IPsec can operate in two different modes. Transport mode is used to send protected traffic between two nodes. A gateway between two endpoints cannot perform transparent mode encryption. In transparent mode, a new header is placed on the original IP packet to allow for the cryptographic functions to be applied to the packet. An IPsec connection can also be made in tunnel mode. A tunnel connection encapsulates an entire IP packet within another IP packet. This allows an intermediate gateway to provide IPsec protection to an entire network. Tunnel mode is the appropriate mode for a VPN connection between a station and egress gateway. The rest of the discussion here will focus on tunnel mode connections.

There are two protocols at the core of IPsec. Authenticated Header (AH) provides authentication and integrity verification of an IP packet. It does not provide confidentiality for the data contained within a packet. Encapsulated Security Payload (ESP) provides confidentiality of the data contained. ESP and AH can be used on their own or in conjunction depending on your security requirements. Given the risk posed by using a wireless network, it is recommended that both protocols be used.

A Security Association (SA) is a unidirectional relationship between two IPsec peers. In order for traffic to flow back and forth between two hosts within an IPsec tunnel, an SA must exist for each direction. The SA includes information about what type of connection exists, what cryptographic algorithms are being utilized, and the keys that are used. A Security Policy Database (SPD) is a list of all security policies installed on a machine. A security policy is a description of a unidirectional connection between two peers including networks to be sent over the IPsec connection and whether the connection should be secured with AH or ESP or both.

Setting up an SA by hand can be a difficult and time-consuming task. Setting up multiple SAs for multiple hosts on a network would be down right annoying. Thankfully, the Internet Key Exchange protocol (IKE) can handle the creation of SAs for us. IKE is the result of several protocols and procedures being unified under one protocol. IKE configuration can get extremely complicated when interoperating between two different IPsec implementations. For your wireless network, keep it simple and get everything working first. Once your IPsec connection is up and running, then tune IKE.

In a general-purpose wireless network, the wireless medium is the least trustworthy part of the entire flow between two hosts. In order to overcome this, IPsec can be run on all stations in tunnel mode with ESP and AH for both authentication and confidentiality. The termination of the tunnel is the network gateway, usually a firewall. Even if an attacker breaks your WEP key, the IPsec protection should protect at least the payload of your traffic from being decrypted.

Using IPsec with IKE under FreeBSD requires enabling IPsec in the kernel as well as installing a userland program, racoon, to handle the IKE negotiations.

Compile a custom kernel with IPsec support:

options         IPSEC                   #IP security
options         IPSEC_ESP               #IP security (crypto; define w/ IPSEC)
options         IPSEC_DEBUG             #debug for IP security

Build and install the kernel. Reboot to verify it works.

racoon can be installed using the network section of the ports tree or can be downloaded from ftp://ftp.kame.net/pub/kame/misc/. Install racoon per the instructions provided with the distribution at http://www.kame.net/, and in particular http://www.kame.net/newsletter/20001119/.

On the station, first you should configure racoon. You will need to modify this example racoon.conf to suit your needs:

path include "/usr/local/etc/racoon" ;
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
remote anonymous
{
        exchange_mode aggressive,main;
        my_identifier user_fqdn "[email protected]";
        lifetime time 1 hour;
        initial_contact on;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}
sainfo anonymous
{
        pfs_group 1;
        lifetime time 30 min;
        encryption_algorithm 3des ;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate ;
}

In your firewall configuration, be sure you allow IKE connections to your machine. racoon needs to be configured to start at boot time. Save the following script in /usr/local/etc/rc.d/racoon.sh:

#!/bin/sh
# This script will start racoon in FreeBSD
case "$1" in
start)
# start racoon
   echo -n 'starting racoon'
   /usr/local/sbin/racoon
   ;;

stop)
# Delete the MAC address from the ARP table
   echo 'stopping racoon'
   killall racoon
   ;;
*)
# Standard usage statement
   echo "Usage: `basename $0` {start|stop}" >&2
   ;;
esac

exit 0

Make sure the file is executable by performing

chmod 755 /usr/local/etc/rc.d/racoon.sh

The /usr/local/etc/racoon/psk.txt file contains your credentials. This file must be readable only by root. If the permissions are not set correctly, racoon will not function. For a shared-secret IPsec connection, the file contains your identification (in this case your email address) and the secret. For instance, you can setup a psk.txt as the following:

[email protected]     supersecret

Finally, you must set up the security policy. This is done using the setkey utility to add entries to the kernel SPD. Create the following client.spd that can be loaded by setkey. For this setup, the station IP is 192.168.0.104 and the gateway is 192.168.0.1:

spdadd 192.168.0.104/32 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.0.104-192.168.
0.1/require ; 
spdadd 0.0.0.0/0 192.168.0.104/32 any -P in ipsec esp/tunnel/192.168.0.1-192.168
.0.104/require ;

The first entry creates a security policy that sends all traffic to the VPN endpoint. The second entry creates a security policy that allows all traffic back from the VPN endpoint. Note that in this configuration the client is unable to talk to any hosts on the local subnet besides the VPN gateway. In a wireless network where the client is a prime target for attack, this is a probably a good thing for your workstation.

Load the SPD by running:

 setkey -f client.spd

For the gateway, racoon.conf is the same as the client side. This allows any client to connect. The psk.txt file must contain all the identification and shared secrets of all clients who may connect. For instance:

[email protected]      supersecret
[email protected]      evenmoresecret
[email protected]      notsosecret

Again, make sure psk.txt is readable only by root. Start racoon and make sure there are no errors. Finally, create a gateway.spd that creates SPD for each client. Assume your clients are at 192.168.0.10[4-6]:

