How we test IPsec and IKEv2: 5,000 tunnels, rekeys and real traffic inside

The IPsec line on a firewall datasheet is measured with one tunnel, large packets and the fastest cipher the chip supports. Your site-to-site estate is 800 tunnels, a mix of AES-GCM and the legacy suite the partner insists on, small packets of voice and the rekey timer firing all day. We test the second thing.

The bench

The device under test is a VPN gateway, a firewall or a router with IPsec, physical or a VM. The generator emulates both sides: thousands of remote gateways and road-warrior clients on one side, the servers they reach on the other, so that every tunnel carries application traffic and the generator sees what arrived. Ports from 1G to 100G, which covers a branch box and a data centre concentrator alike.

The suites, lifetimes, DPD timers and NAT setup come from your production configuration. If 30% of your tunnels sit behind NAT-T and use a particular PFS group, the bench has the same 30%.

What we check

• Tunnel setup: 1, 100, 1,000 and 5,000 tunnels brought up at once, IKEv2 SA and child SA per second, time until the last one carries traffic
• Rekey: IKE and child SA rekey under load, with the per-tunnel gap in milliseconds; a rekey storm when all lifetimes expire together
• Cipher suites: throughput per suite, AES-GCM against AES-CBC with SHA-2, plus whatever legacy suite you still have to run, each with the real frame sizes of the traffic
• Throughput and latency: an application mix inside the tunnels, 64-byte to 1,500-byte packets and a mix, encrypted and plain direction, up to the port rate
• Fragmentation and MTU: packets that exceed the tunnel MTU, IKE fragmentation, PMTUD behaviour with and without NAT
• NAT traversal and DPD: tunnels behind NAT, keepalives, dead peer detection timers and what happens to the traffic in between
• Authentication: certificates with a chain, EAP for clients, revocation checks and their effect on setup time
• HA: failover of the gateway with 5,000 tunnels up, measured as the gap per tunnel, and whether the SAs survive the switch
• Soak: 24 hours at 80% of the measured capacity with rekeys running, then memory and SA counts compared with hour 1

What usually breaks

Rekey. A gateway that holds 5,000 tunnels at the stated throughput loses 30% of it every time the rekey wave passes, because the crypto engine and the IKE daemon share a core. The datasheet throughput is measured between the waves.

Second: the small packets. 10 Gbit/s of IPsec at 1,400 bytes is 0.9 million packets per second; the same box at 128 bytes gives 2.5 Gbit/s, which is what a voice-heavy branch actually gets. The number worth having is packets per second per cipher.

The third is failover. The pair switches in 2 seconds, as promised, and 1,500 of the 5,000 tunnels renegotiate from scratch because their SAs were not synced in time. Each takes the DPD timer plus setup, a few minutes in total, with the branches offline. Found in an afternoon on the bench, not on a Monday morning.

What is in the report

Setup and rekey rates, throughput per suite and per frame size, latency inside the tunnel, the failover table with per-tunnel gaps and the number of SAs that survived. Resources over the 24 hours. The gateway configuration, the emulated peer settings, firmware and port speeds, so the vendor can reproduce every item.

Where to start

Send us the device model, the firmware you plan to run and the topology it will sit in. We answer with a test plan: the items, the bench layout and the dates. The plan is free, the report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.