Troubleshooting
WireGuard logs almost nothing, by design: it doesn't answer, or even acknowledge, packets it can't authenticate. So troubleshooting is mostly reading wg show on both ends, and following packets with tcpdump.
The key test: is there a handshake?
wg show on the client tells you most of what you need. No latest handshake line, and 0 B received means the two ends have never agreed on keys. In the lab, carol's file had the wrong public key for the server: she sent packets, got nothing back, and the server recorded nothing at all about her attempts.
What wg show says | Likely cause | Check |
|---|---|---|
| No handshake, 0 B received | Wrong server public key on the client, client's key not on the server, or UDP 51820 blocked | Compare keys carefully; tcpdump udp port 51820 on the server |
| Handshake recent, but traffic fails | Routing or firewall: missing return route, missing AllowedIPs, forward rules | ip route, the firewall counters, tcpdump -i wg0 |
| The server's tunnel address answers, nothing beyond it does | IP forwarding off, or no forward rule | sysctl net.ipv4.ip_forward; the forward chain's drop counter |
Packets from a user never appear on wg0 | Their source address isn't in their AllowedIPs on the server | Compare the user's addresses with their [Peer] |
| Every user stopped at once | Server's private key missing (wg show wg0 private-key says (none)) | wg set wg0 private-key …; see Managing users |
| Works, then stops after a few minutes idle | NAT mapping expired | PersistentKeepalive = 25 on the client |
| Small requests work, big transfers hang | MTU: packets too big for the path | Lower MTU in [Interface], e.g. 1380 or 1280 |
MTU
WireGuard's interface defaults to an MTU of 1420: the usual 1500 minus the outer IP, UDP and WireGuard headers (80 bytes with an IPv6 outer header; IPv4 needs only 60, but 1420 suits both). In the lab, a 1392-byte ping (1420 with its headers) gets through with don't-fragment set; 1393 doesn't even leave alice's computer. If the path to the server has a smaller MTU, such as PPPoE at 1492 or another tunnel, set MTU = lower in [Interface] on both ends.
root@carol:~# grep PublicKey /etc/wireguard/wrongkey.conf && wg-quick up wrongkey >/dev/null 2>&1 && ping -c 3 -W 1 10.10.0.20 | tail -2; sleep 3; wg show
PublicKey = sh5Ul4rjT56yt7ZYYVSrpJvxEIqKFx/HxkeICJIgGws=
3 packets transmitted, 0 received, 100% packet loss, time 2061ms
interface: wrongkey
public key: P+TMulXP07Ldwcf65Rx1CvXDOxK57C3HWV5aY5oDHEo=
private key: (hidden)
listening port: 35674
peer: sh5Ul4rjT56yt7ZYYVSrpJvxEIqKFx/HxkeICJIgGws=
endpoint: 203.0.113.10:51820
allowed ips: 10.9.0.0/24, 10.10.0.0/24, 10.20.0.0/24
transfer: 0 B received, 296 B sent
persistent keepalive: every 25 seconds
root@vpn:~# wg show | sed -n "/P+TMul/,/^$/p"
peer: P+TMulXP07Ldwcf65Rx1CvXDOxK57C3HWV5aY5oDHEo=
endpoint: 198.51.100.24:53092
allowed ips: 10.9.0.12/32
latest handshake: 42 seconds ago
transfer: 980 B received, 860 B sent- Line 2: The wrong
PublicKey: it's the branch router's key, not the server's. - Lines 5–14: Packets sent, nothing received, and no latest handshake line at all.
- Lines 17–21: The server knows carol, but only from her earlier, working tunnel: the handshake time and byte counts are from that. The bad attempts left no trace.
root@alice:~# ip link show wg0 | head -1; ping -c 1 -W 1 -M do -s 1392 10.10.0.20 | grep -E "bytes from|transmitted"; ping -c 1 -W 1 -M do -s 1393 10.10.0.20 2>&1 | head -2
13: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
1400 bytes from 10.10.0.20: icmp_seq=1 ttl=62 time=0.272 ms
1 packets transmitted, 1 received, 0% packet loss, time 0ms
PING 10.10.0.20 (10.10.0.20) 1393(1421) bytes of data.
ping: sendmsg: Message too long- Line 2: The default 1420.
- Lines 3–4: 1392 bytes of data + 28 bytes of ICMP and IP = 1420: fits.
- Lines 5–6: One byte more, with don't-fragment set: the kernel refuses to send it.
Check your understanding
alice's wg show has no latest handshake and 0 B received. Which of these is NOT a likely cause?
- A missing return route on the office router.
- The wrong server public key in her config.
- Her public key isn't on the server.
- UDP 51820 is blocked on the way.