MTU and MSS Explained: When Big Packets Get Stuck

You set up a VPN. Most things work. But some sites load partially, large file uploads hang, and SSH sessions to certain hosts feel broken. The diagnosis is almost always the same: MTU mismatch. A subtle network parameter you’ve probably never thought about is silently dropping packets that are slightly too big.

This post explains what MTU and MSS are, why they matter, the failure modes when they go wrong, and how to fix them — both as a user and as someone running a service.

What MTU Is

MTU (Maximum Transmission Unit) is the largest single packet — measured in bytes — that a network link can carry. Standard values:

• Ethernet: 1500 bytes (the most common default).
• PPPoE (some DSL): 1492 bytes.
• VPN tunnels: typically 1400-1450, depending on encapsulation overhead.
• Mobile (4G/5G): 1500 in most cases, sometimes lower.
• Jumbo frames (datacenter): 9000 bytes, used inside well-controlled networks.

MTU includes the IP header. The payload available for TCP/UDP data is smaller: MTU - IP_header (20-40 bytes) - protocol_header (20 for TCP, 8 for UDP).

When a packet is too big for the next hop’s MTU, one of two things happens:

• The router fragments it (split into multiple smaller packets, reassembled at destination).
• The router drops it and sends back an ICMP “Fragmentation Needed” message.

Fragmentation is generally bad for performance; modern protocols use a different mechanism.

What MSS Is

MSS (Maximum Segment Size) is the largest TCP payload — measured in bytes — that a TCP segment can carry. It’s negotiated during the TCP handshake.

For a standard Ethernet path:

• IP header: 20 bytes
• TCP header: 20 bytes
• MTU 1500 → MSS = 1500 - 20 - 20 = 1460 bytes

When a TCP segment is created, it’s sized to the MSS, so each individual IP packet fits within the MTU. No fragmentation needed.

MSS is set by the receiving side. In the TCP SYN, you announce “my MSS is 1460.” The sender then never creates segments larger than 1460 bytes of payload toward you.

Path MTU Discovery (PMTUD)

When a packet’s “Don’t Fragment” bit is set (the default for modern TCP), routers can’t fragment it. If a router on the path has a smaller MTU, it drops the packet and sends back ICMP Type 3 Code 4 (“Fragmentation Needed but DF set”). The sender then knows to use a smaller MTU for that destination.

This mechanism is called Path MTU Discovery (PMTUD).

When PMTUD works correctly, large packets adapt to the smallest MTU on the path. Connections work smoothly.

The Problem: PMTUD Blackholes

In practice, PMTUD frequently doesn’t work. The reasons:

ICMP filtering

Many firewalls drop ICMP indiscriminately for security reasons. “Block ICMP” is a popular default — but it breaks PMTUD because the “Fragmentation Needed” messages get dropped, never reaching the sender.

Stateless ICMP responses

Some firewalls drop the specific ICMP type that PMTUD needs.

NAT issues

NAT must rewrite ICMP responses to map back to the original sender. Some NATs do this wrong or don’t do it at all.

Asymmetric paths

The ICMP response takes a different return path that drops it.

When PMTUD breaks, the sender doesn’t get the feedback. It keeps sending packets at its assumed MTU, and they keep getting dropped silently. This is a PMTUD blackhole.

Symptoms of MTU Mismatch

The classic signs:

Small requests work; big ones don’t

A login page (~10 KB) loads. A large download or video stream hangs. The difference: small data fits in a single MSS-sized segment; large data spans many packets, some of which are dropped.

Some sites work; others don’t

A site with a smaller MTU on its path works fine; one with a larger MTU doesn’t. Often “some CDN-fronted sites work, my origin’s direct connection doesn’t.”

Connections start fast then stall

The handshake is small packets. Then comes the first big response and… silence. Time out.

Symptoms vary by direction

Uploads might work; downloads might not (or vice versa) depending on which direction has the MTU problem.

Pings work; TCP hangs

ICMP pings are small by default. The problem doesn’t show until larger packets are needed.

Diagnosing

A few practical tools:

ping -M do -s 1472

Send a ping with the Don’t Fragment bit set and a payload of 1472 bytes (so the total IP packet is 1500 bytes — 1472 payload + 8 ICMP header + 20 IP header).

ping -M do -s 1472 example.com

If it works: path supports MTU 1500. If it fails: try smaller sizes. Binary search down until you find the highest size that works. That’s your path MTU.

Verify on macOS

ping -D -s 1472 example.com

