- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-04-2022 02:20 PM
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:
03-04-2022 03:51 PM
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.
03-08-2022 12:52 PM
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).
03-10-2022 01:52 PM
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...
03-13-2022 01:35 AM - edited 03-13-2022 03:01 AM
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”.
03-14-2022 08:56 AM
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
03-14-2022 12:16 PM
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…
03-14-2022 02:38 PM
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:
03-15-2022 02:23 AM
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?
03-15-2022 10:34 AM
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.
03-16-2022 01:02 AM
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….
03-16-2022 10:56 AM - edited 03-16-2022 10:57 AM
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.
03-16-2022 12:26 PM - edited 03-16-2022 01:50 PM
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.
In all cases, refreshing the connection puts the device back to internal, but users are not going to do that.
03-16-2022 01:34 PM
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 ???
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!