When enterprise customers ask how many concurrent VPN sessions a single appliance can sustain, the answer depends far less on raw throughput than on how the platform manages tunnel lifecycle at scale. At IVO, we engineered our IKEv2 implementation to handle 50,000+ concurrent tunnels — not by overprovisioning hardware, but by designing the session management layer to be efficient from the ground up.
Here is a walk through of how we approached the full IKEv2 tunnel lifecycle, the session table architecture that makes high concurrency possible, and the engineering decisions behind our NAT-Traversal and rekeying strategies.
The IKEv2 Handshake: More Than a Four-Packet Exchange
Every IKEv2 tunnel begins with IKE_SA_INIT — the initial exchange where both peers negotiate cryptographic parameters, exchange Diffie-Hellman values, and send nonces. This is followed by IKE_AUTH, where identities are verified and the first CHILD_SA (the actual IPsec tunnel carrying user traffic) is established.
On paper, that is a clean four-message exchange. In production, it is anything but. Clients connect from behind carrier-grade NAT, corporate proxies, and mobile networks that rewrite source ports mid-session. The handshake has to survive all of it.
Our implementation detects NAT during IKE_SA_INIT using the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads defined in RFC 7296. When NAT is detected, the session automatically transitions to UDP port 4500 encapsulation, and we begin sending keepalive packets to maintain the NAT binding. The key engineering decision here was keepalive interval tuning — too aggressive and you waste bandwidth across 50,000 sessions; too conservative and carrier-grade NAT devices silently drop the binding. We settled on an adaptive interval that starts at 20 seconds and adjusts based on observed binding lifetimes per client network profile.
Aggressive vs. Informational Mode: Why We Made the Choice We Did
IKEv1 offered two Phase 1 modes — aggressive and main (informational). Aggressive mode reduced the handshake to three messages but exposed the initiator's identity in cleartext. IKEv2 eliminated this distinction by design, but the underlying tradeoff still influences implementation decisions.
Our IKEv2 stack prioritizes identity protection in every exchange. We never send identities before the encrypted channel is established. For environments where rapid reconnection matters — mobile clients roaming between networks — we use IKEv2's built-in redirect mechanism (RFC 5685) rather than resorting to shortcuts that would weaken the security posture.
The result is a handshake that completes in under 200 milliseconds on a typical broadband connection, even with full identity protection and EAP-based authentication.
Session Table Design for 50K+ Concurrent Tunnels
The session table is the heart of any high-concurrency VPN gateway. Every active IKE_SA and CHILD_SA must be indexed, tracked, and accessible for rekeying, dead peer detection, and teardown — all without becoming a bottleneck.
Our approach uses a lock-free hash table indexed by SPI (Security Parameter Index) pairs, with a secondary index on the client's inner IP address for fast policy lookups. The critical insight was separating the hot path (packet forwarding using CHILD_SA SPIs) from the cold path (IKE_SA management for rekeying and control messages).
Packet forwarding lookups happen against CHILD_SA SPIs and must be single-digit microseconds. These entries live in a cache-aligned, read-optimized structure. IKE_SA entries, which are accessed far less frequently, live in a separate structure optimized for concurrent writes — because rekeying events, DPD responses, and new CHILD_SA negotiations all modify IKE_SA state.
This separation means that even during a rekeying storm — where thousands of tunnels hit their rekey interval simultaneously — packet forwarding for established tunnels continues unaffected.
Rekeying at Scale: Jitter Is Not Optional
RFC 7296 specifies that IKEv2 peers should periodically rekey both IKE_SAs and CHILD_SAs to limit the exposure of any single set of session keys. The protocol handles this through CREATE_CHILD_SA exchanges.
The engineering challenge is not the rekey itself — it is what happens when 50,000 tunnels with similar lifetimes all attempt to rekey within the same window. Without intervention, this creates a thundering herd that can saturate the control plane.
Our solution applies randomized jitter to every rekey timer. When a tunnel is established with a configured lifetime of, say, 8 hours, the actual rekey is scheduled at a random point within a configurable window (default: the last 10% of the lifetime). This spreads the rekey load across approximately 48 minutes instead of concentrating it in a single moment.
We also implemented make-before-break rekeying for CHILD_SAs. The new CHILD_SA is fully negotiated and installed before the old one is torn down. This eliminates the brief packet-loss window that break-before-make rekeying introduces — a detail that matters enormously for latency-sensitive applications like VoIP and real-time collaboration tools.
Dead Peer Detection: Knowing When to Let Go
Dead Peer Detection (DPD) in IKEv2 uses INFORMATIONAL exchanges with empty payloads — essentially a lightweight "are you there?" probe. The peer must respond, or it is considered dead after a configurable number of retries.
At 50,000 concurrent sessions, naive DPD becomes a scalability problem. Sending periodic probes to every peer consumes control plane resources even when traffic is flowing normally. Our implementation uses traffic-based DPD: we only send a DPD probe when we have not received any authenticated packet (data or control) from the peer within the DPD timeout window. If traffic is flowing, the peer is clearly alive, and no probe is needed.
This reduces DPD overhead by roughly 90% in typical deployments where most tunnels are actively carrying traffic. For idle tunnels — which are common in always-on VPN deployments — DPD probes are staggered using the same jitter approach as rekeying to prevent probe storms.
Handling Carrier-Grade NAT and Port Reassignment
Carrier-grade NAT (CGNAT) presents a specific challenge for IKEv2 deployments. CGNAT devices may reassign the client's external port between packets, and some aggressively time out UDP bindings. Because IKEv2 sessions are identified by SPI pairs rather than source port, a port change does not inherently break the tunnel — but it does require the gateway to update its peer address mapping.
Our implementation maintains a peer address table that is updated on every authenticated packet. When the source address or port changes, we verify the packet's cryptographic integrity before updating the mapping. This prevents an attacker from redirecting a tunnel by spoofing packets with a different source address while still allowing legitimate CGNAT port reassignments.
For environments with particularly aggressive CGNAT behavior, we support MOBIKE (RFC 4555), which provides a protocol-level mechanism for peers to notify each other of address changes. This is especially valuable for mobile clients that transition between Wi-Fi and cellular networks.
What This Means for Deployment
The cumulative effect of these engineering decisions is an IKEv2 implementation that sustains 50,000+ concurrent tunnels on a single appliance without requiring operators to compromise on security, session integrity, or reconnection behavior.
Every design choice — from adaptive keepalive intervals to lock-free session tables to jittered rekeying — was driven by real-world deployment requirements. Enterprise and government networks do not have the luxury of controlled lab conditions. Clients connect from unpredictable networks, tunnels must survive NAT rebinding, and the control plane must remain responsive even under sustained load.
IVO's VPN appliances bring this engineering to organizations that need secure, scalable remote access — without the complexity of managing it themselves.
Ready to evaluate IVO's VPN solution in your environment? Call +1 (650) 286-1300 or start your 30-day free trial today.