RoamGauge › Guides

Hotel Wi-Fi is blocking your VPN. Here is how to tell why.

"The hotel blocks VPNs" is usually wrong. Four quite different things get blamed on the same sentence, and each one has a different fix. Working out which one you are actually hitting takes about two minutes and saves you from trying fixes that were never going to work.

First, rule out the boring one

Before anything else: have you finished the sign-in page?

A captive portal — the hotel's "enter your room number" page — intercepts web traffic and drops everything else on the floor. Your phone says it is connected to Wi-Fi because it is; it just has no route to the internet until the portal lets you through. A VPN started before you sign in will fail every time, and it will fail in a way that looks exactly like deliberate blocking.

The complication is that a VPN app which auto-connects on join can stop the portal from ever appearing. The portal needs to intercept a plain web request, and your VPN is trying to tunnel before that can happen. So:

1. Turn the VPN off.
2. Open http://neverssl.com in a browser — plain http://, not https, so the portal can intercept it.
3. Complete the sign-in.
4. Now turn the VPN on.

The four real causes

Once you are genuinely online and the VPN still will not come up, it is one of these. They are listed in the order you are likely to hit them.

1. UDP is blocked or throttled

This is the most common by a wide margin, and it is rarely deliberate. Plenty of guest networks are configured to pass TCP on ports 80 and 443 and very little else, because that is all a web browser needs. WireGuard is UDP-only. OpenVPN defaults to UDP. Both die quietly.

The tell: web pages load perfectly, video streams fine, and the VPN sits at "connecting" until it times out. No error, just silence — because a blocked UDP packet produces no response to distinguish it from a slow one.

2. The specific port is filtered

Narrower than the above. UDP works — DNS resolves, video calls connect — but the port your VPN uses does not. WireGuard's default 51820 and OpenVPN's default 1194 are recognisable and are sometimes filtered by name in commercial firewall rulesets, while general UDP passes.

3. DNS is being intercepted

Many guest networks transparently redirect all port 53 traffic to their own resolver, whatever you have configured. If your VPN endpoint is a hostname rather than an IP address, and the network's resolver returns nothing or returns the wrong answer for it, the client never gets as far as a handshake.

The tell: the VPN fails with a "could not resolve host" style error rather than a timeout. If it connects when you replace the hostname with the raw IP address, this was it.

4. Deep packet inspection

Rarest on hotel Wi-Fi, common on corporate guest networks, school networks and in a handful of countries. The firewall recognises the shape of a VPN handshake and drops it regardless of the port. Moving to 443 does not help, because the inspection is not looking at the port number.

The tell: the connection fails identically on every port you try, including 443, while ordinary HTTPS to the same host works.

The fixes, in the order worth trying

1. Switch to TCP 443. If your provider offers OpenVPN over TCP 443, this is the single highest-percentage move. Port 443 is HTTPS; a network that blocks it has blocked the web. It is slower than UDP and it has a real failure mode under packet loss (see below), but it gets out of almost everything.
2. Move WireGuard to 443 or 53. WireGuard will happily run on any UDP port — but both ends have to agree, so this only works if you control the server or your provider publishes alternate ports. Which port to pick, and how to change it.
3. Turn on obfuscation. Most commercial providers ship this under a name like Stealth, Obfuscated Servers, Camouflage or Scramble. It wraps the tunnel to look like ordinary TLS. This is the answer to cause 4 and it is the only thing that is.
4. Use the endpoint's IP address instead of its hostname. Sidesteps cause 3 entirely.
5. Tether to your phone. Not a defeat. If the call starts in six minutes, cellular is the right answer and the time is better spent on the call than the firewall.

What will not help

• Changing your DNS servers. Setting 1.1.1.1 or 8.8.8.8 does nothing against a network that transparently redirects port 53 — your queries still land on their resolver. It also does nothing at all against causes 1, 2 and 4.
• Rebooting, forgetting the network, toggling airplane mode. These fix association problems, not filtering.
• A different VPN app on the same protocol and port. If UDP 51820 is blocked, it is blocked for everyone using it.
• Asking the front desk. Worth one try at a business hotel with real IT. At most properties the network is a managed service and nobody on site can change a firewall rule.

Stop guessing at it

Every fix above is conditional on knowing which cause you have, and the honest problem is that a phone gives you almost nothing to tell them apart. A failed VPN connection looks the same whether the port is filtered, the portal is unfinished, or DNS is lying to you.

That is the gap RoamGauge was built for. It sends a real WireGuard handshake, a real OpenVPN reset and a real IKEv2 initiation from your phone — not a port scan, an actual protocol exchange — and tells you which of the four you are looking at, then what to do about it. It never tunnels your traffic and it is not a VPN.