From 3143eccd74c2e488c5084e17cde6d2e0750ba155 Mon Sep 17 00:00:00 2001 From: mhnoyes Date: Tue, 16 Dec 2003 21:08:51 +0000 Subject: [PATCH] DocBook XML conversion git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@867 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/IPSEC.xml | 839 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 839 insertions(+) create mode 100644 Shorewall-docs/IPSEC.xml diff --git a/Shorewall-docs/IPSEC.xml b/Shorewall-docs/IPSEC.xml new file mode 100644 index 000000000..da1025f52 --- /dev/null +++ b/Shorewall-docs/IPSEC.xml @@ -0,0 +1,839 @@ + + +
+ + IPSEC Tunnels + + + + Tom + + Eastep + + + + + 2001 + + 2002 + + 2003 + + Thomas M. Eastep + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, Version + 1.2 or any later version published by the Free Software Foundation; with + no Invariant Sections, with no Front-Cover, and with no Back-Cover + Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". + + + 2003-10-29 + + +
+ 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. + + + 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 + + + + 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: + + + + Open the firewall so that the IPSEC tunnel can be established + (allow the ESP and AH protocols and UDP Port 500). + + + + 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 + + + /etc/shorewall/tunnels system A + + + + + TYPE + + ZONE + + GATEWAY + + GATEWAY ZONE + + + + + + ipsec + + net + + 134.28.54.2 + + + + + +
+ + In /etc/shorewall/tunnels on system B, we would have: + + + /etc/shorewall/tunnels system B + + + + + TYPE + + ZONE + + GATEWAY + + GATEWAY ZONE + + + + + + ipsec + + net + + 206.161.148.9 + + + + + +
+ + + 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. + + + + VPN + + 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. + + /etc/shorewall/zones localZONEDISPLAYCOMMENTSvpnVPNRemote + Subnet
 + + At both systems, ipsec0 would be included in + /etc/shorewall/interfaces as a "vpn" interface: + + /etc/shorewall/interfaces system local & remoteZONEINTERFACEBROADCASTOPTIONSvpnipsec0
 + + 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: + + /etc/shorewall/policy local & remoteSOURCEDESTPOLICYLOG LEVELlocvpnACCEPTvpnlocACCEPT
 + + 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. + + + + 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: + + + + Open the firewall so that two IPSEC tunnels can be established + (allow the ESP and AH protocols and UDP Port 500). + + + + Allow traffic through the tunnels two/from the local zone + (192.168.1.0/24). + + + + 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 + + + /etc/shorewall/tunnels system A + + + + + 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: + + + /etc/shorewall/tunnels system B & C + + + + + TYPE + + ZONE + + GATEWAY + + GATEWAY ZONE + + + + + + ipsec + + net + + 206.161.148.9 + + + + + +
+ + + 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: + + + /etc/shorewall/zones system A + + + + + ZONE + + DISPLAY + + COMMENTS + + + + + + vpn1 + + VPN1 + + Remote Subnet on system B + + + + vpn2 + + VPN2 + + Remote Subnet on system C + + + +
+ + On systems B and C: + + + /etc/shorewall/zones system B & 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: + + + /etc/shorewall/interfaces system A + + + + + ZONE + + INTERFACE + + BROADCAST + + OPTIONS + + + + + + - + + ipsec0 + + + + + + + +
+ + The /etc/shorewall/hosts file on system A defines the two VPN zones: + + + /etc/shorewall/hosts system A + + + + + 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: + + + /etc/shorewall/interfaces system B & C + + + + + 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: + + + /etc/shorewall/policy system A + + + + + 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: + + + /etc/shorewall/policy system B & C + + + + + 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. + + + 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. + + + /etc/shorewall/policy system A + + + + + SOURCE + + DEST + + POLICY + + LOG LEVEL + + + + + + vpn1 + + vpn2 + + ACCEPT + + + + + + vpn2 + + vpn1 + + ACCEPT + + + + + +
+ + + + 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. + + + + + Road Warrior VPN + + 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. + + /etc/shorewall/zones localZONEDISPLAYCOMMENTSvpnVPNRemote + 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: + + /etc/shorewall/tunnels system ATYPEZONEGATEWAYGATEWAY ZONEipsecnet0.0.0.0/0vpn
 + + 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: + + + /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: + + + /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. + + + dyn=dynamic zone + + ACTIONSOURCEDESTINATIONPROTOCOLPORT(S)CLIENT PORT(S)ORIGINAL DESTINATIONDNATz!dynloc:192.168.1.3tcp80 + + Dynamic changes to the zone dyn + will have no effect on the above rule. + +
+
+
\ No newline at end of file