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

The 2.6 Linux Kernel introduced 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). Security policies determine which traffic is subject to encryption. Security Associations are created between pairs of hosts in the network (one SA for traffic in each direction); these SAs define how traffic is to be encrypted. Outgoing traffic that is to be encrypted according to the contents of the SPD requires an appropriate SA to exist. SAs may be created manually using setkey(8) but most often, they are created by a cooperative process involving the ISAKMP protocol and a daemon included in your IPsec package (StrongSwan, LibreSwan, ipsec-tools/Racoon, etc.) . 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:

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 presence of IPsec pseudo-interfaces with names of the form ipsecN (e.g. ipsec0). Outgoing unencrypted traffic (case 1.) was sent 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 and/or the appropriate SA.

Shorewall provides support for policy matching in three ways:

In summary, Shorewall provides the facilities to replace the use of IPsec pseudo-interfaces in zone and MASQUERADE/SNAT definition.

There are two cases to consider:

Finally, the OPTIONS, IN OPTIONS and OUT OPTIONS columns in /etc/shorewall/zones 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.

Suppose that we have the following situation:

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:

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

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.

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. The hosts file entries below assume that you want the remote gateway to be part of the vpn zone — If you don't wish the remote gateway included, simply omit its IP address from the HOSTS column.

If you want to keep things simple, you can simply not restrict the set of addresses in the ipsec zones:

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:

If you need access from each firewall to hosts in the other network, then you could add:

If you need access between the firewall's, you should describe the access in your /etc/shorewall/rules file. For example, to allow SSH access from System B, add this rule on system A:

#ZONE   TYPE    OPTIONS                 IN_OPTIONS              OUT_OPTIONS
vpn     ipsec   mode=tunnel             mss=1400

#ZONE   TYPE    OPTIONS                 IN_OPTIONS              OUT_OPTIONS
vpn     ipsec   -                       mss=1400

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.

This section is based on the previous section. Please make sure that you read it thoroughly and understand it. The setup described in this section is more complex because you are including an additional layer of tunneling. Again, make sure that you have read the previous section and it is highly recommended to have the IPsec-only configuration working first.

Additionally, this section assumes that you are running IPsec, xl2tpd and pppd on the same system that is running shorewall. However, configuration of these additional services is beyond the scope of this document.

Getting layer 2 tunneling to work is an endeavour unto itself. However, if you succeed it can be very convenient. Reasons why you might want configure layer 2 tunneling protocol (L2TP):

Since the target for a VPN including L2TP will (almost) never be a road warrior running Linux, I will not include the client side of the configuration.

The first thing that needs to be done is to create a new zone called “l2tp” to represent the tunneled layer 2 traffic.

Since the L2TP will require the use of pppd, you will end up with one or more ppp interfaces (each representing an individual road warrior connection) for which you will need to account. This can be done by modifying the interfaces file. (Modify with additional options as needed.)

The next thing that must be done is to adjust the policy so that the traffic can go where it needs to go.

First, you need to decide if you want for hosts in your local zone to be able to connect to your road warriors. You may or may not want to allow this. For example, one reason you might want to allow this is so that your support personnel can use ssh, VNC or remote desktop to fix a problem on the road warrior's laptop.

Second, you need to decide if you want the road warrior to have access to hosts on the local network. You generally want to allow this. For example, if you have DNS servers on your local network that you want the road warrior to use. Or perhaps the road warrior needs to mount NFS shares or needs to access intranet sites which are not visible from the public Internet.

Finally, you need to decide if you want the road warriors to be able to access the public Internet. You probably want to do this, unless you are trying to create a situation where when the road warrior connects to the VPN, it is no longer possible to send traffic from the road warrior's machine to the public Internet. Please note that this not really a strong security measure. The road warrior could trivially modify the routing table on the remote machine to have only traffic destined for systems on the VPN local network go through the secure channel. The rest of the traffic would simply travel over an Ethernet or wireless interface directly to the public Internet. In fact, this latter situation is dangerous, as a simple mistake could easily create a situation where the road warrior's machine is acting as a router between your local network and the public Internet, which you certainly do not want to happen. In short, it is best to allow the road warrior to connect to the public Internet by default.

The final step is to modify your rules file. There are three important components. First, you must allow the l2tp traffic to reach the xl2tpd process running on the firewall machine. Second, you must add rules to open up ports on the firewall to the road warrior for services which are running on the firewall. For example, if you are running a webserver on the firewall that must be accessible to road warriors. The reason for the second step is that the policy does not by default allow unrestricted access to the firewall itself. Finally, you should protect an exploit where an attacker can exploit your LT2P server due to a hole in the way that L2TP interacts with UDP connection tracking.

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.

Shorewall configuration goes as follows:

If your IPsec tunnel or transport mode connection fails to work with Shorewall started and you see log messages like the following when you try to use the connection, the problem is that ip compression is being used.

Feb 18 23:43:52 vpngw kernel: Shorewall:vpn2fw:REJECT:IN=eth2 OUT= MAC=00:e0:81:32:b3:5e:00:18:de:12:e5:15:08:00
                              SRC=172.29.59.58 DST=172.29.59.254 LEN=85 TOS=0x00 PREC=0x00 TTL=64 ID=25600 DF PROTO=4

The solution is to add an IPCOMP tunnel to /etc/shorewall/tunnels as follows:

#TYPE                   ZONE    GATEWAY         GATEWAY
#                                               ZONE
ipip                    vpn     0.0.0.0/0

The above assumes that the name of your IPsec vpn zone is vpn.

Cases can arise where you need to use an IPsec tunnel to access a remote network, but you have no control over the associated security polices. In such cases, the resulting tunnel is accessible from your firewall but not from your local networks.

Let's take an example:

You need to configure as follows.

/etc/shorewall/zones:

#ZONE        TYPE       OPTIONS
...
vpn          ip         # Note that the zone cannot be declared as type ipsec
...

/etc/shorewall/interfaces:

#ZONE         INTERFACE                 OPTIONS
net           eth0                      nets=(!172.22.4.0/24),...   # You must exclude the remote network from the net zone

/etc/shorewall/hosts:

#ZONE         HOSTS                     OPTIONS
vpn           eth0:172.22.4.0/24        mss=1380,destonly
vpn           eth0:0.0.0.0/0            mss=1380,ipsec

/etc/shorewall/snat:

SNAT(192.0.2.199)    192.168.219.0/24      eth0:172.22.4.0/24

/etc/shorewall/tunnels:

#TYPE            ZONE      GATEWAY            GATEWAY_ZONE
ipsec            net       192.0.2.26         vpn