Hotel wifi blocking WireGuard

Hotel wifi blocking WireGuard is one of the most common travel failures, and it almost never announces itself. The tunnel does not error. It simply never completes a handshake, wg show reports no latest handshake, and every application times out. The behaviour looks identical whether the network is dropping your packets, dropping all UDP, or dropping only the first packet of the exchange.

Those three cases have three different remedies. Work out which one you are in before you start changing ports, because two of them cannot be fixed by a port change at all.

Guest networks are built to be cheap, predictable and defensible. Blocking whole categories of traffic is the easiest way to get there, and WireGuard is caught by several of those rules at once.

• WireGuard is UDP-only, and many guest networks permit only TCP outbound
• Uncommon destination ports are dropped by default, and UDP 51820 is uncommon
• Deep packet inspection can classify a flow by shape rather than by port
• Some captive portals drop everything until a browser session authenticates

The protocol constraint is not a configuration choice you can undo. WireGuard's own protocol documentation states it directly: "All packets are sent over UDP" (wireguard.com/protocol). There is no TCP mode to fall back to, so a network that drops UDP wholesale ends the conversation.

Run this ladder in order. Each rung costs less than the one after it.

Port blocked

The cheapest case, and the only one a port change fixes. The network drops traffic to unusual destination ports and passes traffic to familiar ones.

Change the Endpoint port in your config to a port the network is likely to permit. Bring the tunnel up again. If a different port completes the handshake, you were port blocked and you are done. If nothing changes across several ports, stop and move to the next rung. The Arch Linux BBS poster who reported this problem had already tried ports 500, 1194, 1500, 4500, 51820 and 51888 before asking (bbs.archlinux.org, thread 281038). That is a reasonable definition of enough.

Note that this only works if the server is actually listening on the port you choose. Changing Endpoint on the client does nothing unless the other end answers there. See changing the WireGuard endpoint port for what is adjustable on the client side.

Protocol blocked

The network drops UDP regardless of destination port. No port change helps, because the filter is not looking at the port.

Test it with something ordinary. Confirm that plain browsing works, then confirm that a UDP-based service works. If TCP traffic flows and UDP does not, the protocol is the filter and WireGuard has no answer. Switch protocol rather than continuing to guess ports.

Handshake blocked

The non-obvious case, and the one nobody writes up. The network permits established flows but drops the packet that starts a new one.

The poster on Arch Linux BBS 281038 worked this out himself and posted the result: "turns out that the network wasn't blocking connections, but was blocking the initial handshake. This strategy works to prevent new connections but it does nothing to stop an existing connection. Therefore, connect to the WG peer before joining such a network to enjoy the encrypted tunnel."

There is a reason this case is hard to see from the client. A WireGuard peer never answers an unauthenticated packet, by design. The protocol documentation describes the server as one that "does not even respond at all to an unauthorized client; it is silent and invisible". Silence from a filtered handshake and silence from a healthy server are the same silence, so the client log cannot tell you which one you have.

Which test tells you which case

Read wg show before you change anything. It prints the peer, the endpoint it is using, the transfer counters and the time of the latest handshake. Those four values separate most of the cases on their own.

The latest handshake value is the one to watch. WireGuard rekeys periodically, so a handshake timestamp that stops advancing while the tunnel appears up means new handshakes are failing even though old state is still present. That is the same filtered-handshake case, observed from the other direction.

Send a small amount of traffic before you conclude anything. The counters only move when packets flow, and an idle tunnel with a stale handshake looks identical to a broken one.

Two suggestions came from the same thread and both are worth trying in order. User -thc wrote: "Hotel WiFis most likely allow only https and mail protocols. You can try UDP port 443 - but chances are slim for this simple trick to work. Some public WiFis allow UDP port 53." User Slithery suggested: "Try 53 as that's usually used for DNS?"

Reproduce that honestly. The person suggesting UDP 443 rated its chance as slim.

The last row is the whole point of the table. The one port almost certain to be open is the one WireGuard structurally cannot use.

