MTU Explained: How Packet Size Breaks VPNs and Large Transfers

A file download that hangs at 90 percent, forever, while every other site on the internet loads fine. That specific, maddening symptom usually traces back to one thing. A packet is too big for some link in the path. A broken feedback loop never tells your device to shrink it.

This guide explains what MTU actually is and how fragmentation works. It covers Path MTU Discovery and why VPNs make the problem worse. It ends with the exact commands to diagnose and fix it.

What MTU Actually Means (and What It Doesn’t)

MTU is the largest payload a single frame or packet can carry, not the total size on the wire. Standard Ethernet MTU is 1500 bytes. Add the Ethernet header and checksum, and the actual frame on the wire is larger.

Every network link imposes a limit on how large a single packet can be. That limit is the Maximum Transmission Unit, or MTU, and it is measured in bytes.

MTU describes the payload, not the whole frame. On Ethernet, a 1500-byte MTU means 1500 bytes of IP packet data. The Ethernet header adds 14 more bytes, and the frame check sequence adds 4 more. The actual frame on the wire runs to 1518 bytes.

Mixing up MTU with total frame size is a common, easy mistake. It rarely matters for everyday use. It matters the moment you calculate overhead for a VPN or a jumbo frame network.

Why 1500 Bytes? Ethernet, PPPoE, and Jumbo Frames

Ethernet settled on 1500 bytes decades ago, and it stuck because nearly every device supports it. PPPoE connections lose 8 bytes to encapsulation, landing at 1492. Jumbo frames raise the ceiling to 9000 bytes, but only where every device on the path agrees.

Ethernet’s 1500-byte MTU traces back to the earliest DIX Ethernet standard, and hardware has stayed compatible with it ever since. That compatibility is exactly why it persists. A number chosen decades ago still works on nearly every device made today.

Not every connection type gets the full 1500, though. PPPoE, common on DSL and some fiber connections, adds 8 bytes of its own header. That leaves 1492 bytes for the actual IP packet. A device that ignores this can suffer the same fragmentation problems covered below.

Jumbo Frames: Bigger Packets, Fewer of Them

Jumbo frames raise the MTU to 9000 bytes, mostly on storage networks and iSCSI deployments. Data centers moving large volumes of data use them too. Fewer, bigger packets mean less per-packet overhead and fewer interrupts for the CPU to handle.

The catch is consistency. Every device in the path, every NIC, every switch, every virtual interface, has to support the larger MTU. That includes trunk ports on a VLAN-segmented network, not just plain switch ports. One 1500-byte device in the middle causes the same fragmentation and black-hole problems this article covers. The only difference is your own infrastructure triggers it, not the internet.

What Happens When a Packet Is Too Big: Fragmentation

A packet bigger than a link’s MTU cannot pass through unmodified. IPv4 routers can fragment it into smaller pieces automatically. IPv6 routers cannot; only the sending device is allowed to fragment, and it often chooses not to.

A packet too large for a link has to be handled somehow. The two IP versions handle it very differently.

In IPv4, a router facing an oversized packet has two choices. It can split the packet into smaller fragments and forward each one, letting the destination reassemble them. Or, if the sender set the Don’t Fragment (DF) bit, it must drop the packet instead and report back.

IPv6 removes that first option entirely. Routers never fragment. Only the originating device can split a packet into pieces. Modern operating systems mostly avoid doing so, preferring to discover the right size upfront.

Why Fragmentation Itself Is a Problem

Even when it works, fragmentation carries real costs. Every fragment needs its own header, adding overhead. Losing a single fragment means the entire packet must be resent, not just the missing piece. Firewalls and NAT devices also have to track and reassemble fragments correctly. That is a common source of bugs, and a known attack surface.

Path MTU Discovery: How Your Connection Finds the Right Size

Path MTU Discovery finds the largest packet size a route can carry without fragmenting. Routers mark oversized packets undeliverable and send an ICMP message back to the sender. The sender shrinks its packets and tries again, all before you notice.

Rather than risk fragmentation, most modern connections avoid oversized packets from the start. That process is called Path MTU Discovery, defined in RFC 1191 for IPv4 and RFC 8201 for IPv6.

The sender starts by assuming its own link’s MTU applies to the whole path. It sets the Don’t Fragment bit and sends normally. If every router along the way can handle that size, nothing else happens. The connection just works.

If a router in the middle cannot forward the packet at that size, it drops the packet. It then sends a message back. On IPv4 that message is an ICMP Type 3, Code 4 message called Fragmentation Needed. On IPv6 it is an ICMPv6 Type 2 message called Packet Too Big. Either way, the message includes the router’s actual MTU.

The sender receives that message, shrinks its packet size to match, and tries again. Repeat this as many times as needed, and the sender converges on the true path MTU. The whole process usually finishes in a fraction of a second.

The MTU Black Hole: When a Firewall Breaks Discovery

Path MTU Discovery only works if that ICMP message actually arrives back at the sender. A firewall that blocks ICMP breaks the feedback loop silently. The sender never learns to shrink its packets, and large transfers just hang.

Path MTU Discovery has one hard dependency: the ICMP message has to actually reach the sender. When it does not, the whole system breaks silently.

Firewalls block ICMP for a reason that made sense once. Blanket ICMP blocking was a common, blunt way to hide a network from ping sweeps. The side effect: the specific ICMP messages Path MTU Discovery depends on get blocked along with everything else.

