extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-15 02:41:01 +01:00
Code Issues Packages Projects Releases Wiki Activity

Shorewall 1.4.6 Beta2

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@649 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-07-07 14:18:52 +00:00
parent cf62edd5ca
commit 184390708e
17 changed files with 11188 additions and 10565 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6339
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

2381
Shorewall-docs/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

174
Shorewall-docs/NAT.htm
View File

@ -1,117 +1,117 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall NAT</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<blockquote>
<blockquote>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Static NAT</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p><font color="#ff0000"><b>IMPORTANT: If all you want to do is forward
ports to servers behind your firewall, you do NOT want to use static
NAT. Port forwarding can be accomplished with simple entries in the
<a href="Documentation.htm#Rules">rules file</a>.</b></font></p>
<p>Static NAT is a way to make systems behind a firewall and configured
with private IP addresses (those reserved for private use in RFC1918)
appear to have public IP addresses. Before you try to use this technique,
I strongly recommend that you read the <a
<p><font color="#ff0000"><b>IMPORTANT: If all you want to do is forward
ports to servers behind your firewall, you do NOT want to use static
NAT. Port forwarding can be accomplished with simple entries in the
<a href="Documentation.htm#Rules">rules file</a>.</b></font></p>
<p>Static NAT is a way to make systems behind a firewall and configured
with private IP addresses (those reserved for private use in RFC1918)
appear to have public IP addresses. Before you try to use this technique,
I strongly recommend that you read the <a
href="shorewall_setup_guide.htm">Shorewall Setup Guide.</a></p>
<p>The following figure represents a static NAT environment.</p>
<p align="center"><strong> <img src="images/staticnat.png"
width="435" height="397">
</strong></p>
</strong></p>
<blockquote> </blockquote>
<p align="left">Static NAT can be used to make the systems with the 10.1.1.*
addresses appear to be on the upper (130.252.100.*) subnet. If we assume
that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT
file would make the lower left-hand system appear to have IP address
130.252.100.18 and the right-hand one to have IP address 130.252.100.19.</p>
<p align="left">Static NAT can be used to make the systems with the 10.1.1.*
addresses appear to be on the upper (130.252.100.*) subnet. If we assume
that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT
file would make the lower left-hand system appear to have IP address 130.252.100.18
and the right-hand one to have IP address 130.252.100.19.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>EXTERNAL</b></td>
<td><b>INTERFACE</b></td>
<td><b>INTERNAL</b></td>
<td><b>ALL INTERFACES</b></td>
<td><b>LOCAL</b></td>
</tr>
<tbody>
<tr>
<td>130.252.100.18</td>
<td>eth0</td>
<td>10.1.1.2</td>
<td>yes</td>
<td>yes</td>
</tr>
<tr>
<td>130.252.100.19</td>
<td>eth0</td>
<td>10.1.1.3</td>
<td>yes</td>
<td>yes</td>
</tr>
</tbody>
<td><b>EXTERNAL</b></td>
<td><b>INTERFACE</b></td>
<td><b>INTERNAL</b></td>
<td><b>ALL INTERFACES</b></td>
<td><b>LOCAL</b></td>
</tr>
<tr>
<td>130.252.100.18</td>
<td>eth0</td>
<td>10.1.1.2</td>
<td>yes</td>
<td>yes</td>
</tr>
<tr>
<td>130.252.100.19</td>
<td>eth0</td>
<td>10.1.1.3</td>
<td>yes</td>
<td>yes</td>
</tr>
</tbody>
</table>
<p>Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above
example) is (are) not included in any specification in /etc/shorewall/masq
or /etc/shorewall/proxyarp.</p>
<p><a name="AllInterFaces"></a>Note 1: The "ALL INTERFACES" column is used
to specify whether access to the external IP from all firewall interfaces
should undergo NAT (Yes or yes) or if only access from the interface in
the INTERFACE column should undergo NAT. If you leave this column empty,
<p>Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above
example) is (are) not included in any specification in /etc/shorewall/masq
or /etc/shorewall/proxyarp.</p>
<p><a name="AllInterFaces"></a>Note 1: The "ALL INTERFACES" column is used
to specify whether access to the external IP from all firewall interfaces
should undergo NAT (Yes or yes) or if only access from the interface in
the INTERFACE column should undergo NAT. If you leave this column empty,
"Yes" is assumed. The ALL INTERFACES column was added in version 1.1.6.</p>
<p>Note 2: Shorewall will automatically add the external address to the
specified interface unless you specify <a
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>="no" (or "No") in
/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if
you set it to "Yes" or "yes" then you must NOT configure your own alias(es).
<b>RESTRICTION: </b>Shorewall versions earlier than 1.4.6 can only add
external addresses to an interface that is configured with a single subnetwork
-- if your external interface has addresses in more than one subnetwork,
Shorewall 1.4.5 and earlier can only add addresses to the first one.</p>
<p><a name="LocalPackets"></a>Note 3: The contents of the "LOCAL" column
determine whether packets originating on the firewall itself and destined
for the EXTERNAL address are redirected to the internal ADDRESS. If
this column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also
contains "Yes" or "yes") then such packets are redirected; otherwise,
such packets are not redirected. The LOCAL column was added in version
1.1.8.</p>
</blockquote>
<p>Note 2: Shorewall will automatically add the external address to the
specified interface unless you specify <a
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>="no" (or "No") in
/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if
you set it to "Yes" or "yes" then you must NOT configure your own alias(es).
<b>RESTRICTION: </b>Shorewall can only add external addresses to an interface
that is configured with a single subnetwork -- if your external interface
has addresses in more than one subnetwork, Shorewall can only add addresses
to the first one.</p>
<p><a name="LocalPackets"></a>Note 3: The contents of the "LOCAL" column
determine whether packets originating on the firewall itself and destined
for the EXTERNAL address are redirected to the internal ADDRESS. If this
column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also contains
"Yes" or "yes") then such packets are redirected; otherwise, such packets
are not redirected. The LOCAL column was added in version 1.1.8.</p>
</blockquote>
<blockquote> </blockquote>
<p><font size="2">Last updated 4/11/2003 - </font><font size="2"> <a
<p><font size="2">Last updated 7/6/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<br>
</body>
</html>

4347
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs/images/Netfilter.png
View File

Binary file not shown.

593
Shorewall-docs/seattlefirewall_index.htm
View File

@ -3,110 +3,111 @@
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="33%" height="90" valign="middle"
<td width="33%" height="90" valign="middle"
align="left"><a href="http://www.cityofshoreline.com"><img
src="images/washington.jpg" alt="" width="97" height="80" hspace="4"
border="0">
</a></td>
<td valign="middle" width="34%" align="center">
</a></td>
<td valign="middle" width="34%" align="center">
<h1><font color="#ffffff">Shorewall 1.4</font><i><font
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i></h1>
</td>
<td valign="middle">
</td>
<td valign="middle">
<h1 align="center"><a href="http://www.shorewall.net"
target="_top"><img border="0" src="images/shorewall.jpg" width="119"
height="38" hspace="4" alt="(Shorewall Logo)" align="right" vspace="4">
</a></h1>
<br>
</td>
</tr>
</a></h1>
<br>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tbody>
<tr>
<tr>
<td width="90%">
<td width="90%">
<h2 align="left">What is it?</h2>
<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>
<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>
<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
Foundation.<br>
<p>This program is free software; you can redistribute it and/or modify
<br>
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>
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>
<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>
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>
<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>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -116,304 +117,384 @@ General Public License</a> as published by the Free Software
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>Looking for Information?</h2>
The <a href="shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a> is a good place to start as is the Quick Search to your right.
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not apply
directly to your setup. If you want to use the documentation that you
find here, you will want to consider uninstalling what you have and installing
a setup that matches the documentation on this site. See the <a
href="two-interface.htm">Two-interface QuickStart Guide</a> for details.<br>
<h2> Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
If so, the documentation<b> </b>on this site will not
apply directly to your setup. If you want to use the documentation
that you find here, you will want to consider uninstalling what you have
and installing a setup that matches the documentation on this site.
See the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.<br>
<h2>News</h2>
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
<blockquote><a href="http://shorewall.net/pub/shorewall/testing">http://shorewall.net/pub/shorewall/testing</a><br>
<a href="ftp://shorewall.net/pub/shorewall/testing"
target="_top">ftp://shorewall.net/pub/shorewall/testing</a><br>
</blockquote>
<p><b>Problems Corrected:</b><br>
</p>
<p><b></b></p>
<ol>
<li>A problem seen on RH7.3 systems where Shorewall encountered
start errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Previously, where a list of IP addresses appears in the DEST
column of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
in the nat table (one for each element in the list). Shorewall now correctly
creates a single DNAT rule with multiple "--to-destination" clauses.<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b><b> <img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
<p><b>Problems Corrected:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option
may be specified in /etc/shorewall/interfaces and overrides the setting
NEWNOTSYN=No for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
<li>A problem seen on RH7.3 systems where Shorewall encountered start
errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Where a list of IP addresses appears in the DEST column of a
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat
table (one for each element in the list). Shorewall now correctly creates
a single DNAT rule with multiple "--to-destination" clauses.<br>
<br>
</li>
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
were mis-handled when they appeared in the DEST column of a rule.<br>
</li>
</ol>
<p><b>Migration Issues:</b><br>
</p>
<ol>
<li>In earlier versions, an undocumented feature allowed entries
in the host file as follows:<br>
<br>
    z    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
    z   eth1:192.168.1.0/24,192.168.2.0/24<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
detected by Shorewall (see below).<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option may
be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address
ranges.<br>
<br>
</li>
<li>Shorewall can now add IP addresses to subnets other than the
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin)
over a set of servers. Up to 256 servers may be specified in a range of addresses
given as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
Note that this capability has previously been available using a combination
of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable
for load-balancing over a large number of servers (&gt; 16) since specifying
a range in the DNAT rule causes one filter table ACCEPT rule to be generated
for each IP address in the range.<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
options have been removed and have been replaced by code that detects whether
these capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
Verifying Configuration...<br>
<br>
</li>
<li>Support for the Connection Tracking Match Extension has been
added. This extension is available in recent kernel/iptables releases and
allows for rules which match against elements in netfilter's connection
<br>
</li>
<li>Shorewall can now add IP addresses to subnets other than the
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin) over
a set of servers. Servers may be specified in a range of addresses given
as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
have been removed and have been replaced by code that detects whether these
capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
Verifying Configuration...<br>
<br>
</li>
<li>Support for the Connection Tracking Match Extension has been
added. This extension is available in recent kernel/iptables releases and
allows for rules which match against elements in netfilter's connection
tracking table. Shorewall automatically detects the availability of this
extension and reports its availability in the output of the start, restart
and check commands.<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
   Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is
