<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
  <head>
    <meta name="generator" content=
    "HTML Tidy for Linux (vers 1st April 2002), see www.w3.org">

    <title> Old News </title>
  </head>

  <body>
  <span style="font-weight: bold;">10/05/2005
Shorewall 2.4.5<br>
</span>
<br>
Problems Corrected in 2.4.5<br>
<ol>
  <li>In previous versions, when the command is 'start', 'restart' or
'stop' then OUTPUT traffic to hosts listed in
/etc/shorewall/routestopped is not enabled if ADMINISABSENTMINDED=Yes.
That traffic is now enabled independent of the setting of
ADMINISABSENTMINDED.</li>
  <li>Although it was documented that icmp types could be used in the
tcrules file, the code did not support it. Thanks to Jorge Molina, that
problem is now corrected.</li>
  <li>In a multi-ISP configuration, fwmark routing rules now have a
higher priority than source IP rules. This allows entries in tcrules to
be more effective in controlling routing.</li>
  <li>Previously, not all of the mangle chains were flushed during
"shorewall restart".</li>
</ol>
<span style="font-weight: bold;">09/12/2005 Shorewall 2.4.4<br>
</span><br>
Problems Corrected<br>
<ol>
  <li>An incorrect comment in the /etc/shorewall/proxyarp file has been
removed.</li>
  <li>The message generated when a duplicate policy has been entered is
now more informative. Previously, only the POLICY column contents
appeared in the message. Now the SOURCE, DEST and POLICY column
contents are shown.</li>
  <li>Shorewall now clears the Netfilter "raw" table during "shorewall
[re]start", "shorewall stop" and "shorewall clear" processing.</li>
</ol>
New Features<br>
<ol>
  <li>Tunnel types "openvpnserver" and "openvpnclient" have been added
to reflect the introduction of client and server OpenVPN configurations
in OpenVPN 2.0.</li>
  <li>The COMMAND variable is now set to 'restore' in restore scripts.
The value of this variable is sometimes of interest to programmers
providing custom /etc/shorewall/tcstart scripts.<br>
  </li>
</ol>
<span style="font-weight: bold;">08/16/2005 Shorewall 2.4.3<br>
</span><br>
Problems Corrected:<br>
<ol>
  <li>Shorewall is no longer dependent on the 'which' utility.</li>
  <li>The 'shorewall add' command failed if there existed a zone in the
configuration that specified the 'ipsec' option in /etc/shorewall/hosts.</li>
  <li>Shorewall is no longer dependent on /bin/echo.</li>
  <li>A CLASSIFY rule&nbsp; with $FW in the SOURCE column (tcrules) no
longer results in a "shorewall start" error.</li>
  <li>You may now use port lists in the DEST PORT and SOURCE PORT
columns of the /etc/shorewall/accounting file.</li>
  <li>The "shorewall show capabilities" command now accurately reports
the availability of "Packet type match" independent of the setting of
PKTTYPE in shorewall.conf.</li>
  <li>Thanks to Tuomo Soini, all of the files have been siginificantly
cleaned up in terms of formatting and extra white-space.<br>
  </li>
</ol>
New Features:<br>
<ol>
  <li>New Allow.Submission and Allow.NTPbrd actions have been added.
Users of the Allow.NTP action that use NTP broadcasting should switch
to use of Allow.NTPbrd instead.</li>
  <li>The kernel version string is now included in the output of
"shorewall status".<br>
  </li>
</ol>
<span style="font-weight: bold;">07/30/2005 Shorewall 2.2.6<br>
<br>
</span>Problems Corrected:<br>
<ol>
  <li><a href="#20050717">MACLIST_TTL Vulnerability</a> fix.</li>
  <li>TCP_FLAGS_LOG_LEVEL=ULOG breaks with recent versions of iptables.</li>
  <li>The bogons file has been updated to reflect recent IANA
allocations.</li>
</ol>
<span style="font-weight: bold;">07/21/2005 Shorewall 2.4.2<br>
<br>
</span>Problems Corrected:<br>
<ol>
  <li>The /etc/shorewall/hosts file now includes information about
defining a zone using one or more ipsets.</li>
  <li>A <a href="#20050717">vulnerability involving MACLIST_TTL &gt; 0
or MACLIST_DISPOSITION=ACCEPT</a> has been corrected.</li>
  <li>It is now possible to specify !&lt;address&gt; in the SUBNET
column of /etc/shorewall/masq. Previously, it was necessary to write
0.0.0.0/0!&lt;address&gt;.</li>
  <li>When &lt;network1&gt;!&lt;network2&gt; was specified in the
SUBNET column of /etc/shorewall/masq, IPSEC policies were not correctly
applied to the resulting rules. This usually resulted in IPSEC not
working through the interface specified in the INTERFACES column.<br>
  </li>
</ol>
New Features:<br>
<ol>
  <li> A 'loose' provider option has been added. If you wish to be able
to use marking to specify the gateway used by connections originating
on the firewall itself, the specify 'loose' for each provider. It has
bee reported that 'loose' may break the effect of 'track' so beware if
you need 'track' functionality (you shouldn't be originating many
connections from your firewall to the net anyway).<br>
    <br>
To use 'loose', you also need to add two entries in /etc/shorewall/masq:<br>
    <pre><span style="font-family: monospace;">#INTERFACE           SUBNET          ADDRESS<br>
   $IF_ISP1             $IP_ISP2        $IP_ISP1<br>
   $IF_ISP2             $IP_ISP1        $IP_ISP2</span>
    </pre>
where:<br>
    <pre>        $IF_ISP1        is the interface to ISP 1.<br>
        $IF_ISP2        is the interface to ISP 2.<br>
        $IP_ISP1        is the IP address of $IF_ISP1<br>
        $IP_ISP2        is the IP address of $IF_ISP2
    </pre>
  </li>
  <li>/sbin/shorewall now issues a warning each time that it finds that
startup is disabled.</li>
  <li>A new COPY column has been added to the /etc/shorewall/providers
file. Normally, when a table name/number is given in the DUPLICATE
column, the entire table (less default routes) is copied. The COPY
column allows you to limit the routes copied to those that go through
an interface listed in COPY. For example, if you enter eth0 in
INTERFACE, "eth1,eth2" in COPY and 'main' in DUPLICATE then the new
table created will contain those routes through the interfaces eth0,
eth1 and eth2.<br>
  </li>
</ol>
<hr style="width: 100%; height: 2px;">
<h2><a name="20050717"></a><font color="#ff0000">07/17/2005 Security
vulnerability in MACLIST processing</font></h2>
<h3>Description</h3>
<p>A security vulnerability has been discovered which affects all
supported stable versions of Shorewall.&nbsp; This vulnerability
enables a client accepted by MAC address filtering to bypass any other
rule.&nbsp; If MACLIST_TTL is set to a value greater than 0 or
MACLIST_DISPOSITION is set to "ACCEPT" in /etc/shorewall/shorewall.conf
(default is MACLIST_TTL=0 and MACLIST_DISPOSITION=REJECT), and a client
is positively identified through its MAC address, it bypasses all other
policies/rules in place, thus gaining access to all open services on
the firewall.</p>
<h3>Fix</h3>
<h4>Workaround</h4>
<p>For Shorewall 2.2.x or 2.4.x, set MACLIST_TTL=0 or
MACLIST_DISPOSITION=REJECT in /etc/shorewall/shorewall.conf.&nbsp; For
Shorewall 2.0.x, set MACLIST_DISPOSITION=REJECT in
/etc/shorewall/shorewall.conf.&nbsp; MACLIST filtering is of limited
value on Internet-connected hosts, and the Shorewall team recommends
this approach to be used if possible.</p>
<h4>Upgrade</h4>
<p>For Shorewall 2.4.x, a fixed version of the 'firewall' script is
available at: <a
 href="http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
http://shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
and its mirrors, <a
 href="http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
http://www.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>
and <a
 href="http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall">
http://slovakia.shorewall.net/pub/shorewall/2.4/shorewall-2.4.1/errata/firewall</a>.</p>
<p>For Shorewall 2.2.x, a fixed version of the 'firewall' script is
available at: <a
 href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
and its mirrors, <a
 href="http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
http://www.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>
and <a
 href="http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall">
http://slovakia.shorewall.net/pub/shorewall/2.2/shorewall-2.2.5/errata/firewall</a>.</p>
<p>For Shorewall 2.0.x, a fixed version of the 'firewall' script is
available at: <a
 href="http://shorewall.net/pub/shorewall/errata/2.0.17/firewall">http://shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>
and its mirrors, <a
 href="http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
http://www.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a> and <a
 href="http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall">
http://slovakia.shorewall.net/pub/shorewall/errata/2.0.17/firewall</a>.</p>
<p>Users of any version before 2.0.17 are urged to upgrade to a
supported version of Shorewall (preferably 2.4.1) before using the
fixed files.&nbsp; Only the most recent version of the 2.0.x and 2.2.x
streams will be supported by the development team, and the 1.x branches
are no longer maintained at all.&nbsp; Future releases of Shorewall
will include this fix.</p>
<p>This information was based on <a
 href="http://seclists.org/lists/fulldisclosure/2005/Jul/0409.html">Patrick
Blitz's post to the Full Disclosure mailing list</a>.&nbsp; Thanks to
Supernaut (supernaut at ns dot sympatico dot ca) for reporting this bug.<br>
</p>
<p><span style="font-weight: bold;">Version Upgrade<br>
</span></p>
<p>The vulnerability is corrected in Shorewall 2.4.2 and in Shorewall
2.2.6.<br>
</p>
<hr style="width: 100%; height: 2px;"> <span style="font-weight: bold;">07/13/2005
Shorewall 2.4.1<br>
</span><br>
Problems Corrected:<br>
<ol>
  <li>Shell variables may now be used in the zones file.</li>
  <li>The /usr/share/shorewall/bogons file has been updated to reflect
recent IANA allocations.</li>
  <li>Shorewall now detects an error where multiple providers specify
the 'track' option on the same interface.</li>
  <li>The remnants of the GATEWAY column in /etc/shorewall/interfaces
have been removed. This column appeared briefly in one of the Beta
versions and was immediately removed but some vestiges remained.</li>
  <li>Shorewall now correctly restores a load-balancing default route
during processing of the 'shorewall restore' and 'shorewall -f start'
commands. The latter command is normally executed by the Shorewall init
script during reboot.</li>
  <li>A log level of "None!" is now allowed on builtin actions such as
ACCEPT and DROP.</li>
  <li>Previously, LIMIT:BURST parameters in /etc/shorewall/policy were
not correctly applied when the policy was QUEUE.</li>
  <li>The 'chkconfig' command on FC4 and Mandriva previously created
symbolic links with incorrect names ("S-1shorewall"). The init script
has been changed to prevent this incorrect behavior.</li>
  <li>DHCP traffic forwarded through a bridge could, under some
configurations, be filtered by the 'maclist' option even though the
'dhcp' option was specified. This has been corrected.<br>
  </li>
</ol>
<span style="font-weight: bold;">06/05/2005 Shorewall 2.4.0<br>
<br>
Note:</span> Because of the short time that has elapsed since the
release of Shorewall 2.2.0, Shorewall 2.0 will be supported until 1
December 2005 or until the release of Shorewall 2.6.0, whichever occurs
first.<br>
<br>
New Features:<br>
<ol>
  <li>Shorewall 2.4.0 includes support for multiple internet interfaces
to different ISPs.<br>
    <br>
The file /etc/shorewall/providers may be used to define the different
providers. It can actually be used to define alternate routing tables
so uses like transparent proxy can use the file as well.<br>
    <br>
Columns are:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The provider name.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
NUMBER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The
provider number -- a number between 1 and 15</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MARK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
A FWMARK value used in your /etc/shorewall/tcrules file to direct
packets for this provider.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DUPLICATE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The name of an existing
table to duplicate. May</span> <span style="font-family: monospace;">be
'main' or the name of a previous provider.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The name of the network
interface to the</span> <span style="font-family: monospace;">provider.
Must be listed in</span><span style="font-family: monospace;">/etc/shorewall/interfaces.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The IP address
of the provider's gateway router.</span> <span
 style="font-family: monospace;">If you enter "detect" here then
Shorewall<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
will</span> <span style="font-family: monospace;">attempt to determine
the gateway IP address</span> <span style="font-family: monospace;">automatically.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OPTIONS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A
comma-separated list selected from the</span> <span
 style="font-family: monospace;">following:</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
track&nbsp;&nbsp; If specified, connections FROM this interface are</span>
    <span style="font-family: monospace;">to be tracked so that
responses may be<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
routed</span> <span style="font-family: monospace;">back out this same
interface.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
You want specify 'track' if internet hosts will be</span> <span
 style="font-family: monospace;">connecting to local servers through<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
this</span> <span style="font-family: monospace;">provider.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Because of limitations in the 'ip' utility and</span> <span
 style="font-family: monospace;">policy routing, you may not use the
SAVE or</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
RESTORE tcrules options or use connection</span><span
 style="font-family: monospace;">marking on any traffic to or from this</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
interface. For traffic control purposes, you</span> <span
 style="font-family: monospace;">must mark packets in the FORWARD chain
(or</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
better yet, use the CLASSIFY target).</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
balance The providers that have 'balance' specified will</span> <span
 style="font-family: monospace;">get outbound traffic load-balanced
among<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
them. By</span> <span style="font-family: monospace;">default, all
interfaces with 'balance' specified</span> <span
 style="font-family: monospace;">will have the same weight (1).<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
You can change the</span><span style="font-family: monospace;">weight
of the route out of the interface by</span> <span
 style="font-family: monospace;">specifiying balance=&lt;weight&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
where &lt;weight&gt; is</span><span style="font-family: monospace;">the
desired route weight.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example:&nbsp; You run squid in
your DMZ on IP address 192.168.2.99. Your DMZ interface is eth2<br>
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#NAME&nbsp;&nbsp; NUMBER&nbsp; MARK DUPLICATE&nbsp; INTERFACE
GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Squid&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1&nbsp;&nbsp;&nbsp;
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
eth2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.99&nbsp; -</span><br>
    <br>
Use of this feature requires that your kernel and iptabls support
CONNMARK target and conntrack match support. It does NOT require the
ROUTE target extension.<br>
    <br>
WARNING: The current version of iptables (1.3.1) is broken with respect
to CONNMARK and iptables-save/iptables-restore. This means that if you
configure multiple ISPs, "shorewall restore" may fail. You must patch
your iptables using the patch at <a
 href="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">
http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</a>.<br>
    <br>
  </li>
  <li>Shorewall 2.3.0 supports the 'cmd-owner' option of the owner
match facility in Netfilter. Like all owner match options, 'cmd-owner'
may only be applied to traffic that originates on the firewall.<br>
    <br>
The syntax of the USER/GROUP column in the following files has been
extended:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/accounting<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/rules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /etc/shorewall/tcrules<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/usr/share/shorewall/action.template<br>
    <br>
To specify a command, prefix the command name with "+".<br>
    <br>
&nbsp;&nbsp; Examples:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+mozilla-bin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#The program is named "mozilla-bin"</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
joe+mozilla-bin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; #The
program is named "mozilla-bin" and</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#is being run by user "joe"</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
joe:users+mozilla-bin&nbsp;&nbsp; #The program is named "mozilla-bin"
and</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#is being run by user "joe" with</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#effective group "users".</span><br style="font-family: monospace;">
    <br>
&nbsp;&nbsp; Note that this is not a particularly robust feature and I
would never advertise it as a "Personal Firewall" equivalent. Using
symbolic links, it's easy to alias command names to be anything you
want.<br>
    <br>
  </li>
  <li>Support has been added for ipsets (see <a
 href="http://people.netfilter.org/kadlec/ipset/">http://people.netfilter.org/kadlec/ipset/</a>).<br>
    <br>
In most places where a host or network address may be used, you may
also use the name of an ipset prefaced by "+".<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example: "+Mirrors"<br>
    <br>
The name of the set may be optionally followed by:<br>
    <br>
a) a number from 1 to 6 enclosed in square brackets ([]) -- this number
indicates the maximum number of ipset binding levels that are to be
matched. Depending on the context where the ipset name is used, either
all "src" or all "dst" matches will be used.<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example: "+Mirrors[4]"<br>
    <br>
b) a series of "src" and "dst" options separated by commas and inclosed
in square brackets ([]). These will be passed directly to iptables in
the generated --set clause. See the ipset documentation for details.<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Example:
"+Mirrors[src,dst,src]"<br>
    <br>
Note that "+Mirrors[4]" used in the SOURCE column of the rules file is
equivalent to "+Mirrors[src,src,src,src]".<br>
    <br>
To generate a negative match, prefix the "+" with "!" as in "!+Mirrors".<br>
    <br>
Example 1: Blacklist all hosts in an ipset named "blacklist"<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/etc/shorewall/blacklist<br>
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#ADDRESS/SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PROTOCOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PORT</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+blacklist</span><br style="font-family: monospace;">
    <br>
Example 2: Allow SSH from all hosts in an ipset named "sshok:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/etc/shorewall/rules<br>
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#ACTION&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST&nbsp;&nbsp;&nbsp;&nbsp;
PROTO&nbsp;&nbsp;&nbsp; DEST PORT(S)</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+sshok&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
fw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tcp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 22</span><br
 style="font-family: monospace;">
    <br>
Shorewall can automatically capture the contents of your ipsets for
you. If you specify SAVE_IPSETS=Yes in /etc/shorewall/shorewall.conf
then "shorewall save" will save the contents of your ipsets. The file
where the sets are saved is formed by taking the name where the
Shorewall configuration is stored and appending "-ipsets". So if you
enter the command "shorewall save standard" then your Shorewall
configuration will be saved in var/lib/shorewall/standard and your
ipset contents will be saved in /var/lib/shorewall/standard-ipsets.
Assuming the default RESTOREFILE setting, if you just enter "shorewall
save" then your Shorewall configuration will be saved in
/var/lib/shorewall/restore and your ipset contents will be saved in
/var/lib/shorewall/restore-ipsets.<br>
    <br>
Regardless of the setting of SAVE_IPSETS, the "shorewall -f start" and
"shorewall restore" commands will restore the ipset contents
corresponding to the Shorewall configuration restored provided that the
saved Shorewall configuration specified exists.<br>
    <br>
For example, "shorewall restore standard" would restore the ipset
contents from /var/lib/shorewall/standard-ipsets provided that
/var/lib/shorewall/standard exists and is executable and that
/var/lib/shorewall/standard-ipsets exists and is executable.<br>
    <br>
Also regardless of the setting of SAVE_IPSETS, the "shorewall forget"
command will purge the saved ipset information (if any) associated with
the saved shorewall configuration being removed.<br>
    <br>
You can also associate ipset contents with Shorewall configuration
directories using the following command:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -S &gt; &lt;config
directory&gt;/ipsets<br>
    <br>
Example:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -S &gt; /etc/shorewall/ipsets<br>
    <br>
When you start or restart Shorewall (including using the 'try' command)
from the configuration directory, your ipsets will be configured from
the saved ipsets file. Once again, this behavior is independent of the
setting of SAVE_IPSETS.<br>
    <br>
Ipsets are well suited for large blacklists. You can maintain your
blacklist using the 'ipset' utility without ever having to restart or
refresh Shorewall. If you use the SAVE_IPSETS=Yes feature just be sure
to "shorewall save" after altering the blacklist ipset(s).<br>
    <br>
Example /etc/shorewall/blacklist:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;
#ADDRESS/SUBNET&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PROTOCOL&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PORT</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
+Blacklist[src,dst]</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;
+Blacklistnets[src,dst]</span><br style="font-family: monospace;">
    <br>
Create the blacklist ipsets using:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N
Blacklist iphash<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N
Blacklistnets nethash<br>
    <br>
Add entries<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklist 206.124.146.177<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklistnets
206.124.146.0/24<br>
    <br>
To allow entries for individual ports<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -N SMTP portmap --from 1
--to 31<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A SMTP 25<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -A Blacklist 206.124.146.177<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipset -B Blacklist 206.124.146.177
-b SMTP<br>
    <br>
Now only port 25 will be blocked from 206.124.146.177.<br>
    <br>
  </li>
  <li>Shorewall 2.4.0 can now configure routing if your kernel and
iptables support the ROUTE target extension. This extension is
available in Patch-O-Matic-ng. This feature is *EXPERIMENTAL* since the
Netfilter team have no intention of ever releasing the ROUTE target
extension to kernel.org.<br>
    <br>
Routing is configured using the /etc/shorewall/routes file. Columns in
the file are as follows:<br>
    <br>
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Source of the packet. May be any of the</span> <span
 style="font-family: monospace;">following:</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A host or network address</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A network interface name.</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- The name of an ipset prefaced with "+"</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- $FW (for packets originating on the firewall)</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A MAC address in Shorewall format</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A range of IP addresses (assuming that your</span> <span
 style="font-family: monospace;">kernel and iptables support range
match)</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A network interface name followed by ":"</span> <span
 style="font-family: monospace;">and an address or address range.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Destination of the packet. May be any of the</span> <span
 style="font-family: monospace;">following:</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A host or network address</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A network interface name (determined from</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
routing table(s))</span><br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- The name of an ipset prefaced with "+"</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- A network interface name followed by ":"</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and an address or address range.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PROTO&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol - Must be "tcp", "udp", "icmp",</span> <span
 style="font-family: monospace;">"ipp2p", a number, or "all". "ipp2p"
requires</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ipp2p match support in your kernel and</span><span
 style="font-family: monospace;">iptables.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PORT(S)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Destination
Ports. A comma-separated list of</span> <span
 style="font-family: monospace;">Port names (from /etc/services), port<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
numbers</span> <span style="font-family: monospace;">or port ranges;
if the protocol is "icmp", this</span><span
 style="font-family: monospace;">column is interpreted as the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
destination</span> <span style="font-family: monospace;">icmp-type(s).</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If the protocol is ipp2p, this column is</span> <span
 style="font-family: monospace;">interpreted as an ipp2p option without
the</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
leading "--" (example "bit" for bit-torrent).</span> <span
 style="font-family: monospace;">If no PORT is given, "ipp2p" is
assumed.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
This column is ignored if PROTOCOL = all but</span> <span
 style="font-family: monospace;">must be entered if any of the following<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
field</span> <span style="font-family: monospace;">is supplied. In
that case, it is suggested that</span> <span
 style="font-family: monospace;">this field contain "-"</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SOURCE PORT(S)&nbsp; (Optional) Source port(s). If omitted,</span> <span
 style="font-family: monospace;">any source port is acceptable.
Specified as a</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
comma-separated list of port names, port</span> <span
 style="font-family: monospace;">numbers or port ranges.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Defines a test on the existing packet or</span> <span
 style="font-family: monospace;">connection mark.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The rule will match only if the test returns</span> <span
 style="font-family: monospace;">true. Tests have the format</span><span
 style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[!]&lt;value&gt;[/&lt;mask&gt;][:C]</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Where:</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inverts the test (not equal)</span>
    <span style="font-family: monospace;">&lt;value&gt; Value of the
packet or</span><span style="font-family: monospace;"><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
connection mark.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;mask&gt;&nbsp; A mask to be applied to the</span> <span
 style="font-family: monospace;">mark before testing</span><br
 style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Designates a connection</span> <span
 style="font-family: monospace;">mark. If omitted, the packet</span> <span
 style="font-family: monospace;">mark's value<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is tested.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
INTERFACE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The interface that the
packet is to be routed</span> <span style="font-family: monospace;">out
of. If you do not specify this<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
field then</span> <span style="font-family: monospace;">you must place
"-" in this column and enter an</span> <span
 style="font-family: monospace;">IP address in the GATEWAY<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
column.</span><br style="font-family: monospace;">
    <br style="font-family: monospace;">
    <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
GATEWAY&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The gateway
that the packet is to be forewarded</span> <span
 style="font-family: monospace;">through.</span><br
 style="font-family: monospace;">
    <br style="font-family: monospace;">
  </li>
  <li>Normally when Shorewall is stopped, starting or restarting then
connections are allowed from hosts listed in
/etc/shorewall/routestopped to the firewall and to other hosts listed
in /etc/shorewall/routestopped.<br>
    <br>
A new 'source' option is added for entries in that file which will
cause Shorewall to allow traffic from the host listed in the entry to
ANY other host. When 'source' is specified in an entry, it is
unnecessary to also specify 'routeback'.<br>
    <br>
Similarly, a new 'dest' option is added which will cause Shorewall to
allow traffic to the host listed in the entry from ANY other host. When
'source' is specified in an entry, it is unnecessary to also specify
'routeback'.<br>
    <br>
  </li>
  <li>This change was implemented by Lorenzo Martignoni. It provides
two new commands: "safe-start" and "safe-restart".<br>
    <br>
    <span style="font-weight: bold;">safe-start</span> starts Shorewall
then prompts you to ask you if everything looks ok. If you answer "no"
or if you don't answer within 60 seconds, a "shorewall clear" is
executed.<br>
    <br>
    <span style="font-weight: bold;">safe-restart</span> saves your
current configuration to /var/lib/shorewall/safe-restart then issues a
"shorewall restart"; It then prompts you to ask if you if you want to
accept the new configuration. If you answer "no" or if you don't answer
within 60 seconds, the configuration is restored to its prior state.<br>
    <br>
These new commands require either that your /bin/sh supports the "-t"
option to the 'read' command or that you have /bin/bash installed.<br>
  </li>
