Ramblings of an aging IT geek
← Ramblings of an aging IT geek
networking

when everything works except the big stuff

A homelab VPN where pings flew but large transfers hung, traced back to an MTU mismatch and fixed with one number.

Network cables in a patch panel

The symptom was maddening. SSH connected fine. ping was clean. Small commands ran instantly. But the moment I tried to scp anything larger than a few kilobytes across the WireGuard tunnel, it hung stone dead. No error, no timeout for ages, just nothing. Web pages that loaded their HTML and then froze waiting for an image. Classic.

This is almost always MTU. A VPN wraps every packet in extra headers, so the usable payload inside the tunnel is smaller than the standard 1500 bytes. If something on the path drops the "packet too big, please fragment" messages, the large packets simply vanish into the void while the small ones sail through. Hence: handshakes work, bulk transfer dies.

The proof is a ping that refuses to be fragmented, sized to fill the link:

ping -M do -s 1420 10.0.0.1   # works
ping -M do -s 1450 10.0.0.1   # silently fails

When the larger size goes quiet, you have found your ceiling. For this WireGuard link the answer was an MTU of 1420, set on the interface in the config:

[Interface]
MTU = 1420

One line. Transfers immediately ran at full speed. The frustrating part is how cheerful everything looks while it is broken: every quick test passes, and nothing in the logs admits a thing. MTU does not announce itself. It just quietly eats your big packets and lets you blame everything else first.