Path MTU discovery through a VPN: sizing and the ICMP gap

A tunnel completes its handshake, small requests come back, and the first large transfer stalls. That pattern points at path MTU long before it points at throughput. Every link along the route caps the packet size, and encapsulation spends part of that allowance on outer headers, so the inner packet must be smaller than the raw path would suggest. The failure is silent, which is what makes it expensive to diagnose.

What path MTU actually measures

Path MTU is the smallest link MTU on the route between two hosts, not the MTU printed on your local interface. The local value is where the estimate starts, and the path decides where it must end. This is why an identical tunnel can work on one access network and stall on another: the route changed, not the configuration. Measuring once and assuming everywhere is the mistake that keeps this problem alive.

For a tunnel, the number that matters is the inner MTU, which is the outer path's allowance minus whatever the encapsulation consumes. WireGuard adds an outer IP header and a UDP header; other transports add their own. Set the inner size too high and each full-size packet needs fragmentation that may never happen.

Why a tunnel shrinks the usable packet

If the tunnel interface keeps the physical link's MTU, every large packet depends on someone downstream being willing to fragment it. IPv4 allows that in principle, but a router told not to fragment returns an error instead. IPv6 routers never fragment in transit at all, so the same setting behaves differently by address family. Either way the sender learns nothing until something reports back.

The practical consequence is a size that fits the handshake and not the payload. A TLS ClientHello or a DNS query is small enough to cross a shrunken path untouched, while a bulk transfer is not. Symptoms therefore cluster around specific operations rather than specific hosts.

Discovery only works when the feedback arrives

IPv4 discovery relies on the don't-fragment bit: a router that cannot forward the packet returns ICMP fragmentation-needed with the next-hop MTU, and the sender lowers its estimate. IPv6 uses Packet Too Big messages instead, because routers do not fragment in transit. Both mechanisms assume the message finds its way back to the sender, through the tunnel and past any firewall on the return path. When that assumption fails, the sender keeps retrying a size the path cannot carry.

A firewall that permits echo request and echo reply has not necessarily permitted those error types. ICMP is a family, and the members that matter here are the errors, not the echo pair. Check the control-traffic policy at both tunnel ends and on the path between them, and follow the platform's supported guidance instead of permitting every ICMP type everywhere.

The same filtering can sit inside the tunnel. If the inner path drops the error but the outer path carries it, the sender may adapt to a limit the encapsulated traffic never actually sees.

Probe the path instead of guessing a number

Keep the destination, the access network and the tunnel fixed, then vary only the packet size. A don't-fragment probe that fails with an MTU hint gives you the next-hop limit; repeat until a size passes, and record both the size and the address family.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

A ping that fits does not prove a real application's full-size segments fit, so repeat the test with the transfer that actually failed. Compare the largest working probe against the tunnel MTU you configured, and keep the two numbers separate in your notes. If they differ by roughly a header's worth, you have found the encapsulation overhead rather than a fault.

PLPMTUD, described in RFC 4821, probes upward and uses transport acknowledgements instead of trusting delivered errors. It helps on paths that filter ICMP, but support varies by stack and by application. A TCP flow may recover on its own while a UDP application with a fixed datagram size keeps failing.

Choose a value and record the reasoning

Lowering the tunnel MTU is both a diagnostic and a legitimate fix once you know the path. It is not a substitute for knowing which path and which feedback mechanism were involved, because a value tuned for a mobile link will be needlessly small on a fibre connection. Record the chosen size, the probe that justified it and the rollback step.

The IPv4 mechanism is described in RFC 1191 and the IPv6 packetization guidance in RFC 8201; naming both keeps the next engineer from re-deriving the assumption. If the transfer still stalls at the size you chose, stop lowering the number and look at the next layer. A path that fails at every size is not an MTU problem.