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
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 |
At both systems, ipsec0 would be included in /etc/shorewall/interfaces as a "gw" interface:
ZONE | INTERFACE | BROADCAST | OPTIONS |
gw | ipsec0 |
You will need to allow traffic between the "gw" 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 | gw | ACCEPT | |
gw | 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 .
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.
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 | gw |
Note that the GATEWAY ZONE column contains the name of the zone corresponding to peer subnetworks (gw in the default /etc/shorewall/zones). 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.
Last updated 5/18/2002 - Tom Eastep