Make iproute required

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@459 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-21 22:22:19 +00:00
parent fe9b56090c
commit bcefe5a0c8
16 changed files with 12371 additions and 12104 deletions

File diff suppressed because it is too large Load Diff

View File

@ -1,52 +1,76 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>GRE/IPIP Tunnels</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>GRE/IPIP Tunnels</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">GRE and IPIP Tunnels</font></h1>
<h1 align="center"><font color="#ffffff">GRE and IPIP Tunnels</font></h1>
</td>
</tr>
</tbody>
</table>
<h3><font color="#FF6633">Warning: </font>GRE and IPIP Tunnels are insecure when used
over the internet; use them at your own risk</h3>
<p>GRE and IPIP tunneling with Shorewall requires iproute2 and can be used to bridge two masqueraded networks.&nbsp;GRE
tunnels were introduced in shorewall version 1.2.0_Beta2.</p>
<p>The simple scripts described in the <a href="http://ds9a.nl/lartc">Linux Advanced Routing
and Shaping HOWTO</a> work fine with Shorewall. Shorewall also includes a tunnel
script for automating tunnel configuration. If you have installed the RPM, the
tunnel script may be found in the Shorewall documentation directory (usually
/usr/share/doc/shorewall-&lt;version&gt;/).</p>
<h3><font color="#ff6633">Warning: </font>GRE and IPIP Tunnels are insecure
when used over the internet; use them at your own risk</h3>
<p>GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded
networks.</p>
<p>The simple scripts described in the <a href="http://ds9a.nl/lartc">Linux
Advanced Routing and Shaping HOWTO</a> work fine with Shorewall. Shorewall
also includes a tunnel script for automating tunnel configuration. If you
have installed the RPM, the tunnel script may be found in the Shorewall documentation
directory (usually /usr/share/doc/shorewall-&lt;version&gt;/).</p>
<h2>Bridging two Masqueraded Networks</h2>
<p>Suppose that we have the following situation:</p>
<p align="center">
<img border="0" src="images/TwoNets1.png" width="745" height="427"></p>
<p align="left">We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is accomplished
through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy file
and the /etc/shorewall/tunnel script that is included with Shorewall.</p>
<p align="center"> <img border="0" src="images/TwoNets1.png" width="745"
height="427">
</p>
<p align="left">We want systems in the 192.168.1.0/24 subnetwork to be able
to communicate with the systems in the 10.0.0.0/8 network. This is accomplished
through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy
file and the /etc/shorewall/tunnel script that is included with Shorewall.</p>
<p align="left">The 'tunnel' script is not installed in /etc/shorewall by
default -- If you install using the tarball, the script is included in the
tarball; if you install using the RPM, the file is in your Shorewall
documentation directory (normally /usr/share/doc/shorewall-&lt;version&gt;).</p>
tarball; if you install using the RPM, the file is in your Shorewall documentation
directory (normally /usr/share/doc/shorewall-&lt;version&gt;).</p>
<p align="left">In the /etc/shorewall/tunnel script, set the 'tunnel_type'
parameter to the type of tunnel that you want to create.</p>
<p align="left">Example:</p>
<blockquote>
<p align="left">tunnel_type=gre</p>
</blockquote>
<p align="left">tunnel_type=gre</p>
</blockquote>
<p align="left">On each firewall, you will need to declare a zone to represent
the remote subnet. We'll assume that this zone is called 'vpn' and declare it in
/etc/shorewall/zones on both systems as follows.</p>
the remote subnet. We'll assume that this zone is called 'vpn' and declare
it in /etc/shorewall/zones on both systems as follows.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
@ -58,12 +82,16 @@ the remote subnet. We'll assume that this zone is called 'vpn' and declare it in
<td>Remote Subnet</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">On system A, the 10.0.0.0/8 will comprise the <b>vpn</b> zone. In
/etc/shorewall/interfaces:</p>
<p align="left">On system A, the 10.0.0.0/8 will comprise the <b>vpn</b>
zone. In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
@ -74,13 +102,18 @@ the remote subnet. We'll assume that this zone is called 'vpn' and declare it in
<td>vpn</td>
<td>tosysb</td>
<td>10.255.255.255</td>
<td>&nbsp;</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<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">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
@ -91,13 +124,18 @@ the remote subnet. We'll assume that this zone is called 'vpn' and declare it in
<td>ipip</td>
<td>net</td>
<td>134.28.54.2</td>
<td>&nbsp;</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IP
encapsulation protocol (4) will be accepted to/from the remote gateway.</p>
encapsulation protocol (4) will be accepted to/from the remote gateway.</p>
<p>In the tunnel script on system A:</p>
<blockquote>
<p>tunnel=tosysb<br>
myrealip=206.161.148.9 (for GRE tunnel only)<br>
@ -105,11 +143,14 @@ encapsulation protocol (4) will be accepted to/from the remote gateway.</p>
hisip=10.0.0.1<br>
gateway=134.28.54.2<br>
subnet=10.0.0.0/8</p>
</blockquote>
</blockquote>
<p>Similarly, On system B the 192.168.1.0/24 subnet will comprise the <b>vpn</b>
zone. In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
@ -120,13 +161,18 @@ zone. In /etc/shorewall/interfaces:</p>
<td>vpn</td>
<td>tosysa</td>
<td>192.168.1.255</td>
<td>&nbsp;</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>In /etc/shorewall/tunnels on system B, we have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
@ -137,11 +183,15 @@ zone. In /etc/shorewall/interfaces:</p>
<td>ipip</td>
<td>net</td>
<td>206.191.148.9</td>
<td>&nbsp;</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>And in the tunnel script on system B:</p>
<blockquote>
<p>tunnel=tosysa<br>
myrealip=134.28.54.2 (for GRE tunnel only)<br>
@ -149,17 +199,18 @@ zone. In /etc/shorewall/interfaces:</p>
hisip=192.168.1.1<br>
gateway=206.191.148.9<br>
subnet=192.168.1.0/24</p>
</blockquote>
<p>You can rename the modified tunnel scripts if you like; be sure that they are
secured so that root can execute them. </p>
</blockquote>
<p align="Left"> You will need to allow traffic between the &quot;vpn&quot; zone and
the &quot;loc&quot; zone on both systems -- if you simply want to admit all traffic
in both directions, you can use the policy file:</p>
<p>You can rename the modified tunnel scripts if you like; be sure that they
are secured so that root can execute them. </p>
<p align="left"> You will need to allow traffic between the "vpn" zone and
the "loc" zone on both systems -- 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">
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
@ -170,27 +221,28 @@ secured so that root can execute them. </p>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
<td> </td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>On both systems, restart Shorewall and
run the modified tunnel script with the &quot;start&quot; argument on each
system. The systems in the two masqueraded subnetworks can now talk to each
other</p>
<p><font size="2">Updated 8/22/2002 - <a href="support.htm">Tom
Eastep</a> </font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
</blockquote>
<p>On both systems, restart Shorewall and run the modified tunnel script
with the "start" argument on each system. The systems in the two masqueraded
subnetworks can now talk to each other</p>
<p><font size="2">Updated 2/22/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003Thomas M. Eastep.</font></a></p>
<br>
</body>
</html>

View File

