Build an IPSEC VPN Without Losing Your Mind
You might be ready to move beyond OpenVPN, but feel daunted by IPSEC's learning curve. With our quick guide, you'll be up and running with free, open Openswan in no time.
With latency-sensitive or high bandwidth requirements, often we find OpenVPN unable to perform. IPSEC is the solution, but the barrier to using IPSEC is great. It is potentially difficult to configure, and one's first exposure to VPN concepts is often confusing.
With the concepts explained, the task of actually making IPSEC work becomes much more tenable. Likewise, using Openswan, the fork and improvement of FreeS/WAN, makes configuring IPSEC almost fun.
We will explain how to create a network-to-network connection so hosts at two remote sites can communicate with each other. If you have trouble setting this up, first try host-to-host mode, using the excellent tutorial on the Openswan wiki.
To successfully run Openswan, there are only four things you need:
- a pre-shared key to make encryption work
- to know the IP addresses of the two gateway servers on each end
- to know the subnet ranges of the networks at each end
- a drawing, if this is your first time
You can ignore requirement number one, for now, since Openswan makes this simple.
Openswan also takes care of adding routing table entries, so this list is really all you need for the basic "make one subnet reach another" configuration. After configuring a tunnel, Openswan will inherently know which traffic is destined for the network on the other side of the tunnel, and automatically adds the route. Of course, you can send traffic for more subnets through the IPSEC tunnel, assuming the gateway on the other end knows how to route there. When everything else is working, simply add another route similar to the one Openswan adds for you, but for the other network.
When configuring IPSEC, you need to draw out your subnets and which interfaces are on the gateways, and label them accordingly. Using the intuitive left/right terminology from Openswan (because all diagrams of this nature are two-dimensional, and in/out or local/remote mean different things to different people), create a diagram similar to the figure below with your own information:
The site represented on the left side, with Gateway A, is known as the "left" when we configure Openswan, and likewise for the right.
We are now ready. Install Openswan and locate its ipsec.conf file.
If a key was generated by your installer package, you can retrieve it by running ipsec showhostkey --left
We will use the resulting key for the configuration file. If instead you see something like "ipsec showhostkey: no default key in /etc/ipsec.secrets," you will need to generate one as root: ipsec newhostkey --output /etc/ipsec.secrets
Repeat the process on the other side of the soon-to-be VPN, and you should now have two keys.
The ipsec.conf file is really quite simple with Openswan. We are now going to combine all the information previously gathered above.
# Openswan ipsec.conf
The "left" and "right" declarations are externally accessible IP addresses of the gateway routers. The "leftid" is the hostname of the machine.
Copy this file to Gateway B, and you are ready to start the tunnel on both ends: ipsec auto --up GatewayA-to-GatewayB
The quick test is of course to ping the external IP of Gateway B from Gateway A. You will notice a route in the routing table that directs this traffic, and traffic to the defined rightsubnet through the tunnel. If IP forwarding is enabled, as it probably is, given that these machines are both already routers, you can now try pinging a host in the remote subnet.
That certainly wasn't hard. You can also define more connections in the same configuration file. They are differentiated by the leftid and rightid parameters, allowing you to use a single configuration across many hosts.