SSL VPN Capacity Calculator
Size an SSL VPN gateway for reconnect storms, TLS throughput and session memory, and see which limit binds first.
About SSL VPN Capacity Calculator
In steady state an SSL VPN is bound by throughput, because TLS sessions are long-lived and handshakes are rare. The handshake rate only matters during a reconnect storm, when a failover or WAN blip makes every client renegotiate inside a few seconds — so divide the user count by that window, not by the working day. Gateways sized on steady-state numbers routinely collapse during failover, because the asymmetric crypto in thousands of simultaneous handshakes costs orders of magnitude more CPU than the bulk encryption that follows.
Formula
SSL VPN Capacity
handshake rate = users ÷ reconnect window; aggregate throughput = users × bandwidth per user; session memory = users × bytes per session.
- reconnect window
- Seconds over which every client re-establishes its tunnel
- session memory
- Per-session state including TLS context and connection tables
Worked example
With the default values below, SSL VPN Capacity Calculator returns Aggregate TLS Throughput Required of 6.000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Concurrent remote usersaccepts 1–1,000,000 users
- 5,000 users
- Reconnect-storm windowaccepts 1–3,600 seconds
- 60 seconds
- Gateway TLS handshake capacityaccepts 10–1,000,000 handshakes/s
- 2,000 handshakes/s
- Gateway TLS throughputaccepts 0.01–2,000 Gbps
- 6 Gbps
- Average bandwidth per useraccepts 0.01–1,000 Mbps
- 1.2 Mbps
- Memory per sessionaccepts 8–8,192 KB
- 180 KB
Results
- Aggregate TLS Throughput Required
- 6.000 Gbps
- Peak Handshake Rate
- 83.3 handshakes/s
- Handshake Capacity Used
- 4.17%
- TLS Throughput Used
- 100.0%
- Session Memory Required
- 878.91 MiB
- Binding Constraint
- TLS throughput
Step by step
- 1Values used
- 2SSL VPN Capacity
- 3Aggregate TLS Throughput Required= 6.000 Gbps
- 4Peak Handshake Rate= 83.3 handshakes/s
- 5Handshake Capacity Used= 4.17
- 6TLS Throughput Used= 100.0
- 7Session Memory Required= 921,600,000.00
- 8Binding Constraint= TLS throughput
Assumptions and limits
- The result is derived only from the 6 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 3 decimal places, 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
How is SSL VPN Capacity calculated?
handshake rate = users ÷ reconnect window; aggregate throughput = users × bandwidth per user; session memory = users × bytes per session. In steady state an SSL VPN is bound by throughput, because TLS sessions are long-lived and handshakes are rare. The handshake rate only matters during a reconnect storm, when a failover or WAN blip makes every client renegotiate inside a few seconds — so divide the user count by that window, not by the working day.
Why does SSL VPN Capacity matter?
Gateways sized on steady-state numbers routinely collapse during failover, because the asymmetric crypto in thousands of simultaneous handshakes costs orders of magnitude more CPU than the bulk encryption that follows.
What values do I need to enter?
This calculator takes 6 inputs: Concurrent remote users, Reconnect-storm window, Gateway TLS handshake capacity, Gateway TLS throughput, Average bandwidth per user, Memory per session. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Does session resumption help?
Yes, substantially. TLS session tickets or 1.3 pre-shared-key resumption skip the expensive asymmetric key exchange, cutting handshake CPU by roughly an order of magnitude. It only helps if the resuming client lands on a gateway that holds the ticket, so a shared ticket key across the cluster is what makes it effective during failover.