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
Also, 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
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 .
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:
a) Open the firewall so that two IPSEC tunnels can be established (allow the ESP and AH protocols and UDP Port 500).
b) Allow traffic through the tunnels two/from the local
zone (192.168.1.0/24).
c) 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
TYPE ZONE GATEWAY GATEWAY ZONE ipsec
net 134.28.54.2 ipsec
net
130.152.100.14
In /etc/shorewall/tunnels on systems B and C, 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.
On each system, we will create a zone to represent the
remote networks. On System A:
ZONE DISPLAY COMMENTS vpn1 VPN1 Remote Subnet on system B vpn2
VPN2
Remote Subnet on system C
On systems B and C:
ZONE DISPLAY COMMENTS vpn VPN Remote Subnet on system A
At system A, ipsec0 represents two zones so we have the following in /etc/shorewall/interfaces:
ZONE INTERFACE BROADCAST OPTIONS -
ipsec0
The /etc/shorewall/hosts file on system A defines the
two VPN zones:
ZONE HOSTS
OPTIONS vpn1
ipsec0:10.0.0.0/16
vpn2
ipsec0:10.1.0.0/16
At systems B and C, ipsec0 represents a single zone so we have the following in /etc/shorewall/interfaces:
ZONE INTERFACE BROADCAST OPTIONS vpn
ipsec0
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:
SOURCE DEST POLICY LOG LEVEL loc vpn1 ACCEPT vpn1 loc ACCEPT loc
vpn2
ACCEPT
vpn2
loc
ACCEPT
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:
SOURCE DEST POLICY LOG LEVEL loc vpn ACCEPT vpn loc ACCEPT
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 that 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.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.
SOURCE DEST POLICY LOG LEVEL vpn1
vpn2 ACCEPT vpn2 vpn1
ACCEPT
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.
In /etc/shorewall/tunnels:
ZONE
DISPLAY
COMMENTS
vpn1
VPN-1
First VPN Zone
vpn2
VPN-2
Second VPN Zone
vpn3
VPN-3
Third VPN Zone
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":
TYPE
ZONE
GATEWAY
GATEWAY ZONE
ipsec
net
0.0.0.0/0
vpn1,vpn2,vpn3
/sbin/shorewall add ipsec0:134.28.54.2 vpn2and the 'down' part will:
/sbin/shorewall delete ipsec0:134.28.54.2 vpn2
Dynamic changes to the zone dyn will have no effect on the above rule.
ACTION
SOURCE
DESTINATION
PROTOCOL
PORT(S)
CLIENT
PORT(S)
ORIGINAL
DESTINATION
DNAT
z!dyn
loc:192.168.1.3
tcp
80
Last updated 10/292003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.