Per-route MTU on Linux: three size controls, one route
Interface MTU, route MTU and the MSS clamp act at different layers. Attach a budget to the route that wins the lookup, and keep the change reversible.
Three settings on a Linux client all read like "make the packets smaller", and they operate at different layers. The interface MTU caps every packet the device sends. A route MTU caps packets that use that route, which is often what you actually want for one VPN destination. The TCP MSS clamp changes what the two endpoints negotiate, and it does nothing for UDP.
Three controls that look like the same knob
Put them side by side before choosing, because picking the wrong row explains most of the advice that does not work:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Lowering the Ethernet MTU for the whole machine is the blunt version of this fix. It works, and it also penalises every other application on the host, including the ones whose paths were fine. A per-route value expresses the same intent without the collateral cost.
The comparison only holds for traffic the host generates. Forwarding a packet for another client involves that client's own path and the tunnel's outer budget, and a route metric on this host does not reach across that boundary.
Attach the budget to the route that wins the lookup
An illustrative IPv4 route record looks like this:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380Read the record as a description of intent, not a value to paste. The prefix, device, and preferred source have to match the real configuration, and the number has to come from evidence about the encapsulated path rather than from a blog post. The route MTU limits the inner IP packet, which is not the same as a 1380-byte TCP payload or a 1380-byte encrypted outer packet.
Look at where the lookup actually resolves before adding anything. A host with policy rules can route a given destination through a table other than main, and a metric that exists only in main is invisible to that request. Compare ip -4 route show table all with the answer from ip route get, including the mark or namespace context when the rules use them. If the two disagree, the table that answered is the one that needs the metric, not the one that looks tidier.
mtu is not mtu lock
By default the kernel can still update the path MTU from ICMP feedback, which is what path MTU discovery is for. Adding lock stops that. It is a different decision, not a stronger way to save the same number, and for IPv4 it changes the documented handling of the don't-fragment bit.
Locking is reasonable when you have measured the path and want the value to stay put regardless of what arrives. It is a poor default when the network sends legitimate size feedback, because the kernel can no longer adjust and the failure moves to a different symptom.
If ICMP is filtered somewhere along the path, no route setting repairs it. The fix belongs at the filter, and a smaller MTU is a workaround that hides the real fault until the next path changes.
Tunnel software adds its own sizing knobs
OpenVPN's mssfix adjusts TCP segment sizing for its documented UDP tunnel case. It operates on the TCP conversation, so it is not another spelling of the operating system's route MTU, and it cannot help a UDP service that ignores the negotiation.
Do not stack a route MTU, an interface MTU change, and an MSS clamp in one change window. If the problem disappears, you will not know which one mattered, and the ones you keep will constrain traffic for years without a reason anyone remembers.
Make it reversible, then prove it
The route's real owner decides whether the change survives a reconnect. A VPN client that installs the route dynamically will usually rebuild it without your metric, and a manual ip route add then looks like a fix that failed a day later. Put the value in the manager's configuration, and if you need a temporary experiment, record the original route first.
Test with a new connection that performs the operation which stalled, then confirm the intended private route still wins and unrelated destinations are unchanged. Reconnect the tunnel and read the route again, because a value that vanishes on reconnect is not a fix.
If the evidence does not support the change, remove the override through its manager and restore the original route attributes rather than deleting the route. Then note what you measured, on which path, so the next person can tell a real improvement from an experiment that was left running.