MTU or MSS? What a VPN change will actually fix

Pings succeed, large transfers hang, and the tunnel reports itself healthy. Someone lowers the interface MTU, someone else clamps MSS, and occasionally the problem goes away for reasons nobody records. The two numbers describe different objects, so changing the wrong one produces a fix that looks like luck. Here is the runbook: identify the layer, apply the matching adjustment, then test on a fresh connection.

Two numbers, two objects

MTU belongs to a link or an interface: it is the largest packet that can be handed across without being split. MSS belongs to TCP: it is the largest amount of TCP payload a segment may carry, and it excludes both the TCP and the IP headers. On an ordinary Ethernet link running IPv4, a 1,500-byte MTU yields the familiar 1,460-byte MSS. Those numbers describe different layers and are exchanged by different mechanisms. Confusing them is easy because both are measured in bytes and both sit near 1,500.

One arrives as an interface setting. The other arrives as an option inside a SYN segment, negotiated between endpoints that never see your interface.

Where the outer overhead lands

A VPN puts the inner packet inside another one, and the outer packet has to fit the physical path. Encapsulation headers, the outer IP header, the transport header and any authentication tag all consume bytes the inner packet cannot use. Leave the tunnel interface at 1,500 and the outer packet routinely exceeds what the path will carry. With the don't-fragment bit set, the router drops it and is supposed to send back an ICMP error; if that error is filtered, the sender never learns.

This is why the failure looks selective. Small requests complete and anything that fills a segment stalls, because only the large packets are discarded. A tunnel that passes a ping is not a tunnel that carries data.

Clamping MSS, and where it applies

MSS clamping rewrites the value in the SYN segment as it crosses a chosen point, which makes both endpoints pick a smaller payload without either of them knowing why. On Linux it is a mangle-table target applied by an explicit rule, and it needs to hit SYN packets in the direction you intend. Scope it to the tunnel interface and address range, because a broad rule changes behaviour for traffic that never enters the tunnel.

The effect is TCP-only. A UDP application, a QUIC session and any protocol that builds its own datagrams are untouched by it.

Diagnose with a fixed path

Keep one variable at a time. Test with a packet whose size you choose, and set the don't-fragment flag so the kernel reports the result instead of hiding it.

Record where the failure begins: inside the tunnel, at the tunnel interface, or on the physical path after encapsulation. Then change one number and repeat the same test rather than a different one. Existing connections keep the MSS they negotiated, so a policy change is visible only on a new connection, which is why a cached page proves nothing either way. If one large upload starts working, you have learned about that path and not about every protocol on it.

What each change does not fix

Lowering the interface MTU does not alter the MSS of a session that is already established. Clamping MSS does not help a UDP flow, and it does not repair a path where ICMP errors are filtered in only one direction. Each change fixes one class of problem and leaves the rest exactly as they were.

Write down which adjustment you applied, where, and which test showed the difference, because otherwise the next engineer applies both and loses the ability to tell which one mattered. If the constraint is real and permanent, prefer a tunnel MTU that reflects it over a clamp that conceals it. If you must clamp, leave the rule scoped and commented, since an unexplained mangle rule becomes permanent by default.