Chapter 11

Handling Thousands of Tunnels

Openswan has been tested to scale to over a thousand concurrent tunnels with no technical problems. There are, however, two operational issues when managing many tunnels: dealing with the configuration file and reducing the Openswan startup time.

Managing Large Configuration Files

When you have an ipsec.conf file with hundreds, or even thousands, of tunnels defined, it can be quite difficult to manage. The following three tips should make this easier.

Standard Naming Convention

If you use standard names or abbreviations in your configuration files, they will be much easier to visually check and modify. It will also make it much easier to write custom scripts around common operations you might want to execute.

For example, to remove all connections you have described with KEYWORD as part of the connection name, you can use the following:

for conn in `grep "^conn .*KEYWORD.*" \ /etc/ipsec.conf|awk '{print $2}'`;

do

ipsec auto --delete $conn done;

The also= Parameter

The also= parameter ensures that you do not enter duplicate information anywhere in your configuration files. You only need to update one entry if some topological change needs to be made.

The include Parameter

Use the include= parameter to separate administrative or geographical boundaries. This makes it easy to make a change in all configurations for a certain location.

Openswan Startup Time

The length of time the script-based system takes to read ipsec.conf can become excessive past about 100 tunnels. The following graph shows the speed of the shell/awk-based parsing system:

257

Enterprise Implementation

As can be seen from this benchmark, this is far from ideal for large-scale deployment on concentrator machines. The reason for the poor performance with a large number of tunnels is due to the startup scripts. Openswan will only start the tunnels sequentially. Currently, there are two solutions for avoiding this connection loading problem:

1.Configure all of your tunnels as auto=ignore, start Openswan, and then use a script, similar to that used in the Standard Naming Convention section above, to run through ipsec.conf executing ipsec auto –add $conn to load each connection. These connections are then loaded in the background, resulting in all connections being loaded in parallel, greatly reducing the start-up time.

2.Use the new C configuration parser written by Arkoon Networks—ipsec starter. Starter parses the ipsec.conf directly and spawns any Pluto and whack processes as needed, bypassing the scripts. The only downside of starter is that development lags behind regular Openswan development, so not all features that you can set in ipsec.conf are currently supported by starter.

Limitations of the Random Device

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).

258