</ol>
    <span style="font-weight: bold;">05/20/2005&nbsp; Shorewall CVS
    Repository has Moved to Sourceforge<br>
    <br>
    </span> The CVS repository may now be accessed at <a target=
    "_top" href=
    "http://sourceforge.net/cvs/?group_id=22587">http://sourceforge.net/cvs/?group_id=22587</a>.<br>

     <span style="font-weight: bold;"><br>
     05/20/2005 Shorewall 2.2.5<br>
    <br>
    </span> This will be my last 2.2 release. It contains a couple
    of small bug fixes that I hadn't yet released.<br>
     <br>
     -Tom<br>
     <br>
     Problems Corrected:<br>


    <ol>
      <li>Previously, if PKTTYPE=No in shorewall.conf then pkttype
      match would still be used if the kernel supported it.</li>

      <li>A typo in the 'tunnel' script has been corrected (Thanks
      to Patrik Varmecký).</li>

      <li>A warning is now generated if an invalid short zone name
      is used in /etc/shorewall/zones.<br>
      </li>
    </ol>
    <span style="font-weight: bold;">05/18/2005 Tom stepping away
    from Shorewall development and support<br>
    </span> <br>
     It is with regret that I announce that my involvement in
    Shorewall development and support is officially ending.<br>
     <br>
     Unlike the originators of other successful open source
    projects, I have not been able to attract a core of people who
    believe in Shorewall and who are willing to make sacrifices to
    ensure it's success. That is my weakness and I accept it. But
    is means that I have been left with trying to develop,
    document, and support Shorewall almost single-handedly. I
    cannot do it any more.<br>
     <br>
     I will clean up what I have for a 2.3 release and place it on
    the server as my last Shorewall release -- Shorewall 2.4.0.<br>
     <br>
     Discussions aimed at continuing Shorewall development under
    new leadership are continuing.<br>
     <br>
     Shorewall will always be a part of my life that I look back on
    with fondness.<br>
     <br>
     Regards,<br>
     <br>
     -Tom<br>


    <p><span style="font-weight: bold;">05/02/2005 Shorewall
    2.2.4<br>
    </span></p>

    <p>Problems Corrected:<br>
    </p>

    <ol>
      <li>The error message:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: No appropriate
      chain for zone &lt;z1&gt; to zone &lt;z2&gt;<br>
      <br>
       has been changed to one that is more self-explanatory:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: No policy
      defined for zone &lt;z1&gt; to zone &lt;z2&gt;</li>

      <li>When only an interface name appeared in the HOST(S)
      column of an /etc/shorewall/hosts file entry, a misleading
      iptables error message resulted. Now the following message is
      generated:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: Invalid HOST(S)
      column contents: &lt;column contents&gt;</li>
    </ol>
    New Features:<br>


    <ol>
      <li>Support has been added for UPnP using linux-igd&nbsp; (<a
      href=
      "http://linux-idg.sourceforge.net/">http://linux-idg.sourceforge.net</a>).
      UPnP is required by a number of popular applications
      including MSN IM.</li>
    </ol>

    <div style="margin-left: 40px;">
      <span style="font-weight: bold;">WARNING</span>:<br>


      <div style="margin-left: 40px;">
        From a security architecture viewpoint, UPnP is a disaster.
        It assumes that:<br>


        <ol style="list-style-type: lower-alpha;">
          <li>All local systems and their users are completely
          trustworthy.</li>

          <li>No local system is infected with any worm or
          trojan.</li>
        </ol>
      </div>

      <div style="margin-left: 40px;">
        If either of these assumptions are not true then UPnP can
        be used to totally defeat your firewall and to allow
        incoming connections to arbitrary local systems on any port
        whatsoever.<br>
         In short: <span style="font-weight: bold;">USE UPnP AT
        YOUR OWN RISK</span>.<br>
      </div>

      <div style="margin-left: 40px;">
        <br>
      </div>
    </div>

    <div style="margin-left: 40px;">
      <span style="font-weight: bold;">WARNING</span>:<br>


      <div style="margin-left: 40px;">
        The linux-igd project appears to be inactive and the web
        site does not display correctly on any open source browser
        that I've tried.<br>
        <br>
         Building and installing linux-igd is not for the faint of
        heart. You must download the source from CVS and be
        prepared to do quite a bit of fiddling with the include
        files from libupnp (which is required to build and/or run
        linux-igd).<br>
        <br>
      </div>
    </div>

    <div style="margin-left: 40px;">
      Configuring linux-igd:<br>


      <div style="margin-left: 40px;">
        In /etc/upnpd.conf, you will want:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        insert_forward_rules = yes<br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        prerouting_chain_name = UPnP<br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        forward_chain_name = forwardUPnP<br>
        <br>
      </div>
    </div>

    <div style="margin-left: 40px;">
      Shorewall Configuration:<br>


      <div style="margin-left: 40px;">
        In /etc/shorewall/interfaces, you need the 'upnp' option on
        your external interface.<br>
        <br>
         If your fw-&gt;loc policy is not ACCEPT then you need this
        rule:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        allowoutUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        fw&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
        <br>
         Note: To use 'allowoutUPnP', your iptables and kernel must
        support the 'owner match' feature (see the output of
        "shorewall check").<br>
        <br>
         If your loc-&gt;fw policy is not ACCEPT then you need this
        rule:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        allowinUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        loc&nbsp;&nbsp;&nbsp;&nbsp; fw<br>
        <br>
         You MUST have this rule:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        forwardUPnP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        net&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
        <br>
      </div>
    </div>

    <div style="margin-left: 40px;">
      &nbsp;&nbsp; You must also ensure that you have a route to
      224.0.0.0/4 on you internal (local) interface.<br>
    </div>

    <ol start="2" style="list-style-type: decimal;">
      <li>A new 'started' extension script has been added.&nbsp;
      The difference between this extension script and
      /etc/shorewall/start is that this one is invoked after
      delayed loading of the blacklist (DELAYBLACKLISTLOAD=Yes) and
      after the 'shorewall' chain has been created (thus signaling
      that the firewall is completely up.<br>
      <br>
       /etc/shorewall/started should not change the firewall
      configuration directly but may do so indirectly by running
      /sbin/shorewall with the 'nolock' option.<br>
      <br>
      </li>

      <li>By default, shorewall is started with the "-f" (fast)
      option when your system boots. You can override that setting
      by setting the OPTIONS variable in /etc/sysconfig/shorewall
      (SUSE/Redhat) or /etc/default/shorewall (Debian/Bering). If
      neither file exists, feel free to create one or the
      other.<br>
      <br>
       Example: If you want Shorewall to always use the config
      files even if there is a saved configuration, then
      specify:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS=""<br>
      <br>
      </li>

      <li>Shorewall now has support for the SAME target. This
      change affects the /etc/shorewall/masq and
      /etc/shorewall/rules file.<br>
      <br>
       SAME is useful when you specify multiple target IP addresses
      (in the ADDRESSES column of /etc/shorewall/masq or in the
      DEST column of /etc/shorewall/rules).<br>
      <br>
       If you use normal SNAT then multiple connections from a
      given local host to hosts on the internet can be assigned
      different source IP addresses. This confuses some
      applications that use multiple connections. To correct this
      problem, prefix the list of address ranges in the ADDRESS
      column with "SAME:"<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Example:&nbsp;&nbsp; SAME:206.124.146.176-206.124.146.180<br>
      <br>
       If you want each internal system to use the same IP address
      from the list regardless of which internet host it is talking
      to then prefix the ranges with "SAME:nodst:".<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Example:&nbsp;&nbsp;
      SAME:nodst:206.124.146.176-206.124.146.180<br>
      <br>
       Note that it is not possible to map port numbers when using
      SAME.<br>
      <br>
       In the rules file, when multiple connections from an
      internet host match a SAME rule then all of the connections
      will be sent to the same internal server. SAME rules are very
      similar to DNAT rules with the keyword SAME replacing DNAT.
      As in the masq file, changing the port number is not
      supported.<br>
      <br>
      </li>

      <li>A "shorewall show capabilities" command has been added to
      report the capabilities of your kernel and iptables.<br>
      <br>
       &nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; gateway:~# shorewall show
      capabilities<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Loading
      /usr/share/shorewall/functions...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Processing
      /etc/shorewall/params ...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Processing
      /etc/shorewall/shorewall.conf...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Loading Modules...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Shorewall has detected the
      following iptables/netfilter capabilities:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NAT: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Packet Mangling: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Multi-port Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Extended Multi-port Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Connection Tracking Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Packet Type Match: Not available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Policy Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Physdev Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      IP range Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Recent Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Owner Match: Available<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; gateway:~#<br>
      <br>
      </li>

      <li>A "-v" option has been added to /sbin/shorewall.
      Currently, this option only affects the "show log" command
      (e.g., "shorewall -v show log") and the "monitor" command. In
      these commands, it causes the MAC address in the log message
      (if any) to be displayed. As previously, when "-v" is
      omitted, the MAC address is suppressed.<br>
      <br>
      </li>

      <li>In /etc/shorewall/rules, a value of 'none' in either the
      SOURCE or DEST columns now causes the rule to be ignored.
      This is most useful when used with shell variables:<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      AllowFTP&nbsp;&nbsp;&nbsp;
      $FTP_CLIENTS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fw<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When FTP_CLIENTS
      is set to 'none', the above rule is ignored.&nbsp; Otherwise,
      the rule is evaluated and generates Netfilter rules.<br>
      <br>
      </li>

      <li>The installer now detects that it is running on a
      Slackware system and adjusts the DEST and INIT variables
      accordingly.<br>
      </li>
    </ol>

    <p><span style="font-weight: bold;">05/01/2005 Tom spoke at
    LinuxFest NW 2005 -- Bellingham Technical College, Bellingham
    Washington<br>
    </span><br>
     Tom's presentation was entitled "Shorewall and Native IPSEC"
    and is available for download <a href=
    "http://shorewall.net/LinuxFest.pdf">here (PDF Format)</a>.<br>
    <br>
     <span style="font-weight: bold;">04/07/2005 Shorewall
    2.2.3<br>
    </span><br>
     Problems Corrected:<br>
    </p>

    <ol>
      <li>If a zone is defined in /etc/shorewall/hosts using
      &lt;interface&gt;:!&lt;network&gt; in the HOSTS column then
      startup errors occur on "shorewall [re]start".</li>

      <li>Previously, if "shorewall status" was run on a system
      whose kernel lacked advanced routing support
      (CONFIG_IP_ADVANCED_ROUTER),&nbsp; then no routing
      information was displayed.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>A new extension script "continue" has been added. This
      script is invoked after Shorewall has set the built-in filter
      chains policy to DROP, deleted any existing Netfilter rules
      and user chains and has enabled existing connections. It is
      useful for enabling certain communication while Shorewall is
      being [re]started. Be sure to delete any rules that you add
      here in your /etc/shorewall/start file.</li>

      <li>There has been ongoing confusion about how the
      /etc/shorewall/routestopped file works. People understand how
      it works with the 'shorewall stop' command but when they read
      that 'shorewall restart' is logically equivalent to
      'shorewall stop' followed by 'shorewall start' then they
      erroneously conclude that /etc/shorewall/routestopped can be
      used to enable new connections during 'shorewall restart'. Up
      to now, it cannot -- that file is not processed during either
      'shorewall start' or 'shorewall restart'.<br>
      <br>
       Beginning with Shorewall version 2.2.3,
      /etc/shorewall/routestopped will be processed TWICE during
      'shorewall start' and during 'shorewall restart'. It will be
      processed early in the command execution to add rules
      allowing new connections while the command is running and it
      will be processed again when the command is complete to
      remove the rules added earlier.<br>
      <br>
       The result of this change will be that during most of
      [re]start, new connections will be allowed in accordance with
      the contents of /etc/shorewall/routestopped.</li>

      <li>The performance of configurations with a large numbers of
      entries in /etc/shorewall/maclist can be improved by setting
      the new MACLIST_TTL variable in
      /etc/shorewall/shorewall.conf.<br>
      <br>
       If your iptables and kernel support the "Recent Match" (see
      the output of "shorewall check" near the top), you can cache
      the results of a 'maclist' file lookup and thus reduce the
      overhead associated with MAC Verification.<br>
      <br>
       When a new connection arrives from a 'maclist' interface,
      the packet passes through then list of entries for that
      interface in /etc/shorewall/maclist. If there is a match then
      the source IP address is added to the 'Recent' set for that
      interface. Subsequent connection attempts from that IP
      address occuring within $MACLIST_TTL seconds will be accepted
      without having to scan all of the entries. After $MACLIST_TTL
      from the first accepted connection request from an IP
      address, the next connection request from that IP address
      will be checked against the entire list.<br>
      <br>
       If MACLIST_TTL is not specified or is specified as empty
      (e.g, MACLIST_TTL="" or is specified as zero then 'maclist'
      lookups will not be cached.</li>

      <li>You can now specify QUEUE as a policy and you can
      designate a common action for QUEUE policies in
      /etc/shorewall/actions. This is useful for sending packets to
      something like Snort Inline.<br>
      </li>
    </ol>
    <span style="font-weight: bold;">03/31/2005 Shorewall
    2.0.17<br>
    <br>
    </span> Problems Corrected:<br>


    <ol>
      <li>Invoking the 'rejNotSyn' action results in an error at
      startup.</li>

      <li>The UDP and TCP port numbers in
      /usr/share/shorewall/action.AllowPCA were reversed.</li>

      <li>If a zone is defined in /etc/shorewall/hosts using
      &lt;<span style=
      "font-style: italic;">interface</span>&gt;:!&lt;<span style=
      "font-style: italic;">network</span>&gt; in the HOSTS column
      then startup errors occur on "shorewall [re]start".<br>
      </li>
    </ol>
    <span style="font-weight: bold;">03/12/2005 Shorewall 2.2.2<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>The SOURCE column in the /etc/shorewall/tcrules file now
      correctly allows IP ranges (assuming that your iptables and
      kernel support ranges).<br>
      </li>

      <li>If A is a user-defined action and you have file
      /etc/shorewall/A then when that file is invoked by Shorewall
      during [re]start, the $TAG value may be incorrect.</li>

      <li>Previously, if an iptables command generating a logging
      rule failed, the Shorewall [re]start was still successful.
      This error is now considered fatal and Shorewall will be
      either restored from the last save (if any) or it will be
      stopped.</li>

      <li>The port numbers for UDP and TCP were previously reversed
      in the /usr/share/shorewall/action.AllowPCA file.</li>

      <li>Previously, the 'install.sh' script did not update the
      /usr/share/shorewall/action.* files.</li>

      <li>Previously, when an interface name appeared in the DEST
      column of /etc/shorewall/tcrules, the name was not validated
      against the set of defined interfaces and bridge ports.<br>
      </li>
    </ol>
    New Features:<br>


    <ol>
      <li>The SOURCE column in the /etc/shorewall/tcrules file now
      allows $FW to be optionally followed by ":" and a
      host/network address or address range.</li>

      <li>Shorewall now clears the output device only if it is a
      terminal. This avoids ugly control sequences being placed in
      files when /sbin/shorewall output is redirected.</li>

      <li>The output from 'arp -na' has been added to the
      'shorewall status' display.</li>

      <li>The 2.6.11 Linux kernel and iptables 1.3.0 now allow port
      ranges to appear in port lists handled by "multiport match".
      If Shorewall detects this capability, it will use "multiport
      match" for port lists containing port ranges. Be cautioned
      that each port range counts for TWO ports and a port list
      handled with "multiport match" can still specify a maximum of
      15 ports.<br>
      <br>
       As always, if a port list in /etc/shorewall/rules is
      incompatible with "multiport match", a separate iptables rule
      will be generated for each element in the list.</li>

      <li>Traditionally, the RETURN target in the 'rfc1918' file
      has caused 'norfc1918' processing to cease for a packet if
      the packet's source IP address matches the rule. Thus, if you
      have:<br>
      <br>
       <span style="font-family: monospace;">&nbsp;&nbsp;
      SUBNETS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      TARGET</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;
      192.168.1.0/24&nbsp;&nbsp; RETURN</span><br>
      <br>
       then traffic from 192.168.1.4 to 10.0.3.9 will be accepted
      even though you also have:<br>
      <br>
       <span style="font-family: monospace;">&nbsp;&nbsp;
      SUBNETS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      TARGET</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;
      10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      logdrop</span><br>
      <br>
       Setting RFC1918_STRICT=Yes in shorewall.conf will cause such
      traffic to be logged and dropped since while the packet's
      source matches the RETURN rule, the packet's destination
      matches the 'logdrop' rule.<br>
      <br>
       If not specified or specified as empty (e.g.,
      RFC1918_STRICT="") then RFC1918_STRICT=No is assumed.<br>
      <br>
       WARNING: RFC1918_STRICT=Yes requires that your kernel and
      iptables support 'Connection Tracking' match.<br>
      </li>
    </ol>

    <p><span style="font-weight: bold;">02/15/2005 Shorewall
    2.2.1<br>
    <br>
    </span> This release rolls up the fixes for bugs found in the
    first 2-3 weeks of deployment of Shorewall 2.2.<br>
    </p>

    <ol>
      <li>The /etc/shorewall/policy file contained a misleading
      comment and both that file and the /etc/shorewall/zones file
      lacked examples.</li>

      <li>Shorewall previously used root's default umask which
      could cause files in /var/lib/shorewall to be world-readable.
      Shorewall now uses umask 0177.</li>

      <li>In log messages produced by logging a built-in action,
      the packet disposition was displayed incorrectly.<br>
      <br>
       &nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      rejNotSyn:ULOG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      all&nbsp;&nbsp;&nbsp;&nbsp;
      all&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      tcp<br>
      <br>
       &nbsp;&nbsp; produces the log message:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Feb 12 23:57:08 server Shorewall:rejNotSyn:ULOG: ...<br>
      <br>
       &nbsp;&nbsp; rather than<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Feb 12 23:57:08 server Shorewall:rejNotSyn:REJECT: ...<br>
      <br>
      </li>

      <li>The comments regarding built-in actions in
      /usr/share/shorewall/actions.std have been corrected.</li>

      <li>The /etc/shorewall/policy file in the LRP package was
      missing the 'all-&gt;all' policy.<br>
      </li>
    </ol>
    <span style="font-weight: bold;">02/05/2005 End of Support for
    Shorewall 1.4<br>
    <br>
    </span> Effective today, support for Shorewall 1.4 has been
    discontinued. See the link at the top of this article for&nbsp;
    upgrade information.<br>
     <br>
     <span style="font-weight: bold;">02/01/2005 Shorewall
    2.0.16<br>
    </span> <br>
     This release back-ports the DROPINVALID shorewall.conf option
    from 2.2.0.<br>


    <ol>
      <li>Recent 2.6 kernels include code that evaluates TCP
      packets based on TCP Window analysis. This can cause packets
      that were previously classified as NEW or ESTABLISHED to be
      classified as INVALID.<br>
      <br>
       The new kernel code can be disabled by including this
      command in your /etc/shorewall/init file:<br>
      <br>
       echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
      <br>
       Additional kernel logging about INVALID TCP packets may be
      obtained by adding this command to /etc/shorewall/init:<br>
      <br>
       echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
      <br>
       Traditionally, Shorewall has dropped INVALID TCP packets
      early. The new DROPINVALID option allows INVALID packets to
      be passed through the normal rules chains by setting
      DROPINVALID=No.<br>
      <br>
       If not specified or if specified as empty (e.g.,
      DROPINVALID="") then DROPINVALID=Yes is assumed.</li>
    </ol>

    <p><span style="font-weight: bold;">02/01/2005 Shorewall
    2.2.0<br>
    <br>
    </span> New Features:<br>
    </p>

    <ol>
      <li>ICMP packets that are in the INVALID state are now
      dropped by the Reject and Drop default actions. They do so
      using the new 'dropInvalid' builtin action. An 'allowInvalid'
      builtin action is also provided which accepts packets in that
      state.</li>

      <li>The /etc/shorewall/masq file INTERFACE column now allows
      additional options.<br>
      <br>
       Normally MASQUERADE/SNAT rules are evaluated after
      one-to-one NAT rules defined in the /etc/shorewall/nat file.
      If you preceed the interface name with a plus sign ("+") then
      the rule will be evaluated before one-to-one NAT.<br>
      <br>
       Examples:<br>
      <br>
       +eth0<br>
       +eth1:192.0.2.32/27<br>
      <br>
       Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for
      an entry by following the interface name by ":" but no
      digit.<br>
      <br>
       Examples:<br>
      <br>
       eth0:<br>
       eth1::192.0.2.32/27<br>
       +eth3:<br>
      <br>
      </li>

      <li>Similar to 2), the /etc/shorewall/nat file INTERFACE
      column now allows you to override the setting of
      ADD_IP_ALIASES=Yes by following the interface name with ":"
      but no digit.</li>

      <li>All configuration files in the Shorewall distribution
      with the exception of shorewall.conf are now empty. In
      particular, the /etc/shorewall/zones, /etc/shorewall/policy
      and /etc/shorewall/tos files now have no active entries.
      Hopefully this will stop the questions on the support and
      development lists regarding why the default entries are the
      way they are.</li>

      <li>Previously, including a log level (and optionally a log
      tag) on a rule that specified a user-defined (or
      Shorewall-defined) action would log all traffic passed to the
      action. Beginning with this release, specifying a log level
      in a rule that specifies a user- or Shorewall-defined action
      will cause each rule in the action to be logged with the
      specified level (and tag).<br>
      <br>
       The extent to which logging of action rules occurs is
      goverend by the following:</li>

      <li style="list-style: none">
        <ul>
          <li>When you invoke an action and specify a log level,
          only those rules in the action that have no log level
          will be changed to log at the level specified at the
          action invocation.<br>
          <br>
           Example:<br>
          <br>
           /etc/shorewall/action.foo:<br>
          <br>
           ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
          -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
           bar:info<br>
          <br>
           /etc/shorewall/rules:<br>
          <br>
           foo:debug&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp; net<br>
          <br>
           Logging in the invoked 'foo' action will be:<br>
          <br>
           ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
          -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
           bar:info<br>
          <br>
          </li>

          <li>If you follow the log level with "!" then logging
          will be at that level for all rules recursively invoked
          by the action<br>
          <br>
           Example: /etc/shorewall/action.foo:<br>
          <br>
           <b>Update:</b> I've been informed by Mandrake
          Development that this problem has been corrected in
          Mandrake 10.0 Final (the problem still exists in the 10.0
          Community release).<br>
           ACCEPT&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
          -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
           bar:info<br>
          <br>
           /etc/shorewall/rules:<br>
          <br>
           foo:debug!&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
          net<br>
          <br>
           Logging in the invoke 'foo' action will be:<br>
          <br>
           ACCEPT:debug&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;
          -&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
           bar:debug!<br>
          <br>
          </li>
        </ul>
      </li>
    </ol>

    <div style="margin-left: 40px;">
      This change has an effect on extension scripts used with
      user-defined actions. If you define an action 'acton' and you
      have an /etc/shorewall/acton script then when that script is
      invoked, the following three variables will be set for use by
      the script:<br>
      <br>


      <div style="margin-left: 40px;">
        $CHAIN = the name of the chain where your rules are to be
        placed. When logging is used on an action invocation,
        Shorewall creates a chain with a slightly different name
        from the action itself.<br>
         $LEVEL = Log level. If empty, no logging was
        specified.<br>
         $TAG&nbsp;&nbsp; = Log Tag.<br>
        <br>
      </div>
      Example:<br>
      <br>
       /etc/shorewall/rules:<br>
       &nbsp;&nbsp;&nbsp;<br>
       acton:info:test<br>
      <br>
       Your /etc/shorewall/acton file will be run with:<br>
      <br>


      <div style="margin-left: 40px;">
        $CHAIN="%acton1<br>
         $LEVEL="info"<br>
         $TAG="test"<br>
      </div>
    </div>
    <br>


    <ol start="6">
      <li>The /etc/shorewall/startup_disabled file is no longer
      created when Shorewall is first installed. Rather, the
      variable STARTUP_ENABLED is set to 'No' in
      /etc/shorewall/shorewall.conf. In order to get Shorewall to
      start, that variable's value must be set to 'Yes'. This
      change accomplishes two things:</li>

      <li style="list-style: none">
        <ul>
          <li>It prevents Shorewall from being started prematurely
          by the user's initialization scripts.</li>

          <li>It causes /etc/shorewall/shorewall.conf to be
          modified so that it won't be replaced by upgrades using
          RPM.<br>
          <br>
          </li>
        </ul>
      </li>

      <li>Support has been added for the 2.6 Kernel IPSEC
      implementation. To use this support, you must have installed
      the IPSEC policy match patch and the four IPSEC/Netfilter
      patches from Patch-0-Matic-ng. The policy match patch affects
      both your kernel and iptables. There are two ways to specify
      that IPSEC is to be used when communicating with a set of
      hosts; both methods involve the new /etc/shorewall/ipsec
      file:</li>

      <li style="list-style: none">
        <ol style="list-style-type: lower-alpha;">
          <li>If encrypted communication is used with all hosts in
          a zone, then you can designate the zone as an "ipsec"
          zone by placing 'Yes" in the IPSEC ONLY column in
          /etc/shorewall/ipsec:<br>
          <br>
           <span style=
          "font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp;
          &nbsp;&nbsp;&nbsp; IPSEC&nbsp;&nbsp;&nbsp; OPTIONS
          ...</span><br style="font-family: monospace;">
           <span style=
          "font-family: monospace;">#&nbsp;&nbsp;&nbsp;
          &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; ONLY</span><br
          style="font-family: monospace;">
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
          &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Yes</span><br>
          <br>
           The hosts in the zone (if any) must be specified in
          /etc/shorewall/hosts but you do not need to specify the
          'ipsec' option on the entries in that file (see below).
          Dynamic zones involving IPSEC must use that
          technique.<br>
          <br>
           Example:Under 2.4 Kernel FreeS/Wan:<br>
          <br>
           /etc/shorewall/zones:<br>
          <br>
           <span style=
          "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
          Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
          style="font-family: monospace;">
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
          VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
          <br>
           /etc/shorewall/interfaces:<br>
          <br>
           <span style=
          "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
          eth0&nbsp;&nbsp;&nbsp; ...</span><br style=
          "font-family: monospace;">
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
          ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
          <br>
           Under 2.6 Kernel with this new support:<br>
          <br>
           /etc/shorewall/zones:<br>
          <br>
           <span style=
          "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
          Net&nbsp;&nbsp;&nbsp; The big bad Internet</span><br
          style="font-family: monospace;">
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
          VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
          <br>
           /etc/shorewall/interfaces:<br>
          <br>
           <span style=
          "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
          eth0&nbsp;&nbsp;&nbsp; ...</span><br>
          <br>
           /etc/shorewall/hosts:<br>
          <br>
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
          eth0:0.0.0.0/0</span><br>
          <br>
           /etc/shorewall/ipsec<br>
          <br>
           <span style=
          "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp; Yes<br>
          <br>
          </span></li>

          <li>
            If only part of the hosts in a zone require encrypted
            communication, you may use of the new 'ipsec' option in
            /etc/shorewall/hosts to designate those hosts.<br>
            <br>
             Example:<br>
            <br>
             Under 2.4 Kernel FreeS/Wan:<br>
            <br>
             /etc/shorewall/zones:<br>

<pre>
net    Net    The big bad Internet<br>
loc    Local  Extended local zone
</pre>
            /etc/shorewall/interfaces:<br>
            <br>
             <span style=
            "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
            eth0&nbsp;&nbsp;&nbsp; ...</span><br style=
            "font-family: monospace;">
             <span style=
            "font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
            eth1&nbsp;&nbsp;&nbsp; ...</span><br style=
            "font-family: monospace;">
             <span style=
            "font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
            ipsec0&nbsp;&nbsp;&nbsp; ...</span><br>
            <br>
             Under 2.6 Kernel with this new support:<br>
            <br>
             /etc/shorewall/zones:<br>
            <br>
             <span style=
            "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
            &nbsp;&nbsp;&nbsp; Net&nbsp;&nbsp;&nbsp; The big bad
            Internet</span><br style="font-family: monospace;">
             <span style=
            "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            &nbsp; VPN&nbsp;&nbsp;&nbsp; Remote Network</span><br>
            <br>
             /etc/shorewall/interfaces:<br>
            <br>
             <span style=
            "font-family: monospace;">net&nbsp;&nbsp;&nbsp;
            eth0&nbsp;&nbsp;&nbsp; ...</span><br style=
            "font-family: monospace;">
             <span style=
            "font-family: monospace;">loc&nbsp;&nbsp;&nbsp;
            eth1&nbsp;&nbsp;&nbsp; ...</span><br>
            <br>
             /etc/shorewall/hosts:<br>
            <br>
             <span style=
            "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;
            eth0:0.0.0.0/0&nbsp;&nbsp;&nbsp; ipsec,...</span>
          </li>
        </ol>
      </li>
    </ol>

    <div style="margin-left: 40px;">
      Regardless of which technique you choose, you can specify
      additional SA options for the zone in the
      /etc/shorewall/ipsec entry.<br>
      <br>
       The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
      input-output, input and output characteristics of the
      security associations to be used to decrypt (input) or
      encrypt (output) traffic to/from the zone.<br>
      <br>
       The available options are:<br>
    </div>

    <div style="margin-left: 2em">
      <ul>
        <li>reqid[!]=&lt;number&gt; where &lt;number&gt; is
        specified using setkey(8) using the 'unique:&lt;number&gt;'
        option for the SPD level.</li>

        <li>spi[!]=&lt;number&gt; where &lt;number&gt; is the SPI
        of the SA. Since different SAs are used to encrypt and
        decrypt traffic, this option should only be listed in the
        IN OPTIONS and OUT OPTIONS columns.</li>

        <li>proto[!]=ah|esp|ipcomp</li>

        <li>mss=&lt;number&gt; (sets the MSS value in TCP SYN
        packets and is not related to policy matching)</li>

        <li>mode[!]=transport|tunnel</li>

        <li>tunnel-src[!]=&lt;address&gt;[/&lt;mask&gt;] (only
        available with mode=tunnel)</li>

        <li>tunnel-dst[!]=&lt;address&gt;[/&lt;mask&gt;] (only
        available with mode=tunnel). Because tunnel source and
        destination are dependent on the direction of the traffic,
        these options should only appear in the IN OPTIONS and OUT
        OPTIONS columns.</li>

        <li>strict&nbsp; (if specified, packets must match all
        policies; policies are delimited by 'next').</li>

        <li>next&nbsp;&nbsp;&nbsp; (only available with
        strict)</li>
      </ul>
    </div>

    <div style="margin-left: 40px;">
      Examples:<br>
      <br>
       <span style=
      "font-family: monospace;">#ZONE&nbsp;&nbsp;&nbsp; IPSEC&nbsp;
      OPTIONS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      IN&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      OUT</span><br style="font-family: monospace;">
       <span style=
      "font-family: monospace;">#&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ONLY&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; OPTIONS&nbsp;&nbsp;&nbsp;&nbsp;
      OPTIONS</span><br style="font-family: monospace;">
       <span style=
      "font-family: monospace;">vpn&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Yes&nbsp;&nbsp;&nbsp; mode=tunnel,proto=esp&nbsp;&nbsp;&nbsp;
      spi=1000&nbsp;&nbsp;&nbsp; spi=1001</span><br style=
      "font-family: monospace;">
       <span style=
      "font-family: monospace;">loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      No&nbsp;&nbsp;&nbsp;&nbsp; reqid=44,mode=transport</span><br>
      <br>
       The /etc/shorewall/masq file has a new IPSEC column added.
      If you specify Yes or yes in that column then the unencrypted
      packets will have their source address changed. Otherwise,
      the unencrypted packets will not have their source addresses
      changed. This column may also contain a comma-separated list
      of the options specified above in which case only those
      packets that will be encrypted by an SA matching the given
      options will have their source address changed.<br>
    </div>

    <ol start="8">
      <li>To improve interoperability, tunnels of type 'ipsec' no
      longer enforce the use of source port 500 for ISAKMP and
      OpenVPN tunnels no longer enforce use of the specified port
      as both the source and destination ports.</li>

      <li>A new 'allowBcast' builtin action has been added -- it
      silently allows broadcasts and multicasts.</li>

      <li>The -c option in /sbin/shorewall commands is now
      deprecated. The commands where -c was previously allowed now
      permit you to specify a configuration directory after the
      command:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall check&nbsp;&nbsp; [
      &lt;configuration-directory&gt; ]<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall restart [
      &lt;configuration-directory&gt; ]<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall start&nbsp;&nbsp; [
      &lt;configuration-directory&gt; ]<br>
      <br>
      </li>

      <li>Normally, when SNAT or MASQUERADE is applied to a tcp or
      udp connection, Netfilter attempts to retain the source port
      number. If it has to change to port number to avoid&nbsp;
      &lt;source address&gt;,&lt;source port&gt; conflicts, it
      tries to do so within port ranges ( &lt; 512, 512-1023, and
      &gt; 1023). You may now specify an explicit range of source
      ports to be used by following the address or address range
      (if any) in the ADDRESS column with ":" and a port range in
      the format &lt;low-port&gt;-&lt;high-port&gt;. You must
      specify either "tcp" or "udp" in the PROTO column.<br>
      <br>
       Examples 1 -- MASQUERADE with tcp source ports
      4000-5000:<br>
      <br>
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      #INTERFACE SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;
      ADDRESS&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; PROTO</span><br
      style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.0/24&nbsp;
      :4000-5000&nbsp;&nbsp;&nbsp;&nbsp; tcp</span><br style=
      "font-family: monospace;">
      <br>
       Example 2 -- SNAT with udp source ports 7000-8000:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">#INTERFACE SUBNET&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; &nbsp; ADDRESS&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      PROTO</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;
      eth0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      10.0.0.0/8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      192.0.2.44:7000-8000&nbsp;&nbsp;&nbsp; udp<br>
      <br>
      </span></li>

      <li>You may now account by user/group ID for outbound traffic
      from the firewall itself with entries in
      /etc/shorewall/accounting. Such accounting rules must be
      placed in the OUTPUT chain. See the comments at the top of
      /etc/shorewall/accounting for details.</li>

      <li>Shorewall now verifies that your kernel and iptables have
      physdev match support if BRIDGING=Yes in shorewall.conf.</li>

      <li>Beginning with this release, if your kernel and iptables
      have iprange match support (see the output from "shorewall
      check"), then with the exception of the /etc/shorewall/netmap
      file, anywhere that a network address may appear an IP
      address range of the form &lt;low address&gt;-&lt;high
      address&gt; may also appear.</li>

      <li>Support has been added for the iptables CLASSIFY target.
      That target allows you to classify packets for traffic
      shaping directly rather than indirectly through fwmark.
      Simply enter the &lt;major&gt;:&lt;minor&gt; classification
      in the first column of /etc/shorewall/tcrules:<br>
      <br>
       Example:<br>
      <br>
       <span style=
      "font-family: monospace;">#MARK/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      DEST&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      PROTO&nbsp;&nbsp;&nbsp;&nbsp; PORT(S)</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">#CLASSIFY</span><br
      style="font-family: monospace;">
       <span style="font-family: monospace;">1:30&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp; &nbsp;
      tcp&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 25</span><br>
      <br>
       Note that when using this form of rule, it is acceptable to
      include the name of an interface in the DEST column.<br>
      <br>
       Marking using the CLASSIFY target always occurs in the
      POSTROUTING chain of the mangle table and is not affected by
      the setting of MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>

      <li>During "shorewall start", IP addresses to be added as a
      consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes
      are quietly deleted when /etc/shorewall/nat and
      /etc/shorewall/masq are processed then they are re-added
      later. This is done to help ensure that the addresses can be
      added with the specified labels but can have the undesirable
      side effect of causing routes to be quietly deleted. A new
      RETAIN_ALIASES option has been added to shorewall.conf; when
      this option is set to Yes, existing addresses will not be
      deleted. Regardless of the setting of RETAIN_ALIASES,
      addresses added during "shorewall start" are still deleted at
      a subsequent "shorewall stop" or "shorewall restart".</li>

      <li>Users with a large black list (from
      /etc/shorewall/blacklist) may want to set the new
      DELAYBLACKLISTLOAD option in shorewall.conf. When
      DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections
      before loading the blacklist rules. While this may allow
      connections from blacklisted hosts to slip by during
      construction of the blacklist, it can substantially reduce
      the time that all new connections are disabled during
      "shorewall [re]start".</li>

      <li>Using the default LOGFORMAT, chain names longer than 11
      characters (such as in user-defined actions) may result in
      log prefix truncation. A new shorewall.conf action&nbsp;
      LOGTAGONLY has been added to deal with this problem. When
      LOGTAGONLY=Yes, logging rules that specify a log tag will
      substitute the tag for the chain name in the log prefix.<br>
      <br>
       Example -- file
      /etc/shorewall/action.thisisaverylogactionname:<br>
      <br>
       &nbsp;&nbsp;&nbsp; Rule:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
      style=
      "font-family: monospace;">DROP:info:ftp&nbsp;&nbsp;&nbsp;
      0.0.0.0/0&nbsp;&nbsp;&nbsp; 0.0.0.0/0&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 21</span><br>
       &nbsp;&nbsp;&nbsp;<br>
       &nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=No:<br>
      <br>
       &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; <span style=
      "font-family: monospace;">Shorewall:thisisaverylongacti</span><br>

      <br>
       &nbsp;&nbsp;&nbsp; Log prefix with LOGTAGONLY=Yes:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span
      style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
      <br>
      </li>

      <li>Shorewall now resets the 'accept_source_route' flag for
      all interfaces. If you wish to accept source routing on an
      interface, you must specify the new 'sourceroute' interface
      option in /etc/shorewall/interfaces.</li>

      <li>The default Drop and Reject actions now invoke the new
      standard action 'AllowICMPs'. This new action accepts
      critical ICMP types:<br>
       &nbsp;&nbsp;&nbsp;<br>
       &nbsp;&nbsp;&nbsp; Type 3 code 4 (fragmentation needed)<br>
       &nbsp;&nbsp;&nbsp; Type
      11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (TTL exceeded)<br>
      <br>
      </li>

      <li>Explicit control over the kernel's Martian logging is now
      provided using the new 'logmartians' interface option. If you
      include 'logmartians' in the interface option list then
      logging of Martian packets on will be enabled on the
      specified interface. If you wish to globally enable martian
      logging, you can set LOG_MARTIANS=Yes in shorewall.conf.</li>

      <li>You may now cause Shorewall to use the '--set-mss' option
      of the TCPMSS target. In other words, you can cause Shorewall
      to set the MSS field of SYN packets passing through the
      firewall to the value you specify. This feature extends the
      existing CLAMPMSS option in /etc/shorewall/shorewall.conf by
      allowing that option to have a numeric value as well as the
      values "Yes" and "No".<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; CLAMPMSS=1400<br>
      <br>
      </li>

      <li>Shorewall now includes support for the ipp2p match
      facility. This is a departure from my usual policy in that
      the ipp2p match facility is included in Patch-O-Matic-NG and
      is unlikely to ever be included in the kernel.org source
      tree. Questions about how to install the patch or how to
      build your kernel and/or iptables should not be posted on the
      Shorewall mailing lists.<br>
      <br>
       In the following files, the "PROTO" or "PROTOCOL" column may
      contain "ipp2p":<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/rules<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/tcrules<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/accounting<br>
      <br>
       When the PROTO or PROTOCOL column contains "ipp2p" then the
      DEST PORT(S) or PORT(S) column may contain a recognized ipp2p
      option; for a list of the options and their meaning, at a
      root prompt:<br>
      <br>
       &nbsp;&nbsp;&nbsp; iptables -m ipp2p --help<br>
      <br>
       You must not include the leading "--" on the option;
      Shorewall will supply those characters for you. If you do not
      include an option then "ipp2p" is assumed (Shorewall will
      generate "-m ipp2p --ipp2p").</li>

      <li>Shorewall now has support for the CONNMARK target from
      iptables. See the /etc/shorewall/tcrules file for
      details.</li>

      <li>A new debugging option LOGALLNEW has been added to
      shorewall.conf. When set to a log level, this option causes
      Shorewall to generaate a logging rule as the first rule in
      each builtin chain.<br>
      <br>
       &nbsp;&nbsp;&nbsp; - The table name is used as the chain
      name in the log prefix.<br>
       &nbsp;&nbsp;&nbsp; - The chain name is used as the target in
      the log prefix.<br>
      <br>
       Example: Using the default LOGFORMAT, the log prefix for
      logging from the nat table's PREROUTING chain is:<br>
      <br>
       &nbsp;&nbsp;&nbsp; &nbsp;<span style=
      "font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
      <br>
       IMPORTANT: There is no rate limiting on these logging rules
      so use LOGALLNEW at your own risk; it may cause high CPU and
      disk utilization and you may not be able to control your
      firewall after you enable this option.<br>
      <br>
       DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES
      WILL BE SENT TO ANOTHER SYSTEM.<br>
      <br>
      </li>

      <li>The SUBNET column in /etc/shorewall/rfc1918 has been
      renamed SUBNETS and it is now possible to specify a list of
      addresses in that column.</li>

      <li>The AllowNNTP action now also allows NNTP over SSL/TLS
      (NNTPS).</li>

      <li>For consistency, the CLIENT PORT(S) column in the tcrules
      file has been renamed SOURCE PORT(S).</li>

      <li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
      now shown in the output of "shorewall status".</li>

      <li>A new IPTABLES option has been added to shorewall.conf.
      IPTABLES can be used to designate the iptables executable to
      be used by Shorewall. If not specified, the iptables
      executable determined by the PATH setting is used.</li>

      <li>You can now use the "shorewall show zones" command to
      display the current contents of the zones. This is
      particularly useful if you use dynamic zones
      (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
      <br>
       &nbsp;&nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">ursa:/etc/shorewall # shorewall
      show zones</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
      2004</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;</span><br
      style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      loc</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; eth0:192.168.1.0/24</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; eth1:1.2.3.4</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; eth0:0.0.0.0/0</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      WiFi</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; eth1:0.0.0.0/0</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      sec</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp; eth1:0.0.0.0/0</span><br style=
      "font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;</span><br
      style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      ursa:/etc/shorewall #</span><br>
      <br>
      </li>

      <li>Variable expansion may now be used with the INCLUDE
      directive.<br>
      <br>
       &nbsp;&nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; /etc/shorewall/params<br>
      <br>
       &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">FILE=/etc/foo/bar</span><br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config
      file:<br>
      <br>
       &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">INCLUDE $FILE</span><br>
      <br>
      </li>

      <li>The output of "shorewall status" now includes the results
      of "ip -stat link ls". This helps diagnose performance
      problems caused by link errors.</li>

      <li>Previously, when rate-limiting was specified in
      /etc/shorewall/policy (LIMIT:BURST column), any traffic which
      exceeded the specified rate was silently dropped. Now, if a
      log level is given in the entry (LEVEL column) then drops are
      logged at that level at a rate of 5/min with a burst of
      5.</li>

      <li>Recent 2.6 kernels include code that evaluates TCP
      packets based on TCP Window analysis. This can cause packets
      that were previously classified as NEW or ESTABLISHED to be
      classified as INVALID.<br>
      <br>
       The new kernel code can be disabled by including this
      command in your /etc/shorewall/init file:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>

      <br>
       Additional kernel logging about INVALID TCP packets may be
      obtained by adding this command to /etc/shorewall/init:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>

      <br>
       Traditionally, Shorewall has dropped INVALID TCP packets
      early. The new DROPINVALID option allows INVALID packets to
      be passed through the normal rules chains by setting
      DROPINVALID=No.<br>
      <br>
       If not specified or if specified as empty (e.g.,
      DROPINVALID="") then DROPINVALID=Yes is assumed.<br>
      <br>
      </li>

      <li>The "shorewall add" and "shorewall delete" commands now
      accept a list of hosts to add or delete.<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">shorewall add eth1:1.2.3.4
      eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp; shorewall
      delete eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
      <br>
       &nbsp;&nbsp;&nbsp; The above commands may also be
      written:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">shorewall add eth1:1.2.3.4,2.3.4.5
      z12</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp; shorewall
      delete eth1:1.2.3.4,2.3.4.5 z12</span><br>
       &nbsp;&nbsp;<br>
      </li>

      <li>TCP OpenVPN tunnels are now supported using the 'openvpn'
      tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
      this format:<br>
      <br>
       &nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
      &lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      &lt;gateway&gt;</span><br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <span style=
      "font-family: monospace;">openvpn:tcp&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      1.2.3.4&nbsp;&nbsp;&nbsp; # TCP tunnel on port 1194</span><br
      style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      openvpn:3344&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp; 1.2.3.4&nbsp;&nbsp;&nbsp; # UDP on port
      3344</span><br style="font-family: monospace;">
       <span style="font-family: monospace;">&nbsp;&nbsp;&nbsp;
      openvpn:tcp:4455&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      1.2.3.4&nbsp;&nbsp;&nbsp; # TCP on port 4455</span><br>
      <br>
      </li>

      <li>A new 'ipsecvpn' script is included in the tarball and in
      the RPM. The RPM installs the file in the Documentation
      directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
      <br>
       This script is intended for use on Roadwarrior laptops for
      establishing an IPSEC SA to/from remote networks. The script
      has some limitations:</li>
    </ol>

    <div style="margin-left: 2em">
      <ul>
        <li>Only one instance of the script may be used at a
        time.</li>

        <li>Only the first SPD accessed will be instantiated at the
        remote gateway. So while the script creates SPDs to/from
        the remote gateway and each network listed in the NETWORKS
        setting at the front of the script, only one of these may
        be used at a time.</li>
      </ul>
    </div>

    <ol start="39">
      <li>The output of "shorewall status" now lists the loaded
      netfilter kernel modules.</li>

      <li>The range of UDP ports opened by the AllowTrcrt action
      has been increased to 33434:33524.</li>

      <li>The IANA has recently registered port 1194 for use by
      OpenVPN. In previous versions of Shorewall (and OpenVPN), the
      default port was 5000 but has been changed to 1194 to conform
      to the new OpenVPN default.</li>
    </ol>

    <p><span style="font-weight: bold;">01/17/2005 - Shorewall
    2.2.0 RC5<br>
    <br>
    </span> Problems Corrected:<br>
    </p>

    <ol>
      <li>The AllowTrcrt action has been changed to allow up to 30
      hops (same as default for 'traceroute'). Previously, the
      action was documented as allowing 20 hops but actually only
      allowed for 6 hops.<br>
      </li>

      <li>Using some lightweight shells, valid entries in
      /etc/shorewall/ecn produce startup errors.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>A new AllowInvalid standard built-in action has been
      added. This action accepts packets that are in the INVALID
      connection-tracking state.</li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "Mirrors"></a>01/16/2005 - New Shorewall Mirrors<br>
    <br>
    </span> Thanks to Lorenzo Martignoni and Nick Slikey, there are
    now Shorewall <a href="shorewall_mirrors.htm">mirrors</a> in
    Milan Italy and in Austin Texas. Thanks Lorenzo and Nick!<br>
     <span style="font-weight: bold;"><br>
     <a name="2_0_15"></a>01/12/2005 - Shorewall 2.0.15<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>The range of ports opened by the AllowTrcrt action has
      been expanded to 33434:33524 to allow for a maximum of 30
      hops.</li>

      <li>Code mis-ported from 2.2.0 in release 2.0.14 caused the
      following error during "shorewall start" where SYN
      rate-limiting is present in /etc/shorewall/policy:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bad argument `DROP'<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Try `iptables -h' or
      'iptables --help' for more information.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_RC4"></a>01/06/2005 - Shorewall 2.2.0 RC4<br>
    </span> <br>
     New Features:<br>


    <ol>
      <li>A listing of loaded iptables kernel modules is now
      included in the output of "shorewall status".<br>
      </li>
    </ol>
    Problems Corrected.<br>


    <ol>
      <li>Several problems associated with processing the IPSEC
      colummn in /etc/shorewall/masq have been corrected.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_0_14"></a>01/03/2005 - Shorewall 2.0.14<br>
    </span> <br>
     New Features:<br>


    <ol>
      <li>Previously, when rate-limiting was specified in
      /etc/shorewall/policy (LIMIT:BURST column), any traffic which
      exceeded the specified rate was silently dropped. Now, if a
      log level is given in the entry (LEVEL column) then drops are
      logged at that level at a rate of 5/min with a burst of
      5.<br>
      </li>
    </ol>
    Problems Corrected:<br>


    <ol>
      <li>A typo in the /etc/shorewall/interfaces file has been
      fixed.</li>

      <li>"bad variable" error messages occurring during "shorewall
      stop" and "shorewall clear" have been eliminated.</li>

      <li>A misleading typo in /etc/shorewall/tunnels has been
      corrected. The TYPE column for an IPIP tunnel should contain
      "ipip" rather than "ip".<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "MandrakeRPMS"></a>12/31/2004 - Mandrake-specific RPMs
    available<br>
    <br>
    </span> Jack Coates has generously volunteered to provide
    Shorewall RPMs for use under Mandrake. You can download Jack's
    RPMs from <a target="_top" href=
    "http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>

     <br>
     <span style="font-weight: bold;"><a name=
    "Redhat_Fedora"></a>12/31/2004 - Redhat/Fedora-specific RPMs
    available<br>
    </span> <br>
     Simon Matter has graciously volunteered to provide RPMs
    tailored for Redhat and Fedora. You can download Simon's RPMs
    from <a target="_top" href=
    "http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>

     <br>
     Thanks, Simon!<br>
     <br>
     <span style="font-weight: bold;"><a name=
    "2_2_0_RC3"></a>12/30/2004 - Shorewall 2.2.0 RC3<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>The following error message could appear during
      "shorewall stop" or "shorewall clear":<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      local: lo:: bad variable name<br>
      <br>
      </li>

      <li>The rate limiting example in /etc/shorewall/rules has
      been changed to use the RATE LIMIT column.</li>

      <li>Entries in /etc/shorewall/masq with the INTERFACE column
      containing &lt;ifname&gt;:: (e.g., "eth0::") would generate a
      progress message but would not generate an iptables
      rule.</li>

      <li>A misleading typo in /etc/shorewall/tunnels has been
      corrected.<br>
      </li>
    </ol>

    <p><br>
    </p>

    <p><span style="font-weight: bold;">12/24/2004 - Shorewall
    2.2.0 RC2<br>
    <br>
    </span> New Features:<br>
    </p>

    <ol>
      <li>By popular demand, the default port for Open VPN tunnels
      is now 1194 (the IANA-reserved port number for Open
      VPN).</li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_RC1"></a>12/19/2004 - Shorewall 2.2.0 RC1<br>
    <br>
    </span> Problems Corrected:<br>


    <ol>
      <li>The syntax of the add and delete command has been
      clarified in the help summary produced by
      /sbin/shorewall.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>
        TCP OpenVPN tunnels are now supported using the 'openvpn'
        tunnel type. OpenVPN entries in /etc/shorewall/tunnels have
        this format:<br>
        <br>
         &nbsp;&nbsp;&nbsp;
        openvpn[:{tcp|udp}][:&lt;port&gt;]&nbsp;&nbsp;&nbsp;
        &lt;zone&gt;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
        &lt;gateway&gt;<br>
        <br>
         Examples:<br>

<pre>
    openvpn:tcp         net    1.2.3.4    # TCP tunnel on port 5000<br>
    openvpn:3344        net    1.2.3.4    # UDP on port 3344<br>
    openvpn:tcp:4455    net    1.2.3.4    # TCP on port 4455
</pre>
      </li>

      <li>A new 'ipsecvpn' script is included in the tarball and in
      the RPM. The RPM installs the file in the Documentation
      directory (/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
      <br>
       This script is intended for use on Roadwarrior laptops for
      establishing an IPSEC SA to/from remote networks. The script
      has some limitations:<br>
      <br>
       &nbsp;&nbsp;&nbsp; - Only one instance of the script may be
      used at a time.<br>
       &nbsp;&nbsp;&nbsp; - Only the first SPD accessed will be
      instantiated at the remote gateway. So while the script
      creates SPDs to/from the remote gateway and each network
      listed in the NETWORKS setting at the front of the script,
      only one of these may be used at a time.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta8"></a>12/11/2004 - Shorewall 2.2.0 Beta 8<br>
    <br>
    </span> Problems Corrected:<br>


    <ol>
      <li>A typo in the /etc/shorewall/interfaces file has been
      corrected.</li>

      <li>Previously, the "add" and "delete" commands were
      generating incorrect policy matches when policy match support
      was available.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>Recent 2.6 kernels include code that evaluates TCP
      packets based on TCP Window analysis. This can cause packets
      that were previously classified as NEW or ESTABLISHED to be
      classified as INVALID.<br>
      <br>
       The new kernel code can be disabled by including this
      command in your /etc/shorewall/init file:<br>
      <br>
       &nbsp;&nbsp;&nbsp; echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal<br>
      <br>
       Additional kernel logging about INVALID TCP packets may be
      obtained by adding this command to /etc/shorewall/init:<br>
      <br>
       &nbsp;&nbsp;&nbsp; echo 1 &gt;
      /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid<br>
      <br>
       Traditionally, Shorewall has dropped INVALID TCP packets
      early. The new DROPINVALID option allows INVALID packets to
      be passed through the normal rules chains by setting
      DROPINVALID=No.<br>
      <br>
       If not specified or if specified as empty (e.g.,
      DROPINVALID="") then DROPINVALID=Yes is assumed.<br>
      <br>
      </li>

      <li>The "shorewall add" and "shorewall delete" commands now
      accept a list of hosts to add or delete.<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp; shorewall add eth1:1.2.3.4 eth1:2.3.4.5
      z12<br>
       &nbsp;&nbsp;&nbsp; shorewall delete eth1:1.2.3.4
      eth1:2.3.4.5 z12<br>
      <br>
       The above commands may also be written:<br>
      <br>
       &nbsp;&nbsp;&nbsp; shorewall add eth1:1.2.3.4,2.3.4.5
      z12<br>
       &nbsp;&nbsp;&nbsp; shorewall delete eth1:1.2.3.4,2.3.4.5
      z12<br>
       &nbsp;&nbsp;<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta7"></a>12/04/2004 - Shorewall 2.2.0 Beta 7<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>The "shorewall add" and "shorewall delete" commands now
      work in a bridged environment. The syntax is:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall add
      &lt;interface&gt;[:&lt;port&gt;]:&lt;address&gt;
      &lt;zone&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall delete
      &lt;interface&gt;[:&lt;port&gt;]:&lt;address&gt;
      &lt;zone&gt;<br>
       &nbsp;<br>
       &nbsp;&nbsp; Examples:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall add br0:eth2:192.168.1.3 OK<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall delete br0:eth2:192.168.1.3 OK<br>
      <br>
      </li>

      <li>Previously, "shorewall save" created an out-of-sequence
      restore script. The commands saved in the user's
      /etc/shorewall/start script were executed prior to the
      Netfilter configuration being restored. This has been
      corrected so that "shorewall save" now places those commands
      at the end of the script.<br>
      <br>
       To accomplish this change, the "restore base" file
      (/var/lib/shorewall/restore-base) has been split into two
      files:<br>
       &nbsp;<br>
       /var/lib/shorewall/restore-base -- commands to be executed
      before Netfilter the configuration is restored.<br>
       &nbsp;<br>
       /var/lib/shorewall/restore-tail -- commands to be executed
      after the Netfilter configuration is restored.<br>
      <br>
      </li>

      <li>Previously, traffic from the firewall to a dynamic zone
      member host did not need to match the interface specified
      when the host was added to the zone. For example, if
      eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
      any firewall interface to 1.2.3.4 will obey the fw-&gt;Z
      policies and rules. This has been corrected.</li>

      <li>Shorewall uses the temporary chain 'fooX1234' to probe
      iptables for detrmining which features are supported.
      Previously, if that chain happened to exist when Shorewall
      was run, capabilities were mis-detected.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>You can now use the "shorewall show zones" command to
      display the current contents of the zones. This is
      particularly useful if you use dynamic zones
      (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp; Example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ursa:/etc/shorewall # shorewall show zones<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST
      2004<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth0:192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth1:1.2.3.4<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; net<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth0:0.0.0.0/0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; WiFi<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth1:0.0.0.0/0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sec<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth1:0.0.0.0/0<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ursa:/etc/shorewall #<br>
      <br>
      </li>

      <li>Variable expansion may now be used with the INCLUDE
      directive.<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp; Example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/params<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      FILE=/etc/foo/bar<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config
      file:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      INCLUDE $FILE<br>
      <br>
      </li>

      <li>The output of "shorewall status" now includes the results
      of "ip -stat link ls". This helps diagnose performance
      problems caused by link errors.</li>

      <li>Previously, when rate-limiting was specified in
      /etc/shorewall/policy (LIMIT:BURST column), any traffic which
      exceeded the specified rate was silently dropped. Now, if a
      log<br>
       level is given in the entry (LEVEL column) then drops are
      logged at that level at a rate of 5/min with a burst of
      5.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_0_13"></a>12/02/2004 - Shorewall 2.0.13<br>
    <br>
    </span> Problems Corrected:<br>


    <ol>
      <li>
        A typo in /usr/share/shorewall/firewall caused the
        "shorewall add" to issue an error message:<br>

<pre class="programlisting">
/usr/share/shorewall/firewall: line 1: match_destination_hosts: command not found
</pre>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_0_12"></a>12/01/2004 - Shorewall 2.0.12<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>A typo in shorewall.conf (NETNOTSYN) has been
      corrected.</li>

      <li>The "shorewall add" and "shorewall delete" commands now
      work in a bridged environment. The syntax is:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall add
      &lt;interface&gt;[:&lt;bridge port&gt;][:&lt;address&gt;]
      &lt;zone&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall delete
      &lt;interface&gt;[:&lt;bridge port&gt;][:&lt;address&gt;]
      &lt;zone&gt;<br>
       &nbsp;<br>
       Examples:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall add
      br0:eth2:192.168.1.3 OK<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; shorewall delete
      br0:eth2:192.168.1.3 OK<br>
      <br>
      </li>

      <li>Previously, "shorewall save" created an out-of-sequence
      restore script. The commands saved in the user's
      /etc/shorewall/start script were executed prior to the
      Netfilter configuration being restored. This has been
      corrected so that "shorewall save" now places those commands
      at the end of the script.<br>
       &nbsp;<br>
       To accomplish this change, the "restore base" file
      (/var/lib/shorewall/restore-base) has been split into two
      files:<br>
       &nbsp;<br>
       &nbsp;&nbsp; /var/lib/shorewall/restore-base -- commands to
      be executed before the Netfilter configuration is
      restored.<br>
       &nbsp;<br>
       &nbsp;&nbsp; /var/lib/shorewall/restore-tail -- commands to
      be executed after the Netfilter configuration is
      restored.<br>
      <br>
      </li>

      <li>Previously, traffic from the firewall to a dynamic zone
      member host did not need to match the interface specified
      when the host was added to the zone. For example, if
      eth0:1.2.3.4 is added to dynamic zone Z then traffic out of
      any firewall interface to 1.2.3.4 will obey the fw-&gt;Z
      policies and rules. This has been corrected.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>Variable expansion may now be used with the INCLUDE
      directive.<br>
       &nbsp;<br>
       Example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /etc/shorewall/params<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      FILE=/etc/foo/bar<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any other config
      file:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      INCLUDE $FILE<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta6"></a>11/26/2004 - Shorewall 2.2.0 Beta 6<br>
    <br>
    </span> Beta 5 was more or less DOA. Here's Beta 6.<br>
     <br>
     Problems Corrected:<br>


    <ol>
      <li>Fixed a number of problems associated with not having an
      IPTABLES value assigned in shorewall.conf</li>

      <li>Corrected a 'duplicate chain' error on "shorewall add"
      when the 'mss' option is present in /etc/shorewall/ipsec.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta5"></a>11/26/2004 - Shorewall 2.2.0 Beta 5<br>
    </span> <br>
     Problems corrected:<br>


    <ol>
      <li>A typo in shorewall.conf (NETNOTSYN) has been
      corrected.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>For consistency, the CLIENT PORT(S) column in the tcrules
      file has been renamed SOURCE PORT(S).</li>

      <li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is
      now shown in the output of "shorewall status".</li>

      <li>A new IPTABLES option has been added to shorewall.conf.
      IPTABLES can be used to designate the iptables executable to
      be used by Shorewall. If not specified, the iptables
      executable determined by the PATH setting is used.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_0_11"></a>11/23/2004 - Shorewall 2.0.11<br>
    </span> <br>
     Problems corrected:<br>


    <ol>
      <li>The INSTALL file now include special instructions for
      Slackware users.</li>

      <li>The bogons file has been updated.</li>

      <li>Service names are replaced by port numbers in
      /etc/shorewall/tos.</li>

      <li>A typo in the install.sh file that caused an error during
      a new install has been corrected.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>The AllowNNTP action now allows NNTP over SSL/TLS
      (NTTPS).<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta4"></a>11/19/2004 - Shorewall 2.2.0 Beta 4<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>A cut and paste error resulted in some nonsense in the
      description of the IPSEC column in /etc/shorewall/masq.</li>

      <li>A typo in /etc/shorewall/rules has been corrected.</li>

      <li>The bogons file has been updated.</li>

      <li>The "shorewall add" command previously reported success
      but did nothing -- now it works.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>The AllowNNTP action now allows NNTP over SSL/TLS
      (NNTPS).<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta3"></a>11/09/2004 - Shorewall 2.2.0 Beta 3<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>Missing '#' in the rfc1918 file has been corrected.</li>

      <li>The INSTALL file now includes special instructions for
      Slackware users.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>
        In CLASSIFY rules (/etc/shorewall/tcrules), an interface
        name may now appear in the DEST column as in:<br>

<pre>
        #MARK/      SOURCE       DEST      PROTO     PORT(S)<br>
        #CLASSIFY<br>
        1:30        -            eth0      tcp       25
</pre>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_2_0_Beta2"></a>11/02/2004 - Shorewall 2.2.0 Beta 2<br>
    <br>
    </span> Problems Corrected:<br>


    <ol>
      <li>The "shorewall check" command results in the (harmless)
      error message:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      /usr/share/shorewall/firewall: line 2753:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      check_dupliate_zones: command not found<br>
      <br>
      </li>

      <li>The AllowNTP standard action now allows outgoing
      responses to broadcasts.</li>

      <li>A clarification has been added to the hosts file's
      description of the 'ipsec' option pointing out that the
      option is redundent if the zone named in the ZONE column has
      been designated an IPSEC zone in the /etc/shorewall/ipsec
      file.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>The SUBNET column in /etc/shorewall/rfc1918 has been
      renamed SUBNETS and it is now possible to specify a list of
      addresses in that column.<br>
      </li>
    </ol>
    <span style="font-weight: bold;"><a name=
    "2_0_10"></a>10/25/2004 - Shorewall 2.0.10<br>
    </span> <br>
     Problems Corrected:<br>


    <ol>
      <li>The GATEWAY column was previously ignored in 'pptpserver'
      entries in /etc/shorewall/tunnels.</li>

      <li>When log rule numbers are included in the LOGFORMAT,
      duplicate rule numbers could previously be generated.</li>

      <li>The /etc/shorewall/tcrules file now includes a note to
      the effect that rule evaluation continues after a match.</li>

      <li>The error message produced if Shorewall couldn't obtain
      the routes through an interface named in the SUBNET column of
      /etc/shorewall/masq was less than helpful since it didn't
      include the interface name.<br>
      </li>
    </ol>
    New Features:<br>


    <ol>
      <li>The "shorewall status" command has been enhanced to
      include the values of key /proc settings:<br>
      <br>
       Example from a two-interface firewall:<br>
      <br>
       /proc<br>
      <br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/ip_forward = 1<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/proxy_arp = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/arp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/all/rp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/proxy_arp =
      0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/arp_filter =
      0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/default/rp_filter =
      0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/proxy_arp = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/arp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth0/rp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/proxy_arp = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/arp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/eth1/rp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/proxy_arp = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/arp_filter = 0<br>
       &nbsp;&nbsp; /proc/sys/net/ipv4/conf/lo/rp_filter = 0<br>
      </li>
    </ol>
    <br>
     <span style="font-weight: bold;"><a name=
    "2_2_0_Beta1"></a>10/24/2004 - Shorewall 2.2.0 Beta1<br>
    <br>
    </span> The first beta in the 2.2 series is now available.
    Download location is:<br>
     <br>


    <div style="margin-left: 40px;">
      <a href=
      "http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">
      http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>

       <a target="_top" href=
      "ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1">
      ftp://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1</a><br>

    </div>

    <p>The features available in this release and the migration
    considerations are covered in the <a href=
    "http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-Beta1/releasenotes.txt">
    release notes</a>. Highlights include:<br>
    </p>

    <ol>
      <li>The behavior produced by specifying a log level in an
      action invocation is now much more rational. Previously, all
      packets sent to the action were logged; now each rule within
      the invoked action behaves as if logging had been specified
      on it.</li>

      <li>Support for the 2.6 Kernel's native IPSEC implementation
      is now available.</li>

      <li>Support for ipp2p is included.</li>

      <li>Support for the iptables CONNMARK facility is now
      included in Shorewall.</li>

      <li>A new LOGALLNEW option facilitates problem analysis.</li>

      <li>Users with a large static blacklist can now defer loading
      the blacklist until after the rest of the ruleset has been
      enabled. Doing so can decrease substantially the amount of
      time that connections are disabled during <span style=
      "font-weight: bold;">shorewall [re]start</span>.</li>

      <li>Support for the iptables 'iprange match' feature has been
      enabled. Users whose kernel and iptables contain this feature
      can use ip address ranges in most places in their Shorewall
      configuration where a CIDR netowrk can be used.</li>

      <li>Accepting of source routing and martian logging may now
      be enabled/disabled on each interface.</li>

      <li>Shorewall now supports the CLASSIFY iptable target.</li>
    </ol>

    <p><span style="font-weight: bold;"><a name=
    "2_0_9"></a>9/23/2004 - Shorewall 2.0.9<br>
    </span><br>
     Problems Corrected:<br>
    </p>

    <ol>
      <li>Previously, an empty PROTO column or a value of "all" in
      that column would cause errors when processing the
      /etc/shorewall/tcrules file.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>The "shorewall status" command now includes the output of
      "brctl show" if the bridge tools are installed.<br>
      </li>
    </ol>

    <p><a name="SupportChange"><b>9/20/2004 – Change in Shorewall
    Support</b></a></p>

    <p style="">Friends,</p>

    <p style="">The demands that my job and my personal life are
    currently placing on me are such that supporing Shorewall to
    the extent that I have been doing is just not possible any
    more.</p>

    <p style="">I will continue to be active on the development
    list and will continue to develop Shorewall if at all
    possible.</p>

    <p style="">I will also continue to read the user's list and
    will help with problems that interest me. But I am no longer
    going to hop on every problem as soon as I see it.</p>

    <p style="">This change means that I'm going to have to depend
    on you folks to help each other; I'm confident that we can make
    this work.</p>

    <p><a name="2_0_8"></a><b>8/22/2004 - Shorewall 2.0.8<br>
    </b><br>
     Problems Corrected:</p>

    <ol>
      <li>
        <p>Entries in the USER/GROUP column of an action file (made
        from action.template) may be ignored or cause odd
        errors.</p>
      </li>
    </ol>

    <p><a name="2_0_7"></a><b>7/29/2004 - Shorewall 2.0.7<br>
    <br>
    </b> Problems Corrected:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">The PKTTYPE option
        introduced in version 2.0.6 is now used when generating
        rules to REJECT packets. Broadcast packets are silently
        dropped rather than being rejected with an ICMP (which is a
        protocol violation) and users whose kernels have broken
        packet type match support are likely to see messages
        reporting this violation. Setting PKTTYPE=No should cause
        these messages to cease.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Multiple interfaces with the
        'blacklist' option no longer result in an error message at
        startup.</p>
      </li>

      <li>
        <p>The following has been added to
        /etc/shorewall/bogons:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0.0.0.0&nbsp;&nbsp;
        RETURN<br>
        <br>
         This prevents the 'nobogons' option from logging DHCP
        'DISCOVER' broadcasts.</p>
      </li>
    </ol>

    <p>New Features:</p>

    <ol>
      <li>
        <p>To improve supportability, the "shorewall status"
        command now includes IP and Route configuration
        information.<br>
        <br>
         &nbsp;&nbsp; Example:<br>
        <br>
         &nbsp;&nbsp; <font face="monospace">IP
        Configuration</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">1: lo:
        &lt;LOOPBACK,UP&gt; mtu 16436 qdisc noqueue</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/loopback 00:00:00:00:00:00 brd
        00:00:00:00:00:00</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet
        127.0.0.1/8 brd 127.255.255.255 scope host lo</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">inet6 ::1/128 scope host</font><br>
         &nbsp;&nbsp; <font face="monospace">2: eth0:
        &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc
        pfifo_fast qlen 1000</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/ether 00:a0:c9:15:39:78 brd
        ff:ff:ff:ff:ff:ff</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">inet6 fe80::2a0:c9ff:fe15:3978/64 scope
        link</font><br>
         &nbsp;&nbsp; <font face="monospace">3: eth1:
        &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc
        pfifo_fast qlen 1000</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/ether 00:a0:c9:a7:d7:bf brd
        ff:ff:ff:ff:ff:ff</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">inet6 fe80::2a0:c9ff:fea7:d7bf/64 scope
        link</font><br>
         &nbsp;&nbsp; <font face="monospace">5: sit0@NONE:
        &lt;NOARP&gt; mtu 1480 qdisc noop</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/sit 0.0.0.0 brd 0.0.0.0</font><br>
         &nbsp;&nbsp; <font face="monospace">6: eth2:
        &lt;BROADCAST,MULTICAST,PROMISC,UP&gt; mtu 1500 qdisc
        pfifo_fast qlen 1000</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/ether 00:40:d0:07:3a:1b brd
        ff:ff:ff:ff:ff:ff</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">inet6 fe80::240:d0ff:fe07:3a1b/64 scope
        link</font><br>
         &nbsp;&nbsp; <font face="monospace">7: br0:
        &lt;BROADCAST,MULTICAST,NOTRAILERS,UP&gt; mtu 1500 qdisc
        noqueue</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">link/ether 00:40:d0:07:3a:1b brd
        ff:ff:ff:ff:ff:ff</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="monospace">inet
        192.168.1.3/24 brd 192.168.1.255 scope global
        br0</font><br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face=
        "monospace">inet6 fe80::240:d0ff:fe07:3a1b/64 scope
        link</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">Routing
        Rules</font><br>
        <br>
         &nbsp;&nbsp; <font face=
        "monospace">0:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from all
        lookup local</font><br>
         &nbsp;&nbsp; <font face="monospace">32765:&nbsp; from all
        fwmark&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ca lookup
        www.out</font><br>
         &nbsp;&nbsp; <font face="monospace">32766:&nbsp; from all
        lookup main</font><br>
         &nbsp;&nbsp; <font face="monospace">32767:&nbsp; from all
        lookup default</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">Table
        local:</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">broadcast 192.168.1.0
        dev br0&nbsp; proto kernel&nbsp; scope link&nbsp; src
        192.168.1.3</font><br>
         &nbsp;&nbsp; <font face="monospace">broadcast
        127.255.255.255 dev lo&nbsp; proto kernel&nbsp; scope
        link&nbsp; src 127.0.0.1</font><br>
         &nbsp;&nbsp; <font face="monospace">local 192.168.1.3 dev
        br0&nbsp; proto kernel&nbsp; scope host&nbsp; src
        192.168.1.3</font><br>
         &nbsp;&nbsp; <font face="monospace">broadcast
        192.168.1.255 dev br0&nbsp; proto kernel&nbsp; scope
        link&nbsp; src 192.168.1.3</font><br>
         &nbsp;&nbsp; <font face="monospace">broadcast 127.0.0.0
        dev lo&nbsp; proto kernel&nbsp; scope link&nbsp; src
        127.0.0.1</font><br>
         &nbsp;&nbsp; <font face="monospace">local 127.0.0.1 dev
        lo&nbsp; proto kernel&nbsp; scope host&nbsp; src
        127.0.0.1</font><br>
         &nbsp;&nbsp; <font face="monospace">local 127.0.0.0/8 dev
        lo&nbsp; proto kernel&nbsp; scope host&nbsp; src
        127.0.0.1</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">Table
        www.out:</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">default via
        192.168.1.3 dev br0</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">Table main:</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">192.168.1.0/24 dev
        br0&nbsp; proto kernel&nbsp; scope link&nbsp; src
        192.168.1.3</font><br>
         &nbsp;&nbsp; <font face="monospace">default via
        192.168.1.254 dev br0</font><br>
        <br>
         &nbsp;&nbsp; <font face="monospace">Table
        default:</font></p>
      </li>
    </ol>

    <p><a name="2_0_6"></a><b>7/16/2004 - Shorewall 2.0.6<br>
    <br>
    </b> Problems Corrected:</p>

    <ul>
      <li>
        <p style="margin-bottom: 0in;">Some users have reported the
        packet type match option in iptables/Netfilter failing to
        match certain broadcast packets. The result is that the
        firewall log shows a lot of broadcast packets.<br>
        <br>
         Other users have complained of the following message when
        starting Shorewall:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        modprobe: cant locate module ipt_pkttype<br>
        <br>
         Users experiencing either of these problems can use
        PKTTYPE=No in shorewall.conf to cause Shorewall to use IP
        address filtering of broadcasts rather than packet
        type.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The shorewall.conf and zones
        file are no longer given execute permission by the
        installer script.</p>
      </li>

      <li>
        <p>ICMP packets that are in the INVALID state are now
        dropped by the Reject and Drop default actions. They do so
        using the new 'dropInvalid' builtin action.</p>
      </li>
    </ul>

    <p><a name="2_0_5"></a><b>7/10/2004 - Shorewall 2.0.5<br>
    </b><br>
     Problems Corrected:</p>

    <ul>
      <li>
        <p style="margin-bottom: 0in;">If DISABLE_IPV6=Yes in
        shorewall.conf then harmless error messages referring to
        $RESTOREBASE are generated during <b>shorewall
        stop</b>.</p>
      </li>

      <li>
        <p>An anachronistic comment concerning a mangle option has
        been removed from shorewall.conf.</p>
      </li>
    </ul>

    <p><a name="2_0_4"></a><b>7/06/2004 - Shorewall 2.0.4<br>
    </b><br>
     Problems Corrected:</p>

    <ul>
      <li>
        <p>Rules with $FW as the source zone and that specify
        logging can cause "shorewall start" to fail.</p>
      </li>
    </ul>

    <p><a name="Release_Model"></a><b>7/03/2004 - New Shorewall
    Release Model<br>
    <br>
    </b> Effective today, Shorewall is adopting a new release model
    which takes ideas from the one used in the Linux Kernel and
    from the release model for Postfix.</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">Releases continue to have a
        three-level identification <i>x.y.z</i> (e.g., 2.0.3).</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The first two levels
        (<i>x.y)</i> designate the <i>Major Release Number</i>
        (e.g., 2.0)</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The third level (<i>z</i>)
        designates the <i>Minor Release Number</i>.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Even numbered major releases
        (e.g., <i>1.4, 2.0, 2.2, ...)</i> are <i>Stable
        Releases</i>. No new features are added to stable releases
        and new minor releases of a stable release will only
        contain bug fixes. Installing a new minor release for the
        major release that you are currently running involves no
        migration issues (for example, if you are running 1.4.10
        and I release 1.4.11, your current configuration is 100%
        compatible with the new release).</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Support is available through
        the <a href="http://lists.shorewall.net/">Mailing List</a>
        for the two most recent Stable Releases.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Odd numbered major releases
        (e.g., 2.1, 2.3, ...) are <i>Development Releases</i>.
        Development releases are where new functionality is
        introduced. Documentation for new features will be
        available but it may not be up to the standards of the
        stable release documentation. Sites running Development
        Releases should be prepared to play an active role in
        testing new features. Bug fixes and problem resolution for
        the development release take a back seat to support of the
        stable releases. Problem reports for the current
        development release should be sent to the <a href=
        "mailto:shorewall-devel@lists.shorewall.net">Shorewall
        Development Mailing List</a>.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">When the level of
        functionality of the current development release is judged
        adaquate, the Beta period for a new Stable release will
        begin. Beta releases have identifications of the form
        <i>x.y.0-BetaN</i> where <i>x.y</i> is the number of the
        next Stable Release and <i>N</i>=1,2,3... . Betas are
        expected to occur rougly once per year. Beta releases may
        contain new functionality not present in the previous beta
        release (e.g., 2.2.0-Beta4 may contain functionality not
        present in 2.2.0-Beta3). When I'm confident that the
        current Beta release is stable, I will release the first
        <i>Release Candidate.</i> Release candidates have
        identifications of the form <i>x.y.0-RCn</i> where
        <i>x.y</i> is the number of the next Stable Release and
        <i>n</i>=1,2,3... . Release candidates contain no new
        functionailty -- they only contain bug fixes. When the
        stability of the current release candidate is judged to be
        sufficient then that release candidate will be released as
        the new stable release (e.g., 2.2.0). At that time, the new
        stable release and the prior stable release are those that
        are supported.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">What does it mean for a
        major release to be <i>supported?</i> It means that I will
        answer questions about the release and that if a bug is
        found, I will fix the bug and include the fix in the next
        minor release.</p>
      </li>

      <li>
        <p>Between minor releases, bug fixes will continue to be
        made available through the Errata page for each major
        release.</p>
      </li>
    </ol>

    <p>The immediate implications of this change are as
    follows:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">The functionality of the 2.0
        major release is frozen at the level of minor release
        2.0.3.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The two major releases
        currently supported are 1.4 and 2.0.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">I will be opening the 2.1
        development release shortly with the release of 2.1.0.</p>
      </li>

      <li>
        <p>Bug-fix releases with identifications of the form
        <i>x.y.zX</i> where X=a,b,c,... (e.g., 2.0.3c) will not be
        seen in the future.</p>
      </li>
    </ol>

    <p><a name="2_0_3c"></a><b>7/02/2004 - Shorewall 2.0.3c<br>
    <br>
    </b> Problems Corrected<b>:</b></p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">Error messages regarding
        $RESTOREBASE occur during <b>shorewall stop</b></p>
      </li>

      <li>
        <p>If CLEAR_TC=Yes in <tt>shorewall.conf</tt>, <b>shorewall
        stop</b> fails without removing the lock file.</p>
      </li>
    </ol>

    <p><a name="2_0_3b"></a><b><br>
     6/30/2004 - Shorewall 2.0.3b and Shorewall 1.4.10g<br>
    <br>
    </b> Problems Corrected:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">The security vulnerability
        fix released in Shorewall 2.0.3a failed under Slackware
        9.1.</p>
      </li>

      <li>
        <p>The security vulnerability fix released in Shorewall
        2.0.3a failed if mktemp was not installed.</p>
      </li>
    </ol>

    <p><a name="2_0_3a"></a><b>6/28/2004 - Shorewall 2.0.3a and
    Shorewall 1.4.10f<br>
    <br>
    </b> Problems Corrected:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">Javier Fernández-Sanguino
        Peña has discovered an exploitable vulnerability in the way
        that Shorewall handles temporary files and directories. The
        vulnerability can allow a non-root user to cause arbitrary
        files on the system to be overwritten. LEAF Bering and
        Bering uClibc users are generally not at risk due to the
        fact that LEAF boxes do not typically allow logins by
        non-root users.</p>
      </li>

      <li>
        <p>(2.0.3a only) A non-empty DEST entry in
        /etc/shorewall/tcrules will generate an error and Shorewall
        fails to start.</p>
      </li>
    </ol>

    <p style="margin-left: 0.42in;">Note:: Slackware users may need
    the 'functions' file from CVS (STABLE/ project for 1.4.10f and
    STABLE2/ project for 2.0.3a) to prevent startup errors with
    these versions installed. These updatged files are also
    available from the Errata (<a href="errata.htm">2.0,</a> <a
    href="1.4/errata.htm">1.4</a>).</p>

    <p><a name="2_0_3"></a><b>6/23/2004 - Shorewall 2.0.3<br>
    <br>
    </b> Problems Corrected:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">The 'firewall' script is not
        purging temporary restore files in /var/lib/shorewall.
        These files have names of the form "restore-nnnnn".</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The
        /var/lib/shorewall/restore script did not load the kernel
        modules specified in /etc/shorewall/modules.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Specifying a null common
        action in /etc/shorewall/actions (e.g., :REJECT) results in
        a startup error.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">If /var/lib/shorewall does
        not exist, shorewall start fails.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">DNAT rules with a dynamic
        source zone don't work properly. When used, these rules
        cause the rule to be checked against ALL input, not just
        input from the designated zone.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The install.sh script
        reported installing some files in /etc/shorewall when the
        files were actually installed in /usr/share/shorewall.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Shorewall checks netfilter
        capabilities before loading kernel modules. Hence if kernel
        module autoloading isn't enabled, the capabilities will be
        misdetected.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The 'newnotsyn' option in
        /etc/shorewall/hosts has no effect.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">The file
        /etc/init.d/shorewall now gets proper ownership when the
        RPM is built by a non-root user.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Rules that specify bridge
        ports in both the SOURCE and DEST columns no longer cause
        "shorewall start" to fail.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Comments in the rules file
        have been added to advise users that "all" in the SOURCE or
        DEST column does not affect intra-zone traffic.</p>
      </li>

      <li>
        <p>With BLACKLISTNEWONLY=Yes, ICMP packets with state
        INVALID are now passed through the blacklisting chains.
        Without this change, it is not possible to blacklist hosts
        that are mounting certain types of ICMP-based DOS
        attacks.</p>
      </li>
    </ol>

    <p>Issues when migrating from Shorewall 2.0.2 to Shorewall
    2.0.3:</p>

    <ol>
      <li>
        <p>The 'dropNonSyn' standard builtin action has been
        replaced with the 'dropNotSyn' standard builtin action. The
        old name can still be used but will generate a warning.</p>
      </li>
    </ol>

    <p>New Features:</p>

    <ol>
      <li>
        <p style="margin-bottom: 0in;">Shorewall now supports
        multiple saved configurations.</p>

        <ol>
          <li>
            <p style="margin-bottom: 0in;">The default saved
            configuration (restore script) in /var/lib/shorewall is
            now specified using the RESTOREFILE option in
            shorewall.conf. If this variable isn't set then to
            maintain backward compatibility, 'restore' is
            assumed.<br>
            <br>
             The value of RESTOREFILE must be a simple file name;
            no slashes ("/") may be included.</p>
          </li>

          <li>
            <p style="margin-bottom: 0in;">The "save" command has
            been extended to be able to specify the name of a saved
            configuration.<br>
            <br>
             &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            shorewall save [ &lt;file name&gt; ]<br>
            <br>
             The current state is saved to
            /var/lib/shorewall/&lt;file name&gt;. If no &lt;file
            name&gt; is given, the configuration is saved to the
            file determined by the RESTOREFILE setting.</p>
          </li>

          <li>
            <p style="margin-bottom: 0in;">The "restore" command
            has been extended to be able to specify the name of a
            saved configuration:<br>
            <br>
             &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            shorewall restore [ &lt;file name&gt; ]<br>
            <br>
             The firewall state is restored from
            /var/lib/shorewall/&lt;file name&gt;. If no &lt;file
            name&gt; is given, the firewall state is restored from
            the file determined by the RESTOREFILE setting.</p>
          </li>

          <li>
            <p style="margin-bottom: 0in;">The "forget" command has
            changed. Previously, the command unconditionally
            removed the /var/lib/shorewall/save file which records
            the current dynamic blacklist. The "forget" command now
            leaves that file alone.<br>
            <br>
             Also, the "forget" command has been extended to be
            able to specify the name of a saved configuration:<br>
            <br>
             &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
            shorewall forget [ &lt;file name&gt; ]<br>
            <br>
             The file /var/lib/shorewall/&lt;file name&gt; is
            removed. If no &lt;file name&gt; is given, the file
            determined by the RESTOREFILE setting is removed.</p>
          </li>

          <li>
            <p style="margin-bottom: 0in;">The "shorewall -f start"
            command restores the state from the file determined by
            the RESTOREFILE setting.</p>
          </li>
        </ol>
      </li>

      <li>
        <p style="margin-bottom: 0in;">"!" is now allowed in
        accounting rules.</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">Interface names appearing
        within the configuration are now verified. Interface names
        must match the name of an entry in
        /etc/shorewall/interfaces (or if bridging is enabled, they
        must match the name of an entry in
        /etc/shorewall/interfaces or the name of a bridge port
        appearing in /etc/shorewall/hosts).</p>
      </li>

      <li>
        <p style="margin-bottom: 0in;">A new 'rejNotSyn' built-in
        standard action has been added. This action responds to
        "New not SYN" packets with an RST.<br>
        <br>
         The 'dropNonSyn' action has been superceded by the new
        'dropNotSyn' action. The old name will be accepted until
        the next major release of Shorewall but will generate a
        warning.<br>
        <br>
         Several new logging actions involving "New not SYN"
        packets have been added:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        logNewNotSyn&nbsp; -- logs the packet with disposition =
        LOG<br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dLogNewNotSyn
        -- logs the packet with disposition = DROP<br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rLogNewNotSyn
        -- logs the packet with disposition = REJECT<br>
        <br>
         The packets are logged at the log level specified in the
        LOGNEWNOTSYN option in shorewall.conf. If than option is
        empty or not specified, then 'info' is assumed.<br>
        <br>
         Examples (In all cases, set NEWNOTSYN=Yes in
        shorewall.conf):</p>

        <ol>
          <li>
            <p style="margin-bottom: 0in;">To simulate the behavior
            of NEWNOTSYN=No:</p>

            <ol>
              <li>
                <p style="margin-bottom: 0in;">Add 'NoNewNotSyn' to
                /etc/shorewall/actions.</p>
              </li>

              <li>
                <p>Create /etc/shorewall/action.NoNewNotSyn
                containing:<br>
                <br>
                 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
                dLogNotSyn<br>
                 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
                dropNotSyn</p>
              </li>

              <li>
                <p>Early in your rules file, place:<br>
                <br>
                 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
                NoNewNotSyn&nbsp;&nbsp; all&nbsp;&nbsp;
                all&nbsp;&nbsp;&nbsp;&nbsp; tcp</p>
              </li>
            </ol>
          </li>

          <li>
            <p style="margin-bottom: 0in;">Drop 'New not SYN'
            packets from the net only. Don't log them:</p>

            <ol>
              <li>
                <p>Early in your rules file, place:<br>
                <br>
                 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
                dropNotSyn&nbsp;&nbsp;&nbsp;
                net&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
                all&nbsp;&nbsp; tcp</p>
              </li>
            </ol>
          </li>
        </ol>
      </li>

      <li>
        <p>Slackware users no longer have to modify the install.sh
        script before installation. Tuomo Soini has provided a
        change that allows the INIT and FIREWALL variables to be
        specified outside the script as in:<br>
        <br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST=/etc/rc.d
        INIT=rc.firewall ./install.sh</p>
      </li>
    </ol>

    <p><b>6/3/2004 - Shorewall 2.0.2f<br>
    </b></p>

    <p>Fixes one problem:<br>
    </p>

    <ol>
      <li>Versions 2.0.2d and 2.0.2e fail to load kernel modules
      unless MODULE_SUFFIX is set in shorewall.conf<br>
      </li>
    </ol>

    <p><b>6/2/2004 - Shorewall 2.0.2e<br>
    </b></p>

    <p>One problem corrected:<br>
    </p>

    <ol>
      <li>LOG rules within an action generate two Netfilter logging
      rules.<br>
      </li>
    </ol>

    <p><b>5/28/2004 - Shorewall 2.0.2d<br>
    </b><br>
     One problem corrected:<br>
    </p>

    <ol>
      <li>Shorewall was checking capabilities before loading kernel
      modules. Consequently, if kernel module autoloading was
      disabled, the capabilities were mis-detected.<br>
      </li>
    </ol>

    <p><b>5/21/2004 - Shorewall 2.0.2c</b></p>
    One problem corrected:<br>


    <ol>
      <li>&nbsp;DNAT rules with a dynamic source zone don't work
      properly. When used, these rules cause the rule to be checked
      against ALL input,&nbsp; not just input from the designated
      zone.<br>
      </li>
    </ol>

    <p><b>5/18/2004 - Shorewall 2.0.2b</b><b>&nbsp;</b></p>

    <p>Corrects two problems:</p>

    <ol>
      <li>Specifying a null common action in /etc/shorewall/actions
      (e.g., :REJECT) results in a startup error.<br>
      <br>
      </li>

      <li>If /var/lib/shorewall does not exist, shorewall start
      fails.<br>
      </li>
    </ol>

    <p><b>5/15/2004 - Shorewall 2.0.2a</b><br>
    </p>

    <p>Corrects two problems:<br>
    </p>

    <ol>
      <li>Temporary restore files were not being removed from
      /var/lib/shorewall. These files have names of the form
      'restore-nnnnn'.&nbsp; You can remove files that have
      accumulated with the command:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;rm -f
      /var/lib/shorewall/restore-[0-9]*<br>
      <br>
      </li>

      <li>The restore script did not load kernel modules. The
      result was that after a cold load, applications like FTP and
      IRC DCC didn't work.<br>
      <br>
       To correct:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;1) Install 2.0.2a<br>
       &nbsp;&nbsp;&nbsp;&nbsp;2) "shorewall restart"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;3) "shorewall save"</li>
    </ol>

    <p><b>5/13/2004 - Shorewall 2.0.2</b><b>&nbsp;</b></p>

    <p>Problems Corrected since 2.0.1<br>
    </p>

    <ol>
      <li>The /etc/init.d/shorewall script installed on Debian by
      install.sh failed silently due to a missing file
      (/usr/share/shorewall/wait4ifup). That file is not part of
      the normal Shorewall distribution and is provided by the
      Debian maintainer.</li>

      <li>A meaningless warning message out of the proxyarp file
      processing has been eliminated.</li>

      <li>The "shorewall delete" command now correctly removes all
      dynamic rules pertaining to the host(s) being deleted. Thanks
      to Stefan Engel for this correction.</li>
    </ol>
    Issues when migrating from Shorewall 2.0.1 to Shorewall
    2.0.2:<br>


    <ol>
      <li>Extension Scripts -- In order for extension scripts to
      work properly with the new iptables-save/restore integration
      (see New Feature 1 below), some change may be required to
      your extension scripts. If your extension scripts are
      executing commands other than iptables then those commands
      must also be written to the restore file (a temporary file in
      /var/lib/shorewall that is renamed
      /var/lib/shorewall/restore-base at the end of the
      operation).<br>
      <br>
       The following functions should be of help:<br>
      <br>
       A. save_command() -- saves the passed command to the restore
      file.<br>
      <br>
       &nbsp;&nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; save_command echo
      Operation Complete<br>
      <br>
       &nbsp;&nbsp; That command would simply write "echo Operation
      Complete" to the restore file.<br>
      <br>
       B. run_and_save_command() -- saves the passed command to the
      restore file then executes it. The return value is the exit
      status of the command.<br>
      <br>
       &nbsp; &nbsp; Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; run_and_save_command
      "echo 1 &gt; /proc/sys/net/ipv4/icmp_echo_ignore_all"<br>
      <br>
       &nbsp;&nbsp;&nbsp; Note that as in this example, when the
      command involves file redirection then the entire command
      must be enclosed in quotes. This applies to all of the
      functions described here.<br>
      <br>
       C. ensure_and_save_command() -- runs the passed command. If
      the command fails, the firewall is restored to it's prior
      saved state and the operation is terminated. If the command
      succeeds, the command is written to the restore file.<br>
      <br>
      </li>

      <li>Dynamic Zone support -- If you don't need to use the
      "shorewall add" and "shorewall delete commands, you should
      set DYNAMIC_ZONES=No in /etc/shorewall/shorewall.conf.</li>
    </ol>
    New Features:<br>


    <ol>
      <li>Shorewall has now been integrated with
      iptables-save/iptables-restore to provide very fast start and
      restart. The elements of this integration are as follows:<br>
      <br>
       a) The 'shorewall save' command now saves the current
      configuration in addition to the current dynamic blacklist.
      If you have dynamic zones, you will want to issue 'shorewall
      save' when the zones are empty or the current contents of the
      zones will be restored by the 'shorewall restore' and
      'shorewall -f start' commands.<br>
      <br>
       b) The 'shorewall restore' command has been added. This
      command restores the configuration at the time of the last
      'save'.<br>
      <br>
       c) The -f (fast) option has been added to 'shorewall start'.
      When specified (e.g. 'shorewall -f start'), shorewall will
      perform a 'shorewall restore' if there is a saved
      configuration. If there is no saved configuration, a normal
      'shorewall start' is performed.<br>
      <br>
       d) The /etc/init.d/shorewall script now translates the
      'start' command into 'shorewall -f start' so that fast
      restart is possible.<br>
      <br>
       e) When a state-changing command encounters an error and
      there is current saved configuration, that configuration will
      be restored (currently, the firewall is placed in the
      'stopped' state).<br>
      <br>
       f) If you have previously saved the running configuration
      and want Shorewall to discard it, use the 'shorewall forget'
      command. WARNING: iptables 1.2.9 is broken with respect to
      iptables-save; if your kernel has connection tracking match
      support, you must patch iptables 1.2.9 with the iptables
      patch availale from the Shorewall errata page.<br>
      <br>
      </li>

      <li>The previous implementation of dynamic zones was
      difficult to maintain. I have changed the code to make
      dynamic zones optional under the control of the DYNAMIC_ZONES
      option in /etc/shorewall/shorewall.conf.<br>
      <br>
      </li>

      <li>In earlier Shorewall 2.0 releases, Shorewall searches in
      order the following directories for configuration files.<br>
      <br>
       a) The directory specified in a 'try' command or specified
      using the -c option.<br>
       b) /etc/shorewall<br>
       c) /usr/share/shorewall<br>
      <br>
       In this release, the CONFIG_PATH option is added to
      shorewall.conf. CONFIG_PATH contains a list of directory
      names separated by colons (":"). If not set or set to a null
      value (e.g., CONFIG_PATH="") then
      "CONFIG_PATH=/etc/shorewall:/usr/share/shorewall" is assumed.
      Now Shorewall searches for shorewall.conf according to the
      old rules and for other configuration files as follows:<br>
      <br>
       a) The directory specified in a 'try' command or specified
      using the -c option.<br>
       b) Each directory in $CONFIG_PATH is searched in
      sequence.<br>
      <br>
       In case it is not obvious, your CONFIG_PATH should include
      /usr/share/shorewall and your shorewall.conf file must be in
      the directory specified via -c or in a try command, in
      /etc/shorewall or in /usr/share/shorewall.<br>
      <br>
       For distribution packagers, the default CONFIG_PATH is set
      in /usr/share/shorewall/configpath. You can customize this
      file to have a default that differs from mine.<br>
      <br>
      </li>

      <li>Previously, in /etc/shorewall/nat a Yes (or yes) in the
      LOCAL column would only take effect if the ALL INTERFACES
      column also contained Yes or yes. Now, the LOCAL columns
      contents are treated independently of the contents of the ALL
      INTERFACES column.<br>
      <br>
      </li>

      <li>The folks at Mandrake have created yet another kernel
      module naming convention (module names end in "ko.gz"). As a
      consequence, beginning with this release, if MODULE_SUFFIX
      isn't specified in shorewall.conf, then the default value is
      "o gz ko o.gz ko.gz".<br>
      <br>
      </li>

      <li>An updated bogons file is included in this release.<br>
      <br>
      </li>

      <li>In /etc/shorewall/rules and in action files generated
      from /usr/share/shorewall/action.template, rules that perform
      logging can specify an optional "log tag". A log tag is a
      string of alphanumeric characters and is specified by
      following the log level with ":" and the log tag.<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT:info:ftp
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 21<br>
      <br>
       The log tag is appended to the log prefix generated by the
      LOGPREFIX variable in /etc/shorewall/conf. If "ACCEPT:info"
      generates the log prefix "Shorewall:net2dmz:ACCEPT:" then
      "ACCEPT:info:ftp" will generate "Shorewall:net2dmz:ACCEPT:ftp
      " (note the trailing blank). The maximum length of a log
      prefix supported by iptables is 29 characters; if a larger
      prefix is generated, Shorewall will issue a warning message
      and will truncate the prefix to 29 characters.<br>
      <br>
      </li>

      <li>A new "-q" option has been added to /sbin/shorewall
      commands. It causes the start, restart, check and refresh
      commands to produce much less output so that warning messages
      are more visible (when testing this change, I discovered a
      bug where a bogus warning message was being generated).<br>
      <br>
      </li>

      <li>Shorewall now uses 'modprobe' to load kernel modules if
      that utility is available in the PATH; otherwise, 'insmod' is
      used.<br>
      <br>
      </li>

      <li>It is now possible to restrict entries in the
      /etc/shorewall/masq file to particular protocols and
      destination port(s). Two new columns (PROTO and PORT(S)) have
      been added to the file.<br>
      <br>
       Example:<br>
      <br>
       You want all outgoing SMTP traffic entering the firewall on
      eth1 to be sent from eth0 with source IP address
      206.124.146.177. You want all other outgoing traffic from
      eth1 to be sent from eth0 with source IP address
      206.124.146.176.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth0&nbsp;&nbsp;&nbsp; eth1&nbsp;&nbsp;&nbsp; 206.124.146.177
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 25<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      eth0&nbsp;&nbsp;&nbsp; eth1&nbsp;&nbsp;&nbsp;
      206.124.146.176<br>
      <br>
       THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!!<br>
      <br>
       Assuming that 10.0.0.0/8 is the only host/network connected
      to eth1, the progress message at "shorewall start" would
      be:<br>
      <br>
       &nbsp;&nbsp;&nbsp; Masqueraded Networks and Hosts:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To 0.0.0.0/0 (tcp 25)
      from 10.0.0.0/8 through eth0 using 206.124.146.177<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To 0.0.0.0/0 (all) from
      10.0.0.0/8 through eth0 using 206.124.146.176<br>
      <br>
      </li>

      <li>Two new actions are available in the /etc/shorewall/rules
      file.<br>
      <br>
       &nbsp;&nbsp;&nbsp; ACCEPT+&nbsp;&nbsp;&nbsp; -- Behaves like
      ACCEPT with the exception that it exempts matching
      connections from subsequent DNAT[-] and REDIRECT[-]
      rules.<br>
       &nbsp;&nbsp;&nbsp; NONAT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --
      Exempts matching connections from subsequent DNAT[-] and
      REDIRECT[-] rules.<br>
      <br>
      </li>

      <li>A new extension script 'initdone' has been added. This
      script is invoked at the same point as the 'common' script
      was previously and is useful for users who mis-used that
      script under Shorewall 1.x (the script was intended for
      adding rules to the 'common' chain but many users treated it
      as a script for adding rules before Shorewall's).<br>
      <br>
      </li>

      <li>Installing/Upgrading Shorewall on Slackware has been
      improved. Slackware users must use the tarball and must
      modify settings in the install.sh script before running it as
      follows:<br>
      <br>
       &nbsp;&nbsp;&nbsp; DEST="/etc/rc.d"<br>
       &nbsp;&nbsp;&nbsp; INIT="rc.firewall"<br>
      <br>
       Thanks to Alex Wilms for helping with this change.</li>
    </ol>

    <p><b>4/17/2004 - Presentation at LinuxFest NW</b><b><br>
    </b></p>
    Today I gave a presentation at LinuxFest NW in Bellingham. The
    presentation was entitled "<a href=
    "http://lists.shorewall.net/Shorewall_and_the_Enterprise.htm"
    target="_blank">Shorewall and the Enterprise</a>" and described
    the history of Shorewall and gave an overview of its features.

    <p><b>4/5/2004 - Shorewall 2.0.1</b><br>
    </p>
    Problems Corrected since 2.0.0<br>
     <br>


    <ol>
      <li>Using actions in the manner recommended in the
      documentation results in a Warning that the rule is a
      policy.</li>

      <li>When a zone on a single interface is defined using
      /etc/shorewall/hosts, superfluous rules are generated in the
      &lt;zone&gt;_frwd chain.</li>

      <li>Thanks to Sean Mathews, a long-standing problem with
      Proxy ARP and IPSEC has been corrected. Thanks Sean!!!</li>

      <li>The "shorewall show log" and "shorewall logwatch"
      commands incorrectly displayed type 3 ICMP packets.<br>
      </li>
    </ol>
    Issues when migrating from Shorewall 2.0.0 to Shorewall
    2.0.1:<br>
     <br>


    <ol>
      <li>The function of 'norfc1918' is now split between that
      option and a new 'nobogons' option.<br>
      <br>
       The rfc1918 file released with Shorewall now contains
      entries for only those three address ranges reserved by RFC
      1918. A 'nobogons' interface option has been added which
      handles bogon source addresses (those which are reserved by
      the IANA, those reserved for DHCP auto-configuration and the
      class C test-net reserved for testing and documentation
      examples). This will allow users to perform RFC 1918
      filtering without having to deal with out of date data from
      IANA. Those who are willing to update their
      /usr/share/shorewall/bogons file regularly can specify the
      'nobogons' option in addition to 'norfc1918'.<br>
      <br>
       The level at which bogon packets are logged is specified in
      the new BOGON_LOG_LEVEL variable in shorewall.conf. If that
      option is not specified or is specified as empty (e.g,
      BOGON_LOG_LEVEL="") then bogon packets whose TARGET is
      'logdrop' in /usr/share/shorewall/bogons are logged at the
      'info' level.</li>
    </ol>
    New Features:<br>
     <br>


    <ol>
      <li>Support for Bridging Firewalls has been added. For
      details, see<br>
      <br>
       <a href=
      "http://shorewall.net/bridge.html">http://shorewall.net/bridge.html</a><br>

      <br>
      </li>

      <li>Support for NETMAP has been added. NETMAP allows NAT to
      be defined between two network:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;
      a.b.c.1&nbsp;&nbsp;&nbsp; -&gt; x.y.z.1<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      a.b.c.2&nbsp;&nbsp;&nbsp; -&gt; x.y.z.2<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      a.b.c.3&nbsp;&nbsp;&nbsp; -&gt; x.y.z.3<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ...<br>
      <br>
       &nbsp; <a href=
      "http://shorewall.net/netmap.htm">http://shorewall.net/netmap.htm</a><br>

      <br>
      </li>

      <li>The /sbin/shorewall program now accepts a "-x" option to
      cause iptables to print out the actual packet and byte counts
      rather than abbreviated counts such as "13MB".<br>
      <br>
       Commands affected by this are:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall -x show [ &lt;chain&gt;[ &lt;chain&gt; ...] ]<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall -x show tos|mangle<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall -x show nat<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall -x status<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shorewall -x monitor [ &lt;interval&gt; ]<br>
      <br>
      </li>

      <li>
        Shorewall now traps two common zone definition errors:<br>


        <ul>
          <li>Including the firewall zone in a /etc/shorewall/hosts
          record.</li>

          <li>Defining an interface for a zone in both
          /etc/shorewall/interfaces and /etc/shorewall/hosts.<br>
          <br>
          </li>
        </ul>
      </li>

      <li>In the second case, the following will appear during
      "shorewall [re]start" or "shorewall check":<br>
      <br>
       &nbsp;&nbsp; Determining Hosts in Zones...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ...<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error: Invalid zone
      definition for zone &lt;name of zone&gt;<br>
       &nbsp;&nbsp; Terminated<br>
      <br>
      </li>

      <li>To support bridging, the following options have been
      added to entries in /etc/shorewall/hosts:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      norfc1918<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      nobogons<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      blacklist<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      tcpflags<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      nosmurfs<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      newnotsyn<br>
      <br>
       With the exception of 'newnotsyn', these options are only
      useful when the entry refers to a bridge port.<br>
      <br>
       &nbsp;&nbsp; Example:<br>
      <br>
       &nbsp;&nbsp; #ZONE&nbsp;&nbsp;
      HOST(S)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONS<br>
       &nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;&nbsp;
      br0:eth0&nbsp;&nbsp;&nbsp;&nbsp;
      norfc1918,nobogons,blacklist,tcpflags,nosmurfs</li>
    </ol>

    <p><b>3/14/2004 - Shorewall 2.0.0b&nbsp;</b></p>
    Corrects two problems:<br>


    <ol>
      <li>Thanks to Sean Mathews, the long-standing problem with
      Proxy ARP and IPSEC has been eliminated!</li>

      <li>The default value of the ALL INTERFACES column in
      /etc/shorewall/nat is documented as 'No' but the default
      continued to be 'Yes' as it was in Shorewall 1.4.<br>
      </li>
    </ol>

    <p><b>3/14/2004 - Shorewall 2.0.0a&nbsp;</b></p>

    <p>Corrects one problem:<br>
    </p>

    <ul>
      <li>Rules of the form:<br>
      <br>
       &lt;action&gt;&nbsp;&nbsp;&nbsp;&nbsp;
      zone1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; zone2<br>
      <br>
       generated a warning stating that the rule was a policy.<br>
      </li>
    </ul>

    <p><b>3/14/2004 - Shorewall 2.0.0</b> <b><br>
    </b></p>

    <p>Dedicated to Agnes Van Slyke Eastep: March 14, 1910 -
    February 23, 2004<br>
    </p>

    <p>Problems Corrected since 1.4.10<br>
    </p>

    <ol>
      <li>A blank USER/GROUP column in /etc/shorewall/tcrules no
      longer causes a [re]start error.</li>

      <li>The 'fgrep' utility is no longer required (caused startup
      problems on LEAF/Bering).</li>

      <li>The "shorewall add" command no longer inserts rules
      before checking of the blacklist.</li>

      <li>The 'detectnets' and 'routeback' options may now be used
      together with the intended effect.</li>

      <li>The following syntax previously produced an error:<br>
      <br>
       DNAT&nbsp; z1!z2,z3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      z4...<br>
      </li>
    </ol>

    <p>Problems Corrected since RC2<br>
    <br>
    </p>

    <ol>
      <li>CONTINUE rules now work again.</li>

      <li>A comment in the rules file has been corrected.<br>
      </li>
    </ol>

    <p>Issues when migrating from Shorewall 1.4.x to Shorewall
    2.0.0:<br>
    </p>

    <ol>
      <li>The 'dropunclean' and 'logunclean' interface options are
      no longer supported. If either option is specified in
      /etc/shorewall/interfaces, an threatening message will be
      generated.</li>

      <li>The NAT_BEFORE_RULES option has been removed from
      shorewall.conf. The behavior of Shorewall is as if
      NAT_BEFORE_RULES=No had been specified. In other words, DNAT
      rules now always take precidence over one-to-one NAT
      specifications.</li>

      <li>The default value for the ALL INTERFACES column in
      /etc/shorewall/nat has changed. In Shorewall 1.*, if the
      column was left empty, a value of "Yes" was assumed. This has
      been changed so that a value of "No" is now assumed.</li>

      <li>The following files don't exist in Shorewall 2.0:<br>
       /etc/shorewall/common.def<br>
       /etc/shorewall/common<br>
       /etc/shorewall/icmpdef<br>
       /etc/shorewall/action.template (Moved to
      /usr/share/shorewall)<br>
       /etc/shorewall/rfc1918 (Moved to /usr/share/shorewall).<br>
      <br>
       The /etc/shorewall/action file now allows an action to be
      designated as the "common" action for a particular policy
      type by following the action name with ":" and the policy
      (DROP, REJECT or ACCEPT).<br>
      <br>
       The file /usr/share/shorewall/actions.std has been added to
      define those actions that are released as part of Shorewall.
      In that file are two actions as follows:<br>
      <br>
       &nbsp;&nbsp;&nbsp; Drop:DROP<br>
       &nbsp;&nbsp; Reject:REJECT<br>
      <br>
       The "Drop" action is the common action for DROP policies
      while the "Reject" action is the default action for "REJECT"
      policies. These actions will be performed on packets prior to
      applying the DROP or REJECT policy respectively. In the first
      release, the difference between "Reject" and "Drop" is that
      "Reject" REJECTs SMB traffic while "Drop" silently drops such
      traffic.<br>
      <br>
       As described above, Shorewall allows a common action for
      ACCEPT policies but does not specify such an action in the
      default configuration.<br>
      <br>
       If for some reason, you don't wish to have a common DROP or
      REJECT action, just include :DROP or :REJECT respectively in
      your /etc/shorewall/actions file.<br>
      <br>
       The file /usr/share/shorewall/actions.std catalogs the
      standard actions and is processed prior to
      /etc/shorewall/actions. This causes a large number of actions
      to be defined. The files which define these aactions are also
      located in /usr/share/shorewall as is the he action template
      file (action.template).<br>
      <br>
       These actions may be used in the ACTION column of the rules
      column. So for example, to allow FTP from your loc zone to
      your firewall, you would place this rule in
      /etc/shorewall/rules:<br>
      <br>
       &nbsp; #ACTION&nbsp;&nbsp;&nbsp;&nbsp;
      SOURCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DEST<br>
       &nbsp; AllowFTP&nbsp;&nbsp;&nbsp;&nbsp;
      loc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;
      &nbsp; &nbsp; &nbsp; &nbsp; fw<br>
      <br>
       If you want to redefine any of the Shorewall-defined
      actions, simply copy the appropriate action file from
      /usr/share/shorewall to /etc/shorewall and modify the copy as
      desired. Your modified copy will be used rather than the
      original one in /usr/share/shorewall.<br>
      <br>
       Note: The 'dropBcast' and 'dropNonSyn' actions are built
      into Shorewall and may not be changed.<br>
      <br>
       Beginning with version 2.0.0-Beta2, Shorewall will only
      create a chain for those actions that are actually used.<br>
      <br>
      </li>

      <li>The /etc/shorewall directory no longer contains a 'users'
      file or a 'usersets' file. Similar functionality is now
      available using user-defined actions.<br>
      <br>
       Now, action files created by copying
      /usr/share/shorewall/action.template may specify a USER and
      or GROUP name/id in the final column just like in the rules
      file (see below). It is thus possible to create actions that
      control traffic from a list of users and/or groups.<br>
      <br>
       The last column in /etc/shorewall/rules is now labeled
      USER/GROUP and may contain:<br>
      <br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;[:]<br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;[:]<br>
       &nbsp;&nbsp;&nbsp; [!]:&lt;group number&gt;<br>
       &nbsp;&nbsp;&nbsp; [!]:&lt;group name&gt;<br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;:&lt;group
      number&gt;<br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user number&gt;:&lt;group
      name&gt;<br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;:&lt;group
      number&gt;<br>
       &nbsp;&nbsp;&nbsp; [!]&lt;user name&gt;:&lt;group
      name&gt;<br>
       &nbsp;<br>
      </li>

      <li>It is no longer possible to specify rate limiting in the
      ACTION column of /etc/shorewall/rules -- you must use the
      RATE LIMIT column.<br>
      <br>
      </li>

      <li>Depending on which method you use to upgrade, if you have
      your own version of /etc/shorewall/rfc1918, you may have to
      take special action to restore it after the upgrade. Look for
      /etc/shorewall/rfc1918*, locate the proper file and rename it
      back to /etc/shorewall/rfc1918. The contents of that file
      will supercede the contents of
      /usr/share/shorewall/rfc1918.</li>
    </ol>

    <p>New Features:<br>
    </p>

    <ol>
      <li>The INCLUDE directive now allows absolute file
      names.</li>

      <li>A 'nosmurfs' interface option has been added to
      /etc/shorewall/interfaces. When specified for an interface,
      this option causes smurfs (packets with a broadcast address
      as their source) to be dropped and optionally logged (based
      on the setting of a new SMURF_LOG_LEVEL option in
      shorewall.conf).</li>

      <li>fw-&gt;fw traffic may now be controlled by Shorewall.
      There is no need to define the loopback interface in
      /etc/shorewall/interfaces; you simply add a fw-&gt;fw policy
      and fw-&gt;fw rules. If you have neither a fw-&gt;fw policy
      nor fw-&gt;fw rules, all fw-&gt;fw traffic is allowed.</li>

      <li>There is a new PERSISTENT column in the proxyarp file. A
      value of "Yes" in this column means that the route added by
      Shorewall for this host will remain after a "shorewall stop"
      or "shorewall clear".</li>

      <li>"trace" is now a synonym for "debug" in /sbin/shorewall
      commands. So to trace the "start" command, you could
      enter:<br>
      <br>
       shorewall trace start 2&gt; /tmp/trace<br>
      <br>
       The trace information would be written to the file
      /tmp/trace.<br>
      <br>
      </li>

      <li>When defining an ipsec tunnel in /etc/shorewall/tunnels,
      if you follow the tunnel type ("ipsec" or "ipsecnet") with
      ":noah" (e.g., "ipsec:noah"), then Shorewall will only create
      rules for ESP (protocol 50) and will not create rules for AH
      (protocol 51).</li>

      <li>A new DISABLE_IPV6 option has been added to
      shorewall.conf. When this option is set to "Yes", Shorewall
      will set the policy for the IPv6 INPUT, OUTPUT and FORWARD
      chains to DROP during "shorewall [re]start" and "shorewall
      stop". Regardless of the setting of this variable, "shorewall
      clear" will silently attempt to set these policies to
      ACCEPT.<br>
      <br>
       If this option is not set in your existing shorewall.conf
      then a setting of DISABLE_IPV6=No is assumed in which case,
      Shorewall will not touch any IPv6 settings except during
      "shorewall clear".</li>

      <li>The CONTINUE target is now available in action
      definitions. CONTINUE terminates processing of the current
      action and returns to the point where that action was
      invoked.</li>
    </ol>

    <p><b>2/15/2004 - Shorewall 1.4.10c&nbsp;</b></p>

    <p>Corrects one problem:<br>
    </p>
    Entries in /etc/shorewall/tcrules with an empty USER/GROUP
    column would cause a startup error.

    <p><b>2/12/2004 - Shorewall 1.4.10b&nbsp;</b></p>

    <p>Corrects one problem:<br>
    </p>

    <ul>
      <li>In the /etc/shorewall/masq entry “<span class=
      "quote">eth0:!10.1.1.150 &nbsp; &nbsp;0.0.0.0/0!10.1.0.0/16
      &nbsp; &nbsp; 10.1.2.16</span>”, the “<span class=
      "quote">!10.1.0.0/16</span>” is ignored.</li>
    </ul>

    <p><b>2/8/2004 - Shorewall 1.4.10a&nbsp;</b></p>

    <p>Corrects two problems:<br>
    </p>

    <ul>
      <li>A problem which can cause [re]start to fail inexplicably
      while processing /etc/shorewall/masq.</li>

      <li>Interfaces using the Atheros WiFi card to use the
      'maclist' option.</li>
    </ul>

    <p><b>1/30/2004 - Shorewall 1.4.10</b></p>

    <p>Problems Corrected since version 1.4.9</p>

    <ol>
      <li>The column descriptions in the action.template file did
      not match the column headings. That has been corrected.</li>

      <li>The presence of IPV6 addresses on devices generated error
      messages during [re]start if ADD_IP_ALIASES=Yes or
      ADD_SNAT_ALIASES=Yes are specified in
      /etc/shorewall/shorewall.conf. These messages have been
      eliminated.</li>

      <li value="3">The CONTINUE action in /etc/shorewall/rules now
      works correctly. A couple of problems involving rate limiting
      have been corrected. These bug fixes courtesy of Steven Jan
      Springl.</li>

      <li>Shorewall now tried to avoid sending an ICMP response to
      broadcasts and smurfs.</li>

      <li>Specifying "-" or "all" in the PROTO column of an action
      no longer causes a startup error.</li>
    </ol>
    Migragion Issues:<br>
     <br>
     &nbsp;&nbsp;&nbsp; None.<br>
     <br>
     New Features:<br>


    <ol>
      <li>The INTERFACE column in the /etc/shorewall/masq file may
      now specify a destination list.<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
       &nbsp;&nbsp;&nbsp;
      eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
      <br>
       If the list begins with "!" then SNAT will occur only if the
      destination IP address is NOT included in the list.<br>
      <br>
      </li>

      <li>Output traffic control rules (those with the firewall as
      the source) may now be qualified by the effective userid
      and/or effective group id of the program generating the
      output. This feature is courtesy of&nbsp; Frédéric
      LESPEZ.<br>
      <br>
       A new USER column has been added to /etc/shorewall/tcrules.
      It may contain :<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or
      number&gt;]:[&lt;group name or number&gt;]<br>
      <br>
       The colon is optionnal when specifying only a user.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john
      / :users / john:users<br>
      <br>
      </li>

      <li>A "detectnets" interface option has been added for
      entries in /etc/shorewall/interfaces. This option
      automatically tailors the definition of the zone named in the
      ZONE column to include just&nbsp; those hosts that have
      routes through the interface named in the INTERFACE column.
      The named interface must be UP when Shorewall is
      [re]started.<br>
      <br>
       &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
      INTERFACE! &nbsp;&nbsp;</li>
    </ol>

    <p><b>1/27/2004 - Shorewall 1.4.10 RC3</b></p>

    <p><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </p>

    <p>Problems Corrected since version 1.4.9</p>

    <ol>
      <li>The column descriptions in the action.template file did
      not match the column headings. That has been corrected.</li>

      <li>The presence of IPV6 addresses on devices generated error
      messages during [re]start if ADD_IP_ALIASES=Yes or
      ADD_SNAT_ALIASES=Yes are specified in
      /etc/shorewall/shorewall.conf. These messages have been
      eliminated.</li>

      <li value="3">The CONTINUE action in /etc/shorewall/rules now
      works correctly. A couple of problems involving rate limiting
      have been corrected. These bug fixes courtesy of Steven Jan
      Springl.</li>

      <li>Shorewall now tried to avoid sending an ICMP response to
      broadcasts and smurfs.<br>
      </li>
    </ol>
    Migragion Issues:<br>
     <br>
     &nbsp;&nbsp;&nbsp; None.<br>
     <br>
     New Features:<br>


    <ol>
      <li>The INTERFACE column in the /etc/shorewall/masq file may
      now specify a destination list.<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
       &nbsp;&nbsp;&nbsp;
      eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
      <br>
       If the list begins with "!" then SNAT will occur only if the
      destination IP address is NOT included in the list.<br>
      <br>
      </li>

      <li>Output traffic control rules (those with the firewall as
      the source) may now be qualified by the effective userid
      and/or effective group id of the program generating the
      output. This feature is courtesy of&nbsp; Frédéric
      LESPEZ.<br>
      <br>
       A new USER column has been added to /etc/shorewall/tcrules.
      It may contain :<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or
      number&gt;]:[&lt;group name or number&gt;]<br>
      <br>
       The colon is optionnal when specifying only a user.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john
      / :users / john:users<br>
      <br>
      </li>

      <li>A "detectnets" interface option has been added for
      entries in /etc/shorewall/interfaces. This option
      automatically tailors the definition of the zone named in the
      ZONE column to include just&nbsp; those hosts that have
      routes through the interface named in the INTERFACE column.
      The named interface must be UP when Shorewall is
      [re]started.<br>
      <br>
       &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
      INTERFACE! &nbsp;&nbsp;</li>
    </ol>

    <p><b>1/24/2004 - Shorewall 1.4.10 RC2</b><b>&nbsp;</b></p>

    <p><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </p>

    <p>Problems Corrected since version 1.4.9</p>

    <ol>
      <li>The column descriptions in the action.template file did
      not match the column headings. That has been corrected.</li>

      <li>The presence of IPV6 addresses on devices generated error
      messages during [re]start if ADD_IP_ALIASES=Yes or
      ADD_SNAT_ALIASES=Yes are specified in
      /etc/shorewall/shorewall.conf. These messages have been
      eliminated.</li>
    </ol>
    Migragion Issues:<br>
     <br>
     &nbsp;&nbsp;&nbsp; None.<br>
     <br>
     New Features:<br>


    <ol>
      <li>The INTERFACE column in the /etc/shorewall/masq file may
      now specify a destination list.<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
       &nbsp;&nbsp;&nbsp;
      eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
      <br>
       If the list begins with "!" then SNAT will occur only if the
      destination IP address is NOT included in the list.<br>
      <br>
      </li>

      <li>Output traffic control rules (those with the firewall as
      the source) may now be qualified by the effective userid
      and/or effective group id of the program generating the
      output. This feature is courtesy of&nbsp; Frédéric
      LESPEZ.<br>
      <br>
       A new USER column has been added to /etc/shorewall/tcrules.
      It may contain :<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or
      number&gt;]:[&lt;group name or number&gt;]<br>
      <br>
       The colon is optionnal when specifying only a user.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john
      / :users / john:users<br>
      <br>
      </li>

      <li>A "detectnets" interface option has been added for
      entries in /etc/shorewall/interfaces. This option
      automatically tailors the definition of the zone named in the
      ZONE column to include just&nbsp; those hosts that have
      routes through the interface named in the INTERFACE column.
      The named interface must be UP when Shorewall is
      [re]started.<br>
      <br>
       &nbsp;WARNING: DO NOT SET THIS OPTION ON YOUR INTERNET
      INTERFACE!</li>
    </ol>

    <p><b>1/22/2004 - Shorewall 1.4.10 RC1</b><b>&nbsp;</b></p>

    <p>Problems Corrected since version 1.4.9</p>

    <ol>
      <li>The column descriptions in the action.template file did
      not match the column headings. That has been corrected.</li>

      <li>The presence of IPV6 addresses on devices generated error
      messages during [re]start if ADD_IP_ALIASES=Yes or
      ADD_SNAT_ALIASES=Yes are specified in
      /etc/shorewall/shorewall.conf. These messages have been
      eliminated.</li>
    </ol>
    Migragion Issues:<br>
     <br>
     &nbsp;&nbsp;&nbsp; None.<br>
     <br>
     New Features:<br>


    <ol>
      <li>The INTERFACE column in the /etc/shorewall/masq file may
      now specify a destination list.<br>
      <br>
       Example:<br>
      <br>
       &nbsp;&nbsp;&nbsp; #INTERFACE&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
      SUBNET&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ADDRESS<br>
       &nbsp;&nbsp;&nbsp;
      eth0:192.0.2.3,192.0.2.16/28&nbsp;&nbsp;&nbsp; eth1<br>
      <br>
       If the list begins with "!" then SNAT will occur only if the
      destination IP address is NOT included in the list.<br>
      <br>
      </li>

      <li>Output traffic control rules (those with the firewall as
      the source) may now be qualified by the effective userid
      and/or effective group id of the program generating the
      output. This feature is courtesy of&nbsp; Frédéric
      LESPEZ.<br>
      <br>
       A new USER column has been added to /etc/shorewall/tcrules.
      It may contain :<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [&lt;user name or
      number&gt;]:[&lt;group name or number&gt;]<br>
      <br>
       The colon is optionnal when specifying only a user.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Examples : john: / john
      / :users / john:users&nbsp;&nbsp;&nbsp;<br>
      </li>
    </ol>

    <p><b>1/13/2004 - Shorewall 1.4.9</b><b><br>
    </b></p>

    <p>Problems Corrected since version 1.4.8:<br>
    </p>

    <ol>
      <li>There has been a low continuing level of confusion over
      the terms "Source NAT" (SNAT) and "Static NAT". To avoid
      future confusion, all instances of "Static NAT" have been
      replaced with "One-to-one NAT" in the documentation and
      configuration files.</li>

      <li>The description of NEWNOTSYN in shorewall.conf has been
      reworded for clarity.</li>

      <li>Wild-card rules (those involving "all" as SOURCE or DEST)
      will no longer produce an error if they attempt to add a rule
      that would override a NONE policy. The logic for expanding
      these wild-card rules now simply skips those (SOURCE,DEST)
      pairs that have a NONE policy.</li>

      <li>DNAT rules that also specified SNAT now work reliably.
      Previously, there were cases where the SNAT specification was
      effectively ignored.</li>
    </ol>

    <p>Migration Issues:<br>
    <br>
     &nbsp;&nbsp;&nbsp; None.<br>
    <br>
     New Features:<br>
    </p>

    <ol>
      <li>The documentation has been completely rebased to Docbook
      XML. The documentation is now released as separate HTML and
      XML packages.</li>

      <li>To cut down on the number of "Why are these ports closed
      rather than stealthed?" questions, the SMB-related rules in
      /etc/shorewall/common.def have been changed from 'reject' to
      'DROP'.</li>

      <li>For easier identification, packets logged under the
      'norfc1918' interface option are now logged out of chains
      named 'rfc1918'. Previously, such packets were logged under
      chains named 'logdrop'.</li>

      <li>Distributors and developers seem to be regularly
      inventing new naming conventions for kernel modules. To avoid
      the need to change Shorewall code for each new convention,
      the MODULE_SUFFIX option has been added to shorewall.conf.
      MODULE_SUFFIX may be set to the suffix for module names in
      your particular distribution. If MODULE_SUFFIX is not set in
      shorewall.conf, Shorewall will use the list "o gz ko
      o.gz".<br>
      <br>
       To see what suffix is used by your distribution:<br>
      <br>
       ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
      <br>
       All of the files listed should have the same suffix
      (extension). Set MODULE_SUFFIX to that suffix.<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
      MODULE_SUFFIX="kzo"<br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then
      set MODULE_SUFFIX="kz.o"</li>

      <li>Support for user defined rule ACTIONS has been
      implemented through two new files:<br>
      <br>
       /etc/shorewall/actions - used to list the user-defined
      ACTIONS.<br>
       /etc/shorewall/action.template - For each user defined
      &lt;action&gt;, copy this file to
      /etc/shorewall/action.&lt;action&gt; and add the appropriate
      rules for that &lt;action&gt;. Once an &lt;action&gt; has
      been defined, it may be used like any of the builtin ACTIONS
      (ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
      <br>
       Example: You want an action that logs a packet at the 'info'
      level and accepts the connection.<br>
      <br>
       In /etc/shorewall/actions, you would add:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
      <br>
       You would then copy /etc/shorewall/action.template to
      /etc/shorewall/action.LogAndAccept and in that file, you
      would add the two rules:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT</li>

      <li>The default value for NEWNOTSYN in shorewall.conf is now
      "Yes" (non-syn TCP packets that are not part of an existing
      connection are filtered according to the rules and policies
      rather than being dropped). I have made this change for two
      reasons:<br>
      <br>
       a) NEWNOTSYN=No tends to result in lots of "stuck"
      connections since any timeout during TCP session tear down
      results in the firewall dropping all of the retries.<br>
      <br>
       b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
      resulted in lots of confusing messages when a connection got
      "stuck". While I could have changed the default value of
      LOGNEWNOTSYN to suppress logging, I dislike defaults that
      silently throw away packets.</li>

      <li>The common.def file now contains an entry that silently
      drops ICMP packets with a null source address. Ad Koster
      reported a case where these were occuring frequently as a
      result of a broken system on his external network.</li>
    </ol>

    <p><b>12/29/2003 - Shorewall 1.4.9 Beta 2</b></p>

    <div style="margin-left: 40px;">
      <a href=
      "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
      "_top">ftp://shorewall.net/pub/shorewall/Beta</a>
    </div>

    <p>Problems Corrected since version 1.4.8:</p>

    <ol>
      <li>There has been a low continuing level of confusion over
      the terms "Source NAT" (SNAT) and "Static NAT". To avoid
      future confusion, all instances of "Static NAT" have been
      replaced with "One-to-one NAT" in the documentation and
      configuration files.</li>

      <li>The description of NEWNOTSYN in shorewall.conf has been
      reworded for clarity.</li>

      <li>Wild-card rules (those involving "all" as SOURCE or DEST)
      will no longer produce an error if they attempt to add a rule
      that would override a NONE policy. The logic for expanding
      these wild-card rules now simply skips those (SOURCE,DEST)
      pairs that have a NONE policy.</li>

      <li>DNAT rules that also specified SNAT now work reliably.
      Previously, there were cases where the SNAT specification was
      effectively ignored.<br>
      </li>
    </ol>

    <p>Migration Issues:</p>

    <p>&nbsp;&nbsp;&nbsp; None.<br>
    <br>
     New Features:</p>

    <ol>
      <li>The documentation has been completely rebased to Docbook
      XML. The documentation is now released as separate HTML and
      XML packages.<br>
      </li>

      <li>To cut down on the number of "Why are these ports closed
      rather than stealthed?" questions, the SMB-related rules in
      /etc/shorewall/common.def have been changed from 'reject' to
      'DROP'.</li>

      <li>For easier identification, packets logged under the
      'norfc1918' interface option are now logged out of chains
      named 'rfc1918'. Previously, such packets were logged under
      chains named 'logdrop'.</li>

      <li>Distributors and developers seem to be regularly
      inventing new naming conventions for kernel modules. To avoid
      the need to change Shorewall code for each new convention,
      the MODULE_SUFFIX option has been added to shorewall.conf.
      MODULE_SUFFIX may be set to the suffix for module names in
      your particular distribution. If MODULE_SUFFIX is not set in
      shorewall.conf, Shorewall will use the list "o gz ko
      o.gz".<br>
      <br>
       To see what suffix is used by your distribution:<br>
      <br>
       ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
      <br>
       All of the files listed should have the same suffix
      (extension). Set MODULE_SUFFIX to that suffix.<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
      MODULE_SUFFIX="kzo"<br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then
      set MODULE_SUFFIX="kz.o"</li>

      <li>Support for user defined rule ACTIONS has been
      implemented through two new files:<br>
      <br>
       /etc/shorewall/actions - used to list the user-defined
      ACTIONS.<br>
       /etc/shorewall/action.template - For each user defined
      &lt;action&gt;, copy this file to
      /etc/shorewall/action.&lt;action&gt; and add the appropriate
      rules for that &lt;action&gt;. Once an &lt;action&gt; has
      been defined, it may be used like any of the builtin ACTIONS
      (ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
      <br>
       Example: You want an action that logs a packet at the 'info'
      level and accepts the connection.<br>
      <br>
       In /etc/shorewall/actions, you would add:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
      <br>
       You would then copy /etc/shorewall/action.template to
      /etc/shorewall/action.LogAndAccept and in that file, you
      would add the two rules:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT<br>
      </li>

      <li>The default value for NEWNOTSYN in shorewall.conf is now
      "Yes" (non-syn TCP packets that are not part of an existing
      connection are filtered according to the rules and policies
      rather than being dropped). I have made this change for two
      reasons:<br>
      <br>
       a) NEWNOTSYN=No tends to result in lots of "stuck"
      connections since any timeout during TCP session tear down
      results in the firewall dropping all of the retries.<br>
      <br>
       b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
      resulted in lots of confusing messages when a connection got
      "stuck". While I could have changed the default value of
      LOGNEWNOTSYN to suppress logging, I dislike defaults that
      silently throw away packets.<br>
      <br>
      </li>
    </ol>

    <p><b>12/28/2003 - www.shorewall.net/ftp.shorewall.net Back
    On-line</b> <b><br>
    </b></p>

    <p>Our high-capacity server has been restored to service --
    please let <a href="mailto:webmaster@shorewall.net">us</a> know
    if you find any problems.</p>

    <p><b>12/29/2003 - Shorewall 1.4.9 Beta 1</b></p>

    <div style="margin-left: 40px;">
      <a href=
      "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
      "_top">ftp://shorewall.net/pub/shorewall/Beta</a>
    </div>

    <p>Problems Corrected since version 1.4.8:</p>

    <ol>
      <li>There has been a low continuing level of confusion over
      the terms "Source NAT" (SNAT) and "Static NAT". To avoid
      future confusion, all instances of "Static NAT" have been
      replaced with "One-to-one NAT" in the documentation and
      configuration files.</li>

      <li>The description of NEWNOTSYN in shorewall.conf has been
      reworded for clarity.</li>

      <li>Wild-card rules (those involving "all" as SOURCE or DEST)
      will no longer produce an error if they attempt to add a rule
      that would override a NONE policy. The logic for expanding
      these wild-card rules now simply skips those (SOURCE,DEST)
      pairs that have a NONE policy.</li>
    </ol>

    <p>Migration Issues:</p>

    <p>&nbsp;&nbsp;&nbsp; None.<br>
    <br>
     New Features:</p>

    <ol>
      <li>To cut down on the number of "Why are these ports closed
      rather than stealthed?" questions, the SMB-related rules in
      /etc/shorewall/common.def have been changed from 'reject' to
      'DROP'.</li>

      <li>For easier identification, packets logged under the
      'norfc1918' interface option are now logged out of chains
      named 'rfc1918'. Previously, such packets were logged under
      chains named 'logdrop'.</li>

      <li>Distributors and developers seem to be regularly
      inventing new naming conventions for kernel modules. To avoid
      the need to change Shorewall code for each new convention,
      the MODULE_SUFFIX option has been added to shorewall.conf.
      MODULE_SUFFIX may be set to the suffix for module names in
      your particular distribution. If MODULE_SUFFIX is not set in
      shorewall.conf, Shorewall will use the list "o gz ko
      o.gz".<br>
      <br>
       To see what suffix is used by your distribution:<br>
      <br>
       ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter<br>
      <br>
       All of the files listed should have the same suffix
      (extension). Set MODULE_SUFFIX to that suffix.<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kzo" then set
      MODULE_SUFFIX="kzo"<br>
       &nbsp;&nbsp;&nbsp;&nbsp; If all files end in ".kz.o" then
      set MODULE_SUFFIX="kz.o"</li>

      <li>Support for user defined rule ACTIONS has been
      implemented through two new files:<br>
      <br>
       /etc/shorewall/actions - used to list the user-defined
      ACTIONS.<br>
       /etc/shorewall/action.template - For each user defined
      &lt;action&gt;, copy this file to
      /etc/shorewall/action.&lt;action&gt; and add the appropriate
      rules for that &lt;action&gt;. Once an &lt;action&gt; has
      been defined, it may be used like any of the builtin ACTIONS
      (ACCEPT, DROP, etc.) in /etc/shorewall/rules.<br>
      <br>
       Example: You want an action that logs a packet at the 'info'
      level and accepts the connection.<br>
      <br>
       In /etc/shorewall/actions, you would add:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp; LogAndAccept<br>
      <br>
       You would then copy /etc/shorewall/action.template to
      /etc/shorewall/action.LogAndAccept and in that file, you
      would add the two rules:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOG:info<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT<br>
      </li>

      <li>The default value for NEWNOTSYN in shorewall.conf is now
      "Yes" (non-syn TCP packets that are not part of an existing
      connection are filtered according to the rules and policies
      rather than being dropped). I have made this change for two
      reasons:<br>
      <br>
       a) NEWNOTSYN=No tends to result in lots of "stuck"
      connections since any timeout during TCP session tear down
      results in the firewall dropping all of the retries.<br>
      <br>
       b) The old default of NEWNOTSYN=No and LOGNEWNOTSYN=info
      resulted in lots of confusing messages when a connection got
      "stuck". While I could have changed the default value of
      LOGNEWNOTSYN to suppress logging, I dislike defaults that
      silently throw away packets.</li>
    </ol>

    <p><b>12/03/2003 - Support Torch Passed</b></p>
    Effective today, I am reducing my participation in the
    day-to-day support of Shorewall. As part of this shift to
    community-based Shorewall support a new <a href=
    "https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">
    Shorewall Newbies mailing list</a> has been established to
    field questions and problems from new users. I will not monitor
    that list personally. I will continue my active development of
    Shorewall and will be available via the development list to
    handle development issues -- Tom.

    <p><b>11/07/2003 - Shorewall 1.4.8<br>
    <br>
    </b> Problems Corrected since version 1.4.7:<br>
    </p>

    <ol>
      <li>Tuomo Soini has supplied a correction to a problem that
      occurs using some versions of 'ash'. The symptom is that
      "shorewall start" fails with:<br>
       &nbsp;<br>
       &nbsp;&nbsp; local: --limit: bad variable name<br>
       &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
      `-j':/lib/iptables/libipt_-j.so:<br>
       &nbsp;&nbsp; cannot open shared object file: No such file or
      directory<br>
       &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
      information.</li>

      <li>Andres Zhoglo has supplied a correction that avoids
      trying to use the multiport match iptables facility on ICMP
      rules.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Example of rule that previously caused
      "shorewall start" to fail:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
      icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
      <br>
      </li>

      <li>Previously, if the following error message was issued,
      Shorewall was left in an inconsistent state.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Error: Unable to determine the routes through
      interface xxx<br>
      <br>
      </li>

      <li>Handling of the LOGUNCLEAN option in shorewall.conf has
      been corrected.</li>

      <li>In Shorewall 1.4.2, an optimization was added. This
      optimization involved creating a chain named
      "&lt;zone&gt;_frwd" for most zones defined using the
      /etc/shorewall/hosts file. It has since been discovered that
      in many cases these new chains contain redundant rules and
      that the "optimization" turns out to be less than optimal.
      The implementation has now been corrected.</li>

      <li>When the MARK value in a tcrules entry is followed by
      ":F" or ":P", the ":F" or ":P" was previously only applied to
      the first Netfilter rule generated by the entry. It is now
      applied to all entries.</li>

      <li>An incorrect comment concerning Debian's use of the
      SUBSYSLOCK option has been removed from shorewall.conf.</li>

      <li>Previously, neither the 'routefilter' interface option
      nor the ROUTE_FILTER parameter were working properly. This
      has been corrected (thanks to Eric Bowles for his analysis
      and patch). The definition of the ROUTE_FILTER option has
      changed however. Previously, ROUTE_FILTER=Yes was documented
      as enabling route filtering on all interfaces (which didn't
      work). Beginning with this release, setting ROUTE_FILTER=Yes
      will enable route filtering of all interfaces brought up
      while Shorewall is started. As a consequence,
      ROUTE_FILTER=Yes can coexist with the use of the
      'routefilter' option in the interfaces file.</li>

      <li>If MAC verification was enabled on an interface with a
      /32 address and a broadcast address then an error would occur
      during startup.</li>

      <li>The NONE policy's intended use is to suppress the
      generating of rules that can't possibly be traversed. This
      means that a policy of NONE is inappropriate where the source
      or destination zone is $FW or "all". Shorewall now generates
      an error message if such a policy is given in
      /etc/shorewall/policy. Previously such a policy caused
      "shorewall start" to fail.</li>

      <li>The 'routeback' option was broken for wildcard interfaces
      (e.g., "tun+"). This has been corrected so that 'routeback'
      now works as expected in this case.<br>
      </li>
    </ol>
    Migration Issues:<br>


    <ol>
      <li>The definition of the ROUTE_FILTER option in
      shorewall.conf has changed as described in item 8) above.<br>
      </li>
    </ol>
    New Features:<br>


    <ol>
      <li>A new QUEUE action has been introduced for rules. QUEUE
      allows you to pass connection requests to a user-space filter
      such as ftwall (http://p2pwall.sourceforge.net). The ftwall
      program allows for effective filtering of p2p applications
      such as Kazaa. For example, to use ftwall to filter P2P
      clients in the 'loc' zone, you would add the following
      rules:<br>
      <br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; tcp<br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; udp<br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;&nbsp; udp<br>
      <br>
       You would normally want to place those three rules BEFORE
      any ACCEPT rules for loc-&gt;net udp or tcp.<br>
      <br>
       Note: When the protocol specified is TCP ("tcp", "TCP" or
      "6"), Shorewall will only pass connection requests (SYN
      packets) to user space. This is for compatibility with
      ftwall.</li>

      <li>A BLACKLISTNEWNONLY option has been added to
      shorewall.conf. When this option is set to "Yes", the
      blacklists (dynamic and static) are only consulted for new
      connection requests. When set to "No" (the default if the
      variable is not set), the blacklists are consulted on every
      packet.<br>
      <br>
       Setting this option to "No" allows blacklisting to stop
      existing connections from a newly blacklisted host but is
      more expensive in terms of packet processing time. This is
      especially true if the blacklists contain a large number of
      entries.</li>

      <li>Chain names used in the /etc/shorewall/accounting file
      may now begin with a digit ([0-9]) and may contain embedded
      dashes ("-").</li>
    </ol>

    <p><b>10/30/2003 - Shorewall 1.4.8 RC1<br>
    </b></p>
    Given the small number of new features and the relatively few
    lines of code that were changed, there will be no Beta for
    1.4.8.<br>


    <p><b><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    <br>
    </b> Problems Corrected since version 1.4.7:<br>
    </p>

    <ol>
      <li>Tuomo Soini has supplied a correction to a problem that
      occurs using some versions of 'ash'. The symptom is that
      "shorewall start" fails with:<br>
       &nbsp;<br>
       &nbsp;&nbsp; local: --limit: bad variable name<br>
       &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
      `-j':/lib/iptables/libipt_-j.so:<br>
       &nbsp;&nbsp; cannot open shared object file: No such file or
      directory<br>
       &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
      information.</li>

      <li>Andres Zhoglo has supplied a correction that avoids
      trying to use the multiport match iptables facility on ICMP
      rules.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Example of rule that previously caused
      "shorewall start" to fail:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
      icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
      <br>
      </li>

      <li>Previously, if the following error message was issued,
      Shorewall was left in an inconsistent state.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Error: Unable to determine the routes through
      interface xxx<br>
      <br>
      </li>

      <li>Handling of the LOGUNCLEAN option in shorewall.conf has
      been corrected.</li>

      <li>In Shorewall 1.4.2, an optimization was added. This
      optimization involved creating a chain named
      "&lt;zone&gt;_frwd" for most zones defined using the
      /etc/shorewall/hosts file. It has since been discovered that
      in many cases these new chains contain redundant rules and
      that the "optimization" turns out to be less than optimal.
      The implementation has now been corrected.</li>

      <li>When the MARK value in a tcrules entry is followed by
      ":F" or ":P", the ":F" or ":P" was previously only applied to
      the first Netfilter rule generated by the entry. It is now
      applied to all entries.</li>

      <li>An incorrect comment concerning Debian's use of the
      SYBSYSLOCK option has been removed from shorewall.conf.</li>

      <li>Previously, neither the 'routefilter' interface option
      nor the ROUTE_FILTER parameter were working properly. This
      has been corrected (thanks to Eric Bowles for his analysis
      and patch). The definition of the ROUTE_FILTER option has
      changed however. Previously, ROUTE_FILTER=Yes was documented
      as enabling route filtering on all interfaces (which didn't
      work). Beginning with this release, setting ROUTE_FILTER=Yes
      will enable route filtering of all interfaces brought up
      while Shorewall is started. As a consequence,
      ROUTE_FILTER=Yes can coexist with the use of the
      'routefilter' option in the interfaces file.</li>
    </ol>
    Migration Issues:<br>


    <ol>
      <li>The definition of the ROUTE_FILTER option in
      shorewall.conf has changed as described in item 8) above.<br>
      </li>
    </ol>
    New Features:<br>


    <ol>
      <li>A new QUEUE action has been introduced for rules. QUEUE
      allows you to pass connection requests to a user-space filter
      such as ftwall (http://p2pwall.sourceforge.net). The ftwall
      program allows for effective filtering of p2p applications
      such as Kazaa. For example, to use ftwall to filter P2P
      clients in the 'loc' zone, you would add the following
      rules:<br>
      <br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; tcp<br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; udp<br>
       &nbsp;&nbsp; QUEUE&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      &nbsp;&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;&nbsp; udp<br>
      <br>
       You would normally want to place those three rules BEFORE
      any ACCEPT rules for loc-&gt;net udp or tcp.<br>
      <br>
       Note: When the protocol specified is TCP ("tcp", "TCP" or
      "6"), Shorewall will only pass connection requests (SYN
      packets) to user space. This is for compatibility with
      ftwall.</li>

      <li>A BLACKLISTNEWNONLY option has been added to
      shorewall.conf. When this option is set to "Yes", the
      blacklists (dynamic and static) are only consulted for new
      connection requests. When set to "No" (the default if the
      variable is not set), the blacklists are consulted on every
      packet.<br>
      <br>
       Setting this option to "No" allows blacklisting to stop
      existing connections from a newly blacklisted host but is
      more expensive in terms of packet processing time. This is
      especially true if the blacklists contain a large number of
      entries.</li>

      <li>Chain names used in the /etc/shorewall/accounting file
      may now begin with a digit ([0-9]) and may contain embedded
      dashes ("-").<br>
      </li>
    </ol>

    <p><b>10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper
    bag awards</b> <b><img style=
    "border: 0px solid ; width: 50px; height: 80px;" src=
    "images/j0233056.gif" title="" alt="" align="middle">Shorewall
    1.4.7c released.</b></p>

    <ol>
      <li>The saga with "&lt;zone&gt;_frwd" chains continues. The
      1.4.7c script produces a ruleset that should work for
      everyone even if it is not quite optimal. My apologies for
      this ongoing mess.<br>
      </li>
    </ol>

    <p><b>10/24/2003 - Shorewall 1.4.7b</b></p>
    This is a bugfx rollup of the 1.4.7a fixes plus:<br>


    <ol>
      <li>The fix for problem 5 in 1.4.7a was wrong with the result
      that "&lt;zone&gt;_frwd" chains might contain too few rules.
      That wrong code is corrected in this release.<br>
      </li>
    </ol>

    <p><b>10/21/2003 - Shorewall 1.4.7a<br>
    </b></p>

    <p>This is a bugfix rollup of the following problem
    corrections:<br>
    </p>

    <ol>
      <li>Tuomo Soini has supplied a correction to a problem that
      occurs using some versions of 'ash'. The symptom is that
      "shorewall start" fails with:<br>
       &nbsp;<br>
       &nbsp;&nbsp; local: --limit: bad variable name<br>
       &nbsp;&nbsp; iptables v1.2.8: Couldn't load match
      `-j':/lib/iptables/libipt_-j.so:<br>
       &nbsp;&nbsp; cannot open shared object file: No such file or
      directory<br>
       &nbsp;&nbsp; Try `iptables -h' or 'iptables --help' for more
      information.<br>
      <br>
      </li>

      <li>Andres Zhoglo has supplied a correction that avoids
      trying to use the multiport match iptables facility on ICMP
      rules.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Example of rule that previously caused
      "shorewall start" to fail:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loc&nbsp; $FW&nbsp;
      icmp&nbsp;&nbsp;&nbsp; 0,8,11,12<br>
      <br>
      </li>

      <li>Previously, if the following error message was issued,
      Shorewall was left in an inconsistent state.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Error: Unable to determine the routes through
      interface xxx<br>
      <br>
      </li>

      <li>Handling of the LOGUNCLEAN option in shorewall.conf has
      been corrected.</li>

      <li>In Shorewall 1.4.2, an optimization was added. This
      optimization involved creating a chain named
      "&lt;zone&gt;_frwd" for most zones defined using the
      /etc/shorewall/hosts file. It has since been discovered that
      in many cases these new chains contain redundant rules and
      that the "optimization" turns out to be less than optimal.
      The implementation has now been corrected.</li>

      <li>When the MARK value in a tcrules entry is followed by
      ":F" or ":P", the ":F" or ":P" was previously only applied to
      the first Netfilter rule generated by the entry. It is now
      applied to all entries.<br>
      </li>
    </ol>

    <p><b>10/06/2003 - Shorewall 1.4.7</b><b><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6 (Those in bold font
    were corrected since 1.4.7 RC2).</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.</li>

      <li value="7">The 'shorewall reject' and 'shorewall drop'
      commands now delete any existing rules for the subject IP
      address before adding a new DROP or REJECT rule. Previously,
      there could be many rules for the same IP address in the
      dynamic chain so that multiple 'allow' commands were required
      to re-enable traffic to/from the address.</li>

      <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
      following entry in /etc/shorewall/masq resulted in a startup
      error:<br>
       &nbsp;<br>
       &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
      206.124.146.20-206.124.146.24<br>
      <br>
      </li>

      <li>Shorewall previously choked over IPV6 addresses
      configured on interfaces in contexts where Shorewall needed
      to detect something about the interface (such as when
      "detect" appears in the BROADCAST column of the
      /etc/shorewall/interfaces file).</li>

      <li>Shorewall will now load module files that are formed from
      the module name by appending ".o.gz".</li>

      <li>When Shorewall adds a route to a proxy ARP host and such
      a route already exists, two routes resulted previously. This
      has been corrected so that the existing route is replaced if
      it already exists.</li>

      <li>The rfc1918 file has been updated to reflect recent
      allocations.</li>

      <li>The documentation of the USER SET column in the rules
      file has been corrected.</li>

      <li>If there is no policy defined for the zones specified in
      a rule, the firewall script previously encountered a shell
      syntax error:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE:
      unexpected operator<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       Now, the absence of a policy generates an error message and
      the firewall is stopped:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined
      from zone &lt;source&gt; to zone &lt;dest&gt;<br>
      <br>
      </li>

      <li>Previously, if neither /etc/shorewall/common nor
      /etc/shorewall/common.def existed, Shorewall would fail to
      start and would not remove the lock file. Failure to remove
      the lock file resulted in the following during subsequent
      attempts to start:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp; Loading
      /usr/share/shorewall/functions...<br>
       &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
       &nbsp;&nbsp;&nbsp; Processing
      /etc/shorewall/shorewall.conf...<br>
       &nbsp;&nbsp;&nbsp; Giving up on lock file
      /var/lib/shorewall/lock<br>
       &nbsp;&nbsp;&nbsp; Shorewall Not Started<br>
      <br>
       Shorewall now reports a fatal error if neither of these two
      files exist and correctly removes the lock fille.</li>

      <li>The order of processing the various options has been
      changed such that blacklist entries now take precedence over
      the 'dhcp' <span style="font-weight: bold;">i</span>nterface
      setting.</li>

      <li>The log message generated from the 'logunclean' interface
      option has been changed to reflect a disposition of LOG
      rather than DROP.</li>

      <li><span style="font-weight: bold;">When a user name and/or
      a group name was specified in the USER SET column and the
      destination zone was qualified with a IP address, the user
      and/or group name was not being used to qualify the rule.<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp; Example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp; ACCEPT fw&nbsp; net:192.0.2.12 tcp 23 - -
      - vladimir:<br>
      <br>
      </span></li>

      <li><span style="font-weight: bold;">The /etc/shorewall/masq
      file has had the spurious "/" character at the front
      removed.<br>
      <br>
      </span></li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>

      <li>The per-interface Dynamic Blacklisting facility
      introduced in the first post-1.4.6 Snapshot has been removed.
      The facility had too many idiosyncrasies for dial-up users to
      be a viable part of Shorewall.<br>
      </li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.</li>
    </ol>

    <p><b>10/02/2003 - Shorewall 1.4.7 RC2</b><b><br>
    </b></p>

    <p><b><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6 (Those in bold font
    were corrected since 1.4.7 RC 1).</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.</li>

      <li value="7">The 'shorewall reject' and 'shorewall drop'
      commands now delete any existing rules for the subject IP
      address before adding a new DROP or REJECT rule. Previously,
      there could be many rules for the same IP address in the
      dynamic chain so that multiple 'allow' commands were required
      to re-enable traffic to/from the address.</li>

      <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
      following entry in /etc/shorewall/masq resulted in a startup
      error:<br>
       &nbsp;<br>
       &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
      206.124.146.20-206.124.146.24<br>
      <br>
      </li>

      <li>Shorewall previously choked over IPV6 addresses
      configured on interfaces in contexts where Shorewall needed
      to detect something about the interface (such as when
      "detect" appears in the BROADCAST column of the
      /etc/shorewall/interfaces file).</li>

      <li>Shorewall will now load module files that are formed from
      the module name by appending ".o.gz".</li>

      <li>When Shorewall adds a route to a proxy ARP host and such
      a route already exists, two routes resulted previously. This
      has been corrected so that the existing route is replaced if
      it already exists.</li>

      <li>The rfc1918 file has been updated to reflect recent
      allocations.</li>

      <li><span style="font-weight: bold;">The documentation of the
      USER SET column in the rules file has been
      corrected.</span></li>

      <li><span style="font-weight: bold;">If there is no policy
      defined for the zones specified in a rule, the firewall
      script previously encountered a shell syntax error:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [: NONE:
      unexpected operator<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       Now, the absence of a policy generates an error message and
      the firewall is stopped:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; No policy defined
      from zone &lt;source&gt; to zone &lt;dest&gt;<br>
      <br>
      </span></li>

      <li><span style="font-weight: bold;">Previously, if neither
      /etc/shorewall/common nor /etc/shorewall/common.def existed,
      Shorewall would fail to start and would not remove the lock
      file. Failure to remove the lock file resulted in the
      following during subsequent attempts to start:<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>

       &nbsp;&nbsp;&nbsp; Loading
      /usr/share/shorewall/functions...<br>
       &nbsp;&nbsp;&nbsp; Processing /etc/shorewall/params ...<br>
       &nbsp;&nbsp;&nbsp; Processing
      /etc/shorewall/shorewall.conf...<br>
       &nbsp;&nbsp;&nbsp; Giving up on lock file
      /var/lib/shorewall/lock<br>
       &nbsp;&nbsp;&nbsp; Shorewall Not Started<br>
      <br>
       Shorewall now reports a fatal error if neither of these two
      files exist and correctly removes the lock fille.</span></li>

      <li><span style="font-weight: bold;">The order of processing
      the various options has been changed such that blacklist
      entries now take precedence over the 'dhcp' interface
      setting.</span></li>

      <li><span style="font-weight: bold;">The log message
      generated from the 'logunclean' interface option has been
      changed to reflect a disposition of LOG rather than
      DROP.</span></li>

      <li><span style="font-weight: bold;">The RFC1918 file has
      been updated to reflect recent IANA allocations.<br>
      </span></li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>

      <li>The per-interface Dynamic Blacklisting facility
      introduced in the first post-1.4.6 Snapshot has been removed.
      The facility had too many idiosyncrasies for dial-up users to
      be a viable part of Shorewall.<br>
      </li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.</li>
    </ol>

    <p><b>9/18/2003 - Shorewall 1.4.7 RC 1</b><b><br>
    </b></p>

    <p><b><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6 (Those in bold font
    were corrected since 1.4.7 Beta 1).</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.</li>

      <li value="7">The 'shorewall reject' and 'shorewall drop'
      commands now delete any existing rules for the subject IP
      address before adding a new DROP or REJECT rule. Previously,
      there could be many rules for the same IP address in the
      dynamic chain so that multiple 'allow' commands were required
      to re-enable traffic to/from the address.</li>

      <li>When ADD_SNAT_ALIASES=Yes in shorewall.conf, the
      following entry in /etc/shorewall/masq resulted in a startup
      error:<br>
       &nbsp;<br>
       &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
      206.124.146.20-206.124.146.24<br>
      <br>
      </li>

      <li>Shorewall previously choked over IPV6 addresses
      configured on interfaces in contexts where Shorewall needed
      to detect something about the interface (such as when
      "detect" appears in the BROADCAST column of the
      /etc/shorewall/interfaces file).</li>

      <li>Shorewall will now load module files that are formed from
      the module name by appending ".o.gz".</li>

      <li style="font-weight: bold;">When Shorewall adds a route to
      a proxy ARP host and such a route already exists, two routes
      resulted previously. This has been corrected so that the
      existing route is replaced if it already exists.</li>

      <li><span style="font-weight: bold;">The rfc1918 file has
      been updated to reflect recent allocations.</span><br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>

      <li>The per-interface Dynamic Blacklisting facility
      introduced in the first post-1.4.6 Snapshot has been removed.
      The facility had too many idiosyncrasies for dial-up users to
      be a viable part of Shorewall.<br>
      </li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.</li>
    </ol>

    <p><b>9/15/2003 - Shorewall 1.4.7 Beta 2</b> <b><br>
    </b></p>

    <p><b><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6 (Those in bold font
    were corrected since 1.4.7 Beta 1).</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.</li>

      <li value="7" style="font-weight: bold;">The 'shorewall
      reject' and 'shorewall drop' commands now delete any existing
      rules for the subject IP address before adding a new DROP or
      REJECT rule. Previously, there could be many rules for the
      same IP address in the dynamic chain so that multiple 'allow'
      commands were required to re-enable traffic to/from the
      address.</li>

      <li style="font-weight: bold;">When ADD_SNAT_ALIASES=Yes in
      shorewall.conf, the following entry in /etc/shorewall/masq
      resulted in a startup error:<br>
       &nbsp;<br>
       &nbsp;&nbsp; eth0 eth1&nbsp;&nbsp;&nbsp;&nbsp;
      206.124.146.20-206.124.146.24<br>
      <br>
      </li>

      <li style="font-weight: bold;">Shorewall previously choked
      over IPV6 addresses configured on interfaces in contexts
      where Shorewall needed to detect something about the
      interface (such as when "detect" appears in the BROADCAST
      column of the /etc/shorewall/interfaces file).</li>

      <li><span style="font-weight: bold;">Shorewall will now load
      module files that are formed from the module name by
      appending ".o.gz".</span><br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>

      <li>The per-interface Dynamic Blacklisting facility
      introduced in the first post-1.4.6 Snapshot has been removed.
      The facility had too many idiosyncrasies for dial-up users to
      be a viable part of Shorewall.<br>
      </li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.</li>
    </ol>

    <p><b>8/27/2003 - Shorewall Mirror in Australia</b></p>

    <p>Thanks to Dave Kempe and Solutions First (<a href=
    "http://www.solutionsfirst.com.au"><font size=
    "3">http://www.solutionsfirst.com.au</font></a>), there is now
    a Shorewall Mirror in Australia:</p>

    <div style="margin-left: 40px;">
      <a href="http://www.shorewall.com.au" target="_top"><font
      size="3">http://www.shorewall.com.au</font></a><br>
       <a href="ftp://ftp.shorewall.com.au"><font size=
      "3">ftp://ftp.shorewall.com.au</font></a>
    </div>

    <p><b>8/26/2003 - French Version of the Shorewall Setup
    Guide&nbsp;</b></p>
    Thanks to Fabien <font size="3">Demassieux, there is now a <a
    href="shorewall_setup_guide_fr.htm">French translation of the
    Shorewall Setup Guide</a>. Merci Beacoup, Fabien!</font>

    <p><b>8/25/2003 - Shorewall 1.4.7 Beta 1</b> <b><br>
    </b></p>

    <p><b><a href=
    "http://shorewall.net/pub/shorewall/Beta">http://shorewall.net/pub/shorewall/Beta</a><br>

     <a href="ftp://shorewall.net/pub/shorewall/Beta" target=
    "_top">ftp://shorewall.net/pub/shorewall/Beta</a><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.<br>
      <br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>

      <li>The per-interface Dynamic Blacklisting facility
      introduced in the first post-1.4.6 Snapshot has been removed.
      The facility had too many idiosyncrasies for dial-up users to
      be a viable part of Shorewall.<br>
      </li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.<br>
      </li>
    </ol>

    <p><b>8/23/2003 - Snapshot 1.4.6_2003082</b><span style=
    "font-weight: bold;">3</span></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>
    <b>Problems Corrected since version 1.4.6</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>Interface-specific dynamic blacklisting chains are now
      displayed by "shorewall monitor" on the "Dynamic Chains" page
      (previously named "Dynamic Chain").</li>

      <li>Thanks to Henry Yang, LOGRATE and LOGBURST now work
      again.<br>
      <br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>

      <li>Shorewall IP Traffic Accounting has changed since
      snapshot 20030813 -- see the <a href=
      "Accounting.html">Accounting Page</a> for details.</li>

      <li>The Uset Set capability introduced in SnapShot 20030821
      has changed -- see the <a href="UserSets.html">User Set
      page</a> for details.</li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Shorewall now creates a dynamic blacklisting chain for
      each interface defined in /etc/shorewall/interfaces. The
      'drop' and 'reject' commands use the routing table to
      determine which of these chains is to be used for
      blacklisting the specified IP address(es).<br>
      <br>
       Two new commands ('dropall' and 'rejectall') have been
      introduced that do what 'drop' and 'reject' used to do;
      namely, when an address is blacklisted using these new
      commands, it will be blacklisted on all of your firewall's
      interfaces.</li>

      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit,<br>
      <br>
       a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
      <br>
       b) A new RATE LIMIT column has been added to the
      /etc/shorewall/rules file. You may specify the rate limit
      there in the format:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>

      <li>Multiple chains may now be displayed in one "shorewall
      show" command (e.g., shorewall show INPUT FORWARD
      OUTPUT).</li>

      <li>Output rules (those with $FW as the SOURCE) may now be
      limited to a set of local users and/or groups. See <a href=
      "UserSets.html">http://shorewall.net/UserSets.html</a> for
      details.<br>
      </li>
    </ol>

    <p><b>8/13/2003 - Snapshot 1.4.6_20030813</b><b>&nbsp;</b></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>
    <b>Problems Corrected since version 1.4.6</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages</li>

      <li>&nbsp;Interface-specific dynamic blacklisting chains are
      now displayed by "shorewall monitor" on the "Dynamic Chains"
      page (previously named "Dynamic Chain").<br>
      <br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Shorewall now creates a dynamic blacklisting chain for
      each interface defined in /etc/shorewall/interfaces. The
      'drop' and 'reject' commands use the routing table to
      determine which of these chains is to be used for
      blacklisting the specified IP address(es).<br>
      <br>
       Two new commands ('dropall' and 'rejectall') have been
      introduced that do what 'drop' and 'reject' used to do;
      namely, when an address is blacklisted using these new
      commands, it will be blacklisted on all of your firewall's
      interfaces.</li>

      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.</li>

      <li>The ADDRESS column in /etc/shorewall/masq may now include
      a comma-separated list of addresses and/or address ranges.
      Netfilter will use all listed addresses/ranges in round-robin
      fashion. \</li>

      <li>An /etc/shorewall/accounting file has been added to allow
      for traffic accounting.&nbsp; See the <a href=
      "Accounting.html">accounting documentation</a> for a
      description of this facility.</li>

      <li>Bridge interfaces (br[0-9]) may now be used in
      /etc/shorewall/maclist.</li>

      <li>ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
      /etc/shorewall/rules may now be rate-limited. For DNAT and
      REDIRECT rules, rate limiting occurs in the nat table DNAT
      rule; the corresponding ACCEPT rule in the filter table is
      not rate limited. If you want to limit the filter table rule,
      you will need o create two rules; a DNAT- rule and an ACCEPT
      rule which can be rate-limited separately.<br>
       &nbsp;<br>
       <span style="font-weight: bold;">Warning:</span> When rate
      limiting is specified on a rule with "all" in the SOURCE or
      DEST fields, the limit will apply to each pair of zones
      individually rather than as a single limit for all pairs of
      covered by the rule.<br>
       &nbsp;<br>
       To specify a rate limit, follow ACCEPT, DNAT[-], REDIRECT[-]
      or LOG with<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;
      &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
       &nbsp;<br>
       &nbsp;&nbsp; where<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;rate&gt; is the sustained
      rate per &lt;interval&gt;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;interval&gt; is "sec" or
      "min"<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;burst&gt; is the largest
      burst accepted within an &lt;interval&gt;. If not given, the
      default of 5 is assumed.<br>
       &nbsp;<br>
       There may be no white space between the ACTION and "&lt;"
      nor there may be any white space within the burst
      specification. If you want to specify logging of a
      rate-limited rule, the ":" and log level comes after the
      "&gt;" (e.g., ACCEPT&lt;2/sec:4&gt;:info ).<br>
       &nbsp;<br>
       Let's take an example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net&nbsp;&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;&nbsp;
      tcp&nbsp;&nbsp;&nbsp;&nbsp; 80<br>
       &nbsp;&nbsp;&nbsp;<br>
       The first time this rule is reached, the packet will be
      accepted; in fact, since the burst is 4, the first four
      packets will be accepted. After this, it will be 500ms (1
      second divided by the rate<br>
       of 2) before a packet will be accepted from this rule,
      regardless of how many packets reach it. Also, every 500ms
      which passes without matching a packet, one of the bursts
      will be regained; if no packets hit the rule for 2 second,
      the burst will be fully recharged; back where we started.<br>
      </li>
    </ol>

    <p><b>8/9/2003 - Snapshot 1.4.6_20030809</b><b>&nbsp;</b></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>
    <b>Problems Corrected since version 1.4.6</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages<br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Shorewall now creates a dynamic blacklisting chain for
      each interface defined in /etc/shorewall/interfaces. The
      'drop' and 'reject' commands use the routing table to
      determine which of these chains is to be used for
      blacklisting the specified IP address(es).<br>
      <br>
       Two new commands ('dropall' and 'rejectall') have been
      introduced that do what 'drop' and 'reject' used to do;
      namely, when an address is blacklisted using these new
      commands, it will be blacklisted on all of your firewall's
      interfaces.</li>

      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>

      <li>Given the wide range of VPN software, I can never hope to
      add specific support for all of it. I have therefore decided
      to add "generic" tunnel support.<br>
       &nbsp;<br>
       Generic tunnels work pretty much like any of the other
      tunnel types. You usually add a zone to represent the systems
      at the other end of the tunnel and you add the appropriate
      rules/policies to<br>
       implement your security policy regarding traffic to/from
      those systems.<br>
       &nbsp;<br>
       In the /etc/shorewall/tunnels file, you can have entries of
      the form:<br>
      <br>
       generic:&lt;protocol&gt;[:&lt;port&gt;]&nbsp;
      &lt;zone&gt;&nbsp; &lt;ip address&gt;&nbsp;&nbsp;&nbsp;
      &lt;gateway zones&gt;<br>
       &nbsp;<br>
       where:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;protocol&gt; is the
      protocol used by the tunnel<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;port&gt;&nbsp; if
      the protocol is 'udp' or 'tcp' then this is the destination
      port number used by the tunnel.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;zone&gt;&nbsp; is
      the zone of the remote tunnel gateway<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;ip address&gt; is
      the IP address of the remote tunnel gateway.<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;gateway
      zone&gt;&nbsp;&nbsp; Optional. A comma-separated list of zone
      names. If specified, the remote gateway is to be considered
      part of these zones.</li>

      <li>An 'arp_filter' option has been added to the
      /etc/shorewall/interfaces file. This option causes
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be
      set with the result that this interface will only answer ARP
      'who-has' requests from hosts that are routed out through
      that interface. Setting this option facilitates testing of
      your firewall where multiple firewall interfaces are
      connected to the same HUB/Switch (all interfaces connected to
      the single HUB/Switch should have this option specified).
      Note that using such a configuration in a production
      environment is strongly recommended against.<br>
      </li>
    </ol>

    <p><b>8/5/2003 - Shorewall-1.4.6b</b><b>&nbsp;<br>
    </b></p>
    <b>Problems Corrected since version 1.4.6:</b><br>


    <ol>
      <li>Previously, if TC_ENABLED is set to yes in shorewall.conf
      then Shorewall would fail to start with the error "ERROR:
      &nbsp;Traffic Control requires Mangle"; that problem has been
      corrected.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages.</li>
    </ol>

    <p><b>8/5/2003 - Shorewall-1.4.6b</b> <b><br>
    </b></p>
    <b>Problems Corrected since version 1.4.6:</b><br>


    <ol>
      <li>Previously, if TC_ENABLED is set to yes in shorewall.conf
      then Shorewall would fail to start with the error "ERROR:
      &nbsp;Traffic Control requires Mangle"; that problem has been
      corrected.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.</li>

      <li>The "shorewall stop" command is now disabled when
      /etc/shorewall/startup_disabled exists. This prevents people
      from shooting themselves in the foot prior to having
      configured Shorewall.</li>

      <li>A change introduced in version 1.4.6 caused error
      messages during "shorewall [re]start" when ADD_IP_ALIASES=Yes
      and ip addresses were being added to a PPP interface; the
      addresses were successfully added in spite of the
      messages.<br>
       &nbsp;&nbsp;<br>
       The firewall script has been modified to eliminate the error
      messages.<br>
      </li>
    </ol>

    <p><b>7/31/2003 - Snapshot 1.4.6_20030731</b></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>

    <p><b>Problems Corrected since version 1.4.6:</b><br>
    </p>

    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.<br>
      </li>
    </ol>

    <p><b>Migration Issues:</b><br>
    </p>

    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>
    </ol>

    <p><b>New Features:</b><br>
    </p>

    <ol>
      <li>Shorewall now creates a dynamic blacklisting chain for
      each interface defined in /etc/shorewall/interfaces. The
      'drop' and 'reject' commands use the routing table to
      determine which of these chains is to be used for
      blacklisting the specified IP address(es).<br>
      <br>
       Two new commands ('dropall' and 'rejectall') have been
      introduced that do what 'drop' and 'reject' used to do;
      namely, when an address is blacklisted using these new
      commands, it will be blacklisted on all of your firewall's
      interfaces.</li>

      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).</li>

      <li>A new option "ADMINISABSENTMINDED" has been added to
      /etc/shorewall/shorewall.conf. This option has a default
      value of "No" for existing users which causes Shorewall's
      'stopped' state &nbsp;to continue as it has been; namely, in
      the stopped state only traffic to/from hosts listed in
      /etc/shorewall/routestopped is accepted.<br>
      <br>
       With ADMINISABSENTMINDED=Yes (the default for new installs),
      in addition to traffic to/from the hosts listed in
      /etc/shorewall/routestopped, Shorewall will allow:<br>
      <br>
       &nbsp;&nbsp; a) All traffic originating from the firewall
      itself; and<br>
       &nbsp;&nbsp; b) All traffic that is part of or related to an
      already-existing connection.<br>
      <br>
       &nbsp;In particular, with ADMINISABSENTMINDED=Yes, a
      "shorewall stop" entered through an ssh session will not kill
      the session.<br>
      <br>
       &nbsp;Note though that even with ADMINISABSENTMINDED=Yes, it
      is still possible for people to shoot themselves in the
      foot.<br>
      <br>
       &nbsp;Example:<br>
      <br>
       &nbsp;/etc/shorewall/nat:<br>
      <br>
       &nbsp; &nbsp; &nbsp;206.124.146.178&nbsp;&nbsp;&nbsp;
      eth0:0&nbsp;&nbsp;&nbsp; 192.168.1.5&nbsp;&nbsp;&nbsp;<br>
      <br>
       &nbsp;/etc/shorewall/rules:<br>
      <br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp;
      loc:192.168.1.5&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
       &nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp;
      fw&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp;
      22<br>
      <br>
       From a remote system, I ssh to 206.124.146.178 which
      establishes an SSH connection with local system 192.168.1.5.
      I then create a second SSH connection from that computer to
      the firewall and confidently type "shorewall stop". As part
      of its stop processing, Shorewall removes eth0:0 which kills
      my SSH connection to 192.168.1.5!!!</li>
    </ol>

    <p><b>7/27/2003 - Snapshot 1.4.6_20030727</b></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>
    <b>Problems Corrected since version 1.4.6</b><br>


    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.<br>
      </li>
    </ol>
    <b>Migration Issues:</b><br>


    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>
    </ol>
    <b>New Features:</b><br>


    <ol>
      <li>Shorewall now creates a dynamic blacklisting chain for
      each interface defined in /etc/shorewall/interfaces. The
      'drop' and 'reject' commands use the routing table to
      determine which of these chains is to be used for
      blacklisting the specified IP address(es).<br>
      <br>
       Two new commands ('dropall' and 'rejectall') have been
      introduced that do what 'drop' and 'reject' used to do;
      namely, when an address is blacklisted using these new
      commands, it will be blacklisted on all of your firewall's
      interfaces.</li>

      <li>Thanks to Steve Herber, the 'help' command can now give
      command-specific help (e.g., shorewall help
      &lt;command&gt;).<br>
      </li>
    </ol>

    <p><b>7/26/2003 - Snapshot 1.4.6_20030726</b></p>

    <blockquote>
      <p><a href=
      "http://shorewall.net/pub/shorewall/Snapshots/">http://shorewall.net/pub/shorewall/Snapshots/</a><br>

       <a href="ftp://shorewall.net/pub/shorewall/Snapshots/"
      target=
      "_top">ftp://shorewall.net/pub/shorewall/Snapshots/</a></p>
    </blockquote>

    <p><b>Problems Corrected since version 1.4.6:</b><br>
    </p>

    <ol>
      <li>Corrected problem in 1.4.6 where the MANGLE_ENABLED
      variable was being tested before it was set.</li>

      <li>Corrected handling of MAC addresses in the SOURCE column
      of the tcrules file. Previously, these addresses resulted in
      an invalid iptables command.<br>
      </li>
    </ol>

    <p><b>Migration Issues:</b><br>
    </p>

    <ol>
      <li>Once you have installed this version of Shorewall, you
      must restart Shorewall before you may use the 'drop',
      'reject', 'allow' or 'save' commands.</li>

      <li>To maintain strict compatibility with previous versions,
      current uses of "shorewall drop" and "shorewall reject"
      should be replaced with "shorewall dropall" and "shorewall
      rejectall"</li>
    </ol>

    <p><b>New Features:</b><br>
    </p>
    Shorewall now creates a dynamic blacklisting chain for each
    interface defined in /etc/shorewall/interfaces. The 'drop' and
    'reject' commands use the routing table to determine which of
    these chains is to be used for blacklisting the specified IP
    address(es).<br>
     <br>
     Two new commands ('dropall' and 'rejectall') have been
    introduced that do what 'drop' and 'reject' used to do; namely,
    when an address is blacklisted using these new commands, it
    will be blacklisted on all of your firewall's interfaces.

    <p><b>7/22/2003 - Shorewall-1.4.6a</b> <b><br>
    </b></p>
    <b>Problems Corrected:</b><br>


    <ol>
      <li>Previously, if TC_ENABLED is set to yes in shorewall.conf
      then Shorewall would fail to start with the error "ERROR:
      &nbsp;Traffic Control requires Mangle"; that problem has been
      corrected.</li>
    </ol>

    <p><b>7/20/2003 - Shorewall-1.4.6</b> <b><br>
    </b></p>

    <p><b>Problems Corrected:</b><br>
    </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>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>
      <br>
      </li>

      <li>A number of problems with rule parsing have been
      corrected. Corrections involve the handling of "z1!z2" in the
      SOURCE column as well as lists in the ORIGINAL DESTINATION
      column.<br>
      <br>
      </li>

      <li>The message "Adding rules for DHCP" is now suppressed if
      there are no DHCP rules to add.<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>
       &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
      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>
       &nbsp; &nbsp; z&nbsp;&nbsp;
      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. Servers may be specified
      in a range of addresses given as &lt;first
      address&gt;-&lt;last address&gt;.<br>
      <br>
       Example:<br>
      <br>
       &nbsp; &nbsp; 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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;Multi-port Match: Available<br>
       &nbsp; &nbsp;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>

      <li style=
      "list-style-type: none; list-style-position: outside; list-style-image: none;">
        <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>
        </ul>
      </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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt;
      &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt; ]<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0 255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#
      shorewall iprange 192.168.1.4-192.168.12.9<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
      eth1:192.168.1.0/24,192.168.2.0/24<br>
      <br>
      </li>

      <li>The "shorewall check" command now includes the chain name
      when printing the applicable policy for each pair of
      zones.<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp; Example:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Policy for dmz to
      net is REJECT using chain all2all<br>
       &nbsp;<br>
       This means that the policy for connections from the dmz to
      the internet is REJECT and the applicable entry in the
      /etc/shorewall/policy was the all-&gt;all policy.<br>
      <br>
      </li>

      <li>Support for the 2.6 Kernel series has been added.<br>
      </li>
    </ol>

    <p><b>7/15/2003 - New Mirror in Brazil</b><b><br>
    </b></p>
    Thanks to the folks at securityopensource.org.br, there is now
    a <a href="http://shorewall.securityopensource.org.br" target=
    "_top">Shorewall mirror in Brazil</a>.

    <p><b>7/15/2003 - Shorewall-1.4.6 RC 1</b> <b><br>
    </b></p>

    <p><b>Problems Corrected:</b><br>
    </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>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>
      <br>
      </li>

      <li>A number of problems with rule parsing have been
      corrected. Corrections involve the handling of "z1!z2" in the
      SOURCE column as well as lists in the ORIGINAL DESTINATION
      column.<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>
       &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
      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>
       &nbsp; &nbsp; z&nbsp;&nbsp;
      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. Servers may be specified
      in a range of addresses given as &lt;first
      address&gt;-&lt;last address&gt;.<br>
      <br>
       Example:<br>
      <br>
       &nbsp; &nbsp; 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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;Multi-port Match: Available<br>
       &nbsp; &nbsp;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>

      <li style=
      "list-style-type: none; list-style-position: outside; list-style-image: none;">
        <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>
        </ul>
      </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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt;
      &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt; ]<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0 255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#
      shorewall iprange 192.168.1.4-192.168.12.9<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
      eth1:192.168.1.0/24,192.168.2.0/24</li>
    </ol>

    <p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b></p>

    <p><b>Problems Corrected:</b><br>
    </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>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>
       &nbsp; &nbsp; z&nbsp;&nbsp;&nbsp;
      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>
       &nbsp; &nbsp; z&nbsp;&nbsp;
      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. Servers may be specified
      in a range of addresses given as &lt;first
      address&gt;-&lt;last address&gt;.<br>
      <br>
       Example:<br>
      <br>
       &nbsp; &nbsp; 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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;Multi-port Match: Available<br>
       &nbsp; &nbsp;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>

      <li style=
      "list-style-type: none; list-style-position: outside; list-style-image: none;">
        <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>
        </ul>
      </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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ipcalc [ &lt;address&gt;
      &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt; ]<br>
      <br>
       Examples:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]#<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@wookie root]# shorewall
      ipcalc 192.168.1.0 255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      CIDR=192.168.1.0/24<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETMASK=255.255.255.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      NETWORK=192.168.1.0<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      BROADCAST=192.168.1.255<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [root@gateway root]#
      shorewall iprange 192.168.1.4-192.168.12.9<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.4/30<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.8/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.16/28<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.32/27<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.64/26<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.128/25<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.2.0/23<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.4.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.8.0/22<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.0/29<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.12.8/31<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [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>
       &nbsp;&nbsp;&nbsp; foo&nbsp;&nbsp;&nbsp;
      eth1:192.168.1.0/24,192.168.2.0/24<br>
      <br>
      </li>
    </ol>

    <p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b></p>

    <p><b>Problems Corrected:</b><br>
    </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>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>

    <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>
       &nbsp; &nbsp; 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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;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>
       &nbsp; &nbsp;NAT: Available<br>
       &nbsp; &nbsp;Packet Mangling: Available<br>
       &nbsp; &nbsp;Multi-port Match: Available<br>
       &nbsp; &nbsp;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>

      <li style=
      "list-style-type: none; list-style-position: outside; list-style-image: none;">
        <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>
        </ul>
      </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>
      </li>
    </ol>

    <p><b>6/17/2003 - Shorewall-1.4.5</b></p>

    <p>Problems Corrected:<br>
    </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>
    </ol>

    <p>New Features:<br>
    </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>
    </ol>

    <p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables
    1.2.8</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></p>

    <p>Thanks to Francesca Smith, the samples have been updated to
    Shorewall version 1.4.4.</p>

    <p><b>5/29/2003 - Shorewall-1.4.4b</b></p>

    <p>Groan -- This version corrects a problem whereby the
    --log-level was not being set when logging via syslog. The most
    commonly reported symptom was that Shorewall messages were
    being written to the console even though console logging was
    correctly configured per FAQ 16.<br>
    </p>

    <p><b>5/27/2003 - Shorewall-1.4.4a</b></p>
    The Fireparse --log-prefix fiasco continues. Tuomo Soini has
    pointed out that the code in 1.4.4 restricts the length of
    short zone names to 4 characters. I've produced version 1.4.4a
    that restores the previous 5-character limit by conditionally
    omitting the log rule number when the LOGFORMAT doesn't contain
    '%d'. <br>


    <p><b>5/23/2003 - Shorewall-1.4.4</b></p>
    I apologize for the rapid-fire releases but since there is a
    potential configuration change required to go from 1.4.3a to
    1.4.4, I decided to make it a full release rather than just a
    bug-fix release. <br>
     <br>
     <b>&nbsp;&nbsp;&nbsp; Problems corrected:</b><br>


    <blockquote>
      None.<br>
    </blockquote>
    <b>&nbsp;&nbsp;&nbsp; New Features:<br>
    </b>

    <ol>
      <li>A REDIRECT- rule target has been added. This target
      behaves for REDIRECT in the same way as DNAT- does for DNAT
      in that the Netfilter nat table REDIRECT rule is added but
      not the companion filter table ACCEPT rule.<br>
      <br>
      </li>

      <li>The LOGMARKER variable has been renamed LOGFORMAT and has
      been changed to a 'printf' formatting template which accepts
      three arguments (the chain name, logging rule number and the
      disposition). To use LOGFORMAT with fireparse (<a href=
      "http://www.fireparse.com">http://www.fireparse.com</a>), set
      it as:<br>
       &nbsp;<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOGFORMAT="fp=%s:%d
      a=%s "<br>
       &nbsp;<br>
       <b>CAUTION:</b> /sbin/shorewall uses the leading part of the
      LOGFORMAT string (up to but not including the first '%') to
      find log messages in the 'show log', 'status' and 'hits'
      commands. This part should not be omitted (the LOGFORMAT
      should not begin with "%") and the leading part should be
      sufficiently unique for /sbin/shorewall to identify Shorewall
      messages.<br>
      <br>
      </li>

      <li>When logging is specified on a DNAT[-] or REDIRECT[-]
      rule, the logging now takes place in the nat table rather
      than in the filter table. This way, only those connections
      that actually undergo DNAT or redirection will be logged.<br>
      </li>
    </ol>

    <p><b>5/20/2003 - Shorewall-1.4.3a</b><br>
    </p>
    This version primarily corrects the documentation included in
    the .tgz and in the .rpm. In addition: <br>


    <ol>
      <li>(This change is in 1.4.3 but is not documented) If you
      are running iptables 1.2.7a and kernel 2.4.20, then Shorewall
      will return reject replies as follows:<br>
       &nbsp;&nbsp; a) tcp - RST<br>
       &nbsp;&nbsp; b) udp - ICMP port unreachable<br>
       &nbsp;&nbsp; c) icmp - ICMP host unreachable<br>
       &nbsp;&nbsp; d) Otherwise - ICMP host prohibited<br>
       If you are running earlier software, Shorewall will follow
      it's traditional convention:<br>
       &nbsp;&nbsp; a) tcp - RST<br>
       &nbsp;&nbsp; b) Otherwise - ICMP port unreachable</li>

      <li>UDP port 135 is now silently dropped in the common.def
      chain. Remember that this chain is traversed just before a
      DROP or REJECT policy is enforced.<br>
      </li>
    </ol>

    <p><b>5/18/2003 - Shorewall 1.4.3</b><br>
    </p>
    &nbsp;&nbsp;&nbsp; <b>Problems Corrected:<br>
    </b>

    <ol>
      <li>There were several cases where Shorewall would fail to
      remove a temporary directory from /tmp. These cases have been
      corrected.</li>

      <li>The rules for allowing all traffic via the loopback
      interface have been moved to before the rule that drops
      status=INVALID packets. This insures that all loopback
      traffic is allowed even if Netfilter connection tracking is
      confused.</li>
    </ol>
    &nbsp;&nbsp;&nbsp; <b>New Features:<br>
    </b>

    <ol>
      <li>&nbsp;IPV6-IPV4 (6to4) tunnels are now supported in the
      /etc/shorewall/tunnels file.</li>

      <li value="2">You may now change the leading portion of the
      --log-prefix used by Shorewall using the LOGMARKER variable
      in shorewall.conf. By default, "Shorewall:" is used.<br>
      </li>
    </ol>

    <p><b>5/10/2003 - Shorewall Mirror in Asia<br>
    </b></p>

    <p>Ed Greshko has established a mirror in Taiwan -- Thanks
    Ed!<br>
    </p>

    <p><b>5/8/2003 - Shorewall Mirror in Chile</b></p>
    Thanks to Darcy Ganga, there is now an HTTP mirror in Santiago
    Chile.

    <p><b>4/21/2003 - Samples updated for Shorewall version
    1.4.2</b></p>

    <p>Thanks to Francesca Smith, the sample configurations are now
    upgraded to Shorewall version 1.4.2.</p>

    <p><b>4/9/2003 - Shorewall 1.4.2</b><br>
    </p>

    <p><b>&nbsp;&nbsp;&nbsp; Problems Corrected:</b></p>

    <blockquote>
      <ol>
        <li>TCP connection requests rejected out of the
        <b>common</b> chain are now properly rejected with TCP RST;
        previously, some of these requests were rejected with an
        ICMP port-unreachable response.</li>

        <li>'traceroute -I' from behind the firewall previously
        timed out on the first hop (e.g., to the firewall). This
        has been worked around.</li>
      </ol>
    </blockquote>

    <p><b>&nbsp;&nbsp;&nbsp; New Features:</b></p>

    <ol>
      <li>Where an entry in the/etc/shorewall/hosts file specifies
      a particular host or network, Shorewall now creates an
      intermediate chain for handling input from the related zone.
      This can substantially reduce the number of rules traversed
      by connections requests from such zones.<br>
      <br>
      </li>

      <li>Any file may include an INCLUDE directive. An INCLUDE
      directive consists of the word INCLUDE followed by a file
      name and causes the contents of the named file to be
      logically included into the file containing the INCLUDE. File
      names given in an INCLUDE directive are assumed to reside in
      /etc/shorewall or in an alternate configuration directory if
      one has been specified for the command.<br>
       &nbsp;<br>
       &nbsp;&nbsp; Examples:<br>
       &nbsp;&nbsp; shorewall/params.mgmt:<br>
       &nbsp;&nbsp; MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3<br>
       &nbsp;&nbsp; TIME_SERVERS=4.4.4.4<br>
       &nbsp;&nbsp; BACKUP_SERVERS=5.5.5.5<br>
       &nbsp;&nbsp; ----- end params.mgmt -----<br>
       &nbsp;<br>
       &nbsp;<br>
       &nbsp;&nbsp; shorewall/params:<br>
       &nbsp;&nbsp; # Shorewall 1.3 /etc/shorewall/params<br>
       &nbsp;&nbsp; [..]<br>
       &nbsp;&nbsp; #######################################<br>
       &nbsp;<br>
       &nbsp; &nbsp;INCLUDE params.mgmt&nbsp;&nbsp;&nbsp;<br>
       &nbsp;<br>
       &nbsp;&nbsp; # params unique to this host here<br>
       &nbsp;&nbsp; #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE -
      DO NOT REMOVE<br>
       &nbsp;&nbsp; ----- end params -----<br>
       &nbsp;<br>
       &nbsp;<br>
       &nbsp;&nbsp; shorewall/rules.mgmt:<br>
       &nbsp;&nbsp; ACCEPT
      net:$MGMT_SERVERS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      $FW&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
       &nbsp;&nbsp; ACCEPT
      $FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net:$TIME_SERVERS&nbsp;&nbsp;&nbsp; udp&nbsp;&nbsp;&nbsp;
      123<br>
       &nbsp;&nbsp; ACCEPT
      $FW&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      net:$BACKUP_SERVERS&nbsp; tcp&nbsp;&nbsp;&nbsp; 22<br>
       &nbsp;&nbsp; ----- end rules.mgmt -----<br>
       &nbsp;<br>
       &nbsp;&nbsp; shorewall/rules:<br>
       &nbsp;&nbsp; # Shorewall version 1.3 - Rules File<br>
       &nbsp;&nbsp; [..]<br>
       &nbsp;&nbsp; #######################################<br>
       &nbsp;<br>
       &nbsp;&nbsp; INCLUDE rules.mgmt&nbsp;&nbsp;&nbsp;&nbsp;<br>
       &nbsp;<br>
       &nbsp;&nbsp; # rules unique to this host here<br>
       &nbsp;&nbsp; #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE
      -- DO NOT REMOVE<br>
       &nbsp;&nbsp; ----- end rules -----<br>
       &nbsp;<br>
       INCLUDE's may be nested to a level of 3 -- further nested
      INCLUDE directives are ignored with a warning message.<br>
      <br>
      </li>

      <li>Routing traffic from an interface back out that interface
      continues to be a problem. While I firmly believe that this
      should never happen, people continue to want to do it. To
      limit the damage that such nonsense produces, I have added a
      new 'routeback' option in /etc/shorewall/interfaces and
      /etc/shorewall/hosts. When used in /etc/shorewall/interfaces,
      the 'ZONE' column may not contain '-'; in other words,
      'routeback' can't be used as an option for a multi-zone
      interface. The 'routeback' option CAN be specified however on
      individual group entries in /etc/shorewall/hosts.<br>
       &nbsp;<br>
       The 'routeback' option is similar to the old 'multi' option
      with two exceptions:<br>
       &nbsp;<br>
       &nbsp;&nbsp; a) The option pertains to a particular
      zone,interface,address tuple.<br>
       &nbsp;<br>
       &nbsp;&nbsp; b) The option only created infrastructure to
      pass traffic from (zone,interface,address) tuples back to
      themselves (the 'multi' option affected all
      (zone,interface,address) tuples associated with the given
      'interface').<br>
       &nbsp;<br>
       See the '<a href="upgrade_issues.htm">Upgrade Issues</a>'
      for information about how this new option may affect your
      configuration.<br>
      </li>
    </ol>

    <p><b>3/24/2003 - Shorewall 1.4.1</b></p>

    <p>This release follows up on 1.4.0. It corrects a problem
    introduced in 1.4.0 and removes additional warts.<br>
    <br>
     <b>Problems Corrected:</b><br>
    </p>

    <ol>
      <li>When Shorewall 1.4.0 is run under the ash shell (such as
      on Bering/LEAF), it can attempt to add ECN disabling rules
      even if the /etc/shorewall/ecn file is empty. That problem
      has been corrected so that ECN disabling rules are only added
      if there are entries in /etc/shorewall/ecn.</li>
    </ol>
    <b>New Features:</b><br>


    <blockquote>
      Note: In the list that follows, the term <i>group</i> 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. Examples:<br>


      <blockquote>
        eth0:0.0.0.0/0<br>
         eth2:192.168.1.0/24<br>
         eth3:192.0.2.123<br>
      </blockquote>
      You can use the "shorewall check" command to see the groups
      associated with each of your zones.<br>
    </blockquote>

    <ol>
      <li>Beginning with Shorewall 1.4.1, if a zone Z comprises
      more than one group then if there is no explicit Z to Z
      policy and there are no rules governing traffic from Z to Z
      then Shorewall will permit all traffic between the groups in
      the zone.</li>

      <li>Beginning with Shorewall 1.4.1, Shorewall will never
      create rules to handle traffic from a group to itself.</li>

      <li>A NONE policy is introduced in 1.4.1. When a policy of
      NONE is specified from Z1 to Z2:</li>
    </ol>

    <ul>
      <li>There may be no rules created that govern connections
      from Z1 to Z2.</li>

      <li>Shorewall will not create any infrastructure to handle
      traffic from Z1 to Z2.</li>
    </ul>
    See the <a href="upgrade_issues.htm">upgrade issues</a> for a
    discussion of how these changes may affect your configuration.

    <p><b>3/17/2003 - Shorewall 1.4.0</b></p>
    Shorewall 1.4 represents the next step in the evolution of
    Shorewall. The main thrust of the initial release is simply to
    remove the cruft that has accumulated in Shorewall over time.
    <br>
     <br>
     <b>IMPORTANT: Shorewall 1.4.0 requires</b> <b>the iproute
    package ('ip' utility).</b><br>
     <br>
     Function from 1.3 that has been omitted from this version
    include:<br>


    <ol>
      <li>The MERGE_HOSTS variable in shorewall.conf is no longer
      supported. Shorewall 1.4 behavior is the same as 1.3 with
      MERGE_HOSTS=Yes.<br>
      <br>
      </li>

      <li>Interface names of the form
      &lt;device&gt;:&lt;integer&gt; in /etc/shorewall/interfaces
      now generate an error.<br>
      <br>
      </li>

      <li>Shorewall 1.4 implements behavior consistent with
      OLD_PING_HANDLING=No. OLD_PING_HANDLING=Yes will generate an
      error at startup as will specification of the 'noping' or
      'filterping' interface options.<br>
      <br>
      </li>

      <li>The 'routestopped' option in the
      /etc/shorewall/interfaces and /etc/shorewall/hosts files is
      no longer supported and will generate an error at startup if
      specified.<br>
      <br>
      </li>

      <li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is
      no longer accepted.<br>
      <br>
      </li>

      <li>The ALLOWRELATED variable in shorewall.conf is no longer
      supported. Shorewall 1.4 behavior is the same as 1.3 with
      ALLOWRELATED=Yes.<br>
      <br>
      </li>

      <li>The icmp.def file has been removed.<br>
      </li>
    </ol>
    Changes for 1.4 include:<br>


    <ol>
      <li>The /etc/shorewall/shorewall.conf file has been
      completely reorganized into logical sections.<br>
      <br>
      </li>

      <li>LOG is now a valid action for a rule
      (/etc/shorewall/rules).<br>
      <br>
      </li>

      <li>The firewall script and version file are now installed in
      /usr/share/shorewall.<br>
      <br>
      </li>

      <li>Late arriving DNS replies are now silently dropped in the
      common chain by default.<br>
      <br>
      </li>

      <li>In addition to behaving like OLD_PING_HANDLING=No,
      Shorewall 1.4 no longer unconditionally accepts outbound ICMP
      packets. So if you want to 'ping' from the firewall, you will
      need the appropriate rule or policy.<br>
      <br>
      </li>

      <li>CONTINUE is now a valid action for a rule
      (/etc/shorewall/rules).<br>
      <br>
      </li>

      <li>802.11b devices with names of the form wlan&lt;n&gt; now
      support the 'maclist' option.<br>
      <br>
      </li>

      <li>Explicit Congestion Notification (ECN - RFC 3168) may now
      be turned off on a host or network basis using the new
      /etc/shorewall/ecn file. To use this facility:<br>
      <br>
       &nbsp;&nbsp; a) You must be running kernel 2.4.20<br>
       &nbsp;&nbsp; b) You must have applied the patch in<br>
       &nbsp;&nbsp;
      http://www.shorewall/net/pub/shorewall/ecn/patch.<br>
       &nbsp;&nbsp; c) You must have iptables 1.2.7a installed.<br>
      <br>
      </li>

      <li>The /etc/shorewall/params file is now processed first so
      that variables may be used in the
      /etc/shorewall/shorewall.conf file.<br>
      <br>
      </li>

      <li value="10">Shorewall now gives a more helpful diagnostic
      when the 'ipchains' compatibility kernel module is loaded and
      a 'shorewall start' command is issued.<br>
      <br>
      </li>

      <li>The SHARED_DIR variable has been removed from
      shorewall.conf. This variable was for use by package
      maintainers and was not documented for general use.<br>
      <br>
      </li>

      <li>Shorewall now ignores 'default' routes when detecting
      masq'd networks.</li>
    </ol>

    <p><b>3/10/2003 - Shoreall 1.3.14a</b></p>

    <p>A roleup of the following bug fixes and other updates:</p>

    <ul>
      <li>There is an updated rfc1918 file that reflects the resent
      allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
    </ul>

    <ul>
      <li>The documentation for the routestopped file claimed that
      a comma-separated list could appear in the second column
      while the code only supported a single host or network
      address.</li>

      <li>Log messages produced by 'logunclean' and 'dropunclean'
      were not rate-limited.</li>

      <li>802.11b devices with names of the form
      <i>wlan</i>&lt;n&gt; don't support the 'maclist' interface
      option.</li>

      <li>Log messages generated by RFC 1918 filtering are not rate
      limited.</li>

      <li>The firewall fails to start in the case where you have
      "eth0 eth1" in /etc/shorewall/masq and the default route is
      through eth1</li>
    </ul>

    <p><b>2/8/2003 - Shoreawall 1.3.14</b></p>

    <p>New features include</p>

    <ol>
      <li>An OLD_PING_HANDLING option has been added to
      shorewall.conf. When set to Yes, Shorewall ping handling is
      as it has always been (see
      http://www.shorewall.net/ping.html).<br>
      <br>
       When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
      rules and policies just like any other connection request.
      The FORWARDPING=Yes option in shorewall.conf and the 'noping'
      and 'filterping' options in /etc/shorewall/interfaces will
      all generate an error.<br>
      <br>
      </li>

      <li>It is now possible to direct Shorewall to create a
      "label" such as&nbsp; "eth0:0" for IP addresses that it
      creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
      This is done by specifying the label instead of just the
      interface name:<br>
       &nbsp;<br>
       &nbsp;&nbsp; a) In the INTERFACE column of
      /etc/shorewall/masq<br>
       &nbsp;&nbsp; b) In the INTERFACE column of
      /etc/shorewall/nat<br>
       &nbsp;</li>

      <li>Support for OpenVPN Tunnels.<br>
      <br>
      </li>

      <li>Support for VLAN devices with names of the form $DEV.$VID
      (e.g., eth0.0)<br>
      <br>
      </li>

      <li>In /etc/shorewall/tcrules, the MARK value may be
      optionally followed by ":" and either 'F' or 'P' to designate
      that the marking will occur in the FORWARD or PREROUTING
      chains respectively. If this additional specification is
      omitted, the chain used to mark packets will be determined by
      the setting of the MARK_IN_FORWARD_CHAIN option in <a href=
      "Documentation.htm#Conf">shorewall.conf</a>.<br>
      <br>
      </li>

      <li>
        When an interface name is entered in the SUBNET column of
        the /etc/shorewall/masq file, Shorewall previously
        masqueraded traffic from only the first subnet defined on
        that interface. It did not masquerade traffic from:<br>
         &nbsp;<br>
         &nbsp;&nbsp; a) The subnets associated with other
        addresses on the interface.<br>
         &nbsp;&nbsp; b) Subnets accessed through local
        routers.<br>
         &nbsp;<br>
         Beginning with Shorewall 1.3.14, if you enter an interface
        name in the SUBNET column, shorewall will use the
        firewall's routing table to construct the masquerading/SNAT
        rules.<br>
         &nbsp;<br>
         Example 1 -- This is how it works in 1.3.14.<br>
         &nbsp;&nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>

