Why the Captive Portal Gates Your VPN, and How to Sign In Again

On an open network your access point does not simply hand packets to the internet. An upstream policy point checks whether your device has been authorized yet, and until it has, almost everything is dropped. Your VPN client reads that silence as a dead server. It rarely says so: WireGuard retries a handshake into a void, OpenVPN reports a connection timeout, and IKEv2 comes back as error 809 about a remote server that is not responding.

What the portal actually controls

A captive portal is two things stapled together: a policy decision point and a redirector. When your device associates and takes a DHCP lease, the network places you in a pre-authorization state.

That state is a firewall rule set. It usually permits DNS and permits HTTP or HTTPS to a short list of portal hosts, and it discards everything else. The permitted list is the walled garden, and it almost never includes a VPN endpoint.

None of the dropping is polite. Packets aimed at a VPN server are discarded rather than refused, so the client gets no ICMP unreachable and no TCP reset, only the absence of an answer. Depending on the vendor, the redirector may answer port 80 with a redirect to the sign-in page while port 443 is dropped or intercepted. Redirects are easy to spot because they carry a plain HTTP response; interception on 443 needs a certificate your browser will refuse to trust.

Authorization itself is usually keyed to the device MAC address, sometimes to the leased IP, and it lives in a session table with a timer. Signing in creates an entry. The firewall rule that lets your traffic through exists only while that entry does, which is why the whole problem returns later without anything changing on your side.

Why the VPN handshake dies before it starts

Each protocol has its own transport, and the pre-authorization firewall breaks each one differently. IKEv2 on Windows and iOS rides on UDP 500 and UDP 4500; a drop on those ports surfaces as 809, or as a name-resolution style failure on clients that report stages separately. OpenVPN over UDP 1194 sits in the connecting state until its timeout expires. OpenVPN over TCP 443 is the interesting case, because the portal may complete the TCP handshake and then answer with its redirect page, so you see a TLS error instead of a timeout.

WireGuard shows the mechanism most cleanly. It is UDP-only by design, with no TCP fallback, so a firewall that discards unknown UDP removes the transport entirely. The client keeps sending handshake initiations with growing backoff and reports a handshake that never completes. Nothing in that message mentions Wi-Fi, and nothing in it suggests you should open a browser.

Platforms try to notice the state before your VPN does. Windows fetches a known URL to decide whether to show its sign-in notification, Android requests an endpoint that should answer 204 No Content, and Apple devices open a small captive-network window. Those probes work because the portal answers with a redirect instead of the expected body. The same behaviour explains how a portal can look perfectly healthy while your tunnel is dead: the probe and the tunnel are being judged by different rules.

What a session expiry really resets

Venues expire sessions for reasons unrelated to your VPN account: an idle timeout, a maximum session length, a fresh DHCP lease, or a re-association onto a different access point. When the timer fires, the session table entry disappears and the pre-authorization rule set comes back exactly as it was at check-in.

An established tunnel often survives long enough to look healthy. Keepalives keep going out, and whether the client notices depends on how it treats unanswered traffic, so the status light may stay green for a while after the path is gone. Then the tunnel drops and every reconnection attempt fails on the same blocked ports.

At that point the client error tells you which stage you are at, if you read it carefully:

One detail catches people out: when the session is bound to a MAC address, reloading the sign-in page may not help. You have to drop the association and join again so the portal sees a new authorization attempt instead of an expired one.

Sign in first, then raise the tunnel

The order that works is authorize the device, prove the path, start the VPN, prove the tunnel, then restore your normal blocking. That last step matters because the temporary state you need in order to reach the portal is exactly the state a kill switch exists to prevent.

A desktop client with a block-outside-tunnel option has to be paused for the portal page to load, and you should keep sensitive apps closed during that outside-tunnel window; it is the one interval when local traffic leaves unprotected. A managed always-on device should use whatever procedure its owner published rather than having you remove policy. If the portal presents a certificate warning, stop: accepting it routes your session through the venue's interception proxy, and that proxy can read everything you send. On Android, lockdown under always-on VPN blocks traffic before the tunnel is up, and some builds cannot exempt the portal flow; if yours cannot, use the venue's alternative access or another device instead of leaving lockdown off. Apple on-demand rules can be written to refuse the tunnel until a probe succeeds, which is the behaviour you want on hotel networks.

Verify in order with tools you already have. Before the tunnel, run the probe with the headers and body both visible, and watch whether your VPN transport gets any answer at all:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Before authorization, a normal portal gives one of two answers: a 302 whose Location points at the sign-in page, or a 200 with an HTML body that is the portal page. Record which one you got. A redirect is not a failure before sign-in; it is the portal telling you where to go. After the portal reports success, repeat the command and expect a 200 whose body is the literal word Success. That string is what makes the probe meaningful. If the host answers normally before you ever signed in, there is no intercepting portal on this network. In the capture, a pre-authorization drop is outbound packets with nothing coming back, while a path that works shows a reply to the same flow within a second or so. Connect, then repeat the capture.

If the tunnel still fails after the portal says yes

Sign-in success is not the same as permitted transport. Plenty of venues allow the portal and ordinary browsing while blocking UDP outright, which leaves WireGuard and UDP OpenVPN broken and TCP 443 working. If TCP 443 passes and UDP does not, that is venue policy rather than a client you misconfigured, so switch transport or accept the limit and move on. If a reconnect still fails after that, keep the exact error; it names the stage you are stuck at.

Other failures live on the device. A session still bound to an old MAC, a second Wi-Fi adapter with its own lease, or a client that cached the portal's certificate exception can each keep failing after a clean re-authorization. Drop the association, re-authorize, and retry once before you touch client settings. RFC 8952 is worth reading if you want the architecture behind the components you are watching.

If the portal itself refuses to authorize, the problem is account or device allocation and no VPN setting will fix it. Changing the VPN's exit country does not reset the venue's local access state; that table is keyed to your device, not to the server you pick. Ask the venue operator and give them the time, because the session table is what they will look at.

Before your next trip, write down three things: the portal page as step zero, the pause-blocking step for each device you carry, and one transport fallback you have actually tested. When a tunnel that worked ten minutes ago stops again, treat it as expired authorization and re-check the portal before you touch the VPN profile.