GlobalProtect: always-on pre-logon external and not logon internal is not working

Showing results for 
Show  only  | Search instead for 
Did you mean: 

GlobalProtect: always-on pre-logon external and not logon internal is not working

L3 Networker

I am trying to setup GP as always-on (pre-logon) when the user is external and not connect while internal. My understanding was that the internal host detection setting was suppose to let the client know that it was internal and not try to connect to the external gateway. That does not seem to work, or most likely I just did not understand the way it works.


Goal: user auto-connects to GP while external and does not connect to GP while internal

Current config: external gateway defined and working, internal host detection defined, no internal gateway defined, users can reach the external gateway while connected internal. If I setup a rule to block access to the external gateway while the user is internal the user gets the error message that the gateway/portal is not reachable.

Current experience: 

  • External: user connects to external gateway is connecting without issue
  • Internal: user still connects to external gateway through the Internet gateway

Things tried:

  • add rule to block access to external gateway (user gets message that gateway/portal is not accessible)
  • add internal host detection (does not seem to make any difference)
  • read as many docs and links that I can find to configure this properly

I have not setup an internal gateway because I cannot figure out how to set it up to so that the traffic does not go through GP while the user is internal. 


Any ideas are appreciated.




Learn at least one new thing every day.

Accepted Solutions

L4 Transporter

One thing that often causes confusion is that the internal host detection needs a PTR record in DNS for the reverse lookup (to resolve the IP to a name), not an A record for a forward lookup (to resolve the name to an IP).  For example, if your internal host detection is set to use gpcheck.mydomain.local with as the address, you must be able to query and get a response of gpcheck.mydomain.local.  Once this is in place, your internal host detection should work.  Then you can permit access to the external portal, so that the agent can still check in for configuration updates, HIPS checks, etc. without the agent establishing a tunnel while on the internal network.

View solution in original post


Cyber Elite
Cyber Elite

Hello there.

I am an ATP (authorized teaching partner) instructor, and we have a lab for GP that we do for our classes.

We set up an internal gateway, so that the user can connect to the FW.  Connecting to the portal (when always on) how pre-logon works.

The clients needs to connect to a gateway, in your case, internal one.


We may not be passing traffic through that gateway, as it not needed for passing traffic, but for establishing your internal login, it is needed. 

Help the community: Like helpful comments and mark solutions

Cyber Elite
Cyber Elite

Hi @BruceBennett 

An internal gateway in your case is not required. You only need to make sure that the DNS reverse lookup is possible in your internal network. This is how GP will detect this. It tries to resolve the specified IP and if the specified name is coming back from the DNS, GP assumes that it is internal.

But the connections to the portal you will see no matter where the client is. So the client also connects to the portal from internal (mainly for configuration updates), but it will not connect with VPN to the gateway.




@vsys_remo That is how I understood what I had read, that I did not have to define an internal gateway as long as the DNS lookup was working. But some working in your response has me questioning it a little. I am confident that I put in the FQDN and IP address correctly, but you mentioned "It tries to resolve the specified IP and if the specified name is coming back from the DNS". if I lookup the address by FQDN I get the IP address, but if I try to look up the IP address, I do not get the FQDN. The direction of that lookup seems odd, but would explain why it is not seeing it as internal.


@SteveCantwell I have setup an internal gateway for testing, but it just does not seem like it is necessary, based on Remo's response and the configurations I have looked at. The internal gateway that I setup is pretty basic and will not create a tunnel, so I think it addresses what I need, but will have to wait for my internal test user to become available for testing again.


Thank you both for the responses. This one has just got me twisted a bit. I think I am following the steps, and even talking through them with my PAN contact, but things are just not flowing as expected.




Learn at least one new thing every day.

@BruceBennett, Hi.

some additional info....

the PanGPS log on the client device will assist with DNS resolution issues.


search the PanGPS log for your internal host detection IP address. (we use




DnsQuery returns 0

The host name is  


is a succesful internal detection.

the following is unsuccesful




DnsQuery returns 1460  or 930 (anything here but a zero)


pan_get_ip_by_host() getaddrinfo failed with error code (11001)!


internal detection works for us and you do not need an internal gateway, not sure if this changes for pre-logon as don't use it.


FYI.  be aware that if you are testing by switching from wifi to LAN then internal detection will not work and you will need to refresh the GP client manually for this to happen. it used to happen but they changed it in a more recent version.  this causes us issues for our users going from meeting rooms (WiFi) to desk (LAN) as GP now tests to see if the gateway is still available before refreshing.  The timeout for this can be adjusted in the app but this then causes issues for roaming. our workaround is to have portal and gateways on different addresses and only allow access to the portal from the LAN. fortunately we have spare addresses to be able to do this.







Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!