Understanding MTU (Maximum Transmission Unit): The Speed Limit of Networking

Your VPN connects fine but large file transfers stall after a few seconds. HTTPS pages load halfway then hang. SSH sessions work but scp gets stuck. These are the classic symptoms of an MTU mismatch — a problem that trips up even experienced network engineers because the symptom (broken transfers) and the cause (packet size) seem completely unrelated. Understanding MTU and how it interacts with tunneling, fragmentation, and Path MTU Discovery is the key to diagnosing this class of failure.

What MTU Is

MTU — Maximum Transmission Unit — is the largest size, in bytes, of a single packet that can be transmitted over a specific network link without being fragmented. It is a property of the network layer interface, not the application or TCP/UDP layer. Every network hop between source and destination has its own MTU, and the practical MTU for a connection is determined by the smallest MTU anywhere along the path — called the Path MTU.

The MTU value includes the IP header (20 bytes for IPv4, 40 bytes for IPv6) and the transport layer header (20 bytes for TCP, 8 bytes for UDP), plus the payload. When people refer to the 1500-byte Ethernet MTU, they mean the maximum IP packet size — the full IP datagram including headers.

Why 1500 Bytes Is the Standard

The 1500-byte Ethernet MTU has been the standard since DIX Ethernet in the early 1980s. The value was chosen as a balance between two competing concerns:

• Too large — bigger packets mean longer transmission times per packet, higher latency for small messages that get queued behind large ones, and more data lost if a packet is corrupted and needs retransmission.
• Too small — smaller packets mean more overhead. Each IP packet carries a 20-byte IP header and a 20-byte TCP header. A 100-byte payload in a tiny packet has 40% overhead. A 1460-byte payload in a 1500-byte packet has only 2.7% overhead.

1500 bytes has proven robust enough that the internet has standardized around it. Most ISP connections, cloud networks, and internet routers operate at or below this MTU. Changing it requires coordination at every hop.

Packet Fragmentation

When a packet larger than the link MTU arrives at a router, IPv4 allows the router to fragment it — split the packet into smaller pieces, each with its own IP header, and reassemble them at the destination. This sounds like an elegant solution, but fragmentation is expensive in practice:

• Fragmented packets must be reassembled at the destination before they can be processed. This consumes CPU and memory on the receiving host.
• If any fragment is lost, the entire original packet must be retransmitted — even if 99% of it arrived successfully.
• Many firewalls and security appliances block IP fragments because fragmentation can be used to bypass firewall rules.
• IPv6 does not allow routers to fragment packets at all. If an IPv6 packet exceeds the link MTU, the router drops it and sends an ICMPv6 Packet Too Big message back to the source.

For these reasons, the preferred approach is Path MTU Discovery — letting the source learn the path MTU and send packets small enough to avoid fragmentation entirely.

Path MTU Discovery (PMTUD)

Path MTU Discovery works by setting the Don't Fragment (DF) bit in the IP header of every packet. When a router receives a packet with the DF bit set and the packet is larger than the outgoing link MTU, the router drops the packet and sends an ICMP Type 3, Code 4 (Fragmentation Needed) message back to the source, including the MTU of the link that could not forward the packet.

The source receives this ICMP message, reduces its packet size accordingly, and retransmits. Over a few exchanges, the source learns the minimum MTU along the entire path and sizes all subsequent packets to fit.

The problem: many networks block ICMP. If the Fragmentation Needed message is filtered by a firewall somewhere between the router and the source, the source never learns about the MTU constraint. It keeps sending large packets with the DF bit set, the router keeps dropping them silently, and the connection appears to hang or transfer only small amounts of data. This is called PMTUD black hole.

MTU and VPN Tunnels

VPN tunnels are the most common source of MTU problems. When you encapsulate a packet inside a VPN tunnel, the encapsulation adds overhead:

• IPSec ESP in tunnel mode: adds approximately 50–90 bytes depending on cipher and authentication algorithm
• OpenVPN (UDP mode): adds approximately 50–80 bytes
• WireGuard: adds approximately 60 bytes
• GRE tunnel: adds 24 bytes

If your physical interface MTU is 1500 bytes and your VPN adds 80 bytes of overhead, the maximum payload that can fit through the tunnel without fragmentation is approximately 1420 bytes. If your VPN tunnel MTU is not set correctly to account for this overhead, every packet above 1420 bytes either gets fragmented or dropped (if DF bit is set).

The correct fix is to set the VPN interface MTU to physical MTU - tunnel overhead. For WireGuard, this is typically 1420. For OpenVPN, 1460 or lower depending on configuration. For IPSec, calculate based on the specific cipher suite in use.

TCP MSS Clamping

For TCP connections specifically, there is another mechanism to handle MTU mismatches: MSS (Maximum Segment Size) clamping. The TCP MSS is negotiated during the TCP handshake and tells the remote end the maximum TCP segment size it should send. MSS relates to MTU as: MSS = MTU - IP header (20) - TCP header (20). For a 1500-byte MTU, MSS is 1460 bytes.

On routers and firewalls, MSS clamping uses ip tcp adjust-mss (Cisco) or iptables -t mangle --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu (Linux) to automatically reduce the MSS in TCP SYN packets to fit the local MTU. This prevents large TCP segments from being sent into tunnels without needing to change any MTU settings on end hosts.

Jumbo Frames

In data center and high-performance computing environments, administrators sometimes configure jumbo frames — MTU values larger than 1500, typically 9000 bytes (called a 9K or 9000-byte jumbo frame). The advantages:

• Lower CPU overhead per byte transferred (fewer packets, fewer interrupt requests)
• Higher throughput for bulk data transfers (storage replication, database backups, NFS)
• Reduced switch forwarding decisions per byte

The critical requirement: jumbo frames only work when every device on the path supports them. A single device in the path with a 1500-byte MTU will cause fragmentation or drops. Jumbo frames are typically used for specific server-to-server paths (SANs, inter-datacenter links) that are entirely under the administrator's control — never on paths that include internet hops.

MTU Values by Network Type

How to Find Your Path MTU

On Linux, use ping with the Don't Fragment flag and incrementally test sizes:

ping -M do -s 1400 -c 4 8.8.8.8

If successful, increase the size. If you get "Message too long" or no response, decrease. The largest size that works is your path MTU minus 28 bytes (8 bytes ICMP header + 20 bytes IP header). Start at 1472 (1500 - 28) and work down in increments of 10.

On Windows: ping -f -l 1472 8.8.8.8

For VPN interfaces, test against the remote endpoint specifically to include the tunnel overhead in the measurement.

Common Misconceptions About MTU

Misconception 1: Lowering MTU always fixes slow transfers

Lowering MTU below the path MTU trades fragmentation problems for higher overhead. A 1300-byte MTU on a path that supports 1500 bytes means every packet carries 13% more header overhead than necessary. Only lower MTU to what the path actually requires.

Misconception 2: MTU and bandwidth are related

MTU affects efficiency and latency but has minimal impact on raw throughput on modern high-speed links. The overhead difference between 1500 and 1460-byte packets is approximately 2.7% — noticeable in benchmarks, irrelevant in most practical scenarios. MTU problems cause connection failures, not just slowdowns.

Misconception 3: If ping works, MTU is fine

Default ping uses small packets (56 bytes payload by default) that are well below any MTU limit. A ping succeeding does not mean large packets can traverse the same path. Always test MTU with large packet sizes explicitly, especially when troubleshooting VPN or tunnel connections.

Misconception 4: The router handles fragmentation so MTU doesn't matter

IPv6 routers do not fragment packets at all. On IPv4, fragmentation is costly and blocked by many firewalls. Many modern stacks set the DF bit on all packets expecting PMTUD to work. When PMTUD is blocked by ICMP filtering, fragmentation does not happen and packets are silently dropped instead.

Pro Tips for MTU Troubleshooting

• When a VPN connection works for small data but fails for large transfers (web pages load partially, SSH sessions stall after a few KB), suspect MTU immediately. Check the VPN interface MTU with ip link show and compare to the physical interface MTU minus tunnel overhead.
• Use tcpdump to capture traffic and look for ICMP Type 3, Code 4 messages. Their presence confirms a PMTUD black hole — a router is dropping packets and sending Fragmentation Needed messages, but something is filtering them before they reach the source.
• When deploying jumbo frames in a data center, verify support at every layer: NIC firmware, switch ports, and physical cables. One device with auto-negotiated 1500-byte MTU silently breaks jumbo frame performance for the entire path.
• On Linux, ip route get 8.8.8.8 shows the route and can include MTU information if PMTUD has cached a path MTU for that destination.
• For WireGuard specifically, set MTU = 1420 in the Interface section of the WireGuard configuration file. This is the most reliable default that works across the majority of ISP connections without needing per-path tuning.
• MSS clamping is the most practical fix when you cannot control the MTU on all devices in a path — add it at the router connecting to any tunnel or WAN link where MTU problems exist.

Test your connection's current IP and network path to diagnose MTU and routing issues