VPN MTU Myths: Why Your Packets Shrink and Where the Room Goes

Somebody tells you the VPN is "losing packets because of MTU", you set the tunnel to 1400, and the transfer works again. That result feels like a diagnosis. It is usually a coincidence of arithmetic: you picked a number small enough to fit under a limit you never identified, and you will meet the same limit again on the next network with a different budget.

Two myths cause most of this. The first is that the tunnel interface's MTU is the path's MTU. The second is that encapsulation costs "one header" and PPPoE costs nothing worth counting. Both are wrong in ways that make the number you choose look arbitrary when it is actually determined.

Myth one: the tunnel's MTU is the path MTU

The value you set on a tunnel interface is a local promise about the largest inner packet the implementation will hand down. The path's real capacity is a property of every link between you and the far end, and it can change when a route changes, when a mobile connection hands over, or when traffic takes a different peering. A configured 1500 tells you what your host will build, not what the network will carry.

Path MTU discovery exists to reconcile the two, and it depends on feedback. With IPv4, a router that cannot forward a full-size packet is supposed to send an ICMP "fragmentation needed" message, and the sender lowers its estimate. With IPv6, the equivalent is a Packet Too Big message and routers do not fragment in transit at all. When that feedback is filtered, the sender keeps producing packets the path cannot carry, and nothing tells it why.

Myth two: encapsulation costs one header

Count the outer layers honestly. An outer IP header is 20 bytes for IPv4 or 40 for IPv6. UDP encapsulation for NAT traversal adds 8. The tunnel protocol adds its own header, an initialization vector or nonce, padding to the cipher's block or alignment boundary, a trailer, and an integrity check value. Depending on the protocol and cipher, the total is comfortably in the tens of bytes before the inner packet even starts.

Then subtract again for the inner packet's own headers. A TCP segment inside the tunnel carries its own 20-byte IP header and 20-byte TCP header, and TCP's MSS is derived from the MTU, not from the tunnel's nominal payload. That is why ping with a smaller payload can succeed while a file transfer stalls: the tools are testing different things, and only one of them is exercising a full-size TCP segment.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

The first command reports the configured tunnel MTU. The two probes send a 1472-byte payload, which with 28 bytes of IPv4 and ICMP headers is a 1500-byte packet, then a smaller one. If the large probe fails outright and the small one succeeds, you have a size-dependent fault rather than a general routing problem.

Myth three: PPPoE still gives you a clean 1500

A conventional PPPoE access link does not carry a 1500-byte IP packet. The PPPoE header plus the PPP protocol field consume 8 bytes inside the Ethernet frame, which leaves 1492 for the IP packet. That is the traditional limit described in RFC 2516. If you run a VPN over such a link, the tunnel's overhead comes out of that 1492, not out of 1500.

RFC 4638 defines a way to negotiate a larger PPP payload when both the access concentrator and the customer equipment support it, which is why "this connection uses PPPoE" alone does not prove a specific number. A local setting cannot make an intermediate device accept a packet it was never configured for, so the useful question is what the link actually negotiated, not what the label says.

Why the failure looks selective

Small requests succeeding and large transfers stalling is the classic signature of a path MTU black hole. The handshake, the DNS query, and the API call all fit; the bulk transfer produces full-size segments that die at one link, and the ICMP message that should have reported the problem never arrives. The connection looks fine and the download hangs, which sends people looking at the server instead of the path.

A second, related mistake is mixing up three numbers: the interface MTU, the TCP MSS, and the protocol's own fragmentation or padding setting. MSS clamping on a router rewrites the advertised MSS so the sender builds smaller segments; it does not change the tunnel MTU, and it does not help UDP traffic. Setting all three to the same number because they look related is how a working setup gets broken by a well-intentioned change.

What to change, in what order

Start with evidence. Confirm the fault is size-dependent with the probes above, then find the smallest size that passes and the largest that fails. Check the access link's real MTU before blaming the tunnel; a PPPoE link caps the budget before your VPN touches it. Keep a note of the original values so the change can be reversed.

Then apply the smallest adjustment the client documents. Many clients expose a tunnel MTU plus an MSS-fix option, and the MSS option is often the better lever for TCP because it reaches the sender without shrinking every packet. Re-test the same destination and the same transfer, and record the numbers you settled on. A tunnel value that works on one access network is not a universal constant, and the next site will have its own budget.