An Introduction to FreeS/WAN, Part I

If you run SuSE with a stock kernel, simply install the package freeswan.rpm from the sec series. Make sure the kernel version of the ipsec.o module matches that of the SuSE kernel you run. The quick way to double-check your system's kernel version is with the command uname -av. To see the kernel version of your not-yet-installed freeswan.rpm package, use this command:

rpm -ql -p ./freeswan.rpm |grep ipsec.o

The kernel version will be indicated by the pathname to this file, e.g., /usr/lib/modules/2.2.18/ipv4/ipsec.o.

If the kernel versions match up, install the package with rpm, like this:

rpm -Uvh ./freeswan.rpm

Next, enable IPSec by opening /etc/rc.config and setting the variable START_IPSEC to “yes”.

Now it's time to replace the sample host key (RSA signing key pair) that was probably installed on your system by the FreeS/WAN RPMs. (If the creation date of /etc/ipsec.secrets is earlier than today's date, you need new keys.) The commands to do this for FreeS/WAN versions 1.92 and higher are:

mv /etc/ipsec.secrets /etc/ipsec.secrets.test
ipsec newhostkey --hostname
--output /etc/ipsec.secrets --bits 2192

You will, of course, replace my.host.FQDN with your host's fully qualified domain name, e.g., george.wiremonkeys.org.

For earlier versions of FreeS/WAN, use:

ipsec rsasigkey --hostname my.host.FQDN 2192 \
> /etc/ipsec.newkey

If you use the ipsec rsasigkey command, you'll also have to open /etc/ipsec.secrets with a text editor and replace everything between the curly brackets ({}) with the contents of ipsec.newkey (or whatever file to which you cat'd the new key).

Even though you haven't configured it yet, you may now test FreeS/WAN by starting and querying it:

/etc/init.d/ipsec start
ipsec whack --status

If the second command (ipsec whack --status) returns 000, your FreeS/WAN installation is working properly.

If you run Red Hat 7.3 with its stock kernel (version 2.4.18 as of this writing), download the appropriate IPSec-enabled kernel package from rpms.steamballoon.com/freeswan. You should grab the binary or source package for freeswan. Install the kernel package first.

If you've already got a stock kernel package installed (and it's almost certain that you do) you'll need to use the --force option, because Steamballoon's FreeS/WAN kernel package's base name (simply, kernel) is the same as that of the official Red Hat stock kernel. On my Celeron-based Red Hat 7.3 system, I installed the Steamballoon kernel package like this (all version numbers in examples are probably obsolete already):

rpm --force -i ./kernel-2.4.18-3ipsec.i686.rpm

Don't worry about forcing the install; the names of the new kernel's image file and module directory are unique and will not overwrite your old kernel. For example, on my Red Hat 7.3 system, the new image file and module directory are named /boot/vmlinuz-2.4.18-3ipsec and /lib/modules/2.4.18-3ipsec, respectively. Steamballon's RPM post-installation script overwrote the boot menu entry in /boot/grub/grub.conf for my old kernel with one for the new IPSec kernel (i.e., it removed the old kernel from the boot menu). But after I re-added a menu entry for the old kernel, I could choose either entry at boot time with no problem.

After you've installed the kernel package, install the user-space tools. On my system the command was:

rpm -i freeswan-1.97-0.i386.rpm

This RPM installs a startup script, /etc/init.d/ipsec, but does not enable it. You can do so like this:

chkconfig --add ipsec

This month, I have enough space to cover only one common FreeS/WAN scenario: wireless LAN tunneling, as illustrated in Figure 2. Figure 4 shows part of the network from Figure 2, this time with IP addresses. In this example, the wireless client system is dynamically IP addressed. As we'll see shortly, you don't need to know the IP addresses of all potential clients.

Figure 4. Wireless VPN with IP Addresses

The rest of this article depends on several important assumptions: 1) basic network connectivity is already in place, so wireless clients can connect to the Linux server; 2) basic packet forwarding works—the wireless clients can reach hosts on the other side of the wireless gateway; and 3) the gateway is not yet acting as a firewall.

I make the third assumption strictly for expediency's sake. Good security comes in layers, and it costs you nothing (other than a little setup time) to restrict where incoming VPN traffic may and may not go. Unfortunately, I can't go into much depth here; see the “FreeS/WAN quick start on firewalling” HOWTO at www.freeswan.org/doc.html for more information.