how to calculate surge of cpu cycles consumption of an ipsec tunnel with aes256/sha512/dhgroup21? The project I'm involved with needs to establish around 2500 simultaneous ipsec connections between roadwarriors clients and the ipsec concentrator/gateway.

In order to be able to estimate the appropriate hardware solution I'd like to be able to calculate the amount of processing power needed to sustain the moment of a surge in computation (like when all clients are connected and the concentrators' link goes down and when it comes back it gets flooded by all 2500 client attempting reconnects).

What would it take for example to carry 2500 simultaneous initiating ipsec connections using aes-256,sha512 and dh group 21 or 24 (as advised on https://supportforums.cisco.com/document/12276506/diffie-hellman-groups)?

The clients won't be generating more than few packets/s once connected (less than 10, for sure)

I've been lookin at this similar question but I'm still confused.
In the scenario of the question, the cryptography involved on the server side will be, for each client connection, and ignoring a number of details like random number generation


Diffie-Hellmann in some group for the generation of session keys
Few SHA-512 as part of that, of relatively negligible computational cost for competent implementation, assuming 1 is in software (or if 2 was in hardware)
Some AES-256 cryptography, as part of packet exchanges, also of relatively negligible computational cost for competent implementation, usual packet size, assuming 1 is in software or 3 is in hardware (including using AES-NI of modern x86 CPUs)
Some other untold assymetric crypto operation (like a few signature verifications), especially if the clients are authenticated by assymetric cryptography; I'll leave that alone, but it could be significant, even dominant.


The groups in the blog post quoted in the question seem to be that of RFC 5114 section 3.2. I thus believe that the blog post makes a serious error when it ranks group 24 as "Next Generation Encryption" and more secure than group 19 ranked "ACCEPTABLE". Group 24 seems to be a Schnorr group with $p$ of 2048 bits and $q$ of 256 bits, quoted as giving 112-bit symmetric security where groups 19, 20 and 21 would be 256-bit, 384-bit and 521-bit elliptic curves with 128, 192 and 256-bit security (taking 192 and 256-bit security with a grain of salt as anything above about 160-bit in that sense could be attackable, with humanly sizable odds of success, only if there was a totally disruptive breakthrough, like quantum computers usable for cryptanalysis; or, regardless of security level, if there's some goof or backdoor in the implementation).

On a nearby VM with openSSL 1.02g installed and lscpu reporting 2 cores at 4 GHz, the command openssl speed reported what could be a passable benchmark for groups 19, 20 and 21 as implemented by openSSL (the last colum is mine, and I have slightly edited the others for legibility)

 256 bit ecdh (nistp256)   18190 op/s   (group 19)
 384 bit ecdh (nistp384)    1980 op/s   (group 20)
 521 bit ecdh (nistp521)    2834 op/s   (group 21)


I'm surprised that nistp521 is shown faster than nistp384; think of it as an illustration that timing varies enormously with the quality of the software implemention (and perhaps, different parameters in benchmarks, which I have not cheked). But these numbers tell us that the 2500 clients reconnecting simultaneously are unlikely to take more than a few seconds of CPU time for the crytography in 1 (thus in 1/2/3), with a competent implementation in software on a powerful x86 CPU, for groups 20 and 21; with group 19 significantly faster (and, as far as we know, unlikely to be an exploitable weakness anytime soon; compromize of the server or its private key is a much more down-to-earth concern).

Beware that an "ipsec concentrator/gateway" typicaly will use something much lesser than a powerful x86 CPU; on the other hand, some have crypto accelerators. The most important thing is how good and trustable is the software; and that's impossible to tell from specs.