IPSEC using Linux Kernel 2.6

Tom Eastep

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.

2004-08-21


Table of Contents

Shorewall 2.1 and Kernel 2.6 IPSEC
IPSec Gateway on the Firewall System
Mobile System (Road Warrior)
Transport Mode

Warning

To use this support, your kernel and iptables must include the Netfilter+ipsec patches and policy match support and you must be running Shorewall 2.1.5 or later.

Warning

As of this writing, the Netfilter+ipsec and policy match support are broken when used with a bridge device. The problem has been reported to the responsible Netfilter developer who has confirmed the problem.

Shorewall 2.1 and Kernel 2.6 IPSEC

This is not a HOWTO for Kernel 2.6 IPSEC -- for that, please see http://www.ipsec-howto.org/.

The 2.6 Linux Kernel introduces new facilities for defining encrypted communication between hosts in a network. The network administrator defines a set of Security Policies which are stored in the kernel as a Security Policy Database (SPD). Outgoing traffic is encrypted according to the contents of the SPD and incoming traffic is verified against the SPD to ensure that no unencrypted traffic is accepted in violation of the administrator's policies.

There are three ways in which IPSEC traffic can interact with Shorewall policies and rules:

  1. Traffic that is encrypted on the firewall system. The traffic passes through Netfilter twice -- first as unencrypted then encrypted.

  2. Traffic that is decrypted on the firewall system. The traffic passes through Netfilter twice -- first as encrypted then as unencrypted.

  3. Encrypted traffic that is passed through the firewall system. The traffic passes through Netfilter once.

In cases 1 and 2, the encrypted traffic is handled by entries in /etc/shorewall/tunnels (don't be mislead by the name of the file -- transport mode encrypted traffic is also handled by entries in that file). The unencrypted traffic is handled by normal rules and policies.

Under the 2.4 Linux Kernel, the association of unencrypted traffic and zones was made easy by the presense of IPSEC pseudo-interfaces with names of the form ipsecn (e.g. ipsec0). Outgoing unencrypted traffic (case 1.) was send through an ipsecn device while incoming unencrypted traffic (case 2) arrived from an ipsecn device. The 2.6 kernel-based implementation does away with these pseudo-interfaces. Outgoing traffic that is going to be encrypted and incoming traffic that has been decrypted must be matched against policies in the SPD.

Shorewall provides support for policy matching in two ways:

  1. In /etc/shorewall/masq, traffic that will later be encrypted is exempted from MASQUERADE/SNAT using existing entries. If you want to MASQUERADE/SNAT outgoing traffic that will later be encrypted, you must include an entry in the new IPSEC column in that file.

  2. A new /etc/shorewall/ipsec file allows you to associate zones with traffic that will be encrypted or that has been decrypted.

In summary, Shorewall 2.1.5 and later versions provide the facilities to replace the use of ipsec pseudo-interfaces in zone and MASQUERADE/SNAT definition.

There are two cases to consider:

  1. Encrypted communication is used to/from all hosts in a zone.

    The value Yes is placed in the IPSEC column of the /etc/shorewall/ipsec entry for the zone.

  2. Encrypted communication is used to/from only part of the hosts in a zone.

    The value No is placed in the IPSEC column of the /etc/shorewall/ipsec entry for the zone and the new ipsec option is specified in /etc/shorewall/hosts for those hosts requiring secure communication.

Note

For simple zones such as are shown in the following examples, the two techniques are equivalent and are used interchangably.

Finally, the OPTIONS, IN OPTIONS and OUT OPTIONS columns in /etc/shorewall/ipsec can be used to match the zone to a particular (set of) SA(s) used to encrypt and decrypt traffic to/from the zone and the security policies that select which traffic to encrypt/decrypt.

IPSec Gateway on the Firewall System

Suppose that we have the following sutuation:

We want systems in the 192.168.1.0/24 sub-network to be able to communicate with systems in the 10.0.0.0/8 network. We assume that on both systems A and B, eth0 is the internet interface.

To make this work, we need to do two things:

  1. Open the firewall so that the IPSEC tunnel can be established (allow the ESP and AH protocols and UDP Port 500).

  2. Allow traffic through the tunnel.

Opening the firewall for the IPSEC tunnel is accomplished by adding an entry to the /etc/shorewall/tunnels file.

In /etc/shorewall/tunnels on system A, we need the following

/etc/shorewall/tunnels — System A:

#TYPE         ZONE        GATEWAY             GATEWAY ZONE
ipsec         net         134.28.54.2
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/tunnels — System B:

#TYPE         ZONE        GATEWAY             GATEWAY ZONE
ipsec         net         206.161.148.9
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Note

If either of the endpoints is behind a NAT gateway then the tunnels file entry on the other endpoint should specify a tunnel type of ipsecnat rather than ipsec and the GATEWAY address should specify the external address of the NAT gateway.

You need to define a zone for the remote subnet or include it in your local zone. In this example, we'll assume that you have created a zone called “vpn” to represent the remote subnet.

/etc/shorewall/zones — Systems A and B:

#ZONE           DISPLAY         COMMENTS
net             Internet        The big bad internet
vpn             VPN             Virtual Private Network
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Remember the assumption that both systems A and B have eth0 as their internet interface.

You must define the vpn zone using the /etc/shorewall/hosts file.

/etc/shorewall/hosts — System A

#ZONE             HOSTS                  OPTIONS
vpn               eth0:10.0.0.0/8        ipsec
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/hosts — System B

#ZONE             HOSTS                  OPTIONS
vpn               eth0:192.168.1.0/24    ipsec
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Assuming that you want to give each local network free access to the remote network and vice versa, you would need the following /etc/shorewall/policy entries on each system:

#SOURCE          DESTINATION            POLICY          LEVEL       BURST:LIMIT
loc              vpn                    ACCEPT
vpn              loc                    ACCEPT

Once you have these entries in place, restart Shorewall (type shorewall restart); you are now ready to configure IPSEC.

Mobile System (Road Warrior)

Suppose that you have a laptop system (B) that you take with you when you travel and you want to be able to establish a secure connection back to your local network.

Example 1. Road Warrior VPN

You need to define a zone for the laptop or include it in your local zone. In this example, we'll assume that you have created a zone called “vpn” to represent the remote host.

/etc/shorewall/zones — System A

#ZONE           DISPLAY         COMMENTS
net             Internet        The big bad internet
vpn             VPN             Road Warriors
loc             local           Local Network (192.168.1.0/24)
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

In this instance, the mobile system (B) has IP address 134.28.54.2 but that cannot be determined in advance. In the /etc/shorewall/tunnels file on system A, the following entry should be made:

#TYPE         ZONE        GATEWAY             GATEWAY ZONE
ipsec         net         0.0.0.0/0           vpn
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Note

the GATEWAY ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the gateway system itself comprises the peer subnetwork; in other words, the remote gateway is a standalone system.

The VPN zone is defined using the /etc/shorewall/hosts file:

/etc/shorewall/hosts — System A:

#ZONE             HOSTS                  OPTIONS
vpn               eth0:0.0.0.0/0         ipsec
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

You will need to configure your “through the tunnel” policy as shown under the first example above.

Transport Mode

In today's wireless world, it is often the case that individual hosts in a network need to establish secure connections with the other hosts in that network. In that case, IPSEC transport mode is an appropriate solution.

Here's an example using the ipsec-tools package. The files shown are from host 192.168.20.10; the configuration of the other nodes is similar.

/etc/racoon/racoon.conf:

path pre_shared_key "/etc/racoon/psk.txt" ;

remote anonymous
{
        exchange_mode main ;
        my_identifier address ;
        lifetime time 24 hour ;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key ;
                dh_group 2 ;
        }
}

