This MTU and MSS calculator works out the largest packet that fits through a tunnel and the TCP MSS to clamp to, so VPN users stop seeing pages that hang, stalled downloads and SSH sessions that freeze. It runs entirely in your browser: nothing you type is sent to our server.
Loading the tool… It runs in your browser and needs JavaScript.
Table of Contents
Overhead per tunnel type
| Tunnel | Overhead (IPv4 outer) | MTU on a 1500 link |
|---|---|---|
| PPPoE | 8 | 1492 |
| GRE | 24 | 1476 |
| IP-in-IP / 6in4 | 20 | 1480 |
| WireGuard | 60 (80 with IPv6 outer) | 1440 (1420) |
| VXLAN | 50 | 1450 |
| IPsec ESP, AES-GCM | 54 with padding | 1446 |
| IPsec ESP, AES-CBC + SHA1 | up to 62 with padding | 1438 |
ESP pads the payload to the cipher block size, so its overhead depends on the packet size. The calculator finds the largest packet that still fits instead of using a fixed number.
MSS calculator: what to clamp
TCP MSS = MTU − 40 for IPv4 (20 IP + 20 TCP) and MTU − 60 for IPv6. Clamping the MSS on the tunnel router makes TCP sessions use segments that fit, even when ICMP “fragmentation needed” messages are blocked somewhere (the usual cause of MTU black holes).
Test it
On Linux, ping -M do -s SIZE sends a packet that may not be fragmented: the largest SIZE that works plus 28 is your path MTU. See also VPN MTU and fragmentation fixes.
Using the MSS calculator for a tunnel
- Start from the MTU of the underlying link: 1500 on most Ethernet and internet links, 1492 on PPPoE.
- Choose the tunnel type. The calculator subtracts its overhead; for IPsec it includes the ESP padding, so the result is lower than a simple sum of header sizes.
- Set the tunnel interface MTU to the result and clamp TCP MSS to the MTU minus 40 bytes for IPv4, or minus 60 bytes for IPv6.
- Confirm with a ping that forbids fragmentation, using a payload of MTU minus 28 bytes:
ping -M do -s SIZE hoston Linux orping -f -l SIZE hoston Windows.
Common mistakes:
- Clamping MSS in one direction only: TCP sessions started from the other side still stall.
- Blocking ICMP “fragmentation needed” (type 3, code 4) or ICMPv6 “packet too big”: path MTU discovery stops working and large transfers hang.
- Reusing IPv4 numbers for IPv6: the IPv6 header is 20 bytes larger.
Related tools and guides: VPN MTU and fragmentation guide, site-to-site WireGuard, ping test, TCP ping.
How we checked it
On 11-12 October 2026 we checked the results against the well-known values for PPPoE (1492/1452), GRE (1476), WireGuard (1440 IPv4, 1420 IPv6), VXLAN (1450) and IPsec ESP with AES-CBC-SHA1 (1438) and AES-GCM (1446).
Background on tunnel MTU problems: RFC 4459 (MTU and fragmentation issues with in-the-network tunneling).
Frequently asked questions
What MTU should I use for WireGuard?
1420 is safe for any outer IP version (1500 − 80). If the tunnel only runs over IPv4, 1440 works. Lower it further on PPPoE links (1412).
What is the MSS for an IPsec tunnel?
With AES-CBC and SHA1 on a 1500-byte link, the tunnel MTU is 1438, so clamp TCP MSS to 1398. With AES-GCM, 1446 and 1406.
Should I clamp MSS or lower the MTU?
Do both on tunnels: set the tunnel MTU so the router knows the real size, and clamp MSS so TCP never needs fragmentation.