On this page
A hotel login page and a strict VPN kill switch often want opposite things. The portal needs local, unauthenticated connectivity; the VPN client may deliberately block that connectivity until its tunnel works.
You cannot guarantee an uninterrupted tunnel when the underlying network refuses internet access. You can keep applications blocked, authenticate deliberately, and restore verified protection before sending sensitive traffic.
Separate portal access from protected access
Treat portal authentication and VPN readiness as different states. Joining Wi-Fi only establishes a local connection. The gateway may still redirect HTTP requests, restrict DNS, or reject the UDP traffic your tunnel needs. A connected Wi-Fi icon says nothing about internet availability or VPN protection.
Use the API Response Latency & Status Tester below to check a public HTTPS endpoint you control after each transition. Compare successful status codes and response times before and after reconnection. It measures browser reachability, not encryption or the route taken by every application. Browser cross-origin restrictions can prevent a readable response even when connectivity works.
Keep a known-good endpoint handy, and record its expected status. Do not enter passwords, session tokens, or private API URLs into diagnostic tools. The objective is repeatable connectivity testing, not a way around access controls.
Prepare a bounded sign-in window
Before joining, pause cloud synchronization, downloads, email clients, and backup jobs. Close sensitive browser tabs because background requests may continue without interaction. On managed equipment, follow your employer's acceptable-use policy and ask IT whether public hotspots are permitted.
Find the VPN client's captive portal mode or documented temporary exception, if offered. Prefer an exception that leaves other applications blocked. Some clients allow only a portal helper; others suspend the entire kill switch. Read the setting carefully instead of treating both behaviors as equivalent.
Use this sequence when the product supports it:
- Enable the VPN client's normal protection before connecting.
- Join the venue's verified SSID and wait for the operating system's login prompt.
- Open only the portal helper or the network's documented sign-in page.
- Complete the authorized login, then immediately exit the exception mode.
- Reconnect the tunnel and verify traffic before reopening applications.
If no bounded exception exists, disconnect Wi-Fi first while reviewing the client's instructions. A manual pause may expose unrelated traffic; it is not equivalent to protected sign-in. When that risk is unacceptable, use a trusted cellular connection. The native firewall and kill-switch guide explains the distinction between client state and enforced policy.
Diagnose redirects without trusting them blindly
On a Linux laptop with curl installed, these checks distinguish an HTTP redirect from an HTTPS certificate failure. Substitute an endpoint you operate for the HTTPS test when available. Time limits prevent a stalled hotspot from hanging your session indefinitely.
curl --max-time 10 --connect-timeout 5 -I http://example.com/
curl --max-time 10 --connect-timeout 5 -I https://example.com/A redirect from HTTP to a venue login can be normal. An HTTPS certificate warning is not a prompt to disable validation. Do not use curl's insecure option, install a hotspot's root certificate, or submit account credentials into an unexpected domain to make the warning disappear.
These commands do not automatically follow redirects. Inspect the Location header, then use the operating system's portal assistant or a verified portal address. Some portals do not handle HEAD requests correctly, so a failed header-only request is inconclusive. Avoid repeatedly sending sign-in credentials through command-line experiments.
Modern portal signaling can reduce guessing, but deployment varies. RFC 8910 describes discovery information, while RFC 8908 defines the captive portal API. Neither guarantees that every hotspot implements it. A portal that works on one phone may fail on a laptop with different DNS and firewall settings.
Restore the tunnel and verify routing
After authorization, reconnect with the client's normal profile and reenable its kill switch. For a full-tunnel policy, check both IPv4 and IPv6. An IPv4 default route through the VPN does not automatically cover IPv6. Successful browsing also does not prove DNS uses the intended resolver.
These Linux commands show routing decisions and resolver configuration without changing them. Replace the interface name if your WireGuard tunnel is not called wg0; omit the WireGuard command for other protocols.
ip route get 192.0.2.10
ip -6 route show default
resolvectl status
sudo wg show wg0The documentation address is only a route lookup target; do not expect it to host a reachable service. Some VPN applications use policy routing or firewall rules requiring additional inspection, so interpret output alongside client diagnostics. A recent WireGuard handshake is evidence of peer contact, not proof that every request took that path.
Compare an external IP check from a trusted service with the expected VPN exit, and review DNS behavior using your client's documented diagnostics. Repeat the browser latency and status test against the same endpoint. WireGuard's quick start explains the peer tools behind these checks.
Handle expiry, roaming, and failed recovery
Hotspots commonly expire sessions after a time limit, idle period, or network change. A reconnect loop may be an authorization problem, not a broken VPN configuration. Stop retrying long enough to check portal state, especially after waking a laptop or moving between access points.
Use a recovery checklist: confirm the SSID, inspect the portal assistant, check the clock, and test ordinary reachability before changing VPN settings. Incorrect device time can cause TLS failures that resemble captive portal interference. Record the failure stage rather than collecting unnecessary packet payloads on a shared network.
Do not change DNS to arbitrary public resolvers just to force the login page to load. Some portals require the venue's initial resolver path, while encrypted DNS settings can complicate discovery. If a temporary resolver change is necessary and authorized, note the previous setting and restore it before normal browsing.
For repeated failures, ask the venue for its supported procedure or switch networks. Do not disguise traffic to defeat controls on networks you do not administer. Follow local law and service terms. Public Wi-Fi also cannot make an untrusted device safe; consult EFF's Surveillance Self-Defense for broader device guidance.
Keep recovery notes that identify the working sequence without storing room credentials or account tokens. A useful note records which portal helper opened, whether the VPN exception affected every application, and whether protection resumed automatically. Test these details again after updating your VPN client because behavior can change between versions.
Key takeaways
- Keep portal login separate from work, with background applications paused.
- Prefer a documented bounded exception rather than globally disabling protection.
- Never bypass certificate warnings or install an untrusted root certificate for access.
- Confirm tunnel state, IPv4 and IPv6 policy, DNS, and endpoint reachability after login.
- Recheck authorization or choose another network when recovery repeatedly fails.
Reach designers & developers at work
Put your product next to the tools people use every day. One sponsor per placement, no tracking pixels.
Become a sponsor
