Technical guide

MTU vs MSS Explained: Why VPNs and Tunnels Break Large Packets

By Subnetica · Published August 24, 2026 · Updated August 24, 2026

When small requests work but HTTPS, file transfers, or larger API payloads hang through a VPN, the path may be unable to carry a packet size that endpoints expect. MTU describes an interface or path’s packet limit; MSS is a TCP connection’s advertised payload limit. They solve related but different parts of the problem.

MTU, packet size, and MSS are different numbers

MTU is the largest IP packet an interface or path is intended to carry without fragmentation at that layer. MSS is the largest TCP segment payload an endpoint advertises during the handshake. With common Ethernet assumptions of a 1500-byte IPv4 MTU, a 20-byte IPv4 header, and a 20-byte TCP header, a basic TCP MSS is 1460 bytes. Options make headers larger, and IPv6’s base header is 40 bytes, so state assumptions.

IP packet: 1500=IPv4: 20+TCP: 20+MSS payload: 1460

A 1500-byte IPv4 MTU leaves about 1460 bytes for TCP data when both headers are minimum size.

A tunnel adds an outer header. If encapsulation consumes 60 bytes and the physical path still supports 1500 bytes, the inner packet may need an MTU near 1440. Multiple headers—IPsec over UDP over outer IP, or nested VPN and container tunnels—make overhead mode-dependent. Do not present one universal VPN overhead number.

Why large packets fail first

Path MTU Discovery lets a sender learn that a packet is too large. In IPv4, a router can send ICMP “Fragmentation Needed” when it cannot forward a packet with DF set. In IPv6, routers do not fragment transit packets; they send ICMPv6 “Packet Too Big.” If those messages are filtered, the sender may keep retransmitting a size the path cannot carry: a PMTUD black hole.

IPv4 fragmentation can hide a bad path until fragments are filtered or reassembly fails. The Do not Fragment bit makes the failure visible to PMTUD. IPv6 fragmentation is performed by the source using a Fragment header, not by intermediate routers. TCP MSS clamping avoids oversized TCP data segments by rewriting MSS in SYN packets, but it does not fix arbitrary UDP traffic or identify the tunnel that caused the limit.

Diagnostic flow

small works / large fails↓find maximum size↓inspect MTU/overhead↓check PMTUD/ICMP↓capture↓fix path or MSS

Find the path limit before changing configuration.

Measure instead of guessing

ip link
ip route
ip route get 203.0.113.10

# Linux: -s is ICMP payload; -M do requests DF for IPv4
ping -M do -s 1472 203.0.113.10
tracepath 203.0.113.10

# Observe retransmissions, SYN MSS, DF, and ICMP errors
tcpdump -ni any host 203.0.113.10
ss -ti

For a 1500-byte IPv4 path with minimum headers, an ICMP payload of 1472 plus 28 bytes of IPv4/ICMP headers makes a 1500-byte packet. That is an example, not a universal command value: IPv6, interface headers, encapsulation, and the remote path can change the limit. Reduce the payload until a DF probe succeeds, then compare the result with ip link and each tunnel endpoint.

Read the capture

Look for SYN packets advertising an MSS larger than the inner path can support, repeated TCP retransmissions, ICMP Fragmentation Needed or Packet Too Big messages, and whether the failing packet is inner or outer traffic. A capture at one side of a tunnel may show a packet leaving while the other side shows that the encapsulated packet never arrives.

Common symptoms and durable fixes

Ping works, HTTPS hangs: small ICMP succeeds while TCP data exceeds the effective path MTU or PMTUD feedback is blocked.
SSH opens, file transfer stalls: the handshake and prompts fit, but sustained larger segments trigger the black hole.
Only some websites fail: servers advertise different options, use IPv6, or sit behind paths with different MTUs.
Nested tunnels fail: each encapsulation consumes more space; the inner MTU must account for the full stack.

Prefer fixing the path and allowing required ICMP feedback. If reduced MTU is intentional, configure the tunnel interface accordingly or apply MSS clamping at the correct boundary for TCP. Randomly lowering MTU can hide a symptom while leaving UDP, IPv6, another tunnel, or a misconfigured ICMP filter broken.

Use Subnetica’s troubleshooting curriculum to practice the evidence-first workflow. For a protocol-specific MTU failure, the published OSPF MTU-mismatch lab makes the EXSTART symptom observable. The DNS troubleshooting guide is a useful contrast: a successful IP test can isolate a layer of failure, but never proves the whole application path is healthy.