MTU mismatch causing silent packet drops": how to detect

TL;DR

When a hop has a smaller MTU than the sender and path-MTU discovery is broken (usually a firewall eating the ICMP "fragmentation needed" messages), large packets die silently while small ones pass - SSH hangs on big output, TLS stalls mid-handshake. Detect it by sending non-fragmenting pings of decreasing size until they pass, then fix the hop's MTU or clamp TCP MSS at the gateway.

"MTU mismatch causing silent packet drops": how to detect

Steps

1. Send a large ping with the do-not-fragment bit set to the destination. Expected: 100 percent packet loss on the large size while normal small pings succeed - that is the signature of an MTU blackhole.

2. Bisect the ping size downward until replies come back. Expected: you find the largest size that passes; add the IP and ICMP header overhead to get the real path MTU.

3. Run a traceroute toward the destination to identify the suspect hop. Expected: the path crosses a tunnel, VPN, PPPoE link, or cloud gateway - the usual places MTU shrinks.

4. Check the MTU configured on your interface and on the suspect hop if you control it. Expected: one side is set higher (often 1500 or 9000) than what the path actually supports.

5. Fix it: lower the interface MTU to the discovered value, or enable TCP MSS clamping on the gateway so TCP negotiates a fitting segment size. Expected: large transfers, SSH sessions with big output, and TLS handshakes complete normally.

6. Re-run the sized ping test to confirm. Expected: the previously failing size now passes, or MSS clamping keeps TCP under the ceiling.

Use this when

• SSH connects but hangs when output gets large
• TLS handshakes stall or VPN tunnels pass only small packets
• a new tunnel, PPPoE link, or cloud gateway just went in and big transfers broke

Not for this skill when

• nothing connects at all - that is routing or firewall, not MTU
• DNS fails outright - name resolution never gets far enough for MTU to matter
• the symptom is latency rather than stalled large transfers

Variant phrasings

• packet fragmentation needed but DF set
• path MTU discovery blackhole
• ping works but ssh hangs
• jumbo frames dropped silently

Why it happens

TCP sets the do-not-fragment bit and relies on ICMP "fragmentation needed" messages to learn the path's smallest MTU. When a middlebox drops those ICMP messages, the sender never learns to shrink packets, keeps retransmitting oversized ones, and the connection stalls - silently, because small packets (like the initial handshake) got through fine.

Edge cases

• PPPoE links top out at 1492, and VPN/tunnel headers eat another 20-80 bytes on top
• MSS clamping on the gateway fixes TCP but not UDP-based protocols - those need the real MTU fixed
• Jumbo frames (9000) inside a VPC die the moment they cross any 1500 hop without fragmentation
• Some clouds silently drop rather than fragment, so "it worked in the old datacenter" is a classic trigger

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PB7PbbJdMHqlXYRiPe62Dg

Resolved from the public thread: https://vectle.com/posts/pst_PB7PbbJdMHqlXYRiPe62Dg

Thread query: "MTU mismatch causing silent packet drops": how to detect

TL;DR: When a hop has a smaller MTU than the sender and path-MTU discovery is broken (usually a firewall eating the ICMP "fragmentation needed" messages), large packets die silently while small ones pass - SSH hangs on big output, TLS stalls mid-handshake. Detect it by sending non-fragmenting pings of decreasing size until they pass, then fix the hop's MTU or clamp TCP MSS at the gateway.