holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Documentation Updates

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@448 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-14 21:27:03 +00:00
parent 5f259f6070
commit 6dd91309a8
9 changed files with 6107 additions and 5995 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1184
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

39
STABLE/documentation/ping.html
View File

@ -24,15 +24,15 @@
</table>
<br>
Shorewall 'Ping' management has evolved over time with the latest change
coming in Shorewall version 1.3.14. In that version, a new option (<b>OLD_PING_HANDLING</b>)
was added to /etc/shorewall/shorewall.conf. The value of that option determines
the overall handling of ICMP echo requests (pings).<br>
coming in Shorewall version 1.3.14. In that version, a new option (<b>OLD_PING_HANDLING</b>)
was added to /etc/shorewall/shorewall.conf. The value of that option determines
the overall handling of ICMP echo requests (pings).<br>
<h2>Shorewall Versions &gt;= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf</h2>
In 1.3.14, Ping handling was put under control of the rules and policies
just like any other connection request. In order to accept ping requests from
zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need
a rule in /etc/shoreall/rules of the form:<br>
just like any other connection request. In order to accept ping requests
from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT and z1
is not the firewall zone, you need a rule in /etc/shoreall/rules of the form:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
@ -42,7 +42,7 @@ a rule in /etc/shoreall/rules of the form:<br>
To permit ping from the local zone to the firewall:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
If you would like to accept 'ping' by default even when the relevant
policy is DROP or REJECT, create <b>/etc/shorewall/icmpdef </b>if it doesn't
@ -52,7 +52,7 @@ already exist and in that file place the following command:<br>
<pre><b><font color="#009900">run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT<br></font></b></pre>
</blockquote>
With that rule in place, if you want to ignore 'ping' from z1 to z2 then
you need a rule of the form:<br>
you need a rule of the form:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
@ -62,7 +62,7 @@ you need a rule of the form:<br>
To drop ping from the internet, you would need this rule in /etc/shorewall/rules:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
<blockquote> </blockquote>
@ -74,8 +74,8 @@ icmp&nbsp;&nbsp;&nbsp; 8<br>
<ol>
<li>The <b>noping</b> and <b>filterping </b>interface options in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>The <b>FORWARDPING</b> option in<a href="Documentation.htm#Conf">
/etc/shorewall/shorewall.conf</a>.</li>
<li>The <b>FORWARDPING</b> option in<a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf</a>.</li>
<li>Explicit rules in <a href="Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
</ol>
@ -98,7 +98,7 @@ icmp&nbsp;&nbsp;&nbsp; 8<br>
the interface that receives the ping request then the request will be responded
to with an ICMP echo-reply.</li>
<li>If <b>noping</b> is specified for the interface that receives the
ping request then the request is ignored.</li>
ping request then the request is ignored.</li>
<li>If <b>filterping </b>is specified for the interface then the request
is passed to the rules/policy evaluation.</li>
@ -111,10 +111,10 @@ ping request then the request is ignored.</li>
Ping requests are ICMP type 8. So the general rule format is:<br>
<br>
&nbsp;&nbsp;&nbsp; <i>Target&nbsp;&nbsp;&nbsp; Source&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp; </i>icmp&nbsp;&nbsp;&nbsp; 8<br>
Destination&nbsp;&nbsp;&nbsp; </i>icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 1. Accept pings from the net to the dmz (pings are responded to
with an ICMP echo-reply):<br>
with an ICMP echo-reply):<br>
<br>
&nbsp;&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
@ -125,12 +125,12 @@ with an ICMP echo-reply):<br>
icmp&nbsp;&nbsp;&nbsp; 8<br>
<h3>Policy Evaluation</h3>
If no applicable rule is found, then the policy for the source to the destination
is applied.<br>
If no applicable rule is found, then the policy for the source to the
destination is applied.<br>
<ol>
<li>If the relevant policy is ACCEPT then the request is responded to
with an ICMP echo-reply.</li>
with an ICMP echo-reply.</li>
<li>If <b>FORWARDPING</b> is set to Yes in /etc/shorewall/shorewall.conf
then the request is responded to with an ICMP echo-reply.</li>
<li>Otherwise, the relevant REJECT or DROP policy is used and the request
@ -138,13 +138,14 @@ with an ICMP echo-reply.</li>
</ol>
<p><font size="2">Updated 1/21/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font size="2">Updated 2/14/2003 - <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></p>
<br>
<br>
<br>
<br>
</body>
</html>

113
STABLE/documentation/seattlefirewall_index.htm
View File

