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]

Some more testing has revealed an odd pattern:

1) Laptop not currently connected to any network, first ever attempt to connect to new Wifi-Internal:

Connects to Wifi-Internal with cert, gets DHCP, GP client recognizes internal host, switches to Connected-Internal. Can disconnect/reconnect to Wifi-Internal and works correctly.

2) Reboot laptop, or take laptop home and connect via normal VPN, bring laptop back to office and try to connect to Wifi-Internal:

Connects to Wifi-Internal with cert, gets DHCP, GP client does not recognize internal host, prompts for VPN login.

3) Connect laptop to Wifi-Public, connect to VPN, switch from Wifi-Public to Wifi-Internal without logging out/disconnecting from VPN:

Connects to Wifi-Internal with cert, gets DHCP, GP client recognizes internal host, switches to Connected-Internal.

4) Connect laptop to Wifi-Public, connect to VPN, disconnect from VPN, switch from Wifi-Public to Wifi-Internal:

Connects to Wifi-Internal with cert, gets DHCP, GP client does not recognize internal host, prompts for VPN login.

[Adrian_Jensen]

Bump... Still fighting with this, detection is still very sporadic. If you are currently connected to the VPN and switch to the internal network (switch Wifi networks, suspend laptop offsite and come onsite and connect the internal network, etc.) then it auto-detects and goes to internal mode. But if you disconnect from the VPN (disconnect, select a different portal, reboot PC, etc.) and then join the internal network, it will sit forever at the VPN auth prompt.

PanGPS logs show no indication of DnsQuery happening on internal network and packet dumps show lots of DNS traffic, but not the host detection query (I can manually query DNS successfully from the internal network). 

[Adrian_Jensen]

So... This is sill working intermittently. We have found that if you explicitly login to the Portal first, the GP Client will do the internal host detection and show "Connected - Internal". However if join the internal network after a power off/reboot, or some time away on the external gateway, the GP Client will usually not do an internal host detection.

PA support is now telling us that you have to log into the Portal every time, before the GP Client will do internal host detection. Is this right? You have to be connected to the Portal before the client will even attempt to determine if it is on an internal network? What is the point of having an internal network detection then, if you have to login anyways?

Logging into the Portal first is a problem for us, and a challenge for end users to move from network to network, as we require a full MFA login and there are places in the building where cell coverage does not work...

[Mick_Ball]

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

[Adrian_Jensen]

I had previously tried to get cert auth to the portal working (to then move MFA to the GW) and could not, both the GP client and a browser would fail to submit the user or machine cert to the portal and then login would fail with a "Valid client cert is required". I had a support ticket open but never got anything useful on it and gave up... My certs work fine for internal Wifi auth.

Do to Infosec policies, I am required to do multiple things which make working around the tendency of the GP client to cache creds/try to autologin a pain.

 - always-on vpn

 - no autologin

 - MFA login (thru third party)

 - automatic disconnect after x hours

 - management doesn't want dual login prompts

[Mick_Ball]

Cert auth works fine for us, seems you are falling at the first hurdle… we have used cert auth since day one and had no issues…

happy to advise if I can…

[Adrian_Jensen]

Perhaps you can. I have user and machine certs signed by our internal corporate CA on the GP client machines. The CA cert is loaded and marked as a Trusted Root CA on the PAs. The portal is setup with Authentication pointing to a Certificate Profile (no Client Authentication entries), and the Certificate Profile has the corporate CA. I have tried multiple options in the Profile and with/without Trusted Root CA set in in the Portal->Agent config... All with no luck... I have a couple theories but I could never seem to get support to answer some questions directly:

