OpenVPN on PPPoE: lower link-mtu, tun-mtu or mssfix?

Pings answer, DNS resolves, and every page that needs a full-size segment hangs. On an uplink that adds its own encapsulation, the path silently loses a few dozen bytes of budget, and a profile written for clean Ethernet keeps asking for packets the line cannot carry. The connection is not slow; it is discarding exactly the packets that matter.

Three options can fix this, and they operate at different layers. Picking the wrong one either does nothing or makes the tunnel fragile in a new way, so the choice starts with what the path actually supports.

Three knobs, three different layers

link-mtu is the outer budget: the encrypted payload plus the OpenVPN header, the UDP header, and the outer IP header. It describes what leaves the machine, which is why it is the number the physical path constrains.

tun-mtu is the inner budget: the interface your traffic sees. It is larger than what the path can carry by exactly the tunnel overhead, and OpenVPN normally derives it rather than making you set it.

mssfix is a different mechanism entirely. It rewrites the maximum segment size announced during TCP handshakes, so TCP peers choose segments that fit after encapsulation. It does not change the interface MTU, and it has no effect on UDP.

If you set link-mtu explicitly, OpenVPN subtracts its own overhead to derive the inner MTU. That overhead is not a fixed constant; it depends on the cipher and authentication, which is why a value copied from a forum post can be wrong on a different profile. Setting both link-mtu and tun-mtu hands the client two contradictory instructions.

Measure the path before choosing any number

Measure from the physical interface, not from inside the tunnel, and remember that ping reports payload, not packet size. Add 28 bytes for the IPv4 and ICMP headers before comparing the payload with a 1500-byte frame, and keep that correction in mind when a peer reports a different number.

On a Linux client, ping -M do -s 1472 forbids fragmentation and fails if the packet is too large. Lower the payload until it passes, then add 28 to get the path MTU. PPPoE costs 8 bytes, so 1492 is normal on DSL. DS-Lite and some mobile paths cost 40 or more, and the answer is usually lower than the nominal link speed suggests.

If every ping size succeeds but large transfers still stall, suspect a black hole rather than a simple size limit. An ICMP fragmentation-needed message is being filtered somewhere along the path, so the sender never learns to shrink, and only the flows that need a big segment notice.

Clamp TCP first, shrink the tunnel second

TCP handshakes are the only thing mssfix touches, which usually makes it the least disruptive control to try first. Set it a little below the path's real budget, push the same value from the server so both ends agree, and retest a large download. If the stall clears, the problem was TCP segment size, and nothing else needs to change.

Lower the inner MTU when the affected traffic is not TCP. A UDP service, a tunnel inside the tunnel, or an application that sends full-size datagrams will keep failing after an MSS clamp because nothing rewrites its packet size. Reduce tun-mtu for that case, or set link-mtu and let the client derive the inner value, but never both.

Do not reach for the old fragmentation option. It split packets inside the tunnel, added overhead, and has been deprecated for good reasons; modern OpenVPN expects the path to be described accurately instead.

Why small probes keep working

DNS queries, ICMP echoes, and TCP handshakes are all far below the failing size. The tunnel therefore looks healthy in every quick test while TLS handshakes and HTTP responses quietly fail. That combination, a working traceroute and a browser that stalls on the first large response, is the signature to look for. Reach for a full-size probe before you reach for a new profile.

Verify with the traffic that failed. Fetch a large page, send a full-size UDP datagram if that is the affected service, and repeat from a second client on a different uplink. Record the measured path MTU and the value you chose, because the next person to touch the profile will otherwise treat the number as arbitrary.

Never take the inner MTU below 1280 when IPv6 runs over the tunnel, because that is the minimum every IPv6 link must carry. A smaller MTU is a fact about the path, not a performance setting to tune by feel.