Technically, FreeS/WAN contains two modules:

FreeS/WAN Configuration
The three most common VPN configurations with FreeS/WAN (and IPSec in general) are:

Depending on your local network configuration, additional scenarios are possible:

There are some network configuration prerequisites that you must check before installing FreeS/WAN. First, enable TCP/IP forwarding on all FreeS/WAN gateway servers. Second, the IPSec gateway should have packet filters rules in the firewall script file permitting the following protocols to traverse three kinds of packets (if you use firewalling, of course):

Install FreeS/WAN source code and integrate it with your kernel source code. It adds an "IP Security Protocol (FreeS/WAN IPSEC)" section under the "Networking Options" section of the kernel configuration interface (see Figure 2). FreeS/WAN documentation includes step-by-step instructions for compiling and installing tools. When installation is complete, check to see whether FreeS/WAN code is properly integrated into kernel. You can do this with the "dmesg" command:

zeus# dmesg | grep ipsec
klips_info:ipsec_init: KLIPS startup, FreeS/WAN
IPSec version: 2.00

All FreeS/WAN configuration parameters are in "/etc/ipsec.conf". You need to change the default values to fit your configuration and topology. "ipsec.conf" contains two sections that apply to all connections: "conn setup", which describes FreeS/WAN machine configuration, and "conn %default", which defines default parameters that apply to all connections. The "ipsec.conf" example shown in Listing 1 defines an end-to-end VPN.

The "conn" sections that will define connections to be made using FreeS/WAN follow. The connection definition takes precedence over the "%default" section. Listing 2 shows an example connection section definition between two gateways (named "zeus" and "athena").

When you have a connection definition ready, the next step is to define a secret to be used for authentication between gateways.

Authentication Issues
FreeS/WAN (like all IPSec implementations) supports two types of connection authentication: manually keyed and automatically keyed (also called perfect forward secrecy or PFS). Manually keyed connections use keys stored in the "/etc/ipsec.conf" file. Automatically keyed connections use keys automatically generated by the Pluto key negotiation daemon. The key negotiation protocol used by default, IKE, authenticates the other system using shared secrets stored in "/etc/ipsec.secrets" file. The better (more secure) solution is to use automatically keyed connections, of course.

The "ipsec.secrets"file stores the secrets used by the Pluto daemon to authenticate communication between both gateways. Several kinds of secrets can be configured in this file: pre-shared key, RSA private keys, and X.509 certificates, which require patching FreeS/WAN sources. An example for pre-shared keys is included in the "ipsec.secrets" file that comes with FreeS/WAN source code.

Pre-Shared Key (PSK)
The pre-shared keys are simply predefined byte strings used for authentication. Of course, both gateways must utilize this same PSK. FreeS/WAN uses PSK for authentication by default, and you can always revert to PSK at any time by adding the following option to your connection definition in "ipsec.conf":

authby=secret

You also need to change the default PSK line in the "ipsec.secrets" file to add the IP addresses for VPN gateways. Last, add preshared keys; the most to use is "ipsec ranbits" command that generates random keys. The result (in "ipsec.secrets") may look something like:

10.0.0.50 10.0.0.72: PSK
"0xaac1c79e_26cb7583a_83e"

RSA Private Keys
The most useful authentication in FreeS/WAN uses RSA keys that can be used by the Pluto daemon on FreeS/WAN gateways. Authentication by RSA signatures requires that each host have its own private key and export its public key. You need to create a separate RSA key for each gateway. Each holds its own private key in the "ipsec.secrets" file, and the public key goes to the "leftrsasigkey" and "rightrsasigkey" parameters in the connection description section in the "ipsec.conf" file. You can generate RSA keys for host with the following command:

zeus# ipsec rsasigkey --verbose 1024 > zebra-RSAkeys

The "rsasigkey" utility generates an RSA public and private key pair of a 1024- bit signature and puts it in the file "zeus- RSA-keys". The file includes both keys with appropriate comments so you can easily separate the private key from the public key. The private key should be inserted into the "ipsec.secrets" file, and the public key into the "ipsec.conf" file. Don't forget to delete temporary files (from the "/tmp" directory) after key generation. Now add the RSA secret definition to your connection definition section in "ipsec.conf":