@ -57,6 +57,7 @@
<div align="center"><a
href="http://shorewall.sf.net/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a><br>
@ -73,6 +74,7 @@
</tbody>
</table>
@ -101,6 +103,7 @@
<h2 align="left">What is it?</h2>
@ -136,19 +139,20 @@ the GNU General Public License</a> as published by the Free Software
<br>
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 for more details.<br>
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 for
more details.<br>
<br>
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>
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>
@ -175,8 +179,8 @@ with this program; if not, write to the Free Software
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric Wolzak
have a LEAF (router/firewall/gateway on a floppy,
</a>Jacques Nilo 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.10 and Kernel-2.4.18.
You can find their work at: <a
@ -186,6 +190,7 @@ with this program; if not, write to the Free Software
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
</p>
@ -193,6 +198,7 @@ Bering 1.0 Final!!! </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>
@ -208,6 +214,7 @@ Bering 1.0 Final!!! </b><br>
<h2>News</h2>
@ -229,7 +236,7 @@ Bering 1.0 Final!!! </b><br>
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
@ -237,18 +244,18 @@ Bering 1.0 Final!!! </b><br>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options in
/etc/shorewall/interfaces will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
@ -257,44 +264,56 @@ of just the interface name:<br>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<li>Support for VLAN devices with names of the form $DEV.$VID
(e.g., eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
<li>In /etc/shorewall/tcrules, the MARK 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>
</li>
<li>When an interface name is entered in the SUBNET column of
the /etc/shorewall/masq file, Shorewall previously masqueraded traffic
from only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
Beginning with Shorewall 1.3.14, if you enter an interface name
in the SUBNET column, shorewall will use the firewall's routing table
to construct the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>  [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
connected to an interface that is specified in the SUBNET column of an
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need changing.
In most cases, you will simply be able to remove redundant entries. In some
cases though, you might want to change from using the interface name to
listing specific subnetworks if the change described above will cause masquerading
to occur on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
@ -303,15 +322,19 @@ on subnetworks that you don't wish to masquerade.<br>
Example 3 -- What if your current configuration is like this?<br>
 <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<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>
</li>
</ol>
<br>
@ -319,11 +342,12 @@ on subnetworks that you don't wish to masquerade.<br>
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard. See
<a href="http://www.webmin.com">http://www.webmin.com</a>.<b> </b>
Webmin version 1.060 now has Shorewall support included as standard.
See <a href="http://www.webmin.com">http://www.webmin.com</a>.<b>
</b>
<p><b></b></p>
<p><b></b></p>
<ul>
@ -331,6 +355,7 @@ on subnetworks that you don't wish to masquerade.<br>
</ul>
@ -338,6 +363,7 @@ on subnetworks that you don't wish to masquerade.<br>
<p><b></b><a href="News.htm">More News</a></p>
@ -352,6 +378,7 @@ on subnetworks that you don't wish to masquerade.<br>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
@ -364,6 +391,7 @@ on subnetworks that you don't wish to masquerade.<br>
</tbody>
</table>
@ -374,6 +402,7 @@ on subnetworks that you don't wish to masquerade.<br>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
@ -407,6 +436,7 @@ on subnetworks that you don't wish to masquerade.<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
to <a
@ -421,13 +451,14 @@ Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</table>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/13/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>

429
STABLE/documentation/shorewall_setup_guide.htm
View File

@ -62,8 +62,8 @@ more about Shorewall than is contained in the <a
<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
@ -82,7 +82,7 @@ for this program:</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 with Shorewall. Similarly,
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>
@ -96,10 +96,10 @@ run them through dos2unix before trying to use them with Shorewall. Similarly,
<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
@ -137,13 +137,13 @@ in this guide. Skeleton files are created during the <a
<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>
<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
you should not expect Shorewall to do something special "because this
is the internet zone" or "because that is the DMZ".</p>
you should not expect Shorewall to do something special "because this is
the internet zone" or "because that is the DMZ".</p>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    Edit the /etc/shorewall/zones file and make any changes necessary.</p>
@ -166,33 +166,33 @@ to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/pol
tracking function</a> that allows what is often referred to as <i>stateful
inspection</i> of packets. This stateful property allows firewall rules
to be defined in terms of <i>connections</i> rather than in terms of
packets. With Shorewall, you:</p>
packets. With Shorewall, you:</p>
<ol>
<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
<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
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
the server's zone.</li>
a rule. That rule is expressed in terms of the client's zone and 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>
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
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.def.</p>
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.def.</p>
<p>The default /etc/shorewall/policy file has the following policies:</p>
@ -236,7 +236,8 @@ the request is first checked against the rules in /etc/shorewall/common.def.</
<p>The above policy will:</p>
<ol>
<li>allow all connection requests from your local network to the internet</li>
<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>
@ -266,7 +267,8 @@ 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>
<li>All systems from the ISP outward comprise the Internet Zone. </li>
<li>All systems from the ISP outward comprise the Internet Zone.
</li>
</ul>
@ -275,8 +277,8 @@ between the compromised system and your local systems. </li>
</p>
<p align="left">The simplest way to define zones is to simply associate the
zone name (previously defined in /etc/shorewall/zones) with a network
interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
zone name (previously defined in /etc/shorewall/zones) with a network interface.
This is done in the <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file.</p>
<p align="left">The firewall illustrated above has three network interfaces.
@ -284,26 +286,27 @@ interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/sh
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>
<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>
<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>
    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>
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 DMZ
computers will be connected to the same switch (note: If you have only
a single DMZ system, you can connect the firewall directly to the computer
computers will be connected to the same switch (note: If you have only a
single DMZ 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"
@ -367,11 +370,11 @@ 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>
    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>
<p align="left">Example:</p>
@ -447,19 +450,19 @@ necessary.</p>
<h2 align="left"><a name="Addressing"></a>4.0 Addressing, Subnets and Routing</h2>
<p align="left">Normally, your ISP will assign you a set of <i> Public</i>
IP addresses. You will configure your firewall's external interface to
use one of those addresses permanently and you will then have to decide
how you are going to use the rest of your addresses. Before we tackle that
question though, some background is in order.</p>
IP addresses. You will configure your firewall's external interface to use
one of those addresses permanently and you will then have to decide how
you are going to use the rest of your addresses. Before we tackle that 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>
@ -501,13 +504,13 @@ value "w", the next byte has value "x", etc. If we take the address 192.0.2.14
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
@ -534,15 +537,15 @@ to as
<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.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
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>
<p align="left">Since <b>n</b> is a power of two, we can easily calculate
the <i>Natural Logarithm</i> (<b>log2</b>) of <b>n</b>. For the more
common subnet sizes, the size and its natural logarithm are given in the
following table:</p>
the <i>Natural Logarithm</i> (<b>log2</b>) of <b>n</b>. For the more common
subnet sizes, the size and its natural logarithm are given in the following
table:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -739,9 +742,8 @@ subnet mask has 26 leading one bits:</p>
<p align="left">The subnet mask has the property that if you logically AND
the subnet mask with an address in the subnet, the result is the subnet
address. Just as important, if you logically AND the subnet mask with
an address outside the subnet, the result is NOT the subnet address.
As we will see below, this property of subnet masks is very useful in
routing.</p>
an address outside the subnet, the result is NOT the subnet address. 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
@ -843,13 +845,13 @@ to VLSM <b>/v</b>.</p>
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
@ -878,23 +880,22 @@ 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
in the table but if we logically and that address with 255.255.255.0,
the result is 192.168.1.0 which matches this routing table entry:</p>
in the table but if we logically and that address with 255.255.255.0, the
result is 192.168.1.0 which matches this routing table entry:</p>
<div align="left">
<blockquote>
<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
@ -911,8 +912,8 @@ independent.</p>
<p align="left">When sending packets over Ethernet, IP addresses aren't used.
Rather Ethernet addressing is based on <i>Media Access Control</i> (MAC)
addresses. Each Ethernet device has it's own unique  MAC address which
is burned into a PROM on the device during manufacture. You can obtain
the MAC of an Ethernet device using the 'ip' utility:</p>
is burned into a PROM on the device during manufacture. You can obtain the
MAC of an Ethernet device using the 'ip' utility:</p>
<blockquote>
<div align="left">
@ -921,9 +922,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">
@ -958,11 +959,11 @@ with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.</p>
</blockquote>
<p align="left">The leading question marks are a result of my having specified
the 'n' option (Windows 'arp' doesn't allow that option) which causes
the 'arp' program to forego IP-&gt;DNS name translation. Had I not given
that option, the question marks would have been replaced with the FQDN
corresponding to each IP address. Notice that the last entry in the table
records the information we saw using tcpdump above.</p>
the 'n' option (Windows 'arp' doesn't allow that option) which causes the
'arp' program to forego IP-&gt;DNS name translation. Had I not given that
option, the question marks would have been replaced with the FQDN corresponding
to each IP address. Notice that the last entry in the table records the
information we saw using tcpdump above.</p>
<h3 align="left"><a name="RFC1918"></a>4.5 RFC 1918</h3>
@ -975,10 +976,10 @@ records the information we saw using tcpdump above.</p>
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>
@ -1000,8 +1001,8 @@ ranges for this purpose:</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>
@ -1035,9 +1036,9 @@ your ISP will handle that set of addresses in one of two ways:</p>
<li>
<p align="left"><b>Routed - </b>Traffic to any of your addresses will
be routed through a single <i>gateway address</i>. This will generally
only be done if your ISP has assigned you a complete subnet (/29 or
larger). In this case, you will assign the gateway address as the IP
address of your firewall/router's external interface. </p>
only be done if your ISP has assigned you a complete subnet (/29 or larger).
In this case, you will assign the gateway address as the IP address
of your firewall/router's external interface. </p>
</li>
<li>
<p align="left"><b>Non-routed - </b>Your ISP will send traffic to each
@ -1075,12 +1076,12 @@ 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
IP addresses, you are able to subnet your /28 into two /29's and set
up your network as shown in the following diagram.</p>
IP addresses, you are able to subnet your /28 into two /29's and set up
your network as shown in the following diagram.</p>
</div>
<div align="left">
@ -1090,20 +1091,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.
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>
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. 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>
</div>
<div align="left">
@ -1122,20 +1123,20 @@ routing table on DMZ 1 will look like this:</p>
<div align="left">
<p align="left">This means that DMZ 1 will send an ARP "who-has 192.0.2.65"
request and no device on the DMZ Ethernet segment has that IP address.
Oddly enough, the firewall will respond to the request with the MAC
address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames
addressed to that MAC address and the frames will be received (correctly)
by the firewall/router.</p>
Oddly enough, the firewall will respond to the request with the MAC address
of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet frames addressed
to that MAC address and the frames will be received (correctly) 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
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>
<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>
<div align="left">
@ -1143,16 +1144,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">
@ -1190,8 +1191,8 @@ 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">
@ -1202,17 +1203,17 @@ these will be discussed in the sections that follow.</p>
<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
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>
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>
</div>
<div align="left">
@ -1261,11 +1262,11 @@ that zone.</p>
<div align="left">
<p align="left">This example used the normal technique of assigning the same
public IP address for the firewall external interface and for SNAT.
If you wanted to use a different IP address, you would either have to
use your distributions network configuration tools to add that IP address
public IP address for the firewall external interface and for SNAT. If
you wanted to use a different IP address, you would either have to use
your distributions network configuration tools to add that IP address
to the external interface or you could set ADD_SNAT_ALIASES=Yes in
/etc/shorewall/shorewall.conf and Shorewall will add the address for you.</p>
/etc/shorewall/shorewall.conf and Shorewall will add the address for you.</p>
</div>
<div align="left">
@ -1274,17 +1275,18 @@ use your distributions network configuration tools to add that IP address
<div align="left">
<p align="left">When SNAT is used, it is impossible for hosts on the internet
to initiate a connection to one of the internal systems since those
systems do not have a public IP address. DNAT provides a way to allow
selected connections from the internet.</p>
to initiate a connection to one of the internal systems since those systems
do not have a public IP address. DNAT provides a way to allow selected
connections from the internet.</p>
</div>
<div align="left">
<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 href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
     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
href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
</div>
<div align="left">
@ -1327,9 +1329,9 @@ address back to 192.0.2.176 and send the response back to <b>A.</b></p>
</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">
@ -1343,8 +1345,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>
@ -1352,9 +1354,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>
@ -1381,8 +1383,8 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<div align="left"> <img border="0" src="images/BD21298_2.gif"
width="13" height="13">
    The Shorewall configuration of Proxy ARP is done using the <a
href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
    The Shorewall configuration of Proxy ARP is done using the
<a href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
<div align="left">
<blockquote>
@ -1416,11 +1418,12 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<div align="left">
<p align="left">Because the HAVE ROUTE column contains No, Shorewall will
add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.<br>
</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>
</p>
</p>
</div>
<div align="left">
@ -1431,31 +1434,31 @@ 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.
There are a couple of things that you can try:<br>
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>
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>
"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>
<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>
"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>
<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>
IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to gratuitous
@ -1464,12 +1467,12 @@ IP&gt;</b></font><br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.</li>
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>
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>
@ -1477,7 +1480,7 @@ ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:<
<div align="left">
<p align="left">Now from 130.252.100.19, ping the ISP's gateway (which we
will assume is 130.252.100.254):</p>
will assume is 130.252.100.254):</p>
</div>
<div align="left">
@ -1509,9 +1512,10 @@ will assume is 130.252.100.254):</p>
<div align="left">
<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 occurs and on incoming connections
DNAT occurs. Let's go back to our earlier example involving your daughter's
web server running on system Local 3.</p>
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>
</div>
<div align="left">
@ -1551,9 +1555,8 @@ will assume is 130.252.100.254):</p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Suppose now that you have decided to give your daughter her own
IP address (192.0.2.179) for both inbound and outbound connections.
You would do that by adding an entry in <a
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
IP address (192.0.2.179) for both inbound and outbound connections. You
would do that by adding an entry in <a href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
</div>
<div align="left">
@ -1590,9 +1593,9 @@ You would do that by adding an entry in <a
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    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>
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>
</div>
<div align="left">
@ -1636,8 +1639,7 @@ 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
rules.</p>
to allow connection requests through your firewall is to use ACCEPT rules.</p>
</div>
<div align="left">
@ -1792,8 +1794,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">
@ -1925,10 +1927,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">
@ -1937,20 +1939,18 @@ I prefer to use NAT only in cases where a system that is part of an RFC
    If you haven't already, it would be a good idea to browse through
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a> just
to see if there is anything there that might be of interest. You might
also want to look at the other configuration files that you haven't
touched yet just to get a feel for the other things that Shorewall can
do.</p>
also want to look at the other configuration files that you haven't touched
yet just to get a feel for the other things that Shorewall can 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">
@ -1990,10 +1990,10 @@ site-specific).</p>
<div align="left">
<p align="left">The setup described here requires that your network interfaces
be brought up before Shorewall can start. This opens a short window
during which you have no firewall protection. If you replace 'detect'
with the actual broadcast addresses in the entries above, you can bring
up Shorewall before you bring up your network interfaces.</p>
be brought up before Shorewall can start. This opens a short window during
which you have no firewall protection. If you replace 'detect' with
the actual broadcast addresses in the entries above, you can bring up
Shorewall before you bring up your network interfaces.</p>
</div>
<div align="left">
@ -2330,19 +2330,19 @@ 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>
<div align="left">
<p align="left">Suppose that your domain is foobar.net and you want the two
DMZ systems named www.foobar.net and mail.foobar.net and you want the
three local systems named "winken.foobar.net, blinken.foobar.net and
nod.foobar.net. You want your firewall to be known as firewall.foobar.net
externally and it's interface to the local network to be know as gateway.foobar.net
three local systems named "winken.foobar.net, blinken.foobar.net and nod.foobar.net.
You want your firewall to be known as firewall.foobar.net externally
and it's interface to the local network to be know as gateway.foobar.net
and its interface to the dmz as dmz.foobar.net. Let's have the DNS server
on 192.0.2.177 which will also be known by the name ns1.foobar.net.</p>
</div>
@ -2496,11 +2496,12 @@ systems that you want to be able to access the firewall when it is stopped.
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/13/2003 - <a
<p align="left"><font size="2">Last updated 2/13/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></p>
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>

122
STABLE/documentation/sourceforge_index.htm
View File

@ -46,10 +46,10 @@
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font><a href="http://www.sf.net">
</a></h1>
</a></i></font><font
color="#ffffff">Shorewall 1.3 - <font
size="4">"<i>iptables made easy"</i></font></font><a
href="http://www.sf.net"> </a></h1>
@ -62,6 +62,7 @@
<div align="center"><a href="/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a></div>
</td>
</tr>
@ -111,9 +112,10 @@
<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>
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>
@ -127,27 +129,27 @@
<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
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
Foundation.<br>
<br>
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
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
along with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
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>
@ -176,14 +178,14 @@ Software Foundation, Inc., 675 Mass Ave, Cambridge
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric
Wolzak have a LEAF (router/firewall/gateway on
a floppy, CD or compact flash) distribution called
</a>Jacques Nilo 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.10
and Kernel-2.4.18. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.0 Final!!! <br>
<b>Congratulations to Jacques
and Eric on the recent release of Bering 1.0 Final!!! <br>
</b>
@ -204,7 +206,7 @@ a floppy, CD or compact flash) distribution called
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
@ -212,19 +214,19 @@ a floppy, CD or compact flash) distribution called
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options in
/etc/shorewall/interfaces will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead of
just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
@ -232,21 +234,28 @@ of just the interface name:<br>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<li>Support for VLAN devices with names of the form $DEV.$VID
(e.g., eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
<li>In /etc/shorewall/tcrules, the MARK 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>
</li>
<li>When an interface name is entered in the SUBNET column of
the /etc/shorewall/masq file, Shorewall previously masqueraded traffic
from only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
Beginning with Shorewall 1.3.14, if you enter an interface name in
the SUBNET column, shorewall will use the firewall's routing table to
construct the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
@ -258,12 +267,12 @@ traffic from:<br>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
connected to an interface that is specified in the SUBNET column of an
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need changing.
In most cases, you will simply be able to remove redundant entries. In
some cases though, you might want to change from using the interface name
to listing specific subnetworks if the change described above will cause
masquerading to occur on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
@ -287,6 +296,7 @@ on subnetworks that you don't wish to masquerade.<br>
<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>
</li>
</ol>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
@ -294,7 +304,7 @@ on subnetworks that you don't wish to masquerade.<br>
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard.
See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</b>
<p><b></b></p>
@ -305,6 +315,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<ul>
@ -313,6 +324,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</ul>
@ -321,6 +333,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<p><a href="News.htm">More News</a></p>
@ -340,6 +353,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h1 align="center"><a href="http://www.sf.net"><img align="left"
alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
@ -349,12 +363,14 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h4> </h4>
<h2>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </h2>
@ -425,11 +441,11 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<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>
@ -447,7 +463,7 @@ Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/14/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>

49
STABLE/documentation/starting_and_stopping_shorewall.htm
View File

@ -44,10 +44,10 @@
I recommend that you start the firewall automatically at boot. Once
you have installed "firewall" in your init.d directory, simply type
"chkconfig --add firewall". This will start the firewall in run
levels 2-5 and stop it in run levels 1 and 6. If you want to configure
your firewall differently from this default, you can use the "--level"
option in chkconfig (see "man chkconfig") or using your favorite
graphical run-level editor.</p>
levels 2-5 and stop it in run levels 1 and 6. If you want to configure
your firewall differently from this default, you can use the "--level"
option in chkconfig (see "man chkconfig") or using your favorite
graphical run-level editor.</p>
@ -62,11 +62,11 @@ graphical run-level editor.</p>
<ol>
<li>Shorewall startup is disabled by default. Once you have configured
your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.
Note: Users of the .deb package must edit /etc/default/shorewall and set
'startup=1'.<br>
Note: Users of the .deb package must edit /etc/default/shorewall and
set 'startup=1'.<br>
</li>
<li>If you use dialup, you may want to start the firewall in
your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
restart" in that script.</li>
</ol>
@ -89,7 +89,7 @@ your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
<li>shorewall reset - reset the packet and byte counters
in the firewall</li>
<li>shorewall clear - remove all rules and chains
installed by Shoreline Firewall</li>
installed by Shoreline Firewall</li>
<li>shorewall refresh - refresh the rules involving the broadcast
addresses of firewall interfaces and the black and white lists.</li>
@ -102,8 +102,8 @@ shell trace of the command is produced as in:<br>
<p>The above command would trace the 'start' command and place the trace information
in the file /tmp/trace<br>
<p>The above command would trace the 'start' command and place the trace
information in the file /tmp/trace<br>
</p>
<p>The <a href="#StateDiagram">Shorewall State Diagram</a> is shown at the
@ -123,8 +123,8 @@ in the file /tmp/trace<br>
<li>shorewall show tos - produce a verbose report about the mangle
table (iptables -t mangle -L -n -v)</li>
<li>shorewall show log - display the last 20 packet log entries.</li>
<li>shorewall show connections - displays the IP connections currently
being tracked by the firewall.</li>
<li>shorewall show connections - displays the IP connections
currently being tracked by the firewall.</li>
<li>shorewall
show
tc - displays information
@ -139,7 +139,7 @@ in the file /tmp/trace<br>
of the zones, interfaces, hosts, rules and policy files. <font
size="4" color="#ff6666"><b>The "check" command does not parse and validate
the generated iptables commands so even though the "check" command
completes successfully, the configuration may fail to start. See the
completes successfully, the configuration may fail to start. See the
recommended way to make configuration changes described below. </b></font>
</li>
<li>shorewall try<i> configuration-directory</i> [<i> timeout</i>
@ -223,8 +223,8 @@ zone.</li>
<p> If the configuration starts but doesn't work, just "shorewall restart"
to restore the old configuration. If the new configuration fails to start,
the "try" command will automatically start the old one for you.</p>
to restore the old configuration. If the new configuration fails to
start, the "try" command will automatically start the old one for you.</p>
@ -248,19 +248,19 @@ zone.</li>
<p><a name="StateDiagram"></a>The Shorewall State Diargram is depicted below.<br>
</p>
<div align="center"><img
src="file:///J:/Shorewall-docs/images/State_Diagram.png"
</p>
<div align="center"><img src="images/State_Diagram.png"
alt="(State Diagram)" width="747" height="714" align="middle">
<br>
</div>
<br>
</div>
<p>  <br>
</p>
You will note that the commands that result in state transitions use
the word "firewall" rather than "shorewall". That is because the actual
transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall
on Debian); /sbin/shorewall runs 'firewall" according to the following table:<br>
the word "firewall" rather than "shorewall". That is because the actual transitions
are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall on
Debian); /sbin/shorewall runs 'firewall" according to the following table:<br>
<br>
<table cellpadding="2" cellspacing="2" border="1">
@ -314,7 +314,7 @@ on Debian); /sbin/shorewall runs 'firewall" according to the following table:<b
</table>
<br>
<p><font size="2"> Updated 1/29/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 2/10/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -331,5 +331,6 @@ on Debian); /sbin/shorewall runs 'firewall" according to the following table:<b
<br>
<br>
<br>
<br>
</body>
</html>

