What this does
Computes a recommended VPN interface MTU and TCP MSS clamp value from your base interface MTU, VPN protocol, and a few transport details — the standard fix for "the VPN connects fine but large transfers hang", a classic symptom of an MTU set too high for what the tunnel can actually carry. Entirely in your browser.
Where the numbers come from
Every layer a packet passes through adds its own header: the outer IP header (20 bytes for IPv4, 40 for IPv6), the outer transport header (8 for UDP, 20 for TCP), and the VPN protocol's own encapsulation. WireGuard's is fixed at exactly 32 bytes by its protocol specification; OpenVPN's and IPsec's vary by cipher, so this tool uses representative values for AEAD ciphers (like AES-GCM) versus older CBC+HMAC combinations, labeled as estimates rather than presented as exact.
FAQ
Why is WireGuard's overhead exact but OpenVPN's and IPsec's labeled "estimated"?
WireGuard's data packet format is fixed by its protocol specification — every transport data message adds exactly the same 32-byte header and authentication tag, regardless of cipher choice (there's only one). OpenVPN and IPsec both support multiple ciphers and framing options, and the exact per-packet overhead varies with the specific cipher and padding — the figures here use commonly-cited representative values for each cipher family, not a value pulled from your specific configuration.
Why does WireGuard's IPv6 calculation land on exactly 1420?
That's not a coincidence — 1420 is WireGuard's own documented default MTU, chosen conservatively so a single default works even when the outer transport ends up being IPv6 (a larger 40-byte header instead of IPv4's 20). If you know your outer transport is always IPv4, you can safely use the larger 1440 this calculator computes for that case instead.
What does the TCP MSS clamp actually do?
It tells intermediate devices (often the VPN gateway itself, via iptables' TCPMSS target or an equivalent) to rewrite the maximum segment size a TCP connection announces during its handshake, so its packets fit inside the tunnel's actual MTU without needing IP fragmentation. It only affects TCP; UDP and other protocols still need to handle path MTU on their own.
Why does PPPoE matter here?
PPPoE (common on DSL connections) adds its own 8-byte encapsulation header between the Ethernet frame and the IP packet, on top of whatever the VPN itself adds — a connection already close to the edge on plain Ethernet can drop below a usable MTU once PPPoE's overhead is added on top of the VPN's.
What actually goes wrong if the MTU is set too high?
Packets larger than the path's actual MTU either get fragmented (extra overhead, and fragile if any device along the path drops fragments or blocks the ICMP messages that make Path MTU Discovery work) or silently dropped entirely — the classic symptom is a VPN that connects fine and browses small pages fine, but hangs specifically on larger transfers or an SSH session that freezes as soon as you do anything beyond simple text.
Try it yourself
For the full picture of how VPN fragmentation problems show up and get diagnosed, see VPN MTU and Fragmentation Explained. Setting up the tunnel itself? WireGuard Config Validator and OpenVPN Config Auditor check the config before you deploy it.