MTU and VPNs: why pages hang at 90 percent
A tunnel adds headers, so the largest packet that fits inside it is smaller than the 1500 bytes a normal link carries. When a router drops the ICMP message that would report the correct size, oversized packets vanish silently: small requests work and large transfers stall.
4 min read
MTU is the maximum transmission unit: the largest packet a link will carry. Ethernet is 1500 bytes, and almost everything assumes that number. A tunnel wraps your packet in another packet, so the payload available inside it is smaller — and if nothing tells the sender, the difference is where traffic goes to die.
The arithmetic
WireGuard's overhead is 60 bytes over IPv4: 20 for the outer IP header, 8 for UDP, and 32 for WireGuard's own. So 1500 minus 60 is 1440 — but the conventional default is 1420, which leaves margin for IPv6 outer headers and for links that are already slightly reduced.
| Underlying link | Link MTU | Sensible tunnel MTU |
|---|---|---|
| Ethernet or Wi-Fi | 1500 | 1420 |
| PPPoE broadband | 1492 | 1412 |
| Mobile data | varies | 1380 |
| Anything unusual | unknown | 1280 |
1280 is the floor worth trying, because RFC 8200 requires every IPv6 path to carry at least that. Nothing should ever need less.
Why it fails silently
The internet has a mechanism for this. A router that cannot forward a packet because it is too large, and which is told not to fragment it, replies with an ICMP "fragmentation needed" message carrying the correct size. The sender learns and sends smaller packets. That is Path MTU Discovery, defined in RFC 1191.
It depends on ICMP being delivered. A great many networks block ICMP wholesale, usually because someone once read that ICMP is a security risk and blocked all of it rather than the parts that are.
When that message is dropped, the sender learns nothing. It keeps sending oversized packets, they keep being discarded, and nothing reports an error. RFC 2923 documents this as a known failure mode; the informal name is a path MTU black hole.
The symptom
This is the most recognisable signature in network troubleshooting once you know it:
pingworks.- Small pages load instantly.
- A page with images hangs partway.
- SSH connects and freezes the moment output exceeds a screen.
- File transfers stall at a percentage and never resume.
Small packets fit. Large ones do not. Anything that needs a large packet disappears.
Finding the right number
Ping with a fixed payload size and the don't-fragment flag, and walk it down until it succeeds:
# macOS and Linux
ping -D -s 1472 1.1.1.1
# Windows
ping -f -l 1472 1.1.1.1
1472 plus 28 bytes of headers is 1500. When the largest size that succeeds is found, add 28 for the real MTU of the path, then subtract the tunnel overhead for the tunnel MTU.
In practice, setting 1380 and moving on is a reasonable shortcut for anyone not chasing the last few percent of throughput.
Where to set it
WireGuard config:
[Interface]
MTU = 1412
Client apps usually expose it in advanced settings, sometimes as an automatic option that should be overridden when it is wrong.
Routers need it in two places: the tunnel interface, and often a TCP MSS clamping rule, which rewrites the maximum segment size in TCP handshakes so both ends agree on something that fits. OpenWrt does this automatically for tunnels; the router guide covers where it lives.
MSS clamping, and why it is not the same thing
MTU applies to all IP traffic. MSS clamping applies only to TCP, and works by editing the value each end advertises during the handshake so neither ever sends an oversized segment.
It is more robust than relying on Path MTU Discovery because it does not depend on ICMP surviving. It does nothing for UDP, which is why both are usually configured together on a router.
Too small is also wrong
Setting 1280 everywhere and forgetting about it costs throughput. Every packet carries the same header overhead regardless of payload, so smaller packets mean proportionally more overhead and more packets per second to move the same data.
The difference between 1420 and 1280 is around ten percent of throughput on a fast connection. Worth finding the real number if you are measuring with the speed test and care about the result.
When it is not MTU
If small requests also fail, or if nothing works at all, this is not an MTU problem. MTU failures are specifically partial: the small things work. That selectivity is the diagnostic.