spdadd 0.0.0.0/0 192.168.0.104/32 any -P out ipsec esp/tunnel/192.168.0.1-192.168
.0.104/require ; 
spdadd 192.168.0.104/32 0.0.0.0/0 any -P in ipsec esp/tunnel/192.168.0.104-192.168.0.
1/require ; 
spdadd 0.0.0.0/0 192.168.0.105/32 any -P in ipsec esp/tunnel/192.168.0.1-192.168
.0.105/require ; 
spdadd 192.168.0.105/32 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.0.105-192.168.
0.1/require ; 
spdadd 0.0.0.0/0 192.168.0.106/32 any -P in ipsec esp/tunnel/192.168.0.1-192.168
.0.106/require ; 
spdadd 192.168.0.106/32 0.0.0.0/0 any -P out ipsec esp/tunnel/192.168.0.106-192.168.
0.1/require ;

Load the SPD by issuing setkey -f gateway.spd. Verify the SPD entries using the spddump command in setkey. At this point, you should be able to ping a wireless client from the gateway. It may take a packet or two for the VPN negotiation to complete, but the connection should be solid after that. If you are unable to ping, examine your syslog output for errors and warnings.

The most popular way of configuring IPsec connections under Linux is using the FreeS/WAN package. FreeS/WAN is made up of two components similar to the FreeBSD implementation. KerneL IP Security (KLIPS) is the kernel level code that actually encrypts and decrypts the data as well as managing the SPD. pluto is a userland daemon that controls IKE negotiation. Unlike FreeBSD, both the kernel-level code and userland tools come from outside the core kernel distribution.

The FreeS/WAN build process will build a new kernel and the required management utilities. Download the latest FreeS/WAN source from http://www.freeswan.org/ and untar the source tree in /usr/src. The documentation that comes with FreeS/WAN is very extensive and can help you tailor the installation to suit your needs. The kernel component can be installed as either a kernel loadable module or statically compiled directly into your kernel. In order to compile FreeS/WAN, you must have your kernel source installed on your machine. During the compilation process, the kernel configuration utility will launch. This is normal. Compile FreeS/WAN using your kernel configuration method of choice (such the menu-based or X11-based options). Once the compilation is complete, install the kernel and userland tools per the FreeS/WAN documentation (typically a make install will suffice).

FreeS/WAN configuration is controlled by two configuration files: /etc/ipsec.conf and /etc/ipsec.secrets. The examples given in this section are very limited in scope to a wireless network. The man pages for both files are quite informative and useful for more complicated connection requirements. An excellent resource for more information is the book Building Linux Virtual Private Networks, by Oleg Kolesnikov and Brian Hatch.

The ipsec.conf file breaks a VPN connection into a right- and left-hand segment. This difference is merely a logical division. The left hand side can be either the internal or external network. This allows the same configuration file to be used for both ends of a VPN network-to-network tunnel. Unfortunately in our case, there will be differences between the client and gateway configurations.

The file is broken up into a configuration section (config) and a connection section (conn). The config section specifies basic parameters for IPsec such as available interfaces as well as specific directives to be passed to pluto. The conn section describes the various connections that are available to the VPN. There is a global conn section (conn %default) where you can specify values that are common to all connections such as the lifetime of a key and the method of key exchange.

The following ipsec.conf encrypts all information to the Internet with a VPN endpoint on your gateway:

# /etc/ipsec.conf
# Set configuration options
config setup
     interfaces=%defaultroute
     # Debug parameters.  Set either to "all" for more info
     klipsdebug=none
     plutodebug=none
     # standard Pluto configuration
     plutoload=%search
     plutostart=%search
     # make sure there are no PMTU Discovery problems
     overridemtu=1443
# default configuration settings
conn %default
     # Be aggressive in rekeying attempts
     keyingtries=0
     # use IKE
     keyexchange=ike
     keylife=12h
     # use shared secrets
     authby=secret
# setup the VPN to the Internet
conn wireless_connection1
     type=tunnel
     # left is the client side
     left=192.168.0.104
     # right is the internet gateway
     right=192.168.0.1
     rightsubnet=0.0.0.0/0
     # automatically start the connection
     auto=start

Now add the shared secret to ipsec.secrets:

192.168.0.104 192.168.0.1: PSK "supersecret"

That is it. Once your gateway is configured, try to ping your default gateway. pluto will launch automatically and the connection should come up. If you have a problem reaching the gateway, check the syslog messages on both the client and gateway.

The gateway configuration is largely the same as the client configuration. Given the intelligence of the ipsec.conf file, there are very few changes that need to be made. Since your gateway has more than one ethernet interface, you should hard-set the IPsec configuration to use the right interface:

# assume internal ethernet interface is eth0
interfaces="ipsec0=eth0"

You will then need to add a connection for each internal client. This can be handled in different ways as your network scales, but this configuration should work for a reasonable number of clients:

...
conn wireless_connection2
     type=tunnel
     left=192.168.0.105
     right=192.168.0.1
     rightsubnet=0.0.0.0/0
     auto=start
conn wireless_connection3
     type=tunnel
     left=192.168.0.106
     right=192.168.0.1
     rightsubnet=0.0.0.0/0
     auto=start
...

Finally, add the shared secrets for all the clients to ipsec.secrets:

192.168.0.105 192.168.0.1: PSK "evenmoresecret"
192.168.0.106 192.168.0.1: PSK "notsosecret"

Clients should now be connecting to the Internet via a VPN tunnel to the gateway. Check the log files or turn up the debug level if the tunnel does not come up.