sainfo anonymous
{
        pfs_group 2;
        lifetime time 12 hour ;
        encryption_algorithm 3des, blowfish, des, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

/etc/racoon/setkey.conf:

# First of all flush the SPD database
spdflush;

# Add some SPD rules

spdadd 192.168.20.10/32 192.168.20.20/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.20/require;
spdadd 192.168.20.20/32 192.168.20.10/32 any -P in  ipsec esp/transport/192.168.20.20-192.168.20.10/require;
spdadd 192.168.20.10/32 192.168.20.30/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.30/require;
spdadd 192.168.20.30/32 192.168.20.10/32 any -P in  ipsec esp/transport/192.168.20.30-192.168.20.10/require;
spdadd 192.168.20.10/32 192.168.20.40/32 any -P out ipsec esp/transport/192.168.20.10-192.168.20.40/require;
spdadd 192.168.20.40/32 192.168.20.10/32 any -P in  ipsec esp/transport/192.168.20.40-192.168.20.10/require;

/etc/racoon/psk.txt:

192.168.20.20             <key for 192.168.20.10<->192.168.20.20>
192.168.20.30             <key for 192.168.20.10<->192.168.20.30>
192.168.20.40             <key for 192.168.20.10<->192.168.20.40>

Shorewall configuration goes as follows:

/etc/shorewall/zones:

#ZONE   DISPLAY         COMMENTS
net     Net             Internet
loc     Local           Local Network
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

/etc/shorewall/interfaces:

#ZONE   INTERFACE       BROADCAST       OPTIONS
net     eth0            detect          routefilter,dhcp,tcpflags
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

/etc/shorewall/tunnels:

#TYPE          ZONE             GATEWAY         GATEWAY
#                                               ZONE
ipsec:noah     net              192.168.20.0/24 loc

/etc/shorewall/ipsec:

#ZONE          IPSEC            OPTIONS             IN           OUT
#              ONLY                                 OPTIONS      OPTIONS
loc            Yes              mode=transport

/etc/shorewall/hosts:

#ZONE           HOST(S)                         OPTIONS
loc             eth0:192.168.20.0/24  
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE

It is worth noting that although loc is a sub-zone of net, because loc is an IPSEC-only zone it does not need to be defined before net in /etc/shorewall/zones.

/etc/shorewall/policy:

#SOURCE         DEST            POLICY          LOG LEVEL       LIMIT:BURST
fw              all             ACCEPT
loc             fw              ACCEPT
net             loc             NONE
loc             net             NONE
net             all             DROP            info
# The FOLLOWING POLICY MUST BE LAST
all             all             REJECT          info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

Since there are no cases where net<->loc traffic should occur, NONE policies are used.