Linux to Cisco Openswan IPSec Configuration

Reading Time: 6 minutes

[notice]For this example I use the following IP scheme|–O–—–[INTERNET]——–O–|[/notice]

I was approached a few weeks back to assist in creating a VPN Tunnel between two end points. Of course in my naivety I readily assumed it was between to Cisco devices but that turned out not to be the case. The tunnel was to be between a Linux box (in this case Ubuntu on a hosted VPS provider) and an unknown endpoint. This tunnel was going to be host to host as opposed to LAN to LAN. After some quick discovery work, getting access to the Linux box, and seeing the required proposal from the other side I started diving into the unknown of Openswan. Luckily, after doing som research for the configuration and verification things started shaping up and much to my approval, a lot of what you would look for in Cisco verification was the same on the Linux box. The configuration goes as such.

Naturally the first step is to install Openswan. As per usual use your distributions software management to install this. The first thing I configured was the ipsec configuration file. On the Ubuntu box this resided in “/etc/ipsec.conf”. The configuration was as follows.

I’ll break down the configuraiton file above a little bit to clarify the concept.

The line at the top stating “virtual_private” underneath the “config setup” declaration is essentially telling IPSec which private networks are allowed to be encrypted. This goes at the top of the file because you can create more than one connection through the same configuration file. In this case we only had one which is labled “conn IPSEC_VPN”

Also in the “config setup” section we are indicating that this configuration is not going to use nat_traversal. Another key line is the “plutoopts” line which is similar to stating a “source interface” on a Cisco GRE tunnel.

From there we move on to the tunnel configuration itself. This is done under the “conn IPSEC_VPN” declaration. Again, you can have more than one in this configuration file.

Underneath here we state we will be authenticating by a preshared secret. The “authby=secret” statement tells Openswan to look at /etc/ipsec.secrets for the pre shared key and peers. We also tell the tunnel to automatically start when Openswan does.

Phase 1 of the tunnel is indicated by the configuration statement “ike=” along with “keyexchange=ike”. In Phase 1 of this tunnel we used AES-256, SHA1, and DH Group 5 indcated by “modp1536”

Phase 2 of the tunnel is configured via the “phase2”, “esp”, and “salifetime” statements. Here we told Phase 2 to utilize ESP and defined AES-256 and SHA1. We also changed the Security Association Lifetime to 3600 seconds.

The next steps are explained by keeping in mind that left is equivelent to the near end of the tunnel (think our side we are configuring) and right is equivelent to the far end of the tunnel. With that in mind, the “left=” and “right=” statements define the public peer ends. The “leftsubnet=” and “rightsubnet=” represent the ACL stating which near end traffic destined to which farend traffic is to be encrypted. In our case, as it was a host to host tunnel we used /32 host prefixes. We also told the near end to use its standard default route to get towards its peer.

Next we configure the preshared keys in the /etc/ipsec.secrets file. This is fairly straight forward indicating the left “near end” public IP followed by the right “far end” public IP ending with a “:”. The key itself follows the PSK statement.

Next, since we needed all traffic from our Linux boxed destined to the private network at the other end to be sourced from our private address we need to add a static route. Linux allows you to add a static route to a destination, define the interface and IP address traffic should be sourced from. This essentially caused the Linux box to source any traffic it generated to the VPN subnet to look at is if came from it’s private address. This allows commands to be run without needing to be able to specify a source interface in the commands. This is the band-aide as some commands don’t have a source interface option.

Naturally I ran into some issues while configuring this as I haven’t ever worked with Openswan or its syntax so I got familiar with the “ipsec auto –status” command. This is similar to debug ipsec and isakmp on a Cisco router. Lines to note are highlighted. Specifically watching for “ISAKMP SA Established” and “IPSec SA Established” just like we would when running “show crypto isakmp sa” and “show crypto ipsec sa”. See marked lines 72 and 74.

There was also a simple command to quickly see if the tunnel made it to the up state or not. This command was “service ipsec status”. The output is self explanitary.

Finally we verified private host to host connectivity with a simple ping.

Ping Proof

Share this article:

Permanent link to this article: