MTU / Path MTU Calculator

Every VPN, tunnel or encapsulation protocol you stack on top of a link eats into the usable payload size, and the fallout — silent packet drops, TCP connections that hang on large transfers but work fine on small ones — is one of the more annoying things to diagnose because it doesn't look like a network problem at first glance. This works out the effective MTU after overhead, and the TCP MSS that follows from it.

Why this bites people specifically on VPNs

The classic symptom: SSH works, small HTTP requests work, but a large file transfer or a big webpage hangs partway through. That's Path MTU Discovery failing — a router along the path needs to fragment a packet that's too big for the next hop, can't (because the Don't Fragment bit is set, which it usually is for TCP), and is supposed to send back an ICMP "too big" message so the sender adjusts. When that ICMP message gets blocked by a firewall somewhere — which happens constantly — the sender never finds out, and the connection just stalls on anything past a certain size.

Why VPN overhead is never just "20 bytes for IP"

Every layer you add costs bytes: WireGuard's overhead (roughly 60 bytes over IPv4) comes from its outer UDP/IP header plus its own protocol header. IPsec in tunnel mode is worse — a new outer IP header, an ESP header, HMAC authentication data, and cipher-specific padding, easily landing at 50–73 bytes depending on the algorithms in play. GRE is comparatively cheap at 24 bytes since it's just a wrapper. Stack two of these — GRE inside IPsec, say — and the overheads add, which is exactly the kind of thing that gets missed when someone copies a "set MTU to 1400" recommendation from a forum post without knowing why that number was right for their specific stack and possibly wrong for yours.

The 1280 floor

IPv6 has a hard minimum MTU of 1280 bytes, unlike IPv4 which technically allows smaller. If your effective MTU after overhead drops below that, IPv6 traffic across the path is at real risk of breaking outright rather than just running a bit slower — worth checking specifically if you're running dual-stack over a heavily encapsulated tunnel.

Setting it correctly once you know the number

Once you've got the effective MTU, set it explicitly on the tunnel interface rather than trusting Path MTU Discovery to sort it out — PMTUD depends on ICMP getting through cleanly end to end, and in practice it often doesn't. For TCP specifically, clamping the MSS at the tunnel endpoint (`iptables --clamp-mss-to-pmtu` on Linux, or the equivalent on your VPN appliance) is usually more reliable than relying on interface MTU alone, because it fixes the value TCP actually negotiates at connection setup instead of hoping fragmentation works correctly downstream.