@ -26,22 +26,21 @@
</tbody>
</table>
<br>
Beginning with Shorewall version 1.3.10, all traffic from an interface
or from a subnet on an interface can be verified to originate from a defined
set of MAC addresses. Furthermore, each MAC address may be optionally associated
with one or more IP addresses. <br>
All traffic from an interface or from a subnet on an interface
can be verified to originate from a defined set of MAC addresses. Furthermore,
each MAC address may be optionally associated with one or more IP addresses.
<br>
<br>
<b>You must have the iproute package (ip utility) installed to use MAC
Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- module name ipt_mac.o).</b><br>
<b>Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- module name ipt_mac.o).</b><br>
<br>
There are four components to this facility.<br>
<ol>
<li>The <b>maclist</b> interface option in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. When this
option is specified, all traffic arriving on the interface is subjet to MAC
verification.</li>
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. When
this option is specified, all traffic arriving on the interface is subjet
to MAC verification.</li>
<li>The <b>maclist </b>option in <a
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>. When this option
is specified for a subnet, all traffic from that subnet is subject to MAC
@ -51,11 +50,12 @@ verification.</li>
with MAC addresses.</li>
<li>The <b>MACLIST_DISPOSITION </b>and <b>MACLIST_LOG_LEVEL </b>variables
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and
determines the disposition of connection requests that fail MAC verification.
The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
requests that fail verification are to be logged. If set the the empty value
(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.<br>
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
and determines the disposition of connection requests that fail MAC verification.
The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
requests that fail verification are to be logged. If set the the empty
value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are
not logged.<br>
</li>
</ol>
@ -65,8 +65,8 @@ requests that fail verification are to be logged. If set the the empty value
<li>INTERFACE - The name of an ethernet interface on the Shorewall
system.</li>
<li>MAC - The MAC address of a device on the ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in this
column although you may use that format if you so choose.</li>
by INTERFACE. It is not necessary to use the Shorewall MAC format in
this column although you may use that format if you so choose.</li>
<li>IP Address - An optional comma-separated list of IP addresses
for the device whose MAC is listed in the MAC column.</li>
@ -95,16 +95,18 @@ and IP address 192.168.1.253. Hosts in the second segment have IP addresses
This entry accomodates traffic from the router itself (192.168.1.253)
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.
<p><font size="2"> Updated 2/18/2002 - <a href="support.htm">Tom Eastep</a>
by the router so that traffic's MAC address will be that of the router
(00:06:43:45:C6:15) and not that of the host sending the traffic.
<p><font size="2"> Updated 2/21/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@ -45,20 +45,17 @@
as a transparent proxy as described at <a
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
<b><br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files /etc/shorewall/start
and /etc/shorewall/init -- if you don't have those files, siimply create
them.<br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13"
height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files
/etc/shorewall/start and /etc/shorewall/init -- if you don't have those
files, siimply create them.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or in
the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
file entries. That is because the packets being routed to the Squid server
still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iproute2 (<i>ip </i>utility) installed
on your firewall.<br>
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or
in the local zone, that zone must be defined ONLY by its interface -- no
/etc/shorewall/hosts file entries. That is because the packets being routed
to the Squid server still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iptables installed on your Squid
@ -69,7 +66,8 @@
/etc/shorewall/conf file<br>
<br>
&nbsp;&nbsp;&nbsp; <b><font color="#009900">&nbsp;&nbsp;&nbsp; NAT_ENABLED=Yes<br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font
color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
<br>
Three different configurations are covered:<br>
@ -77,8 +75,9 @@
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on
the Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in the
local network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the DMZ</a></li>
local network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the
DMZ</a></li>
</ol>
@ -147,7 +146,7 @@ local network</a></li>
<h2><a name="Local"></a>Squid Running in the local network</h2>
You want to redirect all local www connection requests to a Squid
transparent proxy
running in your local zone at 192.168.1.3 and listening on port 3128.
running in your local zone at 192.168.1.3 and listening on port 3128.
Your local interface is eth1. There may also be a web server running on
192.168.1.3. It is assumed that web access is already enabled from the local
zone to the internet.<br>
@ -325,7 +324,7 @@ zone to the internet.<br>
</blockquote>
<blockquote>B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
and add the following entry in /etc/shorewall/tcrules:<br>
and add the following entry in /etc/shorewall/tcrules:<br>
</blockquote>
<blockquote>
@ -477,7 +476,7 @@ and add the following entry in /etc/shorewall/tcrules:<br>
<blockquote> </blockquote>
<p><font size="-1"> Updated 1/23/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="-1"> Updated 2/21/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -490,5 +489,6 @@ and add the following entry in /etc/shorewall/tcrules:<br>
<br>
<br>
<br>
<br>
</body>
</html>

View File

@ -16,6 +16,7 @@
<base target="_self">
<meta name="author" content="Tom Eastep">
</head>
<body>
@ -48,7 +49,7 @@
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.4 - <font size="4">"<i>iptables made
1.4 - <font size="4">"<i>iptables made
easy"</i></font></font></h1>
@ -119,9 +120,9 @@
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
@ -137,8 +138,8 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<p>This program is free software; you can redistribute it and/or modify
it under the terms
of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free Software
of <a href="http://www.gnu.org/licenses/gpl.html">Version 2
of the GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
@ -148,15 +149,15 @@ of <a href="http://www.gnu.org/licenses/gpl.html">Version
WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
for more details.<br>
<br>
You should have received a
copy of the GNU General Public License
copy of the GNU General Public License
along with this program; if not, write to the
Free Software Foundation, Inc., 675 Mass Ave,
Cambridge, MA 02139, USA</p>
Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
@ -186,14 +187,15 @@ copy of the GNU General Public License
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and
Eric Wolzak have a LEAF (router/firewall/gateway
Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.1!!!</b><br>
<p><b>Congratulations to Jacques and Eric on the recent release of Bering
1.1!!!</b><br>
</p>
@ -205,8 +207,8 @@ Bering 1.1!!!</b><br>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
<h2>This is a mirror of the main Shorewall web site at SourceForge (<a
href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
@ -233,6 +235,7 @@ Bering 1.1!!!</b><br>
<h2></h2>
@ -251,7 +254,10 @@ Bering 1.1!!!</b><br>
Shorewall 1.4 represents the next step in the evolution of Shorewall.
The main thrust of the initial release is simply to remove the cruft that
has accumulated in Shorewall over time. <br>
Function from 1.3 that has been omitted from this version include:<br>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
@ -259,7 +265,7 @@ has accumulated in Shorewall over time. <br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
@ -268,16 +274,16 @@ in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
and /etc/shorewall/hosts files is no longer supported and will generate
an error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<li>The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
@ -286,19 +292,22 @@ longer accepted.<br>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.<br>
the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION
columns.<br>
</li>
</ul>
<ol>
</ol>
@ -306,7 +315,7 @@ DESTINATION columns.<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
reorganized into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
@ -321,12 +330,12 @@ common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i>
now support the 'maclist' option.<br>
</li>
</ol>
@ -421,11 +430,11 @@ support the 'maclist' option.<br>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
</td>
@ -446,6 +455,7 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
</body>
</html>

View File

@ -27,14 +27,14 @@
</tbody>
</table>
<br>
Shorewall Requires:<br>
Shorewall Requires:<br>
<ul>
<li>A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6.
<a href="kernel.htm"> Check here for kernel configuration
information.</a> If you are looking for a firewall for use with 2.2
kernels, <a href="http://seawall.sf.net"> see the Seattle Firewall
site</a> .</li>
<a href="kernel.htm"> Check here for kernel configuration information.</a>
If you are looking for a firewall for use with 2.2 kernels, <a
href="http://seawall.sf.net"> see the Seattle Firewall site</a>
.</li>
<li>iptables 1.2 or later but beware version 1.2.3 -- see the <a
href="errata.htm">Errata</a>. <font color="#ff0000"><b>WARNING: </b></font>The
buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
@ -42,14 +42,13 @@ upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
is available <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat</a>
and in the <a href="errata.htm">Shorewall Errata</a>. </li>
<li>Some features require iproute ("ip" utility). The iproute package
is included with most distributions but may not be installed by default.
The official download site is <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> <font
face="Century Gothic, Arial, Helvetica">f</font>tp://ftp.inr.ac.ru/ip-routing</a>.
<li>Iproute ("ip" utility). The iproute package is included with
most distributions but may not be installed by default. The official
download site is <a href="ftp://ftp.inr.ac.ru/ip-routing"
target="_blank"> <font face="Century Gothic, Arial, Helvetica">f</font>tp://ftp.inr.ac.ru/ip-routing</a>.
</li>
<li>A Bourne shell or derivative such as bash or ash. This shell must
have correct support for variable expansion formats ${<i>variable</i>%<i>pattern</i>
have correct support for variable expansion formats ${<i>variable</i>%<i>pattern</i>
}, ${<i>variable</i>%%<i>pattern</i>}, ${<i>variable</i>#<i>pattern</i>
} and ${<i>variable</i>##<i>pattern</i>}.</li>
<li>The firewall monitoring display is greatly improved if you have
@ -57,11 +56,12 @@ awk (gawk) installed.</li>
</ul>
<p align="left"><font size="2">Last updated 11/10/2002 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>

View File

@ -62,14 +62,14 @@
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you run LEAF Bering, your Shorewall configuration is NOT what
I release -- I suggest that you consider installing a stock Shorewall lrp
from the shorewall.net site before you proceed.</p>
I release -- I suggest that you consider installing a stock Shorewall
lrp from the shorewall.net site before you proceed.</p>
<p>This guide assumes that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
if this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
<p>Shorewall requires that the iproute/iproute2 package be installed (on
RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell if
this package is installed by the presence of an <b>ip</b> program on your
firewall system. As root, you can use the 'which' command to check for
this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -84,8 +84,8 @@
must save them as Unix files if your editor supports that option or you
must run them through dos2unix before trying to use them with Shorewall.
Similarly, if you copy a configuration file from your Windows hard drive
to a floppy disk, you must run dos2unix against the copy before using
it with Shorewall.</p>
to a floppy disk, you must run dos2unix against the copy before using it
with Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
@ -97,18 +97,18 @@ it with Shorewall.</p>
<h2 align="left"><a name="Concepts"></a>2.0 Shorewall Concepts</h2>
<p>The configuration files for Shorewall are contained in the directory /etc/shorewall
-- for most setups, you will only need to deal with a few of these as described
in this guide. Skeleton files are created during the <a
href="Install.htm">Shorewall Installation Process</a>.</p>
<p>The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for most setups, you will only need to deal with a few
of these as described in this guide. Skeleton files are created during the
<a href="Install.htm">Shorewall Installation Process</a>.</p>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
and some contain default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the default installation, the following zone
names are used:</p>
set of <i>zones.</i> In the default installation, the following zone names
are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -137,9 +137,9 @@ names are used:</p>
file.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b> but that may be changed in
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
file. In this guide, the default name (<b>fw</b>) will be used.</p>
the firewall itself is known as <b>fw</b> but that may be changed in the
<a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
file. In this guide, the default name (<b>fw</b>) will be used.</p>
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
to zone names. Zones are entirely what YOU make of them. That means that
@ -173,7 +173,7 @@ is the internet zone" or "because that is the DMZ".</p>
<li> Identify the source zone.</li>
<li> Identify the destination zone.</li>
<li> If the POLICY from the client's zone to the server's
zone is what you want for this client/server pair, you need do nothing
zone is what you want for this client/server pair, you need do nothing
further.</li>
<li> If the POLICY is not what you want, then you must add
a rule. That rule is expressed in terms of the client's zone and
@ -181,13 +181,13 @@ the server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed from zone
A to the firewall and are also allowed from the firewall to zone B <font
<p> Just because connections of a particular type are allowed from zone A
to the firewall and are also allowed from the firewall to zone B <font
color="#ff6633"><b><u> DOES NOT mean that these connections are allowed
from zone A to zone B</u></b></font>. It rather means that you can
have a proxy running on the firewall that accepts a connection from
zone A and then establishes its own separate connection from the firewall
to zone B.</p>
from zone A to zone B</u></b></font>. It rather means that you can have
a proxy running on the firewall that accepts a connection from zone
A and then establishes its own separate connection from the firewall to
zone B.</p>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
@ -238,14 +238,15 @@ the request is first checked against the rules in /etc/shorewall/common.def.</
<ol>
<li>allow all connection requests from your local network to the
internet</li>
<li>drop (ignore) all connection requests from the internet to your
firewall or local network and log a message at the <i>info</i> level
(<a href="shorewall_logging.html">here</a> is a description of log levels).</li>
internet</li>
<li>drop (ignore) all connection requests from the internet to
your firewall or local network and log a message at the <i>info</i>
level (<a href="shorewall_logging.html">here</a> is a description of log
levels).</li>
<li>reject all other connection requests and log a message at the
<i>info</i> level. When a request is rejected, the firewall will
return an RST (if the protocol is TCP) or an ICMP port-unreachable
packet for other protocols.</li>
return an RST (if the protocol is TCP) or an ICMP port-unreachable packet
for other protocols.</li>
</ol>
@ -256,15 +257,15 @@ packet for other protocols.</li>
<h2 align="left"><a name="Interfaces"></a>3.0 Network Interfaces</h2>
<p align="left">For the remainder of this guide, we'll refer to the following
diagram. While it may not look like your own network, it can be used
to illustrate the important aspects of Shorewall configuration.</p>
diagram. While it may not look like your own network, it can be used to
illustrate the important aspects of Shorewall configuration.</p>
<p align="left">In this diagram:</p>
<ul>
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
to isolate your internet-accessible servers from your local systems so
that if one of those servers is compromised, you still have the firewall
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is
used to isolate your internet-accessible servers from your local systems
so that if one of those servers is compromised, you still have the firewall
between the compromised system and your local systems. </li>
<li>The Local Zone consists of systems Local 1, Local 2 and Local
3. </li>
@ -284,19 +285,19 @@ interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/sh
<p align="left">The firewall illustrated above has three network interfaces.
Where Internet connectivity is through a cable or DSL "Modem", the <i>External
Interface</i> will be the Ethernet adapter that is connected to that
"Modem" (e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
Interface</i> will be the Ethernet adapter that is connected to that "Modem"
(e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect via
a regular modem, your External Interface will also be <b>ppp0</b>. If
you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then
you will want to set CLAMPMSS=yes in <a href="Documentation.htm#Conf">
/etc/shorewall/shorewall.conf.</a></p>
you will want to set CLAMPMSS=yes in <a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
<p align="left">Your <i>Local Interface</i> will be an Ethernet adapter (eth0,
eth1 or eth2) and will be connected to a hub or switch. Your local computers
@ -372,10 +373,10 @@ work at all.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/interfaces file and define the network
interfaces on your firewall and associate each interface with a zone. If
you have a zone that is interfaced through more than one interface, simply
include one entry for each interface and repeat the zone name as many times
as necessary.</p>
interfaces on your firewall and associate each interface with a zone.
If you have a zone that is interfaced through more than one interface,
simply include one entry for each interface and repeat the zone name as
many times as necessary.</p>
<p align="left">Example:</p>
@ -459,11 +460,11 @@ question though, some background is in order.</p>
<p align="left">If you are thoroughly familiar with IP addressing and routing,
you may <a href="#Options">go to the next section</a>.</p>
<p align="left">The following discussion barely scratches the surface of
addressing and routing. If you are interested in learning more about this
subject, I highly recommend <i>"IP Fundamentals: What Everyone Needs to
Know about Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall,
1999, ISBN 0-13-975483-0.</p>
<p align="left">The following discussion barely scratches the surface of addressing
and routing. If you are interested in learning more about this subject,
I highly recommend <i>"IP Fundamentals: What Everyone Needs to Know about
Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall, 1999, ISBN
0-13-975483-0.</p>
<h3 align="left"><a name="Addresses"></a>4.1 IP Addresses</h3>
@ -499,19 +500,19 @@ Know about Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall,
<p align="left">The class of a network was uniquely determined by the value
of the high order byte of its address so you could look at an IP address
and immediately determine the associated <i>netmask</i>. The netmask
is a number that when logically ANDed with an address isolates the <i>network
and immediately determine the associated <i>netmask</i>. The netmask is
a number that when logically ANDed with an address isolates the <i>network
number</i>; the remainder of the address is the <i>host number</i>. For
example, in the Class C address 192.0.2.14, the network number is hex
C00002 and the host number is hex 0E.</p>
example, in the Class C address 192.0.2.14, the network number is hex C00002
and the host number is hex 0E.</p>
<p align="left">As the internet grew, it became clear that such a gross partitioning
of the 32-bit address space was going to be very limiting (early on, large
corporations and universities were assigned their own class A network!).
After some false starts, the current technique of <i>subnetting</i> these
networks into smaller <i>subnetworks</i> evolved; that technique is referred
to as <i>Classless InterDomain Routing</i> (CIDR). Today, any system that
you are likely to work with will understand CIDR and Class-based networking
<p align="left">As the internet grew, it became clear that such a gross
partitioning of the 32-bit address space was going to be very limiting (early
on, large corporations and universities were assigned their own class A
network!). After some false starts, the current technique of <i>subnetting</i>
these networks into smaller <i>subnetworks</i> evolved; that technique is
referred to as <i>Classless InterDomain Routing</i> (CIDR). Today, any system
that you are likely to work with will understand CIDR and Class-based networking
is largely a thing of the past.</p>
<p align="left">A <i>subnetwork</i> (often referred to as a <i>subnet) </i>is
@ -537,9 +538,9 @@ to as
</ol>
<p align="left">As you can see by this definition, in each subnet of size
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that
can be assigned to hosts). The first and last address in the subnet
are used for the subnet address and subnet broadcast address respectively.
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that can
be assigned to hosts). The first and last address in the subnet are
used for the subnet address and subnet broadcast address respectively.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
@ -748,8 +749,8 @@ As we will see below, this property of subnet masks is very useful in
routing.</p>
<p align="left">For a subnetwork whose address is <b>a.b.c.d</b> and whose
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork
as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork as
"<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
<p align="left">Example:</p>
@ -842,19 +843,18 @@ as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.
<br>
The first three routes are <i>host routes</i> since they indicate
how to get to a single host. In the 'netstat' output this can be seen
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the
Flags column. The remainder are 'net' routes since they tell the kernel
how to route packets to a subnetwork. The last route is the <i>default
route</i> and the gateway mentioned in that route is called the <i>default
gateway</i>.</p>
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags
column. The remainder are 'net' routes since they tell the kernel how
to route packets to a subnetwork. The last route is the <i>default route</i>
and the gateway mentioned in that route is called the <i>default gateway</i>.</p>
<p align="left">When the kernel is trying to send a packet to IP address
<b>A</b>, it starts at the top of the routing table and:</p>
<p align="left">When the kernel is trying to send a packet to IP address <b>A</b>,
it starts at the top of the routing table and:</p>
<ul>
<li>
<p align="left"><b>A</b> is logically ANDed with the 'Genmask' value
in the table entry.</p>
<p align="left"><b>A</b> is logically ANDed with the 'Genmask' value in
the table entry.</p>
</li>
<li>
<p align="left">The result is compared with the 'Destination' value in
@ -866,10 +866,12 @@ in the table entry.</p>
<ul>
<li>
<p align="left">If the 'Gateway' column is non-zero, the packet is
sent to the gateway over the interface named in the 'Iface' column.</p>
</li>
<li>
<p align="left">Otherwise, the packet is sent directly to <b>A </b>over
the interface named in the 'iface' column.</p>
</li>
@ -883,10 +885,10 @@ in the table entry.</p>
</ul>
<p align="left">Since the default route matches any IP address (<b>A</b>
land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing
table entries are sent to the <i>default gateway</i> which is usually a
router at your ISP.</p>
<p align="left">Since the default route matches any IP address (<b>A</b> land
0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table
entries are sent to the <i>default gateway</i> which is usually a router
at your ISP.</p>
<p align="left">Lets take an example. Suppose that we want to route a packet
to 192.168.1.5. That address clearly doesn't match any of the host routes
@ -898,18 +900,17 @@ the result is 192.168.1.0 which matches this routing table entry:</p>
<pre>192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2</pre>
</blockquote>
<p>So to route a packet to 192.168.1.5, the packet is sent directly over
eth2.</p>
<p>So to route a packet to 192.168.1.5, the packet is sent directly over eth2.</p>
</div>
<p align="left">One more thing needs to be emphasized -- all outgoing packet
are sent using the routing table and reply packets are not a special
case. There seems to be a common mis-conception whereby people think
that request packets are like salmon and contain a genetic code that
is magically transferred to reply packets so that the replies follow
the reverse route taken by the request. That isn't the case; the replies
may take a totally different route back to the client than was taken by
the requests -- they are totally independent.</p>
are sent using the routing table and reply packets are not a special case.
There seems to be a common mis-conception whereby people think that request
packets are like salmon and contain a genetic code that is magically
transferred to reply packets so that the replies follow the reverse route
taken by the request. That isn't the case; the replies may take a totally
different route back to the client than was taken by the requests -- they
are totally independent.</p>
<h3 align="left"><a name="ARP"></a>4.4 Address Resolution Protocol</h3>
@ -926,9 +927,9 @@ the MAC of an Ethernet device using the 'ip' utility:</p>
</blockquote>
<div align="left">
<p align="left">As you can see from the above output, the MAC is 6 bytes
(48 bits) wide. A card's MAC is usually also printed on a label attached
to the card itself. </p>
<p align="left">As you can see from the above output, the MAC is 6 bytes (48
bits) wide. A card's MAC is usually also printed on a label attached to
the card itself. </p>
</div>
<div align="left">
@ -953,8 +954,8 @@ to the card itself. </p>
<p align="left">In order to avoid having to exchange ARP information each
time that an IP packet is to be sent, systems maintain an <i>ARP cache</i>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your
system (including your Windows system) using the 'arp' command:</p>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your system
(including your Windows system) using the 'arp' command:</p>
<blockquote>
<div align="left">
@ -976,14 +977,14 @@ records the information we saw using tcpdump above.</p>
who delegates allocations on a geographic basis to <i>Regional Internet
Registries</i> (RIRs). For example, allocation for the Americas and for
sub-Sahara Africa is delegated to the <i><a href="http://www.arin.net">American
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn
delegate to national registries. Most of us don't deal with these registrars
but rather get our IP addresses from our ISP.</p>
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn delegate
to national registries. Most of us don't deal with these registrars but
rather get our IP addresses from our ISP.</p>
<p align="left">It's a fact of life that most of us can't afford as many
Public IP addresses as we have devices to assign them to so we end up making
use of <i> Private </i>IP addresses. RFC 1918 reserves several IP address
ranges for this purpose:</p>
<p align="left">It's a fact of life that most of us can't afford as many Public
IP addresses as we have devices to assign them to so we end up making use
of <i> Private </i>IP addresses. RFC 1918 reserves several IP address ranges
for this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -992,9 +993,9 @@ ranges for this purpose:</p>
<div align="left">
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. This is
understandable given that anyone can select any of these addresses
for their private use.</p>
forward packets which have an RFC-1918 destination address. This is understandable
given that anyone can select any of these addresses for their private
use.</p>
</div>
<div align="left">
@ -1005,8 +1006,8 @@ for their private use.</p>
<div align="left">
<ul>
<li>
<p align="left">As the IPv4 address space becomes depleted, more and
more organizations (including ISPs) are beginning to use RFC 1918 addresses
<p align="left">As the IPv4 address space becomes depleted, more and more
organizations (including ISPs) are beginning to use RFC 1918 addresses
in their infrastructure. </p>
</li>
<li>
@ -1062,8 +1063,8 @@ address of your firewall/router's external interface. </p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    If you are using the Debian package, please check your shorewall.conf
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
file to ensure that the following are set correctly; if they are not,
change them appropriately:<br>
</p>
<ul>
@ -1080,7 +1081,7 @@ address of your firewall/router's external interface. </p>
<div align="left">
<p align="left">Let's assume that your ISP has assigned you the subnet
192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses
192.0.2.64/28 routed through 192.0.2.65. That means that you have IP addresses
192.0.2.64 - 192.0.2.79 and that your firewall's external IP address
is 192.0.2.65. Your ISP has also told you that you should use a netmask
of 255.255.255.0 (so your /28 is part of a larger /24). With this many
@ -1095,20 +1096,20 @@ up your network as shown in the following diagram.</p>
</div>
<div align="left">
<p align="left">Here, the DMZ comprises the subnet 192.0.2.64/29 and the
Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ
would be configured to 192.0.2.66 and the default gateway for hosts in
the local network would be 192.0.2.73.</p>
<p align="left">Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local
network is 192.0.2.72/29. The default gateway for hosts in the DMZ would
be configured to 192.0.2.66 and the default gateway for hosts in the local
network would be 192.0.2.73.</p>
</div>
<div align="left">
<p align="left">Notice that this arrangement is rather wasteful of public
IP addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses
and 192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and
192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
Nevertheless, it shows how subnetting can work and if we were dealing
with a /24 rather than a /28 network, the use of 6 IP addresses out
of 256 would be justified because of the simplicity of the setup.</p>
with a /24 rather than a /28 network, the use of 6 IP addresses out of
256 would be justified because of the simplicity of the setup.</p>
</div>
<div align="left">
@ -1134,11 +1135,11 @@ by the firewall/router.</p>
</div>
<div align="left">
<p align="left">It is this rather unexpected ARP behavior on the part of
the Linux Kernel that prompts the warning earlier in this guide regarding
the connecting of multiple firewall/router interfaces to the same hub
or switch. When an ARP request for one of the firewall/router's IP addresses
is sent by another system connected to the hub/switch, all of the firewall's
<p align="left">It is this rather unexpected ARP behavior on the part of the
Linux Kernel that prompts the warning earlier in this guide regarding the
connecting of multiple firewall/router interfaces to the same hub or switch.
When an ARP request for one of the firewall/router's IP addresses is sent
by another system connected to the hub/switch, all of the firewall's
interfaces that connect to the hub/switch can respond! It is then a
race as to which "here-is" response reaches the sender first.</p>
</div>
@ -1148,16 +1149,16 @@ race as to which "here-is" response reaches the sender first.</p>
</div>
<div align="left">
<p align="left">If you have the above situation but it is non-routed,
you can configure your network exactly as described above with one additional
<p align="left">If you have the above situation but it is non-routed, you
can configure your network exactly as described above with one additional
twist; simply specify the "proxyarp" option on all three firewall interfaces
in the /etc/shorewall/interfaces file.</p>
</div>
<div align="left">
<p align="left">Most of us don't have the luxury of having enough public
IP addresses to set up our networks as shown in the preceding example
(even if the setup is routed). </p>
<p align="left">Most of us don't have the luxury of having enough public IP
addresses to set up our networks as shown in the preceding example (even
if the setup is routed). </p>
</div>
<div align="left">
@ -1169,8 +1170,8 @@ IP addresses to set up our networks as shown in the preceding example
<div align="left">
<p align="left">Clearly, that set of addresses doesn't comprise a subnetwork
and there aren't enough addresses for all of the network interfaces.
There are four different techniques that can be used to work around
this problem.</p>
There are four different techniques that can be used to work around this
problem.</p>
</div>
<div align="left">
@ -1195,8 +1196,8 @@ this problem.</p>
</div>
<div align="left">
<p align="left">Often a combination of these techniques is used. Each of
these will be discussed in the sections that follow.</p>
<p align="left">Often a combination of these techniques is used. Each of these
will be discussed in the sections that follow.</p>
</div>
<div align="left">
@ -1206,19 +1207,19 @@ these will be discussed in the sections that follow.</p>
<div align="left">
<p align="left">With SNAT, an internal LAN segment is configured using RFC
1918 addresses. When a host <b>A </b>on this internal segment initiates
a connection to host <b>B</b> on the internet, the firewall/router
rewrites the IP header in the request to use one of your public IP
addresses as the source address. When <b>B</b> responds and the response
is received by the firewall, the firewall changes the destination address
back to the RFC 1918 address of <b>A</b> and forwards the response back
to <b>A.</b></p>
a connection to host <b>B</b> on the internet, the firewall/router rewrites
the IP header in the request to use one of your public IP addresses
as the source address. When <b>B</b> responds and the response is received
by the firewall, the firewall changes the destination address back
to the RFC 1918 address of <b>A</b> and forwards the response back to
<b>A.</b></p>
</div>
<div align="left">
<p align="left">Let's suppose that you decide to use SNAT on your local zone
and use public address 192.0.2.176 as both your firewall's external
IP address and the source IP address of internet requests sent from
that zone.</p>
IP address and the source IP address of internet requests sent from that
zone.</p>
</div>
<div align="left">
@ -1289,8 +1290,8 @@ selected connections from the internet.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
     Suppose that your daughter wants to run a web server on her
system "Local 3". You could allow connections to the internet to her
server by adding the following entry in <a
system "Local 3". You could allow connections to the internet to her
server by adding the following entry in <a
href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
</div>
@ -1334,9 +1335,9 @@ server by adding the following entry in <a
</div>
<div align="left">
<p align="left">This example used the firewall's external IP address for
DNAT. You can use another of your public IP addresses but Shorewall will
not add that address to the firewall's external interface for you.</p>
<p align="left">This example used the firewall's external IP address for DNAT.
You can use another of your public IP addresses but Shorewall will not
add that address to the firewall's external interface for you.</p>
</div>
<div align="left">
@ -1350,8 +1351,8 @@ not add that address to the firewall's external interface for you.</p>
<div align="left">
<ul>
<li>
<p align="left">A host <b>H </b>behind your firewall is assigned one
of your public IP addresses (<b>A)</b> and is assigned the same netmask
<p align="left">A host <b>H </b>behind your firewall is assigned one of
your public IP addresses (<b>A)</b> and is assigned the same netmask
<b>(M) </b>as the firewall's external interface. </p>
</li>
<li>
@ -1359,9 +1360,9 @@ of your public IP addresses (<b>A)</b> and is assigned the same netmask
</p>
</li>
<li>
<p align="left">When <b>H</b> issues an ARP "who has" request for an
address in the subnetwork defined by <b>A</b> and <b>M</b>, the firewall
will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<p align="left">When <b>H</b> issues an ARP "who has" request for an address
in the subnetwork defined by <b>A</b> and <b>M</b>, the firewall will
respond (with the MAC if the firewall interface to <b>H</b>). </p>
</li>
</ul>
@ -1426,8 +1427,8 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
</p>
<p align="left">The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
to have the IP addresses shown but should have the same default gateway
as the firewall itself -- namely 192.0.2.254.<br>
to have the IP addresses shown but should have the same default gateway as
the firewall itself -- namely 192.0.2.254.<br>
</p>
</div>
@ -1439,28 +1440,28 @@ as the firewall itself -- namely 192.0.2.254.<br>
<div align="left">
<p align="left">A word of warning is in order here. ISPs typically configure
their routers with a long ARP cache timeout. If you move a system from
parallel to your firewall to behind your firewall with Proxy ARP, it will
probably be HOURS before that system can communicate with the internet.
parallel to your firewall to behind your firewall with Proxy ARP, it
will probably be HOURS before that system can communicate with the internet.
There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP
Illustrated, Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
MAC address for its own IP; in addition to ensuring that the IP address isn't
a duplicate,...<br>
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
MAC address for its own IP; in addition to ensuring that the IP address
isn't a duplicate,...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware
address..., this packet causes any other host...that has an entry in its
cache for the old hardware address to update its ARP cache entry accordingly."<br>
address..., this packet causes any other host...that has an entry in its
cache for the old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP (or
static NAT for that matter). Happily enough, recent versions of Redhat's
iputils package include "arping", whose "-U" flag does just that:<br>
from being exposed to the Internet to behind Shorewall using proxy ARP
(or static NAT for that matter). Happily enough, recent versions of Redhat's
iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly proxied
IP&gt;</b></font><br>
@ -1475,9 +1476,10 @@ that it works most of the time.<br>
entry but many either can't or won't purge individual entries.</li>
</ol>
You can determine if your ISP's gateway ARP cache is stale using ping
and tcpdump. Suppose that we suspect that the gateway router has a stale
ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:</div>
You can determine if your ISP's gateway ARP cache is stale using
ping and tcpdump. Suppose that we suspect that the gateway router has
a stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump
as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
@ -1506,8 +1508,8 @@ that it works most of the time.<br>
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of DMZ 1. In other words, the gateway's ARP cache
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with
the firewall's eth0.</p>
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the
firewall's eth0.</p>
</div>
<div align="left">
@ -1518,9 +1520,9 @@ the firewall's eth0.</p>
<p align="left">With static NAT, you assign local systems RFC 1918 addresses
then establish a one-to-one mapping between those addresses and public
IP addresses. For outgoing connections SNAT (Source Network Address
Translation) occurs and on incoming connections DNAT (Destination Network
Address Translation) occurs. Let's go back to our earlier example involving
your daughter's web server running on system Local 3.</p>
Translation) occurs and on incoming connections DNAT (Destination Network
Address Translation) occurs. Let's go back to our earlier example involving
your daughter's web server running on system Local 3.</p>
</div>
<div align="left">
@ -1531,8 +1533,8 @@ your daughter's web server running on system Local 3.</p>
<div align="left">
<p align="left">Recall that in this setup, the local network is using SNAT
and is sharing the firewall external IP (192.0.2.176) for outbound
connections. This is done with the following entry in /etc/shorewall/masq:</p>
and is sharing the firewall external IP (192.0.2.176) for outbound connections.
This is done with the following entry in /etc/shorewall/masq:</p>
</div>
<div align="left">
@ -1601,7 +1603,7 @@ You would do that by adding an entry in <a
    Once the relationship between 192.0.2.179 and 192.168.201.4
is established by the nat file entry above, it is no longer appropriate
to use a DNAT rule for you daughter's web server -- you would rather
just use an ACCEPT rule:</p>
just use an ACCEPT rule:</p>
</div>
<div align="left">
@ -1644,8 +1646,8 @@ just use an ACCEPT rule:</p>
access any servers on the internet and the DMZ can't access any other
host (including the firewall). With the exception of <a
href="#DNAT">DNAT rules</a> which cause address translation and allow
the translated connection request to pass through the firewall, the
way to allow connection requests through your firewall is to use ACCEPT
the translated connection request to pass through the firewall, the way
to allow connection requests through your firewall is to use ACCEPT
rules.</p>
</div>
@ -1801,8 +1803,8 @@ rules.</p>
</div>
<div align="left">
<p align="left">If you run a public DNS server on 192.0.2.177, you would
need to add the following rules:</p>
<p align="left">If you run a public DNS server on 192.0.2.177, you would need
to add the following rules:</p>
</div>
<div align="left">
@ -1934,10 +1936,10 @@ need to add the following rules:</p>
</div>
<div align="left">
<p align="left">The above discussion reflects my personal preference for
using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems.
I prefer to use NAT only in cases where a system that is part of an RFC
1918 subnet needs to have it's own public IP. </p>
<p align="left">The above discussion reflects my personal preference for using
Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I
prefer to use NAT only in cases where a system that is part of an RFC 1918
subnet needs to have it's own public IP. </p>
</div>
<div align="left">
@ -1952,14 +1954,13 @@ do.</p>
</div>
<div align="left">
<p align="left">In case you haven't been keeping score, here's the final
set of configuration files for our sample network. Only those that were
modified from the original installation are shown.</p>
<p align="left">In case you haven't been keeping score, here's the final set
of configuration files for our sample network. Only those that were modified
from the original installation are shown.</p>
</div>
<div align="left">
<p align="left">/etc/shorewall/interfaces (The "options" will be very
site-specific).</p>
<p align="left">/etc/shorewall/interfaces (The "options" will be very site-specific).</p>
</div>
<div align="left">
@ -2339,10 +2340,10 @@ up Shorewall before you bring up your network interfaces.</p>
</div>
<div align="left">
<p align="left">Given the collection of RFC 1918 and public addresses in
this setup, it only makes sense to have separate internal and external
DNS servers. You can combine the two into a single BIND 9 server using
<i>Views. </i> If you are not interested in Bind 9 views, you can <a
<p align="left">Given the collection of RFC 1918 and public addresses in this
setup, it only makes sense to have separate internal and external DNS
servers. You can combine the two into a single BIND 9 server using <i>Views.
</i> If you are not interested in Bind 9 views, you can <a
href="#StartingAndStopping">go to the next section</a>.</p>
</div>
@ -2491,8 +2492,7 @@ externally and it's interface to the local network to be know as gateway.foo
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/routestopped file and configure those
systems that you want to be able to access the firewall when it is
stopped.</p>
systems that you want to be able to access the firewall when it is stopped.</p>
</div>
<div align="left">
@ -2506,7 +2506,7 @@ stopped.</p>
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/18/2003 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
@ -2518,5 +2518,6 @@ stopped.</p>
<br>
<br>
<br>
<br>
</body>
</html>

View File

@ -144,8 +144,8 @@
This program is distributed
in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU General Public License
warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License
for more details.<br>
<br>
@ -153,8 +153,8 @@ A PARTICULAR PURPOSE. See the GNU General Public License
You should have received
a copy of the GNU General Public License
along with this program; if not, write to
the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
the Free Software Foundation, Inc., 675
Mass Ave, Cambridge, MA 02139, USA</p>
@ -185,7 +185,7 @@ A PARTICULAR PURPOSE. See the GNU General Public License
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo
and Eric Wolzak have a LEAF (router/firewall/gateway
and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
@ -198,6 +198,7 @@ and Eric Wolzak have a LEAF (router/firewall/gateway
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.1!!!</b><br>
<h2>News</h2>
@ -218,9 +219,11 @@ on the recent release of Bering 1.1!!!</b><br>
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
Shorewall 1.4 represents the
next step in the evolution of Shorewall. The main thrust of the initial
release is simply to remove the cruft that has accumulated in Shorewall
over time. <br>
next step in the evolution of Shorewall. The main thrust of the initial release
is simply to remove the cruft that has accumulated in Shorewall over time.
<br>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
@ -230,7 +233,7 @@ over time. <br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
@ -239,16 +242,16 @@ in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
and /etc/shorewall/hosts files is no longer supported and will generate
an error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<li>The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
@ -257,18 +260,21 @@ longer accepted.<br>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
the rule must be explicit - it must name the zone in both the SOURCE and DESTINATION
columns.</li>
</ul>
<ul>
</ul>
@ -276,7 +282,7 @@ DESTINATION columns.</li>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
reorganized into logical sections.<br>
<br>
</li>
<li>LOG and CONTINUE are now a valid actions for a rule (/etc/shorewall/rules).<br>
@ -291,12 +297,12 @@ common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i>
now support the 'maclist' option.<br>
<br>
</li>
@ -441,11 +447,11 @@ support the 'maclist' option.<br>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
<p align="center"><font size="4" color="#ffffff">Shorewall is free but
if you try it and find it useful, please consider making a donation
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
</td>
@ -466,6 +472,7 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
</body>
</html>

View File

@ -43,11 +43,11 @@
</ul>
<p>This guide assumes that you have the iproute/iproute2 package installed
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
if this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
if this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -58,11 +58,11 @@ for this program:</p>
.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows system, you must
save them as Unix files if your editor supports that option or you must
run them through dos2unix before trying to use them. Similarly, if you
copy a configuration file from your Windows hard drive to a floppy disk,
you must run dos2unix against the copy before using it with Shorewall.</p>
    If you edit your configuration files on a Windows system, you
must save them as Unix files if your editor supports that option or you
must run them through dos2unix before trying to use them. Similarly, if
you copy a configuration file from your Windows hard drive to a floppy
disk, you must run dos2unix against the copy before using it with Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
@ -77,8 +77,8 @@ you must run dos2unix against the copy before using it with Shorewall.</p>
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13"
alt="">
    The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for simple setups, you only need to deal with a few of
these as described in this guide. After you have <a
/etc/shorewall -- for simple setups, you only need to deal with a few
of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
href="/pub/shorewall/LATEST.samples/one-interface.tgz">one-interface sample</a>,
un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall
@ -90,8 +90,8 @@ you must run dos2unix against the copy before using it with Shorewall.</p>
and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the one-interface sample configuration, only one
zone is defined:</p>
set of <i>zones.</i> In the one-interface sample configuration, only
one zone is defined:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -118,7 +118,7 @@ you must run dos2unix against the copy before using it with Shorewall.</p>
<ul>
<li>You express your default policy for connections from one zone
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
</a>file.</li>
<li>You define exceptions to those default policies in the <a
href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
@ -127,13 +127,13 @@ to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/pol
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common (the
samples provide that file for you).</p>
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the one-interface sample has
the following policies:</p>
<p>The /etc/shorewall/policy file included with the one-interface sample
has the following policies:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -180,7 +180,7 @@ the following policies:</p>
<li>drop (ignore) all connection requests from the internet to your
firewall</li>
<li>reject all other connection requests (Shorewall requires this
catchall policy).</li>
catchall policy).</li>
</ol>
@ -191,21 +191,21 @@ catchall policy).</li>
<p align="left">The firewall has a single network interface. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter (<b>eth0</b>) that is connected to that "Modem" 
<u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint <u>P</u>rotocol
over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint <u>T</u>unneling
<u>P</u>rotocol </i>(PPTP) in which case the External Interface will be
a <b>ppp0</b>. If you connect via a regular modem, your External Interface
will also be <b>ppp0</b>. If you connect using ISDN, your external interface
will be<b> ippp0.</b></p>
will be the ethernet adapter (<b>eth0</b>) that is connected to that
"Modem"  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a <b>ppp0</b>. If you connect via a regular modem, your
External Interface will also be <b>ppp0</b>. If you connect using ISDN,
your external interface will be<b> ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_3.gif" width="13"
height="13">
    The Shorewall one-interface sample configuration assumes that the
external interface is <b>eth0</b>. If your configuration is different,
you will have to modify the sample /etc/shorewall/interfaces file accordingly.
While you are there, you may wish to review the list of options that are
specified for the interface. Some hints:</p>
    The Shorewall one-interface sample configuration assumes that
the external interface is <b>eth0</b>. If your configuration is different,
you will have to modify the sample /etc/shorewall/interfaces file accordingly.
While you are there, you may wish to review the list of options that
are specified for the interface. Some hints:</p>
<ul>
<li>
@ -214,8 +214,8 @@ you will have to modify the sample /etc/shorewall/interfaces file accordingly.
</li>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the option
list. </p>
or if you have a static IP address, you can remove "dhcp" from the
option list. </p>
</li>
</ul>
@ -241,8 +241,8 @@ you will have to modify the sample /etc/shorewall/interfaces file accordingly.
<p align="left"><img border="0" src="images/BD21298_.gif" align="left"
width="13" height="13">
     Before starting Shorewall, you should look at the IP address
of your external interface and if it is one of the above ranges, you should
remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.</p>
of your external interface and if it is one of the above ranges, you
should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.</p>
</div>
<div align="left">
@ -284,8 +284,8 @@ of your external interface and if it is one of the above ranges, you should
</div>
<div align="left">
<p align="left">Example - You want to run a Web Server and a POP3 Server on
your firewall system:</p>
<p align="left">Example - You want to run a Web Server and a POP3 Server
on your firewall system:</p>
</div>
<div align="left">
@ -327,8 +327,8 @@ your firewall system:</p>
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular application
uses, see <a href="ports.htm">here</a>.</p>
<p align="left">If you don't know what port and protocol a particular
application uses, see <a href="ports.htm">here</a>.</p>
</div>
<div align="left">
@ -384,8 +384,7 @@ uses, see <a href="ports.htm">here</a>.</p>
your system to start Shorewall at system boot but beginning with Shorewall
version 1.3.9 startup is disabled so that your system won't try to start
Shorewall before configuration is complete. Once you have completed configuration
of your firewall, you can enable Shorewall startup by removing the file
/etc/shorewall/startup_disabled.<br>
of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.<br>
</p>
<p align="left"><font color="#ff0000"><b>IMPORTANT</b>: Users of the .deb
@ -410,11 +409,11 @@ uses, see <a href="ports.htm">here</a>.</p>
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate configuration</a></i>
and test it using the <a href="starting_and_stopping_shorewall.htm">"shorewall
try" command</a>.</p>
and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/26/2003 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
@ -425,5 +424,6 @@ Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
</body>
</html>

View File

@ -31,8 +31,8 @@
<h2 align="center">Version 2.0.1</h2>
<p align="left">Setting up a Linux system as a firewall for a small network
with DMZ is a fairly straight-forward task if you understand the basics
and follow the documentation.</p>
with DMZ is a fairly straight-forward task if you understand the
basics and follow the documentation.</p>
<p>This guide doesn't attempt to acquaint you with all of the features of
Shorewall. It rather focuses on what is required to configure Shorewall
@ -54,18 +54,18 @@
height="635">
</p>
<p>This guide assumes that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
if this package is installed by the presence of an <b>ip</b> program
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b> program
on your firewall system. As root, you can use the 'which' command to
check for this program:</p>
check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>I recommend that you first read through the guide to familiarize yourself
with what's involved then go back through it again making your configuration
changes. Points at which configuration changes are recommended are
flagged with <img border="0" src="images/BD21298_.gif" width="13"
flagged with <img border="0" src="images/BD21298_.gif" width="13"
height="13">
. Configuration notes that are unique to LEAF/Bering are marked with <img
src="images/leaflogo.gif" alt="(LEAF Logo)" width="49" height="36">
@ -75,15 +75,16 @@ flagged with <img border="0" src="images/BD21298_.gif" width="13"
    If you edit your configuration files on a Windows system,
you must save them as Unix files if your editor supports that option
or you must run them through dos2unix before trying to use them. Similarly,
if you copy a configuration file from your Windows hard drive to a floppy
disk, you must run dos2unix against the copy before using it with Shorewall.</p>
if you copy a configuration file from your Windows hard drive to a
floppy disk, you must run dos2unix against the copy before using it with
Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
of dos2unix</a></li>
</ul>
@ -92,21 +93,21 @@ flagged with <img border="0" src="images/BD21298_.gif" width="13"
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13"
alt="">
    The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for simple setups, you will only need to deal with a
few of these as described in this guide. After you have <a
/etc/shorewall -- for simple setups, you will only need to deal with
a few of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
href="/pub/shorewall/LATEST.samples/three-interfaces.tgz">three-interface
sample</a>, un-tar it (tar -zxvf three-interfaces.tgz) and and copy
the files to /etc/shorewall (the files will replace files with the same
names that were placed in /etc/shorewall when Shorewall was installed)</b>.</p>
the files to /etc/shorewall (the files will replace files with the
same names that were placed in /etc/shorewall when Shorewall was installed)</b>.</p>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
and default entries.</p>
file on your system -- each file contains detailed configuration
instructions and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the three-interface sample configuration, the
following zone names are used:</p>
set of <i>zones.</i> In the three-interface sample configuration,
the following zone names are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -149,10 +150,10 @@ one zone to another zone in the<a
</ul>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common
checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or
DROP  the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the three-interface sample
@ -228,7 +229,7 @@ one zone to another zone in the<a
<ol>
<li>allow all connection requests from your local network
to the internet</li>
to the internet</li>
<li>drop (ignore) all connection requests from the internet
to your firewall or local network</li>
<li>optionally accept all connection requests from the firewall
@ -239,7 +240,7 @@ to the internet</li>
<p><img border="0" src="images/BD21298_1.gif" width="13" height="13">
    At this point, edit your /etc/shorewall/policy file and
make any changes that you wish.</p>
make any changes that you wish.</p>
<h2 align="left">Network Interfaces</h2>
@ -253,21 +254,21 @@ make any changes that you wish.</p>
<b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect via
a regular modem, your External Interface will also be <b>ppp0</b>. If
you connect using ISDN, you external interface will be <b>ippp0.</b></p>
Interface will be a ppp interface (e.g., <b>ppp0</b>). If you connect
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then
you will want to set CLAMPMSS=yes in <a
    If your external interface is <b>ppp0</b> or <b>ippp0
</b>then you will want to set CLAMPMSS=yes in <a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
<p align="left">Your <i>Local Interface</i> will be an ethernet adapter (eth0,
eth1 or eth2) and will be connected to a hub or switch. Your local
computers will be connected to the same switch (note: If you have only
a single local system, you can connect the firewall directly to the computer
using a <i>cross-over </i> cable).</p>
computers will be connected to the same switch (note: If you have
only a single local system, you can connect the firewall directly to
the computer using a <i>cross-over </i> cable).</p>
<p align="left">Your <i>DMZ Interface</i> will also be an ethernet adapter
(eth0, eth1 or eth2) and will be connected to a hub or switch. Your
@ -285,9 +286,9 @@ hub or switch (even for testing). It won't work the way that you expect
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    The Shorewall three-interface sample configuration assumes
that the external interface is <b>eth0, </b>the local interface is <b>eth1
</b>and the DMZ interface is <b> eth2</b>. If your configuration is
different, you will have to modify the sample /etc/shorewall/interfaces
that the external interface is <b>eth0, </b>the local interface is
<b>eth1 </b>and the DMZ interface is <b> eth2</b>. If your configuration
is different, you will have to modify the sample /etc/shorewall/interfaces
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
@ -300,8 +301,8 @@ different, you will have to modify the sample /etc/shorewall/interfaces
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the
option list. </p>
or if you have a static IP address, you can remove "dhcp" from
the option list. </p>
</li>
</ul>
@ -310,16 +311,17 @@ different, you will have to modify the sample /etc/shorewall/interfaces
<p align="left">Before going further, we should say a few words about Internet
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign you
a single <i> Public</i> IP address. This address may be assigned via the<i>
Dynamic Host Configuration Protocol</i> (DHCP) or as part of establishing
your connection when you dial in (standard modem) or establish your PPP
connection. In rare cases, your ISP may assign you a<i> static</i> IP
address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>Regardless of how the address is
assigned, it will be shared by all of your systems when you access the
Internet. You will have to assign your own addresses for your internal network
(the local and DMZ Interfaces on your firewall plus your other computers).
RFC 1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
a single <i> Public</i> IP address. This address may be assigned via
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of
establishing your connection when you dial in (standard modem) or establish
your PPP connection. In rare cases, your ISP may assign you a<i> static</i>
IP address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>Regardless of how the address
is assigned, it will be shared by all of your systems when you access
the Internet. You will have to assign your own addresses for your internal
network (the local and DMZ Interfaces on your firewall plus your other
computers). RFC 1918 reserves several <i>Private </i>IP address ranges for
this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -339,8 +341,8 @@ interface's entry in /etc/shorewall/interfaces.</p>
sub-network </i>or <i>subnet</i> and your DMZ addresses from another
subnet. For our purposes, we can consider a subnet to consists of
a range of addresses x.y.z.0 - x.y.z.255. Such a subnet will have a
<i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved
as the <i>Subnet Address</i> and x.y.z.255 is reserved as the <i>Subnet
<i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0 is reserved as
the <i>Subnet Address</i> and x.y.z.255 is reserved as the <i>Subnet
Broadcast</i> <i>Address</i>. In Shorewall, a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR)</a> notation with consists of the subnet address followed
@ -382,8 +384,8 @@ Broadcast</i> <i>Address</i>. In Shorewall, a subnet is described using
<div align="left">
<p align="left">It is conventional to assign the internal interface either
the first usable address in the subnet (10.10.10.1 in the above example)
or the last usable address (10.10.10.254).</p>
the first usable address in the subnet (10.10.10.1 in the above
example) or the last usable address (10.10.10.254).</p>
</div>
<div align="left">
@ -399,15 +401,15 @@ Broadcast</i> <i>Address</i>. In Shorewall, a subnet is described using
    Your local computers (Local Computers 1 &amp; 2) should
be configured with their<i> default gateway</i> set to the IP address
of the firewall's internal interface and your DMZ computers ( DMZ
Computers 1 &amp; 2) should be configured with their default gateway
set to the IP address of the firewall's DMZ interface.   </p>
Computers 1 &amp; 2) should be configured with their default gateway
set to the IP address of the firewall's DMZ interface.   </p>
</div>
<p align="left">The foregoing short discussion barely scratches the surface
regarding subnetting and routing. If you are interested in learning
more about IP addressing and routing, I highly recommend <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i> Thomas
A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
What Everyone Needs to Know about Addressing &amp; Routing",</i>
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left">The remainder of this quide will assume that you have configured
your network as shown here:</p>
@ -423,10 +425,10 @@ set to the IP address of the firewall's DMZ interface.
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP  might assign
your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24
subnet then you will need to select a DIFFERENT RFC 1918 subnet for your
local network and if it is in the 10.10.11.0/24 subnet then you will need
to select a different RFC 1918 subnet for your DMZ.</b><br>
your external interface an RFC 1918 address. If that address is in the
10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918
subnet for your local network and if it is in the 10.10.11.0/24 subnet then
you will need to select a different RFC 1918 subnet for your DMZ.</b><br>
</p>
<p align="left">IP Masquerading (SNAT)</p>
@ -436,20 +438,20 @@ to select a different RFC 1918 subnet for your DMZ.</b><br>
forward packets which have an RFC-1918 destination address. When one
of your local systems (let's assume local computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network Address
Translation </i>(NAT). The firewall rewrites the source address in the
packet to be the address of the firewall's external interface; in other
words, the firewall makes it look as if the firewall itself is initiating
the connection.  This is necessary so that the destination host will be
able to route return packets back to the firewall (remember that packets
whose destination address is reserved by RFC 1918 can't be routed accross
the internet). When the firewall receives a return packet, it rewrites
the destination address back to 10.10.10.1 and forwards the packet on
to local computer 1. </p>
Translation </i>(NAT). The firewall rewrites the source address in
the packet to be the address of the firewall's external interface; in
other words, the firewall makes it look as if the firewall itself is
initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed accross the internet). When the firewall receives a return
packet, it rewrites the destination address back to 10.10.10.1 and
forwards the packet on to local computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> and you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> and you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<ul>
<li>
@ -473,9 +475,9 @@ to select a different RFC 1918 subnet for your DMZ.</b><br>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    If your external firewall interface is <b>eth0</b>, your
local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b> then
you do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change it to match your configuration.</p>
local interface <b>eth1 </b>and your DMZ interface is <b>eth2</b>
then you do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change it to match your configuration.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
@ -489,8 +491,8 @@ your static IP in column 3 makes <br>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    If you are using the Debian package, please check your shorewall.conf
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
file to ensure that the following are set correctly; if they are not,
change them appropriately:<br>
</p>
<ul>
@ -503,17 +505,17 @@ your static IP in column 3 makes <br>
<h2 align="left">Port Forwarding (DNAT)</h2>
<p align="left">One of your goals will be to run one or more servers on your
DMZ computers. Because these computers have RFC-1918 addresses, it is
not possible for clients on the internet to connect directly to them.
It is rather necessary for those clients to address their connection
requests to your firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When your
server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
DMZ computers. Because these computers have RFC-1918 addresses, it
is not possible for clients on the internet to connect directly to
them. It is rather necessary for those clients to address their connection
requests to your firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When your
server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
Destination Network Address Translation</i> (DNAT). You configure port
forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
<p>The general form of a simple port forwarding rule in /etc/shorewall/rules
is:</p>
@ -547,8 +549,8 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
</table>
</blockquote>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to be
the same as <i>&lt;port&gt;</i>.</p>
<p>If you don't specify the <i>&lt;server port&gt;</i>, it is assumed to
be the same as <i>&lt;port&gt;</i>.</p>
<p>Example - you run a Web Server on DMZ 2 and you want to forward incoming
TCP port 80 to that system:</p>
@ -596,8 +598,8 @@ the same as <i>&lt;port&gt;</i>.</p>
<li>When you are connecting to your server from your local
systems, you must use the server's internal IP address (10.10.11.2).</li>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000 (e.g., connect to <a
80. If you have problems connecting to your web server, try the following
rule and try connecting to port 5000 (e.g., connect to <a
href="http://w.x.y.z:5000"> http://w.x.y.z:5000</a> where w.x.y.z is your
external IP).</li>
@ -632,8 +634,8 @@ following rule and try connecting to port 5000 (e.g., connect to <a
</blockquote>
<p>If you want to be able to access your server from the local network using
your external address, then if you have a static external IP you can
replace the loc-&gt;dmz rule above with:</p>
your external address, then if you have a static external IP you
can replace the loc-&gt;dmz rule above with:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -665,7 +667,7 @@ following rule and try connecting to port 5000 (e.g., connect to <a
<p>If you have a dynamic ip then you must ensure that your external interface
is up before starting Shorewall and you must take steps as follows
(assume that your external interface is <b>eth0</b>):</p>
(assume that your external interface is <b>eth0</b>):</p>
<ol>
<li>Include the following in /etc/shorewall/params:<br>
@ -706,43 +708,44 @@ following rule and try connecting to port 5000 (e.g., connect to <a
</blockquote>
<p>If you want to access your server from the DMZ using your external IP
address, see <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
address, see <a href="FAQ.htm#faq2a">FAQ 2a</a>.</p>
<p><img border="0" src="images/BD21298_2.gif" width="13" height="13">
    At this point, add the DNAT and ACCEPT rules for your servers.
</p>
    At this point, add the DNAT and ACCEPT rules for your
servers. </p>
<h2 align="left">Domain Name Server (DNS)</h2>
<p align="left">Normally, when you connect to your ISP, as part of getting
an IP address your firewall's <i>Domain Name Service </i>(DNS) resolver
will be automatically configured (e.g., the /etc/resolv.conf file will
be written). Alternatively, your ISP may have given you the IP address
of a pair of DNS <i> name servers</i> for you to manually configure as
your primary and secondary name servers. It is <u>your</u> responsibility
will be automatically configured (e.g., the /etc/resolv.conf file
will be written). Alternatively, your ISP may have given you the IP
address of a pair of DNS <i> name servers</i> for you to manually configure
as your primary and secondary name servers. It is <u>your</u> responsibility
to configure the resolver in your internal systems. You can take one
of two approaches:</p>
of two approaches:</p>
<ul>
<li>
<p align="left">You can configure your internal systems to use your ISP's
name servers. If you ISP gave you the addresses of their servers
or if those addresses are available on their web site, you can configure
or if those addresses are available on their web site, you can configure
your internal systems to use those addresses. If that information
isn't available, look in /etc/resolv.conf on your firewall system --
the name servers are given in "nameserver" records in that file. </p>
isn't available, look in /etc/resolv.conf on your firewall system
-- the name servers are given in "nameserver" records in that file.
</p>
</li>
<li>
<p align="left"><img border="0" src="images/BD21298_2.gif"
width="13" height="13">
    You can configure a<i> Caching Name Server </i>on your
firewall or in your DMZ.<i> </i>Red Hat has an RPM for a caching name
server (which also requires the 'bind' RPM) and for Bering users,
there is dnscache.lrp. If you take this approach, you configure your
internal systems to use the caching name server as their primary (and
only) name server. You use the internal IP address of the firewall
firewall or in your DMZ.<i> </i>Red Hat has an RPM for a caching
name server (which also requires the 'bind' RPM) and for Bering
users, there is dnscache.lrp. If you take this approach, you configure
your internal systems to use the caching name server as their primary
(and only) name server. You use the internal IP address of the firewall
(10.10.10.254 in the example above) for the name server address if
you choose to run the name server on your firewall. To allow your local
systems to talk to your caching name server, you must open port 53
@ -918,8 +921,8 @@ by adding the rules in /etc/shorewall/rules. </p>
<div align="left">
<p align="left">Those rules allow DNS access from your firewall and may be
removed if you commented out the line in /etc/shorewall/policy allowing
all connections from the firewall to the internet.</p>
removed if you commented out the line in /etc/shorewall/policy
allowing all connections from the firewall to the internet.</p>
</div>
<div align="left">
@ -1056,8 +1059,8 @@ by adding the rules in /etc/shorewall/rules. </p>
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular application
uses, look <a href="ports.htm">here</a>.</p>
<p align="left">If you don't know what port and protocol a particular
application uses, look <a href="ports.htm">here</a>.</p>
</div>
<div align="left">
@ -1098,11 +1101,13 @@ uses, look <a href="ports.htm">here</a>.</p>
<div align="left">
<p align="left"> </p>
<p align="left"><img src="images/leaflogo.gif" alt="(LEAF Logo)"
width="49" height="36">
    Bering users will want to add the following two rules to be compatible
with Jacques's Shorewall configuration.<br>
</p>
</p>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -1146,6 +1151,7 @@ with Jacques's Shorewall configuration.<br>
</table>
</blockquote>
</div>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Now modify /etc/shorewall/rules to add or remove other
@ -1178,9 +1184,9 @@ with Jacques's Shorewall configuration.<br>
and stopped using "shorewall stop". When the firewall is stopped,
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart" command.
If you want to totally remove any trace of Shorewall from your Netfilter
configuration, use "shorewall clear".</p>
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
</div>
<div align="left">
@ -1196,15 +1202,15 @@ set of hosts, modify /etc/shorewall/routestopped accordingly.</p>
<div align="left">
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate configuration</a></i>
and test it using the <a
an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/30/2003 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
@ -1223,5 +1229,6 @@ to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
<br>
<br>
<br>
<br>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@ -28,12 +28,10 @@
</tbody>
</table>
<p align="left">Beginning with version 1.2.0, Shorewall has limited support
for traffic shaping/control. In order to use traffic shaping under
Shorewall, it is essential that you get a copy of the <a
href="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping HOWTO</a>,
version 0.3.0 or later. You must also install the iproute (iproute2)
package to provide the "ip" and "tc" utilities.</p>
<p align="left">Shorewall has limited support for traffic shaping/control.
In order to use traffic shaping under Shorewall, it is essential that
you get a copy of the <a href="http://ds9a.nl/lartc">Linux Advanced Routing
and Shaping HOWTO</a>, version 0.3.0 or later.</p>
<p align="left">Shorewall traffic shaping support consists of the following:</p>
@ -41,46 +39,46 @@ Shorewall, it is essential that you get a copy of the <a
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in
Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the
setting of this variable determines whether Shorewall clears the traffic
shaping configuration during Shorewall [re]start and Shorewall stop. <br>
Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the
setting of this variable determines whether Shorewall clears the traffic
shaping configuration during Shorewall [re]start and Shorewall stop. <br>
</li>
<li><b>/etc/shorewall/tcrules</b> - A file where you can specify
firewall marking of packets. The firewall mark value may be used
to classify packets for traffic shaping/control.<br>
<li><b>/etc/shorewall/tcrules</b> - A file where you can
specify firewall marking of packets. The firewall mark value may
be used to classify packets for traffic shaping/control.<br>
</li>
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you
can use to define your traffic shaping disciplines and classes.
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file
that is sourced by Shorewall during "shorewall start" and which
you can use to define your traffic shaping disciplines and classes.
I have provided a <a
href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a> that does
table-driven CBQ shaping but if you read the traffic shaping sections
of the HOWTO mentioned above, you can probably code your own faster
than you can learn how to use my sample. I personally use <a
href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of
2.4.20, HTB is a standard part of the kernel but iproute2 must be patched
in order to use it.<br>
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
the firewall.<br>
In tcstart, when you want to run the 'tc' utility, use
the run_tc function supplied by shorewall if you want tc errors
to stop the firewall.<br>
<br>
You can generally use off-the-shelf traffic shaping scripts by simply
copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If you
use use Masquerading or SNAT (i.e., you only have one external IP address)
modified it according to the Wonder Shaper README). <b>WARNING: </b>If
you use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file that
is sourced by Shorewall when it is clearing traffic shaping. This
file is normally not required as Shorewall's method of clearing
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file
that is sourced by Shorewall when it is clearing traffic shaping.
This file is normally not required as Shorewall's method of clearing
qdisc and filter definitions is pretty general.</li>
</ul>
@ -101,14 +99,15 @@ qdisc and filter definitions is pretty general.</li>
</ol>
To start traffic shaping when you bring up your network interfaces, you
will have to arrange for your traffic shaping configuration script to be
run at that time. How you do that is distribution dependent and will not
be covered here. You then should:<br>
run at that time. How you do that is distribution dependent and will not be
covered here. You then should:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier, you
can mark packets using entries in /etc/shorewall/tcrules.</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear
scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier,
you can mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
@ -131,20 +130,20 @@ be covered here. You then should:<br>
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option
in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255. Beginning with
Shorewall version 1.3.14, this value may be optionally followed by ":" and
either 'F' or 'P' to designate that the marking will occur in the FORWARD
or PREROUTING chains respectively. If this additional specification is omitted,
the chain used to mark packets will be determined by the setting of the
MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<li>MARK - Specifies the mark value is to be assigned in
case of a match. This is an integer in the range 1-255. Beginning
with Shorewall version 1.3.14, this value may be optionally followed by
":" and either 'F' or 'P' to designate that the marking will occur in the
FORWARD or PREROUTING chains respectively. If this additional specification
is omitted, the chain used to mark packets will be determined by the setting
of the MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<br>
Example - 5<br>
</li>
@ -164,9 +163,9 @@ in <a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
/etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list of
Port names (from /etc/services), port numbers or port ranges (e.g.,
21:22); if the protocol is "icmp", this column is interpreted as
the destination icmp type(s).<br>
Port names (from /etc/services), port numbers or port ranges (e.g.,
21:22); if the protocol is "icmp", this column is interpreted as
the destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client.
If omitted, any source port is acceptable. Specified as a comma-separate
@ -287,9 +286,9 @@ the destination icmp type(s).<br>
<p>While I am currently using the HTB version of <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (I just copied
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown in
the Wondershaper README), I have also run with the following set of hand-crafted
rules in my <b>/etc/shorewall/tcstart</b> file:<br>
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown
in the Wondershaper README), I have also run with the following set of
hand-crafted rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<blockquote>
@ -315,8 +314,8 @@ the destination icmp type(s).<br>
<ol>
<li>I wanted to allow up to 140kbits/second for traffic outbound
from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic
can use all available bandwidth if there is no traffic from the local systems
or from my laptop or firewall).</li>
can use all available bandwidth if there is no traffic from the local
systems or from my laptop or firewall).</li>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.<br>
</li>
@ -329,5 +328,6 @@ the destination icmp type(s).<br>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

View File

@ -42,7 +42,7 @@
<h3 align="left">If the firewall fails to start</h3>
If you receive an error message when starting or restarting
the firewall and you can't determine the cause, then do the following:
the firewall and you can't determine the cause, then do the following:
<ul>
<li>Make a note of the error message that you see.<br>
@ -50,9 +50,9 @@ the firewall and you can't determine the cause, then do the following:
<li>shorewall debug start 2&gt; /tmp/trace</li>
<li>Look at the /tmp/trace file and see if that helps you
determine what the problem is. Be sure you find the place in the log
where the error message you saw is generated -- in 99.9% of the cases, it
will not be near the end of the log because after startup errors, Shorewall
goes through a "shorewall stop" phase which will also be traced.</li>
where the error message you saw is generated -- in 99.9% of the cases, it
will not be near the end of the log because after startup errors, Shorewall
goes through a "shorewall stop" phase which will also be traced.</li>
<li>If you still can't determine what's wrong then see the
<a href="support.htm">support page</a>.</li>
@ -74,18 +74,18 @@ goes through a "shorewall stop" phase which will also be traced.</li>
<h3>Your network environment</h3>
<p>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular snafus:
actually an ill-conceived network setup. Here are several popular snafus:
</p>
<ul>
<li>Port Forwarding where client and server are in
the same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe that the system
is in the 'net' zone.</li>
the same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the
external subnet, thinking that Shorewall will suddenly believe that
the system is in the 'net' zone.</li>
<li>Multiple interfaces connected to the same HUB or Switch.
Given the way that the Linux kernel respond to ARP "who-has" requests,
this type of setup does NOT work the way that you expect it to.</li>
Given the way that the Linux kernel respond to ARP "who-has" requests,
this type of setup does NOT work the way that you expect it to.</li>
</ul>
@ -93,9 +93,9 @@ this type of setup does NOT work the way that you expect it to.</li>
<p align="left">If the appropriate policy for the connection that you are
trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
TO MAKE IT WORK. Such additional rules will NEVER make it work, they add
clutter to your rule set and they represent a big security hole in the
event that you forget to remove them later.</p>
TO MAKE IT WORK. Such additional rules will NEVER make it work, they
add clutter to your rule set and they represent a big security hole in
the event that you forget to remove them later.</p>
<p align="left">I also recommend against setting all of your policies to
ACCEPT in an effort to make something work. That robs you of one of
@ -105,8 +105,8 @@ event that you forget to remove them later.</p>
<p align="left">Check your log ("/sbin/shorewall show log"). If you don't
see Shorewall messages, then your problem is probably NOT a Shorewall
problem. If you DO see packet messages, it may be an indication that you
are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
problem. If you DO see packet messages, it may be an indication that you
are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<p align="left">While you are troubleshooting, it is a good idea to clear
two variables in /etc/shorewall/shorewall.conf:</p>
@ -129,8 +129,8 @@ are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<ul>
<li>all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the "all"-&gt;"all" REJECT policy
(see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
chain -- the packet was rejected under the "all"-&gt;"all" REJECT
policy (see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
<li>IN=eth2 - the packet entered the firewall via eth2</li>
<li>OUT=eth1 - if accepted, the packet would be sent on eth1</li>
<li>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</li>
@ -152,7 +152,7 @@ are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<h3 align="left">'Ping' Problems?</h3>
Either can't ping when you think you should be able to or are able to ping
when you think that you shouldn't be allowed? Shorewall's 'Ping' Management<a
when you think that you shouldn't be allowed? Shorewall's 'Ping' Management<a
href="ping.html"> is described here</a>.<br>
<h3 align="left">Other Gotchas</h3>
@ -163,18 +163,18 @@ or FORWARD chains? This means that:
<ol>
<li>your zone definitions are screwed up and the host that
is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
file are you?); or</li>
is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
file are you?); or</li>
<li>the source and destination hosts are both connected to
the same interface and you don't have a policy or rule for the
the same interface and you don't have a policy or rule for the
source zone to or from the destination zone.</li>
</ol>
</li>
<li>Remember that Shorewall doesn't automatically allow ICMP
type 8 ("ping") requests to be sent between zones. If you want pings
to be allowed between zones, you need a rule of the form:<br>
type 8 ("ping") requests to be sent between zones. If you want
pings to be allowed between zones, you need a rule of the form:<br>
<br>
    ACCEPT    &lt;source zone&gt;    &lt;destination zone&gt;   
icmp    echo-request<br>
@ -184,26 +184,26 @@ source zone to or from the destination zone.</li>
<br>
    10.1.1.2    eth0    130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type
8 between the zone containing the system you are pinging from and
the zone containing 10.1.1.2, the ping requests will be dropped. </li>
and you ping 130.252.100.18, unless you have allowed icmp
type 8 between the zone containing the system you are pinging from
and the zone containing 10.1.1.2, the ping requests will be dropped. </li>
<li>If you specify "routefilter" for an interface, that
interface must be up prior to starting the firewall.</li>
<li>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect of
routing is that in order for two hosts to communicate, the routing
between them must be set up <u>in both directions.</u> So when setting
up routing between <b>A</b> and<b> B</b>, be sure to verify that the
route from <b>B</b> back to <b>A</b> is defined.</li>
<li>Is your routing correct? For example, internal systems
usually need to be configured with their default gateway set to
the IP address of their nearest firewall interface. One often overlooked
aspect of routing is that in order for two hosts to communicate, the
routing between them must be set up <u>in both directions.</u> So
when setting up routing between <b>A</b> and<b> B</b>, be sure to
verify that the route from <b>B</b> back to <b>A</b> is defined.</li>
<li>Some versions of LRP (EigerStein2Beta for example) have
a shell with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected
shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a
href="kernel.htm">Click here to see my kernel configuration.</a> </li>
<li>Some features require the "ip" program. That program
is generally included in the "iproute" package which should be included
<li>Shorewall requires the "ip" program. That program is
generally included in the "iproute" package which should be included
with your distribution (though many distributions don't install iproute
by default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
@ -222,11 +222,12 @@ add all external addresses to be use with NAT unless you have set <a
<blockquote> </blockquote>
</font>
<p><font size="2">Last updated 2/18/2003 - Tom Eastep</font> </p>
<p><font size="2">Last updated 2/21/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

View File

@ -45,7 +45,7 @@
local network.</li>
<li>Single public IP address.</li>
<li>Internet connection through cable modem, DSL, ISDN,
Frame Relay, dial-up ...</li>
Frame Relay, dial-up ...</li>
</ul>
@ -59,22 +59,23 @@ Frame Relay, dial-up ...</li>
configure the above setup using the Mandrake "Internet Connection Sharing"
applet. From the Mandrake Control Center, select "Network &amp; Internet"
then "Connection Sharing".<br>
</b></p>
</b></p>
<p><b>Note however, that the Shorewall configuration produced by Mandrake
Internet Connection Sharing is strange and is apt to confuse you if you use
the rest of this documentation (it has two local zones; "loc" and "masq"
where "loc" is empty; this conflicts with this documentation which assumes
a single local zone "loc"). We therefore recommend that once you have set
up this sharing that you uninstall the Mandrake Shorewall RPM and install
the one from the <a href="download.htm">download page</a> then follow the
instructions in this Guide.</b><br>
the rest of this documentation (it has two local zones; "loc" and "masq" where
"loc" is empty; this conflicts with this documentation which assumes a single
local zone "loc"). We therefore recommend that once you have set up this
sharing that you uninstall the Mandrake Shorewall RPM and install the one
from the <a href="download.htm">download page</a> then follow the instructions
in this Guide.</b><br>
</p>
<p>This guide assumes that you have the iproute/iproute2 package installed
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can
tell if this package is installed by the presence of an <b>ip</b> program
on your firewall system. As root, you can use the 'which' command to
check for this program:</p>
tell if this package is installed by the presence of an <b>ip</b>
program on your firewall system. As root, you can use the 'which'
command to check for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -83,8 +84,8 @@ tell if this package is installed by the presence of an <b>ip</b> program
changes. Points at which configuration changes are recommended are
flagged with <img border="0" src="images/BD21298_.gif" width="13"
height="13">
. Configuration notes that are unique to LEAF/Bering are marked
with <img src="images/leaflogo.gif" alt="(LEAF Logo)" width="49"
. Configuration notes that are unique to LEAF/Bering are
marked with <img src="images/leaflogo.gif" alt="(LEAF Logo)" width="49"
height="36">
</p>
@ -92,15 +93,16 @@ tell if this package is installed by the presence of an <b>ip</b> program
    If you edit your configuration files on a Windows system,
you must save them as Unix files if your editor supports that option
or you must run them through dos2unix before trying to use them. Similarly,
if you copy a configuration file from your Windows hard drive to a floppy
disk, you must run dos2unix against the copy before using it with Shorewall.</p>
if you copy a configuration file from your Windows hard drive to a
floppy disk, you must run dos2unix against the copy before using it with
Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
Version of dos2unix</a></li>
<li><a
href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
of dos2unix</a></li>
of dos2unix</a></li>
</ul>
@ -114,15 +116,15 @@ a few of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
href="/pub/shorewall/LATEST.samples/two-interfaces.tgz">two-interface sample</a>,
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to
/etc/shorewall (these files will replace files with the same name).</b></p>
/etc/shorewall (these files will replace files with the same name).</b></p>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
and default entries.</p>
file on your system -- each file contains detailed configuration
instructions and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the two-interface sample configuration, the
following zone names are used:</p>
set of <i>zones.</i> In the two-interface sample configuration,
the following zone names are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -163,13 +165,13 @@ the <a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in /etc/shorewall/policy
file matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or
DROP  the request is first checked against the rules in /etc/shorewall/common
DROP  the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the two-interface sample has
the following policies:</p>
<p>The /etc/shorewall/policy file included with the two-interface sample
has the following policies:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -260,9 +262,9 @@ firewall to the internet (if you uncomment the additional policy)</li>
height="635">
</p>
<p align="left">The firewall has two network interfaces. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<p align="left">The firewall has two network interfaces. Where Internet connectivity
is through a cable or DSL "Modem", the <i>External Interface</i> will be
the ethernet adapter that is connected to that "Modem" (e.g., <b>eth0</b>) 
<u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint <u>P</u>rotocol
over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
@ -278,9 +280,9 @@ connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
<p align="left">Your <i>Internal Interface</i> will be an ethernet adapter
(eth1 or eth0) and will be connected to a hub or switch. Your other
computers will be connected to the same hub/switch (note: If you have
only a single internal system, you can connect the firewall directly
to the computer using a <i>cross-over </i> cable).</p>
computers will be connected to the same hub/switch (note: If you
have only a single internal system, you can connect the firewall
directly to the computer using a <i>cross-over </i> cable).</p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
@ -293,22 +295,23 @@ connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
width="13" height="13">
    The Shorewall two-interface sample configuration assumes
that the external interface is <b>eth0</b> and the internal interface
is <b>eth1</b>. If your configuration is different, you will have to
modify the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file accordingly. While you are there, you may wish to review the
list of options that are specified for the interfaces. Some hints:</p>
is <b>eth1</b>. If your configuration is different, you will have
to modify the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
<ul>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>,
you can replace the "detect" in the second column with "-". </p>
you can replace the "detect" in the second column with "-".
</p>
</li>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the
option list. </p>
or if you have a static IP address, you can remove "dhcp" from
the option list. </p>
</li>
</ul>
@ -318,15 +321,15 @@ list of options that are specified for the interfaces. Some hints:</p>
<p align="left">Before going further, we should say a few words about Internet
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign you
a single <i> Public</i> IP address. This address may be assigned via
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of establishing
your connection when you dial in (standard modem) or establish your PPP
connection. In rare cases, your ISP may assign you a<i> static</i> IP
address; that means that you configure your firewall's external interface
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of
establishing your connection when you dial in (standard modem) or establish
your PPP connection. In rare cases, your ISP may assign you a<i> static</i>
IP address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>However your external address
is assigned, it will be shared by all of your systems when you access the
Internet. You will have to assign your own addresses in your internal network
(the Internal Interface on your firewall plus your other computers). RFC
1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
is assigned, it will be shared by all of your systems when you access
the Internet. You will have to assign your own addresses in your internal
network (the Internal Interface on your firewall plus your other computers).
RFC 1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -335,8 +338,8 @@ is assigned, it will be shared by all of your systems when you access the
<div align="left">
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    Before starting Shorewall, you should look at the IP
address of your external interface and if it is one of the above
    Before starting Shorewall, you should look at the
IP address of your external interface and if it is one of the above
ranges, you should remove the 'norfc1918' option from the external
interface's entry in /etc/shorewall/interfaces.</p>
</div>
@ -344,15 +347,15 @@ is assigned, it will be shared by all of your systems when you access the
<div align="left">
<p align="left">You will want to assign your addresses from the same <i>
sub-network </i>(<i>subnet)</i>.  For our purposes, we can consider a subnet
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a
subnet will have a <i>Subnet Mask </i>of 255.255.255.0. The address
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255 is
reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
a subnet is described using <a
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such
a subnet will have a <i>Subnet Mask </i>of 255.255.255.0. The address
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255 is
reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR) notation</a> with consists of the subnet address followed
by "/24". The "24" refers to the number of consecutive leading "1" bits
from the left of the subnet mask. </p>
by "/24". The "24" refers to the number of consecutive leading "1"
bits from the left of the subnet mask. </p>
</div>
<div align="left">
@ -390,7 +393,7 @@ from the left of the subnet mask. </p>
<div align="left">
<p align="left">It is conventional to assign the internal interface either
the first usable address in the subnet (10.10.10.1 in the above
example) or the last usable address (10.10.10.254).</p>
example) or the last usable address (10.10.10.254).</p>
</div>
<div align="left">
@ -412,8 +415,8 @@ the above diagram) should be configured with their<i> default gateway<
<p align="left">The foregoing short discussion barely scratches the surface
regarding subnetting and routing. If you are interested in learning
more about IP addressing and routing, I highly recommend <i>"IP Fundamentals:
What Everyone Needs to Know about Addressing &amp; Routing",</i> Thomas
A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
What Everyone Needs to Know about Addressing &amp; Routing",</i>
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p>
<p align="left">The remainder of this quide will assume that you have configured
your network as shown here:</p>
@ -428,33 +431,33 @@ the above diagram) should be configured with their<i> default gateway<
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13" alt="">
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP might assign
your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24
subnet then you will need to select a DIFFERENT RFC 1918 subnet for your
local network.</b><br>
your external interface an RFC 1918 address. If that address is in the
10.10.10.0/24 subnet then you will need to select a DIFFERENT RFC 1918
subnet for your local network.</b><br>
</p>
<h2 align="left">IP Masquerading (SNAT)</h2>
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When one
of your local systems (let's assume computer 1) sends a connection request
to an internet host, the firewall must perform <i>Network Address
Translation </i>(NAT). The firewall rewrites the source address in
the packet to be the address of the firewall's external interface; in
other words, the firewall makes it look as if the firewall itself is
initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed across the internet so the remote host can't address its response
to computer 1). When the firewall receives a return packet, it rewrites
the destination address back to 10.10.10.1 and forwards the packet on to
computer 1. </p>
forward packets which have an RFC-1918 destination address. When
one of your local systems (let's assume computer 1) sends a connection
request to an internet host, the firewall must perform <i>Network
Address Translation </i>(NAT). The firewall rewrites the source address
in the packet to be the address of the firewall's external interface;
in other words, the firewall makes it look as if the firewall itself
is initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed across the internet so the remote host can't address its response
to computer 1). When the firewall receives a return packet, it rewrites
the destination address back to 10.10.10.1 and forwards the packet on
to computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> but you will also see the term <i>Source Network Address
Translation </i>(SNAT) used. Shorewall follows the convention used with
Netfilter:</p>
<p align="left">On Linux systems, the above process is often referred to
as<i> IP Masquerading</i> but you will also see the term <i>Source Network
Address Translation </i>(SNAT) used. Shorewall follows the convention used
with Netfilter:</p>
<ul>
<li>
@ -480,9 +483,9 @@ computer 1. </p>
height="13">
    If your external firewall interface is <b>eth0</b>, you
