MTU too large: the network bug that lets pings through and blocks everything else

Key takeaways

• Telltale symptom: small exchanges get through, large ones hang. Ping and DNS work, transfers stall.
• A tunnel adds headers: the packet exceeds the link limit and has to be fragmented or dropped.
• Automatic discovery of the maximum size relies on ICMP messages that many firewalls block — the packet then disappears with no error.
• The decisive test: a ping of increasing size with fragmentation disabled, which gives you the exact size of the largest acceptable packet.
• Fix it in the right place: setting the tunnel MTU beats patching over it with TCP segment clamping.

The picture is always more or less the same. The VPN is up, ping answers, DNS resolves. But the web page only half-loads, the SSH session freezes right after the banner, and the file transfer sits at 4% forever.

You suspect the firewall, the routing, the ISP. It is almost always the MTU.

The signature to look for

An MTU problem stands out from an ordinary network failure by its asymmetry: small exchanges get through, large ones fail.

• Ping works — it sends tiny packets.
• DNS works — queries fit inside a single packet.
• The SSH connection is established, then freezes the moment it has to print anything bulky.
• A web page loads the text, never the images.
• A transfer starts, then stops at a percentage that never moves again.

That mix of successes and stalls, sorted by size, is very specific. When you see it, test the MTU first — it will save you hours spent re-reading perfectly innocent firewall rules.

Why tunnels trigger this

The MTU is the largest packet size allowed on a link. On plain Ethernet, that is 1500 bytes.

A tunnel encapsulates: it wraps every packet in its own headers before sending it on. A 1500-byte packet, perfectly legal on your local network, is bigger than that once dressed up. It then exceeds the limit of the link it has to cross.

Two possible outcomes: fragment it, or drop it. And if the packet carries the flag that forbids fragmentation — which TCP sets all the time — dropping is the only option left.

The silent drop

There is a mechanism designed for exactly this: when a device drops an oversized packet that forbids fragmentation, it sends back an ICMP message stating the acceptable size. The sender adjusts, and everything falls back into place.

Except that plenty of firewalls block ICMP, out of a misplaced caution that denies everything without telling the useful messages apart.

The message never arrives. The sender has no idea its packets are dying in transit. It retransmits them unchanged, indefinitely. The connection returns no error: it simply hangs.

The test that settles it in three minutes

The method is direct: send pings of increasing size with fragmentation disabled, and find where it stops.

You raise the payload until the replies stop. The last value that gets through, plus 28 bytes of headers (20 for IP, 8 for ICMP), gives the MTU actually usable along the path.

Bisect rather than step: try 1472, then 1400 or 1440 depending on the result, and narrow down. Three or four attempts are enough.

One detail that matters: test against the real destination, not against the gateway. MTU is a property of the whole path, and the tightest link can sit anywhere along it.

Fixing it in the right place

Once you know the value, two fixes are available — and they are not equivalent.

Setting the MTU on the tunnel interface is the clean fix. You tell the interface never to emit packets larger than the measured size, encapsulation headers included. All traffic benefits, TCP and UDP alike.

Clamping the TCP segment size is a catch-up fix: the device rewrites, on the fly, the size advertised when connections are established, forcing both ends to stay under the limit. It is useful when you do not control the client machines.

But that second method has a hard limit: it only covers TCP. Everything running over UDP — large DNS responses, video calls, some VPNs — stays broken. It treats the most visible symptom, not the cause.

Good practice: fix the interface MTU, and use TCP clamping only as a supplement when a path is outside your control.

Jumbo frames, the other source of trouble

The reverse problem exists too. You enable jumbo frames on a storage network to improve throughput, raising the MTU to 9000 bytes. The gain is real — provided every device along the path is configured identically.

One switch left at 1500 and you get exactly the same symptoms: small exchanges get through, large ones vanish. With one extra difficulty: because the problem was born of an optimization meant to make things better, that is rarely where anyone looks.

If you enable jumbo frames, do it everywhere or nowhere, then verify with the ping test. Three minutes that save you three days.