One-Device Public Wi-Fi: Why a VPN Exit Cannot Help

The laptop shows Connected, the handshake succeeds, and the portal still refuses to load a page on a second device. That is not a tunnel problem. A hotspot's device limit belongs to its access system, which counts the devices it authorized and the sessions it released. A VPN changes where traffic exits after authorization, and it changes nothing about how many devices that system will admit.

What the Portal Is Actually Counting

Captive portals track an authorization grant, and the grant is normally attached to something the network can identify. A MAC address is the common choice, a session cookie in the browser is another, and some systems combine either one with a room number or a printed ticket. Four devices on one room code means four grants, and a fifth device has none regardless of what software it runs. Installing a VPN on that fifth device changes the answer from refused to refused.

Association and authorization are separate states. A laptop can associate with the access point, hold a DHCP lease and still have no internet, because the portal never granted it anything. Reading the Wi-Fi icon as evidence of portal success is the first mistake in this whole class of ticket.

Confirm the Rule With the Venue

Ask two questions rather than guessing: what device count the account allows, and how a stale session gets released. The second matters more, because a grant left behind by a device that departed is what usually blocks the next one. Reception staff can often release it or issue a new code faster than any client-side workaround. Use that process before changing hardware addresses, since copying another device's identifier breaks the network's terms and puts a duplicate identity on the segment.

Behaviour varies by operator. Some systems bind to a device fingerprint, others to a browser session, and a few allow a fixed number of simultaneous grants that expire on a timer. One venue's policy predicts nothing about the next one, which is why the venue's answer beats any general rule.

Keep Portal and VPN Credentials Apart

A room code is not a gateway login, and reusing a work credential in a portal is a bad trade even when both screens show a username field and a password field. Authorize the intended device first, verify a small ordinary request where the venue permits it, and only then connect the tunnel. That order gives you clean attribution when something fails, because the portal stage was already proven before the VPN entered the picture.

When the portal refuses, the tunnel is the wrong place to debug. Nothing in the VPN configuration can grant access the access system never issued.

What a Travel Router Changes

A travel router can help by presenting one upstream device while serving several locally, and it changes what the portal sees. Authorization binds to the router's identifier rather than to each laptop, and every client behind it shares one grant and one public address. Whether that arrangement is acceptable depends on the network's terms, and many venues prohibit sharing explicitly. A router is a legitimate design where sharing is permitted and a violation where it is not, whatever the technical merit.

None of this removes the limit. It relocates the single grant from a laptop to a router, which is useful for one traveller with several devices and useless for two people who each need their own authorization.

Solve the local authorization problem first. A tunnel that works perfectly still cannot manufacture a grant the access system never issued.