</pre>
<pre>
   [root@gateway test]# shorewall start<br>
   ...<br>
   Masqueraded Subnets and Hosts:<br>
       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
   Processing /etc/shorewall/tos...

</pre>
        &nbsp;<br>
         When upgrading to Shorewall 1.3.14, if you have multiple
        local subnets connected to an interface that is specified
        in the SUBNET column of an /etc/shorewall/masq entry, your
        /etc/shorewall/masq file will need changing. In most cases,
        you will simply be able to remove redundant entries. In
        some cases though, you might want to change from using the
        interface name to listing specific subnetworks if the
        change described above will cause masquerading to occur on
        subnetworks that you don't wish to masquerade.<br>
         &nbsp;<br>
         Example 2 -- Suppose that your current config is as
        follows:<br>
         &nbsp;&nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   eth0                    192.168.10.0/24         206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#

</pre>
        &nbsp;<br>
         &nbsp;&nbsp; In this case, the second entry in
        /etc/shorewall/masq is no longer required.<br>
         &nbsp;<br>
         Example 3 -- What if your current configuration is like
        this?<br>
         &nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#

</pre>
        &nbsp;<br>
         &nbsp;&nbsp; In this case, you would want to change the
        entry in&nbsp; /etc/shorewall/masq to:<br>

