The other issue at startup is entropy from /dev/random
. In July 2004, 1006 IPsec Tunnels were established in 205 seconds (~3.5 minutes), giving a rate of 5 tunnels/sec. This scales linearly, if the tunnel initiation rate does not increase. The CPU load during the test was always around 60% to 90% (very low).
The main problem we found was that there was a bottleneck in the Linux kernel random number generator. Switching from /dev/random
to /dev/urandom
increased the set-up rate to 10 tunnels per second, at the risk of being slightly less secure due to not-as-random numbers being used for the Diffe-Hellman calculations.
Note that both versions 1 and 2 of Openswan already use /dev/urandom
, which is safe enough for generating the session keys that normally only last for an hour anyway. When the ipsec
newhostkey
command is used to generate long-term RSA keys, Openswan explicitly uses /dev/random
to generate these keys.
If you are using a VIA CPU with the PadLock...