changed in the following ways:</li>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is changed
in the following ways:</li>
<ul>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
in the filter table (rfc1918 chain).</li>
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
one in the nat table and one in the filter table. If the Connection Tracking
Match Extension is available, the rule in the filter table is extended to
check that the original destination address was the same as specified (or
defaulted to) in the DNAT rule.<br>
<br>
</li>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
in the filter table (rfc1918 chain).</li>
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
one in the nat table and one in the filter table. If the Connection Tracking
Match Extension is available, the rule in the filter table is extended to
check that the original destination address was the same as specified (or
defaulted to) in the DNAT rule.<br>
<br>
</li>
</ul>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.</li>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.<br>
<br>
</li>
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
<br>
      ipcalc [ &lt;address&gt; &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt;
]<br>
<br>
Examples:<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0/24<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
Warning:<br>
<br>
If your shell only supports 32-bit signed arithmatic (ash or dash), then
the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1
and for /1 networks. Bash should produce correct information for all valid
IP addresses.<br>
<br>
</li>
<li>An 'iprange' command has been added to /sbin/shorewall. <br>
<br>
      iprange &lt;address&gt;-&lt;address&gt;<br>
<br>
This command decomposes a range of IP addressses into a list of network
and host addresses. The command can be useful if you need to construct an
efficient set of rules that accept connections from a range of network addresses.<br>
<br>
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
then the range may not span 128.0.0.0.<br>
<br>
Example:<br>
<br>
      [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9<br>
      192.168.1.4/30<br>
      192.168.1.8/29<br>
      192.168.1.16/28<br>
      192.168.1.32/27<br>
      192.168.1.64/26<br>
      192.168.1.128/25<br>
      192.168.2.0/23<br>
      192.168.4.0/22<br>
      192.168.8.0/22<br>
      192.168.12.0/29<br>
      192.168.12.8/31<br>
      [root@gateway root]#<br>
<br>
</li>
<li>A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.<br>
<br>
Example:<br>
<br>
    foo    eth1:192.168.1.0/24,192.168.2.0/24<br>
</li>
</ol>
<p><b>6/17/2003 - Shorewall-1.4.5</b><b> </b></p>
<p>Problems Corrected:<br>
</p>
</p>
<ol>
<li>The command "shorewall debug try &lt;directory&gt;" now correctly
traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones file;
previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
<li>The command "shorewall debug try &lt;directory&gt;" now
correctly traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones
file; previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
</ol>
<p>New Features:<br>
</p>
</p>
<ol>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then the
rule will take effect only if the original destination address in the connection
request does not match any of the addresses listed.</li>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then
the rule will take effect only if the original destination address in
the connection request does not match any of the addresses listed.</li>
</ol>
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
</b></p>
<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
have been encountered with this set of software. The Shorewall version
is 1.4.4b plus the accumulated changes for 1.4.5.<br>
</p>
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
</b></p>
<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No
problems have been encountered with this set of software. The Shorewall
version is 1.4.4b plus the accumulated changes for 1.4.5.<br>
</p>
<p><b>6/8/2003 - Updated Samples</b><b> </b></p>
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>
<p><b></b></p>
<ol>
</ol>
<p><a href="News.htm">More News</a></p>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</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.4.2 and Kernel-2.4.20. You
can find their work at: <a
</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.4.2 and Kernel-2.4.20. You
can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
</a></p>
<b>Congratulations to Jacques and Eric on the recent
release of Bering 1.2!!! </b><br>
<b>Congratulations to Jacques and Eric on the recent
release of Bering 1.2!!! </b><br>
<h2><a name="Donations"></a>Donations</h2>
</td>
</td>
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<td width="88" bgcolor="#4b017c"
valign="top" align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font
action="http://lists.shorewall.net/cgi-bin/htsearch">
<strong><br>
<font
color="#ffffff"><b>Note: </b></font></strong><font
color="#ffffff">Search is unavailable Daily 0200-0330 GMT.</font><br>
<strong></strong>
<strong></strong>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font
<font
face="Arial" size="-1"> <input type="text" name="words"
size="15"></font><font size="-1"> </font> <font face="Arial"
size="-1"> <input type="hidden" name="format" value="long"> <input
type="hidden" name="method" value="and"> <input type="hidden"
name="config" value="htdig"> <input type="submit" value="Search"></font>
</p>
<font
name="config" value="htdig"> <input type="submit" value="Search"></font>
</p>
<font
face="Arial"> <input type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font> </form>
<p><font color="#ffffff"><b><a
href="http://lists.shorewall.net/htdig/search.html"><font
color="#ffffff">Extended Search</font></a></b></font></p>
<br>
</td>
<br>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</center>
</div>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="100%" style="margin-top: 1px;"
valign="middle">
<td width="100%" style="margin-top: 1px;"
valign="middle">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10" alt="(Starlight Logo)">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff"><br>
<font size="+2"> 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></font></p>
<font size="+2"> 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></font></p>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
<p><font size="2">Updated 7/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
<p><font size="2">Updated 7/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</body>
</html>

603
Shorewall-docs/shorewall_firewall_structure.htm
View File

@ -1,333 +1,326 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Firewall Structure</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Firewall Structure</font></h1>
</td>
</tr>
</td>
</tr>
</tbody>
</table>
<p> Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw" which
refers to the firewall system itself . The /etc/shorewall/zones file is
used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li> net -- the (untrusted) internet.</li>
<li> dmz - systems that must be accessible from the internet
and from the local network.  These systems cannot be trusted completely since
their servers may have been compromised through a security exploit.</li>
<li> loc - systems in your local network(s). These systems
must be protected from the internet and from the DMZ and in some cases,
from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall zone</a>.
For ease of description in this documentation, it is assumed that the firewall
zone is named "fw".</p>
<p>It can't be stressed enough that with the exception of the firewall zone,
Shorewall itself attaches no meaning to zone names. Zone names are simply
labels used to refer to a collection of network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the
purpose of this document, we will consider Netfilter to have three tables:</p>
<ol>
<li>Filter table -- this is the main table for packet filtering and can
be displayed with the command "shorewall show".</li>
<li>Nat table -- used for all forms of Network Address Translation (NAT);
SNAT, DNAT and MASQUERADE.</li>
<li>Mangle table -- used to modify fields in the packet header.<br>
</li>
</ol>
<p>Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
as shown in this table.<br>
</p>
<div align="center">
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">CHAIN<br>
</td>
<td valign="top">Filter<br>
</td>
<td valign="top">Nat<br>
</td>
<td valign="top">Mangle<br>
</td>
</tr>
<tr>
<td valign="top">PREROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">INPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">OUTPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">FORWARD<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">POSTROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
</tbody>
</table>
<p> Shorewall views the network in which it is running as a set of
<i> zones. </i>Shorewall itself defines exactly one zone called "fw" which
refers to the firewall system itself . The /etc/shorewall/zones file is
used to define additional zones and the example file provided with Shorewall
defines the zones:</p>
<ol>
<li> net -- the (untrusted) internet.</li>
<li> dmz - systems that must be accessible from the internet
and from the local network.  These systems cannot be trusted completely
since their servers may have been compromised through a security exploit.</li>
<li> loc - systems in your local network(s). These systems
must be protected from the internet and from the DMZ and in some cases,
from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall
zone</a>. For ease of description in this documentation, it is assumed
that the firewall zone is named "fw".</p>
<p>It can't be stressed enough that with the exception of the firewall zone,
Shorewall itself attaches no meaning to zone names. Zone names are simply
labels used to refer to a collection of network hosts.</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the purpose
of this document, we will consider Netfilter to have three tables:</p>
<ol>
<li>Filter table -- this is the main table for packet filtering and can
be displayed with the command "shorewall show".</li>
<li>Nat table -- used for all forms of Network Address Translation (NAT);
SNAT, DNAT and MASQUERADE.</li>
<li>Mangle table -- used to modify fields in the packet header.<br>
</li>
</ol>
<p>Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
as shown in this table.<br>
</p>
<div align="center">
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">CHAIN<br>
</td>
<td valign="top">Filter<br>
</td>
<td valign="top">Nat<br>
</td>
<td valign="top">Mangle<br>
</td>
</tr>
<tr>
<td valign="top">PREROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">INPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">OUTPUT<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">FORWARD<br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
</tr>
<tr>
<td valign="top">POSTROUTING<br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top">X<br>
</td>
</tr>
</div>
<p>Shorewall doesn't create rules in all of the builtin chains. In the large
diagram below are boxes such as  shown below.  This box represents in INPUT
chain and shows that packets first flow through the INPUT chain in the Mangle
table followed by the INPUT chain in the Filter table. The parentheses around
"Mangle" indicate that while the packets will flow through the INPUT chain
in the Mangle table, Shorewall does not create any rules in that chain.<br>
</p>
</tbody>
</table>
</div>
<p>Shorewall doesn't create rules in all of the builtin chains. In the large
diagram below are boxes such as  shown below.  This box represents in INPUT
chain and shows that packets first flow through the INPUT chain in the Mangle
table followed by the INPUT chain in the Filter table. The parentheses around
"Mangle" indicate that while the packets will flow through the INPUT chain
in the Mangle table, Shorewall does not create any rules in that chain.<br>
</p>
<div align="center"><img src="images/Legend.png" alt="(Box Legend)"
width="145" height="97" align="middle">
<br>
</div>
<p></p>
<p>Here is a picture of how packets traverse the various chains and tables
in Netfilter. In that diagram, "Local Process" refers to a process running
on the Firewall itself (in the 'fw' zone).</p>
<br>
</div>
<p></p>
<p>Here is a picture of how packets traverse the various chains and tables
in Netfilter. In that diagram, "Local Process" refers to a process running
on the Firewall itself (in the 'fw' zone).</p>
<div align="center"><img src="images/Netfilter.png"
alt="Netfilter Flow Diagram" width="541" height="767">
</div>
<p><br>
<br>
In the text that follows, the paragraph numbers correspond to the box number
in the diagram above.<br>
</p>
<ol>
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing "shorewall show
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b> chain which will
drop the packet if its destination IP address is reserved (as specified
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
file. Finally, if traffic control/shaping is being used, the packet is sent
through the<b> tcpre</b> chain to be marked for later use in policy routing
or traffic control.<br>
<br>
Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
by typing "shorewall show nat"). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on
the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
on then packets will ender a chain called<b> <i>interface_</i>in</b> where
<i>interface</i> is the name of the interface on which the packet entered.
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP
addresses from /etc/shorewall/nat that correspond to this interface; if
there is a match, DNAT is applied and the packet header is modified to
the IP in the <i>INTERNAL</i> column of the nat file record. If the destination
address doesn't match any of the rules in the <b><i>interface_</i>in</b>
chain then the packet enters a chain called <b><i>sourcezone</i>_dnat</b>
where <i>sourcezone</i> is the source zone of the packet. There it is compared
for a match against each of the DNAT records in the rules file that specify
<i> sourcezone </i>as the source zone. If a match is found, the destination
IP address (and possibly the destination port) is modified based on the
rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of
the <b><i> interface_</i>in</b> and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
<br>
</li>
<li>Depending on whether the packet is destined for the firewall itself
or for another system, it follows either the left or the right path. Traffic
going to the firewall goes through chains called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain. Traffic next passes the the
INPUT chain in the filter table where it is broken out based on the interface
on which the packet arrived; packets from interface <i>interface</i> are routed
to chain <b><i>interface</i>_in</b>. For example, packets arriving through
eth0 are passed to the chain <b>eth0_in.</b></li>
<ol>
<li>The first rule in <b><i>interface</i>_in</b> jumps to the chain
named <b>dynamic</b> which matches the source IP in the packet against all
of the addresses that have been blacklisted using <a
href="blacklisting_support.htm#Dynamic">dynamic blacklisting</a>.</li>
<li>If the the interface has the <b>norfc1918</b> option then the packet
is sent down the <b>rfc1918 </b>which checks the source address against those
listed in /etc/shorewall/rfc1918 and treats the packet according to the first
match in that file (if any).</li>
<li>If the interface has the  <b>dhcp </b>option, UDP packets to ports
67 and 68 are accepted.</li>
<li><br>
</li>
</ol>
<li>Traffic is next sent to an<i> input </i>chain in the mail Netfilter
table (called 'filter'). If the traffic is destined for the firewall itself,
the name of the input chain is formed by appending "_in" to the interface
name. So traffic on eth0 destined for the firewall will enter a chain called
<i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending "_fwd" to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces,
share input chains. if <i>ppp+ </i>appears in /etc/shorewall/interfaces
then all PPP interfaces (ppp0, ppp1, ...) will share the input chains <i>ppp_in</i>
and <i>ppp_fwd</i>. In other words, "+" is deleted from the name before
forming the input chain names.</li>
</ol>
<p> While the use of input chains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </p>
<p> Traffic directed from a zone to the firewall itself is sent through
a chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">  </font></p>
<p> Traffic being forwarded between two zones (or from one interface to
a zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to as
the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p> For each record in the /etc/shorewall/policy file, a chain is created.
Policies in that file are expressed in terms of a source zone and destination
zone where these zones may be a zone defined in /etc/shorewall/zones,
"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
zones and "fw". These chains are referred to as <i>Policy Chains.</i> Notice
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
may also be the policy chain for the pair or the policy chain may be a
different chain (za2all, for example). Packets from one zone to another
will traverse chains as follows:</p>
<ol>
<li> If the canonical chain exists, packets first traverse that
chain.</li>
<li> If the canonical chain and policy chain are different and
the packet does not match a rule in the canonical chain, it then is sent
to the policy chain.</li>
<li> If the canonical chain does not exist, packets are sent
immediately to the policy chain.</li>
</ol>
<p> The canonical chain from zone za to zone zb will be created only if
there are exception rules defined in /etc/shorewall/rules for packets going
from za to zb.</p>
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
<ol>
<li> Identify the client's zone.</li>
<li> Identify the server's 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 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>
</ol>
<p> Just because connections of a particular type are allowed between zone
A and the firewall and are also allowed between the firewall and zone
B <font color="#ff6633"><b><u> DOES NOT mean that these connections
are allowed between zone A and zone B</u></b></font>. It rather means
that you can have a proxy running on the firewall that accepts a connection
from zone A and then establishes its own separate connection from the firewall
to zone B.</p>
<p> If you adopt the default policy of ACCEPT from the local zone to the
internet zone and you are having problems connecting from a local client
to an internet server, <font color="#ff6633"><b><u> adding a rule won't
help</u></b></font> (see point 3 above).</p>
</div>
<p><font size="2">Last modified 5/22/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, 2003 Thomas M. Eastep.</font></a></font></p>
<p><br>
<br>
In the text that follows, the paragraph numbers correspond to the box number
in the diagram above.<br>
</p>
<ol>
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing "shorewall show
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
option and if iptables/netfilter doesn't support the connection tracking
match extension, then the packet is sent down the <b>man1918</b> chain which
will drop the packet if its destination IP address is reserved (as specified
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
file. Finally, if traffic control/shaping is being used, the packet is sent
through the<b> tcpre</b> chain to be marked for later use in policy routing
or traffic control.<br>
<br>
Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
by typing "shorewall show nat"). If you are doing both static nat and port
forwarding, the order in which chains are traversed is dependent on the
setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on
then packets will ender a chain called<b> <i>interface_</i>in</b> where
<i>interface</i> is the name of the interface on which the packet entered.
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP addresses
from /etc/shorewall/nat that correspond to this interface; if there is
a match, DNAT is applied and the packet header is modified to the IP in
the <i>INTERNAL</i> column of the nat file record. If the destination address
doesn't match any of the rules in the <b><i>interface_</i>in</b> chain then
the packet enters a chain called <b><i>sourcezone</i>_dnat</b> where <i>sourcezone</i>
is the source zone of the packet. There it is compared for a match against
each of the DNAT records in the rules file that specify <i> sourcezone
</i>as the source zone. If a match is found, the destination IP address
(and possibly the destination port) is modified based on the rule matched.
If NAT_BEFORE_RULES is off, then the order of traversal of the <b><i> interface_</i>in</b>
and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
<br>
</li>
<li>Depending on whether the packet is destined for the firewall itself
or for another system, it follows either the left or the right path. Traffic
going to the firewall goes through chain called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain.<br>
<br>
</li>
<li>Traffic that is to be forwarded to another host goes through the chains
called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf,
all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are
processed in a chain called <br>
<br>
</li>
<ol>
</ol>
<li>Traffic is next sent to an<i> interface </i>chain in the main Netfilter
table (called 'filter'). If the traffic is destined for the firewall itself,
the name of the interface chain is formed by appending "_in" to the interface
name. So traffic on eth0 destined for the firewall will enter a chain called
<i>eth0_in</i>. The interface chain for traffic that will be routed
to another system is formed by appending "_fwd" to the interface name.
So traffic from eth1 that is going to be forwarded enters a chain called<i>
eth1_fwd</i>. Interfaces described with the wild-card character ("+")
in /etc/shorewall/interfaces, share input chains. if <i>ppp+ </i>appears
in /etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will
share the interface chains <i>ppp_in</i> and <i>ppp_fwd</i>. In other words,
"+" is deleted from the name before forming the input chain names.<br>
<br>
While the use of interfacechains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </li>
</ol>
<p> Traffic directed from a zone to the firewall itself is sent through a
chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent
to a host in a given zone is sent through a chain named fw2<i>&lt;zone
name&gt;. </i>For example, traffic originating in the firewall and
destined for a host in the local network is sent through a chain named
<i>fw2loc.</i> <font face="Century Gothic, Arial, Helvetica">  </font></p>
<p> Traffic being forwarded between two zones (or from one interface to a
zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to
as the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should
be expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p> For each record in the /etc/shorewall/policy file, a chain is created.
Policies in that file are expressed in terms of a source zone and destination
zone where these zones may be a zone defined in /etc/shorewall/zones, "fw"
or "all". Policies specifying the pseudo-zone "all" matches all defined
zones and "fw". These chains are referred to as <i>Policy Chains.</i> Notice
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
may also be the policy chain for the pair or the policy chain may be a
different chain (za2all, for example). Packets from one zone to another
will traverse chains as follows:</p>
<ol>
<li> If the canonical chain exists, packets first traverse that
chain.</li>
<li> If the canonical chain and policy chain are different and
the packet does not match a rule in the canonical chain, it then is sent
to the policy chain.</li>
<li> If the canonical chain does not exist, packets are sent
immediately to the policy chain.</li>
</ol>
<p> The canonical chain from zone za to zone zb will be created only if there
are exception rules defined in /etc/shorewall/rules for packets going from
za to zb.</p>
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than
in terms of "packets". With Shorewall, you:</p>
<ol>
<li> Identify the client's zone.</li>
<li> Identify the server's 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 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>
</ol>
<p> Just because connections of a particular type are allowed between zone
A and the firewall and are also allowed between the firewall and zone B
<font color="#ff6633"><b><u> DOES NOT mean that these connections are
allowed between zone A and zone B</u></b></font>. It rather means that
you can have a proxy running on the firewall that accepts a connection
from zone A and then establishes its own separate connection from the firewall
to zone B.</p>
<p> If you adopt the default policy of ACCEPT from the local zone to the
internet zone and you are having problems connecting from a local client
to an internet server, <font color="#ff6633"><b><u> adding a rule won't
help</u></b></font> (see point 3 above).</p>
<p><font size="2">Last modified 5/22/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, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>
</body>

465
Shorewall-docs/shorewall_quickstart_guide.htm
View File

@ -1,308 +1,321 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall QuickStart Guide</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
Version 4.0</font></h1>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="center">With thanks to Richard who reminded me once again that we
must all first walk before we can run.<br>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
<p align="center">With thanks to Richard who reminded me once again that
we must all first walk before we can run.<br>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
<h2>The Guides</h2>
<p>These guides provide step-by-step instructions for configuring Shorewall
in common firewall setups.</p>
<p>These guides provide step-by-step instructions for configuring Shorewall
in common firewall setups.</p>
<p>The following guides are for <b>users who have a single public IP address</b>:</p>
<ul>
<li><a href="standalone.htm">Standalone</a>
Linux System (<a href="standalone_fr.html">Version Française</a>)</li>
<li><a href="two-interface.htm">Two-interface</a>
Linux System acting as a firewall/router for a small local
network (<a href="two-interface_fr.html">Version Française</a>)</li>
<li><a href="three-interface.htm">Three-interface</a>
Linux System acting as a firewall/router for a small local
network and a DMZ. (<a href="three-interface_fr.html">Version Française</a>)</li>
<li><a href="standalone.htm">Standalone</a>
Linux System (<a href="standalone_fr.html">Version Française</a>)</li>
<li><a href="two-interface.htm">Two-interface</a>
Linux System acting as a firewall/router for a small local
network (<a href="two-interface_fr.html">Version Française</a>)</li>
<li><a href="three-interface.htm">Three-interface</a>
Linux System acting as a firewall/router for a small local
network and a DMZ. (<a href="three-interface_fr.html">Version Française</a>)</li>
</ul>
<p>The above guides are designed to get your first firewall up and running
quickly in the three most common Shorewall configurations.</p>
<p>The <a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a> (See
Index Below) outlines the steps necessary to set up a firewall
where <b>there are multiple public IP addresses involved or
if you want to learn more about Shorewall than is explained in
the single-address guides above.</b></p>
<p>The above guides are designed to get your first firewall up and running
quickly in the three most common Shorewall configurations.</p>
<p>The <a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a> (See
Index Below) outlines the steps necessary to set up a firewall
where <b>there are multiple public IP addresses involved or
if you want to learn more about Shorewall than is explained in
the single-address guides above.</b></p>
<ul>
</ul>
<h2><a name="Documentation"></a>Documentation Index</h2>
<p>The following documentation covers a variety of topics and <b>supplements
the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
described above</b>. Please review the appropriate guide before
trying to use this documentation directly.</p>
<p>The following documentation covers a variety of topics and <b>supplements
the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
described above</b>. Please review the appropriate guide before
trying to use this documentation directly.</p>
<ul>
<li><a
href="Shorewall_and_Aliased_Interfaces.html">Aliased (virtual) Interfaces
(e.g., eth0:0)</a><br>
</li>
<li><a href="blacklisting_support.htm">Blacklisting</a>
<li><a
href="Shorewall_and_Aliased_Interfaces.html">Aliased (virtual) Interfaces
(e.g., eth0:0)</a><br>
</li>
<li><a href="blacklisting_support.htm">Blacklisting</a>
<ul>
<li>Static Blacklisting using /etc/shorewall/blacklist</li>
<li>Dynamic Blacklisting using /sbin/shorewall</li>
<li>Static Blacklisting using /etc/shorewall/blacklist</li>
<li>Dynamic Blacklisting using /sbin/shorewall</li>
</ul>
</li>
<li><a
href="configuration_file_basics.htm">Common configuration file
features</a>
</li>
<li><a
href="configuration_file_basics.htm">Common configuration file
features</a>
<ul>
<li><a
href="configuration_file_basics.htm#Comments">Comments in configuration
files</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#Comments">Comments in configuration
files</a></li>
<li><a
href="configuration_file_basics.htm#Continuation">Line Continuation</a></li>
<li><a href="configuration_file_basics.htm#INCLUDE">INCLUDE Directive</a><br>
</li>
<li><a
<li><a href="configuration_file_basics.htm#INCLUDE">INCLUDE Directive</a><br>
</li>
<li><a
href="configuration_file_basics.htm#Ports">Port Numbers/Service Names</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#Ranges">Port Ranges</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#Variables">Using Shell Variables</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#dnsnames">Using DNS Names</a><br>
</li>
<li><a
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a
href="configuration_file_basics.htm#Configs">Shorewall Configurations
(making a test configuration)</a></li>
<li><a
</li>
<li><a
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a
href="configuration_file_basics.htm#Configs">Shorewall Configurations (making
a test configuration)</a></li>
<li><a
href="configuration_file_basics.htm#MAC">Using MAC Addresses in Shorewall</a></li>
</ul>
</li>
<li><a href="Documentation.htm">Configuration
File Reference Manual</a>
</li>
<li><a href="Documentation.htm">Configuration
File Reference Manual</a>
<ul>
<li> <a
<li> <a
href="Documentation.htm#Variables">params</a></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Zones">zones</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Interfaces">interfaces</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Hosts">hosts</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Policy">policy</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Rules">rules</a></font></li>
<li><a href="Documentation.htm#Common">common</a></li>
<li><font color="#000099"><a
<li><a
href="Documentation.htm#Common">common</a></li>
<li><font color="#000099"><a
href="Documentation.htm#Masq">masq</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#ProxyArp">proxyarp</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#NAT">nat</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Tunnels">tunnels</a></font></li>
<li><a
<li><a
href="traffic_shaping.htm#tcrules">tcrules</a></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Conf">shorewall.conf</a></font></li>
<li><a
<li><a
href="Documentation.htm#modules">modules</a></li>
<li><a href="Documentation.htm#TOS">tos</a>
</li>
<li><a
<li><a href="Documentation.htm#TOS">tos</a>
</li>
<li><a
href="Documentation.htm#Blacklist">blacklist</a></li>
<li><a
<li><a
href="Documentation.htm#rfc1918">rfc1918</a></li>
<li><a
<li><a
href="Documentation.htm#Routestopped">routestopped</a></li>
</ul>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><a href="ECN.html">ECN Disabling by host
or subnet</a><br>
</li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code through the
use of files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped,
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><a href="ECN.html">ECN Disabling by
host or subnet</a></li>
<li><a href="errata.htm">Errata</a><br>
</li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code through the
use of files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped,
etc.)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="FAQ.htm">FAQs</a><br>
</li>
<li><a href="shorewall_features.htm">Features</a><br>
</li>
<li><a
href="shorewall_firewall_structure.htm">Firewall Structure</a></li>
<li><font color="#000099"><a
<li><a href="support.htm">Getting help or answers to questions</a></li>
<li><a href="Install.htm">Installation/Upgrade</a><br>
</li>
<li><font color="#000099"><a
href="kernel.htm">Kernel Configuration</a></font></li>
<li><a href="shorewall_logging.html">Logging</a><br>
</li>
<li><a href="MAC_Validation.html">MAC Verification</a><br>
</li>
<li><a href="myfiles.htm">My Shorewall
Configuration (How I personally use Shorewall)</a><br>
</li>
<li><a href="ping.html">'Ping' Management</a><br>
<li><a href="shorewall_logging.html">Logging</a><br>
</li>
<li><a href="ports.htm">Port Information</a>
<li><a href="MAC_Validation.html">MAC Verification</a></li>
<li><a href="http://lists.shorewall.net">Mailing Lists</a><br>
</li>
<li><a href="myfiles.htm">My Shorewall
Configuration (How I personally use Shorewall)</a><br>
</li>
<li><a href="ping.html">'Ping' Management</a><br>
</li>
<li><a href="ports.htm">Port Information</a>
<ul>
<li>Which applications use which ports</li>
<li>Ports used by Trojans</li>
<li>Which applications use which ports</li>
<li>Ports used by Trojans</li>
</ul>
</li>
<li><a href="ProxyARP.htm">Proxy ARP</a></li>
<li><a href="samba.htm">Samba</a></li>
<li><a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a><br>
</li>
</li>
<li><a href="ProxyARP.htm">Proxy ARP</a></li>
<li><a href="shorewall_prerequisites.htm">Requirements</a><br>
</li>
<li><a href="samba.htm">Samba</a></li>
<li><a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a><br>
</li>
<ul>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0 Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0 Shorewall
Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0 Network
Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0 Addressing,
Subnets and Routing</a>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0 Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0 Shorewall
Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0 Network
Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0 Addressing,
Subnets and Routing</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Addresses">4.1 IP
Addresses</a></li>
<li><a href="shorewall_setup_guide.htm#Subnets">4.2 Subnets</a></li>
<li><a href="shorewall_setup_guide.htm#Routing">4.3 Routing</a></li>
<li><a href="shorewall_setup_guide.htm#ARP">4.4 Address
Resolution Protocol (ARP)</a></li>
</ul>
<ul>
<li><a href="shorewall_setup_guide.htm#RFC1918">4.5 RFC
1918</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Options">5.0 Setting
up your Network</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Addresses">4.1 IP
Addresses</a></li>
<li><a href="shorewall_setup_guide.htm#Subnets">4.2 Subnets</a></li>
<li><a href="shorewall_setup_guide.htm#Routing">4.3 Routing</a></li>
<li><a href="shorewall_setup_guide.htm#ARP">4.4 Address
Resolution Protocol (ARP)</a></li>
<li><a href="shorewall_setup_guide.htm#Routed">5.1 Routed</a></li>
</ul>
<ul>
<li><a href="shorewall_setup_guide.htm#RFC1918">4.5 RFC
1918</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Options">5.0 Setting
up your Network</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Routed">5.1 Routed</a></li>
</ul>
<ul>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2 Non-routed</a>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2 Non-routed</a>
<ul>
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1 SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2 DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#ProxyARP">5.2.3
Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4 Static
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1 SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2 DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#ProxyARP">5.2.3
Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4 Static
NAT</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a href="shorewall_setup_guide.htm#OddsAndEnds">5.4 Odds
and Ends</a></li>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a href="shorewall_setup_guide.htm#OddsAndEnds">5.4 Odds
and Ends</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#DNS">6.0 DNS</a></li>
<li><a href="shorewall_setup_guide.htm#StartingAndStopping">7.0
</li>
<li><a href="shorewall_setup_guide.htm#DNS">6.0 DNS</a></li>
<li><a href="shorewall_setup_guide.htm#StartingAndStopping">7.0
Starting and Stopping the Firewall</a></li>
</ul>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="starting_and_stopping_shorewall.htm">Starting/stopping the Firewall</a></font></li>
<ul>
<li>Description of all /sbin/shorewall commands</li>
<li>How to safely test a Shorewall configuration
<li>Description of all /sbin/shorewall commands</li>
<li>How to safely test a Shorewall configuration
change<br>
</li>
</li>
</ul>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="NAT.htm">Static NAT</a></font></li>
<li><a href="Shorewall_Squid_Usage.html">Squid as a Transparent
Proxy with Shorewall</a><br>
</li>
<li><a href="traffic_shaping.htm">Traffic
Shaping/QOS</a></li>
<li>VPN
<li><a href="Shorewall_Squid_Usage.html">Squid as a Transparent
Proxy with Shorewall</a></li>
<li><a href="traffic_shaping.htm">Traffic
Shaping/QOS</a></li>
<li><a href="troubleshoot.htm">Troubleshooting (Things to try if it doesn't
work)</a><br>
</li>
<li><a href="upgrade_issues.htm">Upgrade Issues</a><br>
</li>
<li>VPN
<ul>
<li><a href="IPSEC.htm">IPSEC</a></li>
<li><a href="IPIP.htm">GRE and IPIP</a></li>
<li><a href="OPENVPN.html">OpenVPN</a><br>
</li>
<li><a href="PPTP.htm">PPTP</a></li>
<li><a href="6to4.htm">6t04</a><br>
</li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from
a system behind your firewall to a remote network.</li>
<li><a href="IPSEC.htm">IPSEC</a></li>
<li><a href="IPIP.htm">GRE and IPIP</a></li>
<li><a href="OPENVPN.html">OpenVPN</a><br>
</li>
<li><a href="PPTP.htm">PPTP</a></li>
<li><a href="6to4.htm">6t04</a><br>
</li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from
a system behind your firewall to a remote network.</li>
</ul>
</li>
<li><a
</li>
<li><a
href="whitelisting_under_shorewall.htm">White List Creation</a></li>
</ul>
<p>If you use one of these guides and have a suggestion for improvement <a
href="mailto:webmaster@shorewall.net">please let me know</a>.</p>
<p><font size="2">Last modified 5/18/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<p><font size="2">Last modified 7/6/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
</p>
</body>
</html>

4445
Shorewall-docs/shorewall_setup_guide.htm
View File

File diff suppressed because it is too large Load Diff

651
Shorewall-docs/sourceforge_index.htm
View File

@ -3,473 +3,556 @@
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="33%" height="90" valign="middle"
<td width="33%" height="90" valign="middle"
align="left"><a href="http://www.cityofshoreline.com"><img
src="images/washington.jpg" alt="" width="97" height="80" hspace="4"
border="0">
</a></td>
<td valign="middle" width="34%" align="center">
</a></td>
<td valign="middle" width="34%" align="center">
<h1><font color="#ffffff">Shorewall 1.4</font><i><font
color="#ffffff"> <small><small><small>"iptables made easy"</small></small></small></font></i></h1>
</td>
<td valign="middle">
</td>
<td valign="middle">
<h1 align="center"><a href="http://www.shorewall.net"
target="_top"><br>
</a></h1>
<br>
</td>
</tr>
</a></h1>
<br>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tbody>
<tr>
<tr>
<td width="90%">
<td width="90%">
<h2 align="left">What is it?</h2>
<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>
<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>
<p>This program is free software; you can redistribute it and/or modify
<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
Foundation.<br>
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>
<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>
<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,
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>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not apply
directly to your setup. If you want to use the documentation that
you find here, you will want to consider uninstalling what you have and
installing a setup that matches the documentation on this site. See
the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.<br>
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2><b>News</b></h2>
<b> </b>
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
New to Shorewall? Start by selecting the <a
href="file:///vfat/Shorewall-docs/shorewall_quickstart_guide.htm">QuickStart
Guide</a> that most closely match your environment and follow
the step by step instructions.<br>
<h2>Looking for Information?</h2>
The <a href="shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a> is a good place to start as is the Quick Search to your right.
<blockquote><a href="http://shorewall.net/pub/shorewall/testing">http://shorewall.net/pub/shorewall/testing</a><br>
<a href="ftp://shorewall.net/pub/shorewall/testing" target="_top">ftp://shorewall.net/pub/shorewall/testing</a><br>
</blockquote>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not
apply directly to your setup. If you want to use the documentation
that you find here, you will want to consider uninstalling what you have
and installing a setup that matches the documentation on this site.
See the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.
<h2></h2>
<h2><b>News</b></h2>
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b><b> <img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
<p><b>Problems Corrected:</b><br>
</p>
</p>
<ol>
<li>A problem seen on RH7.3 systems where Shorewall encountered
start errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Previously, where a list of IP addresses appears in the DEST
column of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
in the nat table (one for each element in the list). Shorewall now correctly
creates a single DNAT rule with multiple "--to-destination" clauses.<br>
</li>
<li>A problem seen on RH7.3 systems where Shorewall encountered start
errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Where a list of IP addresses appears in the DEST column of a
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat
table (one for each element in the list). Shorewall now correctly creates
a single DNAT rule with multiple "--to-destination" clauses.<br>
<br>
</li>
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
were mis-handled when they appeared in the DEST column of a rule.<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<p><b>Migration Issues:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option
may be specified in /etc/shorewall/interfaces and overrides the setting
NEWNOTSYN=No for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
<li>In earlier versions, an undocumented feature allowed entries
in the host file as follows:<br>
<br>
    z    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
    z   eth1:192.168.1.0/24,192.168.2.0/24<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
detected by Shorewall (see below).<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option may
be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
to use for SNAT is now documented. ADD_SNAT_ALIASES=Yes is enabled for address
ranges.<br>
<br>
</li>
<li>Shorewall can now add IP addresses to subnets other than the
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin)
over a set of servers. Up to 256 servers may be specified in a range of addresses
given as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
Note that this capability has previously been available using a combination
of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable
for load-balancing over a large number of servers (&gt; 16) since specifying
a range in the DNAT rule causes one filter table ACCEPT rule to be generated
for each IP address in the range.<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
options have been removed and have been replaced by code that detects whether
these capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
Verifying Configuration...<br>
<br>
</li>
<li>Support for the Connection Tracking Match Extension has been
added. This extension is available in recent kernel/iptables releases and
allows for rules which match against elements in netfilter's connection
<br>
</li>
<li>Shorewall can now add IP addresses to subnets other than the
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin) over
a set of servers. Servers may be specified in a range of addresses given
as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
have been removed and have been replaced by code that detects whether these
capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
Verifying Configuration...<br>
<br>
</li>
<li>Support for the Connection Tracking Match Extension has been
added. This extension is available in recent kernel/iptables releases and
allows for rules which match against elements in netfilter's connection
tracking table. Shorewall automatically detects the availability of this
extension and reports its availability in the output of the start, restart
and check commands.<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
   Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is
changed in the following ways:</li>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
   NAT: Available<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is changed
in the following ways:</li>
<ul>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
in the filter table (rfc1918 chain).</li>
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
one in the nat table and one in the filter table. If the Connection Tracking
Match Extension is available, the rule in the filter table is extended to
check that the original destination address was the same as specified (or
defaulted to) in the DNAT rule.<br>
<br>
</li>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
in the filter table (rfc1918 chain).</li>
<li>Recall that Shorewall DNAT rules generate two netfilter rules;
one in the nat table and one in the filter table. If the Connection Tracking
Match Extension is available, the rule in the filter table is extended to
check that the original destination address was the same as specified (or
defaulted to) in the DNAT rule.<br>
<br>
</li>
</ul>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.</li>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.<br>
<br>
</li>
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
<br>
      ipcalc [ &lt;address&gt; &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt;
]<br>
<br>
Examples:<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0/24<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
Warning:<br>
<br>
If your shell only supports 32-bit signed arithmatic (ash or dash), then
the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1
and for /1 networks. Bash should produce correct information for all valid
IP addresses.<br>
<br>
</li>
<li>An 'iprange' command has been added to /sbin/shorewall. <br>
<br>
      iprange &lt;address&gt;-&lt;address&gt;<br>
<br>
This command decomposes a range of IP addressses into a list of network
and host addresses. The command can be useful if you need to construct an
efficient set of rules that accept connections from a range of network addresses.<br>
<br>
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
then the range may not span 128.0.0.0.<br>
<br>
Example:<br>
<br>
      [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9<br>
      192.168.1.4/30<br>
      192.168.1.8/29<br>
      192.168.1.16/28<br>
      192.168.1.32/27<br>
      192.168.1.64/26<br>
      192.168.1.128/25<br>
      192.168.2.0/23<br>
      192.168.4.0/22<br>
      192.168.8.0/22<br>
      192.168.12.0/29<br>
      192.168.12.8/31<br>
      [root@gateway root]#<br>
<br>
</li>
<li>A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.<br>
<br>
Example:<br>
<br>
    foo    eth1:192.168.1.0/24,192.168.2.0/24</li>
</ol>
<b> </b>
<ol>
</ol>
<p><b>6/17/2003 - Shorewall-1.4.5</b><b> </b></p>
<p>Problems Corrected:<br>
</p>
</p>
<ol>
<li>The command "shorewall debug try &lt;directory&gt;" now correctly
traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones file;
previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
<li>The command "shorewall debug try &lt;directory&gt;" now
correctly traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones
file; previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
</ol>
<p>New Features:<br>
</p>
</p>
<ol>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then the
rule will take effect only if the original destination address in the connection
request does not match any of the addresses listed.</li>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then
the rule will take effect only if the original destination address in
the connection request does not match any of the addresses listed.</li>
</ol>
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
</b></p>
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
have been encountered with this set of software. The Shorewall version
is 1.4.4b plus the accumulated changes for 1.4.5.
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
</b></p>
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No
problems have been encountered with this set of software. The Shorewall
version is 1.4.4b plus the accumulated changes for 1.4.5.
<p><b>6/8/2003 - Updated Samples</b><b> </b></p>
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>
<p><b></b></p>
<ol>
</ol>
<p><b></b></p>
<p><b></b></p>
<blockquote>
<blockquote>
<ol>
</ol>
</blockquote>
</blockquote>
<p><a href="file:///Z:/Shorewall-docs/News.htm"></a></p>
<b> </b>
<b> </b>
<p><b><a href="News.htm">More News</a></b></p>
<b> </b>
<b> </b>
<h2><b> </b></h2>
<b> </b>
<b> </b>
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36"
alt="(Leaf Logo)">
</a>Jacques Nilo and Eric Wolzak
have a LEAF (router/firewall/gateway
</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.4.2 and Kernel-2.4.20. You
can find their work at: <a
called <i>Bering</i> that features
Shorewall-1.4.2 and Kernel-2.4.20. You
can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.2!!!
</b><br>
<b>Congratulations to Jacques
and Eric on the recent release of Bering 1.2!!!
</b><br>
<h1 align="center"><b><a href="http://www.sf.net"><img
align="left" alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
</a></b></h1>
<b> </b>
</a></b></h1>
<b> </b>
<h4><b> </b></h4>
<b> </b>
<b> </b>
<h2><b>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </b></h2>
<b> </b>
<b> </b>
<h2><b><a name="Donations"></a>Donations</b></h2>
<b> </b></td>
<b> </b></td>
<td width="88" bgcolor="#4b017c"
valign="top" align="center">
<td width="88" bgcolor="#4b017c"
valign="top" align="center">
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch">
action="http://lists.shorewall.net/cgi-bin/htsearch">
<p><strong><br>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
 </p>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily
0200-0330 GMT.</font><br>
 </p>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial" size="-1"> <input
type="text" name="words" size="15"></font><font size="-1"> </font><font
face="Arial" size="-1"> <input type="hidden" name="format"
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
type="submit" value="Search"></font> </p>
<font face="Arial"> <input
<font face="Arial" size="-1">
<input type="text" name="words" size="15"></font><font
size="-1"> </font><font face="Arial" size="-1"> <input
type="hidden" name="format" value="long"> <input
type="hidden" name="method" value="and"> <input type="hidden"
name="config" value="htdig"> <input type="submit"
value="Search"></font> </p>
<font face="Arial"> <input
type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font>
</form>
value="[http://lists.shorewall.net/pipermail/*]"> </font>
</form>
<p><font color="#ffffff"><b> <a
href="http://lists.shorewall.net/htdig/search.html"> <font
color="#ffffff">Extended Search</font></a></b></font></p>
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
<a target="_top"
href="file:///vfat/Shorewall-docs/1.3/index.html"><font color="#ffffff">
</font></a><a target="_top"
href="http://www1.shorewall.net/1.2/index.htm"><font color="#ffffff"><small><small><small></small></small></small></font></a><br>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
</center>
</center>
</div>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="100%" style="margin-top: 1px;">
<td width="100%" style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
</a></p>
<p align="center"><font size="4" color="#ffffff"><br>
<font size="+2">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></font></p>
</td>
</tr>
<p align="center"><font size="4" color="#ffffff"><br>
<font size="+2">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></font></p>
</td>
</tr>
</tbody>
</tbody>
</table>
<p><font size="2">Updated 7/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
<p><font size="2">Updated 7/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</body>
</html>

495
Shorewall-docs/starting_and_stopping_shorewall.htm
View File

@ -1,341 +1,294 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Starting and Stopping Shorewall</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Starting/Stopping and Monitoring
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Starting/Stopping and Monitoring
the Firewall</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p> If you have a permanent internet connection such as DSL or Cable,
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>
<p> If you have a permanent internet connection such as DSL or Cable,
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>
<p><strong><u> <font color="#000099"> Important Notes:</font></u></strong><br>
</p>
</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
<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>
</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 restart" in that script.</li>
</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
restart" in that script.</li>
</ol>
<p>
</p>
<p> You can manually start and stop Shoreline Firewall using the "shorewall"
<p> </p>
<p> You can manually start and stop Shoreline Firewall using the "shorewall"
shell program: </p>
<ul>
<li>shorewall start - starts the firewall</li>
<li>shorewall stop - stops the firewall</li>
<li>shorewall restart - stops the firewall (if it's
running) and then starts it again</li>
<li>shorewall reset - reset the packet and byte counters
<li>shorewall start - starts the firewall</li>
<li>shorewall stop - stops the firewall</li>
<li>shorewall restart - stops the firewall (if it's
running) and then starts it again</li>
<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>
<li>shorewall refresh - refresh the rules involving the broadcast
addresses of firewall interfaces, <a
<li>shorewall clear - remove all rules and chains installed
by Shoreline Firewall</li>
<li>shorewall refresh - refresh the rules involving the
broadcast addresses of firewall interfaces, <a
href="blacklisting_support.htm">the black list</a>, <a
href="traffic_shaping.htm">traffic control rules</a> and <a
href="ECN.html">ECN control rules</a>.</li>
</ul>
If you include the keyword <i>debug</i> as the first argument, then
If you include the keyword <i>debug</i> as the first argument, then
a shell trace of the command is produced as in:<br>
<pre> <font color="#009900"><b>shorewall debug start 2&gt; /tmp/trace</b></font><br></pre>
<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
<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
bottom of this page.<br>
</p>
</p>
<p>The "shorewall" program may also be used to monitor the firewall.</p>
<ul>
<li>shorewall status - produce a verbose report about the
<li>shorewall status - produce a verbose report about the
firewall (iptables -L -n -v)</li>
<li>shorewall show <i>chain</i> - produce a verbose report
<li>shorewall show <i>chain</i> - produce a verbose report
about <i>chain </i>(iptables -L <i>chain</i> -n -v)</li>
<li>shorewall show nat - produce a verbose report about the
nat table (iptables -t nat -L -n -v)</li>
<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
<li>shorewall show nat - produce a verbose report about
the nat table (iptables -t nat -L -n -v)</li>
<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
tc - displays
<li>shorewall show
tc - displays
information about the traffic control/shaping configuration.</li>
<li>shorewall monitor [ delay ] - Continuously display the
firewall status, last 20 log entries and nat. When the log
<li>shorewall monitor [ delay ] - Continuously display the
firewall status, last 20 log entries and nat. When the log
entry display changes, an audible alarm is sounded.</li>
<li>shorewall hits - Produces several reports about the Shorewall
packet log messages in the current /var/log/messages file.</li>
<li>shorewall version - Displays the installed version
<li>shorewall hits - Produces several reports about the
Shorewall packet log messages in the current /var/log/messages
file.</li>
<li>shorewall version - Displays the installed version
number.</li>
<li>shorewall check - Performs a <u>cursory</u> validation of the
<li>shorewall check - Performs a <u>cursory</u> validation of the
zones, interfaces, hosts, rules and policy files.<br>
<br>
<font size="4" color="#ff6666"><b>The "check" command is totally unsuppored
and does not parse and validate the generated iptables commands. Even
though the "check" command completes successfully, the configuration
may fail to start. Problem reports that complain about errors that the 'check'
<br>
<font size="4" color="#ff6666"><b>The "check" command is totally unsuppored
and does not parse and validate the generated iptables commands.
Even though the "check" command completes successfully, the configuration
may fail to start. Problem reports that complain about errors that the 'check'
command does not detect will not be accepted.<br>
<br>
See the recommended way to make configuration changes described below.</b></font><br>
<br>
See the recommended way to make configuration changes described below.</b></font><br>
<br>
</li>
<li>shorewall try<i> configuration-directory</i> [<i> timeout</i>
] - Restart shorewall using the specified configuration and if an
error occurs or if the<i> timeout </i> option is given and the new
configuration has been up for that many seconds then shorewall is
restarted using the standard configuration.</li>
<li>shorewall deny, shorewall reject, shorewall accept and
shorewall save implement <a href="blacklisting_support.htm">dynamic
</li>
<li>shorewall try<i> configuration-directory</i> [<i> timeout</i>
] - Restart shorewall using the specified configuration and if
an error occurs or if the<i> timeout </i> option is given and the
new configuration has been up for that many seconds then shorewall
is restarted using the standard configuration.</li>
<li>shorewall deny, shorewall reject, shorewall accept and
shorewall save implement <a href="blacklisting_support.htm">dynamic
blacklisting</a>.</li>
<li>shorewall logwatch (added in version 1.3.2) - Monitors
the <a href="#Conf">LOGFILE </a>and produces an audible alarm when
<li>shorewall logwatch (added in version 1.3.2) - Monitors
the <a href="#Conf">LOGFILE </a>and produces an audible alarm when
new Shorewall messages are logged.</li>
</ul>
Finally, the "shorewall" program may be used to dynamically alter
the contents of a zone.<br>
Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of commands
for dealing with IP addresses and IP address ranges:<br>
<ul>
<li>shorewall add <i>interface</i>[:<i>host]</i> <i>zone </i>-
Adds the specified interface (and host if included) to the specified
zone.</li>
<li>shorewall delete <i>interface</i>[:<i>host]</i> <i>zone </i>-
Deletes the specified interface (and host if included) from the specified
zone.</li>
<li>shorewall ipcalc [ <i>address mask </i>| <i>address/vlsm</i> ] - displays
the network address, broadcast address, network in CIDR notation and netmask
corresponding to the input[s].</li>
<li>shorewall iprange <i>address1-address2</i> - Decomposes the specified
range of IP addresses into the equivalent list of network/host addresses.
<br>
</li>
</ul>
Finally, the "shorewall" program may be used to dynamically alter the
contents of a zone.<br>
<ul>
<li>shorewall add <i>interface</i>[:<i>host]</i> <i>zone </i>-
Adds the specified interface (and host if included) to the specified zone.</li>
<li>shorewall delete <i>interface</i>[:<i>host]</i> <i>zone
</i>- Deletes the specified interface (and host if included) from
the specified zone.</li>
</ul>
<blockquote>Examples:<br>
<blockquote><font color="#009900"><b>shorewall add ipsec0:192.0.2.24 vpn1</b></font>
<blockquote><font color="#009900"><b>shorewall add ipsec0:192.0.2.24 vpn1</b></font>
-- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1<br>
<font color="#009900"><b> shorewall delete ipsec0:192.0.2.24
vpn1</b></font> -- deletes the address 192.0.2.24 from interface ipsec0
<font color="#009900"><b> shorewall delete ipsec0:192.0.2.24
vpn1</b></font> -- deletes the address 192.0.2.24 from interface ipsec0
from zone vpn1<br>
</blockquote>
</blockquote>
<p> The <b>shorewall start</b>, <b>shorewall restart, shorewall check, </b>and
</blockquote>
</blockquote>
<p> The <b>shorewall start</b>, <b>shorewall restart, shorewall check, </b>and
<b>shorewall try </b>commands allow you to specify which <a
href="configuration_file_basics.htm#Configs"> Shorewall configuration</a>
href="configuration_file_basics.htm#Configs"> Shorewall configuration</a>
to use:</p>
<blockquote>
<blockquote>
<p> shorewall [ -c <i>configuration-directory</i> ] {start|restart|check}<br>
shorewall try <i>configuration-directory</i></p>
</blockquote>
<p> If a <i>configuration-directory</i> is specified, each time that Shorewall
is going to use a file in /etc/shorewall it will first look in the
<i>configuration-directory</i> . If the file is present in the <i>configuration-directory</i>,
that file will be used; otherwise, the file in /etc/shorewall will be
shorewall try <i>configuration-directory</i></p>
</blockquote>
<p> If a <i>configuration-directory</i> is specified, each time that Shorewall
is going to use a file in /etc/shorewall it will first look in the
<i>configuration-directory</i> . If the file is present in the <i>configuration-directory</i>,
that file will be used; otherwise, the file in /etc/shorewall will be
used.</p>
<p> When changing the configuration of a production firewall, I recommend
<p> When changing the configuration of a production firewall, I recommend
the following:</p>
<ul>
<li><font color="#009900"><b>mkdir /etc/test</b></font></li>
<li><font color="#009900"><b>cd /etc/test</b></font></li>
<li>&lt;copy any files that you need to change from
/etc/shorewall to . and change them here&gt;</li>
<li><font color="#009900"><b>shorewall -c . check</b></font></li>
<li>&lt;correct any errors found by check and check again&gt;</li>
<li><font color="#009900"><b>/sbin/shorewall
try .</b></font></li>
<li><font color="#009900"><b>mkdir /etc/test</b></font></li>
<li><font color="#009900"><b>cd /etc/test</b></font></li>
<li>&lt;copy any files that you need to change
from /etc/shorewall to . and change them here&gt;</li>
<li><font color="#009900"><b>shorewall -c . check</b></font></li>
<li>&lt;correct any errors found by check and check again&gt;</li>
<li><font
color="#009900"><b>/sbin/shorewall try .</b></font></li>
</ul>
<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>
<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>
<p> When the new configuration works then just </p>
<ul>
<li><font color="#009900"><b>cp * /etc/shorewall</b></font></li>
<li><font color="#009900"><b>cd</b></font></li>
<li><font color="#009900"><b>rm -rf /etc/test</b></font></li>
<li><font color="#009900"><b>cp * /etc/shorewall</b></font></li>
<li><font color="#009900"><b>cd</b></font></li>
<li><font color="#009900"><b>rm -rf /etc/test</b></font></li>
</ul>
<p><a name="StateDiagram"></a>The Shorewall State Diargram is depicted below.<br>
</p>
</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>
<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>
<br>
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">shorewall start<br>
</td>
<td valign="top">firewall start<br>
</td>
</tr>
<tr>
<td valign="top">shorewall stop<br>
</td>
<td valign="top">firewall stop<br>
</td>
</tr>
<tr>
<td valign="top">shorewall restart<br>
</td>
<td valign="top">firewall restart<br>
</td>
</tr>
<tr>
<td valign="top">shorewall add<br>
</td>
<td valign="top">firewall add<br>
</td>
</tr>
<tr>
<td valign="top">shorewall delete<br>
</td>
<td valign="top">firewall delete<br>
</td>
</tr>
<tr>
<td valign="top">shorewall refresh<br>
</td>
<td valign="top">firewall refresh<br>
</td>
</tr>
<tr>
<td valign="top">shorewall try<br>
</td>
<td valign="top">firewall -c &lt;new configuration&gt; restart<br>
If unsuccessful then firewall start (standard configuration)<br>
If timeout then firewall restart (standard configuration)<br>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td valign="top">shorewall start<br>
</td>
<td valign="top">firewall start<br>
</td>
</tr>
<tr>
<td valign="top">shorewall stop<br>
</td>
<td valign="top">firewall stop<br>
</td>
</tr>
<tr>
<td valign="top">shorewall restart<br>
</td>
<td valign="top">firewall restart<br>
</td>
</tr>
<tr>
<td valign="top">shorewall add<br>
</td>
<td valign="top">firewall add<br>
</td>
</tr>
<tr>
<td valign="top">shorewall delete<br>
</td>
<td valign="top">firewall delete<br>
</td>
</tr>
<tr>
<td valign="top">shorewall refresh<br>
</td>
<td valign="top">firewall refresh<br>
</td>
</tr>
<tr>
<td valign="top">shorewall try<br>
</td>
<td valign="top">firewall -c &lt;new configuration&gt; restart<br>
If unsuccessful then firewall start (standard configuration)<br>
If timeout then firewall restart (standard configuration)<br>
</td>
</tr>
</tbody>
</table>
<br>
<p><font size="2"> Updated 2/27/2003 - <a href="support.htm">Tom Eastep</a>
<br>
<p><font size="2"> Updated 7/6/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
<p><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>
</p>
</p>
<br>
<br>
</body>
</html>

487
Shorewall-docs/support.htm
View File

@ -1,82 +1,84 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Support Guide</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td
width="100%">
<tbody>
<tr>
<td
width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Support Guide<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
</td>
</tr>
</tbody>
</font></h1>
</td>
</tr>
</tbody>
</table>
<h2>Before Reporting a Problem or Asking a Question<br>
</h2>
There
are a number of sources of Shorewall information. Please try
these before you post.
</h2>
There
are a number of sources of Shorewall information. Please try
these before you post.
<ul>
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
<li>Shorewall versions
earlier that 1.3.0 are no longer supported.<br>
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="http://www.shorewall.net/shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has
solutions to more than 20 common problems. </li>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a>
has solutions to more than 20 common problems.
</li>
<li>
The <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to
help you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has
links to download updated components. </li>
<li> The
Site and Mailing List Archives search facility can locate
documents and posts about similar problems: </li>
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li>
The Site and Mailing List Archives search facility can
locate documents and posts about similar problems:
</li>
</ul>
<h2>Site and Mailing List Archive Search</h2>
<blockquote>
<blockquote>
<form method="post"
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
action="http://lists.shorewall.net/cgi-bin/htsearch"> <font size="-1"> Match:
<select name="method">
<option value="and">All </option>
<option value="or">Any </option>
<option value="boolean">Boolean </option>
</select>
Format:
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -85,246 +87,237 @@ links to download updated components. </li>
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font><input type="hidden" name="config"
</font><input type="hidden" name="config"
value="htdig"><input type="hidden" name="restrict" value=""><font
size="-1"> Include Mailing List Archives:
size="-1"> Include Mailing List Archives:
<select size="1" name="exclude">
<option value="">Yes</option>
<option value="[http://lists.shorewall.net/pipermail/.*]">No</option>
</select>
</font><br>
Search: <input type="text" size="30" name="words"
</font><br>
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"><br>
</form>
</blockquote>
</form>
</blockquote>
<h2>Problem Reporting Guidelines<br>
</h2>
</h2>
<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>
<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>
<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>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
<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>
<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>
<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>
<br>
</li>
<li>When reporting a problem,
<strong>ALWAYS</strong> include this information:</li>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall
<li>the exact version of Shorewall
you are running.<br>
<br>
<b><font color="#009900">shorewall
<br>
<b><font color="#009900">shorewall
version</font><br>
</b> <br>
</li>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version
you are running<br>
<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output
of<br>
<br>
<font color="#009900"><b>ip
addr show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output
of<br>
<br>
<font color="#009900"><b>ip
route show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
</ul>
<ul>
<li>the complete, exact output
of<br>
<br>
<font color="#009900"><b>ip
addr show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output
of<br>
<br>
<font color="#009900"><b>ip
route show<br>
</b></font></li>
</ul>
<ul>
</ul>
</ul>
<ul>
<ul>
<li><font color="#ff0000"><u><i><big><b>If you are having
connection problems of any kind then:</b></big></i></u></font><br>
<br>
1. <b><font color="#009900">/sbin/shorewall
reset</font></b><br>
<br>
2. Try the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall
<li><font color="#ff0000"><u><i><big><b>THIS IS IMPORTANT!<br>
<br>
</b></big></i></u></font>If your problem is that some type of connection
to/from or through your firewall isn't working then please:<br>
<br>
1. <b><font color="#009900">/sbin/shorewall reset</font></b><br>
<br>
2. Try making the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall
status &gt; /tmp/status.txt</font></b><br>
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>the exact wording of any <code
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>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using
the Mandrake installation of Shorewall, please say so.<br>
<br>
</b></li>
<br>
</li>
<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.<br>
<br>
</b></li>
</ul>
<li>As a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<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).<br>
<br>
</li>
<li>If an error occurs when you try to
"<font color="#009900"><b>shorewall start</b></font>", include
a trace (See the <a
href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so
don't post GIFs of your network layout,
<li>As a general matter, please <strong>do not edit the diagnostic
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained
in the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<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).<br>
<br>
</li>
<li>If an error occurs when you try to
"<font color="#009900"><b>shorewall start</b></font>", include
a trace (See the <a
href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
section for instructions).<br>
<br>
</li>
<li><b>The list server limits posts to 120kb so
don't post GIFs of your network layout,
etc. to the Mailing List -- your post will be rejected.</b></li>
</ul>
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<em>Olszewski</em> found at <a
<blockquote> The author gratefully acknowleges that the above list was
heavily plagiarized from the excellent LEAF document by <i>Ray</i>
<em>Olszewski</em> found at <a
href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
</blockquote>
</blockquote>
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> 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>
<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>
<br>
<big><font color="#cc0000"><b>If you run your own outgoing mail server
and it doesn't have a valid DNS PTR record, your email won't reach the lists
unless/until the postmaster notices that your posts are being rejected.
To avoid this problem, you should configure your MTA to forward posts to
shorewall.net through an MTA that <u>does</u> have a valid PTR record (such
as the one at your ISP). </b></font></big><br>
</blockquote>
<blockquote> 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>
<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>
<br>
<big><font color="#cc0000"><b>If you run your own outgoing mail server
and it doesn't have a valid DNS PTR record, your email won't reach the lists
unless/until the postmaster notices that your posts are being rejected. To
avoid this problem, you should configure your MTA to forward posts to shorewall.net
through an MTA that <u>does</u> have a valid PTR record (such as the one
at your ISP). </b></font></big><br>
</blockquote>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
style="font-weight: 400;">please post your question or problem
to the <a
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
href="mailto:leaf-user@lists.sourceforge.net">LEAF Users mailing
list</a>.</span></h4>
<b>If you run Shorewall under
MandrakeSoft Multi Network Firewall (MNF) and you have
not purchased an MNF license from MandrakeSoft then you can
<b>If you run Shorewall under
MandrakeSoft Multi Network Firewall (MNF) and you have
not purchased an MNF license from MandrakeSoft then you can
post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list</b>
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a>. <b>Do not expect to get free MNF support on the list</b>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list</a> .</p>
<p> To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.<br>
</p>
</blockquote>
</p>
</blockquote>
<p>For information on other Shorewall mailing lists, go to <a
href="http://lists.shorewall.net">http://lists.shorewall.net</a><br>
</p>
<p align="left"><font size="2">Last Updated 6/24/2003 - Tom Eastep</font></p>
</p>
<p align="left"><font size="2">Last Updated 7/6/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>
</p>
</p>
<br>
<br>
</body>
</html>

763
Shorewall-docs/upgrade_issues.htm
View File

@ -1,447 +1,464 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Upgrade Issues</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p>For upgrade instructions see the <a
href="Install.htm">Install/Upgrade page</a>.<br>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you
are currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
be a host address) accessed through a particular interface.<br>
</p>
</p>
<p>It is important that you read all of the sections on this page where the
version number mentioned in the section title is later than what you
are currently running.<br>
</p>
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
be a host address) accessed through a particular interface.<br>
</p>
<p>Examples:<br>
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
    <br>
    eth0:0.0.0.0/0<br>
    eth2:192.168.1.0/24<br>
    eth3:192.0.2.123<br>
