MTU / MSS Calculator

MTU vs MSS — what the difference is

Two related sizing values that often get confused:

• MTU (Maximum Transmission Unit) is the largest single packet your link will carry, including IP and transport headers. Standard Ethernet is 1500 bytes.
• MSS (Maximum Segment Size) is what's left for actual TCP payload after subtracting IP and TCP headers. For standard IPv4 TCP, MSS = MTU − 40.

If MTU is too high for the path (some link in the middle drops packets bigger than 1492, say), you get black-hole behavior: short connections work, long ones stall. Symptoms: pages load partially, SSH hangs after auth, file transfers freeze. Lowering MSS to match path-MTU fixes it.

Where MTU goes wrong

• PPPoE (DSL service) eats 8 bytes for its own header. ISP-provided routers usually set MTU to 1492 automatically; consumer routers often don't.
• VPN tunnels add 50–80 bytes of encryption overhead. Every IP packet through the tunnel is wrapped in another IP packet. If MTU isn't lowered, you get fragmentation or drops.
• Jumbo frames (9000 MTU) only work end-to-end if every device in the path supports them. Mostly used inside data centers, not across the internet.

Why MTU matters more than most people realize

Maximum Transmission Unit is the largest packet size a network segment will carry without fragmentation. On a standard Ethernet network, the MTU is 1500 bytes. Every packet larger than that gets either fragmented into smaller pieces or dropped, depending on how the network is configured. When MTU is misconfigured, the symptoms are baffling: some things work, some don't, some work slowly, and troubleshooting takes hours because the failure mode doesn't match what you'd expect.

I run into MTU problems most often with VPN tunnels. A tunnel encapsulates one packet inside another, which adds overhead to every packet. If the outer packet has to fit within a 1500-byte MTU and the inner packet is also 1500 bytes, the outer one is now 1500 plus the tunnel overhead — which won't fit. What happens next depends on the Don't Fragment bit and the specific network gear along the path.

What the numbers actually mean

MTU: 1500 (standard Ethernet)

The default for essentially all consumer Ethernet networks, most business networks, and most WAN links. If you don't know otherwise, assume 1500.

MTU: 1492 (PPPoE)

DSL connections that use PPPoE lose 8 bytes to the PPPoE header, so the effective MTU is 1492. Most modern DSL routers handle this automatically, but if you're manually configuring anything downstream of a PPPoE link, you might need to account for it.

MTU: 1400-1450 (VPN territory)

Most VPN protocols add 40-80 bytes of overhead. WireGuard adds 60. OpenVPN adds 50-80 depending on cipher and compression. IPsec varies from 40 to 100+ depending on the specific configuration. The rule of thumb: if you're inside a VPN tunnel, expect the effective MTU to be somewhere in the 1380-1450 range.

MTU: 9000 (jumbo frames)

Some LAN environments use jumbo frames to reduce per-packet overhead for high-throughput applications like storage networking, backup traffic, and virtualization. Both endpoints and every switch in between have to support the larger frame size or packets get dropped. Jumbo frames rarely make sense outside of dedicated storage networks.

MTU: 68 (the IP minimum)

The IP protocol requires all devices to be able to handle at least 68 bytes. You'll never see this in practice on a real network, but it's the theoretical minimum below which nothing is guaranteed to work.

TCP MSS: the number that actually matters for TCP

MTU is the packet size on the wire. MSS (Maximum Segment Size) is the TCP payload size within that packet. The relationship is straightforward: MSS = MTU - IP header - TCP header - any tunnel overhead. For a standard 1500 MTU with no tunneling, MSS is 1460 (1500 - 20 IP - 20 TCP). For IPv6, it's 1440 (1500 - 40 IPv6 - 20 TCP).

TCP endpoints negotiate MSS during the SYN handshake. Each side announces what MSS it can receive, and the connection uses the minimum of the two announced values. This works well when both endpoints know their own MTU accurately. It breaks when a middlebox in the path has a smaller MTU than either endpoint realizes.

Every consumer router with VPN support has a feature called MSS clamping, which rewrites the MSS in TCP SYN packets to force smaller segments. This is a workaround for the case where PMTUD fails and you end up with a tunnel that drops full-size packets. If a VPN is configured correctly, MSS clamping usually isn't needed. If it's not, MSS clamping can make VPN traffic actually work.

Path MTU Discovery: what it does and how it fails

Path MTU Discovery (PMTUD) is the protocol that lets endpoints figure out the smallest MTU along the entire path between them, not just the local link. It works by setting the Don't Fragment bit on outgoing packets. If a router along the path has a smaller MTU than the packet size, and DF is set, the router drops the packet and sends back an ICMP "Fragmentation Needed" message telling the sender the acceptable MTU.

The sender receives the ICMP, reduces its MTU for that destination, and tries again with smaller packets. Everything works.

