Estimate ESP and NAT-T overhead, safe tunnel MTU, encrypted WAN capacity, packets per second, and average
throughput per tunnel. Compare the WAN link with the VPN gatewayโs rated encryption capacity using a representative packet size.
Private by design: calculations run entirely in your browser and inputs are not uploaded or stored.
Capacity inputs
Use one-way or aggregate capacity consistently for both WAN and gateway ratings.
Use a measured or vendor rating for comparable cipher, packet size, services, and traffic direction.
Includes the inner IP header. Model multiple packet sizes for mixed workloads.
Tunnel and packet inputs
Additional encapsulation
Advanced algorithm and wire fields
Changing these fields switches the cipher selector to Custom. Alignment includes the encrypted payload, ESP padding, Pad Length, and Next Header, but excludes the IV.
Results
Usable inner throughput-
Capacity bottleneck-
Packet efficiency-
Safe inner MTU-
Packet overhead
ESP header (SPI + sequence):-
ESP IV + trailer + padding + ICV:-
Outer IP + NAT-T + other:-
Total IPsec overhead per packet:-
Outer IP packet size:-
On-wire bytes per packet:-
Overhead share:-
Approximate TCP MSS:-
Capacity at selected reserve
Usable WAN-derived inner throughput:-
Usable gateway crypto throughput:-
Average per active tunnel:-
Packet rate at usable throughput:-
WAN rate consumed:-
WAN utilization-
Gateway utilization-
Target check
Required WAN line rate with reserve:-
Required gateway rating with reserve:-
Enter valid values to calculate.
How to use the IPsec throughput calculator
Enter both constraints: WAN line rate and the gatewayโs rated or measured IPsec throughput.
Reserve operating margin: 20% is a useful planning starting point, but your failover and burst requirements may differ.
Match the tunnel: choose mode, outer IP version, NAT-T state, and the negotiated ESP algorithm.
Model packet size: 1400 bytes approximates large data packets; also test 64โ256-byte packets for voice, DNS, transactional, or acknowledgement-heavy traffic.
Validate: compare the target with usable capacity, then confirm using platform counters, packet captures, and controlled throughput tests.
Formulas and assumptions
ESP padding:(alignment - ((protected payload + 2) mod alignment)) mod alignment
Outer packet:inner IP packet + outer IP when tunnel mode + UDP when NAT-T + ESP header + IV + padding + 2-byte trailer + ICV + custom overhead
For transport mode, the existing IP header remains outside the encrypted ESP payload, so padding is calculated
from the packet after subtracting the selected protected IP header. Ethernet accounting adds a 14-byte header,
4 bytes per VLAN tag, andโwhen selectedโ4-byte FCS plus 8-byte preamble/SFD and 12-byte inter-frame gap.
Rates use decimal network units: 1 Mbps = 1,000,000 bits/s and 1 Gbps = 1,000 Mbps. Capacity reserve is applied
once to both the link-derived goodput and gateway rating. WAN and gateway values must use the same directional
basis. Results model steady-state ESP data, not IKE.
ESP preset byte assumptions
Preset
Explicit IV
Alignment
ICV / tag
Fixed ESP fields before padding
AES-GCM, 16-byte tag
8 B
4 B
16 B
8 B ESP header + 8 B IV + 2 B trailer + 16 B tag
ChaCha20-Poly1305
8 B
4 B
16 B
8 B ESP header + 8 B IV + 2 B trailer + 16 B tag
AES-CBC + HMAC-SHA-256-128
16 B
16 B
16 B
8 B ESP header + 16 B IV + 2 B trailer + 16 B ICV
AES-CBC + HMAC-SHA-1-96
16 B
16 B
12 B
8 B ESP header + 16 B IV + 2 B trailer + 12 B ICV
AES-GCM key size does not change these packet bytes. The presets use minimum required alignment padding and no optional TFC padding.
Standards references
RFC 4303 defines the 8-byte ESP header, trailer, padding, ICV field, and tunnel/transport placement.
RFC 4106 specifies the 8-byte explicit IV for AES-GCM ESP and supports a 16-byte ICV.
RFC 7634 specifies the 8-byte explicit IV, 16-byte tag, and four-byte ESP alignment for ChaCha20-Poly1305.
RFC 3602 specifies AES-CBCโs 16-byte IV and 16-byte block alignment.
RFC 4868 defines the 128-bit truncated authenticator for HMAC-SHA-256-128.
RFC 3948 defines UDP encapsulation of ESP for NAT traversal; the data-plane UDP header adds 8 bytes.
IPsec throughput FAQs
How much overhead does IPsec add?
It varies by packet. For the default 1400-byte inner packet, IPv4 tunnel mode, NAT-T, and AES-GCM with a 16-byte tag, IPsec adds 64 bytes before Ethernet accounting. Different payload lengths can change padding by up to three bytes for this preset.
Why does small-packet traffic reduce VPN throughput?
Headers consume more of each small packet, while packets per second rise sharply. A gateway that reaches its large-packet Mbps rating may hit a PPS, CPU, or interrupt limit first on small packets.
What does rated IPsec throughput mean here?
The model assumes clear inner-IP throughput across all active tunnels. Vendor benchmarks may be one-way or aggregate and may disable threat inspection, logging, QoS, or other features. Use the most comparable figure available.
Does NAT-T reduce IPsec throughput?
It adds an 8-byte UDP header to every ESP data packet, reducing efficiency and safe inner MTU slightly.
How is safe inner MTU calculated?
The calculator tests inner packet sizes and returns the largest whose resulting outer IP packet does not exceed the selected path MTU.
Is AES-GCM overhead different for 128-bit and 256-bit keys?
No, not when both negotiate the same explicit IV and tag sizes. Gateway performance can still differ.
Does this include IKE, loss, or retransmissions?
No. It excludes IKE control traffic, packet loss, retransmission, compression, TFC padding, IP options, IPv6 extension headers, and vendor-specific encapsulation.
Are inputs uploaded or stored?
No. All values remain in the browser.
Production planning limits
This calculator is an engineering planning aid, not a performance guarantee. Actual capacity depends on hardware
acceleration, negotiated transforms, traffic direction, packet-size distribution, routing, QoS, inspection,
logging, HA state, loss, latency, and software version. Validate production sizing with current vendor data and
representative failover and load tests.