MTU / MSS calculator (tunnel-overhead aware)

Fragmentation, PMTUD black holes, and MSS clamping

Every link has a maximum transmission unit: the largest packet it will carry. When an IPv4 packet exceeds the MTU of a hop, the router either fragments it (slow, fragile, often dropped by firewalls) or, if the Don't Fragment bit is set, drops it and sends back an ICMP "fragmentation needed" message telling the sender to use smaller packets. IPv6 never fragments in transit: the sender must get it right, guided by the same kind of ICMP feedback. Tunnels make this worse because every layer of encapsulation (VPN header, GRE, PPPoE) eats bytes out of the budget, so a packet that fit on the outer link no longer fits inside the tunnel.

Path MTU discovery depends entirely on those ICMP messages arriving. Many firewalls filter ICMP wholesale, which creates the classic black hole: small packets (the TCP handshake, short requests) pass fine, but the first full-size data packet silently vanishes and is retransmitted forever. The symptom is maddening: the site connects, the page half loads, then hangs. SSH logs in but the session freezes the moment you cat a large file. Nothing is "down", so monitoring stays green while users suffer.

Clamping TCP MSS at the tunnel endpoint sidesteps the problem: the router rewrites the MSS option in TCP SYN packets so both ends agree on segments small enough to traverse the tunnel without ever needing fragmentation or ICMP feedback. Purists object, with some justice, that a router rewriting a transport-layer option is a layering violation, and it only helps TCP (UDP-based protocols like QUIC must still solve MTU themselves). In practice it is the pragmatic fix: one rule on the box you control, instead of begging every network on the path to unfilter ICMP.