Except when someone's firewall is blocking ICMP. This is the number one cause of "the internet is broken for me" support tickets in environments with tunneling. A firewall admin somewhere along the path blocked ICMP because "it's a security thing" — probably twenty years ago — and now nobody can figure out why some websites work fine and others hang forever when loading. The traffic is going out, but the ICMP messages telling the sender to reduce packet size are being dropped, so the sender keeps sending oversized packets that get silently discarded.

The symptom is characteristic: small requests work fine (they fit in any MTU), and larger responses either hang or silently fail. Loading a website's homepage works, but downloading a file stalls after the TCP handshake completes. When you see this, "ICMP is being blocked somewhere" is the first thing to check.

When I actually calculate MTU by hand

Setting up a new WireGuard VPN

WireGuard adds 60 bytes of overhead (a 20-byte IPv4 header on the outer packet, a 4-byte type field, an 8-byte counter, and a 16-byte MAC on the encrypted payload, plus a small header). So the safe inside-tunnel MTU is 1500 - 60 = 1440. If the WireGuard peer is on a network that's already tunneled (double-encapsulation, like WireGuard inside GRE, which some people actually do), the safe MTU drops further.

Debugging Proxmox VM networking

I run a Proxmox homelab with a bunch of Debian LXCs on a bridged network. When I bring up a new VM and it has strange connectivity issues — DNS works but web requests hang, for example — MTU is one of the first things I check. Usually the bridge, the VM's virtual interface, and the physical uplink all need to have consistent MTU. If one is 1500 and another is 1400 (maybe because someone changed it for a different purpose and forgot), traffic gets weird.

Cloud VPC networks

AWS VPCs default to MTU 9001 for jumbo frame support. If you set up a VPN or transit gateway between VPCs, the tunnel MTU is smaller. Instances that were happily talking to each other over the internal network start dropping packets on the cross-VPC path because the sending instance doesn't know the outer path is limited. Explicitly setting the interface MTU on affected instances or using PMTUD (with ICMP allowed) resolves it.

Enabling jumbo frames for storage traffic

If you have a storage network on its own VLAN and every device on it supports jumbo frames, you can bump the MTU to 9000 and reduce per-packet overhead for large sequential reads and writes. The gain is modest (a few percent throughput improvement) but real for high-throughput workloads. The catch: every device has to agree. A single switch or NIC still using 1500 breaks things silently.

MSS clamping specifically

MSS clamping is a middlebox intervention where a device rewrites the MSS value in TCP SYN packets to force a smaller MSS than either endpoint would have chosen on its own. Most consumer routers with VPN termination do this automatically for VPN traffic. Home fiber routers running behind a VDSL modem often do it too.

The classic use case is a VPN tunnel where PMTUD isn't working (usually because ICMP is blocked somewhere). Without clamping, endpoints negotiate MSS 1460 assuming 1500 MTU, then packets get dropped inside the tunnel. With clamping, the router intercepts the SYN and rewrites MSS to something like 1360, so endpoints never send packets larger than the tunnel can carry.

MSS clamping is a workaround, not a fix. It handles TCP but does nothing for UDP (which doesn't have MSS). If your VPN is dropping large UDP packets and you can't fix the underlying MTU issue, MSS clamping won't save you.

Common MTU-related problems

"Some sites don't load but Google works fine"

Classic PMTUD failure. Small responses (Google's homepage) fit; large responses (images from a CDN) don't. Check whether ICMP is being blocked somewhere in the path. Enable MSS clamping on your router as a workaround.

"My VPN works but downloads are slow"

The connection is working but packets are getting fragmented. Fragmentation adds overhead and requires reassembly, both of which hurt throughput. Either fix the MTU to avoid fragmentation, or if you can't, at least enable MSS clamping so TCP avoids the problem.

"Large emails fail to send but small ones work"

Email is TCP, so it should benefit from MSS negotiation. If large emails fail specifically, the MSS clamping or PMTUD is broken somewhere, or the mail server itself has a bug. Check whether the SMTP connection is going through a tunnel that has smaller MTU than the client thinks.

"I set up jumbo frames and now half my network is broken"

Not every device on the path supports jumbo frames. Older switches, some cheap NICs, and any device that hasn't been reconfigured after a MTU change will still be doing 1500. Traffic between jumbo-enabled devices works fine as long as no packet larger than the smallest MTU in the path tries to cross. When it does, drops.

Related tools

If you're actually testing throughput and want to see how MTU-related issues might be affecting your connection, the Speed Test and Bandwidth Calculator are the practical tools. If you see much lower speeds than your link should provide and you suspect MTU is a factor, running a test with different MSS clamping settings can identify whether that's the cause.

For understanding the addressing on both sides of a tunnel, the Subnet Calculator and CIDR Range Tool handle the addressing math.