do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change the first column to the name
of your external interface and the second column to the name of your
internal interface.</p>
edit /etc/shorewall/masq and change the first column to the name of
your external interface and the second column to the name of your internal
interface.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
@ -495,8 +498,8 @@ internal interface.</p>
<img border="0" src="images/BD21298_.gif" width="13" height="13"
alt="">
    If you are using the Debian package, please check your shorewall.conf
file to ensure that the following are set correctly; if they are not, change
them appropriately:<br>
file to ensure that the following are set correctly; if they are not,
change them appropriately:<br>
</p>
<ul>
@ -510,12 +513,12 @@ internal interface.</p>
<p align="left">One of your goals may be to run one or more servers on your
local computers. Because these computers have RFC-1918 addresses,
it is not possible for clients on the internet to connect directly to
them. It is rather necessary for those clients to address their connection
requests to the firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
it is not possible for clients on the internet to connect directly
to them. It is rather necessary for those clients to address their
connection requests to the firewall who rewrites the destination address
to the address of your server and forwards the packet to that server.
When your server responds, the firewall automatically performs SNAT
to rewrite the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -589,9 +592,9 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
<ul>
<li>You must test the above rule from a client outside
of your local network (i.e., don't test from a browser running on
computers 1 or 2 or on the firewall). If you want to be able to
access your web server using the IP address of your external interface,
see <a href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
computers 1 or 2 or on the firewall). If you want to be able to access
your web server using the IP address of your external interface, see
<a href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000.</li>
@ -628,18 +631,18 @@ following rule and try connecting to port 5000.</li>
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13">
    At this point, modify /etc/shorewall/rules to add any
