MTU, MSS, and the silent reason your VPN feels slow

Speed tests are great at one thing: measuring throughput on a single fat TCP connection from your machine to a server with infinite buffers, run over a few seconds. They are bad at measuring almost everything else. Most real-world internet usage looks nothing like a speed test. It looks like dozens of small TCP connections, lots of small packets, and a steady drumbeat of TLS handshakes.

When users complain that their VPN "feels slow even though the speed test looks fine", the cause, more often than not, is not throughput. It is fragmentation, caused by a wrong MTU.

Envelopes inside envelopes

The MTU — Maximum Transmission Unit — is the largest packet, in bytes, that an interface will send without splitting it. Standard Ethernet MTU is 1500 bytes. Your home router, your cable modem, your ISP, and the wider internet are all designed around that number.

A VPN tunnel works by taking each of your packets and wrapping it inside another packet. The outer packet has its own headers — IP header, UDP header, encryption framing, authentication tag — and those headers eat bytes. So if your underlying network supports 1500-byte packets, and your VPN adds 80 bytes of overhead, your effective tunnel MTU is 1420.

If you tell the tunnel its MTU is 1500 anyway, every full-sized packet you generate becomes a 1580-byte wrapped packet, which exceeds what your underlying network can carry. Now one of two things happens, both bad.

What goes wrong, mechanically

Either the network fragments the oversized packet, splitting it into two smaller ones, sending both, and forcing the receiver to reassemble — adding latency, CPU cost, and a chance of one fragment being dropped (in which case both halves get retransmitted). Or, more commonly in 2026 because middleboxes drop fragments, the network drops the packet and sends back an ICMP "Fragmentation Needed" message that ought to tell the source to lower its packet size. This is called Path MTU Discovery (PMTUD).

PMTUD works in theory. In practice, an alarming number of network operators block ICMP, because security textbooks from 2003 said ICMP was dangerous. So the ICMP message does not arrive. The sender does not know its packets are being dropped. It just sends them again and again, slightly faster, hoping. This is called the "PMTUD black hole" and it is one of the more enduring bugs in the operational internet.

How much overhead does each VPN protocol add?

Approximate per-packet overhead, IPv4 underlay:

• WireGuard: ~80 bytes (20 IP + 8 UDP + 4 type + 4 key index + 8 nonce + 16 auth tag + 20 inner IP). Effective tunnel MTU on a 1500 underlay: 1420.
• OpenVPN UDP with AES-GCM: ~50-60 bytes depending on TLS auth and compression settings. Tunnel MTU: 1440-1450.
• OpenVPN TCP: ~60-80 bytes plus the cost of TCP-in-TCP, which is its own special hell.
• IKEv2/IPsec ESP UDP-encapsulated: ~70-80 bytes. Tunnel MTU: 1420.
• WireGuard over IPv6: ~100 bytes (the outer IPv6 header is 20 bytes larger than IPv4). Tunnel MTU: 1400.

Those numbers are upper-bound for the common case. They get worse if there is double encapsulation — say, you are on a network that uses PPPoE (8 bytes), so the underlay is already 1492 instead of 1500, and now your effective tunnel MTU is 1412 instead of 1420. Cellular networks frequently have MTUs in the 1400-1450 range. Some satellite links are even smaller.

MSS, MSS clamping, and why TCP needs special handling

MTU is an IP-layer concept. TCP has its own equivalent: MSS, the Maximum Segment Size, which is the largest TCP payload that fits inside one packet. MSS is announced during the TCP handshake. Each side tells the other "do not send me TCP segments larger than X bytes."

A TCP endpoint that does not know about your VPN announces an MSS based on its local interface MTU — typically 1460 for an Ethernet host. If your tunnel can only carry 1380-byte packets, that 1460-byte MSS is going to cause exactly the fragmentation/blackhole problem above.

The fix is MSS clamping. The VPN gateway rewrites the MSS option in passing TCP SYN packets to a value that fits inside the tunnel. Linux iptables has a built-in target for this:

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

Every serious VPN does this on the server side. If yours does not, you can do it on your local machine, but the right place is the gateway because then it works for every endpoint. Note that MSS clamping only fixes TCP. UDP-based protocols (QUIC, video calls, gaming, DNS) need a correct MTU end-to-end; clamping does nothing for them.

Diagnosing it yourself

On Linux or macOS, the classic test: ping with the don't-fragment bit set, sweeping packet sizes until you find the largest that gets through.

1. 1Connect to your VPN.
2. 2Run: ping -M do -s 1372 1.1.1.1 (Linux) or ping -D -s 1372 1.1.1.1 (macOS). The -s value is payload size; add 28 for ICMP+IP headers to get the real packet size.
3. 3If it succeeds, increase by 10 and try again. If it fails ("Message too long" or just no replies), decrease.
4. 4The largest size that succeeds, plus 28, is your effective path MTU. For most VPN setups in 2026, expect a number between 1380 and 1450.

If your VPN client lets you set MTU manually, set it to that number minus a small safety margin. If it does not, file a bug.

What we ship as defaults, and why

Our app sets WireGuard MTU to 1380 by default on wired and Wi-Fi connections, and 1280 on cellular. The reasoning:

• 1380 leaves headroom for one extra layer of encapsulation that we did not anticipate — a corporate proxy, an ISP-level tunnel, an unusual MPLS hop. We pay maybe 40 bytes of efficiency to never see fragmentation in practice.
• 1280 is the IPv6 minimum MTU, mandated by RFC 8200. Every IPv6 path on the internet is required to support 1280-byte packets without fragmentation. On cellular networks, where MTUs are unpredictable and PMTUD is broken often enough that we cannot trust it, 1280 is the safest possible setting. We lose some efficiency. We gain reliability.
• Users who want to tune for maximum throughput on a known-good network can override the MTU in settings. We surface it as a number, not a dropdown of vague labels. People who care about MTU know what to do with a number.

The fix list

1. 1Test your current path MTU using the ping technique above.
2. 2Set your VPN client MTU to that minus 20-40 bytes of safety margin.
3. 3Confirm your VPN gateway does MSS clamping on TCP — if it does not, do it locally.
4. 4On cellular and satellite, prefer 1280 over higher values. The throughput cost is real but small; the reliability win is large.
5. 5If you still see "small things work, big things fail" symptoms, drop MTU another 40 bytes and try again. Some paths have surprises.

MTU is one of those topics where five minutes of theory and a single ping test save you weeks of "the internet feels weird, I do not know why". It is not glamorous. It is not what marketing pages talk about. But it is the difference between a VPN that disappears into the background and one that you blame for a hundred unrelated problems.