Internal host detection not working

[Adrian_Jensen]

Anyone have anything to look at for getting Internal Host Detection to work? I have been tearing my hair out for several days tying to figure out why the GP client will occasionally detect internal, but mostly defaults back to requiring a VPN login.

The setup is a new Wifi SSID (with corporate cert login) that is to be an internal network. Our GP clients are configured for User-Login (Always On) and connected from home or the corporate general Wifi (different SSID). I have setup the Internal Host Detection, PC can connect to the new Wifi just fine and query the DNS records without issue - rDNS name matches Hostname. The first time a PC connects to the new Wifi the GP client detects it is on the internal network and allows connection as expected. After logging out/switching to a different network that requires VPN connection, and then switching back, the GP client will no longer detect it is on the internal network again.

Looking in the PanGPS.log, there are DNSQuery = 9003 errors when off network (as expected). When on the new Wifi there are no DNSQuery entries in the logs and no indication the GP client is attempting to do rDNS.

Things looked at/fixed already but didn't change behavior:

• verified rDNS entry, resolvable on command line when internal, fixed case as I found a note saying it is case sensitive but it was intermittently working before changing as well
• limited DNS servers, DHCP previously returned 3 DNS servers but the GP client only allows traffic to 2
• changed to a completely different internal host for detection
• changed automatic restoration of VPN timeout to 0min

[Adrian_Jensen]

Yeah, the GP client will try to reconnect to the gateway automatically for the timeout period, even if you have switched to an internal network. As MickBall says, you can refresh, or you can block connections from the internal network to the gateway, or you can disable the gateway reconnect timer in:

Network->GlobalProtect->Portal->[config]->Agent->[config]->App->Automatic Restoration of VPN Connection Timeout = 0

[mkroell1]

Timeout was going to be my next step to try. How will this work with always-on connections? Will it try to reconnect even if this timeout is 0?

I can't block, which is what I'd rather do because I'm using Prisma mixed with on-prem

[Adrian_Jensen]

My understanding is that it won't automatically reconnect to the gateway. But I am still testing that in practice.

[mkroell1]

Did some initial testing. Always-on seems to try to connect every time the network connects but doesn't try to recycle the tunnel if it was previously connected, resulting in a new authentication attempt. I think this will work well for our use case.

[Mick_Ball]

@Adrian_Jensen , try using the copy of the root CA on it’s own in the cert profile, that’s pretty much what we do…

@mkroell1  be careful no to set timeout too low as may cause a reconnect on the occasional packet loss…

[mb_equate]

---

@Mick_Ball wrote:

Yes this is the correct behaviour. 
Internal host detection was originally added to determine whether internal or external gateways should be used but has become a convenient way to prevent external gateway connection when connected to the corp lan (By not actually entering any internal gateways). Could you not use cert auth to the portal and MFA to GW when prompted… or select your current app config to “on demand”.

---

I'm glad I saw this, my client has a similar issue with portal MFA on internal networks - if a user can already access resources it conditions them to close the SAML auth prompt which has the effect of disabling the client which is not ideal. For this very reason, 2 days before your reply Mick I also tried cert auth only on the portal - it failed with "client certificate not found" despite being able to use the certificate as an authentication factor (Allow Authentication with User Credentials OR Client Certificate = No (User Credentials AND Client Certificate Required)).

If this worked, it should solve the auth prompts on internal networks but not real-time network location awareness (or near-real time). It would be great if internal host detection ran on a schedule rather than requiring a portal login.

I have a TAC case open as I'm sure the portal should work with just cert-based auth.

FWIW agent configs use pre-login and machine certs are issued by a M$ CA / autoenrollment template.

-Matt

[Arnesh]

Hi All,

Please refer to the section of document - Customize the GlobalProtect App

>> With the Always On connect method, if a user switches from an external network to an internal network before the timeout value expires, GlobalProtect does not perform network discovery. As a result, GlobalProtect restores the connection to the last known external gateway. To trigger internal host detection, the user must select "Refresh Connection" from the settings menu on the GlobalProtect status panel.

Try tweaking the value of "Automatic Restoration of VPN Connection Timeout" or wait the configured amount of time before you connect to Internal Network after disconnecting from external network.

The GlobalProtect application goes through a set of steps to get connected to an external gateway or identify it's internal. One of the initial steps is called "Network-Discovery" when the the IHD (Internal-Host Detection) gets triggered. If the application finds the device is not internal, it moves ahead to "gateway-login" and gets connected to available gateway.

Now, before the above said timer expires, GP app does not start again with the Network-Discovery, but continues with the gateway-login and connects back to an external gateway.

Regards,

Arnesh