- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-18-2026 11:38 AM
We have Global Protect installed on all of our corporate laptops and our users fall into one of two scenarios:
1. They are a remote user; cannot reach the host we have defined for Internal Host Detection and are required to authenticate to the Gateway with DUO.
2. They are an "on-site" and can reach the host we set for Internal Host Detection and Internal Host Detection should disable the Global Protect services.
The issue we are seeing is that "on-site" users are able to reach the host we have set for Internal Host Detection but are being prompted to authenticate to the Global Protect Gateway to establish the tunnel. The Internal Host detection should be preventing this as I understand it.
03-18-2026 03:54 PM
Hi @R.Singh384240 ,
Could you share the PanGPS.log from an affected user while the issue is occurring?
I’d first like to confirm whether IHD is succeeding consistently during the failure. In the logs, there may be DnsQuery entries and return codes that can help show whether the client is intermittently failing to identify itself as internal.
Also, could you confirm a couple of configuration details:
Do you have any internal gateways configured?
Is the app set to Always-On?
I ask because internal gateways are optional. If IHD succeeds, the client can either connect to an internal gateway if one is configured, or simply remain in an internal state without bringing up the external VPN tunnel.
If Always-On is enabled, there is also a documented behavior where, if a user moves from an external network back to the internal network before the Automatic Restoration of VPN Connection Timeout expires, GlobalProtect may restore the last known external gateway without re-running network discovery immediately. In that case, having the user select Refresh Connection / Rediscover Network can help force a new IHD check.
If the logs show that IHD itself is working normally, then it may be worth testing whether reducing or setting the Automatic Restoration of VPN Connection Timeout to 0 changes the behavior.
03-18-2026 03:54 PM
Hi @R.Singh384240 ,
Could you share the PanGPS.log from an affected user while the issue is occurring?
I’d first like to confirm whether IHD is succeeding consistently during the failure. In the logs, there may be DnsQuery entries and return codes that can help show whether the client is intermittently failing to identify itself as internal.
Also, could you confirm a couple of configuration details:
Do you have any internal gateways configured?
Is the app set to Always-On?
I ask because internal gateways are optional. If IHD succeeds, the client can either connect to an internal gateway if one is configured, or simply remain in an internal state without bringing up the external VPN tunnel.
If Always-On is enabled, there is also a documented behavior where, if a user moves from an external network back to the internal network before the Automatic Restoration of VPN Connection Timeout expires, GlobalProtect may restore the last known external gateway without re-running network discovery immediately. In that case, having the user select Refresh Connection / Rediscover Network can help force a new IHD check.
If the logs show that IHD itself is working normally, then it may be worth testing whether reducing or setting the Automatic Restoration of VPN Connection Timeout to 0 changes the behavior.
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!

