Odd Internal Host Behavior

JakeHarris — Fri, 10 Jun 2022 12:32:46 GMT

Community,

First off, I'm looking for ideas on what could possibly be causing a situation we are experiencing. This is an issue with Always On Mode, using SAML authentication (built in browser, no default browser), in an Internal Host Detection state. We are not having any issues with a remote user at all, only when the user moves from remote to an office.

Global Protect works well normally for internal host detection (no internal gateways). We have a full FQDN DNS recursive lookup configured that works well. However on occasion we will experience a user (usually 1-3 per week) that come into the office (after working on Always on VPN for several days) and can not connect to our internal network. GP gives a connection error and because of traffic policy enforcement they can not connect to anything. 3 things are occurring at the point. 1. Client CAN nslookup the FQDN used for internal host detection, again this works from a command prompt, 2) Client can not communicate on the network, 3) Global Protect does not attempt internal host detection again.

The fix has been to move the client to a public guest network, restart the PAN GPS service and connect the user to the Portal/Gateway. Once this is done, we switch the user back to the production internal network, internal host detection is working again. Note: simply rebooting the laptop does not fix it, restarting PAN GPS service alone does not fix it.

We have clients running 5.2.9 and 5.2.12 that are experiencing this issue (Yes I have a ticket open, but not seeing much progress). We were asked to set the user saving option in our portal config from "Save Username Only" to "No". After doing this, almost every client in this test group began experiencing this issue, and several now experience the issue on every reboot or refresh connection.

Any help would be appreciated!

Looking through pangps.log we see a few errors, which ends up in turning on the enforcer, without a network discovery:

(P17196-T12160)Error( 480): 06/09/22 14:46:41:944 CPanHTTPSession::PostRequest: WinHttpReceiveResponse failed with error code 12152.
(P17196-T12160)Debug(1182): 06/09/22 14:46:41:944 PostRequest error code=12152(The server returned an invalid or unrecognized response)
(P17196-T12160)Debug(7301): 06/09/22 14:46:41:944 prelogin to portal result is (null)
(P17196-T12160)Debug(7603): 06/09/22 14:46:41:944 Failed to pre-login to the portal vpn.mycorp.com with return value 12152(The server returned an invalid or unrecognized response).
(P17196-T12160)Debug(8461): 06/09/22 14:46:41:944 Failed to get portal config from portal vpn.mycorp.com.
(P17196-T12160)Debug(8503): 06/09/22 14:46:41:944 Try to restore last portal config from file.
(P17196-T12160)Debug(8554): 06/09/22 14:46:41:944 Skip retrieve cached portal configuration for empty user
(P17196-T12160)Debug(8481): 06/09/22 14:46:41:944 portal status is Invalid portal.
(P17196-T12160)Debug(7095): 06/09/22 14:46:41:944 --Set state to Disconnected
(P17196-T7972)Debug(2530): 06/09/22 14:46:41:944 Setting debug level to 5
(P17196-T12160)Debug(1927): 06/09/22 14:46:41:944 unknown network type.
(P17196-T12160)Debug(1898): 06/09/22 14:46:41:960 Send response to client for request portal
(P17196-T7660)Debug( 845): 06/09/22 14:47:01:278 enforcer exception: call SPSetParameters to set 2 IPs

Re: Odd Internal Host Behavior

dmifsud — Sat, 11 Jun 2022 11:24:25 GMT

Hello,

On this forum it would be difficult to determine the cause of the Portal connection failure, but I have seen this before when Zscalar was blocking a response. It could really be anything at this stage.

(P17196-T12160)Debug(1182): 06/09/22 14:46:41:944 PostRequest error code=12152(The server returned an invalid or unrecognized response)

Internal Host Detection is setting which comes from the Portal. If the Portal is inaccessible, as it shows above, then the cached Portal config is used.

If you set "Save Username Only" to "No", GlobalProtect will no longer be able to find a cached config, since the name of it includes a hash of the username and relies on saved username to pick it up. That's why you've started to see the issue after disabling it.

(P17196-T12160)Debug(8554): 06/09/22 14:46:41:944 Skip retrieve cached portal configuration for empty user

I would recommend saving the username to ensure a cached config can be used in case of connectivity issues to the Portal. To cache the config, the user will still need to make one successful connection though.

For the WINHTTP error 12152, I would start with checking packet captures and seeing if you can rule out any 3rd party intrusive/security software by disabling them temporarily under test conditions.

- DM

topic Odd Internal Host Behavior in GlobalProtect Discussions

Odd Internal Host Behavior

Re: Odd Internal Host Behavior