Skip to content

MTU and MSS calculator

Do some pages fail to load, or large transfers stall, after a VPN or tunnel? Enter the physical MTU and the encapsulation layers to see the inner MTU, the TCP MSS, ping test commands and MSS clamping examples.

Free tool · Infrastructure
bytes

The MTU of the interface the tunnel runs over. Usually 1500 for Ethernet; may be 9000 on networks with jumbo frames.

IP version of the traffic inside the tunnel

For MSS and ping size: the header is 20 bytes for IPv4, 40 bytes for IPv6.

Encapsulation layers

Add them in order from the physical link inwards (e.g. PPPoE first, then WireGuard). Each header size is a typical value; edit it to match your own configuration and verify.

bytes

Typical value; varies with configuration, verify it.

Results

Inner tunnel MTU
1,440 bytes
TCP MSS
1,400 bytes
MTU 1,440 − 40 (IP + TCP header, options excluded)
Total header
60 bytes
Ping payload (inner path)
1,412 bytes
MTU 1,440 − 28 (IP + ICMP header)

MTU layer by layer

LayerHeaderMTU left
Physical interface—1,500
WireGuard (IPv4 outer)−601,440

Testing with ping

Verify the real path MTU by pinging with the DF (don't fragment) bit set. If the command succeeds, that size passes the path; if it fails, reduce the size and repeat; the largest N that passes + the headers = the path MTU.

Inner tunnel path (for the calculated inner MTU) · Payload size N = 1412 bytes

Windows

ping -f -l 1412 <host>

Linux

ping -M do -s 1412 <host>

Path outside the tunnel (IPv4 underlay, for the physical MTU) · Payload size N = 1472 bytes

Windows

ping -f -l 1472 <host>

Linux

ping -M do -s 1472 <host>

A "Packet needs to be fragmented but DF set" or "message too long" reply means that size does not pass the path.

MSS clamping example lines

Lowering the MSS of TCP SYN packets at the tunnel entry avoids fragmentation and stalls on paths where ICMP is filtered.

Example; adapt it to your environment (verify interface names, chains and direction rules).

Linux (iptables/ip6tables)

ip link set dev <tunnel-interface> mtu 1440
iptables -t mangle -A FORWARD -o <tunnel-interface> -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

MikroTik RouterOS

/ip firewall mangle add chain=forward out-interface=<tunnel-interface> protocol=tcp tcp-flags=syn action=change-mss new-mss=1400 passthrough=yes

Cisco IOS

interface <tunnel-interface>
 ip mtu 1440
 ip tcp adjust-mss 1400

Do not apply to a production router without testing.

Fragmentation and the DF bit

In IPv4, if a packet is larger than the MTU of a link on the path and the DF bit is clear, the router fragments it; if DF is set, it drops the packet and sends an ICMP "Fragmentation Needed" message. In IPv6, routers do not fragment packets: a large packet is dropped and ICMPv6 "Packet Too Big" is returned; only the sender may fragment.

If a firewall blocks these ICMP messages, path MTU discovery (PMTUD) fails and the connection opens with small packets but stalls on large transfers (a "black hole"). The common fix is to lower the MSS on TCP SYN; for UDP and other protocols the tunnel interface's MTU itself must be lowered.

Calculation and assumptions

  • Inner tunnel MTU = physical MTU − Σ encapsulation headers.
  • TCP MSS = MTU − 40 (IPv4: 20 IP + 20 TCP) or MTU − 60 (IPv6: 40 IP + 20 TCP). TCP options (e.g. timestamps) reduce the effective MSS slightly further.
  • Ping payload N = MTU − 28 (IPv4: 20 IP + 8 ICMP) or MTU − 48 (IPv6: 40 IP + 8 ICMP).
  • Typical headers: PPPoE 8, GRE 24, WireGuard IPv4 60 / IPv6 80, VXLAN 50 (IPv4 outer). For IPsec ESP, OpenVPN and L2TP the value varies with configuration; enter it yourself.

The values you enter are processed in your browser; they are not sent to a server and not stored.

This is a preliminary estimate: header sizes are typical values and vary with the cipher suite, NAT-T, options and the outer IP version. Always verify the result with ping and on real traffic; do not apply the example configuration lines without adapting them to your environment.

Shall we design and test your VPN, site-to-site links or cloud network connections together?

Request a meeting

01

How to use

  1. A

    Enter the MTU of the physical interface and choose the IP version of the traffic inside the tunnel.

  2. B

    Add the encapsulation layers from the physical link inwards; edit the typical header sizes to match your configuration, and enter the value yourself for IPsec/OpenVPN/L2TP.

  3. C

    Get the inner MTU and MSS; test the path with the ping commands and adapt the MSS clamping example to your environment if needed.

02

MTU, MSS and tunnel headers

MTU is the largest IP packet an interface can carry in one frame (typically 1500 bytes on Ethernet). A tunnel or VPN wraps every packet in new headers; these take space from the same frame, so the MTU left for packets going through the tunnel is smaller. MSS is the largest amount of data TCP carries in one segment and is found by subtracting the IP and TCP headers from the MTU.

Layers can be stacked (e.g. WireGuard over PPPoE); each lowers the MTU by its own header. The tool adds the encapsulations in order from the physical link inwards and shows the MTU left at every step.

03

Why header sizes are "typical values"

PPPoE (8 bytes), GRE (24 for an IPv4 outer header), WireGuard (60 for IPv4 outer, 80 for IPv6 outer) and VXLAN (50 for IPv4 outer) have a fixed structure and are common values. Even so, the outer IP version, options and extra tags on the surrounding network (e.g. VLAN) can change them; that is why every value stays editable.

For IPsec ESP, OpenVPN and L2TP the header varies over a wide range with the cipher suite, integrity algorithm, padding and options such as NAT traversal (NAT-T). This tool offers no preset for them: enter it from your own configuration or the product documentation.

04

When MSS clamping is needed

A TCP connection fixes its MSS when the ends handshake (SYN) and does not know the MTU of a tunnel in the middle. If path MTU discovery fails (ICMP blocked), the ends send packets that do not fit the tunnel and the connection stalls. Lowering the MSS of SYN packets at the tunnel exit pulls the ends to a suitable size from the start.

Clamping only fixes TCP; for UDP-based protocols the tunnel interface's MTU must be set to a suitable value. The example lines are for common platforms; verify interface names, chains and direction rules for your own environment.

FAQ

Is my input sent anywhere?
No. The calculation runs in code in your browser; values are not sent to any server and are not stored.
What is the difference between MTU and MSS?
MTU is the largest IP packet an interface can carry; MSS is the amount of data TCP carries in one segment. In IPv4 MSS = MTU − 40, in IPv6 MTU − 60 (TCP options excluded).
Which MTU should I use for WireGuard?
With a 1500-byte outer link you get 1440 over IPv4 and 1420 over IPv6 (60 and 80 bytes of headers). In practice 1420 is widely considered safe; still, verify your own path with ping. A narrower link (PPPoE, mobile) may call for a lower value.
Why is there no preset header value for IPsec?
The ESP header and trailer vary with the cipher suite, padding, whether NAT-T is used and tunnel/transport mode. A wrong preset would mislead; enter it from your own configuration or find it by testing with ping.
Why is the -l / -s value in the ping command MTU − 28?
Ping takes the size of the ICMP payload; 20 bytes of IPv4 header and 8 bytes of ICMP header are added. In IPv6 the IP header is 40 bytes, i.e. MTU − 48.
Is MSS clamping enough on its own?
For TCP usually yes, for UDP/ICMP no. Also set the tunnel interface's MTU correctly and do not block ICMP "Fragmentation Needed" / "Packet Too Big" messages needlessly.

Seeing stalls on a VPN or tunnel?

Let us do the design, MTU plan and testing together for site-to-site links, remote access and cloud networks. In a free discovery call we discuss your current state and goals.