authby=rsasig

Insert the RSA public keys for both gateways into the connection definition in "ipsec.conf":

leftrsasigkey=<Public key of zeus>
rightrsasigkey=<Public key of athena>
auto=start

Next, modify "ipsec.secrets" on each gateway to include its RSA private key. The "/etc/ipsec.secrets" file should have permissions set to 600 and be owned by root user. The "/etc/ipsec.conf" file is installed with permissions mask 644 and must be also owned by root. The other question is how to deliver public keys to gateways that you want to establish secure communication with. There are three ways to do this:
1.  Put public keys in the connection descriptions in the "/etc/ipsec.conf" file (use "ipsec showhostkey --left" [or "-- right"] to extract the public key prepared for "ipsec.conf" insertion).
2.  Place the public key in DNS records (if you use "ipsec showhostkey" you'll get the public key in a format suitable for KEY and TXT records in DNS).
3.  Use X.509 certificates or PGP keys for storing public (and also private) keys and implement a third-party patch on FreeS/WAN (see resources). Using X.509 certificates is most useful if your organization utilizes PKI (Public Key Infrastructure) and you can use it for generating trusted certificates for FreeS/WAN authentication. The MS Certificate Authority and Domino built-in Certificate Authority are examples of inexpensive CA servers that you may use with FreeS/WAN. If you don't have PKI or at least CA server, you can always generate self-signed certificates with the OpenSSL package.

FreeS/WAN Interoperability
IPSec has been designed to work in heterogeneous VPN environments and is supported by major firewall software and hardware vendors, including Apple, Microsoft, Sun, Cisco Systems, Check Point, Nortel Networks, Lucent, IBM, and Alcatel. Unfortunately, interoperability between IPSec products is still the problem. You must realize that many third-party products will require some tweaking to work with FreeS/WAN because it's not completely compliant with the IPSec IETF RFC specification.

FreeS/WAN works out of the box with Cisco routers (IOS 12.0 or later), Nortel Switches, OpenBSD, Check Point FW-1/NG, SSH Sentinel VPN, F-Secure VPN, Xedia Access Point, PGPnet, IRE SafeNet/SoftPK, Freegate, Borderware, Intel Shiva LANRover, Windows 2000/XP, and Sun Solaris. When you try to connect FreeS/WAN products other than those listed with IPSec, first check whether your product supports 3DES. Detailed instructions can be found on the FreeS/WAN Web site, and documentation is included with the FreeS/WAN distribution.

Summary
Thanks to FreeS/WAN you can set up an IPSec VPN connection in a short time. FreeS/WAN is stable solution developed over many years, and commercial IPSeccompatible products will cooperate with it. FreeS/WAN is a cheap and flexible solution for building advanced VPN topology. Best of all, it's open source, so you can even improve the way it works.

Resources

Source Code

Listing 1

config setup
interfaces="ipsec0=eth0"
# specifies network interfaces for IPSec to use.
klipsdebug=none
plutodebug=none
#Two above lines specifies the debugging output for KLIPS and for the Pluto.
plutoload=%search
# The value %search loads all defined connections with auto=add or auto=start parameters.
plutostart=%search
conn %default
keyingtries=0
disablearrivalcheck=0
authby=rsasig
# We use RSA keys for authentication. See below
auth=ah
# This option specifies whether authentication should be done separately using AH (Authentication Header), or be included as part of the ESP - Encapsulated Security Payload service.
auto=start
# This option specifies whether automatic startup operations should be done at IPSec startup.

Listing 2

conn zeus-athena
# left host - this is 'zeus'. 'ipsec.conf' uses left-right notation for more intuitive
gateways distinction
left=10.0.0.50
# next hop to reach right - this should ge used if
# right host - this is 'athena'
right=10.0.0.72
# manual encryption/authentication algorithm and parameters to it
# here we use ESP with 3DES and MD5
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]