RoamGauge › Guides

Which port to use when your VPN is blocked

Restrictive networks rarely block VPNs as such. They allow a short list of ports and drop everything else, and the VPN defaults happen to sit outside that list. Move the tunnel onto a port the network already has to allow and it usually walks straight out.

The ports, and how likely each is to get out

The pattern is simple: the ports that get out are the ones the network cannot block without breaking something its guests will complain about.

WireGuard

WireGuard runs on any UDP port. The default of 51820 is a convention, not a requirement — but both ends must agree, so this only helps if you run the server or your provider publishes alternate endpoints.

On the server, in wg0.conf:

[Interface]
ListenPort = 443

On the client, the endpoint must name the same port:

[Peer]
Endpoint = vpn.example.com:443

Restart the interface at both ends (wg-quick down wg0 && wg-quick up wg0) and open the new port in the server's firewall — forgetting that step is the usual reason this appears not to work.

Good candidates, in order: 443, then 53, then 123 (NTP, almost always open and rarely inspected). If you run the server yourself, there is no reason not to listen on several at once.

OpenVPN

OpenVPN's advantage here is that it speaks TCP as well as UDP, and OpenVPN over TCP 443 is the single most reliable way out of a restrictive network. On the wire it is a TLS session to port 443, which is what the network expects to see all day.

In the client config:

proto tcp
remote vpn.example.com 443

Most commercial providers ship a separate "TCP" config file rather than asking you to edit anything — look for it before hand-editing.

IKEv2 / IPsec

IKEv2 is not really port-flexible: it needs UDP 500 for the key exchange and UDP 4500 for NAT traversal, and both have to get through. Behind almost any hotel NAT it will move to 4500 immediately.

There is little to tune here, which is the honest downside of an otherwise excellent protocol — it is the fastest to reconnect when you move between networks, and the least adaptable when a firewall dislikes it. If 500 and 4500 are blocked, switch protocol rather than port.

When changing the port will not help

If the network is doing deep packet inspection, it is recognising the shape of the handshake, not the port number. A WireGuard handshake initiation has a distinctive fixed-size first packet; an OpenVPN reset is equally recognisable. Move either to 443 and a DPI firewall drops it just the same.

The tell is that every port fails identically while ordinary HTTPS to the same host works. The answer is obfuscation — your provider's Stealth, Obfuscated, Camouflage or Scramble mode, which wraps the tunnel so it reads as ordinary TLS. It costs some throughput and it is the only thing that works against inspection.

Test rather than guess

Working through this list by hand means reconfiguring a client, waiting for a timeout, and reconfiguring again — several minutes per attempt, with no way to tell a blocked port from a slow one, since a dropped UDP packet and a delayed one look identical from the client.

RoamGauge sweeps the alternate ports for you. It sends a real WireGuard handshake initiation to 443, 53, 123, 500, 4500 and 1194 in one pass and reports which ones answered — an actual protocol exchange, not a port scan, so a green result means the tunnel would genuinely establish. It does the same for OpenVPN, IKEv2 and Tailscale, and it never establishes a tunnel of its own.