</p>
<p> You can use the "shorewall check" command to see the groups associated
with each of your zones.<br>
</p>
</p>
<h3> </h3>
<h3>Version &gt;= 1.4.6</h3>
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed from
shorewall.conf. These capabilities are now automatically detected by Shorewall.<br>
<h3>Version &gt;= 1.4.4</h3>
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then you
must set the new LOGFORMAT variable appropriately and remove your setting
of LOGMARKER<br>
<br>
<ul>
<li> The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
from shorewall.conf. These capabilities are now automatically detected by
Shorewall.</li>
<li>An undocumented <i>feature</i> previously allowed entries in the host
file as follows:<br>
<br>
<i>zone</i>    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
<i>zone</i>   eth1:192.168.1.0/24,192.168.2.0/24<br>
</li>
</ul>
<h3>Version &gt;= 1.4.4</h3>
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
you must set the new LOGFORMAT variable appropriately and remove your setting
of LOGMARKER<br>
<br>
<h3>Version 1.4.4<br>
</h3>
If you have zone names that are 5 characters long, you may experience problems
starting Shorewall because the --log-prefix in a logging rule is too long.
Upgrade to Version 1.4.4a to fix this problem..<br>
</h3>
If you have zone names that are 5 characters long, you may experience problems
starting Shorewall because the --log-prefix in a logging rule is too long.
Upgrade to Version 1.4.4a to fix this problem..<br>
<h3>Version &gt;= 1.4.2</h3>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
There are some cases where you may want to handle traffic from a particular
group to itself. While I personally think that such a setups are ridiculous,
there are two cases covered in this documentation where it can occur:<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a
transparent proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current
documentation and change your configuration accordingly.<br>
If you have either of these cases, you will want to review the current
documentation and change your configuration accordingly.<br>
<h3>Version &gt;= 1.4.1</h3>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the
same zone is accepted by default. Previously, traffic from a zone to
itself was treated just like any other traffic; any matching rules were
applied followed by enforcement of the appropriate policy. With 1.4.1
and later versions, unless you have explicit rules for traffic from Z
to Z or you have an explicit Z to Z policy (where "Z" is some zone) then
traffic between the groups in zone Z will be accepted. If you do have one
or more explicit rules for Z to Z or if you have an explicit Z to Z policy
then the behavior is as it was in prior versions.</li>
<li>Beginning with Version 1.4.1, traffic between groups in the
same zone is accepted by default. Previously, traffic from a zone to itself
was treated just like any other traffic; any matching rules were applied
followed by enforcement of the appropriate policy. With 1.4.1 and later
versions, unless you have explicit rules for traffic from Z to Z or you
have an explicit Z to Z policy (where "Z" is some zone) then traffic between
the groups in zone Z will be accepted. If you do have one or more explicit
rules for Z to Z or if you have an explicit Z to Z policy then the behavior
is as it was in prior versions.</li>
</ul>
<blockquote>
<blockquote>
<ol>
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
<li>If you have a Z Z ACCEPT policy for a zone to allow traffic
between two interfaces to the same zone, that policy can be removed and
traffic between the interfaces will traverse fewer rules than previously.</li>
<li>If you have a Z Z DROP or Z Z REJECT policy or you have
<li>If you have a Z Z DROP or Z Z REJECT policy or you have
Z-&gt;Z rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent traffic
between two interfaces to a zone Z and you have no rules for Z-&gt;Z then
you should add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
<li>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent traffic
between two interfaces to a zone Z and you have no rules for Z-&gt;Z
then you should add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
</blockquote>
</blockquote>
<ul>
<li> Sometimes, you want two separate zones on one interface but
you don't want Shorewall to set up any infrastructure to handle traffic
between them. </li>
<li> Sometimes, you want two separate zones on one interface but
you don't want Shorewall to set up any infrastructure to handle traffic
between them. </li>
</ul>
<blockquote>Example:<br>
<blockquote>
<blockquote>
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going
to be involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to
</blockquote>
Here, zone z1 is nested in zone z2 and the firewall is not going
to be involved in any traffic between these two zones. Beginning with Shorewall
1.4.1, you can prevent Shorewall from setting up any infrastructure to
handle traffic between z1 and z2 by using the new NONE policy:<br>
<blockquote>
<blockquote>
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
</blockquote>
Note that NONE policies are generally used in pairs unless there
is asymetric routing where only the traffic on one direction flows through
the firewall and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between
two subnetworks on the same interface then I recommend that you upgrade
to Version 1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the
iproute package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface
options are no longer supported nor is the <b>FORWARDPING </b>option
in shorewall.conf. ICMP echo-request (ping) packets are treated just
like any other connection request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when
there are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and
hosts file has been eliminated; use entries in the routestopped file
instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
is no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf
is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped
by default; there is no need for your own /etc/shorewall/common file
simply to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version'
file have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you
include it from /etc/shorewall/icmpdef, you will need to modify that
file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same
interface that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to
or from the destination zone. An explicit policy names both zones and
does not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same
then the rule must be explicit - it must name the zone in both the SOURCE
and DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
     Beginning in version 1.3.14, Shorewall treats entries
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
Note that NONE policies are generally used in pairs unless there
is asymetric routing where only the traffic on one direction flows through
the firewall and you are using a NONE polciy in the other direction. </blockquote>
<h3>Version 1.4.1<br>
</h3>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST
subnet on the interface (as shown by "ip addr show <i>interface</i>")
and would masquerade traffic from that subnet. Any other subnets that
routed through eth1 needed their own entry in /etc/shorewall/masq to
be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the
firewall's routing table to determine ALL subnets routed through the
named interface. Traffic originating in ANY of those subnets is masqueraded
or has SNAT applied.</li>
<li>In Version 1.4.1, Shorewall will never create rules to
deal with traffic from a given group back to itself. The <i>multi</i>
interface option is no longer available so if you want to route traffic
between two subnetworks on the same interface then I recommend that you
upgrade to Version 1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq
with an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- 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<br> [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>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is
like this?<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 <br> [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>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<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>
<h3>Version &gt;= 1.4.0</h3>
<b>IMPORTANT: Shorewall &gt;=1.4.0 </b><b>requires</b> <b>the
iproute package ('ip' utility).</b><br>
<br>
<b>Note: </b>Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
<br>
     error: failed dependencies:iproute is needed by shorewall-1.4.0-1
<br>
<br>
This may be worked around by using the --nodeps option of rpm
(rpm -Uvh --nodeps &lt;shorewall rpm&gt;).<br>
<br>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface
options are no longer supported nor is the <b>FORWARDPING </b>option
in shorewall.conf. ICMP echo-request (ping) packets are treated just
like any other connection request and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate a Shorewall error at startup
(they always have produced warnings in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
contents are determined by BOTH the interfaces and hosts files when
there are entries for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and
hosts file has been eliminated; use entries in the routestopped file
instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
is no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped
by default; there is no need for your own /etc/shorewall/common file
simply to avoid logging these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version'
file have been moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you
include it from /etc/shorewall/icmpdef, you will need to modify that
file.</li>
<ul>
</ul>
<li>If you followed the advice in FAQ #2 and call find_interface_address
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
</li>
</ul>
<ul>
</ul>
<h3>Version 1.4.0</h3>
<ul>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same
interface that they arrived on in two cases:</li>
</ul>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone
to or from the destination zone. An explicit policy names both zones
and does not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source
zone to or from the destination zone including rules that use the 'all'
reserved word. Exception: if the source zone and destination zone are
the same then the rule must be explicit - it must name the zone in both
the SOURCE and DESTINATION columns.</li>
</ul>
</blockquote>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the
old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now
upgrading to version 1.3.10, you will need to use the '--force' option:<br>
     Beginning in version 1.3.14, Shorewall treats entries
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
The change involves entries with an <b>interface name</b> in the
<b>SUBNET</b> (second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST
subnet on the interface (as shown by "ip addr show <i>interface</i>")
and would masquerade traffic from that subnet. Any other subnets that
routed through eth1 needed their own entry in /etc/shorewall/masq
to be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses
the firewall's routing table to determine ALL subnets routed through
the named interface. Traffic originating in ANY of those subnets
is masqueraded or has SNAT applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq
with an interface name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
 <b>Example 1</b> -- 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<br> [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>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration
is like this?<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 <br> [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>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13"
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to
be used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting
the old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now
upgrading to version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file,
your application will need to be changed to reflect this change of
location.<br>
<h3>Version &gt;= 1.3.8</h3>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<p>If you have a pair of firewall systems configured for failover
or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall
versions &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this
file if necessary):</p>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following
rules in their /etc/shorewall/icmpdef file (creating this
file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall &gt;= 1.3.3</b></h3>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering
floppy with the later one. If you did
not obtain the later version from Jacques's site, see additional
instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget
to backup root.lrp !</li>
<li>Be sure you
have a backup -- you will need
to transcribe any Shorewall configuration
changes that you have made to the new
configuration.</li>
<li>Replace the
shorwall.lrp package provided on
the Bering floppy with the later one. If you did
not obtain the later version from Jacques's
site, see additional instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not
forget to backup root.lrp !</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a
href="two-interface.htm">instructions for setting up a two-interface
firewall</a> plus you also need to add the following two Bering-specific
rules to /etc/shorewall/rules:</p>
<blockquote>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a
href="two-interface.htm">instructions for setting up a two-interface
firewall</a> plus you also need to add the following two Bering-specific
rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    #
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn
-j RETURN # So that the connection tracking table can
be rebuilt<br>
                                    #
from non-SYN packets after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept
Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept
Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those
applications should be modified accordingly.</p>
<p><font size="2"> Last updated 6/29/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, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<p align="left">The functions and versions files together with the 'firewall'
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those
applications should be modified accordingly.</p>
<p><font size="2"> Last updated 6/29/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, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

2
Shorewall/fallback.sh
View File

@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{

2
Shorewall/install.sh
View File

@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{

4
Shorewall/shorewall.spec
View File

@ -1,6 +1,6 @@
%define name shorewall
%define version 1.4.6
%define release 0Beta1
%define release 0Beta2
%define prefix /usr
Summary: Shoreline Firewall is an iptables-based firewall for Linux systems.
@ -105,6 +105,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Mon Jul 07 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.6-0Beta2
* Fri Jul 04 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.6-0Beta1
* Tue Jun 17 2003 Tom Eastep <tom@shorewall.net>

2
Shorewall/uninstall.sh
View File

@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{