IPsec Tunnel MTU Calculator for MSS Clamp

August 23, 2026

IPsec Tunnel MTU Calculator

Calculate ESP tunnel overhead, safe inner MTU, TCP MSS clamp, and payload efficiency for route-based or policy-based VPN links.

🧭Real IPsec tunnel presets
⚙Tunnel inputs
Result display
Used for the recommendation text and comparison grid.
Outer packet ceiling before any optional deductions below.
Use the smallest proven DF ping payload plus IP/ICMP headers.
The public or WAN-side packet family.
Used for MSS clamp and payload efficiency.
Padding is calculated from this suite's block alignment.
NAT-T adds the UDP header to every ESP data packet.
Most home IPsec tunnels use ESP authentication instead of AH.
Use 1 for 802.1Q or 2 for QinQ if the service does not supply baby giants.
Each label is 4 bytes when label overhead eats into customer MTU.
Choose GRE/VXLAN only when that header sits inside the protected payload.
Common home lab value: 8 to 20 bytes for path variance.
Add 12 bytes for timestamps if you want a stricter clamp.
Applies to the MSS recommendation, not the physical tunnel MTU.
Changes the final note about MSS, fragmentation, and PMTUD.
Used to estimate payload throughput after per-packet overhead.
Used for a second efficiency check at your workload size.

IPsec MTU result

Safe tunnel MTU
0
inner bytes
Path MTU minus IPsec overhead and padding.
TCP MSS clamp
0
bytes
Tunnel MTU minus inner IP and TCP headers.
IPsec overhead
0
bytes per full packet
Outer IP + ESP + IV + trailer + ICV + NAT-T + AH.
Payload efficiency
0%
full-size packet payload share
Inner MTU divided by outer packet size.
📊Current scenario quick metrics
1500 B
Outer MTU budget
Smallest path value after service deductions.
0 B
ESP padding
Calculated from suite alignment at the selected MTU.
0 Mbps
Payload rate
Estimated useful payload at the configured WAN rate.
0 B
Headroom
Unused bytes after the recommended full packet size.
🧱ESP transform reference table
Transform suite ESP IV or nonce ICV or tag Padding alignment Typical tunnel overhead on IPv4
AES-GCM-128 or AES-GCM-2568 bytes explicit IV16 bytes4 byte alignment54 to 57 bytes before NAT-T
AES-CBC with HMAC-SHA1-9616 bytes IV12 bytes16 byte block58 to 73 bytes before NAT-T
AES-CBC with HMAC-SHA256-12816 bytes IV16 bytes16 byte block62 to 77 bytes before NAT-T
ChaCha20-Poly13058 bytes nonce16 bytes4 byte alignment54 to 57 bytes before NAT-T
3DES-CBC with HMAC-SHA1-968 bytes IV12 bytes8 byte block50 to 57 bytes before NAT-T
🖧Access MTU and service overhead table
Access type Usual IP MTU Why it changes IPsec planning note
Standard Ethernet WAN1500 bytesNo customer PPPoE overheadAES-GCM tunnel MTU often lands near 1426 bytes.
PPPoE broadband1492 bytes8 byte PPPoE and PPP headerClamp MSS lower or enable MSS adjust on the firewall.
Cellular or CGNAT1420 to 1460 bytesCarrier tunnels and middleboxesMeasure PMTU because advertised values vary by carrier.
MPLS or Metro-E1500 or baby giantLabels may need extra frame roomAsk whether label overhead is outside the customer MTU.
Jumbo lab backbone9000 bytesSwitch and NIC jumbo supportVerify every hop, including virtual switches and firewalls.
📝MSS clamp reference table
Inner traffic IP header TCP base header Common formula When to reduce further
IPv4 TCP20 bytes20 bytesMSS = tunnel MTU - 40TCP timestamps, tunnels inside tunnels, broken PMTUD.
IPv6 TCP40 bytes20 bytesMSS = tunnel MTU - 60Extension headers or low cellular path MTU.
GRE inside IPsec20 or 40 bytes20 bytesSubtract GRE before MSSRoute-based GRE designs over broadband.
Storage replication20 or 40 bytes20 bytesUse exact MTU, then testLarge sequential streams reveal black-hole MTU faster.
🛠Equipment and protocol comparison grid
Platform or design Common IPsec mode MSS control MTU planning behavior Best use in home lab
pfSense or OPNsenseRoute-based VTI or policyInterface MSS clampStrong for PPPoE and NAT-T edge casesFirewall-to-firewall site tunnel
Linux strongSwanXFRM or VTIiptables or nft TCPMSSFlexible, but you must set MTU routes cleanlyLab routers, containers, and cloud nodes
MikroTik RouterOSPolicy or IPsec profileMangle change-mssOften needs explicit clamp on PPPoE linksLow-power home gateway
Cisco IOS or ASACrypto map or VTIip tcp adjust-mssPredictable if transform and NAT-T are knownBranch router practice lab
Ubiquiti EdgeOS or UniFiSite-to-site IPsecFirewall modify rulesCheck offload and PMTUD behavior per modelHome office VPN to cloud or family site
Cloud VPN gatewayIKEv2 tunnelRoute or VM clampProvider MTU may be lower than EthernetAWS, Azure, GCP, or VPS lab tunnel
GRE over IPsecGRE payload protected by ESPClamp on GRE interfaceSubtract GRE before ESP and MSSDynamic routing across IPsec
ESP with NAT-TUDP 4500 encapsulated ESPClamp at both peersAdd 8 bytes for UDP on every data packetBroadband behind ISP router or CGNAT
📈Common project sizes table
Scenario Outer path Transform Typical safe MTU Typical MSS clamp
Small home lab over fiber1500 IPv4AES-GCM1426 bytes1386 bytes
PPPoE FTTH firewall pair1492 IPv4AES-GCM NAT-T1418 bytes1378 bytes
IPv6 underlay branch1500 IPv6AES-GCM1406 bytes1366 bytes
LTE failover tunnel1420 IPv4AES-GCM NAT-T1338 bytes1298 bytes
Jumbo lab backbone9000 IPv4AES-CBC8918 bytes8878 bytes
💡Planning tips
MTU tip: If TCP stalls but pings work, test with the Don't Fragment bit and packet sizes near the calculated outer budget. Black-hole PMTUD usually appears only on larger flows.
MSS tip: Apply the clamp where SYN packets enter the tunnel. For bidirectional site-to-site VPNs, that normally means both firewall LAN or tunnel interfaces.

