Why Hotel and Airport Wi-Fi Breaks Your VPN

Guest networks in hotels, airports, and cafés work by intercepting your first connection attempts and redirecting them to a sign-in page. A VPN that connects automatically defeats that interception, so the portal never appears, the network never authorises you, and everything appears to hang. The problem is almost never your VPN configuration — it is the order in which two systems that both want to control your traffic get to act.

Get the sequence right and these networks are unremarkable.

What a captive portal actually does

When you join the network, you get an address and a resolver, but the gateway refuses to forward your traffic to the wider internet. Instead it answers your early requests itself, redirecting them to a local sign-in page where you accept terms, enter a room number, or pay.

To do that, the portal has to see and modify your traffic. It commonly redirects name lookups, intercepts plain web requests, and only permits general traffic once your device’s address has been added to an allowed list. Until that happens, an encrypted tunnel to an outside server cannot be established, because the outside server is unreachable.

Modern devices help by probing a known address on join and popping the portal up automatically when they see a redirect instead of the expected response. That probe is also the thing a VPN’s always-on mode can prevent.

The three symptoms and what each means

Nothing happens at all — no portal, no internet. Your VPN or a kill switch is blocking traffic before the portal can be reached. Disconnect the tunnel, let the portal load, sign in, then reconnect.

The portal loads but the sign-in never completes. Often a custom DNS setting or a filtering profile is interfering with the portal’s own hostnames. Temporarily reverting to network-assigned DNS is the usual fix.

You sign in successfully but the VPN will not connect. Now you are past the portal and into ordinary restriction: the network permits web traffic but blocks the protocol or port your VPN uses. This is a different problem with different remedies, below.

Telling these three apart takes seconds and saves a great deal of guessing. The broader version of that diagnostic habit is in blocked by the network or the service.

The correct sequence

Turn the VPN off, including any always-on or auto-connect setting, before joining the network.
Join the network and wait for the portal. If it does not appear, open a plain, non-encrypted address in a browser to trigger it.
Complete sign-in, including any terms checkbox and any room or ticket detail.
Confirm you have real internet access with one ordinary page.
Connect the VPN, then re-test.
Re-enable always-on once connected, if you use it.

Do steps one and two deliberately rather than fighting the tunnel. A kill switch doing its job is not a malfunction — it is refusing to leak while unauthorised, which is what you asked it to do.

Guest networks are frequently restricted beyond the portal. Common causes, in the order worth trying:

Blocked ports or protocols. Networks that permit only standard web traffic will drop a tunnel on an unusual port. Most apps offer an alternative protocol or a mode that presents traffic on a common port; switching is the single most effective change.
Enforced local DNS. Some networks redirect all name lookups to their own resolver and block others.
Per-device session limits. Sign-in may be tied to one device or one MAC address at a time.
Bandwidth shaping. A connection that establishes and then stalls under load is being shaped, not blocked.

If a different protocol fixes it, that is worth remembering as your default for guest networks rather than something you rediscover each trip.

The privacy point people miss

Everything you do before the tunnel comes up happens on the network’s terms. That includes the portal sign-in itself, which frequently asks for a name, room number, email address, or loyalty number, and any automatic background traffic your device generated while joining.

You cannot avoid that entirely, but you can reduce it:

Sign in with the minimum information the portal will accept.
Do not use portal sign-in as an opportunity to log into anything else.
Connect the tunnel before doing anything that matters, then leave it up.
Prefer your own cellular connection for genuinely sensitive tasks if you have data available; the choice between carrier data and hotel Wi-Fi is discussed in roaming vs local SIM vs eSIM.

Why hotel networks are worse than airport networks

Airport networks are usually simple: accept terms, get a time-limited session, done. Hotel networks tend to be more elaborate — tiered paid plans, room-number binding, per-device charges, occasionally an in-room wired connection with different rules from the lobby Wi-Fi. More moving parts means more ways for the portal step to go wrong.

Hotels also more often run older equipment with aggressive filtering, so the “portal works, tunnel does not” case is more common there. If your protocol switch works in the lobby but not the room, you are on two different networks with two different policies, and that is worth knowing before you conclude anything about your provider.

Bottom line

A captive portal has to intercept traffic and a VPN exists to prevent interception, so one of them must go first. Sign in on the network’s terms, then bring the tunnel up and leave it up — and if the tunnel still fails, change protocol before you change anything else.