Why a VPN stalls on large transfers but not on small ones

A page loads, a ping succeeds, and a file copy hangs at the same point every time. That pattern points at packet size rather than at bandwidth or credentials. Encapsulation adds bytes to every packet, so a payload that fitted on the original path can exceed the limit once it is tunnelled. Three different numbers get called MTU during these conversations, and confusing them leads to a setting that fixes one application and breaks another.

Three numbers people call MTU

The interface MTU is the configured limit for a packet on that link. The path MTU is the smallest limit along the route, discovered rather than configured. The TCP MSS is the payload size a peer advertises it can receive, and it is derived from the other two rather than being a separate physical limit.

A tunnel has an inner and an outer view. The outer packet carries the encapsulated one plus whatever headers the protocol needs, so the usable inner size is smaller than the outer path allows. The path to the VPN server is also different from the server's path to the destination.

Path MTU discovery lets a sender learn the working size, but it depends on feedback arriving. When an intermediate device filters the relevant ICMP messages, the sender keeps transmitting packets that never complete, which is the classic black hole. The symptom is distinctive once you know it: the handshake succeeds, the first full-size payload disappears, and the connection eventually resets or hangs. Nothing in the application log looks like a network problem.

Probe the path with a payload you control

A probe is evidence about one route and one size, not a recommended setting. Use a host that answers, and vary only the payload size.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

The first command sends a Linux probe with fragmentation disabled and a 1372-byte payload, and the second does the same on Windows where the payload is set with -l. A reply means that size survived the path. A fragmentation-needed message is informative, while a timeout is ambiguous because the host or an intermediate device may simply drop ICMP.

Walk the size down in a few steps rather than binary-searching to the byte. You are trying to establish whether a size ceiling exists, not to publish a number for every network. The number you find applies to this path, this protocol and this address family.

IPv4 and IPv6 fragment differently, so a probe result from one family says nothing about the other. Test the family the application actually uses.

MSS clamping only helps TCP

For TCP, the effective payload is negotiated during the handshake, and a router on the path can rewrite that value downward so both endpoints send smaller segments. That is what MSS clamping does, and it works without touching the client at all.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

The first rule clamps the advertised MSS to the path MTU for forwarded TCP handshakes, and the second shows the tunnel interface's own MTU so you can compare it with what the path allows. Clamping is the least invasive fix for a TCP application that stalls after the handshake.

It does nothing for UDP. A voice or game client sending large datagrams will ignore an MSS setting entirely, because there is no handshake to rewrite. If the failing application is UDP, look at the client's own packet size options instead. The two protocols fail differently and are repaired by different tools, which is why the protocol belongs in the first sentence of the ticket.

OpenVPN exposes options such as tun-mtu, mssfix and fragment-related settings, and their behaviour depends on the version and on whether the data channel is AEAD. Read the manual for the version in use, and change one option at a time.

Change one supported setting and repeat both runs

Keep the original profile, change a single supported value, and repeat both the small request that worked and the large transfer that failed. If only the large one changes, you were chasing size. If both change, something else moved with it.

A lower value can reduce the symptom while adding overhead, so the smallest possible number is not the goal. The goal is a size the path carries reliably with the least waste. Note the value, the path and the client version in the ticket, because the same number applied elsewhere is a guess.

If the same profile works from another trusted network, keep that difference in the diagnosis rather than declaring the client fixed. The variable that changed is the path, and the path is what the probe measured.