GlobalProtect with conditional connect failing to detect internal gateway due to IHD failing

GlobalProtect with conditional connect failing to detect internal gateway due to IHD failing

1068
Created On 02/12/25 04:33 AM - Last Modified 07/01/26 20:54 PM


Symptom


  •   GlobalProtect sessions did not automatically reconnect after reboot
  •   We notice that IHD is failing with the error resulting in the network type being detected as external:  

(P6472-T9388)Debug(2091): 12/16/24 12:04:36:393 IP 172.16.0.1

(P6472-T9388)Debug(2110): 12/16/24 12:04:36:393 host <hostname.com>

(P6472-T9388)Debug(2128): 12/16/24 12:04:36:414 DnsQuery returns 9003

(P6472-T9388)Debug(2145): 12/16/24 12:04:36:414 Resolved 1.0.16.172.in-addr.arpa for internal host detection with return value 9003

(P6472-T9388)Debug(11565): 12/16/24 12:04:36:414 CPanMSService::SetProxyAgentNetWorkType previous 1  now 1

(P6472-T9388)Debug(11581): 12/16/24 12:04:36:414 CPanMSService::SetProxyAgentMode pre mode 4  mode 1

(P6472-T9388)Debug(11632): 12/16/24 12:04:36:414 CPanMSService::OnProxyAgentMode: tunnel only mode, try stop start agent proxy

(P6472-T9388)Debug(11904): 12/16/24 12:04:36:414 CPanMSService::ProcessProxyAgentPortalConfig::Conditional connect: yes

(P6472-T9388)Debug(11920): 12/16/24 12:04:36:414 CPanMSService::ProcessProxyAgentPortalConfig:: Conditional connect is enabled and external network, enable on demand mode

(P6472-T9388)Debug(12361): 12/16/24 12:04:36:414 CPanMSService::ProcessPortalConfig portal default-browser value is 0.



Environment


  •  GlobalProtect (GP) w/ conditional connect
  •  Internal host detection configured (IHD)
  •  Windows or macOS host


Cause


  •  The customer wasn't saving the username during SAML authentication resulting in us presenting an empty username while attempting to restore the cached Portal configuration
  •  They also had SSO enabled which resulted in mismatched usernames during authentication attempts


Resolution


To resolve the issue we completed the following steps:

  1.  First we reviewed the GP logs and found that the App wasn't presenting a username while attempting to restore the cached Portal configuration because it's not configured to save the username/credentials as shown below: 

(P6692-T1288)Debug(3643): 01/23/25 11:03:18:297 Portal portal.com, user , logonDomain ABCDEFG, saved user , path C:\Users\username\AppData\Local\Palo Alto Networks\GlobalProtect\

 

  1.  After the empty username connection attempt fails then the App falls back to Single Sign On (SSO) to retrieve the user's credentials which isn't a recommended setting while using SAML authentication unless the logon/SAML username formats are exactly the same

(P6692-T1288)Debug(9369): 01/23/25 11:03:18:297 User name for cached portal confg: user.name%abcdefg.com

(P6692-T1288)Debug(3948): 01/23/25 11:03:18:297 CheckCachedPortalForPrelogon 0, PrelogonNeedTimeout 0, RenameTimeout -1, userName user.name%40abcdefg.com, preUsername user.name%abcdefg.com

 

  1.  Next we modified the Portal's configuration to save the username only by navigating to "Network > GlobalProtect > Portals > [select appropriate Portal] > Agent > [select agent configuration] > Authentication > Save User Credentials: Save Username Only"
  2.  (Optional) Under the same Authentication tab we also enabled the Portal to both generate and accept authentication override cookies to ensure a seamless user experience by selecting both check boxes under the "Authentication Override" section. Please note that this requires a lifetime to be set along with providing a valid certificate used to encrypt/decrypt the cookies as discussed further here 
  3.  (Optional) You can also enable the Gateway to either generate and/or accept an authentication override cookie as well by navigating to Network > GlobalProtect > Gateways > [select appropriate Gateway] > Agent > Client Settings > [select client configuration] > Authentication Override > select either or both checkbox(es) along with providing a lifetime and certificate to encrypt/decrypt the cookie
    •  Note: It's required to use the same certificate if you're only generating a cookie on the Portal and only accepting it on the Gateway
  1.  Upon retesting we now see the following log during the attempt to restore the cached Portal configuration resulting in a successful internal host detection process allowing the App to properly detect the internal network

(P6180-T7824)Debug(3643): 01/23/25 10:40:45:819 Portal portal.com, user User.Name%40abcdefg.com, logonDomain ABCDEFG, saved user , path C:\Users\username\AppData\Local\Palo Alto Networks\GlobalProtect\

<+++++++++++++++++++>

(P6180-T7824)Debug(9369): 01/23/25 10:40:45:819 User name for cached portal confg: User.Name%40abcdefg.com

(P6180-T7824)Debug(3948): 01/23/25 10:40:45:819 CheckCachedPortalForPrelogon 0, PrelogonNeedTimeout 0, RenameTimeout -1, userName User.Name%40abcdefg.com, preUsername user.name%40abcdefg.com

 



Additional Information




Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000sdNvCAI&lang=en_US&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail