From ae440fc19ef3629ebbd719e7fba44f1bbaf81064 Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Tue, 16 Dec 2003 21:10:13 +0000 Subject: [PATCH] Content moved to IPSEC.xml git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@868 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/IPSEC.htm | 714 --------------------------------------- 1 file changed, 714 deletions(-) delete mode 100644 Shorewall-docs/IPSEC.htm 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 @@ - - - - - Shorewall IPSec Tunneling - - - - -

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 configuring 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
-

-

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
-

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

-

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
ipsecnet134.28.54.2 
-
-

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

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

-

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.

-
- - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote Subnet
-
-

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

-
- - - - - - - - - - - - - - - -
ZONE INTERFACE BROADCAST OPTIONS
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:

-
- - - - - - - - - - - - - - - - - - - - - -
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.
-
(Three networks linked with IPSEC)
-
-

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
- 		net134.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
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:
-

-
- - - - - - - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpn1VPN1Remote Subnet on system B
vpn2
- 		VPN2
- 		Remote Subnet on system C
-
-
-

On systems B and C:
-

-
- - - - - - - - - - - - - -
ZONEDISPLAYCOMMENTS
vpnVPNRemote 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:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
locvpn1ACCEPT 
vpn1locACCEPT 
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:

-
- - - - - - - - - - - - - - - - - - - - - -
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 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.
-
- - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG LEVEL
vpn1
- 		vpn2ACCEPT 
vpn2vpn1
- 		ACCEPT 
-
-
-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.

-

-

-

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.

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

-
- - - - - - - - - - - - - - - -
TYPE ZONE GATEWAY GATEWAY ZONE
ipsecnet0.0.0.0/0vpn
-
-

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 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 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 10/292003 - Tom Eastep

-

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

-
-
- -