IPsec Transport Mode with strongswan on Debian 8 Jessie

Posted by Christoph Haas on 10 03 2016. 1 Kommentar zu IPsec Transport Mode with strongswan on Debian 8 Jessie

Today I am going to write a small tutorial on how inter-server communication can be secured via IPsec in transport mode. This tutorial was written for Debian 8 Jessie but it should work similar with other linux distributions aswell.

 

Here is a small diagram of my test setup:

 

 

 

 

 

 

Each server has only one network interface with an public IP (in this test case, we use private IPs).

As we only want the host to host communication to be encrypted, we can use the transport mode. In the standard tunnel mode, entire packets are encapsulated within a single stream, encrypted, then sent on their way. This is great for LAN-to-LAN connections where you want to allow a subnet (or many subnets) on one side of the tunnel to be able to communicate with a subnet (or many) on the other side of the tunnel.

To contrast, in transport mode, IPsec merely encrypts packet payloads, leaving the IP headers intact. This fact enables easy integration into existing routing infrastructures and makes it perfect for securing host-to-host communication on untrusted networks.

 

First, install prerequisite packages:

$ sudo apt-get update && sudo apt-get install strongswan

IPsec core functions are provided by the kernel – „strongswan“ provides the user-space tools needed to easily configure connections, in addition to providing the „charon“ daemon, which takes care of the periodic re-keying that is essential to IPsec’s security.

Next, add a line like this to your /etc/ipsec.secrets file (example for cluster01).

10.0.99.31 10.0.99.32 : PSK "strongpresharedkey1"
10.0.99.31 10.0.99.33 : PSK "strongpresharedkey2"

Needless to say, you’ll need to substitute the IDs of your actual servers in addition to providing a strong pre-shared key that will be used to bootstrap the IPsec connection between these two IPs.
So for cluster02 the file should look like:

10.0.99.32 10.0.99.31 : PSK "strongpresharedkey1"
10.0.99.32 10.0.99.33 : PSK "strongpresharedkey3"

Add this line to the bottom of /etc/ipsec.conf:

include /etc/ipsec.d/*.conf

NOTE: this line is optional – it is only required if you’d like to keep each individual IPsec connection configuration in its own file. If you don’t care about this, you can just add the below IPsec config to the /etc/ipsec.conf file and be done with it.

However, if you do want to keep things clean and separate out each connection into its own file (doing this can make automated configuration very simple), then add the above line and then add the following to a new config file. Something like /etc/ipsec.d/cluster01_cluster02.conf for server cluster01:

conn cluster01-cluster02
 type=transport
 authby=secret
 left=10.0.99.31
 right=10.0.99.32
 pfs=yes
 auto=start

Let me digest this for you line by line.

• conn cluster01-cluster02: arbitrary label for your connection. This can be anything you’d like.
• type=transport: we want to use transport mode for this connection
• authby=secret: we’ll be using a pre-shared key (PSK) for this connection. This is in reference to the line we added to /etc/ipsec.secrets. IPsec can also use certificate authentication, which adds an additional level of security, but also adds complexity in configuration, so we’re starting simple.
• left=10.0.99.31: this and the next line are just denoting the IP addresses involved in this IPsec association. It does not matter which IP is „left“ and which is „right“ but I always configure the left host to be the current one.
• right=10.0.99.32: see explanation in above bullet.
• pfs=yes: we want to enable Perfect Forward Secrecy for this connection. In short, this drastically improves security. It’s a large topic to discuss, so I’m not going to touch it now. If you want to read more, Wikipedia is your friend.
• auto=start: We want to pro-actively initiate the IPsec association immediately. This can also be set to auto=add or auto=route, in which case it waits for the other end of the connection to initiate traffic.
  The above configuration needs to be duplicated on both cluster01 and cluster02, cluster03 configuration works the same way. Their configurations can be identical with the exception of one of them should have their connection set to auto=route and one to auto=start. This way, they’re not „fighting“ over who should initiate the connection. In all honesty, I’ve not seen it cause a problem when both are set to auto=start, but it’s a best practice to only have one peer initiate things.
  For an detailed explanation see here: http://serverfault.com/questions/556885/using-strongswan-whats-the-difference-between-auto-add-and-auto-start

At this point, we’re ready to fire things up. On each server run this command:

$ sudo systemctl restart ipsec
$ sudo systemctl status ipsec -l

After doing this, all traffic between cluster01 and cluster02 should be encrypted. To verify this, run a ping between servers and then:

$ sudo tcpdump esp

This will display all ESP packets. You should see two lines (one incoming, one outgoing) for each ping. If you are not seeing ESP traffic, then something is wrong and you’ll need to dig into the joy that is IPsec troubleshooting.

 

If you get any error messages like „operation not permitted“ make sure to allow IPsec traffic in iptables:

iptables -A INPUT -i eth0 -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A INPUT -i eth0 -p udp --sport 4500 --dport 4500 -j ACCEPT
iptables -A INPUT -i eth0 -p esp -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -o eth0 -p udp --sport 4500 --dport 4500 -j ACCEPT
iptables -A OUTPUT -o eth0 -p esp -j ACCEPT

Configuration files

cluster01:

/etc/ipsec.d/cluster01_cluster02.conf:

conn cluster01-cluster02
 type=transport
 authby=secret
 left=10.0.99.31
 right=10.0.99.32
 pfs=yes
 auto=start

/etc/ipsec.d/cluster01_cluster03.conf:

conn cluster01-cluster03
 type=transport
 authby=secret
 left=10.0.99.31
 right=10.0.99.33
 pfs=yes
 auto=start

/etc/ipsec.secrets

10.0.99.31 10.0.99.32 : PSK "secret1_2"
10.0.99.31 10.0.99.33 : PSK "secret1_3"

cluster02:

/etc/ipsec.d/cluster02_cluster01.conf:

conn cluster02-cluster01
 type=transport
 authby=secret
 left=10.0.99.32
 right=10.0.99.31
 pfs=yes
 auto=route

/etc/ipsec.d/cluster02_cluster03.conf:

conn cluster02-cluster03
 type=transport
 authby=secret
 left=10.0.99.32
 right=10.0.99.33
 pfs=yes
 auto=start

/etc/ipsec.secrets

10.0.99.32 10.0.99.31 : PSK "secret1_2"
10.0.99.32 10.0.99.33 : PSK "secret2_3"

cluster03:

/etc/ipsec.d/cluster03_cluster01.conf:

conn cluster03-cluster01
 type=transport
 authby=secret
 left=10.0.99.33
 right=10.0.99.31
 pfs=yes
 auto=route

/etc/ipsec.d/cluster03_cluster02.conf:

conn cluster03-cluster02
 type=transport
 authby=secret
 left=10.0.99.33
 right=10.0.99.32
 pfs=yes
 auto=route

/etc/ipsec.secrets

10.0.99.33 10.0.99.31 : PSK "secret1_3"
10.0.99.33 10.0.99.32 : PSK "secret2_3"

This article is based on http://andersonfam.org/2014/04/02/ipsec-transport-mode/.