A completed handshake and no traffic is one of the most misleading states in networking, because it looks like a failure while proving that a great deal already works. Understanding what the handshake certifies is what turns this from guesswork into a two-minute diagnosis.
What the handshake already proved
WireGuard's handshake succeeds only if your keys match, the endpoint is reachable, and UDP passes between you and the server. That is a large slice of everything that can go wrong, and it is now ruled out.
So: stop re-generating keys. Stop changing ports. The tunnel is up. What is broken is what happens to packets after they enter it.
A VPN changes your IP. It does not change your browser.
A tunnel replaces the address a service sees. It changes nothing about what your browser announces on its own - fonts, screen, time zone, graphics stack - and that combination is often stable enough to recognise you across sessions, tunnel or no tunnel.
Measure your own browser fingerprint - passive, no questions, no account, no email.
The four commands that locate the fault
Run these in order. Each one rules out everything above it.
| # | Command | If it fails, the cause is |
|---|---|---|
| 1 | ping 10.0.0.1 (server's tunnel IP) | AllowedIPs, traffic is not entering the tunnel |
| 2 | ping 1.1.1.1 | Forwarding or NAT on the server |
| 3 | ping example.com | DNS |
| 4 | Load a real web page | MTU |
1. AllowedIPs, the client never sent the traffic
AllowedIPs on the client is not a permission list. It is a routing table: it tells WireGuard which destinations to send into the tunnel. Set it to 10.0.0.0/24 and only tunnel-internal addresses go through; everything else takes your normal connection, which is why the internet appears untouched by the VPN.
For a full tunnel, the client peer needs AllowedIPs = 0.0.0.0/0, ::/0.
2. Forwarding and NAT, the server received it and dropped it
Two separate settings on the server, and missing either produces the same silence.
IP forwarding must be enabled, or the kernel refuses to pass packets between interfaces. It also resets on reboot unless written into the sysctl configuration, which is why this failure often appears weeks after a working setup, right after a restart.
Masquerading rewrites the source address of packets leaving the server. Without it, your traffic reaches its destination carrying a private tunnel address, and the reply has nowhere to go. Nothing errors; packets simply never come back.
3. DNS, names fail, numbers work
If ping 1.1.1.1 succeeds and ping example.com does not, the tunnel carries traffic and cannot resolve names. Either there is no DNS line in the client config, or it points at a resolver only reachable outside the tunnel.
One trap worth knowing on Linux: the DNS directive requires resolvconf or systemd-resolved to be installed. Without it, the line is silently ignored, indistinguishable from a resolver that is not answering.
4. MTU, the one most guides skip
This is the signature everyone misdiagnoses: ping works, small pages load, then transfers freeze.
Encapsulation adds overhead, so the usable payload inside the tunnel is smaller than on the raw link. When a packet is too large to pass and the ICMP message that would say so is blocked, which is common, the packet is dropped in silence. Small packets sail through, large ones vanish. The connection opens, then hangs.
Set MTU = 1420 on the interface. If it persists, try 1280, the IPv6 minimum, which almost any path will carry.
The order matters more than the list
Every one of these has been written about individually, and that is precisely why the problem takes people hours: five plausible causes, no way to tell them apart, so they try fixes at random and change three things at once.
The four pings above cost about a minute and eliminate roughly one cause each. Run them before touching a configuration file, and change one thing at a time afterwards, so you learn which one it was.
Get NordVPN at its best price
2-year plan · audited no-logs (PwC) · 30-day money-back
