SSL VPN Capacity Calculator
Size an SSL VPN gateway for reconnect storms, TLS throughput and session memory, and see which limit binds first.
Inputs
After a WAN blip or gateway failover, every client reconnects inside this window.
Aggregate TLS Throughput Required
6.000Gbps
Peak Handshake Rate
83.3handshakes/s
Handshake Capacity Used
4.17%
TLS Throughput Used
100.0%
Session Memory Required
878.91 MiB
Binding Constraint
TLS throughput
Step by step
Values used
Concurrent remote users = 5,000 users; Reconnect-storm window = 60 seconds; Gateway TLS handshake capacity = 2,000 handshakes/s; Gateway TLS throughput = 6 Gbps; Average bandwidth per user = 1.20 Mbps; Memory per session = 180 KB
SSL VPN Capacity
handshake rate = users ÷ reconnect window; aggregate throughput = users × bandwidth per user; session memory = users × bytes per session.
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
= 921,600,000.00
Binding Constraint
= TLS throughput
How it works
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
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.