<pre>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    192.168.1.0/24          206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
      </li>
    </ol>

    <p><br>
     <b>2/5/2003 - Shorewall Support included in Webmin
    1.060</b></p>

    <p>Webmin version 1.060 now has Shorewall support included as
    standard. See <a href=
    "http://www.webmin.com">http://www.webmin.com</a>.<br>
     <b><br>
     2/4/2003 - Shorewall 1.3.14-RC1</b></p>

    <p>Includes the Beta 2 content plus support for OpenVPN
    tunnels.</p>

    <p><b>1/28/2003 - Shorewall 1.3.14-Beta2</b></p>

    <p>Includes the Beta 1 content plus restores VLAN device names
    of the form $dev.$vid (e.g., eth0.1)</p>

    <p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><br>
    </p>

    <p>The Beta includes the following changes:<br>
    </p>

    <ol>
      <li>An OLD_PING_HANDLING option has been added to
      shorewall.conf. When set to Yes, Shorewall ping handling is
      as it has always been (see
      http://www.shorewall.net/ping.html).<br>
      <br>
       When OLD_PING_HANDLING=No, icmp echo (ping) is handled via
      rules and policies just like any other connection request.
      The FORWARDPING=Yes option in shorewall.conf and the 'noping'
      and 'filterping' options in /etc/shorewall/interfaces will
      all generate an error.<br>
      <br>
      </li>

      <li>It is now possible to direct Shorewall to create a
      "label" such as&nbsp; "eth0:0" for IP addresses that it
      creates under ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes.
      This is done by specifying the label instead of just the
      interface name:<br>
       &nbsp;<br>
       &nbsp;&nbsp; a) In the INTERFACE column of
      /etc/shorewall/masq<br>
       &nbsp;&nbsp; b) In the INTERFACE column of
      /etc/shorewall/nat<br>
       &nbsp;</li>

      <li>
        When an interface name is entered in the SUBNET column of
        the /etc/shorewall/masq file, Shorewall previously
        masqueraded traffic from only the first subnet defined on
        that interface. It did not masquerade traffic from:<br>
         &nbsp;<br>
         &nbsp;&nbsp; a) The subnets associated with other
        addresses on the interface.<br>
         &nbsp;&nbsp; b) Subnets accessed through local
        routers.<br>
         &nbsp;<br>
         Beginning with Shorewall 1.3.14, if you enter an interface
        name in the SUBNET column, shorewall will use the
        firewall's routing table to construct the masquerading/SNAT
        rules.<br>
         &nbsp;<br>
         Example 1 -- This is how it works in 1.3.14.<br>
         &nbsp;&nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>

