Why isn't WireGuard's overhead exactly the same as OpenVPN's?

WireGuard uses a fixed, modern header format, so its overhead is always exactly 60 bytes over an IPv4 path or 80 bytes over an IPv6 path. OpenVPN supports many ciphers, authentication methods, and transport options, so its overhead genuinely varies, typically 40 to 80 bytes depending on configuration.

Is this calculator the same as testing my actual path MTU?

No. This adds up published, typical overhead values for the encapsulation you select. Your actual path MTU can be smaller if a link along the route has a lower MTU than expected. Confirm with a Do Not Fragment ping test if you are still seeing issues after applying the calculated value.

What is TCP MSS and why does it differ from MTU?

MSS is the largest chunk of TCP payload a segment can carry, not counting IP and TCP headers. It is calculated as MTU minus 40 bytes for IPv4 (20-byte IP header plus 20-byte TCP header) or MTU minus 60 bytes for IPv6, since the IPv6 header is 40 bytes.

MTU Path Calculator – Find Your MTU & MSS Free

MTU Path Calculator

Stack PPPoE, VLAN tagging, and VPN encapsulation on your base MTU to find the right interface MTU and TCP MSS.

What you’re getting: this adds up published, typical overhead values for the layers you select. It is arithmetic, not a live test of your actual path.

WireGuard’s overhead is fixed by the protocol (60 or 80 bytes), so that figure is exact. OpenVPN and IPsec/IKEv2 overhead genuinely varies by cipher and configuration, so those use conservative estimates. If you are still seeing fragmentation after applying the calculated value, confirm with a Do Not Fragment ping test.

Base MTU (your physical connection, usually 1500)

Encapsulation layers (select all that apply)

PPPoE −8 bytes, fixed VLAN tag (802.1Q) −4 bytes, fixed WireGuard, IPv4 outer −60 bytes, fixed WireGuard, IPv6 outer −80 bytes, fixed OpenVPN over UDP −60 bytes, estimated (typically 40–80) IPsec / IKEv2 −80 bytes, estimated (typically 60–100) GRE tunnel −24 bytes, fixed L2TP/IPsec −90 bytes, estimated

MTU Path Calculator

What This Tool Does

Every layer of encapsulation between your device and the internet, PPPoE, a VPN tunnel, a VLAN tag, eats into the 1500-byte budget a standard Ethernet connection starts with. Stack the wrong combination without adjusting your interface MTU and the result is silent packet loss: connections that hang, video calls that freeze, and large downloads that stall while small requests work fine. This tool adds up the overhead for the layers you select and gives you the interface MTU and TCP MSS to configure.

Why the VPN Numbers Aren’t All Equally Precise

WireGuard uses one fixed header format, so its overhead is always exactly 60 bytes over an IPv4 path or 80 bytes over an IPv6 path, no guessing required. OpenVPN and IPsec support many cipher and authentication combinations, so their real overhead varies with configuration, roughly 40 to 80 bytes for OpenVPN and 60 to 100 bytes for IPsec. This tool uses a conservative estimate for those two so the calculated MTU errs toward too small rather than too large, since a slightly undersized MTU wastes a little efficiency while an oversized one causes the fragmentation you are trying to avoid.

Confirming With a Real Test

If you want to confirm the actual path MTU rather than rely on typical values, send a ping with the Do Not Fragment flag set and decrease the size until it stops failing.

Windows: ping -f -l 1472 destination — the -f flag sets Do Not Fragment. Add 28 bytes to the largest working size for the interface MTU.
macOS / Linux: ping -M do -s 1472 destination — add 28 bytes to the largest working size the same way.

Once you have a working ping output to interpret, our Ping and Packet-Loss Interpreter can help make sense of the results.

Related Tools & Guides

For the full concept behind why packet size breaks VPNs and large transfers, see MTU Explained. If you suspect the issue is somewhere else in the path, Traceroute Explained shows where a connection is struggling, and How to Troubleshoot Network Connectivity covers the full diagnostic sequence.