Chapter 11

config setup interfaces="ipsec0=eth0:0"

Lastly, copy ipsec.conf, along with ipsec.secrets and any X.509 Certificates, to all other nodes in the HA cluster.

Xen Migration

Another upcoming development is Xen VM technology. Xen allows the migration of live servers, which could be used to keep a continuous mirror state of the kernel's entire internal state, including all session information about IPsec not saved to disk. In case of a failure of the main server, the second Xen image could be told to 'go live'. Xen migration, however, is still very much on the bleeding edge of development, and the authors hope to be able to invest some time in exploring the options that it has to offer.

Using Anycast

Combining anycast with Openswan can be interesting in two scenarios. The first scenario is when you are moving a certain network and server farm that is announced by BGP from one physical location to the other, using just a single redundant Openswan router.

Let's say you have ColoA and ColoB. ColoA hosts most of the infrastructure, and ColoB has a copy of the Openswan router from ColoA. Depending on the shortest BPG prefix, clients trying to reach the network that is being moved will connect to either ColoA or ColoB. However, there is an IPsec tunnel using PA space from ColoA and ColoB that connects these two Openswan machines that share the same public IP address. By adding or removing tunnels for one machine (/32) or a few machines (e.g. /28), it is possible to tunnel the packets to wherever the physical server is at that point in time. If the server has not yet moved from ColoA to ColoB, and a packet for it reaches ColoB, it will be tunneled to ColoA. When the server is moved, the tunnel is updated to its reverse policy, and packets that still arrive at the old ColoA can be forwarded to ColoB.

You can extend this scheme. Imagine you are anycasting your VPN gateway worldwide. Wherever your roadwarriors are, they will be routed via the shortest prefix. This usually means over peering routes, instead of transit routes. By having most of your roadwarriors come in over peering instead of transit, you will achieve better network connectivity and save substantially on the traffic bill for your VPN service. Moreover, if one location should go down, the roadwarriors will just connect to the shortest prefix path location of the anycasted IP of the VPN server.

The same trick can also be used to set up an IPsec tunnel from the main office network to the particular VPN server the roadwarrior is connected to. There is one catch in this scenario. The different VPN front ends do not know about each other's state, so if a roadwarrior vanishes from one VPN server, and appears at another, some tunnels might need to be torn down or changed. This can, however, all be configured using custom _updown scripts.

263

Enterprise Implementation

Summary

Hopefully this chapter has given you some insight into sizing your IPsec gateway, and how to manage hundreds, or even thousands of IPsec tunnels. We have also covered the basics for a High Availability IPsec fail-over setup, with IP address takeover and IPsec tunnel takeover.

264