What MTU is

MTU (Maximum Transmission Unit) is the largest number of bytes a network link can carry in a single packet. For standard Ethernet that value is 1500 bytes. When a packet exceeds this limit it is either fragmented or, if fragmentation is not permitted (the Don't Fragment bit is set), silently dropped. This limit matters especially on connections that use a VPN, because the tunnelling protocol adds extra headers on top of the original packet and that reduces the usable space.

How a VPN tunnel lowers the MTU

A VPN tunnel adds extra headers to the original packet for encryption, authentication and encapsulation. That overhead determines the number of bytes that has to be subtracted from a 1500-byte Ethernet MTU, and it varies with the protocol, the encryption cipher in use and whether IPv4 or IPv6 is being used. Typical starting values in common use are: roughly 60 bytes for WireGuard, roughly 60 bytes for OpenVPN (UDP), roughly 80 bytes for IKEv2/IPsec and roughly 60 bytes for L2TP/IPsec. These figures are typical starting points, not a firm guarantee; real overhead can vary with the chosen cipher and configuration.

What MSS is and how it relates to MTU

MSS (Maximum Segment Size) is the amount of data TCP can carry in a single segment, calculated with the formula MTU - IP header - TCP header. The IP header is 20 bytes in IPv4 and 40 bytes in IPv6; the TCP header is 20 bytes. If the effective tunnel MTU is 1440 bytes, for example, the MSS is 1400 bytes over IPv4 and 1380 bytes over IPv6. When a TCP connection is established, both sides announce their own MSS value in the SYN packets; that value failing to reflect the real capacity over the tunnel is the root cause of connection problems.

A worked example of effective MTU and MSS

To put numbers on it: with a standard Ethernet MTU of 1500 bytes and WireGuard's typical overhead of ~60 bytes, the effective MTU over the tunnel comes to roughly 1440 bytes. From that MTU, the MSS for IPv4 works out at 1440 - 40 = 1400 bytes, while for IPv6, whose header is 20 bytes larger, the MSS is 1440 - 60 = 1380 bytes. With a protocol that adds more overhead (~80 bytes), such as IKEv2/IPsec, the same arithmetic gives a different answer: an effective MTU of 1420 and an IPv4 MSS of 1380 bytes. Some local networks and data centre links support MTU values higher than the standard 1500 — up to 9000 bytes, known as jumbo frames; but even when a VPN tunnel runs across such a network, the smallest MTU supported by the far end of the tunnel and by the internet path in between is what applies.

Why Path MTU Discovery fails

Path MTU Discovery (PMTUD) is designed to find the smallest MTU along a connection path automatically: the sender transmits a large packet with the Don't Fragment bit set; if a device along the path cannot carry that packet, it informs the sender with an ICMP Fragmentation Needed message and the sender reduces the packet size. The trouble is that many firewalls block ICMP traffic entirely. With ICMP blocked, the sender never receives the signal to shrink, and large packets disappear silently before reaching their destination — this is known as the "black hole" PMTUD problem. The distinguishing feature of this scenario is that small packets pass without trouble while large packets exceeding the tunnel MTU vanish with no error message at all — which makes the source of the problem hard to identify.

Common symptoms

  • Small ICMP packets such as ping go through without trouble, but large file downloads or uploads stall completely at a certain point.
  • An SSH connection is established and the prompt appears, but the session freezes suddenly on commands that produce long output, such as directory listings or log viewing.
  • HTTPS sites load partially, with the page skeleton and text, but images or large script files never arrive and the browser stays stuck in a loading state.
  • Small emails are delivered without trouble while large attachments time out.

Testing for an MTU problem

Testing the real MTU limit on a connection before guessing at it saves time. On Linux and macOS you can send a ping with the Don't Fragment bit set to check whether a particular packet size passes without fragmentation; if the packet does not get through, the system returns a Frag needed or timeout error. On Windows, a ping can be sent similarly with a flag that prevents fragmentation. Repeating this test with different packet sizes (starting from 1500 and stepping down, for example) finds the largest packet size that passes, and the effective MTU is then calculated backwards from it. When running this test over a VPN tunnel, make sure ICMP traffic is not blocked at intermediate hops; otherwise the result can mislead and the real limit may appear higher than it is.

On Linux, sends an ICMP packet of the given size without allowing fragmentation; if the packet passes, the size is increased to find the limit.

ping -M do -s 1472 10.0.0.1

The fix: MSS clamping

Because PMTUD does not work reliably on networks that block ICMP, the common solution on VPN gateways is MSS clamping: forcibly reducing the MSS value in the SYN packet at the router or firewall level, according to the tunnel's real capacity, while the TCP connection is being established. That way the client and server never even attempt to send a segment larger than the tunnel can carry, and PMTUD's ICMP signal is no longer needed.

Pins the MSS value in SYN packets to the stated tunnel capacity; usually added to the FORWARD chain on the VPN gateway.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

As an alternative, the --clamp-mss-to-pmtu option can be used; instead of a fixed value it adjusts automatically to the current path MTU: iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu.

Common mistakes

  • Lowering the MTU only on the tunnel interface without adding an MSS clamping rule; because TCP on the client side still advertises the old MSS value, the problem persists.
  • Blocking all ICMP traffic on the network firewall with a blanket rule; this renders Path MTU Discovery completely useless and leads to black hole problems.
  • Using the same MSS value for IPv4 and IPv6; because the IPv6 header is 40 bytes, it takes up 20 bytes more than IPv4, and the same value can still cause packets to be dropped over IPv6.
  • Keeping the default 1500 MTU without measuring the real overhead added by the VPN protocol; because different protocols (WireGuard, OpenVPN, IKEv2/IPsec, L2TP/IPsec) add different amounts of header, one fixed value does not give the right answer in every configuration.

Instead of calculating the effective tunnel MTU and the corresponding MSS values by hand, you can enter your base MTU and your VPN protocol's typical overhead to see the recommended values and a ready-made iptables command.