shorewall_code/Shorewall-Website/News.htm

6878 lines
297 KiB
HTML
Raw Normal View History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Shorewall News</title>
</head>
<body>
<h1 style="text-align: left;">Shorewall News Archive</h1>
<span style="font-weight: bold;">Tom Eastep<br>
<br>
</span>Copyright © 2001-2004 Thomas M. Eastep<br>
<p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled “<span
class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free
Documentation License</a></span>”.<br>
</p>
<p>2004-10-25<br>
</p>
<hr style="width: 100%; height: 2px;">
<p><span style="font-weight: bold;"><br>
<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><b> </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><b></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><b></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><b></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 taylors 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 taylors 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 taylors 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><b> </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><b> </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> <b></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> <b></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> <b></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> <b></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> <b></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>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>
<b></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>
<b></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> <b></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> <b></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></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> <b></b> <b></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> <b></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> <b></b></p>
<b></b>
<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 <i></i>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> <b></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>
<b></b></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>
<b></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.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</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.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</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> <b></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> <b></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> <b></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>