</pre>
<pre>
   [root@gateway test]# shorewall start<br>
   ...<br>
   Masqueraded Subnets and Hosts:<br>
       To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br>
       To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br>
   Processing /etc/shorewall/tos...

</pre>
        &nbsp;<br>
         When upgrading to Shorewall 1.3.14, if you have multiple
        local subnets connected to an interface that is specified
        in the SUBNET column of an /etc/shorewall/masq entry, your
        /etc/shorewall/masq file will need changing. In most cases,
        you will simply be able to remove redundant entries. In
        some cases though, you might want to change from using the
        interface name to listing specific subnetworks if the
        change described above will cause masquerading to occur on
        subnetworks that you don't wish to masquerade.<br>
         &nbsp;<br>
         Example 2 -- Suppose that your current config is as
        follows:<br>
         &nbsp;&nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   eth0                    192.168.10.0/24         206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#

</pre>
        &nbsp;<br>
         &nbsp;&nbsp; In this case, the second entry in
        /etc/shorewall/masq is no longer required.<br>
         &nbsp;<br>
         Example 3 -- What if your current configuration is like
        this?<br>
         &nbsp;<br>

<pre>
   [root@gateway test]# cat /etc/shorewall/masq<br>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    eth2                    206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
<pre>
   [root@gateway test]# ip route show dev eth2<br>
   192.168.1.0/24  scope link<br>
   192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br>
   [root@gateway test]#