Check with your provider which UDP ports its servers accept before you edit the Endpoint line. A port the server is not listening on fails in exactly the same silence as a port the network is blocking, so guessing here costs you the one signal you have.

A captive portal blocks everything until a browser session authenticates against the network's own login page. An active kill switch blocks that login page too. The result is a device that cannot get online and cannot reach the thing that would let it get online.

Order the steps deliberately. Join the network with the tunnel down, complete the portal login in a browser, then bring the tunnel up immediately afterwards. Keep the unprotected window as short as you can, and do nothing sensitive inside it. Firewall rules that deny outbound traffic by default need relaxing for the portal and reapplying after. See kill switch setup for the rules involved.

This ordering conflicts with the handshake workaround described below, and the conflict is real rather than theoretical. A tunnel established before you join cannot survive a portal that drops all traffic until you authenticate.

The version that catches people out is the second login rather than the first. Many hotel portals expire a session after a fixed period or at checkout time, and some expire it whenever the device roams to a different access point. When that happens the network starts intercepting again while your tunnel is still up and still believes it is connected. Nothing errors. Traffic simply stops, exactly as it would if the network had begun filtering WireGuard.

Recognise it by the shape rather than by a message. A tunnel that worked for hours and then stopped, on a network that never blocked it before, is far more likely to be an expired portal session than a new filter. Confirm it by dropping the tunnel and opening any plain HTTP address, since the portal can only intercept traffic it can read. A login page means the session expired. No login page means the portal is not involved and the ladder above applies.

Stop after the second failed port. If UDP 443 and UDP 53 both fail, the evidence points at UDP itself or at inspection, and further ports are guesswork with a low prior.

At that point the remedy is a different protocol rather than a different port. OpenVPN can run over TCP, which means it can use the one port that restrictive networks reliably permit. OpenVPN's own documentation sets out the same hierarchy: Access Server "works best over UDP", and "TCP 443 is the preferred fallback option when firewalls block UDP" (blog.openvpn.net/vpn-server-behind-firewall). The full procedure, including what it costs in throughput and where it stops working, is in using OpenVPN on TCP 443 to bypass a firewall.

This is where the choice of provider becomes a technical constraint rather than a preference. A provider that ships only WireGuard configs leaves you with no second option on this network, because there is no .ovpn profile to import. PulseVPN issues both WireGuard and OpenVPN config files on the same account, and both protocols work at the same time.

Know which file to reach for before you need it. Each PulseVPN OpenVPN download is a ZIP holding two profiles for that server, one on UDP and one on TCP. Both connect on port 80. The TCP profile in that ZIP is the one to import here, because port 80 carries plain HTTP and a guest network that closes it breaks its own portal. Note that PulseVPN ships no profile on port 443, so the file you want is the TCP one on 80. See using an OpenVPN profile for the import path.

If the diagnosis landed on a blocked handshake, this is the workaround, and it is the poster's own. It exploits the gap between blocking new connections and blocking established ones.

1. Bring the tunnel up somewhere the handshake completes, such as a phone hotspot or cellular data.
2. Confirm with wg show that a latest handshake exists and that the transfer counters are moving.
3. Join the hotel network without taking the tunnel down.
4. Check that traffic still passes before assuming it worked.

Keep PersistentKeepalive in mind here. The wg(8) manual defines it as an interval for sending "an authenticated empty packet to the peer" (wg.8). Its stated purpose is "keeping a stateful firewall or NAT mapping valid persistently". The recommended value behind NAT is 25 seconds. A tunnel that goes quiet on a hostile network may not come back without a new handshake, and a new handshake is exactly the thing being blocked.

Prepare for this before you travel rather than in a hotel lobby. Download a second profile in another region, download the OpenVPN fallback, and confirm both work on a network you control. That is the argument made in the travel VPN checklist, and this failure is the reason it exists. For symptoms that persist on a network you know is permissive, start instead with connection troubleshooting.