MTU / MSS Calculator

Calculate the effective MTU and correct TCP MSS for any stack of encapsulations, so tunnelled traffic stops hanging on large packets.

Calculator ISP Toolkit Runs in your browser
Try:

Result

Effective MTU
1492 bytes
TCP MSS
1452 bytes
Total encapsulation overhead
8 bytes
Ping payload to test this MTU
1464 bytes
with DF set
Efficiency
96.8%
payload as a share of base MTU

Overhead breakdown

ElementBytes
Base MTU1500
PPPoE-8
Plain Ethernet-0
Effective MTU1492
IPv4 header-20
TCP header-20
TCP MSS1452
MikroTik
# MikroTik RouterOS - clamp MSS on the tunnel/PPPoE path
/ip firewall mangle
add chain=forward action=change-mss new-mss=1452 protocol=tcp tcp-flags=syn passthrough=yes comment="Netvorx MSS clamp"

# or clamp to path MTU automatically
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
Cisco IOS
interface Tunnel0
 ip mtu 1492
 ip tcp adjust-mss 1452
Juniper Junos
set interfaces gr-0/0/0 unit 0 family inet mtu 1492
set security flow tcp-mss all-tcp mss 1452
Linux
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
# or
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Why clamp instead of relying on PMTUD
Clamping MSS on the SYN is the reliable fix because it does not depend on ICMP surviving the path. Path MTU discovery is the correct mechanism, but firewalls that drop ICMP "fragmentation needed" create black holes where large packets vanish and small ones work - the classic "web pages load but downloads hang" symptom.

About MTU / MSS Calculator

Every encapsulation steals bytes from the payload. Get the arithmetic wrong and you get the worst kind of fault: pings work, SSH works, and large transfers hang forever. This calculates the effective MTU and the MSS to clamp for any stack of encapsulations.

Diagnosing a PMTU black hole

The signature is unmistakable once you know it: small requests succeed, large ones hang. SSH connects and then freezes on a verbose command, a web page returns headers but never finishes, a VPN passes ping but not file transfers. The cause is a device on the path that drops oversized packets without returning ICMP type 3 code 4, so the sender never learns to reduce its segment size. Confirm with ping -M do at descending sizes, then fix it by clamping MSS at the tunnel edge rather than hoping ICMP starts working.

Common overheads

PPPoE costs 8 bytes, giving the familiar 1492. A VLAN tag costs 4, QinQ 8. GRE is 24, WireGuard about 60, and IPsec ESP in tunnel mode can reach 73 bytes worst case depending on cipher and padding. Stacking them compounds: IPsec over PPPoE leaves under 1420 bytes, and any device assuming 1500 in that path will black-hole large packets.

Common use cases

  • Fixing "some websites do not load" complaints on a PPPoE or tunnelled service.
  • Sizing tunnel interface MTU before deploying a VPN.
  • Setting MSS clamping on a BNG for subscriber traffic.

Edge cases and gotchas

  • IPsec overhead varies with cipher, mode and padding - use the worst case and leave margin.
  • MSS clamping only helps TCP. UDP-based protocols such as QUIC need correct PMTUD or their own probing.

Frequently asked questions

Why is PPPoE MTU 1492?
1500 minus the 8-byte PPPoE header: 6 bytes of PPPoE plus 2 bytes of PPP protocol field.
Should I lower the client MTU instead?
Clamping MSS at the router is far more reliable - it fixes every client without touching them, and it survives clients that ignore PMTUD entirely.