Sometimes you try to load a website only for it to fail halfway through. Your connection reaches some kind of invisible wall; ping works, SSH connects just fine, but big downloads gets stuck. It’s rarely because of bandwidth. In nearly all cases, it’s MTU.

There is mismatch between the size of packets your firewall believes it can send and how much the encrypted tunnel will actualy transport. The invisible baggage: IPsec encrypts your data using ESP header. It also adds padding, an IV, authentication tag and more. NAT traversal? Add yet another UDP header to the mix. This overhead consume some of the space available for your payloads.

Why Your VPN Gets Stuck and How to Fix It

A tunnel MTU that’s too large results in the outer packet being larger than the underlying internet connection’s path MTU. The end result is either fragmentation (no good) or a silent drop if DF is enabled on the packet.

Plug in your path constraints and transform suite and the above calculator does math for you. It spares you from the usual trial and error that affects most new VPN setups.

Common sense says “start with 1500” (the typical Ethernet MTU). Okay, sure, in the world of pure IP, fine. But throw IPsec into the mix and all bets are off. For example: if you use the super-efficient cipher AES-GCM, then there’s a mandatory authentication tag plus an explicit IV. That’s another 54 or so bytes of overhead, before you factor in the outer IPv4 header.

And then, if your home router do NAT, you need to tack on another 8 bytes for the UDP 4500 encapsulation. Tiny! But it’s what separates a big packet being sent into the black hole from a big packet getting through intact. To clarify this, here’s a chart from the page that lays it out for typical use cases.

Here we have a PPPoE link whose baseline MTU is 1492, so every byte matters. You’re tempted to set the tunnel MTU to 1500 and let path MTU discovery take care of it. That should of worked in theory. In reality, it often fails.

Many middleboxes will drop ICMP fragmentation-needed messages along the way. If your hosts never recieve these signals, they’ll continue to send giant frames which is then silently dropped. The connection appears to have packet loss. What it actualy has is a sizing problem.

Enter the TCP MSS clamp (your best friend). MSS = Maximum Segment Size. So the MSS will tell the other side how large a segment you can receive over TCP. When clamped on the tunnel interface, the MSS forces the endpoints to agree on a smaller size from the very beginning during their initial hand shake. No more oversized packets even enter the tunnel. It is a proactive fix, not a reactive fix.

The calculator gives you a safe clamp value which takes into account your chosen path MTU, transform, and the inner TCP/IP header. Generally speaking you want to set this on both ends of the tunnel. This is especially important if you’re using the link for site-to-site traffic, with traffic flowing in both directions.

Beyond security strength, the choice of transform suite also has an impact on overhead. For example, older suites such as AES-CBC with HMAC-SHA1 needs to perform a separate integrity check. That involves additional bytes in the trailer. More moddern AEAD suites (e.g., AES-GCM or ChaCha20-Poly1305) does both encryption and authentication. As such they maintain tighter overhead. That can matter if you’re on a low-bandwidth link, such as LTE or a congested broadband connection. Each byte of overhead is one less byte of actual data.

Consider what kind of traffic you’re shoveling around as well. Email and web surfing will be mostly untroubled by an occasional MTU hiccup since the segment sizes are small by nature. VoIP, database replication and large file transfer isnt resilient. They scream “MTU problem!” at the first opportunity.

And if you’re doing storage traffic, maybe you want jumbo frames. This means you must check that each hop can handle the bigger packet. This includes cloud gateways and virtual switches.

How do you configure your IPsec tunnel? At its heart, selecting a strong cipher isnt merely about cipher strength. You need to know the underlying protocol and physical layer below it. Ping your route with the “Don’t Fragment” bit set to measure your path MTU. Use this tool to determine your safe limits. Clamp your MSS accordingly. Once you size things properly, that invisible wall goes away. Your data flows freely, as if it weren’t encrypted at all.

IPsec Tunnel MTU Calculator for MSS Clamp

Related posts

Leave a Comment