DNAT rules that you require.</p>
DNAT rules that you require.</p>
<h2 align="left">Domain Name Server (DNS)</h2>
<p align="left">Normally, when you connect to your ISP, as part of getting
an IP address your firewall's <i>Domain Name Service </i>(DNS) resolver
will be automatically configured (e.g., the /etc/resolv.conf file will
be written). Alternatively, your ISP may have given you the IP address
of a pair of DNS <i> name servers</i> for you to manually configure as
your primary and secondary name servers. Regardless of how DNS gets
configured on your firewall, it is <u>your</u> responsibility to configure
the resolver in your internal systems. You can take one of two approaches:</p>
will be automatically configured (e.g., the /etc/resolv.conf file
will be written). Alternatively, your ISP may have given you the IP
address of a pair of DNS <i> name servers</i> for you to manually configure
as your primary and secondary name servers. Regardless of how DNS gets
configured on your firewall, it is <u>your</u> responsibility to configure
the resolver in your internal systems. You can take one of two approaches:</p>
<ul>
<li>
@ -649,7 +652,7 @@ the resolver in your internal systems. You can take one of two approaches:<
or if those addresses are available on their web site, you can configure
your internal systems to use those addresses. If that information
isn't available, look in /etc/resolv.conf on your firewall system
-- the name servers are given in "nameserver" records in that file.
-- the name servers are given in "nameserver" records in that file.
</p>
</li>
<li>
@ -660,12 +663,12 @@ the resolver in your internal systems. You can take one of two approaches:<
firewall.<i> </i>Red Hat has an RPM for a caching name server
(the RPM also requires the 'bind' RPM) and for Bering users, there
is dnscache.lrp. If you take this approach, you configure your internal
systems to use the firewall itself as their primary (and only) name
server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your
local systems to talk to your caching name server, you must open port
53 (both UDP and TCP) from the local network to the firewall; you
do that by adding the following rules in /etc/shorewall/rules. </p>
systems to use the firewall itself as their primary (and only) name server.
You use the internal IP address of the firewall (10.10.10.254 in the
example above) for the name server address. To allow your local systems
to talk to your caching name server, you must open port 53 (both UDP
and TCP) from the local network to the firewall; you do that by adding
the following rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -880,19 +883,19 @@ do that by adding the following rules in /etc/shorewall/rules. </p>
<div align="left">
<p align="left">Those two rules would of course be in addition to the rules
listed above under "You can configure a Caching Name Server on your
firewall"</p>
listed above under "You can configure a Caching Name Server on
your firewall"</p>
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular application
uses, look <a href="ports.htm">here</a>.</p>
<p align="left">If you don't know what port and protocol a particular
application uses, look <a href="ports.htm">here</a>.</p>
</div>
<div align="left">
<p align="left"><b>Important: </b>I don't recommend enabling telnet to/from
the internet because it uses clear text (even for login!). If you
want shell access to your firewall from the internet, use SSH:</p>
the internet because it uses clear text (even for login!). If
you want shell access to your firewall from the internet, use SSH:</p>
</div>
<div align="left">
@ -977,8 +980,8 @@ uses, look <a href="ports.htm">here</a>.</p>
<p align="left"><br>
<img border="0" src="images/BD21298_.gif" width="13" height="13">
    Now edit your /etc/shorewall/rules file to add or delete
