Information here is seriously outdated

This page hasn’t been updated since 2014, and many of the tools mentioned here are not in Debian anymore. Someone with knowledge in this area should probably update it, possibly using information from this ArchWiki article.

Background

IPsec is short for "IP security". It is a means of authenticating and also optionally encrypting TCP/IP traffic, thereby ensuring a selected measure of security.

More information about IPsec in general can be found on http://en.wikipedia.org/wiki/IPsec.

There are, roughly, two parts to an IPsec implementation: one kernel part, which takes care of everything once the encryption or signing keys are known, and one "user-level" program which negotiates beforehand to set the keys up and give them to the kernel part via an IPsec-specific kernel API. The user-level program can also be configured to renegotiate keys periodically so no keys are used for too long.

Since the user-level-program requires kernel-level support it is not as simple as just selecting a package and installing it; you need to make sure that the kernel supports the kernel API that the package you select expects.

Before Linux had IPsec support, there was ?FreeS/WAN and KAME. They both included a kernel patch which communicated with a key exchange daemon. KAME had no Debian package, so you would install the packages freeswan and kernel-patch-freeswan (both version 1.96), and recompile your kernel with the patch. Life was simple, even if you were forced to use a non-standard kernel.

The experimental Linux 2.5 series (to become 2.6) adopted KAME's kernel API, and the newer upstream versions of FreeS/WAN (2.01 and above) started to support that API too, as well as their own.

Then, the Debian Linux packages (both source and images), starting with version 2.4.21, included a backport of the KAME kernel IPsec API from the 2.5 series of Linux. This presented a problem for those users of Debian Woody using FreeS/WAN; the packages in Woody did not support the new API. The only possible solution was to use the kernel-patch-freeswan, but go back to version 2.4.18 of the Linux packages, which was apparently the only ones receiving security updates, anyway.

Also, the FreeS/WAN project had recently ended; the final version was 2.06. A program whose original API was not chosen for adoption in Linux and which faces an uncertain future is hardly the solution of choice for those who value stability. (FreeS/WAN has been forked, one branch of which is in Debian testing and unstable, but those projects has yet to prove themselves to have the stability and commitment of the FreeS/WAN project.)

And for those users who needed a newer Linux than 2.4.18 for their hardware, and had been using 2.4.20, the situation was problematic. The newer Linux source packages could not be unpatched to remove the IPsec support without failed hunks. Neither could the FreeS/WAN source be patched to understand the new API without similar problems. The newer FreeS/WAN packages from "unstable" and "testing" failed to compile in Woody.

The only thing left to do for those users was to bite the bullet and convert completely to the "new" model; to use the KAME user-level programs which works with the new Linux API. The KAME tools do not exist in Woody, but they existed in testing (later Sarge), and the debian/rules file includes an easily-enabled conditional to enable compiling the packages for woody. See (dead link) Racoon In Woody.

Now that Sarge is released, you can create IPsec tunnels in two different ways. Either by using the Freeswan/Openswan KLIPS methodology or by using the Racoon/BSD KAME method. The necessary patches for Openswan modules are already backported into the stock Debian kernel (2.4.27 & 2.6.8 <I can verify this is true for the 2.6.8 kernel but haven't tried the 2.4.27 kernel>). This method allows for basic use (no NAT) with Shorewall but doesn't implement the new Security Policy Database (SPD).

The other method is the newer KAME methodology. This is integrated directly into the 2.6 kernel but in order to work with the new security policies (SPD), you need to patch the kernel and iptables with the new netfilter policy match. There is a different Shorewall setup for this type of method.

Ken Bantoft of OpenSwan held a talk on LinuxTag 2004 entitled [The Future of IPsec on Linux (dead link) http://www.xelerance.com/talks/linuxtag2004/] which contains some history and outlines possible future paths from here.

The KAME packages are called ipsec-tools (source package and command-line utilities) and racoon (key exchange daemon).

Howtos

Micro-Howto of using racoon and ipsec-tools in Woody: [Debian IPsec Micro-Howto http://www.fukt.bsnet.se/~teddy/debian-ipsec]

Quick Howto on configuring an ipsec tunnel

With lenny/squeeze.

Alice IP: 172.27.1.165/24 Alice VPN Network: 172.20.1.0/24

Bob IP: 172.27.1.169/24 Bob VPN Network: 192.168.22.0/24

On each host:

apt-get install racoon ipsec-tools

Configure racoon

Alice /etc/racoon/racoon.conf

path pre_shared_key "/etc/racoon/psk.txt";

remote 172.27.1.169 {
        exchange_mode main,aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo address 172.20.1.0/24 any address 192.168.22.0/24 any {
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

Alice /etc/racoon/psk.txt

172.27.1.169  a9993e364706816aba3e

Bob /etc/racoon/racoon.conf

path pre_shared_key "/etc/racoon/psk.txt";

remote 172.27.1.165 {
        exchange_mode main,aggressive;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo address 192.168.22.0/24 any address 172.20.1.0/24 any {
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

Bob /etc/racoon/psk.txt

172.27.1.165  a9993e364706816aba3e

Security Policies

Alice /etc/ipsec-tools.conf

flush;
spdflush;

spdadd 172.20.1.0/24 192.168.22.0/24 any -P out ipsec
           esp/tunnel/172.27.1.165-172.27.1.169/require;

spdadd 192.168.22.0/24 172.20.1.0/24 any -P in ipsec
           esp/tunnel/172.27.1.169-172.27.1.165/require;

Bob /etc/ipsec-tools.conf

flush;
spdflush;

spdadd 192.168.22.0/24 172.20.1.0/24 any -P out ipsec
           esp/tunnel/172.27.1.169-172.27.1.165/require;

spdadd 172.20.1.0/24 192.168.22.0/24 any -P in ipsec
           esp/tunnel/172.27.1.165-172.27.1.169/require;

Run it

On both

/etc/init.d/setkey restart
/etc/init.d/racoon restart

On alice

ip addr add 172.20.1.1/24 dev eth0
ip route add to 192.168.22.0/24 via 172.20.1.1 src 172.20.1.1

On bob

ip addr add 192.168.22.1/24 dev eth0
ip route add to 172.20.1.0/24 via 192.168.22.1 src 192.168.22.1

The vpn will connect when you try to access the network, on alice:

ping 192.168.22.1

Exclude subnet example

Extending this example, here's how to exclude a subnet: connect to a larger network, while excluding a local subnet.


CategoryNetwork