Linux Kernel 2.6 using KAME-tools

Transport Mode

This section will first cover the setup of a manual keyed connection in transport mode. This is probably the best way to start because it is the simplest connection to setup. This section assumes that two machines with the IP addresses 192.168.1.100 and 192.168.2.100 communicate using IPsec.

All parameters stored in the SAD and the SPD can be modified using the setkey command. This command has a quite exhaustive man page. Therefore only the options needed for the setup of a connection in transport mode are covered here. setkey reads its commands from a file when invoked with setkey -f /etc/setkey.conf. A suitable /etc/setkey.conf file is shown in following listing.

#!/usr/sbin/setkey -f

# Configuration for 192.168.1.100

# Flush the SAD and SPD
flush;
spdflush;

# Attention: Use this keys only for testing purposes!
# Generate your own keys!

# AH SAs using 128 bit long keys
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 
0x96358c90783bbfa3d7b196ceabe0536b;

# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc 
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc 
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;
	

You will need some keys to replace the keys of this script, if you want to use the manually keyed connection for anything but testing purposes. Use a command such as the following to generate your keys:

$ # 128 Bit long key
$ dd if=/dev/random count=16 bs=1| xxd -ps
16+0 Records ein
16+0 Records aus
cd0456eff95c5529ea9e918043e19cbe

$ # 192 Bit long key
$ dd if=/dev/random count=24 bs=1| xxd -ps
24+0 Records ein
24+0 Records aus
9d6c4a8275ab12fbfdcaf01f0ba9dcfb5f424c878e97f888
	

Please use the device /dev/random when generating the keys because it ensures random keys.

The script first flushes the security association database (SAD) and the security policy database (SPD). It then creates AH SAs and ESP SAs. The command add adds a security association to the SAD and requires the source and destination IP address, the IPsec protocol (ah), the SPI (0x200) and the algorithm. The authentication algorithm is specified with -A (encryption using -E, compression using -C; IP compression is not yet supported). Following the algorithm the key must be specified. The key may be formatted in double-quoted “ASCII” or in hexadecimal with a leading 0x.

Linux supports the following algorithms for AH and ESP: hmac-md5 and hmac-sha, des-cbc and 3des-cbc. Within a short amount of time the following algorithms will probably be supported: simple (no encryption), blowfish-cbc, aes-cbc, hmac-sha2-256 and hmac-sha2-512.

spdadd adds the security policies to the SPD. These policies define which packets are to be protected by IPsec and which protocols and keys to use. The command requires the source and destination IP addresses of the packets to be protected, the protocol (and port) to protect (any) and the policy to use (-P). The policy specifies the direction (in/out), the action to apply (ipsec/discard/none), the protocol (ah/esp/ipcomp), the mode (transport) and the level (use/require).

This configuration file has to be created on both peers taking part in the IPsec communication. While the shown listing works without any change on the peer 192.168.1.100 it has to be slightly modified on the peer 192.168.2.100 to reflect the change of direction of the packets. The easiest way to do it is to exchange the directions in the security policies: replace -P in with -P out and vice versa. This is shown in the following listing:

#!/usr/sbin/setkey -f

# Configuration for 192.168.2.100

# Flush the SAD and SPD
flush;
spdflush;

# Attention: Use this keys only for testing purposes!
# Generate your own keys!

# AH SAs using 128 bit long keys
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5 
0x96358c90783bbfa3d7b196ceabe0536b;

# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc 
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc 
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;

# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P in ipsec
           esp/transport//require
           ah/transport//require;

spdadd 192.168.2.100 192.168.1.100 any -P out ipsec
           esp/transport//require
           ah/transport//require;
	

Once the configuration file is in place on the peers it can be loaded using setkey -f /etc/setkey.conf. The successful load can be tested by displaying the SAD and the SPD:

# setkey -D
# setkey -DP
	  

The setup resembles now the setup of Figure 4.

If you now ping from one peer to the other the traffic will be encrypted and tcpdump will show the following packets:

12:45:39.373005 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x1): 
ESP(spi=0x00000201,seq=0x1) (DF)
12:45:39.448636 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x1): 
ESP(spi=0x00000301,seq=0x1)
12:45:40.542430 192.168.1.100 > 192.168.2.100: AH(spi=0x00000200,seq=0x2): 
ESP(spi=0x00000201,seq=0x2) (DF)
12:45:40.569414 192.168.2.100 > 192.168.1.100: AH(spi=0x00000300,seq=0x2): 
ESP(spi=0x00000301,seq=0x2)
	

