IPSec (Internet Protocol SECurity) is an extension to the Internet Protocol (IP) that provides authentication and encryption. IPSec uses strong cryptography to provide both authentication and encryption services intended for building Virtual Private Networks (VPN).
In fact, IPSec is a peer-to-peer protocol that allows you to build secure tunnels through untrusted networks like the Internet. Everything passing through this network is encrypted by the IPSec gateway machine and decrypted by the gateway at the other end. The result is a VPN because IPSec allows building networks that are effectively private, even though it includes machines at several different sites connected by the insecure Internet (or another network). IPSec is an industry standard described in a series of IETF's (Internet Engineering Task Force) RFC (Request For Comments) documents – RFC2402, RFC2406, and RFC2408 – and is also widely accepted by vendors and developers. Originally, IPSec was designed for IPv6, but it's currently being deployed mostly for IPv4. IPSec services (authentication and encryption) are implemented at the IP level of the protocol stack; therefore, IPSec can protect any protocol running above IP and any medium used below IP. Of course, IPSec provides security services in the background, with no visible impact on applications because the authentication and encryption occur at the IP level.
Most IPSec implementations are commercial products, but thanks to the FreeS/WAN package Linux administrators can build up VPN based on IPSec. FreeS/WAN is an open source implementation of IPSec for Linux that is compliant with the IETF's IPSec specification. It does not yet implement all of IPSec, but everything it does follows the IPSec RFCs. FreeS/WAN, including the full source code, is available under GPL license. Thanks to the FreeS/WAN package, Linux becomes an attractive platform for building IPSec-based VPN gateways.
Unfortunately, FreeS/WAN code cannot be distributed with standard Linux kernel source because the export laws of some countries (not only the U.S.) restrict the distribution of strong cryptography. However, there are a few Linux distributions that include FreeS/WAN support: SuSE Linux (www.suse.com), Connectiva Linux (www.connectiva.com.br), and Trustix Secure Linux (www.trustix.net). If your Linux distribution isn't on this list, you'll need to download and compile FreeS/WAN for yourself.
FreeS/WAN Services
IPSec– (and then FreeS/WAN) based VPNs are built upon two services: authentication and encryption. These can be used separately in theory, but in real life they're used together. Authentication allows you to be confident that a packet came from a particular machine and that its contents were not altered en route to you. Authentication service doesn't protect transmission of content.
Authentication can be provided separately using a special Authentication Header (AH), or it can be included as part of the service that offers encryption (this is called Encapsulated Security Payload [ESP], defined in RFC 2406). In most configurations authentication uses keys that are automatically negotiated (and periodically renegotiated) using the IKE (Internet Key Exchange) protocol.
Encryption service prevents the unauthorized reading of packet contents. In IPSec this is done using a block cipher (3DES and MD5 in FreeS/WAN). FreeS/WAN also supports ESP encryption service. ESP provides encryption and/or authentication. It may be used with or without AH authentication. FreeS/WAN can work in the following IPSec modes:
AH: Authentication only, no content encryption.
ESP: Encryption only, no authentication.
ESP: Authentication and encryption together; this is the recommended and most commonly used configuration.
AH + ESP: Double authentication.
Technically, FreeS/WAN contains two modules:
KLIPS (KerneL IPSec): Implements AH, ESP, and packet handling within the Linux kernel.
Pluto daemon: Implements IKE, negotiating connections with other gateways and performing other high-level tasks. Pluto calls KLIPS kernel code.
FreeS/WAN Configuration
The three most common VPN configurations with FreeS/WAN (and IPSec in general) are:
End-to-end VPN: Two end hosts communicate through an IPSec connection. This is the simplest configuration and is used often.
Node-to-end VPN: The client machine is connected to the intranet through an IPSec gateway, e.g., mobile VPN clients (see Figure 1).
Node-to-node VPN: The two private networks communicate through an IPSec gateway using an unsecure network (i.e., the Internet); VPN gateways decrypt communication on the intranet side.
Depending on your local network configuration, additional scenarios are possible:
"Road Warrior" configuration: When the remote host doesn't have fixed IP address.
Opportunistic encryption: This doesn't rely on any prearranged connection and doesn't require that the administrators of the gateways involved communicate with each other. Each gateway checks the destinations of outgoing packets to see if an encrypted connection is possible, and if so, takes the opportunity to encrypt.
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):
UDP port 500 for IKE implemented by the Pluto daemon
Non-IP protocol 50 for ESP encryption and/or authentication (see "etc/protocols")
Non-IP protocol 51 for AH packet-level authentication (see "/etc/protocols")
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
FreeS/WAN VPN: www.freeswan.org
IPSec white papers: www.vpnc.org/white-papers.html
Patches for X.509 certificate support: www.strongsec.com/freeswan/
Patch for IPv6 support: www.ipv6.iabg.de/downloadframe/index.html
Hardware acceleration for FreeS/WAN: http://sources.colubris.com/en/projects/FreeSWAN/
All standards and official documents regarding IPSec collected by IPSec Working Group: www.ietf.org/html.charters/ipsec-charter.html
Configuring FreeS/WAN with X.509 certificates: www.natecarlson.com/linux/ipsecx509.php
Using Windows 2000/XP as VPN client for FreeS/WAN: http://vpn.ebootis.de
Setting IPSec on Mac OS X for connecting FreeS/WAN: www.slackwerks.com/thecrew/arete/soekris/macosx-ipsec.html
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]
Subscribe to Linux Email News Alerts
Subscribe via RSS
