GuardX
Get started

Free tool · Tunnels

Tunnel MTU & MSS
stack it, then clamp it.

Stack GRE, IP-in-IP, WireGuard, VXLAN, PPPoE or IPsec on any underlay MTU and get the tunnel MTU, the TCP MSS for IPv4 and IPv6, and the commands to set them. It all runs in your browser.

FreeNo sign-upNothing stored

The MTU of the link the tunnel runs over.

Encapsulation stack

From the link inwards: the first layer sits on the underlay, the last is the tunnel your traffic enters.

  1. GRE24 B
    Outer header for layer 1, GRE

Add a layer

Tunnel MTU
1,476
Overhead
24 bytes
TCP MSS, IPv4
1,436
TCP MSS, IPv6
1,416
Layer breakdown and copy-paste MSS clamping rules

Result

1,476-byte tunnel MTU, 1,436 MSS

Layer by layer

Bytes each layer adds and the MTU left inside it
LayerOuter headerBytesMade ofMTU inside
Underlay–––1,500
1. GREIPv424outer IPv4 header 20 + GRE header 41,476

TCP MSS = tunnel MTU − 20 bytes of TCP − 20 bytes of IPv4 (or 40 of IPv6): 1,476 − 40 = 1,436 and 1,476 − 60 = 1,416.

Copy-paste configuration

Set the MTU on each interface and clamp the MSS of TCP handshakes that cross the tunnel, in both directions. Rename the interfaces to match yours; the clamp rules use the innermost one.

Leave empty for gre1.

Linux interface MTU (iproute2)
# set the MTU of each interface, outermost first
ip link set dev gre1 mtu 1476
MSS clamping with iptables
# IPv4: clamp SYN and SYN-ACK in both directions
iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1436
iptables -t mangle -A FORWARD -i gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1436
# IPv6
ip6tables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1416
ip6tables -t mangle -A FORWARD -i gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1416
# or follow the route MTU instead of a fixed value (outgoing direction)
iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
MSS clamping with nftables
table inet mss_clamp {
	chain forward {
		type filter hook forward priority mangle; policy accept;
		oifname "gre1" meta nfproto ipv4 tcp flags syn tcp option maxseg size set 1436
		iifname "gre1" meta nfproto ipv4 tcp flags syn tcp option maxseg size set 1436
		oifname "gre1" meta nfproto ipv6 tcp flags syn tcp option maxseg size set 1416
		iifname "gre1" meta nfproto ipv6 tcp flags syn tcp option maxseg size set 1416
		# or follow the route MTU (outgoing direction):
		# oifname "gre1" tcp flags syn tcp option maxseg size set rt mtu
	}
}
MSS clamping on MikroTik RouterOS
/ip firewall mangle
add chain=forward out-interface=gre1 protocol=tcp tcp-flags=syn tcp-mss=1437-65535 action=change-mss new-mss=1436 passthrough=yes
add chain=forward in-interface=gre1 protocol=tcp tcp-flags=syn tcp-mss=1437-65535 action=change-mss new-mss=1436 passthrough=yes
/ipv6 firewall mangle
add chain=forward out-interface=gre1 protocol=tcp tcp-flags=syn tcp-mss=1417-65535 action=change-mss new-mss=1416 passthrough=yes
add chain=forward in-interface=gre1 protocol=tcp tcp-flags=syn tcp-mss=1417-65535 action=change-mss new-mss=1416 passthrough=yes

02Guide

How to work out a tunnel's MTU and MSS

Subtract every header the tunnel adds from the MTU of the link it runs over. GRE over IPv4 adds 24 bytes, so a 1,500-byte link leaves 1,476 for the tunnel. The TCP maximum segment size (MSS) is that figure minus 40 bytes of IPv4 and TCP header, 1,436, or minus 60 over IPv6, 1,416. Stacked tunnels simply add up: WireGuard over IPv4 with GRE inside leaves 1,500 − 60 − 24 = 1,416.

Enter the underlay MTU or pick a preset, then add layers from the bottom up: the first sits on the physical link, the last is the tunnel your traffic enters. Each layer that brings its own outer IP header can use IPv4 or IPv6. The summary next to the form updates as you go; Calculate shows the breakdown per layer, warnings, and the commands to set the MTU and clamp the MSS.

Everything is computed in your browser. Calculate keeps the stack in the part of the address after the #, which browsers never send to a server, so the link can be shared.

