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

[BruceBennett]

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.

[S.Cantwell]

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. 

[Remo]

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.

Regards,

Remo

[BruceBennett]

@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.

@S.Cantwell 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.

[Mick_Ball]

@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 10.250.1.56)

IP 10.250.1.56

host prxweb.xxx.xxx.uk

DnsQuery returns 0

The host name is prxweb.xxx.xxx.uk  

is a succesful internal detection.

the following is unsuccesful

IP 10.250.1.56

host prxweb.xxx.xxx.uk

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

IP 10.250.1.56

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.

HTH.

[pkaren]

We have this configured and working in a similar fashion. Internal Host Detection enabled with no internal gateway configured, but I still had to explicitly block access to the external gateway to get the desired behaviour. We don't get any error messages from the client but we have Portal and Gateway on different IPs and only the gateway blocked. We also have additional gateways configured as Manual Only in addition to the pre-logon gateway. 

[BruceBennett]

Thank you for the replies, I appreciate the help.

I have decided to back out the internal gateway changes I made and go with no internal gateway for further testing. Unfortunately, I am not going to get to test this with an internal user until next week. Based on the comments, it looks like I was headed the right direction. 

Testing config: no internal gateway, block access to external gateway, internal host detection enabled.

Thanks again to everyone that replied!

[OwenFuller · Accepted solution]

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 10.0.0.1 as the address, you must be able to query 10.0.0.1 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.

[BruceBennett]

Thank you. I found out today the entry needed to be a PTR record. As soon as I changed the entry to one with a PTR record it started working.

[jdelio]

Just wanted to let everyone know that if they are having any GlobalProtect issues, and need to troubleshoot the issue, our Very own @kiwi has written a great blog all about troubleshooting GlobalProtect.

Be sure to check it out here: 
https://live.paloaltonetworks.com/t5/blogs/dotw-globalprotect-troubleshooting-tips/ba-p/383911