IPSEC Tunnels

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 confuring FreeS/Wan. 

Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. If you start or restart Shorewall with an IPSEC tunnel active, the proxied IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to the interface that you specify in the INTERFACE column of /etc/shorewall/proxyarp. I haven't had the time to debug this problem so I can't say if it is a bug in the Kernel or in FreeS/Wan. 

You might be able to work around this problem using the following (I haven't tried it):

In /etc/shorewall/init, include:

     qt service ipsec stop

In /etc/shorewall/start, include:

    qt service ipsec start

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:

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

b) 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 

TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 134.28.54.2  

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

TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 206.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.

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.

ZONE DISPLAY COMMENTS
vpn VPN Remote Subnet

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

ZONE INTERFACE BROADCAST OPTIONS
vpn ipsec0    

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:

SOURCE DEST POLICY LOG LEVEL
loc vpn ACCEPT  
vpn loc ACCEPT  

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

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.

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.

ZONE DISPLAY COMMENTS
vpn VPN Remote 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:

TYPE ZONE GATEWAY GATEWAY ZONE
ipsec net 0.0.0.0/0 vpn

Note that 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:

ZONE
 DISPLAY
 COMMENTS
vpn1
 VPN-1
 First VPN Zone
vpn2
 VPN-2
 Second VPN Zone
vpn3
 VPN-3
 Third VPN Zone

In /etc/shorewall/tunnels:
TYPE
 ZONE
 GATEWAY
 GATEWAY ZONE
ipsec
 net
 0.0.0.0/0
 vpn1,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 vpn

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 with dyn=dynamic zone:

ACTION
 SOURCE
 DESTINATION
 PROTOCOL
 PORT(S)
 CLIENT
PORT(S)
 ORIGINAL
DESTINATION
DNAT
 z:dyn
 loc:192.168.1.3
 tcp
 80

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

Last updated 5/3//2003 - Tom Eastep

Copyright © 2001, 2002, 2003 Thomas M. Eastep.