Overhead of each encapsulation

The bytes each layer adds, without IP options or IPv6 extension headers. The tunnel MTU column assumes a 1,500-byte underlay with an IPv4 or IPv6 outer header. Optional GRE fields cost 4 bytes each: the checksum (RFC 2784) and the sequence number (RFC 2890) as well as the key.

Encapsulation overhead in bytes
EncapsulationOver IPv4Over IPv6Tunnel MTU on 1,500Made ofSource
GRE24441,476 / 1,456outer IP header 20 or 40 + GRE header 4RFC 2784
GRE with key28481,472 / 1,452outer IP header 20 or 40 + GRE header 4 + key field 4RFC 2784, RFC 2890
IP-in-IP20401,480 / 1,460outer IP header 20 or 40RFC 2003 (IPv4 outer), RFC 2473 (IPv6 outer)
WireGuard60801,440 / 1,420outer IP header 20 or 40 + UDP header 8 + WireGuard data header 16 + Poly1305 tag 16WireGuard protocol and whitepaper
VXLAN50701,450 / 1,430outer IP header 20 or 40 + UDP header 8 + VXLAN header 8 + inner Ethernet header 14RFC 7348
IPsec ESP57 (estimate)77 (estimate)1,443 / 1,423outer IP header 20 or 40 + ESP header (SPI, sequence number) 8 + AES-GCM IV 8 + padding at worst 3 + pad length and next header 2 + GCM integrity check value 16RFC 4303, RFC 4106 (tunnel mode, AES-GCM)
IPsec ESP with NAT-T65 (estimate)85 (estimate)1,435 / 1,415outer IP header 20 or 40 + UDP header for NAT traversal 8 + ESP header (SPI, sequence number) 8 + AES-GCM IV 8 + padding at worst 3 + pad length and next header 2 + GCM integrity check value 16RFC 4303, RFC 4106, RFC 3948
PPPoE8No outer IP header1,492PPPoE header 6 + PPP protocol field 2RFC 2516

What the MSS clamping rules do

The rules rewrite the MSS option in TCP SYN and SYN-ACK packets that cross the tunnel, in both directions, so each end announces a segment size that fits through it. Why a tunnel without them stalls on large transfers while pings still pass, and why path MTU discovery cannot be relied on to fix it, is covered in GRE vs IPIP and what GRE tunnelling is.

A fixed value works for both directions and does not depend on routes; the iptables TCPMSS target never raises an MSS that is already lower. The automatic forms, iptables' --clamp-mss-to-pmtu and nftables' rt mtu, take the value from the route MTU of the outgoing interface, so they only cover the direction that leaves through the tunnel. A host that terminates the tunnel and sends its replies back through it needs no clamp for its own connections, because the kernel derives the MSS from the route MTU. With direct server return, where replies leave through another interface, clamp the outgoing SYN-ACKs as GRE vs IPIP shows.

Where tunnels meet DDoS protection

GRE is how routed DDoS protection usually reaches a network that is not a website: the provider announces the prefix, filters the traffic and hands the clean packets back through a tunnel, which is why its MTU has to be right from the first day. GuardX GRE transit for that use is coming soon. Websites need no tunnel at all: DDoS protection for HTTP works by pointing DNS at the edge.

If you are deciding between tunnel types, GRE vs IPIP compares the two simplest ones; WireGuard and IPsec add encryption at the price of more overhead, as the table above shows.

Methodology and sources

Every figure is a sum of fixed header sizes taken from the specifications below, without IP options or IPv6 extension headers. The MSS is the tunnel MTU minus a 20-byte TCP header and a 20-byte IPv4 or 40-byte IPv6 header (RFC 6691, RFC 9293); TCP options such as timestamps are taken out of each segment, not out of the MSS. Below 1,280 bytes the IPv6 values are left out, because IPv6 requires at least that MTU on every link (RFC 8200).

The GRE figures were checked against the GRE driver in the Linux kernel, which gives a new GRE device an MTU of 1,476 on a 1,500-byte path, 1,472 with a key and 1,464 with key, checksum and sequence numbers. The iptables and nftables snippets are generated by the same code as the page and were checked with iptables-restore --test and nft -c. The RouterOS rules follow MikroTik's documented mangle syntax; try them on a lab router first.