95
STABLE/documentation/support.htm
View File

@ -51,14 +51,15 @@
<h2 align="center"><big><font color="#ff0000"><b>-Tom Eastep</b></font></big></h2>
<h1>Before Reporting a Problem</h1>
<i>"Well at least you tried to read the documentation, which is a lot more
<i>"Well at least you tried to read the documentation, which is a lot more
than some people on this list appear to do.</i>"<br>
<br>
<br>
<div align="center">- Wietse Venema - On the Postfix mailing list<br>
</div>
<br>
</div>
<br>
There are a number of sources for
problem solution information. Please try these before you post.
problem solution information. Please try these before you post.
<h3> </h3>
@ -97,8 +98,8 @@ problem solution information. Please try these before you post.
<ul>
<li> The Mailing List
Archives search facility can locate posts about similar problems:
</li>
Archives search facility can locate posts about similar
problems: </li>
</ul>
@ -147,39 +148,40 @@ Archives search facility can locate posts about similar problem
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed
at the range and variety of smells we could come up with. Even more
amazing is that all of the explanations for the smells would be completely
plausible."<br>
smell and even what's causing it. You would be absolutely amazed at
the range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely plausible."<br>
</i><br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
</div>
<br>
<h3> </h3>
<ul>
<li>Please remember we only know what is posted in your message.
Do not leave out any information that appears to be correct, or was mentioned
in a previous post. There have been countless posts by people who were
sure that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is lacking.<br>
Do not leave out any information that appears to be correct, or was
mentioned in a previous post. There have been countless posts by people
who were sure that some part of their configuration was correct when
it actually contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're asking for <strong>free</strong>
technical support. Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous practices
in writing and formatting your e-mail. Provide details that we need if
you expect good answers. <em>Exact quoting </em> of error messages, log
entries, command output, and other output is better than a paraphrase or
summary.<br>
technical support. Any help we offer is an act of generosity, not an
obligation. Try to make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. <em>Exact quoting </em> of error messages,
log entries, command output, and other output is better than a paraphrase
or summary.<br>
<br>
</li>
<li> Please don't describe your
environment and then ask us to send you custom configuration
files. We're here to answer your questions but we can't
do your job for you.<br>
<li> Please don't describe
your environment and then ask us to send you custom
configuration files. We're here to answer your questions but
we can't do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
@ -235,12 +237,12 @@ this information:</li>
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart Guides, please
indicate which one. <br>
<li>If you installed Shorewall using one of the QuickStart Guides,
please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the Mandrake
installation of Shorewall, please say so.</b><br>
installation of Shorewall, please say so.</b><br>
<br>
</li>
@ -250,8 +252,8 @@ installation of Shorewall, please say so.</b><br>
<ul>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, if you are having connection
problems of any kind, post the exact output of<br>
color="#009900">iptables -L</font></b>". Instead, <b>if you are having
connection problems of any kind</b>, post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
@ -283,18 +285,18 @@ your post<br>
<h3> </h3>
<ul>
<li> Do you see any "Shorewall"
messages ("<b><font color="#009900">/sbin/shorewall show log</font></b>")
when you exercise the function that is giving you problems? If
so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<li> Do you see any
"Shorewall" messages ("<b><font color="#009900">/sbin/shorewall show
log</font></b>") when you exercise the function that is giving
you problems? If so, include the message(s) in your post along with a
copy of your /etc/shorewall/interfaces file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies). </li>
please include /etc/shorewall/policy as well (rules are meaningless
unless one also knows the policies). </li>
</ul>
@ -336,16 +338,16 @@ when you try to "<font color="#009900"><b>shorewall start</b></font>",
A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse" because it has been my policy to allow HTML in
list posts!!<br>
list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the
list subscribers whose MTAs are bouncing all shorewall.net mail. As
one list subscriber wrote to me privately "These e-mail admin's need
to get a <i>(expletive deleted)</i> life instead of trying to rid the
planet of HTML based e-mail". Nevertheless, to allow subscribers to receive
list posts as must as possible, I have now configured the list server
at shorewall.net to strip all HTML from outgoing posts.<br>
spam and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one
list subscriber wrote to me privately "These e-mail admin's need to get
a <i>(expletive deleted)</i> life instead of trying to rid the planet
of HTML based e-mail". Nevertheless, to allow subscribers to receive list
posts as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts.<br>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
@ -373,7 +375,7 @@ at shorewall.net to strip all HTML from outgoing posts.<br>
.</p>
<p align="left"><font size="2">Last Updated 2/4/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 2/9/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
@ -383,5 +385,6 @@ at shorewall.net to strip all HTML from outgoing posts.<br>
<br>
<br>
<br>
<br>
</body>
</html>

139
STABLE/documentation/traffic_shaping.htm
View File

@ -32,79 +32,83 @@
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>
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 traffic shaping support consists of the following:</p>
<ul>
<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>
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>
</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>
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
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>
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>
<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>
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
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)
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
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 qdisc
and filter definitions is pretty general.</li>
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>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic shaping
rules.</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic
shaping rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark packets
using entries in /etc/shorewall/tcrules.</li>
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark
packets using entries in /etc/shorewall/tcrules.</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
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>
<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>
can mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
<h3 align="left">Kernel Configuration</h3>
@ -125,16 +129,21 @@ can mark packets using entries in /etc/shorewall/tcrules.</li>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
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>
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>
</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.<br>
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>
@ -147,19 +156,19 @@ of a match. This is an integer in the range 1-255.<br>
    eth0<br>
    192.168.2.4,192.168.1.0/24<br>