1.  Our external Portal is currently signed by a public Entrust CA, not our internal corporate CA, so externally it validates correctly (though I'm not sure this really matters as the only people connecting should be from corporate PCs). Does the Portal->SSL/TLS Profile cert have to be signed by our internal CA in order for the client to recognize/present a user cert signed by the same CA?
2. We currently have 2 versions of the internal corporate CA loaded on the PAs: a version that is set to expire in 2023 (that still has some existing machine and PA certs linked to it) and a renewed version that expires in 2026. When I create a new CSR on the PA (say for a new Portal), sign it with the 2026 CA, and then load the signed cert back onto the PA, the PA shows the new cert as dependent on the 2023 CA, not the 2026 CA. The GP client user/machine certs are all signed by the 2026 CA. Is this a problem?
3. Not that I seem to have gotten this far yet... but for the Certificate Profile-> Username Field, the Subject field (and SAN) of our internal user certs is an email address based on our external domain, not our internal corporate path... So how can the cert-based Portal auth select the right user (referring to some PA docs on cert-based auth where it says the username will be taken from the cert, or set to "None" for machine certs, but "None" that fails with a commit error on my PA)? Or perhaps this doesn't matter as we will then redirect to the Gateway and do user/pass/PFA there? 

[Mick_Ball]

Hi Adrian,,,,   I am no cert guru but i can answer some of your questions..

1. No. there is no link between ssl/tls profile and authentication certificate profile.  we have an externally signed cert for ssl/tls and a mixture of AD corp cert and PA self signed for user auth..

2. not sure..  usually th PA willl determine which cert can be used against what the user is offering..  in one of our cert profiles there is a few different CA's and any user cert generated by them will work..  can't really answer on the dependencies...

3. the username here is not really relevant as long as the user cert was generated by the CA, the profile will then log you in as whatever is in your field.  if you set this to none then commit will fail because your cert is the only auth method. if you set this to none then you must add another auth profile..

how do you generate your  certs and by what method do you distribute them?

[Adrian_Jensen]

Our user/machine certs are being generated/updated by AD automatically, signed by our corporate CA. I am generating CSRs on the PA for the management (testing portal) interface and signing them with the corporate CA.

[Mick_Ball]

Is that process documented, I use a different approach. Our AD is issuing user certs but we just have a copy of the AD root CA on the palo. Perhaps you should generate a self signed root CA on the palo and then use that to generate a user cert. Only to check that you are setting up cert profiles correctly. Then perhaps compare that user cert with the AD user cert…. 

[Adrian_Jensen]

Yes, I have a copy of the AD root CA on the PA... the cert doesn't have the private key of course, that remains on the AD. So the PA can't create sub-cert off the CA, it just knows that is a trusted root. Then I create a CSR on the PA and sign it with the AD root CA (or intermediate) for the PA management interface/etc. certs. The clients all have the public half of the AD root CA as well, so they see the PA as trusted.

  root CA (on AD server - private/public key pair, on clients - public key only)

  --> server machine cert (on individual machines, signed by root CA)

  --> user cert (in user profile, signed by root CA)

  --> intermediate CA (on cert server - private/public key, on clients public key only, signed by root)

    -->  machine cert (on individual machines, signed by intermediate CA)

    -->  user cert (on individual machines, signed by intermediate CA)

    -->  PA mgmt interface cert (on PA, signed by intermediate CA)

For decryption of traffic, yeah the PA needs a root cert with private key so it can generate new certs on the fly. The public half of that root is also on the clients.

[mkroell1]

I'd like to jump in on this. I am having the same issue. Mine has nothing to do with authentication though, just on proper internal host detection. I am using a mix of Certificate Authentication & SAML. If both Computer & User certs are available, then no prompt happens, internal or external.

• When I connect to Corp Wifi It shows as Internal
• when I connect to non-corp wifi, it connects with a tunnel.
• When I switch back to Corp, it just reconnects the tunnel and does not switch back to internal.
  • If I turn off Wifi for a while and turn it back on connected to corp Wifi, it still reconnects without switching to internal.
• Mac & PC going to sleep and resuming still connects back to a tunnel.
• Mac & PC, Logout and back in, the connect switches back to internal.

In all cases, refreshing the connection puts the device back to internal, but users are not going to do that.

[Mick_Ball]

@mkroell1 

when this happens…

When I switch back to Corp, it just reconnects the tunnel and does not switch back to internal.

select refresh… what happens ???

[mkroell1]

Sorry, I forgot to include that refresh then fixes it.