What a PMTU Black Hole Actually Looks Like

The signature is unmistakable once you know it. Small requests work fine. DNS lookups, a basic webpage, a TCP handshake, all succeed normally. Then a specific transfer, usually one carrying a full-size packet, just hangs, with no error and no explanation.

Cloudflare documented a real version of this. A networking change on their end broke Path MTU Discovery for some IPv6-over-IPv4 tunnel users. The fix was on their end. The failure mode is exactly what any admin can hit behind an overzealous firewall rule.

Why VPNs and Tunnels Shrink Your Effective MTU

Every VPN and tunnel wraps your original packet inside a new one, and that wrapper takes up space. WireGuard adds roughly 60 bytes on IPv4. Your effective MTU inside the tunnel shrinks accordingly, even though nothing on your end changed.

A VPN or tunnel does not just encrypt your traffic. It wraps your original packet inside a new one, with its own headers. That wrapper eats into your available space.

How Much Overhead Each Protocol Adds

Every protocol adds a different amount:

These numbers assume a standard 1500-byte link underneath. Start from a smaller number, like PPPoE’s 1492 or a mobile carrier’s own reduced MTU. The effective tunnel MTU shrinks further still.

Safe Starting Points by Connection Type

These are starting points, not guarantees. Our guide to how VPN protocols actually work covers WireGuard and OpenVPN in more depth. Anyone using the Tailscale or Cloudflare Tunnel workarounds for CGNAT runs into this same overhead.

How to Find Your Path MTU (Step by Step)

Finding your real path MTU takes one command and a few tries. Ping the destination with the Don’t Fragment flag set, shrinking the size until it stops failing. Add 28 bytes back for the IP and ICMP headers to get your answer.

Guessing at MTU wastes time. Testing it directly takes one command.

# Windows
ping -f -l 1472 8.8.8.8

# Linux / macOS
ping -M do -s 1472 8.8.8.8

Start with 1472, since that is 1500 minus the 28 bytes a normal ping’s IP and ICMP headers add. If it succeeds, your path supports the full 1500-byte MTU. If it fails with a fragmentation message, cut the size and try again.

Binary search gets you there fast. Try 1000, then 1200 or 800 depending on the result, narrowing the gap each time. Once you find the largest size that still works, add 28 bytes back to get your actual path MTU. If you’d rather skip the manual math, especially once VPN, PPPoE, and VLAN overhead are all stacked together, our MTU Path Calculator adds it up for you and gives you the interface MTU and TCP MSS directly.

Reading the Result

A working ping at 1472 but not 1473 means your path MTU is exactly 1500. A failure well below that, especially over a VPN, points straight at tunnel overhead. Compare your result against the safe starting points above. Adjust your VPN client’s MTU setting to match.

Fixing It: MSS Clamping and Manual MTU Settings

The production fix for tunnels is TCP MSS clamping, which caps segment size at the router. It only helps TCP traffic, though. UDP and ICMP still fragment or get dropped, since clamping has nothing to adjust on those protocols.

Finding the right MTU is step one. Making sure it actually gets used everywhere is step two. That is where TCP MSS clamping comes in.

TCP connections negotiate a Maximum Segment Size during their handshake, based on each side’s MTU. A router sitting on a VPN or tunnel path can rewrite that negotiated value downward. That forces every TCP connection through it to use packets small enough to survive the tunnel.

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

That single rule fixes the vast majority of real-world MTU complaints. Most traffic, web browsing, downloads, SSH, all rides on TCP. Home routers with a VPN client built in usually apply this automatically once you set the tunnel’s MTU correctly.

The Gap MSS Clamping Doesn’t Cover

MSS clamping only touches TCP. Our guide to TCP versus UDP covers why that split matters here specifically. UDP has no MSS to clamp. Applications using it, like some VoIP and gaming traffic, still rely on working Path MTU Discovery or handle fragmentation themselves.

IPv6 and MTU: What’s Different

IPv6 removes router-side fragmentation entirely, shifting the job to the sending host alone. Every IPv6 link must support at least 1280 bytes, a guaranteed floor IPv4 never had. That floor makes path MTU problems less common, not impossible.

IPv6 handles MTU differently by design, not by accident.

Router fragmentation is gone entirely. If a packet is too big, the router drops it and sends back an ICMPv6 Packet Too Big message. Only the originating host is ever allowed to fragment. Most modern stacks avoid it, preferring Path MTU Discovery instead.

IPv6 also guarantees a floor. Every IPv6 link must support at least 1280 bytes, defined directly in the IPv6 standard. IPv4 never had an equivalent guarantee. That is part of why MTU problems have historically been worse on IPv4 paths.

None of this makes IPv6 immune to the black hole problem covered earlier. A firewall that blocks ICMPv6 Packet Too Big messages breaks Path MTU Discovery the same way. Only the message type differs. Our IPv4 versus IPv6 guide covers the rest of the differences between the two protocols.

Frequently Asked Questions

Quick answers to what people ask most about MTU, fragmentation, and why VPNs seem to break large downloads. These cover jumbo frames, black holes, and the fix that actually works in production.

Related Tools & Resources

These NetworkCheckr guides pair with the diagnostic steps in this article. Confirm your public IP before and after a tunnel change. Then dig into the VPN protocols that shrink your effective MTU in the first place.