</li>
<li>DEST -- Destination of the packet. Comma-separated list of
IP addresses and/or subnets.<br>
<li>DEST -- Destination of the packet. Comma-separated list
of IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/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>
<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>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client. If
omitted, any source port is acceptable. Specified as a comma-separate
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client.
If omitted, any source port is acceptable. Specified as a comma-separate
list of port names, port numbers or port ranges.</li>
</ul>
@ -276,9 +285,9 @@ 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>
@ -303,9 +312,9 @@ rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<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
<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>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.<br>
@ -313,12 +322,10 @@ can use all available bandwidth if there is no traffic from the local systems
</ol>
<p><font size="2">Last Updated 12/31/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last Updated 2/13/2003 - <a href="support.htm">Tom Eastep</a></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>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
</body>
</html>

278
STABLE/documentation/two-interface.htm
View File

@ -24,6 +24,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Basic Two-Interface Firewall</font></h1>
</td>
</tr>
@ -33,18 +34,18 @@
<p align="left">Setting up a Linux system as a firewall for a small network
is a fairly straight-forward task if you understand the basics and
follow the documentation.</p>
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
in its most common configuration:</p>
<ul>
<li>Linux system used as a firewall/router for a small local
network.</li>
<li>Linux system used as a firewall/router for a small
local network.</li>
<li>Single public IP address.</li>
<li>Internet connection through cable modem, DSL, ISDN, Frame
Relay, dial-up ...</li>
<li>Internet connection through cable modem, DSL, ISDN,
Frame Relay, dial-up ...</li>
</ul>
@ -57,26 +58,38 @@ follow the documentation.</p>
<p><b>If you are running Shorewall under Mandrake 9.0 or later, you can easily
configure the above setup using the Mandrake "Internet Connection Sharing"
applet. From the Mandrake Control Center, select "Network &amp; Internet"
then "Connection Sharing". You should not need to refer to this guide.</b><br>
then "Connection Sharing".<br>
</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>
</p>
<p><br>
</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 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"
with <img src="images/leaflogo.gif" alt="(LEAF Logo)" width="49"
height="36">
</p>
</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows system,
@ -103,8 +116,8 @@ 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/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>
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>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
@ -144,18 +157,18 @@ a few of these as described in this guide. After you have <a
<ul>
<li>You express your default policy for connections from
one zone to another zone in the<a
one zone 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>
<li>You define exceptions to those default policies in
the <a href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
</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 two-interface sample has
@ -231,18 +244,18 @@ the following policies:</p>
<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
to the internet (if you uncomment the additional policy)</li>
<li>optionally accept all connection requests from the
firewall to the internet (if you uncomment the additional policy)</li>
<li>reject all other connection requests.</li>
</ol>
<p><img border="0" src="images/BD21298_.gif" width="13" height="13">
    At this point, edit your /etc/shorewall/policy and make
