OpenVPN mssfix: Why One Client Stalls on Large Transfers

A single laptop stalls on uploads through the tunnel while every other device on the same server keeps working. That pattern points at one path, not at the server configuration, and it is the usual entry to the mssfix question. The option can help, but only for the TCP connections it actually rewrites. Knowing its reach keeps you from changing a working server to rescue one client.

What the option rewrites

mssfix edits the maximum segment size advertised in TCP handshakes that pass through the tunnel, so the sending side picks segments that fit the encapsulated budget. It acts on the handshake, which means a connection opened before the change keeps the value it negotiated.

It does not shrink UDP datagrams, and it does not set the tunnel MTU. Two different problems produce the same symptom: a TCP sender that ignores the path limit, and a path that silently drops large packets at any size. mssfix addresses the first and does nothing for the second.

That distinction explains the disappointing experiments. Setting a smaller value on a black-holed path changes the segment size but not the drop that follows, so the transfer fails at a different point.

Scope is TCP inside the tunnel

Only TCP traffic is rewritten. A QUIC session, a game or an application that sends large UDP datagrams will keep its own packet sizes, and if those are the transfers that stall, the fix belongs at the tunnel or path MTU instead. Read which protocol the failing transfer uses before reaching for a TCP option, because the wrong layer has its own fix.

Direction matters as well. A client setting affects the traffic that client sends into the tunnel, while the server covers flows it forwards toward clients. If only inbound downloads stall, the client-side value is not the whole story.

The number and the keyword are not portable

Community OpenVPN 2.6 accepts an optional keyword after the value. With mtu, the number describes the outer packet size including IP and UDP headers; without it, the argument follows a different accounting convention. A line copied between versions therefore does not describe the same packet budget. Check the manual page that ships with the build you actually run instead of a tutorial for another release.

The syntax looks like this:

mssfix 1400 mtu

Treat 1400 as a placeholder, not a recommendation for your path. Derive the value from the measured path and the encapsulation actually in use, and remember that clients on older versions or other implementations may reject or reinterpret the keyword.

Confirm on the one client first

Measure the path from the failing machine before changing anything. A payload that the path can carry without fragmentation is the number you are looking for:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

The first probe fits a 1500-byte packet once the 28 bytes of headers are added. If it fails with a fragmentation error and the smaller one succeeds, the usable size is somewhere between them, and the tunnel overhead comes off the top.

Then repeat the transfer that stalled, on a fresh connection, and compare. If the single client improves while others are untouched, you have found the scope of the problem. If every client stalls, the server-side value is the one to review. Neither result justifies a change on hardware that was never in the failing path.