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

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

bilal_guclu — Wed, 14 Jan 2026 09:06:08 GMT

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.

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

Raido_Rattameister — Wed, 14 Jan 2026 15:15:16 GMT

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.

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

BPry — Wed, 14 Jan 2026 22:01:22 GMT

@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.

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

bilal_guclu — Thu, 15 Jan 2026 11:46:26 GMT

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.