any changes that you wish.</p>
any changes that you wish.</p>
<h2 align="left">Network Interfaces</h2>
@ -257,8 +270,8 @@ connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
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 via ISDN, your external interface will be <b>ippp0.</b></p>
via a regular modem, your External Interface will also be <b>ppp0</b>.
If you connect via ISDN, your external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
@ -275,18 +288,18 @@ If you connect via ISDN, your external interface will be <b>ippp0.</b></p>
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect the internal and external interface
to the same hub or switch (even for testing). It won't work the way
that you think that it will and you will end up confused and believing
that Shorewall doesn't work at all.</p>
to the same hub or switch (even for testing). It won't work the way
that you think that it will and you will end up confused and believing
that Shorewall doesn't work at all.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" align="left"
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>
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>
<ul>
<li>
@ -307,14 +320,14 @@ modify the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/inter
<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
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>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
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>
@ -326,22 +339,23 @@ Internet. You will have to assign your own addresses in your internal network
<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
ranges, you should remove the 'norfc1918' option from the external
interface's entry in /etc/shorewall/interfaces.</p>
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>
<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 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>
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>
</div>
<div align="left">
@ -378,8 +392,8 @@ interface's entry in /etc/shorewall/interfaces.</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>
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">
@ -392,8 +406,8 @@ interface's entry in /etc/shorewall/interfaces.</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Your local computers (computer 1 and computer 2 in the
above diagram) should be configured with their<i> default gateway</i>
    Your local computers (computer 1 and computer 2 in
the above diagram) should be configured with their<i> default gateway</i>
to be the IP address of the firewall's internal interface.<i>     
</i> </p>
</div>
@ -417,9 +431,9 @@ interface's entry in /etc/shorewall/interfaces.</p>
<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>
@ -428,16 +442,17 @@ network.</b><br>
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>
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
@ -467,17 +482,17 @@ When the firewall receives a return packet, it rewrites the destination address
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
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>
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>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    If your external IP is static, you can enter it in the
third column in the /etc/shorewall/masq entry if you like although
your firewall will work fine if you leave that column empty. Entering
your static IP in column 3 makes processing outgoing packets a little
third column in the /etc/shorewall/masq entry if you like although
your firewall will work fine if you leave that column empty. Entering
your static IP in column 3 makes processing outgoing packets a little
more efficient.<br>
<br>
<img border="0" src="images/BD21298_.gif" width="13" height="13"
@ -497,13 +512,13 @@ your static IP in column 3 makes processing outgoing packets a little
<h2 align="left">Port Forwarding (DNAT)</h2>
<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>
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>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
Destination Network Address Translation</i> (DNAT). You configure
@ -575,13 +590,13 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
<p>A couple of important points to keep in mind:</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>
<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>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000.</li>
</ul>
@ -615,8 +630,8 @@ following rule and try connecting to port 5000.</li>
</blockquote>
<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>
    At this point, modify /etc/shorewall/rules to add any
