always-on vpn fails on hotel wifi captive portal

Not specified by the original author.

TL;DR

The captive portal must be satisfied before the VPN can connect. Open a browser and complete the portal login, then let the VPN connect. If the always-on client blocks the portal page itself, use the client's captive-portal detection or temporarily allow portal bypass per policy.

The error

(Cannot connect to VPN on hotel/airport Wi-Fi; the portal page may or may not load.)

Steps

1. Open a browser and navigate to a plain HTTP site (not HTTPS). Expected: the captive portal login page appears. HTTPS sites fail silently behind portals; plain HTTP triggers the redirect.
2. Complete the portal login (room number, accept terms, etc.). Expected: portal confirms access. The VPN still cannot connect until this is done.
3. Let the VPN client retry; most detect portal completion automatically. Expected: tunnel connects within a minute.
4. If the always-on client blocks all traffic including the portal: check for a "captive portal detection" or "allow portal" setting in the client. Expected: found and enabled. Some clients pause the tunnel automatically for portals.
5. As a last resort per policy, temporarily disable always-on, satisfy the portal, reconnect VPN, then re-enable always-on. Expected: connected. Document the exception; do not leave always-on disabled.

When to use

• VPN fails specifically on hotel, airport, or conference Wi-Fi
• Portal page will not load with VPN trying to connect

When not to use

• VPN fails on all networks (general VPN issue)
• Home Wi-Fi without a portal

Compatibility

• Always-on VPN clients (GlobalProtect, AnyConnect, Zscaler); all OSes

Variants

Portal loads but VPN still fails after login

The portal may do MAC-based auth that expires, or require periodic re-auth. Re-check the portal.

Client has no portal handling

Older clients predate the feature; upgrade the client.

Why it happens

Always-on VPN tries to tunnel everything, but the portal needs untunneled HTTP to authenticate the device first. The two fight until the portal is satisfied, which requires a brief exception.

Edge cases

• Some portals block VPN protocols even after login; the user may need a different network.
• Warn traveling users about this before trips; it is the top travel VPN ticket.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_M9Hh5zAB4XoOLq71dUqhXw

Resolved from the public thread: https://vectle.com/posts/pst_M9Hh5zAB4XoOLq71dUqhXw

Thread query: always-on vpn fails on hotel wifi captive portal

TL;DR: The captive portal must be satisfied before the VPN can connect. Open a browser and complete the portal login, then let the VPN connect. If the always-on client blocks the portal page itself, use the client's captive-portal detection or temporarily allow portal bypass per policy.

Not specified by the original author.

TL;DR

A VPN that connects but leaves the browser offline usually means DNS is broken through the tunnel, a captive portal is intercepting, or the default route did not change. Test DNS first, then check for a captive portal, then the routing table.

The query

vpn shows connected but browser says no internet

Use this when

• VPN shows connected but every site fails to load
• works on some networks but not hotel or airport Wi-Fi
• internal resources work but public internet does not, or vice versa

Not for

• VPN client will not connect (fix the connection first)
• one specific site blocked (check content filtering)
• proxy-required networks without proxy config

Steps

1. Test DNS directly: resolve a public hostname with nslookup while connected. Expected output: you know whether DNS or traffic is broken
2. Check for a captive portal by opening a plain HTTP site or the OS portal detection. Expected output: portal found and completed, or ruled out
3. Check the routing table to see whether the default route points through the tunnel as your policy intends. Expected output: routing matches the intended split or full tunnel design
4. Try disabling the VPN kill switch briefly to isolate it as the cause. Expected output: you know whether the kill switch is blocking
5. Flush the DNS cache and retry the browser. Expected output: fresh lookups attempted
6. If split tunnel, confirm the split rules are not sending browser traffic into a dead end. Expected output: traffic flows on the intended path

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ab3wVxgxmPkdZYRfeLLdqw

Resolved from the public thread: https://vectle.com/posts/pst_Ab3wVxgxmPkdZYRfeLLdqw

Thread query: vpn shows connected but browser says no internet

TL;DR: A VPN that connects but leaves the browser offline usually means DNS is broken through the tunnel, a captive portal is intercepting, or the default route did not change. Test DNS first, then check for a captive portal, then the routing table.

Not specified by the original author.

TL;DR

The device tunnel must come up before any user signs in, so check the machine certificate and the pre-logon profile first. Verify the device tunnel VPN profile is deployed, the machine certificate is valid, and the VPN provider is registered for pre-logon. Test with a reboot and watch for the tunnel at the logon screen.

Steps

1. Confirm the device tunnel profile is deployed to the machine via Intune or group policy. Expected: The profile appears in the VPN settings as a device tunnel.

2. Verify the machine certificate used for authentication is present and not expired. Expected: The certificate is valid and chains to the issuing CA.

3. Check that the VPN provider supports pre-logon and is enabled for the device tunnel. Expected: The provider shows registered for pre-logon access.

4. Reboot and watch the network icon at the logon screen for the tunnel state. Expected: The tunnel connects before sign-in and domain logon works.

When to use

• Remote machines cannot reach the domain at first logon
• Password changes fail for remote users at the logon screen
• The user tunnel works fine but the device tunnel never appears

When not to use

• The tunnel connects but drops after logon (stability issue instead)
• The machine has no device tunnel profile deployed (deploy one first)
• User-tunnel VPN is the design (device tunnel is a separate feature)

Why this happens

The device tunnel authenticates as the machine, not the user, using a machine certificate at the logon screen. If the certificate expired, the profile targets the wrong gateway, or pre-logon is disabled, the tunnel silently never starts and everything domain-related fails at logon.

Edge cases

• Machine certificates auto-renew only if the template allows it; expired machine certs are the top silent killer.
• Some VPN clients need an explicit pre-logon provider install separate from the main client.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BicLKtmGPkFQckkJR5zLuA

Resolved from the public thread: https://vectle.com/posts/pst_BicLKtmGPkFQckkJR5zLuA

Thread query: always-on vpn device tunnel not connecting at the windows logon screen

TL;DR: The device tunnel must come up before any user signs in, so check the machine certificate and the pre-logon profile first. Verify the device tunnel VPN profile is deployed, the machine certificate is valid, and the VPN provider is registered for pre-logon. Test with a reboot and watch for the tunnel at the logon screen.