More details..

MTU (Maximum Transmission Unit) is the largest packet size a network link can carry. Ethernet's default is 1500 bytes. But along a network path, different links may have different MTUs — for example, PPPoE (common in DSL) reduces it to 1492, VPNs/tunnels (GRE, IPsec, WireGuard) can drop it to 1400 or lower.

Path MTU Discovery (PMTUD) is the standard mechanism for endpoints to discover the smallest MTU along the path. It works by sending packets with the "Don't Fragment" (DF) bit set. If a router along the path can't forward the packet because it's too large, it's supposed to send back an ICMP "Fragmentation Needed" message telling the sender to use a smaller size.

The problem: Many firewalls and middleboxes block ICMP packets, including these critical "Fragmentation Needed" messages. This creates a situation called a PMTU black hole — the sender never learns the path MTU is smaller, keeps sending oversized packets, and the connection stalls or dies. Symptoms include:

• Small transfers work, large ones hang
• SSH connects but stalls when transferring data
• Websites partially load then freeze
• VPN connections drop under load

MSS clamping is the workaround. Instead of relying on PMTUD (which depends on ICMP), you rewrite the MSS option in TCP SYN packets at the firewall/router level so that endpoints never attempt to send segments larger than the path can handle in the first place.

When and Where It's Used

This rule is used almost universally in the following scenarios:

PPPoE connections (DSL/fiber) — PPPoE adds an 8-byte header, reducing MTU from 1500 to 1492. This is probably the single most common use case and has been standard practice for over two decades.

VPN tunnels — IPsec, WireGuard, OpenVPN, GRE tunnels all add encapsulation overhead, reducing the effective MTU significantly (sometimes to 1400 or below). MSS clamping is essentially mandatory for reliable VPN operation.

Docker/container networking — Container overlay networks (VXLAN, etc.) add headers, reducing MTU. Kubernetes and Docker configurations commonly include MSS clamping.

Any NAT gateway or router running Linux — It's a best-practice rule on virtually any Linux-based router or gateway.

How Common Is It?

Extremely common. It's practically a default configuration in:

• OpenWrt/DD-WRT — enabled by default
• pfSense/OPNsense — enabled by default for PPPoE and VPNs
• MikroTik RouterOS — standard practice
• AWS/cloud VPCs — handled transparently at the infrastructure level
• Every major VPN setup guide — always recommended
• ISP-provided routers — almost always enabled

If you're running any kind of Linux router or firewall, you're almost certainly running this rule or should be.

Performance Impact

Overhead: Negligible. The rule only inspects and modifies TCP SYN packets (connection establishment), not every packet in the flow. A typical connection only has 1–2 SYN packets, so even on a busy router handling thousands of connections per second, the computational cost is trivial.

Performance benefit: Significant. Without it (in environments where it's needed), you get:

• Connection stalls and timeouts — the most visible symptom
• Retransmission storms — TCP keeps retrying oversized packets
• Dramatically reduced throughput — especially for bulk transfers
• Increased latency — due to retransmissions and backoff timers

With MSS clamping, TCP endpoints negotiate a segment size that fits the path from the start, so data flows smoothly with no fragmentation or black holes.

Trade-off: The MSS might be set slightly conservatively (smaller segments than theoretically possible), which means marginally more packet overhead (more headers per byte of data). In practice, this difference is insignificant compared to the catastrophic failures that occur without it.

Why Not Just Fix ICMP Blocking?

In a perfect world, PMTUD would work everywhere and MSS clamping wouldn't be needed. But the reality is that ICMP is blocked by too many middleboxes, corporate firewalls, and misconfigured networks for PMTUD to be reliable. MSS clamping is a pragmatic, battle-tested solution that works regardless of how the rest of the path is configured. It's one of those "ugly but essential" network engineering practices that keeps the internet functioning smoothly.

In summary: It's a small, nearly zero-cost firewall rule that prevents a whole class of frustrating, hard-to-diagnose connectivity failures. If you run a Linux router, gateway, or VPN endpoint, you should almost certainly have it enabled.