GlobalProtect Always-On (6.3.3-c711) – Users Stuck in “Connecting” State but Still Have Internet Access

[bilal_guclu]

Hello everyone,

We are running GlobalProtect 6.3.3-c711 in an always-on architecture for our end users.

Our setup is as follows:

• Always-On enabled

• Full tunnel configuration (all traffic routed through GlobalProtect)

• Portal → App settings → Restoration interval set to 0 to strictly enforce VPN usage

• Expectation: If VPN connectivity is unavailable, all internet access should be blocked

Despite this configuration, we are observing an unexpected behavior where:

• Some users remain in a “Connecting” state in the GlobalProtect client

• While in this state, they are still able to access the internet without restriction

We have already opened a support case with Palo Alto Networks, but so far we have not received a clear root cause or a definitive explanation.

Has anyone in the community experienced a similar issue with Always-On GlobalProtect?
If so:

• Were you able to identify the root cause?

• Was this related to OS behavior, split-tunnel edge cases, captive portal detection, or a known client bug?

• Did upgrading/downgrading the GlobalProtect agent resolve the issue?

Any insight or real-world experience would be highly appreciated.

Thank you.

[Raido_Rattameister]

Export log bundle from GlobalProtect agent and analyze why it gets stuck at connecting state.

If GlobalProtect is not connected then it is expected for Internet traffic to work directly.

[BPry]

@bilal_guclu,

As @Raido_Rattameister mentioned, this would be expected with how you have things configured. You may want to look into setting up the 'enforce GlobalProtect for Network Access' option ensuring that you have properly configured the enforcement setting and specifying the transition timeline if this is something that you want to truly enforce. There's a couple of tuning points like captive portal timeout that you have to watch out for, and understanding the support aspect in the event that someone simply can't connect for some reason, but that will do what you seem to expect. 

[bilal_guclu]

Hi,

You mentioned “If GlobalProtect is not connected, then it is expected for Internet traffic to work directly.”
However, in our case, “Enforce GlobalProtect for Network Access” is enabled in the GlobalProtect app configuration, and under Endpoint Traffic Policy Enforcement, all traffic is selected.

Therefore, even if the end user is not able to establish a VPN connection, internet access should be blocked. That is exactly the purpose of these settings.

As an example:
If a user tries to connect to another portal where enforcement options are not enabled, and traffic becomes stuck for some reason, I would consider that behavior expected — especially since the endpoint already received that portal configuration (I am explicitly stating this because I tested this scenario).

However, that is not the case here.

What we are observing instead is the following behavior:

• The end user turns on their PC in the morning

• GlobalProtect automatically attempts to reconnect to the same portal it was connected to the previous night

• The client remains in a “Connecting” state, but never actually connects

• Despite this, internet access is somehow restored, even though enforcement is enabled

This behavior is unexpected and contradicts the intended function of Always-On with full traffic enforcement. So far, I have not been able to pinpoint the cause of this behavior from the PanGPS logs.