other connections as required.</p>
    Now edit your /etc/shorewall/rules file to add or
delete other connections as required.</p>
</div>
<div align="left">
@ -990,10 +993,10 @@ uses, look <a href="ports.htm">here</a>.</p>
width="13" height="13" alt="Arrow">
    The <a href="Install.htm">installation procedure </a>
configures your system to start Shorewall at system boot  but beginning
with Shorewall version 1.3.9 startup is disabled so that your system
won't try to start Shorewall before configuration is complete. Once you
have completed configuration of your firewall, you can enable Shorewall
startup by removing the file /etc/shorewall/startup_disabled.<br>
with Shorewall version 1.3.9 startup is disabled so that your system
won't try to start Shorewall before configuration is complete. Once
you have completed configuration of your firewall, you can enable Shorewall
startup by removing the file /etc/shorewall/startup_disabled.<br>
</p>
<p align="left"><font color="#ff0000"><b>IMPORTANT</b>: </font><font
@ -1008,8 +1011,8 @@ startup by removing the file /etc/shorewall/startup_disabled.<br>
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
</div>
<div align="left">
@ -1017,8 +1020,8 @@ your Netfilter configuration, use "shorewall clear".</p>
height="13">
    The two-interface sample assumes that you want to enable
routing to/from <b>eth1 </b>(the local network) when Shorewall is
stopped. If your local network isn't connected to <b>eth1</b> or if you
wish to enable access to/from other hosts, change /etc/shorewall/routestopped
stopped. If your local network isn't connected to <b>eth1</b> or if
you wish to enable access to/from other hosts, change /etc/shorewall/routestopped
accordingly.</p>
</div>
@ -1027,18 +1030,19 @@ wish to enable access to/from other hosts, change /etc/shorewall/routesto
the internet, do not issue a "shorewall stop" command unless you
have added an entry for the IP address that you are connected from
to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate configuration</a></i>
and test it using the <a
Also, I don't recommend using "shorewall restart"; it is better to
create an <i><a href="configuration_file_basics.htm#Configs">alternate
configuration</a></i> and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/13/2003 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a><br>
</p>
<br>
<br>
</body>
</html>

