Captive portal and VPN deadlock: which one moves first
A hotel portal needs traffic before the tunnel exists; the VPN blocks until the tunnel is up. Compare the two orderings and what each exposes in the gap.
The hotel's portal wants a browser before it will pass any traffic. Your VPN refuses to pass traffic before its tunnel is up. Each side is waiting for the other, and both are behaving exactly as configured. Only two orderings break that deadlock, and they differ in what they expose while the gap is open. Pick one deliberately instead of toggling whatever setting makes the browser load.
Two orderings, one of them works
Either the network admits you first and the tunnel comes second, or you open a narrow exception for the portal and restore the block afterwards. Both are legitimate. What is not legitimate is disabling the block and forgetting to put it back.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
The two orderings are not equally good in every situation. A managed device with a mandated admission process has one answer, and a personal laptop on hotel Wi-Fi has another. The comparison is about what each option gives up.
Start by knowing which one your client and your device policy actually support.
Option A: admit the network, then connect the tunnel
Confirm the expected network name, then use the operating system's sign-in prompt or the client's supported captive-portal flow. On iPhone and iPad, dismissing the sign-in sheet can either drop the association or keep it with a warning that the network has no internet, and those are different starting points. Complete the admission step first, then bring up the tunnel. This ordering keeps the block intact for the entire time the tunnel is down.
The catch is that a portal which authorizes internet access has not authenticated your VPN account. The tunnel still has to connect afterwards, and it can fail for its own reasons. Admission and authentication are separate events that people merge into one.
If admission keeps expiring, note whether the portal asks again, the network drops, or only the VPN fails.
Option B: a narrow sign-in exception, then restore the block
The alternative is to permit the portal's traffic while the block stays otherwise in force, sign in, and then remove the exception. The exception has to be narrow: one destination or one address range, for the duration of the sign-in, with the block restored immediately afterwards. A broad temporary window is how a two-minute sign-in becomes an afternoon of unprotected traffic.
Know what your client actually implements. OpenVPN Connect on macOS documents captive-portal detection separately from its option that blocks internet access while the VPN is paused or reconnecting. Detecting a portal and permitting its traffic are related tasks, not interchangeable promises.
On a managed device, follow the configured admission process rather than inventing an exception.
What the gap exposes, and to whom
The interesting part of the deadlock is not the browser tab in front of you. It is everything else that starts using the network the moment connectivity appears: mail, photo sync, update checks, a chat client reconnecting, a backup agent resuming.
A quiet browser window tells you nothing about those. Close or pause sensitive work before any permitted direct-access interval, and check what runs at login. On Android, always-on VPN paired with blocking connections outside the VPN is the relevant control, and an arbitrary route exception is not a substitute for understanding it.
This is the one place where older advice about temporary access windows still holds. The concern was right even where the mechanism was not.
How to choose and how to confirm it
Choose Option A when the device or the client supports a real portal flow, because it keeps the block intact throughout. Choose Option B when the portal cannot be reached any other way, and treat the exception as a timed change with an owner.
Then confirm the sequence rather than the outcome:
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'Complete admission, establish the intended profile, restore any temporarily changed blocking control, and then make a fresh harmless request and confirm it follows the tunnel. A request that succeeds because the block is still off proves nothing about the tunnel.
Switching the VPN exit will not renew an expired hotel session. Those are different events, and mixing them up sends you looking in the wrong place.