MTU and PMTUD, the obscure detail that explains many "weird disconnect" issues

A common networking pattern: a connection appears to work. You can SSH in, type commands, get responses. But you try to download a file or load a large page and it just... hangs. No error. Eventually times out. Try again, same thing.

The cause is often MTU mismatch combined with broken Path MTU Discovery. It's one of the most frustrating network failures because nothing logs it clearly. This article explains what's happening and how to fix it.

MTU, recap

The Maximum Transmission Unit is the largest packet a network link can carry without fragmentation. For typical ethernet, MTU is 1500 bytes.

Some networks have different MTUs:

• Cellular: often 1200 to 1400.
• DSL with PPPoE: 1492 (PPPoE adds 8 bytes).
• Some VPNs / tunnels: 1400 or smaller.
• Data center jumbo frames: 9000.

When a packet is too large for a link, two things can happen:

1. Fragmentation. The packet is split into smaller pieces that fit.
2. Drop. The packet is rejected.

Modern IPv6 doesn't allow in-flight fragmentation. IPv4 allows it but with significant performance cost. The current best practice: avoid fragmentation by sending appropriately-sized packets in the first place.

How hosts pick packet size

When a TCP connection is established, both ends negotiate a Maximum Segment Size (MSS). This is the largest TCP payload either side will send. It's based on the local interface's MTU.

Typical:

• MTU 1500, MSS 1460 (MTU minus 20 for IP, 20 for TCP).
• MTU 1400, MSS 1340.

For a connection between hosts on different MTUs, both sides know their own MTU but not the path's. The path might have a smaller MTU than either endpoint.

Enter Path MTU Discovery.

PMTUD, the mechanism

Path MTU Discovery (RFC 1191 for IPv4, RFC 8201 for IPv6) is the mechanism by which hosts learn the actual minimum MTU on the path between them.

How it works:

1. Sender sends a normal-sized packet (e.g., 1500 bytes) with the "Don't Fragment" flag set.
2. If the path can handle it, packet arrives, sender doesn't get an error.
3. If somewhere along the path the packet is too big, that router drops it and sends back an ICMP "Fragmentation Needed" message telling the sender "you need to send packets at most X bytes."
4. Sender adjusts MTU for this destination and retransmits.

After a few round trips, the sender knows the actual path MTU and sends accordingly.

This is elegant when it works.

Why PMTUD fails

PMTUD depends on those ICMP "Fragmentation Needed" messages getting back to the sender. They don't always.

Common reasons:

Overly aggressive firewalls drop ICMP. Many sysadmins block ICMP for "security" reasons (despite ICMP being mostly benign and operationally important). With ICMP blocked, the "this packet is too big" message never arrives. Sender keeps sending oversized packets that keep getting dropped. Connection appears hung.

Stateful firewalls don't track ICMP-to-TCP correlations. Even if ICMP is allowed inbound, some firewalls don't connect "this ICMP is about that TCP connection" and drop it.

Asymmetric paths. The path back to the sender goes through different equipment than the path out. The "fragmentation needed" message might take a route where it's blocked.

When PMTUD fails, you get the "small packets work, large packets don't" symptom.

How to diagnose

Tools and techniques:

ping with size. Send progressively larger pings:

ping -c 5 -M do -s 1472 destination

The -M do says "don't fragment." 1472 bytes payload + 8 bytes ICMP + 20 bytes IP = 1500 bytes packet.

If this works, MTU >= 1500. Try 1492, 1400, 1300, etc., to find where it breaks. The break point is your effective MTU.

For Windows: ping -f -l 1472 destination (note -f for don't-fragment, -l for size).

tracepath:

tracepath destination

Shows the path with PMTU information at each hop. Available on Linux.

Wireshark / tcpdump. Capture packets to see if ICMP messages are arriving.

How to fix MTU issues

Multiple approaches:

MSS clamping. Configure your firewall or router to rewrite the TCP MSS option in handshake packets, forcing connections through your link to use a smaller MSS than the endpoints might otherwise negotiate.

In Linux iptables:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Or with a specific value:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360

This guarantees TCP connections through your network use packets small enough for the path.

Lower the interface MTU. Set your network interface's MTU to a smaller value (e.g., 1450). All outbound packets will be sized accordingly.

Allow ICMP "fragmentation needed" through firewalls. The correct fix to the root cause. Specifically:

iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type packet-too-big -j ACCEPT

Use a tunnel with explicit MTU. If you're operating a tunnel (GRE, WireGuard, etc.), set the tunnel's MTU explicitly to account for encapsulation overhead.

Where MTU problems hide

A few common scenarios:

Tunnels (GRE, VPN, WireGuard). Encapsulation adds overhead. The effective MTU through the tunnel is less than the link MTU. If you don't adjust, large packets through the tunnel get dropped.

DSL with PPPoE. PPPoE adds 8 bytes. Effective MTU is 1492. Many ISPs don't communicate this clearly.

Cellular. Mobile networks often use lower MTUs (1200 to 1400). Cellular-attached devices can have weird MTU behavior.

Cloud overlays. Some cloud networking adds encapsulation. AWS, Azure, GCP all have some variant of "effective MTU is less than 1500."

IPSec. The protocol's overhead reduces effective MTU. Common cause of slow VPN performance for large payloads.

The specific game-server problem

For game hosting, MTU usually isn't an issue. Game packets are typically small (a few hundred bytes for position updates). Even with an aggressive MTU reduction, game packets fit.

Where MTU bites game hosting:

• File downloads from the server (modpack downloads, world downloads) can hit MTU issues.
• Web admin panels through tunnels may be slow.
• Inbound HTTP traffic if your DDoS protection adds GRE overhead.

For game admins seeing weird "downloads from server hang" issues, MTU is worth checking.

The "anti-replay" failure mode

A specific story: a customer of a hosting service complains that "everything works except connecting to one specific service." Other services are fine. Investigation reveals:

• The customer's home internet uses PPPoE with MTU 1492.
• The problematic service requires HTTPS to a server through a load balancer that has anti-replay filters.
• The TLS handshake involves a large certificate (close to 1500 bytes).
• The handshake packets are exactly the size that PMTUD fails on.
• Result: the customer can't establish TLS connections to that specific service.

Fix: enable MSS clamping at the customer's router.

This pattern repeats across many "weird, intermittent" failures. MTU is the unsung culprit.

Why this is so hard to diagnose

The symptoms:

• Some things work (small packets).
• Others don't (large packets).
• No clear error.
• Tools like traceroute succeed (small packets).
• Timeouts eventually.

Without knowing to test with ping -M do -s 1472, the issue looks like a vague "internet is flaky." Specific tests reveal it.

A note on jumbo frames

Some networks (especially data center internal networks) use jumbo frames with MTU 9000. The benefit: less per-packet overhead for large transfers. The cost: incompatibility with the rest of the internet (which expects 1500).

Jumbo frames are great inside controlled networks. Crossing them with public-internet traffic requires careful handling (fragmenting or MSS clamping at the edge).

A summary

MTU is the maximum size of a packet on a given link. Path MTU Discovery is how endpoints learn the minimum MTU on a path. When PMTUD fails (usually because ICMP is blocked), you get the "works for small, fails for large" symptom.

The diagnostic: ping -c 5 -M do -s 1472 destination and adjust the size until you find the break point.

The fix: MSS clamping, lower interface MTU, or allow the right ICMP through firewalls.

This is one of those problems that looks like magic if you don't know about it and trivial once you do. Now you know.

Coming up

We've covered the strange edges of IP networking. The next few articles return to common, useful patterns: reverse proxies, what they do, when to use them, and how they shape modern web architecture.