</pre>
        &nbsp;<br>
         &nbsp;&nbsp; In this case, you would want to change the
        entry in&nbsp; /etc/shorewall/masq to:<br>

<pre>
   #INTERFACE              SUBNET                  ADDRESS<br>
   eth0                    192.168.1.0/24          206.124.146.176<br>
   #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE

</pre>
      </li>
    </ol>

    <p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF
    Format</b></p>

    <p>Juraj Ontkanin has produced a PDF containing the Shorewall
    1.3.13 documenation. the PDF may be downloaded from</p>
    &nbsp;&nbsp;&nbsp; <a href=
    "ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
    "_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>

     &nbsp;&nbsp;&nbsp; <a href=
    "http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>


    <p><b>1/17/2003 - shorewall.net has MOVED</b><b>&nbsp;</b></p>

    <p>Thanks to the generosity of Alex Martin and <a href=
    "http://www.rettc.com">Rett Consulting</a>, www.shorewall.net
    and ftp.shorewall.net are now hosted on a system in Bellevue,
    Washington. A big thanks to Alex for making this happen.<br>
    </p>

    <p><b>1/13/2003 - Shorewall 1.3.13<br>
    </b></p>

    <p>Just includes a few things that I had on the burner:<br>
    </p>

    <ol>
      <li>A new 'DNAT-' action has been added for entries in the
      /etc/shorewall/rules file. DNAT- is intended for advanced
      users who wish to minimize the number of rules that
      connection requests must traverse.<br>
      <br>
       A Shorewall DNAT rule actually generates two iptables rules:
      a header rewriting rule in the 'nat' table and an ACCEPT rule
      in the 'filter' table. A DNAT- rule only generates the first
      of these rules. This is handy when you have several DNAT
      rules that would generate the same ACCEPT rule.<br>
      <br>
       &nbsp;&nbsp; Here are three rules from my previous rules
      file:<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp;
      net&nbsp; dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT&nbsp;&nbsp;
      net&nbsp; dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
      dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
      <br>
       &nbsp;&nbsp; These three rules ended up generating _three_
      copies of<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT
      net&nbsp; dmz:206.124.146.177 tcp smtp<br>
      <br>
       &nbsp;&nbsp; By writing the rules this way, I end up with
      only one copy of the ACCEPT rule.<br>
      <br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp;
      net&nbsp; dmz:206.124.146.177 tcp smtp -&nbsp;
      206.124.146.178<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DNAT-&nbsp;
      net&nbsp; dmz:206.124.146.177 tcp smtp -&nbsp;
      206.124.146.179<br>
       &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ACCEPT net&nbsp;
      dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
      <br>
      </li>

      <li>The 'shorewall check' command now prints out the
      applicable policy between each pair of zones.<br>
      <br>
      </li>

      <li>A new CLEAR_TC option has been added to shorewall.conf.
      If this option is set to 'No' then Shorewall won't clear the
      current traffic control rules during [re]start. This setting
      is intended for use by people that prefer to configure
      traffic shaping when the network interfaces come up rather
      than when the firewall is started. If that is what you want
      to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply
      an /etc/shorewall/tcstart file. That way, your traffic
      shaping rules can still use the 'fwmark' classifier based on
      packet marking defined in /etc/shorewall/tcrules.<br>
      <br>
      </li>

      <li>A new SHARED_DIR variable has been added that allows
      distribution packagers to easily move the shared directory
      (default /usr/lib/shorewall). Users should never have a need
      to change the value of this shorewall.conf setting.<br>
      </li>
    </ol>

    <p><b>1/6/2003 -
    <big><big><big>BURNOUT</big></big></big></b></p>

    <p><b>Until further notice, I will not be involved in either
    Shorewall Development or Shorewall Support</b></p>

    <p><b>-Tom Eastep</b><br>
    </p>

    <p><b>12/30/2002 - Shorewall Documentation in PDF
    Format</b></p>

    <p>Juraj Ontkanin has produced a PDF containing the Shorewall
    1.3.12 documenation. the PDF may be downloaded from</p>

    <p>&nbsp;&nbsp;&nbsp; <a href=
    "ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
    "_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>

     &nbsp;&nbsp;&nbsp; <a href=
    "http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>

    </p>

    <p><b>12/27/2002 - Shorewall 1.3.12 Released</b></p>

    <p>Features include:<br>
    </p>

    <ol>
      <li>"shorewall refresh" now reloads the traffic shaping rules
      (tcrules and tcstart).</li>

      <li>"shorewall debug [re]start" now turns off debugging after
      an error occurs. This places the point of the failure near
      the end of the trace rather than up in the middle of it.</li>

      <li>"shorewall [re]start" has been speeded up by more than
      40% with my configuration. Your milage may vary.</li>

      <li>A "shorewall show classifiers" command has been added
      which shows the current packet classification filters. The
      output from this command is also added as a separate page in
      "shorewall monitor"</li>

      <li>ULOG (must be all caps) is now accepted as a valid syslog
      level and causes the subject packets to be logged using the
      ULOG target rather than the LOG target. This allows you to
      run ulogd (available from <a href=
      "http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
      and log all Shorewall messages <a href=
      "shorewall_logging.html">to a separate log file</a>.</li>

      <li>If you are running a kernel that has a FORWARD chain in
      the mangle table ("shorewall show mangle" will show you the
      chains in the mangle table), you can set
      MARK_IN_FORWARD_CHAIN=Yes in <a href=
      "Documentation.htm#Conf">shorewall.conf</a>. This allows for
      marking input packets based on their destination even when
      you are using Masquerading or SNAT.</li>

      <li>I have cluttered up the /etc/shorewall directory with
      empty 'init', 'start', 'stop' and 'stopped' files. If you
      already have a file with one of these names, don't worry --
      the upgrade process won't overwrite your file.</li>

      <li>I have added a new RFC1918_LOG_LEVEL variable to <a href=
      "Documentation.htm#Conf">shorewall.conf</a>. This variable
      specifies the syslog level at which packets are logged as a
      result of entries in the /etc/shorewall/rfc1918 file.
      Previously, these packets were always logged at the 'info'
      level.<br>
      </li>
    </ol>

    <p><b>12/20/2002 - Shorewall 1.3.12 Beta 3<br>
    </b></p>
    This version corrects a problem with Blacklist logging. In Beta
    2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the
    firewall would fail to start and "shorewall refresh" would also
    fail.<br>


    <p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b></p>

    <p>The first public Beta version of Shorewall 1.3.12 is now
    available (Beta 1 was made available only to a limited
    audience).<br>
    </p>
    Features include:<br>


    <ol>
      <li>"shorewall refresh" now reloads the traffic shaping rules
      (tcrules and tcstart).</li>

      <li>"shorewall debug [re]start" now turns off debugging after
      an error occurs. This places the point of the failure near
      the end of the trace rather than up in the middle of it.</li>

      <li>"shorewall [re]start" has been speeded up by more than
      40% with my configuration. Your milage may vary.</li>

      <li>A "shorewall show classifiers" command has been added
      which shows the current packet classification filters. The
      output from this command is also added as a separate page in
      "shorewall monitor"</li>

      <li>ULOG (must be all caps) is now accepted as a valid syslog
      level and causes the subject packets to be logged using the
      ULOG target rather than the LOG target. This allows you to
      run ulogd (available from <a href=
      "http://www.netfilter.org/projects/ulogd/index.html">http://www.netfilter.org/projects/ulogd/index.html</a>)
      and log all Shorewall messages <a href=
      "shorewall_logging.html">to a separate log file</a>.</li>

      <li>If you are running a kernel that has a FORWARD chain in
      the mangle table ("shorewall show mangle" will show you the
      chains in the mangle table), you can set
      MARK_IN_FORWARD_CHAIN=Yes in shorewall.conf. This allows for
      marking input packets based on their destination even when
      you are using Masquerading or SNAT.</li>

      <li>I have cluttered up the /etc/shorewall directory with
      empty 'init', 'start', 'stop' and 'stopped' files. If you
      already have a file with one of these names, don't worry --
      the upgrade process won't overwrite your file.</li>
    </ol>
    You may download the Beta from:<br>


    <blockquote>
      <a href=
      "http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>

       <a href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target=
      "_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
    </blockquote>

    <p><b>12/12/2002 - Mandrake Multi Network Firewall <a href=
    "http://www.mandrakesoft.com"><img src="images/logo2.png" alt=
    "Powered by Mandrake Linux" border="0" height="21" width="140">
    </a></b></p>
    Shorewall is at the center of MandrakeSoft's recently-announced
    <a href=
    "http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">
    Multi Network Firewall (MNF)</a> product. Here is the <a href=
    "http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">
    press release</a>.<br>


    <p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b></p>

    <p>Two months and 3 days after I ordered Mandrake 9.0, it was
    finally delivered. I have installed 9.0 on one of my systems
    and I am now in a position to support Shorewall users who run
    Mandrake 9.0.</p>

    <p><b>12/6/2002 - Debian 1.3.11a Packages Available<br>
    </b></p>

    <p>Apt-get sources listed at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

    <p><b>12/3/2002 - Shorewall 1.3.11a</b></p>

    <p>This is a bug-fix roll up which includes Roger Aich's fix
    for DNAT with excluded subnets (e.g., "DNAT foo!bar ...").
    Current 1.3.11 users who don't need rules of this type need not
    upgrade to 1.3.11.</p>

    <p><b>11/24/2002 - Shorewall 1.3.11</b></p>

    <p>In this version:</p>

    <ul>
      <li>A 'tcpflags' option has been added to entries in <a href=
      "Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
      This option causes Shorewall to make a set of sanity check on
      TCP packet header flags.</li>

      <li>It is now allowed to use 'all' in the SOURCE or DEST
      column in a <a href="Documentation.htm#Rules">rule</a>. When
      used, 'all' must appear by itself (in may not be qualified)
      and it does not enable intra-zone traffic. For example, the
      rule<br>
      <br>
       &nbsp; &nbsp; ACCEPT loc all tcp 80<br>
      <br>
       does not enable http traffic from 'loc' to 'loc'.</li>

      <li>Shorewall's use of the 'echo' command is now compatible
      with bash clones such as ash and dash.</li>

      <li>fw-&gt;fw policies now generate a startup error.
      fw-&gt;fw rules generate a warning and are ignored</li>
    </ul>

    <p><b>11/14/2002 - Shorewall Documentation in PDF
    Format</b></p>

    <p>Juraj Ontkanin has produced a PDF containing the Shorewall
    1.3.10 documenation. the PDF may be downloaded from</p>

    <p>&nbsp;&nbsp;&nbsp; <a href=
    "ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target=
    "_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>

     &nbsp;&nbsp;&nbsp; <a href=
    "http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>

    </p>

    <p><b>11/09/2002 - Shorewall is Back at SourceForge</b></p>

    <p>The main Shorewall 1.3 web site is now back at SourceForge
    at <a href="http://shorewall.sf.net" target=
    "_top">http://shorewall.sf.net</a>.<br>
    </p>

    <p><b>11/09/2002 - Shorewall 1.3.10</b></p>

    <p>In this version:</p>

    <ul>
      <li>You may now <a href="IPSEC.htm#Dynamic">define the
      contents of a zone dynamically</a> with the <a href=
      "starting_and_stopping_shorewall.htm">"shorewall add" and
      "shorewall delete" commands</a>. These commands are expected
      to be used primarily within <a href=
      "http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
      scripts.</li>

      <li>Shorewall can now do <a href="MAC_Validation.html">MAC
      verification</a> on ethernet segments. You can specify the
      set of allowed MAC addresses on the segment and you can
      optionally tie each MAC address to one or more IP
      addresses.</li>

      <li>PPTP Servers and Clients running on the firewall system
      may now be defined in the <a href=
      "PPTP.htm">/etc/shorewall/tunnels</a> file.</li>

      <li>A new 'ipsecnat' tunnel type is supported for use when
      the <a href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
      gateway</a>.</li>

      <li>The PATH used by Shorewall may now be specified in <a
      href=
      "Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>

      <li>The main firewall script is now
      /usr/lib/shorewall/firewall. The script in
      /etc/init.d/shorewall is very small and uses /sbin/shorewall
      to do the real work. This change makes custom distributions
      such as for Debian and for Gentoo easier to manage since it
      is /etc/init.d/shorewall that tends to have
      distribution-dependent code</li>
    </ul>

    <p><b>10/24/2002 - Shorewall is now in Gentoo Linux</b> <a
    href="http://www.gentoo.org"><br>
    </a></p>
    Alexandru Hartmann reports that his Shorewall package is now a
    part of <a href="http://www.gentoo.org">the Gentoo Linux
    distribution</a>. Thanks Alex!<br>


    <p><b>10/23/2002 - Shorewall 1.3.10 Beta 1</b></p>
    In this version:<br>


    <ul>
      <li>You may now <a href="IPSEC.htm#Dynamic">define the
      contents of a zone dynamically</a> with the <a href=
      "starting_and_stopping_shorewall.htm">"shorewall add" and
      "shorewall delete" commands</a>. These commands are expected
      to be used primarily within <a href=
      "http://www.xs4all.nl/%7Efreeswan/">FreeS/Wan</a> updown
      scripts.</li>

      <li>Shorewall can now do <a href="MAC_Validation.html">MAC
      verification</a> on ethernet segments. You can specify the
      set of allowed MAC addresses on the segment and you can
      optionally tie each MAC address to one or more IP
      addresses.</li>

      <li>PPTP Servers and Clients running on the firewall system
      may now be defined in the <a href=
      "PPTP.htm">/etc/shorewall/tunnels</a> file.</li>

      <li>A new 'ipsecnat' tunnel type is supported for use when
      the <a href="IPSEC.htm">remote IPSEC endpoint is behind a NAT
      gateway</a>.</li>

      <li>The PATH used by Shorewall may now be specified in <a
      href=
      "Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>

      <li>The main firewall script is now
      /usr/lib/shorewall/firewall. The script in
      /etc/init.d/shorewall is very small and uses /sbin/shorewall
      to do the real work. This change makes custom distributions
      such as for Debian and for Gentoo easier to manage since it
      is /etc/init.d/shorewall that tends to have
      distribution-dependent code.</li>
    </ul>
    You may download the Beta from:<br>


    <ul>
      <li><a href=
      "http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a></li>

      <li><a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
      target=
      "_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a></li>
    </ul>

    <p><b>10/10/2002 - &nbsp;Debian 1.3.9b Packages Available<br>
    </b></p>

    <p>Apt-get sources listed at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

    <p><b>10/9/2002 - Shorewall 1.3.9b</b></p>
    This release rolls up fixes to the installer and to the
    firewall script.<br>


    <p><b>10/6/2002 - Shorewall.net now running on RH8.0<br>
    </b><br>
     The firewall and server here at shorewall.net are now running
    RedHat release 8.0.<br>
     <b><br>
     9/30/2002 - Shorewall 1.3.9a</b></p>
    Roles up the fix for broken tunnels.<br>


    <p><b>9/30/2002 - TUNNELS Broken in 1.3.9!!!</b></p>
    There is an updated firewall script at <a href=
    "ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
    target=
    "_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
    -- copy that file to /usr/lib/shorewall/firewall.<br>


    <p><b>9/28/2002 - Shorewall 1.3.9</b></p>

    <p>In this version:<br>
    </p>

    <ul>
      <li><a href="configuration_file_basics.htm#dnsnames">DNS
      Names</a> are now allowed in Shorewall config files (although
      I recommend against using them).</li>

      <li>The connection SOURCE may now be qualified by both
      interface and IP address in a <a href=
      "Documentation.htm#Rules">Shorewall rule</a>.</li>

      <li>Shorewall startup is now disabled after initial
      installation until the file /etc/shorewall/startup_disabled
      is removed. This avoids nasty surprises during reboot for
      users who install Shorewall but don't configure it.</li>

      <li>The 'functions' and 'version' files and the 'firewall'
      symbolic link have been moved from /var/lib/shorewall to
      /usr/lib/shorewall to appease the LFS police at Debian.<br>
      </li>
    </ul>

    <p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive
    Search Capability Restored</b><br>
    </p>
    <img src="images/j0233056.gif" alt="Brown Paper Bag" align=
    "left" height="86" width="50"> A couple of recent configuration
    changes at www.shorewall.net broke the Search facility:<br>


    <blockquote>
      <ol>
        <li>Mailing List Archive Search was not available.</li>

        <li>The Site Search index was incomplete</li>

        <li>Only one page of matches was presented.</li>
      </ol>
    </blockquote>
    Hopefully these problems are now corrected.

    <p><b>9/23/2002 - Full Shorewall Site/Mailing List Archive
    Search Capability Restored<br>
    </b></p>
    A couple of recent configuration changes at www.shorewall.net
    had the negative effect of breaking the Search facility:<br>


    <ol>
      <li>Mailing List Archive Search was not available.</li>

      <li>The Site Search index was incomplete</li>

      <li>Only one page of matches was presented.</li>
    </ol>
    Hopefully these problems are now corrected.<br>


    <p><b>9/18/2002 - &nbsp;Debian 1.3.8 Packages Available<br>
    </b></p>

    <p>Apt-get sources listed at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>

    <p><b>9/16/2002 - Shorewall 1.3.8</b></p>

    <p>In this version:<br>
    </p>

    <ul>
      <li>A <a href="Documentation.htm#Conf">NEWNOTSYN</a> option
      has been added to shorewall.conf. This option determines
      whether Shorewall accepts TCP packets which are not part of
      an established connection and that are not 'SYN' packets (SYN
      flag on and ACK flag off).</li>

      <li>The need for the 'multi' option to communicate between
      zones za and zb on the same interface is removed in the case
      where the chain 'za2zb' and/or 'zb2za' exists. 'za2zb' will
      exist if:</li>

      <li style=
      "list-style-type: none; list-style-position: outside; list-style-image: none;">
        <ul>
          <li>There is a policy for za to zb; or</li>

          <li>There is at least one rule for za to zb.</li>
        </ul>
      </li>
    </ul>

    <ul>
      <li>The /etc/shorewall/blacklist file now contains three
      columns. In addition to the SUBNET/ADDRESS column, there are
      optional PROTOCOL and PORT columns to block only certain
      applications from the blacklisted addresses.<br>
      </li>
    </ul>

    <p><b>9/11/2002 - Debian 1.3.7c Packages Available</b></p>

    <p>Apt-get sources listed at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>9/2/2002 - Shorewall 1.3.7c</b></p>

    <p>This is a role up of a fix for "DNAT" rules where the source
    zone is $FW (fw).</p>

    <p><b>8/31/2002 - I'm not available</b></p>

    <p>I'm currently on vacation&nbsp; -- please respect my need
    for a couple of weeks free of Shorewall problem reports.</p>

    <p>-Tom</p>

    <p><b>8/26/2002 - Shorewall 1.3.7b</b></p>

    <p>This is a role up of the "shorewall refresh" bug fix and the
    change which reverses the order of "dhcp" and "norfc1918"
    checking.</p>

    <p><b>8/26/2002 - French FTP Mirror is Operational</b></p>

    <p><a target="_blank" href=
    "ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall</a>
    is now available.</p>

    <p><b>8/25/2002 - Shorewall Mirror in France</b></p>

    <p>Thanks to a Shorewall user in Paris, the Shorewall web site
    is now mirrored at <a target="_top" href=
    "http://france.shorewall.net">http://france.shorewall.net</a>.</p>

    <p><b>8/25/2002 - Shorewall 1.3.7a Debian Packages
    Available</b></p>

    <p>Lorenzo Martignoni reports that the packages for version
    1.3.7a are available at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award
    for its Author -- Shorewall 1.3.7a released<img src=
    "images/j0233056.gif" alt="Brown Paper Bag Graphic" align=
    "middle" border="0" height="80" width="50"></b></p>

    <p>1.3.7a corrects problems occurring in rules file processing
    when starting Shorewall 1.3.7.</p>

    <p><b>8/22/2002 - Shorewall 1.3.7 Released 8/13/2002</b></p>

    <p>Features in this release include:</p>

    <ul>
      <li>The 'icmp.def' file is now empty! The rules in that file
      were required in ipchains firewalls but are not required in
      Shorewall. Users who have ALLOWRELATED=No in <a href=
      "Documentation.htm#Conf">shorewall.conf</a> should see the <a
      href="errata.htm#Upgrade">Upgrade Issues</a>.</li>

      <li>A 'FORWARDPING' option has been added to <a href=
      "Documentation.htm#Conf">shorewall.conf</a>. The effect of
      setting this variable to Yes is the same as the effect of
      adding an ACCEPT rule for ICMP echo-request in <a href=
      "shorewall_extension_scripts.htm">/etc/shorewall/icmpdef</a>.
      Users who have such a rule in icmpdef are encouraged to
      switch to FORWARDPING=Yes.</li>

      <li>The loopback CLASS A Network (127.0.0.0/8) has been added
      to the rfc1918 file.</li>

      <li>Shorewall now works with iptables 1.2.7</li>

      <li>The documentation and web site no longer uses FrontPage
      themes.</li>
    </ul>

    <p>I would like to thank John Distler for his valuable input
    regarding TCP SYN and ICMP treatment in Shorewall. That input
    has led to marked improvement in Shorewall in the last two
    releases.</p>

    <p><b>8/13/2002 - Documentation in the <a target="_top" href=
    "http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
    Repository</a></b></p>

    <p>The Shorewall-docs project now contains just the HTML and
    image files - the Frontpage files have been removed.</p>

    <p><b>8/7/2002 - <i>STABLE</i></b> <b>branch added to <a
    target="_top" href=
    "http://www.shorewall.net/cgi-bin/cvs/cvsweb.cgi">CVS
    Repository</a></b></p>

    <p>This branch will only be updated after I release a new
    version of Shorewall so you can always update from this branch
    to get the latest stable tree.</p>

    <p><b>8/7/2002 - <a href="errata.htm#Upgrade">Upgrade
    Issues</a> section added to the <a href="errata.htm">Errata
    Page</a></b></p>

    <p>Now there is one place to go to look for issues involved
    with upgrading to recent versions of Shorewall.</p>

    <p><b>8/7/2002 - Shorewall 1.3.6</b></p>

    <p>This is primarily a bug-fix rollup with a couple of new
    features:</p>

    <ul>
      <li>The latest <a href=
      "shorewall_quickstart_guide.htm">QuickStart Guides</a>
      including the <a href="shorewall_setup_guide.htm">Shorewall
      Setup Guide.</a></li>

      <li>Shorewall will now DROP TCP packets that are not part of
      or related to an existing connection and that are not SYN
      packets. These "New not SYN" packets may be optionally logged
      by setting the LOGNEWNOTSYN option in <a href=
      "Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>

      <li>The processing of "New not SYN" packets may be extended
      by commands in the new <a href=
      "shorewall_extension_scripts.htm">newnotsyn extension
      script</a>.</li>
    </ul>

    <p><b>7/30/2002 - Shorewall 1.3.5b Released</b></p>

    <p>This interim release:</p>

    <ul>
      <li>Causes the firewall script to remove the lock file if it
      is killed.</li>

      <li>Once again allows lists in the second column of the <a
      href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
      file.</li>

      <li>Includes the latest <a href=
      "shorewall_quickstart_guide.htm">QuickStart Guides</a>.</li>
    </ul>

    <p><b>7/29/2002 - New Shorewall Setup Guide Available</b></p>

    <p>The first draft of this guide is available at <a href=
    "http://www.shorewall.net/shorewall_setup_guide.htm">http://www.shorewall.net/shorewall_setup_guide.htm</a>.
    The guide is intended for use by people who are setting up
    Shorewall to manage multiple public IP addresses and by people
    who want to learn more about Shorewall than is described in the
    single-address guides. Feedback on the new guide is
    welcome.</p>

    <p><b>7/28/2002 - Shorewall 1.3.5 Debian Package
    Available</b></p>

    <p>Lorenzo Martignoni reports that the packages are version
    1.3.5a and are available at <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>7/27/2002 - Shorewall 1.3.5a Released</b></p>

    <p>This interim release restores correct handling of REDIRECT
    rules.</p>

    <p><b>7/26/2002 - Shorewall 1.3.5 Released</b></p>

    <p>This will be the last Shorewall release for a while. I'm
    going to be focusing on rewriting a lot of the
    documentation.</p>

    <p><b>&nbsp;</b> In this version:</p>

    <ul>
      <li>Empty and invalid source and destination qualifiers are
      now detected in the rules file. It is a good idea to use the
      'shorewall check' command before you issue a 'shorewall
      restart' command be be sure that you don't have any
      configuration problems that will prevent a successful
      restart.</li>

      <li>Added <b>MERGE_HOSTS</b> variable in <a href=
      "Documentation.htm#Conf">shorewall.conf</a> to provide saner
      behavior of the /etc/shorewall/hosts file.</li>

      <li>The time that the counters were last reset is now
      displayed in the heading of the 'status' and 'show'
      commands.</li>

      <li>A <b>proxyarp</b> option has been added for entries in <a
      href=
      "Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
      This option facilitates Proxy ARP sub-netting as described in
      the Proxy ARP subnetting mini-HOWTO (<a href=
      "http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>).
      Specifying the proxyarp option for an interface causes
      Shorewall to set
      /proc/sys/net/ipv4/conf/&lt;interface&gt;/proxy_arp.</li>

      <li>The Samples have been updated to reflect the new
      capabilities in this release.</li>
    </ul>

    <p><b>7/16/2002 - New Mirror in Argentina</b></p>

    <p>Thanks to Arturo "Buanzo" Busleiman, there is now a
    Shorewall mirror in Argentina. Thanks Buanzo!!!</p>

    <p><b>7/16/2002 - Shorewall 1.3.4 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>A new <a href=
      "Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>
      file has been added. This file is intended to eventually
      replace the <b>routestopped</b> option in the
      /etc/shorewall/interface and /etc/shorewall/hosts files. This
      new file makes remote firewall administration easier by
      allowing any IP or subnet to be enabled while Shorewall is
      stopped.</li>

      <li>An /etc/shorewall/stopped <a href=
      "Documentation.htm#Scripts">extension script</a> has been
      added. This script is invoked after Shorewall has
      stopped.</li>

      <li>A <b>DETECT_DNAT_ADDRS</b> option has been added to <a
      href=
      "Documentation.htm#Conf">/etc/shoreall/shorewall.conf</a>.
      When this option is selected, DNAT rules only apply when the
      destination address is the external interface's primary IP
      address.</li>

      <li>The <a href="shorewall_quickstart_guide.htm">QuickStart
      Guide</a> has been broken into three guides and has been
      almost entirely rewritten.</li>

      <li>The Samples have been updated to reflect the new
      capabilities in this release.</li>
    </ul>

    <p><b>7/8/2002 - Shorewall 1.3.3 Debian Package
    Available</b></p>

    <p>Lorenzo Marignoni reports that the packages are available at
    <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>7/6/2002 - Shorewall 1.3.3 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>Entries in /etc/shorewall/interface that use the wildcard
      character ("+") now have the "multi" option assumed.</li>

      <li>The 'rfc1918' chain in the mangle table has been renamed
      'man1918' to make log messages generated from that chain
      distinguishable from those generated by the 'rfc1918' chain
      in the filter table.</li>

      <li>Interface names appearing in the hosts file are now
      validated against the interfaces file.</li>

      <li>The TARGET column in the rfc1918 file is now checked for
      correctness.</li>

      <li>The chain structure in the nat table has been changed to
      reduce the number of rules that a packet must traverse and to
      correct problems with NAT_BEFORE_RULES=No</li>

      <li>The "hits" command has been enhanced.</li>
    </ul>

    <p><b>6/25/2002 - Samples Updated for 1.3.2</b></p>

    <p>The comments in the sample configuration files have been
    updated to reflect new features introduced in Shorewall
    1.3.2.</p>

    <p><b>6/25/2002 - Shorewall 1.3.1 Debian Package
    Available</b></p>

    <p>Lorenzo Marignoni reports that the package is available at
    <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>6/19/2002 - Documentation Available in PDF Format</b></p>

    <p>Thanks to Mike Martinez, the Shorewall Documentation is now
    available for <a href="download.htm">download</a> in <a href=
    "http://www.adobe.com">Adobe</a> PDF format.</p>

    <p><b>6/16/2002 - Shorewall 1.3.2 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>A <a href="Documentation.htm#Starting">logwatch
      command</a> has been added to /sbin/shorewall.</li>

      <li>A <a href="blacklisting_support.htm">dynamic blacklist
      facility</a> has been added.</li>

      <li>Support for the <a href=
      "Documentation.htm#Conf">Netfilter multiport match
      function</a> has been added.</li>

      <li>The files <b>firewall, functions</b> and <b>version</b>
      have been moved from /etc/shorewall to
      /var/lib/shorewall.</li>
    </ul>

    <p><b>6/6/2002 - Why CVS Web access is Password
    Protected</b></p>

    <p>Last weekend, I installed the CVS Web package to provide
    brower-based access to the Shorewall CVS repository. Since
    then, I have had several instances where my server was almost
    unusable due to the high load generated by website copying
    tools like HTTrack and WebStripper. These mindless tools:</p>

    <ul>
      <li>Ignore robot.txt files.</li>

      <li>Recursively copy everything that they find.</li>

      <li>Should be classified as weapons rather than tools.</li>
    </ul>

    <p>These tools/weapons are particularly damaging when combined
    with CVS Web because they doggedly follow every link in the
    cgi-generated HTML resulting in 1000s of executions of the
    cvsweb.cgi script. Yesterday, I spend several hours
    implementing measures to block these tools but unfortunately,
    these measures resulted in my server OOM-ing under even
    moderate load.</p>

    <p>Until I have the time to understand the cause of the OOM (or
    until I buy more RAM if that is what is required), CVS Web
    access will remain Password Protected.</p>

    <p><b>6/5/2002 - Shorewall 1.3.1 Debian Package
    Available</b></p>

    <p>Lorenzo Marignoni reports that the package is available at
    <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</p>

    <p><b>6/2/2002 - Samples Corrected</b></p>

    <p>The 1.3.0 samples configurations had several serious
    problems that prevented DNS and SSH from working properly.
    These problems have been corrected in the <a href=
    "/pub/shorewall/samples-1.3.1">1.3.1 samples.</a></p>

    <p><b>6/1/2002 - Shorewall 1.3.1 Released</b></p>

    <p>Hot on the heels of 1.3.0, this release:</p>

    <ul>
      <li>Corrects a serious problem with "all <i>&lt;zone&gt;</i>
      CONTINUE" policies. This problem is present in all versions
      of Shorewall that support the CONTINUE policy. These previous
      versions optimized away the "all2<i>&lt;zone&gt;</i>" chain
      and replaced it with the "all2all" chain with the usual
      result that a policy of REJECT was enforced rather than the
      intended CONTINUE policy.</li>

      <li>Adds an <a href=
      "Documentation.htm#rfc1918">/etc/shorewall/rfc1918</a> file
      for defining the exact behavior of the <a href=
      "Documentation.htm#Interfaces">'norfc1918' interface
      option</a>.</li>
    </ul>

    <p><b>5/29/2002 - Shorewall 1.3.0 Released</b></p>

    <p>In addition to the changes in Beta 1, Beta 2 and RC1,
    Shorewall 1.3.0 includes:</p>

    <ul>
      <li>A 'filterping' interface option that allows ICMP
      echo-request (ping) requests addressed to the firewall to be
      handled by entries in /etc/shorewall/rules and
      /etc/shorewall/policy.</li>
    </ul>

    <p><b>5/23/2002 - Shorewall 1.3 RC1 Available</b></p>

    <p>In addition to the changes in Beta 1 and Beta 2, RC1
    (Version 1.2.92) incorporates the following:</p>

    <ul>
      <li>Support for the /etc/shorewall/whitelist file has been
      withdrawn. If you need whitelisting, see <a href=
      "/1.3/whitelisting_under_shorewall.htm">these
      instructions</a>.</li>
    </ul>

    <p><b>5/19/2002 - Shorewall 1.3 Beta 2 Available</b></p>

    <p>In addition to the changes in Beta 1, this release which
    carries the designation 1.2.91 adds:</p>

    <ul>
      <li>The structure of the firewall is changed markedly. There
      is now an INPUT and a FORWARD chain for each interface; this
      reduces the number of rules that a packet must traverse,
      especially in complicated setups.</li>

      <li><a href="Documentation.htm#Exclude">Sub-zones may now be
      excluded from DNAT and REDIRECT rules.</a></li>

      <li>The names of the columns in a number of the configuration
      files have been changed to be more consistent and
      self-explanatory and the documentation has been updated
      accordingly.</li>

      <li>The sample configurations have been updated for 1.3.</li>
    </ul>

    <p><b>5/17/2002 - Shorewall 1.3 Beta 1 Available</b></p>

    <p>Beta 1 carries the version designation 1.2.90 and implements
    the following features:</p>

    <ul>
      <li>Simplified rule syntax which makes the intent of each
      rule clearer and hopefully makes Shorewall easier to
      learn.</li>

      <li>Upward compatibility with 1.2 configuration files has
      been maintained so that current users can migrate to the new
      syntax at their convenience.</li>

      <li><b><font color="#CC6666">WARNING:&nbsp; Compatibility
      with the old parameterized sample configurations has NOT been
      maintained. Users still running those configurations should
      migrate to the new sample configurations before upgrading to
      1.3 Beta 1.</font></b></li>
    </ul>

    <p><b>5/4/2002 - Shorewall 1.2.13 is Available</b></p>

    <p>In this version:</p>

    <ul>
      <li><a href="Documentation.htm#Whitelist">White-listing</a>
      is supported.</li>

      <li><a href="Documentation.htm#Policy">SYN-flood
      protection</a> is added.</li>

      <li>IP addresses added under <a href=
      "Documentation.htm#Conf">ADD_IP_ALIASES and
      ADD_SNAT_ALIASES</a> now inherit the VLSM and Broadcast
      Address of the interface's primary IP address.</li>

      <li>The order in which port forwarding DNAT and Static DNAT
      <a href="Documentation.htm#Conf">can now be reversed</a> so
      that port forwarding rules can override the contents of <a
      href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</li>
    </ul>

    <p><b>4/30/2002 - Shorewall Debian News</b></p>

    <p>Lorenzo Marignoni reports that Shorewall 1.2.12 is now in
    both the <a href=
    "http://packages.debian.org/testing/net/shorewall.html">Debian
    Testing Branch</a> and the <a href=
    "http://packages.debian.org/unstable/net/shorewall.html">Debian
    Unstable Branch</a>.</p>

    <p><b>4/20/2002 - Shorewall 1.2.12 is Available</b></p>

    <ul>
      <li>The 'try' command works again</li>

      <li>There is now a single RPM that also works with SUSE.</li>
    </ul>

    <p><b>4/17/2002 - Shorewall Debian News</b></p>

    <p>Lorenzo Marignoni reports that:</p>

    <ul>
      <li>Shorewall 1.2.10 is in the <a href=
      "http://packages.debian.org/testing/net/shorewall.html">Debian
      Testing Branch</a></li>

      <li>Shorewall 1.2.11 is in the <a href=
      "http://packages.debian.org/unstable/net/shorewall.html">Debian
      Unstable Branch</a></li>
    </ul>

    <p>Thanks, Lorenzo!</p>

    <p><b>4/16/2002 - Shorewall 1.2.11 RPM Available for
    SUSE</b></p>

    <p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
    Mohr</a>, there is now a Shorewall 1.2.11 <a href=
    "http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm">
    SUSE RPM</a> available.</p>

    <p><b>4/13/2002 - Shorewall 1.2.11 Available</b></p>

    <p>In this version:</p>

    <ul>
      <li>The 'try' command now accepts an optional timeout. If the
      timeout is given in the command, the standard configuration
      will automatically be restarted after the new configuration
      has been running for that length of time. This prevents a
      remote admin from being locked out of the firewall in the
      case where the new configuration starts but prevents
      access.</li>

      <li>Kernel route filtering may now be enabled globally using
      the new ROUTE_FILTER parameter in <a href=
      "Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>

      <li>Individual IP source addresses and/or subnets may now be
      excluded from masquerading/SNAT.</li>

      <li>Simple "Yes/No" and "On/Off" values are now
      case-insensitive in /etc/shorewall/shorewall.conf.</li>
    </ul>

    <p><b>4/13/2002 - Hamburg Mirror now has FTP</b></p>

    <p>Stefan now has an FTP mirror at <a target="_blank" href=
    "ftp://germany.shorewall.net/pub/shorewall">ftp://germany.shorewall.net/pub/shorewall</a>.&nbsp;
    Thanks Stefan!</p>

    <p><b>4/12/2002 - New Mirror in Hamburg</b></p>

    <p>Thanks to <a href="mailto:s.mohr@familie-mohr.com">Stefan
    Mohr</a>, there is now a mirror of the Shorewall website at <a
    target="_top" href=
    "http://germany.shorewall.net">http://germany.shorewall.net</a>.</p>

    <p><b>4/10/2002 - Shorewall QuickStart Guide Version 1.1
    Available</b></p>

    <p><a href="shorewall_quickstart_guide.htm">Version 1.1 of the
    QuickStart Guide</a> is now available. Thanks to those who have
    read version 1.0 and offered their suggestions. Corrections
    have also been made to the sample scripts.</p>

    <p><b>4/9/2002 - Shorewall QuickStart Guide Version 1.0
    Available</b></p>

    <p><a href="shorewall_quickstart_guide.htm">Version 1.0 of the
    QuickStart Guide</a> is now available. This Guide and its
    accompanying sample configurations are expected to provide a
    replacement for the recently withdrawn parameterized
    samples.</p>

    <p><b>4/8/2002 - Parameterized Samples Withdrawn</b></p>

    <p>Although the <a href=
    "http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized
    samples</a> have allowed people to get a firewall up and
    running quickly, they have unfortunately set the wrong level of
    expectation among those who have used them. I am therefore
    withdrawing support for the samples and I am recommending that
    they not be used in new Shorewall installations.</p>

    <p><b>4/2/2002 - Updated Log Parser</b></p>

    <p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has
    provided an updated version of his <a href=
    "pub/shorewall/parsefw/">CGI-based log parser</a> with
    corrected date handling.</p>

    <p><b>3/30/2002 - Shorewall Website Search Improvements</b></p>

    <p>The quick search on the home page now excludes the mailing
    list archives. The <a href="htdig/search.html">Extended
    Search</a> allows excluding the archives or restricting the
    search to just the archives. An archive search form is also
    available on the <a href=
    "http://lists.shorewall.net/mailing_list.htm">mailing list
    information page</a>.</p>

    <p><b>3/28/2002 - Debian Shorewall News (From Lorenzo
    Martignoni)</b></p>

    <ul>
      <li>The 1.2.10 Debian Package is available at <a href=
      "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>

      <li>Shorewall 1.2.9 is now in the <a href=
      "http://packages.debian.org/unstable/net/shorewall.html">Debian
      Unstable Distribution</a>.</li>
    </ul>

    <p><b>3/25/2002 - Log Parser Available</b></p>

    <p><a href="mailto:JML@redwoodtech.com">John Lodge</a> has
    provided a <a href="pub/shorewall/parsefw/">CGI-based log
    parser</a> for Shorewall. Thanks John.</p>

    <p><b>3/20/2002 - Shorewall 1.2.10 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>A "shorewall try" command has been added (syntax:
      shorewall try <i>&lt;configuration directory&gt;</i>). This
      command attempts "shorewall -c <i>&lt;configuration
      directory&gt;</i> start" and if that results in the firewall
      being stopped due to an error, a "shorewall start" command is
      executed. The 'try' command allows you to create a new <a
      href="Documentation.htm#Configs">configuration</a> and
      attempt to start it; if there is an error that leaves your
      firewall in the stopped state, it will automatically be
      restarted using the default configuration (in
      /etc/shorewall).</li>

      <li>A new variable ADD_SNAT_ALIASES has been added to <a
      href=
      "Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.
      If this variable is set to "Yes", Shorewall will
      automatically add IP addresses listed in the third column of
      the <a href="Documentation.htm#Masq">/etc/shorewall/masq</a>
      file.</li>

      <li>Copyright notices have been added to the
      documenation.</li>
    </ul>

    <p><b>3/11/2002 - Shorewall 1.2.9 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>
        Filtering by <a href="Documentation.htm#MAC">MAC
        address</a> has been added. MAC addresses may be used as
        the source address in:

        <ul>
          <li>Filtering rules (<a href=
          "Documentation.htm#Rules">/etc/shorewall/rules</a>)</li>

          <li>Traffic Control Classification Rules (<a href=
          "traffic_shaping.htm#tcrules">/etc/shorewall/tcrules</a>)</li>

          <li>TOS Rules (<a href=
          "Documentation.htm#TOS">/etc/shorewall/tos</a>)</li>

          <li>Blacklist (<a href=
          "Documentation.htm#Blacklist">/etc/shorewall/blacklist</a>)</li>
        </ul>
      </li>

      <li>Several bugs have been fixed</li>

      <li>The 1.2.9 Debian Package is also available at <a href=
      "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a>.</li>
    </ul>

    <p><b>3/1/2002 - 1.2.8 Debian Package is Available</b></p>

    <p>See <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

    <p><b>2/25/2002 - New Two-interface Sample</b></p>

    <p>I've enhanced the two interface sample to allow access from
    the firewall to servers in the local zone - <a href=
    "http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz">
    http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz</a></p>

    <p><b>2/23/2002 - Shorewall 1.2.8 Released</b></p>

    <p>Do to a serious problem with 1.2.7, I am releasing 1.2.8. It
    corrects problems associated with the lock file used to prevent
    multiple state-changing operations from occuring
    simultaneously. My apologies for any inconvenience my
    carelessness may have caused.</p>

    <p><b>2/22/2002 - Shorewall 1.2.7 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>UPnP probes (UDP destination port 1900) are now silently
      dropped in the <i>common</i> chain</li>

      <li>RFC 1918 checking in the mangle table has been
      streamlined to no longer require packet marking. RFC 1918
      checking in the filter table has been changed to require half
      as many rules as previously.</li>

      <li>A 'shorewall check' command has been added that does a
      cursory validation of the zones, interfaces, hosts, rules and
      policy files.</li>
    </ul>

    <p><b>2/18/2002 - 1.2.6 Debian Package is Available</b></p>

    <p>See <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

    <p><b>2/8/2002 - Shorewall 1.2.6 Released</b></p>

    <p>In this version:</p>

    <ul>
      <li>$-variables may now be used anywhere in the configuration
      files except /etc/shorewall/zones.</li>

      <li>The interfaces and hosts files now have their contents
      validated before any changes are made to the existing
      Netfilter configuration. The appearance of a zone name that
      isn't defined in /etc/shorewall/zones causes "shorewall
      start" and "shorewall restart" to abort without changing the
      Shorewall state. Unknown options in either file cause a
      warning to be issued.</li>

      <li>A problem occurring when BLACKLIST_LOGLEVEL was not set
      has been corrected.</li>
    </ul>

    <p><b>2/4/2002 - Shorewall 1.2.5 Debian Package
    Available</b></p>

    <p>see <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

    <p><b>2/1/2002 - Shorewall 1.2.5 Released</b></p>

    <p>Due to installation problems with Shorewall 1.2.4, I have
    released Shorewall 1.2.5. Sorry for the rapid-fire
    development.</p>

    <p>In version 1.2.5:</p>

    <ul>
      <li>The installation problems have been corrected.</li>

      <li><a href="Documentation.htm#Masq">SNAT</a> is now
      supported.</li>

      <li>A "shorewall version" command has been added</li>

      <li>The default value of the STATEDIR variable in
      /etc/shorewall/shorewall.conf has been changed to
      /var/lib/shorewall in order to conform to the GNU/Linux File
      Hierarchy Standard, Version 2.2.</li>
    </ul>

    <p><b>1/28/2002 - Shorewall 1.2.4 Released</b></p>

    <ul>
      <li>The "fw" zone <a href="Documentation.htm#FW">may now be
      given a different name</a>.</li>

      <li>You may now place end-of-line comments (preceded by '#')
      in any of the configuration files</li>

      <li>There is now protection against against two state
      changing operations occuring concurrently. This is
      implemented using the 'lockfile' utility if it is available
      (lockfile is part of procmail); otherwise, a less robust
      technique is used. The lockfile is created in the STATEDIR
      defined in /etc/shorewall/shorewall.conf and has the name
      "lock".</li>

      <li>"shorewall start" no longer fails if "detect" is
      specified in <a href=
      "Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
      for an interface with subnet mask 255.255.255.255.</li>
    </ul>

    <p><b>1/27/2002 - Shorewall 1.2.3 Debian Package Available</b>
    -- see <a href=
    "http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html</a></p>

    <p><b>1/20/2002 - Corrected firewall script
    available&nbsp;</b></p>

    <p>Corrects a problem with BLACKLIST_LOGLEVEL. See <a href=
    "errata.htm">the errata</a> for details.</p>

    <p><b>1/19/2002 - Shorewall 1.2.3 Released</b></p>

    <p>This is a minor feature and bugfix release. The single new
    feature is:</p>

    <ul>
      <li>Support for TCP MSS Clamp to PMTU -- This support is
      usually required when the internet connection is via PPPoE or
      PPTP and may be enabled using the <a href=
      "Documentation.htm#ClampMSS">CLAMPMSS</a> option in
      /etc/shorewall/shorewall.conf.</li>
    </ul>

    <p>The following problems were corrected:</p>

    <ul>
      <li>The "shorewall status" command no longer hangs.</li>

      <li>The "shorewall monitor" command now displays the icmpdef
      chain</li>

      <li>The CLIENT PORT(S) column in tcrules is no longer
      ignored</li>
    </ul>

    <p><b>1/18/2002 - Shorewall 1.2.2 packaged with new</b> <a
    href="http://leaf.sourceforge.net">LEAF</a> <b>release</b></p>

    <p>Jacques Nilo and Eric Wolzak have released a kernel 2.4.16
    LEAF distribution that includes Shorewall 1.2.2. See <a href=
    "http://leaf.sourceforge.net/devel/jnilo">http://leaf.sourceforge.net/devel/jnilo</a>
    for details.</p>

    <p><b>1/11/2002 - Debian Package (.deb) Now Available -</b>
    Thanks to <a href="mailto:lorenzo.martignoni@milug.org">Lorenzo
    Martignoni</a>, a 1.2.2 Shorewall Debian package is now
    available. There is a link to Lorenzo's site from the <a href=
    "download.htm">Shorewall download page</a>.</p>

    <p><b>1/9/2002 - Updated 1.2.2 /sbin/shorewall available -</b>
    <a href="/pub/shorewall/errata/1.2.2/shorewall">This corrected
    version</a> restores the "shorewall status" command to
    health.</p>

    <p><b>1/8/2002 - Shorewall 1.2.2 Released</b></p>

    <p>In version 1.2.2</p>

    <ul>
      <li>
        Support for IP blacklisting has been added

        <ul>
          <li>You specify whether you want packets from blacklisted
          hosts dropped or rejected using the <a href=
          "Documentation.htm#BLDisposition">BLACKLIST_DISPOSITION</a>
          setting in /etc/shorewall/shorewall.conf</li>

          <li>You specify whether you want packets from blacklisted
          hosts logged and at what syslog level using the <a href=
          "Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a>
          setting in /etc/shorewall/shorewall.conf</li>

          <li>You list the IP addresses/subnets that you wish to
          blacklist in <a href=
          "Documentation.htm#Blacklist">/etc/shorewall/blacklist</a></li>

          <li>You specify the interfaces you want checked against
          the blacklist using the new "<a href=
          "Documentation.htm#BLInterface">blacklist</a>" option in
          /etc/shorewall/interfaces.</li>

          <li>The black list is refreshed from
          /etc/shorewall/blacklist by the "shorewall refresh"
          command.</li>
        </ul>
      </li>

      <li>
        Use of TCP RST replies has been expanded&nbsp;

        <ul>
          <li>TCP connection requests rejected because of a REJECT
          policy are now replied with a TCP RST packet.</li>

          <li>TCP connection requests rejected because of a
          protocol=all rule in /etc/shorewall/rules are now replied
          with a TCP RST packet.</li>
        </ul>
      </li>

      <li>A <a href="Documentation.htm#Logfile">LOGFILE</a>
      specification has been added to
      /etc/shorewall/shorewall.conf. LOGFILE is used to tell the
      /sbin/shorewall program where to look for Shorewall
      messages.</li>
    </ul>

    <p><b>1/5/2002 - New Parameterized Samples (<a href=
    "ftp://ftp.shorewall.net/pub/shorewall/samples-1.2.0/" target=
    "_blank">version 1.2.0</a>) released.</b> These are minor
    updates to the previously-released samples. There are two new
    rules added:</p>

    <ul>
      <li>Unless you have explicitly enabled Auth connections (tcp
      port 113) to your firewall, these connections will be
      REJECTED rather than DROPPED. This speeds up connection
      establishment to some servers.</li>

      <li>Orphan DNS replies are now silently dropped.</li>
    </ul>

    <p>See the README file for upgrade instructions.</p>

    <p><b>1/1/2002 - <u><font color="#FF6633">Shorewall Mailing
    List Moving</font></u></b></p>

    <p>The Shorewall mailing list hosted at <a href=
    "http://sourceforge.net">Sourceforge</a> is moving to
    Shorewall.net. If you are a current subscriber to the list at
    Sourceforge, please <a href=
    "shorewall_mailing_list_migration.htm">see these
    instructions</a>. If you would like to subscribe to the new
    list, visit <a href=
    "http://www.shorewall.net/mailman/listinfo/shorewall-users">http://www.shorewall.net/mailman/listinfo/shorewall-users</a>.</p>

    <p><b>12/31/2001 - Shorewall 1.2.1 Released</b></p>

    <p>In version 1.2.1:</p>

    <ul>
      <li><a href="Documentation.htm#LogUncleanOption">Logging of
      Mangled/Invalid Packets</a> is added.&nbsp;</li>

      <li>The <a href="IPIP.htm">tunnel script</a> has been
      corrected.</li>

      <li>'shorewall show tc' now correctly handles tunnels.</li>
    </ul>

    <p><b>12/21/2001 - Shorewall 1.2.0 Released!</b> - <b>I
    couldn't resist releasing 1.2 on 12/21/2001</b></p>

    <p>Version 1.2 contains the following new features:</p>

    <ul>
      <li>Support for <a href="traffic_shaping.htm">Traffic
      Control/Shaping</a></li>

      <li>Support for <a href="Documentation.htm#Unclean">Filtering
      of Mangled/Invalid Packets</a></li>

      <li>Support for <a href="IPIP.htm">GRE Tunnels</a></li>
    </ul>

    <p>For the next month or so, I will continue to provide
    corrections to version 1.1.18 as necessary so that current
    version 1.1.x users will not be forced into a quick upgrade to
    1.2.0 just to have access to bug fixes.</p>

    <p>For those of you who have installed one of the Beta RPMS,
    you will need to use the "--oldpackage" option when upgrading
    to 1.2.0:</p>

    <blockquote>
      <p>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</p>
    </blockquote>

    <p><b>12/19/2001 - Thanks to <a href=
    "mailto:scowles@infohiiway.com">Steve Cowles</a>, there is now
    a Shorewall mirror in Texas.</b> This web site is mirrored at
    <a href="http://www.infohiiway.com/shorewall" target=
    "_top">http://www.infohiiway.com/shorewall</a> and the ftp site
    is at <a href=
    "ftp://ftp.infohiiway.com/pub/mirrors/shorewall">ftp://ftp.infohiiway.com/pub/mirrors/shorewall</a>.
    <b>&nbsp;</b></p>

    <p><b>11/30/2001 - A new set of the parameterized <a href=
    "ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">Sample
    Configurations</a> has been released</b>. In this version:</p>

    <ul>
      <li>Ping is now allowed between the zones.</li>

      <li>In the three-interface configuration, it is now possible
      to configure the internet services that are to be available
      to servers in the DMZ.&nbsp;</li>
    </ul>

    <p><b>11/20/2001 - The current version of Shorewall is
    1.1.18.&nbsp;</b></p>

    <p>In this version:</p>

    <ul>
      <li>The spelling of ADD_IP_ALIASES has been corrected in the
      shorewall.conf file</li>

      <li>The logic for deleting user-defined chains has been
      simplified so that it avoids a bug in the LRP version of the
      'cut' utility.</li>

      <li>The /var/lib/lrpkg/shorwall.conf file has been corrected
      to properly display the NAT entry in that file.</li>
    </ul>

    <p><b>11/19/2001 - Thanks to <a href=
    "mailto:shorewall@timelord.sk">Juraj Ontkanin</a>, there is now
    a Shorewall mirror in the Slovak Republic</b>. The website is
    now mirrored at <a href="http://www.nrg.sk/mirror/shorewall"
    target="_top">http://www.nrg.sk/mirror/shorewall</a> and the
    FTP site is mirrored at <a href=
    "ftp://ftp.nrg.sk/mirror/shorewall">ftp://ftp.nrg.sk/mirror/shorewall</a>.</p>

    <p><b>11/2/2001 - Announcing Shorewall Parameter-driven Sample
    Configurations.</b> There are three sample configurations:</p>

    <ul>
      <li>One Interface -- for a standalone system.</li>

      <li>Two Interfaces -- A masquerading firewall.</li>

      <li>Three Interfaces -- A masquerading firewall with
      DMZ.</li>
    </ul>

    <p>Samples may be downloaded from <a href=
    "ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17">ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17</a>
    . See the README file for instructions.</p>

    <p><b>11/1/2001 - The current version of Shorewall is
    1.1.17</b>.&nbsp; I intend this to be the last of the 1.1
    Shorewall releases.</p>

    <p>In this version:</p>

    <ul>
      <li>The handling of <a href=
      "Documentation.htm#Aliases">ADD_IP_ALIASES</a> has been
      corrected.&nbsp;</li>
    </ul>

    <p><b>10/22/2001 - The current version of Shorewall is
    1.1.16</b>. In this version:</p>

    <ul>
      <li>A new "shorewall show connections" command has been
      added.</li>

      <li>In the "shorewall monitor" output, the currently tracked
      connections are now shown on a separate page.</li>

      <li>Prior to this release, Shorewall unconditionally added
      the external IP adddress(es) specified in /etc/shorewall/nat.
      Beginning with version 1.1.16, a new parameter (<a href=
      "Documentation.htm#Aliases">ADD_IP_ALIASES</a>) may be set to
      "no" (or "No") to inhibit this behavior. This allows IP
      aliases created using your distribution's network
      configuration tools to be used in static NAT.&nbsp;</li>
    </ul>

    <p><b>10/15/2001 - The current version of Shorewall is
    1.1.15.</b> In this version:</p>

    <ul>
      <li>Support for nested zones has been improved. See <a href=
      "Documentation.htm#Nested">the documentation</a> for
      details</li>

      <li>Shorewall now correctly checks the alternate
      configuration directory for the 'zones' file.</li>
    </ul>

    <p><b>10/4/2001 - The current version of Shorewall is
    1.1.14.</b> In this version</p>

    <ul>
      <li>Shorewall now supports alternate configuration
      directories. When an alternate directory is specified when
      starting or restarting Shorewall (e.g., "shorewall -c
      /etc/testconf restart"), Shorewall will first look for
      configuration files in the alternate directory then in
      /etc/shorewall. To create an alternate configuration
      simply:<br>
       1. Create a New Directory<br>
       2. Copy to that directory any of your configuration files
      that you want to change.<br>
       3. Modify the copied files as needed.<br>
       4. Restart Shorewall specifying the new directory.</li>

      <li>The rules for allowing/disallowing icmp echo-requests
      (pings) are now moved after rules created when processing the
      rules file. This allows you to add rules that selectively
      allow/deny ping based on source or destination address.</li>

      <li>Rules that specify multiple client ip addresses or
      subnets no longer cause startup failures.</li>

      <li>Zone names in the policy file are now validated against
      the zones file.</li>

      <li>If you have <a href=
      "Documentation.htm#MangleEnabled">packet mangling</a> support
      enabled, the "<a href=
      "Documentation.htm#Interfaces">norfc1918</a>" interface
      option now logs and drops any incoming packets on the
      interface that have an RFC 1918 destination address.</li>
    </ul>

    <p><b>9/12/2001 - The current version of Shorewall is
    1.1.13</b>. In this version</p>

    <ul>
      <li>Shell variables can now be used to parameterize Shorewall
      rules.</li>

      <li>The second column in the hosts file may now contain a
      comma-separated list.<br>
      <br>
       Example:<br>
       &nbsp;&nbsp;&nbsp; sea&nbsp;&nbsp;&nbsp;
      eth0:130.252.100.0/24,206.191.149.0/24</li>

      <li>Handling of multi-zone interfaces has been improved. See
      the <a href="Documentation.htm#Interfaces">documentation for
      the /etc/shorewall/interfaces file</a>.</li>
    </ul>

    <p><b>8/28/2001 - The current version of Shorewall is
    1.1.12</b>. In this version</p>

    <ul>
      <li>Several columns in the rules file may now contain
      comma-separated lists.</li>

      <li>Shorewall is now more rigorous in parsing the options in
      /etc/shorewall/interfaces.</li>

      <li>Complementation using "!" is now supported in rules.</li>
    </ul>

    <p><b>7/28/2001 - The current version of Shorewall is
    1.1.11</b>. In this version</p>

    <ul>
      <li>A "shorewall refresh" command has been added to allow for
      refreshing the rules associated with the broadcast address on
      a dynamic interface. This command should be used in place of
      "shorewall restart" when the internet interface's IP address
      changes.</li>

      <li>The /etc/shorewall/start file (if any) is now processed
      after all temporary rules have been deleted. This change
      prevents the accidental removal of rules added during the
      processing of that file.</li>

      <li>The "dhcp" interface option is now applicable to firewall
      interfaces used by a DHCP server running on the
      firewall.</li>

      <li>The RPM can now be built from the .tgz file using "rpm
      -tb"&nbsp;</li>
    </ul>

    <p><b>7/6/2001 - The current version of Shorewall is
    1.1.10.</b> In this version</p>

    <ul>
      <li>Shorewall now enables Ipv4 Packet Forwarding by default.
      Packet forwarding may be disabled by specifying
      IP_FORWARD=Off in /etc/shorewall/shorewall.conf. If you don't
      want Shorewall to enable or disable packet forwarding, add
      IP_FORWARDING=Keep to your /etc/shorewall/shorewall.conf
      file.</li>

      <li>The "shorewall hits" command no longer lists extraneous
      service names in its last report.</li>

      <li>Erroneous instructions in the comments at the head of the
      firewall script have been corrected.</li>
    </ul>

    <p><b>6/23/2001 - The current version of Shorewall is
    1.1.9.</b> In this version</p>

    <ul>
      <li>The "tunnels" file <u>really</u> is in the RPM now.</li>

      <li>SNAT can now be applied to port-forwarded
      connections.</li>

      <li>A bug which would cause firewall start failures in some
      dhcp configurations has been fixed.</li>

      <li>The firewall script now issues a message if you have the
      name of an interface in the second column in an entry in
      /etc/shorewall/masq and that interface is not up.</li>

      <li>You can now configure Shorewall so that it <a href=
      "Documentation.htm#NatEnabled">doesn't require the NAT and/or
      mangle netfilter modules</a>.</li>

      <li>Thanks to Alex&nbsp; Polishchuk, the "hits" command from
      seawall is now in shorewall.</li>

      <li>Support for <a href="IPIP.htm">IPIP tunnels</a> has been
      added.</li>
    </ul>

    <p><b>6/18/2001 - The current version of Shorewall is
    1.1.8</b>. In this version</p>

    <ul>
      <li>A typo in the sample rules file has been corrected.</li>

      <li>It is now possible to restrict masquerading by <a href=
      "Documentation.htm#Masq">destination host or subnet.</a></li>

      <li>It is now possible to have static <a href=
      "NAT.htm#LocalPackets">NAT rules applied to packets
      originating on the firewall itself</a>.</li>
    </ul>

    <p><b>6/2/2001 - The current version of Shorewall is 1.1.7.</b>
    In this version</p>

    <ul>
      <li>The TOS rules are now deleted when the firewall is
      stopped.</li>

      <li>The .rpm will now install regardless of which version of
      iptables is installed.</li>

      <li>The .rpm will now install without iproute2 being
      installed.</li>

      <li>The documentation has been cleaned up.</li>

      <li>The sample configuration files included in Shorewall have
      been formatted to 80 columns for ease of editing on a VGA
      console.</li>
    </ul>

    <p><b>5/25/2001 - The current version of Shorewall is
    1.1.6</b>. In this version</p>

    <ul>
      <li><a href="Documentation.htm#lograte">You may now
      rate-limit the packet log.</a></li>

      <li>Previous versions of Shorewall have an implementation of
      Static NAT which violates the principle of least
      surprise.&nbsp; NAT only occurs for packets arriving at
      (DNAT) or send from (SNAT) the interface named in the
      INTERFACE column of /etc/shorewall/nat. Beginning with
      version 1.1.6, NAT effective regardless of which interface
      packets come from or are destined to. To get compatibility
      with prior versions, I have added a new "ALL <a href=
      "NAT.htm#AllInterFaces">"ALL INTERFACES"&nbsp; column to
      /etc/shorewall/nat</a>. By placing "no" or "No" in the new
      column, the NAT behavior of prior versions may be
      retained.&nbsp;</li>

      <li>The treatment of <a href="IPSEC.htm#RoadWarrior">IPSEC
      Tunnels where the remote gateway is a standalone system has
      been improved</a>. Previously, it was necessary to include an
      additional rule allowing UDP port 500 traffic to pass through
      the tunnel. Shorewall will now create this rule automatically
      when you place the name of the remote peer's zone in a new
      GATEWAY ZONE column in /etc/shorewall/tunnels.&nbsp;</li>
    </ul>

    <p><b>5/20/2001 - The current version of Shorewall is
    1.1.5.</b> In this version</p>

    <ul>
      <li><a href="Documentation.htm#modules">You may now pass
      parameters when loading netfilter modules and you can specify
      the modules to load.</a></li>

      <li>Compressed modules are now loaded. This requires that you
      modutils support loading compressed modules.</li>

      <li><a href="Documentation.htm#TOS">You may now set the Type
      of Service (TOS) field in packets.</a></li>

      <li>Corrected rules generated for port redirection
      (again).</li>
    </ul>

    <p><b>5/10/2001 - The current version of Shorewall is
    1.1.4.</b> In this version</p>

    <ul>
      <li><a href="Documentation.htm#Conf">Accepting RELATED
      connections is now optional.</a></li>

      <li>Corrected problem where if "shorewall start" aborted
      early (due to kernel configuration errors for example),
      superfluous 'sed' error messages were reported.</li>

      <li>Corrected rules generated for port redirection.</li>

      <li>The order in which iptables kernel modules are loaded has
      been corrected (Thanks to Mark Pavlidis).&nbsp;</li>
    </ul>

    <p><b>4/28/2001 - The current version of Shorewall is
    1.1.3.</b> In this version</p>

    <ul>
      <li>Correct message issued when Proxy ARP address added
      (Thanks to Jason Kirtland).</li>

      <li>/tmp/shorewallpolicy-$$ is now removed if there is an
      error while starting the firewall.</li>

      <li>/etc/shorewall/icmp.def and /etc/shorewall/common.def are
      now used to define the icmpdef and common chains unless
      overridden by the presence of /etc/shorewall/icmpdef or
      /etc/shorewall/common.</li>

      <li>In the .lrp, the file /var/lib/lrpkg/shorwall.conf has
      been corrected. An extra space after "/etc/shorwall/policy"
      has been removed and "/etc/shorwall/rules" has been
      added.</li>

      <li>When a sub-shell encounters a fatal error and has stopped
      the firewall, it now kills the main shell so that the main
      shell will not continue.</li>

      <li>A problem has been corrected where a sub-shell stopped
      the firewall and main shell continued resulting in a
      perplexing error message referring to "common.so"
      resulted.</li>

      <li>Previously, placing "-" in the PORT(S) column in
      /etc/shorewall/rules resulted in an error message during
      start. This has been corrected.</li>

      <li>The first line of "install.sh" has been corrected -- I
      had inadvertently deleted the initial "#".</li>
    </ul>

    <p><b>4/12/2001 - The current version of Shorewall is
    1.1.2.</b> In this version</p>

    <ul>
      <li>Port redirection now works again.</li>

      <li>The icmpdef and common chains <a href=
      "Documentation.htm#Icmpdef">may now be user-defined</a>.</li>

      <li>The firewall no longer fails to start if "routefilter" is
      specified for an interface that isn't started. A warning
      message is now issued in this case.</li>

      <li>The LRP Version is renamed "shorwall" for 8,3 MSDOS file
      system compatibility.</li>

      <li>A couple of LRP-specific problems were corrected.</li>
    </ul>

    <p><b>4/8/2001 - Shorewall is now affiliated with the <a href=
    "http://leaf.sourceforge.net">Leaf Project</a></b> <a href=
    "http://leaf.sourceforge.net"><img src="images/leaflogo.gif"
    alt="Leaf Logo" border="0" height="36" width="49"></a></p>

    <p><b>4/5/2001 - The current version of Shorewall is 1.1.1. In
    this version:</b></p>

    <ul>
      <li>The common chain is traversed from INPUT, OUTPUT and
      FORWARD before logging occurs</li>

      <li>The source has been cleaned up dramatically</li>

      <li>DHCP DISCOVER packets with RFC1918 source addresses no
      longer generate log messages. Linux DHCP clients generate
      such packets and it's annoying to see them logged.&nbsp;</li>
    </ul>

    <p><b>3/25/2001 - The current version of Shorewall is 1.1.0. In
    this version:</b></p>

    <ul>
      <li>Log messages now indicate the packet disposition.</li>

      <li>Error messages have been improved.</li>

      <li>The ability to define zones consisting of an enumerated
      set of hosts and/or subnetworks has been added.</li>

      <li>The zone-to-zone chain matrix is now sparse so that only
      those chains that contain meaningful rules are defined.</li>

      <li>240.0.0.0/4 and 169.254.0.0/16 have been added to the
      source subnetworks whose packets are dropped under the
      <i>norfc1918</i> interface option.</li>

      <li>Exits are now provided for executing an user-defined
      script when a chain is defined, when the firewall is
      initialized, when the firewall is started, when the firewall
      is stopped and when the firewall is cleared.</li>

      <li>The Linux kernel's route filtering facility can now be
      specified selectively on network interfaces.</li>
    </ul>

    <p><b>3/19/2001 - The current version of Shorewall is 1.0.4.
    This version:</b></p>

    <ul>
      <li>Allows user-defined zones. Shorewall now has only one
      pre-defined zone (fw) with the remaining zones being defined
      in the new configuration file /etc/shorewall/zones. The
      /etc/shorewall/zones file released in this version provides
      behavior that is compatible with Shorewall 1.0.3.&nbsp;</li>

      <li>Adds the ability to specify logging in entries in the
      /etc/shorewall/rules file.</li>

      <li>Correct handling of the icmp-def chain so that only ICMP
      packets are sent through the chain.</li>

      <li>Compresses the output of "shorewall monitor" if awk is
      installed. Allows the command to work if awk isn't installed
      (although it's not pretty).</li>
    </ul>

    <p><b>3/13/2001 - The current version of Shorewall is 1.0.3.
    This is a bug-fix release with no new features.</b></p>

    <ul>
      <li>The PATH variable in the firewall script now includes
      /usr/local/bin and /usr/local/sbin.</li>

      <li>DMZ-related chains are now correctly deleted if the DMZ
      is deleted.</li>

      <li>The interface OPTIONS for "gw" interfaces are no longer
      ignored.</li>
    </ul>

    <p><b>3/8/2001 - The current version of Shorewall is 1.0.2. It
    supports an additional "gw" (gateway) zone for tunnels and it
    supports IPSEC tunnels with end-points on the firewall. There
    is also a .lrp available now.</b></p>
  </body>
</html>