Account for encapsulation and MTU

Every tunnel adds outer headers. So the wrapped packet is larger than the original. That small piece of arithmetic produces some of the strangest bugs you will ever debug.

A network interface has a Maximum Transmission Unit, or MTU: the largest packet it agrees to carry. Ethernet links commonly use 1500 bytes. WireGuard’s outer headers take about 60 of those bytes on IPv4, so the tunnel interface must advertise a smaller MTU. wg-quick does this for you, and that is why you typically see 1420:

ip link show wg0
# 4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue ...

Now the problem. If a protected packet is too large for some link on the path, that link must either fragment it or tell the sender to use a smaller size. Modern senders set the Don’t Fragment flag and rely on an ICMP “packet too big” message coming back. That mechanism is Path MTU Discovery. Firewalls that silently drop ICMP break it.

Broken Path MTU Discovery has a signature. Small requests work while larger transfers stall. The login page loads, the file download hangs at zero. Ping succeeds, HTTPS to the same host freezes halfway through the response. Nothing errors. Packets just vanish.

You can probe packet sizes on purpose. The -M do flag forbids fragmentation, so a failure shows you exactly where the limit sits:

ping -c 1 -M do -s 1392 10.14.0.1
# 1392 data bytes + 28 header bytes = 1420: fits, replies arrive

ping -c 1 -M do -s 1400 10.14.0.1
# ping: local error: message too long, mtu=1420

The first ping fits the interface MTU exactly. The second is 8 bytes too big, and the kernel refuses to send it. That second error is local and expected. The interesting failures are the ones that happen further away.

If sizes fail well below the interface MTU, some link on the path is smaller than everyone assumed. A PPPoE connection at 1492 is a classic cause. Try -s 1350 and work up until pings stop returning.

Don’t guess first. Compare working and failing packet sizes, inspect the interface MTU, and change it only with evidence. When the evidence points to a smaller path, set MTU = 1380 in the [Interface] section, restart the interface, and test again.

The mistake to avoid is the reflex fix: lowering MTU to some tiny value at the first sign of trouble. It often hides the symptom, costs throughput on every packet, and leaves the real cause in place. That cause is usually an ICMP-dropping firewall, and it will keep breaking other things until someone fixes it.