MTU / MSS Calculator — PPPoE, MAP-E, IPsec, WireGuard overhead
Stack PPPoE, MAP-E/DS-Lite, GRE, WireGuard, VXLAN and IPsec (with real ESP padding) to get the effective MTU and TCP MSS, plus Cisco, YAMAHA RTX and Linux config and a DF ping to verify.
🔒 Runs entirely in your browser. Your input and output are never sent to a server or stored — fully private.
Breakdown
Configuration
Verify with a DF ping
Payload = MTU − 28 (IPv4 20 + ICMP 8). If this passes and payload + 1 fails, the path MTU is confirmed.
MSS = MTU − 40 for IPv4 (IP 20 + TCP 20) and MTU − 60 for IPv6. Clamp MSS on the device where the MTU shrinks, so TCP never sends a segment that would have to be fragmented.
About this tool
This MTU and MSS calculator works out how big a packet can really be once a link is wrapped in encapsulation. Start from the link MTU, tick the layers your traffic actually passes through — PPPoE, IPv4-over-IPv6 for MAP-E or DS-Lite, GRE, WireGuard, VXLAN, IPsec with NAT-T — and it shows the effective MTU, the TCP MSS for IPv4 and IPv6, a per-layer breakdown, configuration lines for Cisco IOS, YAMAHA RTX and Linux, and the exact DF-bit ping to confirm it on the wire. IPsec is calculated with real ESP padding rather than a rounded guess. Everything runs in your browser.
Frequently asked questions
Why is the FLET'S PPPoE MTU 1454 instead of 1492?
PPPoE itself only costs 8 bytes, so the theoretical figure on an Ethernet link is 1492. NTT East and West nevertheless publish 1454 as the recommended value for FLET'S Hikari, leaving extra headroom that is usually explained by additional overhead inside their access network. In practice, 1454 is the safe choice: it costs a few bytes of efficiency but avoids fragmentation and stalled connections on every path. Select the FLET'S preset and the calculator starts from 1454.
What is MSS clamping and why do I need it?
A TCP connection agrees its maximum segment size at the handshake, based on each end's own interface — which knows nothing about a tunnel further along the path. Path MTU discovery is meant to fix that with ICMP 'fragmentation needed' messages, but many networks drop ICMP, and the result is the classic symptom: small pages load, large downloads and some HTTPS sites hang forever. Clamping rewrites the MSS in passing SYN packets on the router where the MTU shrinks, so oversized segments are never sent at all.
How is IPv6 different?
Three things change. The TCP and IP headers are 20 bytes larger, so MSS is MTU − 60 instead of MTU − 40. Routers never fragment IPv6 in transit, so path MTU discovery is not optional — blocking ICMPv6 'packet too big' breaks connections outright. And every IPv6 link must carry at least 1280 bytes, which is why the Cisco example never sets an IPv6 MTU below that. In Japan, MAP-E and DS-Lite carry your IPv4 inside IPv6, which is where the familiar 1460 comes from.
Why isn't IPsec overhead a fixed number?
Because ESP pads the payload so that it, plus a two-byte trailer, fills whole cipher blocks. With AES-CBC the block is 16 bytes, so depending on the packet size the padding is anywhere from 0 to 15 bytes, on top of a 16-byte IV and the authentication tag. AES-GCM only aligns to 4 bytes and uses an 8-byte IV, so it wastes less. That is why quoted figures vary between sources; this tool computes the largest inner packet that actually fits, and NAT-T adds a further 8-byte UDP header outside the ESP.
Is anything sent to a server?
No. The calculation and the configuration snippets are generated by JavaScript in your browser, so nothing about your network design leaves your machine, and the tool keeps working offline once the page has loaded. The ping commands are for you to run yourself; this page does not send any probes.