IPsec ESP has no single overhead. The calculator assumes tunnel mode with AES-GCM: 8 bytes of ESP header, an 8-byte IV, 0 to 3 bytes of padding counted at the worst case, 2 bytes of trailer and a 16-byte ICV, plus the outer IP header and, with NAT traversal, an 8-byte UDP header. CBC ciphers have a 16-byte IV and pad to 16-byte blocks, so AES-CBC with HMAC-SHA1-96 can take up to 73 bytes over IPv4. Results with ESP are marked as estimates.

  • RFC 2784: Generic Routing Encapsulation, the 4-byte GRE header and the optional checksum.
  • RFC 2890: key and sequence number extensions to GRE, 4 bytes each.
  • RFC 2003: IP encapsulation within IP, a 20-byte outer IPv4 header.
  • RFC 2473: generic packet tunnelling in IPv6, the 40-byte outer header and the 8-byte tunnel encapsulation limit option.
  • RFC 8200: IPv6, the 40-byte header and the 1,280-byte minimum link MTU.
  • WireGuard protocol and whitepaper: the 16-byte transport data header and 16-byte Poly1305 tag, carried in UDP.
  • RFC 7348: VXLAN, an 8-byte header in UDP carrying a whole Ethernet frame.
  • RFC 4303: IP Encapsulating Security Payload, the ESP header, padding, trailer and ICV.
  • RFC 4106: AES-GCM in ESP, the 8-byte IV and 16-byte ICV. RFC 3602 and RFC 2404 for AES-CBC and HMAC-SHA1-96.
  • RFC 3948: UDP encapsulation of ESP for NAT traversal, an 8-byte UDP header.
  • RFC 2516: PPPoE, a 6-byte PPPoE header plus the 2-byte PPP protocol field, and the 1,492-byte maximum MRU.
  • RFC 6691: TCP options and maximum segment size, how the MSS relates to the MTU.

03Questions

Questions, answered.

Something else? Talk to us.

1,476 bytes on a standard 1,500-byte path: GRE over IPv4 adds a 20-byte outer IPv4 header and a 4-byte GRE header. With a GRE key it is 1,472, over an IPv6 underlay 1,456. The matching TCP MSS for IPv4 traffic is 40 bytes lower, 1,436 for plain GRE.

1,440 over IPv4 and 1,420 over IPv6 on a 1,500-byte path: WireGuard adds a UDP header, a 16-byte data header and a 16-byte authentication tag to the outer IP header, 60 or 80 bytes in total. Its tools default to 1,420 so that one value works with peers of either address family.

The MTU is the largest IP packet an interface sends, headers included. The MSS is the largest TCP payload in one segment, which each side announces in its SYN: the MTU minus 40 bytes for IPv4 or 60 bytes for IPv6.

A fixed value from this calculator covers both directions and does not depend on routing. Clamping to the path MTU (--clamp-mss-to-pmtu, or rt mtu in nftables) follows the route automatically but only corrects SYNs that leave through the tunnel, so the return direction still needs the tunnel MTU to be right.

PPPoE puts a 6-byte PPPoE header and a 2-byte PPP protocol field inside the 1,500-byte Ethernet payload, and RFC 2516 limits the negotiated MRU to 1,492 bytes. The TCP MSS over a PPPoE link is therefore 1,452 for IPv4 and 1,432 for IPv6.

It depends on the cipher, the integrity check, the mode and NAT traversal. AES-GCM in tunnel mode over IPv4 adds 54 bytes plus up to 3 bytes of padding, and NAT traversal adds an 8-byte UDP header; CBC ciphers can need up to 73 bytes. The calculator uses the AES-GCM worst case and marks the result as an estimate.

04More free tools

Check the rest of the stack.

Subnet calculator

Network, broadcast, host range and netmask for any IPv4 CIDR block, with a /8 to /32 reference table.

IP & ASN lookup

Which network (ASN), organisation and country an IPv4 or IPv6 address belongs to, starting with yours.

DNS lookup

A, AAAA, CNAME, MX, NS, TXT, CAA and SOA records for any domain, straight from public resolvers.

Bandwidth to PPS calculator

Bit rate to packets per second and back for any frame size, with line-rate overhead and a 95th percentile calculator.

Get started

Put a WAF, CDN and unmetered DDoS protection
in front of your site.

Point your DNS at GuardX and traffic is filtered at the edge before it reaches your server. Flat pricing, no surcharge while an attack runs.

Create free accountExplore the WAF