IPsec Tunnel
Calculate IPsec tunnel overhead and effective throughput for encrypted traffic.
About IPsec Tunnel
IPsec overhead depends on both the protocol and mode chosen. ESP (Encapsulating Security Payload) adds a header, trailer, and authentication data (roughly 22 bytes fixed) plus variable padding to align the payload to the encryption cipher's block size. AH (Authentication Header) provides integrity/authentication without encryption, adding a fixed ~24 bytes with no padding needed since there's no block cipher. Tunnel mode wraps the entire original IP packet with a new outer IP header (adding 20 bytes for IPv4), enabling site-to-site VPNs where the original source/destination stay hidden — while transport mode protects only the payload and reuses the original IP header, adding less overhead but only working end-to-end between the two IPsec peers themselves.
Formula
Total overhead
overhead = protocol_fixed + cipher_padding (ESP only) + 20 (tunnel mode outer IP)
- O_{proto}
- 22 bytes for ESP, 24 bytes for AH
Worked example
With the default values below, IPsec Tunnel returns Effective MTU of 1,450. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Physical (Underlay) MTUminimum 576 bytes
- 1,500 bytes
- IPsec Protocolone of ESP (Encapsulating Security Payload), AH (Authentication Header)
- ESP (Encapsulating Security Payload)
- Modeone of Tunnel Mode, Transport Mode
- Tunnel Mode
- Average Block Cipher Paddingminimum 0 bytes
- 8 bytes
Results
- Effective MTU
- 1,450 bytes
- Total IPsec Overhead
- 50 bytes
- Protocol Fixed Overhead (header + trailer)
- 22 bytes
- Tunnel Mode Outer IP Header
- 20 bytes
Step by step
- 1Values used
- 2Total overhead
- 3Effective MTU= 1,450 bytes
- 4Total IPsec Overhead= 50 bytes
- 5Protocol Fixed Overhead (header + trailer)= 22 bytes
- 6Tunnel Mode Outer IP Header= 20 bytes
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to whole numbers, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why does ESP need padding but AH doesn't?
ESP encrypts the payload using a block cipher (like AES), which requires the plaintext to be padded to a multiple of the cipher's block size (16 bytes for AES) before encryption — AH only provides authentication/integrity checking without any encryption, so there's no block cipher alignment requirement and no padding needed.
When should I use tunnel mode vs transport mode?
Tunnel mode is used for site-to-site or remote-access VPNs where traffic between two networks needs to be protected end-to-end across an untrusted path, since it encapsulates the entire original packet and hides the original addresses. Transport mode is used when the two communicating hosts are themselves the IPsec endpoints (e.g. host-to-host protection on a trusted LAN), since it has less overhead but doesn't work for routing traffic between different subnets through an intermediate gateway.
Why is AH rarely used compared to ESP in modern deployments?
AH authenticates the entire packet including parts of the outer IP header, which breaks when traffic passes through NAT (since NAT rewrites IP addresses) — ESP with its NAT-Traversal (NAT-T) extension handles this correctly, and ESP also provides both encryption and authentication in one protocol, making it the near-universal choice for modern IPsec VPNs.