Hotel Wi-Fi: the VPN fails before it ever reaches the server

The VPN client spins, then reports that it cannot reach the server, and everyone concludes the hotel blocks VPNs. Usually nothing that dramatic has happened: the network has not let you out yet. A captive portal holds every connection until you sign in, and a tunnel cannot complete while its packets are being intercepted by a login page. Work through the sign-in before blaming the tunnel.

The myth: the hotel blocks VPNs

Most hotel networks do not filter tunnels specifically. They intercept web traffic until the guest authenticates, and they may also cap devices, expire sessions or throttle throughput. Each of those produces a failure that looks like a block from the inside of a VPN client.

The tunnel is a poor diagnostic here, because it is the one application guaranteed to fail while the portal is unauthenticated. Ordinary web access is the better indicator, since it can show you the sign-in page itself.

That ordering matters for another reason: a client with a kill switch or always-on mode will refuse to let the portal load, and the user concludes the network is broken rather than the setting. Both facts are true at once, and only one of them can be changed at the hotel. Turn the protection off through the client's own control, sign in, and turn it back on. Anything else is a workaround that hides the real sequence.

Finish the portal first, then test ordinary HTTPS

Ask staff for the official network name and the sign-in method. A convincing SSID is not proof of ownership, and a second network with a similar name is a common trick in public places. Use the operating system's own sign-in prompt where it offers one, or the hotel's documented page.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

The first request asks a well-known captive-portal detection endpoint over plain HTTP; a redirect or unexpected body means you are still behind the portal. The second tests a normal HTTPS site. If the first shows an interception and the second fails, the sign-in is incomplete and the VPN has nothing to do with it.

On a personal device, the kill switch or always-on VPN may need to be turned off through the client's supported control so the portal can load. Close sensitive applications during that window and turn the protection back on immediately afterwards. On a managed device, use the procedure the administrator approved rather than removing a policy yourself.

Never bypass a certificate warning or install an unknown certificate or helper application to get online. If the portal demands something unexpected, confirm it with staff, and with the administrator if the device belongs to an employer.

Keep the original profile and its error

Once ordinary access works, connect the original profile and record the exact error. An authentication rejection is an account problem, a timeout during negotiation is a path problem, and a tunnel that establishes but carries nothing is a routing or policy problem.

Those three need different next steps, and a screenshot of the error is worth more than a description. Note the time as well, because hotel session limits can expire within an hour and produce a failure that appears random. If the client offers a log, keep the section around the first failure rather than the whole file. That excerpt is usually enough for whoever owns the profile to identify the stage.

If ordinary access works and negotiation still times out, ask the hotel whether it supports the traffic, and compare against a trusted hotspot with the device and profile held constant. Working on the hotspot narrows attention to the hotel path without proving anything about the profile.

Use only alternatives the operator supplies

A matching TCP profile may succeed where the offered UDP path does not, but only if the server actually listens on that transport and port. TCP port 443 is not automatically treated as ordinary HTTPS, and it is not a guarantee of passage through a restrictive network.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Running the supplied profile with a higher verbosity keeps the first useful error visible instead of collapsing it into a generic failure dialog. Use the file the operator provided rather than editing ports or protocols yourself, because a local change cannot create a matching listener on the far side.

If the tunnel resets repeatedly, note whether the portal reappears or the local signal drops, and follow the stability checks rather than switching several protocols at once. Then test the application you actually need and restore the normal privacy controls. A connection that carries one site but not another is a routing or policy question, not a portal question.

Finally, check recovery after the laptop sleeps. Portal authorization can expire independently of the tunnel, so a device that reconnects automatically may come back to a network that has already forgotten it. Reopening the portal page is a normal step, not a sign that the VPN is broken.