IPSEC Tunnels

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-03-20


Table of Contents

Configuring FreeS/Wan
IPSec Gateway on the Firewall System
VPN Hub
Mobile System (Road Warrior)
Dynamic RoadWarrior Zones
Limitations of Dynamic Zones

Warning

This documentation does not cover configuring IPSEC under the 2.6 Linux Kernel. David Hollis has provided information about how to set up a simple tunnel under 2.6. One important point that is not made explicit in David's post is that the vpn zone must be defined before the net zone in /etc/shorewall/zones.

Configuring FreeS/Wan

There is an excellent guide to configuring IPSEC tunnels at http://www.geocities.com/jixen66/. I highly recommend that you consult that site for information about configuring FreeS/Wan.

Warning

IPSEC and Proxy ARP do not work unless you are running Shorewall 2.0.1 Beta 3 or later or unless you have installed the fix to Shorewall 2.0.0 available from the Errata Page.

Important

The documentation below assumes that you have disabled opportunistic encryption feature in FreeS/Wan 2.0 using the following additional entries in ipsec.conf:

conn block
        auto=ignore

conn private
        auto=ignore

conn private-or-clear
        auto=ignore

conn clear-or-private
        auto=ignore

conn clear
        auto=ignore

conn packetdefault
        auto=ignore

For further information see http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html.

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.

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

Table 1. /etc/shorewall/tunnels system A

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet134.28.54.2 

In /etc/shorewall/tunnels on system B, we would have:

Table 2. /etc/shorewall/tunnels system B

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet206.161.148.9 

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.

Example 1. VPN

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.

Table 3. /etc/shorewall/zones local

ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet

At both systems, ipsec0 would be included in /etc/shorewall/interfaces as a “vpn” interface:

Table 4. /etc/shorewall/interfaces system local & remote

ZONEINTERFACEBROADCASTOPTIONS
vpnipsec0  

You will need to allow traffic between the “vpn” zone and the “loc” zone -- if you simply want to admit all traffic in both directions, you can use the policy file:

Table 5. /etc/shorewall/policy local & remote

SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 

Once you have these entries in place, restart Shorewall (type shorewall restart); you are now ready to configure the tunnel in FreeS/WAN.

VPN Hub

Shorewall can be used in a VPN Hub environment where multiple remote networks are connected to a gateway running Shorewall. This environment is shown in this diatram.

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/16 and 10.1.0.0/16 networks and we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to communicate.

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

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

  2. Allow traffic through the tunnels two/from the local zone (192.168.1.0/24).

  3. Deny traffic through the tunnels between the two remote networks.

Opening the firewall for the IPSEC tunnels is accomplished by adding two entries to the /etc/shorewall/tunnels file.

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

Table 6. /etc/shorewall/tunnels system A

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet134.28.54.2 
ipsecnet130.152.100.14 

In /etc/shorewall/tunnels on systems B and C, we would have:

Table 7. /etc/shorewall/tunnels system B & C

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet206.161.148.9 

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.

On each system, we will create a zone to represent the remote networks. On System A:

Table 8. /etc/shorewall/zones system A

ZONEDISPLAYCOMMENTS
vpn1VPN1Remote Subnet on system B
vpn2VPN2Remote Subnet on system C

On systems B and C:

Table 9. /etc/shorewall/zones system B & C

ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet on system A

At system A, ipsec0 represents two zones so we have the following in /etc/shorewall/interfaces:

Table 10. /etc/shorewall/interfaces system A

ZONEINTERFACEBROADCASTOPTIONS
-ipsec0  

The /etc/shorewall/hosts file on system A defines the two VPN zones:

Table 11. /etc/shorewall/hosts system A

ZONEHOSTSOPTIONS
vpn1ipsec0:10.0.0.0/16 
vpn2ipsec0:10.1.0.0/16 

At systems B and C, ipsec0 represents a single zone so we have the following in /etc/shorewall/interfaces:

Table 12. /etc/shorewall/interfaces system B & C

ZONEINTERFACEBROADCASTOPTIONS
vpnipsec0  

On systems A, you will need to allow traffic between the “vpn1” zone and the “loc” zone as well as between “vpn2” and the “loc” zone -- if you simply want to admit all traffic in both directions, you can use the following policy file entries on all three gateways:

Table 13. /etc/shorewall/policy system A

SOURCEDESTPOLICYLOG LEVEL
locvpn1ACCEPT 
vpn1locACCEPT 
locvpn2ACCEPT 
vpn2locACCEPT 

On systems B and C, you will need to allow traffic between the “vpn” zone and the “loc” zone -- if you simply want to admit all traffic in both directions, you can use the following policy file entries on all three gateways:

Table 14. /etc/shorewall/policy system B & C

SOURCEDESTPOLICYLOG LEVEL
locvpnACCEPT 
vpnlocACCEPT 

Once you have the Shorewall entries added, restart Shorewall on each gateway (type shorewall restart); you are now ready to configure the tunnels in FreeS/WAN.

Note

to allow traffic between the networks attached to systems B and C, it is necessary to simply add two additional entries to the /etc/shorewall/policy file on system A.

Table 15. /etc/shorewall/policy system A

SOURCEDESTPOLICYLOG LEVEL
vpn1vpn2ACCEPT 
vpn2vpn1ACCEPT 

Note

If you find traffic being rejected/dropped in the OUTPUT chain, place the names of the remote VPN zones as a comma-separated list in the GATEWAY ZONE column of the /etc/shorewall/tunnels file entry.

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 2. 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.

Table 16. /etc/shorewall/zones local

ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet

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:

Table 17. /etc/shorewall/tunnels system A

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet0.0.0.0/0vpn

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.

You will need to configure /etc/shorewall/interfaces and establish your “through the tunnel” policy as shown under the first example above.

Dynamic RoadWarrior Zones

Beginning with Shorewall release 1.3.10, you can define multiple VPN zones and add and delete remote endpoints dynamically using /sbin/shorewall. In /etc/shorewall/zones:

Table 18. /etc/shorewall/zones

ZONEDISPLAYCOMMENTS
vpn1VPN-1First VPN Zone
vpn2VPN-2Second VPN Zone
vpn3VPN-3Third VPN Zone

In /etc/shorewall/tunnels:

Table 19. /etc/shorewall/tunnels

TYPEZONEGATEWAYGATEWAY ZONE
ipsecnet0.0.0.0/0vpn1,vpn2,vpn3

When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall will issue warnings to that effect. These warnings may be safely ignored. FreeS/Wan may now be configured to have three different Road Warrior connections with the choice of connection being based on X-509 certificates or some other means. Each of these connectioins will utilize a different updown script that adds the remote station to the appropriate zone when the connection comes up and that deletes the remote station when the connection comes down. For example, when 134.28.54.2 connects for the vpn2 zone the “up” part of the script will issue the command:

/sbin/shorewall add ipsec0:134.28.54.2 vpn2

and the “down” part will:

/sbin/shorewall delete ipsec0:134.28.54.2 vpn2

Limitations of Dynamic Zones

If you include a dynamic zone in the exclude list of a DNAT rule, the dynamically-added hosts are not excluded from the rule.

Example 3. dyn=dynamic zone

ACTIONSOURCEDESTINATIONPROTOCOLPORT(S)CLIENT PORT(S)ORIGINAL DESTINATION
DNATz!dynloc:192.168.1.3tcp80  

Dynamic changes to the zone dyn will have no effect on the above rule.