mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-16 03:10:39 +01:00
Content moved to IPSEC.xml
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@868 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
mhnoyes
parent
3143eccd74
commit
ae440fc19e
@ -1,714 +0,0 @@
|
||||
<!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.
|
||||
<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. </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;"> 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;"> 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>
|
||||
auto=ignore<br>
|
||||
<br>
|
||||
conn private<br>
|
||||
auto=ignore<br>
|
||||
<br>
|
||||
conn private-or-clear<br>
|
||||
auto=ignore<br>
|
||||
<br>
|
||||
conn clear-or-private<br>
|
||||
auto=ignore<br>
|
||||
<br>
|
||||
conn clear<br>
|
||||
auto=ignore<br>
|
||||
<br>
|
||||
conn packetdefault<br>
|
||||
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 </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> </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> </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> </td>
|
||||
<td> </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> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn</td>
|
||||
<td>loc</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </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 </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> </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> </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> </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> </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> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn1</td>
|
||||
<td>loc</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </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> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn</td>
|
||||
<td>loc</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </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> </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>vpn2</td>
|
||||
<td>vpn1<br>
|
||||
</td>
|
||||
<td>ACCEPT</td>
|
||||
<td> </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> © <font
|
||||
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
|
||||
</p>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
Loading…
Reference in New Issue
Block a user