Tunnel Mode

Tunnel mode is used when the two peers using IPsec work as a gateway and protect the traffic between two networks (Figure 5). The original IP packets are encrypted and encapsulated by one gateway and transfered to it's peer. The peer will decapsulate the packet and will pass on the original unprotected packet.

The configuration of the security associations and policies for the tunnel mode is similar to the transport mode and is shown in the following listing.

#!/usr/sbin/setkey -f

# Flush the SAD and SPD
flush;
spdflush;

# ESP SAs doing encryption using 192 bit long keys (168 + 24 parity)
# and authentication using 128 bit long keys
add 192.168.1.100 192.168.2.100 esp 0x201 -m tunnel -E 3des-cbc 
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 
-A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6;

add 192.168.2.100 192.168.1.100 esp 0x301 -m tunnel -E 3des-cbc 
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df 
-A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b;

# Security policies
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Attention: When using the Linux kernel >= 2.6.10 you also have to define the forward policy if packets need to be fowarded by the box. Just make sure you use the ipsec-tools 0.5 which add this policy automatically or add it yourself if using older tools. If you are running setkey in Kernel-mode (-k) you have to add the fwd-policy manually, too.

spdadd 172.16.2.0/24 172.16.1.0/24 any -P fwd ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

This example uses only the ESP protocol. The ESP protocol can ensure integrity and confidentiality. In this case the order of the ESP algorithms is important. First you need to define the encryption algorithm and its key and secondly the authentication algorithm and its key.

For the peer of the tunnel you have to copy this file and to replace the direction of the policies (in vs. out). If you are using a forward policy, you have to additionally reverse the directions of the IP addresses.

In contrast to the BSD IPsec implementation a security association on Linux can only be used for either transport or tunnel mode. Transport mode is the default mode, so whenever tunnel mode is desired, the security association has to be defined with -m tunnel.

The security policies now specify the IP addresses of the protected networks. Packets using these source and destination IP addresses shall be protected by IPsec. Whenever the tunnel mode is used the security policy must specify tunnel and the IP addresses of the actual peers doing implementing the protection. This information is needed to find the appropiate IPsec SA.

If you tunnel is not working, please check your routing. Your hosts need to know that they should send the packets for the opposite network to you vpn gateway. The easiest setup would be using your vpn gateway as default gateway.

Preshared Keys

The easiest way to authenticate using racoon is the usage of preshared keys. These keys have to be defined in a file /etc/psk.txt. This file should not be read by unprivileged users (chmod 400 /etc/psk.txt) and has the following syntax:

# IPv4 Adressen
192.168.2.100          simple psk
5.0.0.1                0xe10bd52b0529b54aac97db63462850f3
# USER_FQDN
ralf@spenneberg.net    This is a psk for an email address
# FQDN
www.spenneberg.net     This is a psk
	

This file is organized in columns. The first column holds the identity of the peer authenticated by the psk. Everything starting in the second column is the PSK.

The configuration of racoon is straightforward. The following listing shows a typical /etc/racoon.conf configuration file:

path pre_shared_key "/etc/psk.txt";

remote 192.168.2.100 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

This configuration file first defines where racoon may find the preshared keys. It then defines a peer 192.168.2.100 and the parameters to use for the phase one of the IKE negotiation. The second paragraph specifies the parameters which may be used for the setup of the security associations. This definition may be specific for defined IP addresses or general using anonymous instead of the IP addresses. Here the encryption, authentication and compression algorithms to use for the SA are defined. All three need to be defined to avoid an error during the startup of racoon.

The IKE daemon racoon does not start the tunnel negotiation immediately when started. Rather racoon waits until the tunnel is needed. For this notification to occur the kernel needs to know when to notify racoon. To achieve this, the administrator needs to define security policies without the appropiate security associations. Whenever the Linux kernel needs to protect a packet according to the security policies and when no security association is available, the Linux kernel calls racoon and asks for the required security associations. Racoon will then start the IKE negotiations and will create the SAs when finished. The Linux kernel can then send the packets.

For the assumed setup the following policies are needed on 192.168.1.100:

#!/usr/sbin/setkey -f
#
# Flush SAD and SPD
flush;
spdflush;

# Create policies for racoon
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
	

Once the policies are loaded using setkey -f /etc/setkey.conf racoon may be started. For testing purposes racoon should be started using racoon -F -f /etc/racoon.conf. Again the configuration of the other peer has to be modified to reflect the different direction. The IP addresses in the files /etc/psk.txt, /etc/setkey.conf and /etc/racoon.conf must be exchanged.

The initiation of the tunnel can then be followed in the logs:

2003-02-21 18:11:17: INFO: main.c:170:main(): @(#)racoon 20001216 20001216
 sakane@kame.net
2003-02-21 18:11:17: INFO: main.c:171:main(): @(#)This product linked Open
SSL 0.9.6b [engine] 9 Jul 2001 (http://www.openssl.org/)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] use
d as isakmp port (fd=7)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 192.168.1.100[500]
 used as isakmp port (fd=9)
2003-02-21 18:11:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA r
equest for 192.168.2.100 queued due to no phase1 found.
2003-02-21 18:11:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new 
phase 1 negotiation: 192.168.1.100[500]<=>192.168.2.100[500]
2003-02-21 18:11:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Identit
y Protection mode.
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA es
tablished 192.168.1.100[500]-192.168.2.100[500] spi:6a01ea039be7bac2:bd288f
f60eed54d0
2003-02-21 18:11:39: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new p
hase 2 negotiation: 192.168.1.100[0]<=>192.168.2.100[0]
2003-02-21 18:11:39: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA establish
ed: ESP/Tunnel 192.168.2.100->192.168.1.100 spi=68291959(0x4120d77)
2003-02-21 18:11:39: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
 ESP/Tunnel 192.168.1.100->192.168.2.100 spi=223693870(0xd554c2e)
	

X.509 Certificates

Racoon supports the usage of X.509 certificates for the authentication process. These certificates may be checked against a certificate authority (CA). The configuration is similar to the PSK configuration and differs only on the authentication part:

path certificate "/etc/certs";

remote 192.168.2.100 {
        exchange_mode main;
        certificate_type x509 "my_certificate.pem" "my_private_key.pem";
	verify_cert on;
        my_identifier asn1dn;
	peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

The certificate and the private key are stored in the certificate path /etc/certs. This path is set using the option path certificate in the configuration file. The certificates and the certificate revocation lists are stored in PEM format as generated with openssl. For the generation of certificates see the chapter on X.509 certificates. If the certificate of the peer is to be checked against a certificate authority (verify_cert on; is the default), then the certificate of the CA has to be also stored in this directory. For OpenSSL to find the certificate it has to be renamed or linked using the hashed name:

ln -s CAfile.pem `openssl x509 -noout -hash < CAfile.pem`.0
	

If the certificate additionally is to be checked against a certificate revocation file (CRL) the CRL must be stored in the same directory using a similar linked hashed name:

ln -s CRLfile.pem `openssl x509 -noout -hash < CAfile.pem`.r0
	

When storing the certificates and the private key it is important to note that racoon cannot decrypt a private key. Therefore the private key must be stored in its decrypted cleartext form. If you created a crypted private key, you have to decrypt it:

# openssl rsa -in my_private_key.pem -out my_private_key.pem
read RSA key
Enter PEM pass phrase: password
writing RSA key
	

Roadwarrior

Roadwarriors are clients using unknown dynamic IP addresses to connect to a VPN gateway. In combination with racoon this poses two problems:

• The IP address is not known and cannot be specified in the racoon configuration file or in the /etc/psk.txt file. A different way to determine the identity of the client must be found. When using pre-shared keys this requires the aggressive mode! The best solution is the usage of X.509 certificates though.

• No security policy can be created for racoon to act on, since the destination IP address is not known. racoon must create the security policy and the security association when the connection is initiated.

To achieve this the configuration file /etc/racoon.conf needs several modifications:

path certificate "/etc/certs";

remote anonymous {
        exchange_mode main;
        generate_policy on;
        passive on;
        certificate_type x509 "my_certificate.pem" "my_private_key.pem";
        my_identifier asn1dn;
        peers_identifier asn1dn;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method rsasig;
                dh_group modp1024;
        }
}


sainfo anonymous {
        pfs_group modp1024;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
	

The option generate_policy on instructs racoon to create the appropriate policy when a new connection is initiated. The option passive on tells racoon to remain passive and wait for new connection to be started from the outside. racoon may not start a connection.

The most important change though is the definition of anonymous in the remote and sainfo line. This instructs racoon to accept the connection from anywhere.