DNAT rules that you require.</p>
<h2 align="left">Domain Name Server (DNS)</h2>
@ -625,19 +640,20 @@ following rule and try connecting to port 5000.</li>
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>
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>
<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>
@ -645,14 +661,14 @@ the name servers are given in "nameserver" records in that file. </p>
height="13">
    You can configure a<i> Caching Name Server </i>on your
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>
(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>
</li>
</ul>
@ -915,8 +931,9 @@ uses, look <a href="ports.htm">here</a>.</p>
<div align="left">
<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.</p>
    Bering users will want to add the following two rules to be compatible
with Jacques's Shorewall configuration.</p>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -960,8 +977,9 @@ with Jacques's Shorewall configuration.</p>
</table>
</blockquote>
</div>
<p align="left"><br>
<img border="0" src="images/BD21298_.gif" width="13" height="13">
<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>
</div>
@ -973,12 +991,12 @@ with Jacques's Shorewall configuration.</p>
<div align="left">
<p align="left"> <img border="0" src="images/BD21298_2.gif"
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>
    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>
</p>
<p align="left"><font color="#ff0000"><b>IMPORTANT</b>: </font><font
@ -992,50 +1010,38 @@ with Jacques's Shorewall configuration.</p>
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">
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
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
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
accordingly.</p>
</div>
<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
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/21/2003 - <a
<p align="left"><font size="2">Last updated 2/13/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></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Thomas M. Eastep</font></a><br>
</p>
<br>
</body>
</html>