Internal host detection not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Internal host detection not working

L6 Presenter

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
20 REPLIES 20

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

L1 Bithead

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

L6 Presenter

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

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.

 

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


@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

  • 9190 Views
  • 20 replies
  • 0 Likes
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!