diff --git a/Shorewall-docs/IPSEC.htm b/Shorewall-docs/IPSEC.htm deleted file mode 100644 index 9d832e994..000000000 --- a/Shorewall-docs/IPSEC.htm +++ /dev/null @@ -1,714 +0,0 @@ - - -
- -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 vpn2-and 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.
-