Setting up an IPsec VPN using FreeS/WAN
-
Encapsulating Security Payload (ESP, RFC 2406), protocol number 50:
The ESP protocol encapsulates the payload of IP packets and protects them by encryption and authentication. This protocol is mandatory for VPNs. -
Authentication Header (AH, RFC 2402), protocol number 51:
The AH protocol provides authentication to the payload and some header fields of IP packets. This protocol is usually not used for VPNs, as the payload is not encrypted. -
Transport mode:
Only the original IP payload is encapsulated by inserting an AH or ESP header between the IP header and the original next header. This mode does not protect the original IP header and is not recommended for VPNs. -
Tunnel mode:
Both the original IP header and payload are encapsulated and protected by AH or ESP. This mode also allows the use of private source or destination addresses, as these are not contained in the encapsulating IP headers. Routing is performed by the security gateways (i.e. the tunnel end points). VPNs should be built using tunnel mode. -
Configure your kernel and make sure that /usr/src/linux points to the right kernel source tree.
# cd /usr/src # ln -s linux-2.4.17 linux # cd linux # make menuconfig
-
Download and untar the source tar ball freeswan-1.97.tar.gz from URL_VISIBLE(ftp://ftp.xs4all.nl/pub/crypto/freeswan/). The make menugo command will patch the kernel under /usr/src/linux, invoke make menuconfig therein, build and install the pluto daemon and ipsec utilities/configuration files under /usr/local and /etc, and invoke make bzImage and make modules in the kernel source tree.
# tar xzf freeswan-1.97.tar.gz # cd freeswan-1.97 # make menugo
-
Install the kernel and the kernel modules, and boot the new kernel.
# cd /usr/src/linux # cp System.map /boot/System.map-2.4.17 # cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.17 # make modules_install # vi /etc/lilo.conf # lilo # reboot
Author: MAIL_FSMLABS
Last updated: 17 Nov 2003
Copyright (c) 2002
MAIL_FSMLABS.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or any
later version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A
copy of the GNU Free Documentation License is included here.
Overview
The IPsec architecture (RFC 2401) defines a mechanism to provide authentication and optionally encryption of IP packets that is transparent to layers above the network layer. To this end, two new IP protocol types are defined:
IPsec packets are IP packets that encapsulate the original IP payload (usually UDP, TCP, or ICMP packets) and optionally the original IP header depending on the mode of operation:
Encryption and authentication of IP packets are achieved by symmetric mechanisms, i.e. they use the same (secret) key for encryption and decryption, and for authentication and verification, respectively. These keys may either be setup manually or established in a secure manner using ISAKMP (Internet Security and Key Management Protocol, RFC 2408), which is run on top of UDP port 500. ISAKMP is actually a framework for various key exchange mechanisms. Currently, only one such mechanism is defined, which is called Internet Key Exchange (IKE, RFC 2409).
The FreeS/WAN implementation of IPsec provides the ESP and AH protocols through the so-called KLIPS kernel patch and the user-space ISAKMP daemon called pluto. Version 1.97 of FreeS/WAN supports the 3DES cipher and the MD5 and SHA-1 hash functions, which can be regarded secure for VPNs from today's viewpoint. The IETF IPsec working group is currently developing standards for incorporating stronger ciphers (AES) and hash functions (SHA-256), as well as an improved IKE version (IKEv2).
The next few sections briefly describe how to setup a VPN between two private networks using FreeS/WAN. For a concise explanation of the installation and configuration steps see the documentation coming with the FreeS/WAN software or at the FreeS/WAN homepage.
Installing FreeS/WAN
The sample VPN
We assume the following sample network layout, whose configuration as a FreeS/WAN VPN is described below. All interface addresses shown have the same prefix 192.168. The VPN tunnel exists between the security gateways sgwA and sgwB. The interfaces of gw denote the default gateways (to the internet) of sgwA and sgwB, respectively. In reality, gw has to be replaced by the internet. The tunnel is transparent to both clients. In particular, the communication between clientA and sgwA (and between clientB and sgwB) is not protected by IPsec.
clientA ------ sgwA ======== gw ======== sgwB ------ clientB
| | | | | | | |
| eth1 eth0 | | eth0 eth1 |
.10.10 .10.1 .0.10 .0.1 .1.1 .1.11 .11.1 .11.11
Configuring and Testing FreeS/WAN
-
Before using IPsec, make sure that sgwA is reachable from sgwB and vice versa. It is a good idea to allow ICMP echo packets (ping) on both security gateways until FreeS/WAN is setup and running. Furthermore, gw must allow UDP port 500 and IP protocol 50 packets.
However, it is not necessary that any intermediate routers (gw) know of the client subnets, as IPsec packets will always be addressed to one of the security gateways -- provided that tunnel mode is used.
-
We want to use automatic keying via ISAKMP, that is, the keys which are used for encryption and authentication of packets are established by pluto running on both security gateways. To allow for authentication of the security gateways to each other for key establishment purposes, we choose to use a public-key mechanism (authentication based on pre-shared secret keys is also supported). To this end, we need to generate an RSA key pair on each security gateway.
sgwA # ipsec rsasigkey 1024 > /etc/ipsec.secrets sgwB # ipsec rsasigkey 1024 > /etc/ipsec.secrets
Now edit /etc/ipsec.secrets on both security gateways and insert a line at the beginning and at the end of the file as shown below. The first line must start at the first column, but all others (including the last one) must be preceded by white-space.
@sgwA: RSA { # RSA 1024 bits sgwA Thu May 30 10:26:12 2002 # for signatures only, UNSAFE FOR ENCRYPTION #pubkey=0x01036e6572ce4e7dd... ... }Of course, the /etc/ipsec.secrets file must be kept secret (mode 0600). In particular, it must not be transmitted over insecure channels. Usually, these files are generated locally on all security gateways and never need to be transmitted elsewhere.
-
Edit /etc/ipsec.conf on sgwA to include the following parameters (see ipsec.conf(5) for the meaning of each parameter):
config setup interfaces="ipsec0=eth0" klipsdebug=all plutodebug=all plutoload=%search plutostart=%search uniqueids=yes conn %default type=tunnel keyingtries=1 auth=esp authby=rsasig conn my-vpn # sgwA left=192.168.0.10 leftnexthop=192.168.0.1 leftsubnet=192.168.10.0/24 leftid=@sgwA leftrsasigkey=0x01036e6572ce4e7dd... # sgwB right=192.168.1.11 rightnexthop=192.168.1.1 rightsubnet=192.168.11.0/24 rightid=@sgwB rightrsasigkey=0x0103... auto=addThe klipsdebug, plutodebug, keyingtries and auto settings should be changed once the VPN is working. The leftrsasigkey parameter must be set to the pubkey value appearing in /etc/ipsec.secrets on sgwA (the line is several hundred characters long, but must not be split into multiple lines). Similarly, rightrsasigkey must be set to the public-key value of sgwB. Note that these values need not be kept secret.
The ipsec.conf syntax is designed to facilitate distribution of this file to security gateways. In our case, no changes are necessary. Just copy ipsec.conf to sgwB.
-
Now start the IPsec machinery and kick-off the session key negotiation.
sgwA # /etc/init.d/ipsec start sgwA # ifconfig ipsec0 ipsec0 Link encap:Ethernet HWaddr 00:60:6E:33:95:97 inet addr:192.168.0.10 Mask:255.255.255.0 inet6 addr: fe80::260:6eff:fe33:9597/10 Scope:Link UP RUNNING NOARP MTU:16260 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:3 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) sgwB # /etc/init.d/ipsec start sgwB # ifconfig ipsec0 sgwA # ipsec auto --up my-vpn 104 "my-vpn" #1: STATE_MAIN_I1: initiate 106 "my-vpn" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "my-vpn" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "my-vpn" #1: STATE_MAIN_I4: ISAKMP SA established 112 "my-vpn" #2: STATE_QUICK_I1: initiate 004 "my-vpn" #2: STATE_QUICK_I2: sent QI2, IPsec SA established sgwA # ipsec look sgwA Mon Jun 3 15:28:05 CEST 2002 192.168.10.0/24 -> 192.168.11.0/24 => tun0x1002@192.168.1.11 esp0x731a562b@192.168.1.11 (0) ipsec0->eth0 mtu=16260(1500)->1500 esp0x731a562b@192.168.1.11 ESP_3DES_HMAC_MD5: dir=out src=192.168.0.10 iv_bits=64bits iv=0xb43cfc7f91e6ce32 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(1077,0,0) esp0xb31290cc@192.168.0.10 ESP_3DES_HMAC_MD5: dir=in src=192.168.1.11 iv_bits=64bits iv=0xbd405fec25c28e97 ooowin=64 alen=128 aklen=128 eklen=192 life(c,s,h)=addtime(1077,0,0) tun0x1001@192.168.0.10 IPIP: dir=in src=192.168.1.11 life(c,s,h)=addtime(1077,0,0) tun0x1002@192.168.1.11 IPIP: dir=out src=192.168.0.10 life(c,s,h)=addtime(1077,0,0) Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 40 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0 192.168.10.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 ipsec0 192.168.11.0 192.168.0.1 255.255.255.0 UG 40 0 0 ipsec0The virtual network interface ipsec0 should be bound to the same IP address as the local external interface. Packets sent over the IPsec tunnel will be routed through ipsec0.
The ipsec look command shows some information about the security parameters negotiated by ISAKMP. You should see an esp... and tun... parameter identifier for each direction to and from the other security gateway, indicating that ESP is used in tunnel mode. Note that there is a route to the foreign client subnet via ipsec0.
-
To test the IPsec tunnel, try to ping clientB from clientA. Note that issuing a ping 192.168.1.11 on sgwA will not use the IPsec tunnel, as only the internal subnets are protected by this setup. However, the following command issued on sgwA will use the tunnel:
sgwA # ping -c 3 -I 192.168.10.1 192.168.11.1
Note also that this ping command should work even if gw does not forward ICMP echo packets, because these packets arrive encapsulated at gw. This can be verified by running tcpdump on gw while executing the ping command on clientA or sgwA.
gw # tcpdump -n -i eth1 src or dst 192.168.1.11 16:43:44.023816 192.168.0.10 > 192.168.1.11: ip-proto-50 116 16:43:44.024366 192.168.1.11 > 192.168.0.10: ip-proto-50 116 16:43:45.046806 192.168.0.10 > 192.168.1.11: ip-proto-50 116 16:43:45.047377 192.168.1.11 > 192.168.0.10: ip-proto-50 116 16:43:46.046698 192.168.0.10 > 192.168.1.11: ip-proto-50 116 16:43:46.047265 192.168.1.11 > 192.168.0.10: ip-proto-50 116
If you see the ip-proto-50 entries, then you know your tunnel is working. The six packets shown are the ESP-encapsulated ICMP echo packets.
Firewalling and NAT
TODO: Firewalling and NAT on security gateways needs to be evaluated in the testbed network.
If the security gateways are running firewalls (which usually is a good idea), the order in which incoming and outgoing packets enter the input, output, and forward filters must be known. This order depends on the filter mechanism used (ipchains or iptables). The basic mechanism is that incoming IPsec packets arrive at the real interface (eth0), go through the filters (unmodified), are processed (and decapsulated) by IPsec, and go through the filters again, this time appearing at the virtual IPsec interface (ipsec0).
Network address translation (NAT) is not necessary for IPsec tunnels, as the complete original IP header is encapsulated. If the security gateways need to forward non-IPsec traffic, NAT may be required and may lead to complications with IPsec.