Verify on Windows

ping -f -l 1472 example.com

tracepath (Linux)

tracepath example.com

Specifically designed to discover path MTU; reports it explicitly.

mtr with packet sizing

mtr --psize 1472 example.com

Common Causes

VPNs and tunneling

The biggest source of MTU problems in 2026. Each tunnel layer adds encapsulation overhead:

• WireGuard: ~60 bytes overhead → 1440 MTU on a 1500 underlay
• OpenVPN: ~50-80 bytes overhead
• IPSec: Variable; often 1400 MTU on a 1500 underlay
• GRE: 24 bytes overhead

If you don’t reduce MTU inside the tunnel and the underlay doesn’t fragment, packets are dropped.

PPPoE

DSL connections using PPPoE have a slightly reduced MTU (1492 instead of 1500). Older routers handled this transparently; modern setups usually do too, but misconfigured ones leak fragmented packets.

Cloud VPCs

Some cloud VPCs have specific MTU requirements. AWS supports jumbo frames (9001) within a VPC but 1500 to the internet. Container networking (Docker, Kubernetes) can add 50 bytes of overlay overhead.

Firewall ICMP blocking

The “block all ICMP” misconfiguration is everywhere. It breaks PMTUD invisibly.

Fixing It

Option 1: Lower the MTU

On the affected interface, explicitly set a smaller MTU.

# Linux
sudo ip link set dev eth0 mtu 1400

# macOS
sudo ifconfig en0 mtu 1400

For VPN tunnels, set the tunnel interface MTU appropriately. WireGuard, OpenVPN, and others have config options.

Option 2: TCP MSS clamping

A router on the path can rewrite the MSS in TCP SYN packets to a safer value, forcing both sides to use smaller segments.

# Linux iptables
iptables -t mangle -A POSTROUTING -o ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

MSS clamping is the standard mitigation for VPN/tunnel deployments. It works without depending on PMTUD.

Option 3: Fix the ICMP problem

If the issue is upstream ICMP filtering, fixing the firewall is the right solution. ICMP “Fragmentation Needed” should be allowed everywhere — it’s a critical signaling mechanism.

Option 4: Use larger MTU end-to-end (when possible)

Within a single controlled datacenter, enable jumbo frames (MTU 9000). Larger frames = fewer packets = less per-packet overhead. Only practical when you control every hop.

MTU in Cloud Deployments

A few specific notes:

AWS

• EC2 supports 9001 MTU internally; 1500 to the internet.
• Container networking (ECS, EKS) often defaults to slightly smaller MTU due to overlay overhead.
• AWS Direct Connect supports configurable jumbo frames.

GCP

• VPC default is 1460 MTU (4 bytes less than Ethernet for service overhead).
• Configurable up to 8896 for jumbo frames within VPC.

Azure

• Default 1500 MTU; some specialized SKUs support 1700 or higher.

Kubernetes

• Most CNI plugins (Calico, Flannel, Cilium) set pod MTU 30-50 bytes below the host MTU for tunnel overhead.
• Misconfigurations cause “intra-cluster traffic works; egress doesn’t.”

MTU in 2026

A few practical observations:

• Most consumer connections have MTU 1500. PMTUD usually works.
• Mobile networks generally MTU 1500 too. Occasional smaller values during transitions.
• IPv6 minimum MTU is 1280. All IPv6 paths must support at least this. Modern internet paths almost always support more.
• PMTUD works better than it used to. ICMPv6 is more universally allowed than ICMPv4 was.
• VPNs remain the main source of problems. If users complain about a VPN, MTU is high on the suspect list.

TL;DR

• MTU is the largest packet a link can carry. Default 1500 on Ethernet.
• MSS is the largest TCP payload. Negotiated in the TCP handshake.
• PMTUD is the mechanism to discover the smallest MTU on a path.
• PMTUD blackholes happen when ICMP responses are filtered. Common cause of “some things work, others don’t.”
• VPNs are the dominant source of MTU problems due to encapsulation overhead.
• MSS clamping is the standard fix for tunnels — rewrite MSS in SYN packets to a safe value.
• Diagnose with ping -M do -s 1472 and binary-search down.
• Don’t block ICMP universally — it breaks PMTUD invisibly.

MTU is one of those topics most application developers never need to know about — until you do, and then you really do. The next time a VPN feels broken or a corporate firewall seems to be eating large requests, MTU is a top suspect. For the related transport-layer topics, see TCP vs UDP and port numbers.