openswan [Lnk: OSW] [Lnk: NCa]

Racoon has some problems, but there are some reasons why you might want to stick with it:

• You don't want to use Linux as your VPN-Server but a BSD-variant, for example.
• You don't care about NAT-Traversal issues in Transport Mode with racoon.
• NAT-T support for Racoon is already implemented, when you read this.

Otherwise Openswan is the ISAKMP daemon I chose. Several reasons led to this decision:

• Support for Certificate Revocation Lists (CRL) to revoke certificates
• Easy configuration Syntax
• Support for NAT-Traversal (Road Warriors behind NATed networks)
• Good documentation and support can be found on the Internet
• My personal experience with openswan: more rock-solid than racoon

Openswan does nothing differently compared to racoon, it is an ISAKMP daemon. The wonderful thing about openswan and Linux 2.6 is, that you don't need to patch your kernel to work with openswan. Openswan is fully compatible to the 2.6sec implementation. All you need to get openswan working, is the user-land daemon itself. If you want to use kernel 2.4 and openswan, you have to patch the kernel with the openswan kernel patches.

The creation of the config-file requires some tweaking and patience, and some help from the Internet [Lnk: JDL].

My sample configuration file for support for various road warriors looks like this (/etc/ipsec.conf):

version 2.0config setup

       interfaces=%defaultroute

       forwardcontrol=yes

       nat_traversal=yes

       virtual_private=%v4:10.0.0.0/8,\

            %v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default

       keyingtries=1

       compress=yes

       disablearrivalcheck=no

       authby=rsasig

       leftrsasigkey=%cert

       rightrsasigkey=%cert

       pfs=no

conn roadwarrior-l2tp-updatedwin

       pfs=no

       leftprotoport=17/1701

       rightprotoport=17/1701

       also=roadwarrior

conn roadwarrior-l2tp

      pfs=no

      leftprotoport=17/0

      rightprotoport=17/1701

      also=roadwarriorconn 

macintosh-l2tp

       pfs=no

       leftprotoport=17/1701

       rightprotoport=17/%any

       also=roadwarriorconn 

roadwarrior

       left=%defaultroute

       leftcert=vpn1.company.net.pem

       right=%any

       auto=add

       type=transport

Very Important: Indentations matter. Therefore do a tab-indentation for the indented lines, if you would copy my sample config-file.

• Left and right defines server-side and client-side. Left in my example stands for the server, and right for the clients.
• The auto=add configuration parameter enables the configuration section. Without this, you would be forced to 'start' this section by hand, which would not really become handy on a production server.
• The also configuration-parameter includes additional sections (works like #include in c).
• Openswan is able to identify the different clients on the behavior, how they send packets. It is visible in my example, that macintosh computer behave different than windows-computers.
• PFS stands for perfect forwarding secrecy, which would enable encryption algorithms, where penetration of the key-exchange protocol would not compromise keys negotiated earlier. Unfortunately, Windows does not support this without hacking the registry. ^2.2

Certificate files have to be copied to /etc/ipsec.d/ into the appropriate directories. Openswan also supports a password-protected private key file, but you have to type that secret password in a file (/etc/ipsec.secret) in clear-text anyway.

Openswan requires the ipsec-tools. It is poorly documented, but one has to flush the SA entries in the kernel after starting openswan. To start openswan, one might enter the following command in order to maintain connectivity to the openswan box:

/etc/init.d/ipsec start; sleep 5; setkey -FP

Of course this has to be tweaked in the startup-scripts, too. Important: Openswan logs to /var/log/secure, not /var/log/daemon or similar files.