{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
OUTER ESP PAYLOAD {{ ipsecSleeveValueLabel }}
IPsec overhead inputs
Use the transport path MTU, such as 1500 for Ethernet or 9000 for a jumbo underlay.
bytes
Common MTU slider {{ underlayMtuRangeLabel }}
Choose the transform closest to the tunnel proposal; custom bytes are available in Advanced.
Pick the tunnel transport family between the VPN peers.
Use the protected payload family for the TCP MSS recommendation.
Keep None when the underlay MTU already accounts for PPPoE, VLAN, GRE, or provider encapsulation.
Adds the 8-byte UDP header used for ESP NAT traversal packets.
Use 0 for exact fit or 8-32 bytes when the path has unknown vendor padding or options.
bytes
Reserve slider {{ safetyReserveRangeLabel }}
Use 0 for classic MSS, or 12 when timestamp/SACK option space must be reserved.
bytes
Option reserve slider {{ tcpOptionsRangeLabel }}
Leave 0 unless the tunnel deliberately pads every packet for traffic-flow confidentiality.
bytes
TFC slider {{ tfcPaddingRangeLabel }}
Keep 0 unless you have a platform-specific encapsulation value to include.
bytes
Path-byte slider {{ additionalOverheadRangeLabel }}
Set the explicit IV or nonce bytes carried in ESP payload data for a custom transform.
bytes
Set the integrity check value or AEAD authentication tag bytes.
bytes
Use 1 for AEAD-style transforms, 4 for alignment-only, or 16 for AES-CBC style padding.
bytes
Metric Value Detail Copy
{{ row.label }} {{ row.value }} {{ row.detail }}
Component Bytes Applies as Note Copy
{{ row.component }} {{ row.bytesLabel }} {{ row.applies }} {{ row.note }}
Check Recommendation Detail Copy
{{ row.check }} {{ row.recommendation }} {{ row.detail }}

        
Customize
Advanced
:

Large packets are often the first packets to expose a VPN sizing mistake. A tunnel may pass small pings, DNS queries, and short web requests while file transfers, database sessions, backups, or TLS handshakes stall because the protected packet no longer fits after IPsec adds its own headers and trailer fields.

IPsec tunnel mode does not merely label an existing packet. It wraps the original IP packet in Encapsulating Security Payload (ESP), then sends that protected packet inside a new outer IP packet between the VPN peers. The outside path still has a maximum transmission unit (MTU), so every byte used by outer IP, ESP, NAT traversal, padding, or access-link encapsulation leaves fewer bytes for the inner packet.

That byte budget matters before a tunnel is deployed and again when an established tunnel changes. A new cipher suite can change IV or tag length. NAT traversal can add UDP encapsulation. A provider handoff may already include PPPoE, VLAN tagging, GRE, or another carrier feature. The same 1500 byte Ethernet starting point can therefore lead to different inner MTU and TCP maximum segment size (MSS) values depending on what is already counted in the path and what must still be reserved.

Packet envelope showing outer IP, ESP overhead, and protected inner packet budget.
Outer headers, ESP bytes, NAT-T, padding, and path extras all reduce the inner packet budget.

The main planning value is the inner MTU, the largest protected IP packet that can travel through the tunnel without exceeding the outside path budget. TCP has a second value, the maximum segment size (MSS), which is the TCP payload size after subtracting the inner IP header, the TCP header, and any option space that must be reserved from that inner MTU.

IPsec sizing terms and practical meaning
Term Practical meaning
Underlay MTU The packet-size limit on the outside path between VPN peers.
Inner MTU The protected IP packet size available after tunnel overhead is reserved.
NAT-T ESP carried in UDP/4500, usually used when native ESP protocol 50 cannot pass cleanly through NAT or firewall policy.
MSS clamp A TCP segment-size limit based on the inner MTU, used to keep TCP from sending oversize segments.

A single fixed "IPsec overhead" number is rarely accurate enough for planning. AES-GCM, AES-CBC with HMAC, ChaCha20-Poly1305, and integrity-only ESP carry different IV, nonce, integrity tag, and padding assumptions. NAT-T adds an 8 byte UDP header to ESP data packets, while PPPoE, VLAN tags, GRE, IP-in-IP, carrier features, or nested tunnels may consume more of the outside budget.

Two common mistakes cause bad tunnel MTU recommendations. One is double-counting bytes that are already reflected in the underlay MTU, such as entering a 1492 byte PPPoE path and also adding PPPoE overhead. The other is treating an MSS clamp as a complete fix. MSS clamping helps TCP, but UDP, QUIC, ICMP, and IPv6 Packet Too Big behavior still depend on path MTU discovery and firewall policy.

IPv6 adds another practical boundary because protected IPv6 traffic normally needs an inner MTU of at least 1280 bytes. A tunnel that leaves less than that may still carry some traffic with special lower-layer adaptation, but it is a warning sign for ordinary site-to-site, remote-access, and cloud VPN planning.

How to Use This Tool:

Start with the outside path, then add only the overhead that is not already included in that path MTU.

  1. Enter Underlay MTU. Use 1500 for a normal Ethernet path, 9000 for a jumbo underlay, or the lower transport MTU when the provider path is already constrained.
  2. Choose the ESP profile that matches the tunnel proposal. Use Custom ESP byte profile only when you know the IV or nonce length, ICV or tag length, and block-alignment requirement.
  3. Select Outer IP version for the transport between VPN peers and Inner IP version for the protected traffic. IPv6 inner traffic needs enough room to clear the 1280 byte minimum.
  4. Set Path extra for bytes such as PPPoE, VLAN, GRE over IPv4, or IP-in-IP over IPv4 only when those bytes are outside the entered underlay MTU.
  5. Turn on Include NAT-T UDP/4500 when ESP data packets are encapsulated in UDP for NAT traversal.
  6. Open Advanced when you need a safety reserve, TCP option reserve, traffic-flow-confidentiality padding, additional path bytes, or custom ESP transform bytes.
  7. Check MTU Ledger first for the recommended inner MTU and TCP MSS clamp. Use Overhead Stack to audit each byte, Clamp Guidance for operational checks, and Profile MTU Ladder when comparing transform choices.

If the result shows Check tunnel assumptions, read the validation messages before applying the numbers. An underlay below 576 bytes, protected IPv6 traffic below 1280 bytes, or overhead that leaves no usable TCP payload budget should be corrected by raising the path budget, removing double-counted extras, reducing reserve bytes, or choosing a lower-overhead profile.

Interpreting Results:

Recommended inner MTU is the largest protected IP packet that fits within the safety-adjusted underlay budget. TCP MSS clamp is smaller because it subtracts the inner IP header, the base TCP header, and any entered TCP option reserve.

On-wire overhead is the modeled tunnel byte cost at the recommended packet size. Total MTU reduction can be larger than that overhead because it includes the safety reserve and any padding headroom left by the largest fitting packet.

  • Fits path means the selected assumptions produce a fitting inner MTU and usable TCP MSS.
  • Review MTU appears when the underlay is below a useful protocol floor, IPv6 inner traffic falls below 1280 bytes, or the selected overhead leaves no usable TCP payload budget.
  • Profile MTU Ladder is useful when a transform change is under discussion, because CBC-style profiles and AEAD profiles can leave different inner MTU and MSS values.
  • Validate the platform proposal before changing production policy. Vendor defaults, ICV truncation, extended sequence-number handling, TFC padding, and nested tunnels can change the real byte count.

Technical Details:

ESP tunnel mode carries the original IP packet as protected payload and adds ESP fields around it. The transmitted ESP header begins with an 8 byte Security Parameters Index and sequence number. The protected payload area may include an explicit IV or nonce, optional traffic-flow-confidentiality padding, ordinary ESP padding, and the mandatory Pad Length and Next Header trailer bytes. Integrity data or an AEAD tag may appear at the end of the ESP packet depending on the transform.

Padding is the reason IPsec MTU arithmetic is not always a simple subtraction. ESP padding must satisfy the selected transform's block alignment and ESP's 4 byte alignment rule for the integrity data. Nearby inner MTU values can therefore need different padding amounts, especially with AES-CBC style transforms.

Formula Core:

The safe inner MTU is the largest candidate whose modeled outer packet is no larger than the available budget.

Mbudget = Munderlay-safety reserve Pouter = Minner+outer IP+NAT-T+path extra+ESP bytes Minner = largest candidate where PouterMbudget TCP MSS = Minner-inner IP header-20-TCP option reserve

With a 1500 byte underlay, IPv4 outer header, IPv4 inner header, AES-GCM with a 16 byte tag, NAT-T enabled, and no path extras or reserve, the overhead at the fitting point is 62 bytes. The largest fitting inner MTU is 1438 bytes, and the TCP MSS clamp is 1398 bytes after subtracting 20 bytes for the inner IPv4 header and 20 bytes for TCP.

IPsec overhead byte components
Component Bytes When it applies
IPv4 outer header 20 Used when the tunnel transport is IPv4.
IPv6 outer header 40 Used when the tunnel transport is IPv6.
NAT-T UDP header 8 Added to ESP data packets when UDP/4500 encapsulation is enabled.
ESP SPI and sequence 8 Fixed ESP header bytes before the protected payload area.
ESP Pad Length and Next Header 2 Mandatory trailer fields after ESP padding.
IV, nonce, ICV, AEAD tag, TFC padding, and alignment padding varies Determined by the ESP profile, optional TFC padding, and the candidate inner MTU.
Built-in ESP profile assumptions
ESP profile IV or nonce ICV or tag Block alignment
AES-GCM with 16-byte tag 8 B 16 B 1 B
AES-GCM with 12-byte tag 8 B 12 B 1 B
AES-CBC with HMAC-SHA1-96 16 B 12 B 16 B
AES-CBC with HMAC-SHA-256-128 16 B 16 B 16 B
ChaCha20-Poly1305 with 16-byte tag 8 B 16 B 1 B
NULL encryption with HMAC-SHA1-96 0 B 12 B 1 B

Safety reserve is not a wire header. It subtracts bytes from the recommended inner MTU as a conservative planning allowance. TCP option reserve works differently: it subtracts from the MSS recommendation after the inner MTU has already been found.

Limitations and Privacy Notes:

The calculation models byte budgets from the visible assumptions. It does not test a live tunnel, inspect negotiated security associations, or observe real packets.

  • Vendor features, nested tunnels, extended sequence-number handling, unusual ICV truncation, and platform-specific encapsulation can require custom byte allowances.
  • IPv6 protected traffic should keep the inner MTU at or above 1280 bytes unless a lower-layer adaptation is deliberately in place.
  • MSS clamping applies to TCP only. PMTUD and ICMP or ICMPv6 error handling still matter for other protocols.
  • The sizing values you enter are used for the page calculation and exports. No tunnel credentials, packet captures, or live VPN traffic are required.

Advanced Tips:

  • Use Path extra only for bytes outside the entered Underlay MTU. If the carrier or access link already reduced the MTU, leave the preset at None and enter the lower underlay value directly.
  • Compare Profile MTU Ladder before changing a transform. AEAD profiles and CBC plus HMAC profiles can differ by tag length, IV length, and padding behavior even when the underlay MTU stays fixed.
  • Reserve TCP options when timestamps, SACK, or other option space must remain available. This changes the TCP MSS clamp without changing the recommended inner MTU.
  • Add TFC padding only when the tunnel deliberately pads every packet for traffic-flow confidentiality. It is not the same as ordinary ESP alignment padding, which is calculated from the selected profile and packet size.
  • Use Additional path bytes for platform-specific encapsulation, nested tunnels, or vendor features that are not represented by the built-in path presets.
  • Export the JSON result when handing values to a network change record so the ESP profile, NAT-T choice, IP versions, path extras, reserve bytes, and warning state are preserved with the MTU recommendation.

Worked Examples:

Common IPv4 NAT-T tunnel. A 1500 byte underlay with IPv4 outer and inner headers, AES-GCM with a 16 byte tag, NAT-T enabled, no path extra, and no reserve produces a 1438 byte recommended inner MTU. The matching TCP MSS clamp is 1398 bytes because the IPv4 inner header and base TCP header consume 40 more bytes.

Broadband path with PPPoE. If the outside path is entered as 1500 bytes and PPPoE is truly outside that budget, adding the PPPoE path extra reserves 8 bytes for access overhead. If the path is already entered as 1492 bytes because PPPoE has already reduced it, adding PPPoE again double-counts the same cost and makes the recommendation too small.

IPv6 payload warning. When the protected traffic is IPv6 and the selected overhead leaves an inner MTU below 1280 bytes, the result warns that the main IPv6 floor is not met. Raise the underlay MTU, remove unnecessary path extras, reduce reserve bytes, or choose a smaller overhead profile before carrying IPv6 through that tunnel.

FAQ:

Why does the NAT-T option add 8 bytes?

ESP data packets carried for NAT traversal use a UDP header on port 4500. The IKE non-ESP marker is part of IKE traffic handling, not part of the ESP data-packet overhead modeled here.

Should I add VLAN, PPPoE, GRE, or IP-in-IP bytes?

Add those bytes only when they are outside the MTU value you entered. If the underlay MTU already reflects the access link or nested tunnel, adding the same preset again makes the estimate too conservative.

Why can changing the inner packet by one byte change padding?

ESP padding must satisfy the transform block size and ESP alignment. A nearby packet size may need a different number of padding bytes before the Pad Length, Next Header, and integrity data fit correctly.

Does MSS clamping replace path MTU discovery?

No. MSS clamping reduces TCP segment size, but PMTUD still matters for UDP, QUIC, ICMP, and any TCP traffic that is not affected by the clamp.

Why compare ESP profiles?

Different transforms carry different IV, nonce, ICV, tag, and alignment costs. Profile comparison shows how much inner MTU and TCP MSS would change if the negotiated transform changed.

Glossary:

ESP
Encapsulating Security Payload, the IPsec format that carries SPI, sequence number, protected payload, padding, trailer fields, and optional integrity data.
ICV
Integrity Check Value, authentication data used by some ESP transforms to verify packet integrity.
Inner MTU
The protected IP packet size available inside the tunnel after overhead is reserved.
NAT-T
NAT traversal, which carries ESP data inside UDP/4500.
PMTUD
Path MTU Discovery, the process hosts use to learn the largest packet size that can cross a path without fragmentation.
TFC padding
Traffic-flow-confidentiality padding, optional ESP padding used to obscure traffic-size patterns.