Windows Clients – Captive Portal Not Triggering with GlobalProtect Always-On Enabled

[bilal_guclu]

Hello everyone,

We are using a Captive Portal on our Palo Alto firewall at the headquarters. When users enter the building and connect to the wireless network, a Captive Portal pop-up is presented, and users gain internet access after entering their username and password.

At the same time, our end users are operating under a GlobalProtect Always-On architecture, where internet access is restricted unless the VPN is connected.

The issue we are facing is the following:

• Only Windows users report that the Captive Portal does not appear when they arrive at the office and connect to Wi-Fi

• If we disable Always-On for the affected users, or uninstall and reinstall the GlobalProtect client, the issue is resolved

• In some cases, the issue only resolves after multiple system reboots

We have already:

• Allowed access to Captive Portal-related IPs/FQDNs so that users can reach them even when VPN is not connected

• Confirmed that this behavior only occurs on Windows endpoints (macOS users are not affected)

Despite these steps, the problem still persists.

Has anyone experienced a similar issue with GlobalProtect Always-On on Windows in combination with a local Captive Portal?
If so:

• Was this related to Windows network detection (NCSI), captive portal detection, or GlobalProtect pre-logon / always-on behavior?

• Are there any recommended workarounds, registry settings, or known bugs?

• Did a specific GlobalProtect agent version resolve this issue?

Any suggestions or shared experiences would be greatly appreciated.

Thank you.

[JayGolf]

Hi @bilal_guclu ,

Which GP agent version are you currently running? I see there are Windows-specific captive portal issues with Always-On that were addressed in later 6.x releases. If you’re on an older version, upgrading to 6.0.11, 6.1.6, 6.2.7, 6.3.3, or later would be the first thing I’d recommend checking.

If possible, could you also take a look at PanGPS.log from an affected Windows endpoint? I’d focus on entries showing network unavailability, failures retrieving portal configuration, or anything related to cached portal settings. What do you see?

[bilal_guclu]

Hi,

We are currently using GlobalProtect version 6.3.3-c711. Previously, we were running version 6.3.2, and the same behavior was observed in both versions.

In the PanGPS logs, I can see that the captive portal addresses are allowed. However, “Enforce GlobalProtect for Network Access” is enabled in the GlobalProtect connection.

For internet access to be available, the captive portal must be reachable. Since the VPN connection cannot be established, GlobalProtect blocks internet access entirely. Even though the captive portal addresses are configured as exclusions (and I can confirm from the logs that they are indeed excluded), for some reason GlobalProtect still does not allow the traffic, preventing the captive portal process from completing.

[JayGolf]

@bilal_guclu ,

Got it...do you have Captive Portal Exception Timeout configured? (Network > GlobalProtect -> Portals -> Your Portal Config -> Agent -> Agent-Config -> App) By default this value is 0, which means GP can block traffic immediately on Windows before the captive portal flow completes. 

The timeout value range is 0 to 3600. For example, a value of 60 means the user has one minute to log in to the captive portal after GP detects it. 

[bilal_guclu]

If you are referring to that timeout value, yes we already tried it, but it made no difference

[JayGolf]

 

How about checking the Pre-Logon Tunnel Rename Timeout (sec) (Windows only) ? The default value is -1, which means the pre-logon tunnel does not time out and continues enforcing pre-logon behavior. A value of 0 causes the pre-logon tunnel to terminate immediately and forces a clean transition.

Even though the name references “pre-logon,” the impact of this setting isn’t limited to user login. On Windows, it can influence behavior while the device is still determining network state (for example, right when it connects to Wi-Fi), which is when captive portal detection should occur.

Could you try setting this to 0 and see if that changes the behavior?