extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-03 21:13:29 +01:00
Code Issues Packages Projects Releases Wiki Activity
b37e367832
shorewall_code/STABLE/documentation/IPSEC.htm
teastep dbfc838988 Shorewall 1.4.8 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@789 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-11-17 21:06:32 +00:00

715 lines
22 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall IPSec Tunneling</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<h1 style="text-align: center;">IPSEC Tunnels<br>
</h1>
<h2><font color="#660066">Configuring FreeS/Wan</font></h2>
There is an excellent guide to configuring IPSEC tunnels at<a
href="http://www.geocities.com/jixen66/">
http://www.geocities.com/jixen66/</a> . I highly recommend that you
consult that site for information about configuring FreeS/Wan.&nbsp;
<p><font color="#ff6633"><b>Warning: </b></font>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.&nbsp;</p>
<p>You <b>might</b> be able to work around this problem using the
following (I haven't tried it):</p>
<p style="margin-left: 40px;">In /etc/shorewall/init, include:</p>
<div style="margin-left: 40px;"></div>
<p style="margin-left: 40px;">&nbsp;&nbsp;&nbsp;&nbsp; qt service ipsec
stop</p>
<div style="margin-left: 40px;"></div>
<p style="margin-left: 40px;">In /etc/shorewall/start, include:</p>
<div style="margin-left: 40px;"></div>
<p style="margin-left: 40px;">&nbsp;&nbsp;&nbsp; qt service ipsec start<br>
</p>
<p>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:<br>
</p>
<p style="margin-left: 40px;"><tt>conn block<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
<br>
conn private<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
<br>
conn private-or-clear<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
<br>
conn clear-or-private<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
<br>
conn clear<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
<br>
conn packetdefault<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; auto=ignore<br>
</tt></p>
For further information see <a
href="http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html">http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html</a>.<tt><br>
</tt>
<h2> <font color="#660066">IPSec Gateway on the Firewall System </font></h2>
<p>Suppose that we have the following sutuation:</p>
<font color="#660066">
<p align="center"><font face="Century Gothic, Arial, Helvetica"> <img
src="images/TwoNets1.png" width="745" height="427"> </font></p>
</font>
<p align="left">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.</p>
<p align="left">To make this work, we need to do two things:</p>
<p align="left">a) Open the firewall so that the IPSEC tunnel can be
established (allow the ESP and AH protocols and UDP Port 500). </p>
<p align="left">b) Allow traffic through the tunnel.</p>
<p align="left">Opening the firewall for the IPSEC tunnel is
accomplished by adding an entry to the /etc/shorewall/tunnels file.</p>
<p align="left">In /etc/shorewall/tunnels on system A, we need the
following&nbsp;</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> TYPE</strong></td>
<td><strong> ZONE</strong></td>
<td><strong> GATEWAY</strong></td>
<td><strong> GATEWAY ZONE</strong></td>
</tr>
<tr>
<td>ipsec</td>
<td>net</td>
<td>134.28.54.2</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">In /etc/shorewall/tunnels on system B, we would have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> TYPE</strong></td>
<td><strong> ZONE</strong></td>
<td><strong> GATEWAY</strong></td>
<td><strong> GATEWAY ZONE</strong></td>
</tr>
<tr>
<td>ipsec</td>
<td>net</td>
<td>206.161.148.9</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left"><b>Note: </b>If either of the endpoints is behind a
NAT gateway then the tunnels file entry on the <u><b>other</b></u>
endpoint should specify a tunnel type of <i>ipsecnat</i> rather than <i>ipsec</i>
and the GATEWAY address should specify the external address of the NAT
gateway.<br>
</p>
<p align="left">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.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">At both systems, ipsec0 would be included in
/etc/shorewall/interfaces as a "vpn" interface:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> ZONE</strong></td>
<td><strong> INTERFACE</strong></td>
<td><strong> BROADCAST</strong></td>
<td><strong> OPTIONS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>ipsec0</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left"> 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:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left"> Once you have these entries in place, restart
Shorewall
(type shorewall restart); you are now ready to configure the tunnel in <a
href="http://www.xs4all.nl/%7Efreeswan/"> FreeS/WAN</a> .<br>
</p>
<h2><a name="VPNHub"></a>VPN Hub</h2>
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.<br>
<div align="center"><img src="images/ThreeNets.png"
alt="(Three networks linked with IPSEC)" width="750" height="781"> <br>
</div>
<p align="left">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.</p>
<p align="left">To make this work, we need to do several things:</p>
<p align="left">a) Open the firewall so that two IPSEC tunnels can be
established (allow the ESP and AH protocols and UDP Port 500). </p>
<p align="left">b) Allow traffic through the tunnels two/from the local
zone (192.168.1.0/24).<br>
</p>
<p align="left">c) Deny traffic through the tunnels between the two
remote networks.<br>
</p>
<p align="left">Opening the firewall for the IPSEC tunnels is
accomplished by adding two entries to the /etc/shorewall/tunnels file.</p>
<p align="left">In /etc/shorewall/tunnels on system A, we need the
following&nbsp;</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> TYPE</strong></td>
<td><strong> ZONE</strong></td>
<td><strong> GATEWAY</strong></td>
<td><strong> GATEWAY ZONE</strong></td>
</tr>
<tr>
<td>ipsec<br>
</td>
<td>net</td>
<td>134.28.54.2</td>
<td>&nbsp;</td>
</tr>
<tr>
<td valign="top">ipsec<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">130.152.100.14<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">In /etc/shorewall/tunnels on systems B and C, we would
have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> TYPE</strong></td>
<td><strong> ZONE</strong></td>
<td><strong> GATEWAY</strong></td>
<td><strong> GATEWAY ZONE</strong></td>
</tr>
<tr>
<td>ipsec</td>
<td>net</td>
<td>206.161.148.9</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left"></p>
<p align="left"><b>Note: </b>If either of the endpoints is behind a
NAT gateway then the tunnels file entry on the <u><b>other</b></u>
endpoint should specify a tunnel type of <i>ipsecnat</i> rather than <i>ipsec<br>
</i> and the GATEWAY address should specify the external address of the
NAT gateway.<br>
</p>
<p align="left">On each system, we will create a zone to represent the
remote networks. On System A:<br>
</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn1</td>
<td>VPN1</td>
<td>Remote Subnet on system B</td>
</tr>
<tr>
<td valign="top">vpn2<br>
</td>
<td valign="top">VPN2<br>
</td>
<td valign="top">Remote Subnet on system C<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">On systems B and C:<br>
</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet on system A</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">At system A, ipsec0 represents two zones so we have the
following in /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> ZONE</strong></td>
<td><strong> INTERFACE</strong></td>
<td><strong> BROADCAST</strong></td>
<td><strong> OPTIONS</strong></td>
</tr>
<tr>
<td>-<br>
</td>
<td>ipsec0</td>
<td>&nbsp;</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">The /etc/shorewall/hosts file on system A defines the
two VPN zones:<br>
</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> ZONE</strong></td>
<td><strong> HOSTS</strong><br>
</td>
<td><strong> OPTIONS</strong></td>
</tr>
<tr>
<td>vpn1<br>
</td>
<td>ipsec0:10.0.0.0/16</td>
<td><br>
</td>
</tr>
<tr>
<td valign="top">vpn2<br>
</td>
<td valign="top">ipsec0:10.1.0.0/16<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">At systems B and C, ipsec0 represents a single zone so
we have the following in /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> ZONE</strong></td>
<td><strong> INTERFACE</strong></td>
<td><strong> BROADCAST</strong></td>
<td><strong> OPTIONS</strong></td>
</tr>
<tr>
<td>vpn<br>
</td>
<td>ipsec0</td>
<td>&nbsp;</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<p align="left">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:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn1</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>vpn1</td>
<td>loc</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">vpn2<br>
</td>
<td valign="top">ACCEPT<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">vpn2<br>
</td>
<td valign="top">loc<br>
</td>
<td valign="top">ACCEPT<br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">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:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">Once you have the Shorewall entries added, restart
Shorewall on each gateway (type shorewall restart); you are now ready
to configure the tunnels in <a href="http://www.xs4all.nl/%7Efreeswan/">
FreeS/WAN</a> .</p>
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.<br>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>vpn1<br>
</td>
<td>vpn2</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>vpn2</td>
<td>vpn1<br>
</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<span style="font-weight: bold;">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.</span>
<blockquote> </blockquote>
<h2><font color="#660066"><a name="RoadWarrior"></a> </font>Mobile
System (Road Warrior)</h2>
<p>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.</p>
<p align="center"><strong><font face="Century Gothic, Arial, Helvetica">
<img src="images/Mobile.png" width="677" height="426"> </font></strong></p>
<p align="left">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.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left"> 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:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong> TYPE</strong></td>
<td><strong> ZONE</strong></td>
<td><strong> GATEWAY</strong></td>
<td><strong> GATEWAY ZONE</strong></td>
</tr>
<tr>
<td>ipsec</td>
<td>net</td>
<td>0.0.0.0/0</td>
<td>vpn</td>
</tr>
</tbody>
</table>
</blockquote>
<p>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.</p>
<p>You will need to configure /etc/shorewall/interfaces and establish
your "through the tunnel" policy as shown under the first example above.<br>
</p>
<h2><a name="Dynamic"></a>Dynamic RoadWarrior Zones</h2>
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:<br>
<br>
<blockquote>
<table cellpadding="2" border="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>DISPLAY<br>
</b></td>
<td valign="top"><b>COMMENTS<br>
</b></td>
</tr>
<tr>
<td valign="top">vpn1<br>
</td>
<td valign="top">VPN-1<br>
</td>
<td valign="top">First VPN Zone<br>
</td>
</tr>
<tr>
<td valign="top">vpn2<br>
</td>
<td valign="top">VPN-2<br>
</td>
<td valign="top">Second VPN Zone<br>
</td>
</tr>
<tr>
<td valign="top">vpn3<br>
</td>
<td valign="top">VPN-3<br>
</td>
<td valign="top">Third VPN Zone<br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
In /etc/shorewall/tunnels:<br>
<blockquote>
<table cellpadding="2" border="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td valign="top"><b>TYPE<br>
</b></td>
<td valign="top"><b>ZONE<br>
</b></td>
<td valign="top"><b>GATEWAY<br>
</b></td>
<td valign="top"><b>GATEWAY ZONE<br>
</b></td>
</tr>
<tr>
<td valign="top">ipsec<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">vpn1,vpn2,vpn3<br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
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":<br>
<br>
<blockquote>/sbin/shorewall add ipsec0:134.28.54.2 vpn2<br>
</blockquote>
and the 'down' part will:<br>
<blockquote>/sbin/shorewall delete ipsec0:134.28.54.2 vpn2<br>
<br>
</blockquote>
<h3>Limitations of Dynamic Zones</h3>
If you include a dynamic zone in the exclude list of a DNAT rule, the
dynamically-added hosts are not excluded from the rule.<br>
<br>
Example with dyn=dynamic zone:<br>
<br>
<blockquote>
<table cellpadding="2" border="2">
<tbody>
<tr>
<td valign="top"><u><b>ACTION<br>
</b></u></td>
<td valign="top"><u><b>SOURCE<br>
</b></u></td>
<td valign="top"><u><b>DESTINATION<br>
</b></u></td>
<td valign="top"><u><b>PROTOCOL<br>
</b></u></td>
<td valign="top"><u><b>PORT(S)<br>
</b></u></td>
<td valign="top"><u><b>CLIENT<br>
PORT(S)<br>
</b></u></td>
<td valign="top"><u><b>ORIGINAL<br>
DESTINATION<br>
</b></u></td>
</tr>
<tr>
<td valign="top">DNAT<br>
</td>
<td valign="top">z!dyn<br>
</td>
<td valign="top">loc:192.168.1.3<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
Dynamic changes to the zone <b>dyn</b> will have no effect on the
above rule.
<p><font size="2">Last updated 10/292003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<p><a href="copyright.htm"><font size="2"> Copyright</font> <20> <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink