MTU, fragmentation and tunnels
The classic symptom: small requests are instant, large ones hang forever, and ping says everything is perfect. Nine times out of ten that is MTU.
What is happening
Your machine sends a packet at the full 1500 bytes. Somewhere along the path sits a link that cannot carry it — a tunnel, a VPN, an encapsulation — so it should send back an ICMP “too big” message. If a firewall along the way drops that message, your side never learns, keeps sending packets that are too large, and the connection simply stalls.
Small packets fit, so ping and the first bytes of a handshake work. Anything bigger disappears. That asymmetry is the fingerprint.
Finding the real MTU
Send unfragmented packets of decreasing size:
ping -M do -s 1472 -c 2 <host>
1472 plus 28 bytes of headers is 1500. If that fails and 1400 works, the path is smaller than you think. Walk it down until it passes.
Fixing it
- On a tunnel interface, set the MTU to what actually fits: 1420 for WireGuard over IPv4 is a common safe value, lower over IPv6.
- Clamp MSS on your firewall so TCP negotiates a size that fits:
the
TCPMSS --clamp-mss-to-pmturule exists exactly for this. - Do not block ICMP wholesale. Blocking type 3 code 4 is how people create this problem on their own machine — ICMP is not optional on the modern internet.
On our network
The standard 1500 bytes works end to end from your port; you do not need to lower anything for us. If you build tunnels on top, the arithmetic is yours — but if you suspect something between us and a destination is mangling it, send us the ping test above and we will look.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base