WireGuard's networking is refreshingly simple — but the one number that trips people up is the port. By default WireGuard listens on UDP 51820, and almost every "my self-hosted VPN won't connect" problem comes down to that port not being open, not being forwarded, or not matching the client config. This guide covers the default, how to change it, and how to open and forward it correctly.
The default: UDP 51820
WireGuard listens on UDP port 51820 by convention, set by the ListenPort line in the server's [Interface] section. Two things matter here:
- It's UDP, not TCP. WireGuard has no TCP mode at all. Firewalls or networks that block UDP will stop it cold.
- 51820 is just the default, not a rule — you can use any free UDP port from 1 to 65535.
Clients reach the server using the Endpoint = <public-ip>:51820 line in their own config. That port has to match the server's ListenPort exactly.

Opening the port in the firewall
On the server, the port must be allowed for UDP. With UFW:
sudo ufw allow 51820/udp
sudo ufw reload
With iptables it's -A INPUT -p udp --dport 51820 -j ACCEPT. This is the single most common cause of a server that "runs" but never accepts connections: the WireGuard service is up, but the firewall silently drops the packets.
Forwarding the port through a router
Where your server lives decides whether you also need port forwarding:
- On a VPS (a rented server with a public IP): no forwarding needed — the firewall rule is enough, because the public IP points straight at the machine.
- On a home server behind a router: add a port-forward rule in the router admin — forward UDP 51820 (external) to the server's local IP on UDP 51820 (internal). Without it, packets from the internet never reach the server.
Test from outside your network (e.g. a phone on mobile data, Wi-Fi off): a client should reach server-public-ip:51820. If it works on your LAN but not from outside, forwarding is the missing piece.
Changing the port
To use a different port, set it in the server's [Interface]:
[Interface]
ListenPort = 51821
Then restart the tunnel (systemctl restart wg-quick@wg0) and update everything that referenced the old port:
- the firewall rule (allow the new UDP port),
- the router forward (if applicable),
- the
Endpointline in every client config.
Miss any one and clients won't connect. A self-hosted VPS makes all of this straightforward because you control the firewall and the public IP directly.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed
A VPS with a public IP — no router forwarding needed → ContaboPublic IPv4 · You control the firewall and port · Host WireGuard reachably from anywhere→Does changing the port hide your VPN?
A non-default port reduces noise from bots that scan 51820, but it is not stealth. Deep packet inspection fingerprints WireGuard's distinctive UDP handshake regardless of the port number. If you need to get through a firewall that actively blocks or detects VPNs, you need obfuscation (wrapping the tunnel), not just a different port — see WireGuard with port knocking / stealth. For routing specific traffic or forwarding services through the tunnel, see port forwarding.
The bottom line
WireGuard uses UDP 51820 by default — UDP only, no TCP. To make a self-hosted server reachable: open the port for UDP in the firewall, forward it on the router if the server is behind one (a VPS with a public IP skips that), and make sure every client's Endpoint matches. Change the port if you like for less scan noise, but treat it as light hardening, not real stealth.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed
Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→