View File

@ -35,52 +35,62 @@
<h3> </h3>
<h3>Version &gt;= 1.4.0</h3>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<b>IMPORTANT: Shorewall &gt;=1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options are no
longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf. ICMP
echo-request (ping) packets are treated just like any other connection request
and are subject to rules and policies.</li>
longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
ICMP echo-request (ping) packets are treated just like any other connection
request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in /etc/shorewall/interfaces
now generate a Shorewall error at startup (they always have produced warnings
in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall
1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are
determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts file has
been eliminated; use entries in the routestopped file instead.</li>
1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are
determined by BOTH the interfaces and hosts files when there are entries for
the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts file
has been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are not dropped by default; there
is no need for your own /etc/shorewall/common file simply to avoid logging
these packets.</li>
<li value="6">Late-arriving DNS replies are not dropped by default;
there is no need for your own /etc/shorewall/common file simply to avoid
logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have been
moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include it from
/etc/shorewall/icmpdef, you will need to modify that file.</li>
/etc/shorewall/icmpdef, you will need to modify that file.</li>
<li value="8">The 'multi' interface option is no longer supported.  Shorewall
will generate rules for sending packets back out the same interface that they
arrived on in two cases:</li>
will generate rules for sending packets back out the same interface that
they arrived on in two cases:</li>
</ul>
<ul>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or from
the destination zone. An explicit policy names both zones and does not use
the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone to or
from the destination zone including rules that use the 'all' reserved word.
Exception: if the source zone and destination zone are the same then the rule
must be explicit - it must name the zone in both the SOURCE and DESTINATION
columns.</li>
Exception: if the source zone and destination zone are the same then the
rule must be explicit - it must name the zone in both the SOURCE and DESTINATION
columns.</li>
</ul>
</ul>
<ul>
</ul>
@ -94,14 +104,13 @@ columns.</li>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST subnet on the
interface (as shown by "ip addr show <i>interface</i>") and would masquerade
traffic from that subnet. Any other subnets that routed through eth1 needed
their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT
applied.</li>
interface (as shown by "ip addr show <i>interface</i>") and would masquerade
traffic from that subnet. Any other subnets that routed through eth1 needed
their own entry in /etc/shorewall/masq to be masqueraded or to have SNAT
applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
routing table to determine ALL subnets routed through the named interface.
Traffic originating in ANY of those subnets is masqueraded or has SNAT
applied.</li>
Traffic originating in ANY of those subnets is masqueraded or has SNAT applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
@ -133,16 +142,16 @@ applied.</li>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13" height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request (ping)
handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be used
(If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes
handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be used
(If the option is not set in your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes
is assumed). I don't plan on supporting the old handling indefinitely so
I urge current users to migrate to using the new handling as soon as possible.
I urge current users to migrate to using the new handling as soon as possible.
See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to
version 1.3.10, you will need to use the '--force' option:<br>
version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
@ -151,7 +160,7 @@ version 1.3.10, you will need to use the '--force' option:<br>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions. If
you have an application that uses functions from that file, your application
you have an application that uses functions from that file, your application
will need to be changed to reflect this change of location.<br>
<h3>Version &gt;= 1.3.8</h3>
@ -182,26 +191,26 @@ you have an application that uses functions from that file, your application
1.3.3 and later:</p>
<ol>
<li>Be sure you have a backup --
you will need to transcribe any Shorewall
<li>Be sure you have a backup
-- you will need to transcribe any Shorewall
configuration changes that you have made
to the new configuration.</li>
<li>Replace the shorwall.lrp package
provided on the Bering floppy with the
later one. If you did not obtain the
later version from Jacques's site, see
additional instructions below.</li>
later one. If you did not obtain the later
version from Jacques's site, see additional
instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget to
backup root.lrp !</li>
entry if present. Then do not forget
to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need to add
the following two Bering-specific rules to /etc/shorewall/rules:</p>
for setting up a two-interface firewall</a> plus you also need to
add the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
@ -222,8 +231,8 @@ additional instructions below.</li>
<br>
<font face="Courier">run_iptables -A newnotsyn -j RETURN
# So that the connection tracking table can be rebuilt<br>
                                    # from non-SYN packets
after takeover.<br>
                                    # from non-SYN
packets after takeover.<br>
 </font> </p>
</li>
<li>
@ -291,5 +300,6 @@ additional instructions below.</li>
<br>
<br>
<br>
<br>
</body>
</html>