SSH Hangs Over OpenVPN? Measure the Path MTU First

SSH connects, the prompt appears, and the session dies as soon as a command returns something substantial. Echo keeps working briefly, then the connection times out while the client still shows the tunnel as up. A session that is healthy until data arrives is usually hitting a size limit rather than an SSH defect. The checks below are ordered so that the cheapest explanation is eliminated first.

Read the failure shape before touching the profile

Tiny packets make it and full ones do not. A prompt, a banner or a single keystroke fits easily; a directory listing, a download or a pasted block does not. The size at which behaviour changes is the clue, not the fact that SSH is the program involved.

The mechanism is path MTU discovery, which depends on feedback. TCP picks a segment size, and when a router along the way cannot forward the resulting packet it is supposed to say so with an ICMP message. Encapsulation makes the outer packet larger than the inner one, so the usable size inside a tunnel is always below the physical link. Filter those ICMP messages anywhere and the sender never receives the correction, keeps sending full segments, and the outer packet is discarded without notice.

Measure the ceiling from both sides

Compare the tunnel's MTU with the physical link before you change either one. A tunnel that copied the physical value has already told you where the mismatch lives.

Probe from inside the tunnel with a do-not-fragment request, stepping the payload down until replies come back. The size argument counts payload only, so the working number is always below the interface MTU. Add the header sizes back if you need the interface figure.

ip link show tun0
ping -M do -s 1380 10.9.0.1

Repeat the probe against the server's public address from outside the tunnel. If large probes fail there as well, the limit sits on the path to the server and no tunnel option will move it. That comparison saves you from tuning a client that was never the problem. Write both results down before you open a configuration file.

mssfix and fragment do different jobs

mssfix clamps the segment size that TCP connections inside the tunnel advertise during their handshake. It is the right lever for SSH, HTTPS and file copies, which is why the stall often vanishes once it is set. It does not touch UDP payloads at all.

A tunnel that also carries a UDP service can keep failing after SSH is fixed, and that outcome confuses anyone who assumes one option covers everything.

fragment is the other mechanism and a different tool. It splits oversized packets before encapsulation, applies to UDP transport only, adds per-datagram overhead and is documented as a last resort for broken discovery. Both settings need to agree across the peers that terminate the tunnel. One end clamping while the other fragments produces log warnings and behaviour nobody can predict from the files.

Lowering the interface MTU is the blunt option

Reducing the interface MTU on both ends is the blunt instrument. It tells every inner sender a smaller number, which works, and it charges that cost to all traffic rather than to the TCP flows that need it.

Choose it when the tunnel carries traffic you cannot clamp, or when the client is an appliance whose profile you do not control. Apply it symmetrically and record the value beside the profile. A half-applied change is worse than none, because it looks like a fix.

Retest with the transfer that stalled

Reconnect so the settings load, open a fresh connection and repeat the command that froze. Segment size is negotiated at handshake time, so a session that survived the reconnect still carries the old value. A ping is a poor test here, since the whole failure is that small packets pass. Use the listing, the download or the paste that broke.

If the stall persists at a smaller size, look elsewhere: a stateful firewall expiring the flow, a duplicate address, or a route that shifts on reconnect. Record the probe size that failed and the setting you changed, because that pair is what makes the next report useful.