A VPN concentrator datasheet gives a user count and a throughput figure, both taken separately: thousands of idle tunnels for the first, a few fat ones for the second. A Monday morning looks different. 3,000 people connect between 8:50 and 9:10, every login goes through the directory and an MFA push, and then everyone joins a video call through the tunnel. We measure that morning: tunnels per second with authentication on, what one user gets when all of them are connected, and how many come back after the pair fails over.
The bench
The device under test is a remote-access VPN concentrator, a firewall with an SSL VPN or IPsec client gateway, or a ZTNA gateway, one of the device classes of our firewall and NGFW bench: a box shipped to CloudLAB, an image on the bench hypervisor or an instance in your tenant. The generator plays the employees: IPsec and SSL VPN clients by the thousand, logging in along a curve taken from your gateway logs, with video calls, file shares and SaaS over TLS inside the tunnels. Emulated servers answer behind the gateway.
The authentication chain is part of the load. Your RADIUS, LDAP or SAML identity provider joins the run, or a lab instance answers with the response time measured in your network, MFA wait included. The client side passes through our WANemu emulator (in beta on 1G and 10G links) with home broadband and LTE profiles. Tunnel mechanics (IKEv2 setup, rekey, NAT-T, DPD) are covered in the IPsec and IKEv2 post. This one is about the person at the far end of the tunnel.
What we check
- Login wave: tunnels per second with authentication on, along the 8:50–9:10 curve; time from the click to the first packet in the tunnel, p50 and p99
- Concurrent users: the count where a new login is refused or connected users slow down, with traffic in every tunnel
- Throughput per user and in total: full tunnel and split tunnel, IPsec, SSL VPN over DTLS and over TLS
- Added latency: round trip and jitter for voice and video at idle, 50 % and 90 % of the measured load
- Re-authentication and MFA: session lifetimes that expire for everyone in the same 15 minutes, an identity provider that answers in 5 s or not at all, and who stays connected meanwhile
- ZTNA policy: per-application access with posture checks, setup time per app, the cost of thousands of rules in new connections per second
- Failover of the pair: the active unit switched off with all users on; seconds until traffic flows, sessions that survived, the reconnect storm and the minute the last user is back
What usually breaks
The login wave. A concentrator rated for 10,000 users brings up 10,000 tunnels in the vendor test against a local user database. In a typical project the real chain (directory lookup, MFA push, address assignment, posture check) brings the rate down from a few hundred setups per second to about 40. At 9:05 the queue is minutes long, clients time out and retry, and the retries make it longer. A longer client timeout and a second authentication server bring the wait under a minute.
The fallback to TLS. SSL VPN clients prefer DTLS over UDP. A home router or a hotel network that blocks UDP pushes them onto TLS over TCP. With 1 % loss from the LTE profile, TCP inside TCP stalls: retransmissions pile up in both layers, and in a typical run a file copy through the tunnel drops to about a third of the same copy over DTLS. Both numbers go into the report per profile.
Failover. The pair switches in 2 seconds as promised, but on many platforms SSL VPN sessions are not synced between the units, so every user logs in again, MFA included. 3,000 logins arrive within a minute, the identity provider becomes the bottleneck, and the last user is back after 6 minutes. The 2 seconds on the datasheet are honest. Users judge the outage by the reconnect curve.
What is in the report
The login curve: tunnels per second and time to the first packet per percentile, next to the curve from your logs. The user ceiling with traffic on. Throughput per user and in total per tunnel type, split and full. Latency added at each load step. The re-authentication and MFA cases as a pass and fail list. The failover table with seconds, surviving sessions and the reconnect curve. Configs, identity provider timings and emulator profiles, so the same Monday morning replays on the next firmware.
Where to start
Send us the gateway model, the user count and an export of the VPN policy. We answer with a draft test plan: the items, the bench layout and the dates. The report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.
Alexander Zemskov
5 min read
Alexander Zemskov
5 min read
