forked from extern/shorewall_code
Some 2.2.0 Updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1928 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
6b388d822f
commit
73d5757eaf
@ -18,11 +18,131 @@ 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>2005-01-04<br>
|
||||
<p>2005-02-01<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><span style="font-weight: bold;"><br>
|
||||
</span><span style="font-weight: bold;">12/24/2004 -
|
||||
</span><span style="font-weight: bold;">01/17/2005 -
|
||||
Shorewall 2.2.0 RC5<br>
|
||||
<br>
|
||||
</span>Problems Corrected:<br>
|
||||
</p>
|
||||
<ol>
|
||||
<li>The AllowTrcrt action has been changed to allow up to 30 hops
|
||||
(same as default for 'traceroute'). Previously, the action was
|
||||
documented as allowing 20 hops but actually only allowed for 6 hops.<br>
|
||||
</li>
|
||||
<li>Using some lightweight shells, valid entries in
|
||||
/etc/shorewall/ecn produce startup errors.</li>
|
||||
</ol>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>A new AllowInvalid standard built-in action has been added. This
|
||||
action accepts packets that are in the INVALID connection-tracking
|
||||
state.</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="Mirrors"></a>01/16/2005 - New
|
||||
Shorewall Mirrors<br>
|
||||
<br>
|
||||
</span>Thanks to Lorenzo Martignoni and Nick Slikey, there are now
|
||||
Shorewall <a href="shorewall_mirrors.htm">mirrors</a> in Milan Italy
|
||||
and in Austin Texas. Thanks Lorenzo
|
||||
and Nick!<br>
|
||||
<span style="font-weight: bold;"><br>
|
||||
<a name="2_0_15"></a>01/12/2005 -
|
||||
Shorewall 2.0.15<br>
|
||||
</span><br>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>The range of ports opened by the AllowTrcrt action has been
|
||||
expanded to 33434:33524 to allow for a maximum of 30 hops.</li>
|
||||
<li>Code mis-ported from 2.2.0 in release 2.0.14 caused the following
|
||||
error during "shorewall start" where SYN rate-limiting is present in
|
||||
/etc/shorewall/policy:<br>
|
||||
<br>
|
||||
Bad argument `DROP'<br>
|
||||
Try `iptables -h' or 'iptables --help'
|
||||
for more information.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="2_2_0_RC4"></a>01/06/2005 -
|
||||
Shorewall 2.2.0 RC4<br>
|
||||
</span><br>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>A listing of loaded iptables kernel modules is now included in
|
||||
the output of "shorewall status".<br>
|
||||
</li>
|
||||
</ol>
|
||||
Problems Corrected.<br>
|
||||
<ol>
|
||||
<li>Several problems associated with processing the IPSEC colummn in
|
||||
/etc/shorewall/masq have been corrected.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="2_0_14"></a>01/03/2005 -
|
||||
Shorewall 2.0.14<br>
|
||||
</span><br>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>Previously, when rate-limiting was specified in
|
||||
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
||||
the specified rate was silently dropped. Now, if a log level is given
|
||||
in the entry (LEVEL column) then drops are logged at that level at a
|
||||
rate of 5/min with a burst of 5.<br>
|
||||
</li>
|
||||
</ol>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>A typo in the /etc/shorewall/interfaces file has been fixed.</li>
|
||||
<li>"bad variable" error messages occurring during "shorewall stop"
|
||||
and "shorewall clear" have been eliminated.</li>
|
||||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.
|
||||
The TYPE column for an IPIP tunnel should contain "ipip" rather than
|
||||
"ip".<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="MandrakeRPMS"></a>12/31/2004
|
||||
- Mandrake-specific RPMs available<br>
|
||||
<br>
|
||||
</span>Jack Coates has generously volunteered to provide Shorewall RPMs
|
||||
for use under Mandrake. You can download Jack's RPMs from <a
|
||||
target="_top" href="http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
|
||||
<br>
|
||||
<span style="font-weight: bold;"><a name="Redhat_Fedora"></a>12/31/2004
|
||||
- Redhat/Fedora-specific RPMs available<br>
|
||||
</span><br>
|
||||
Simon Matter has graciously volunteered to provide RPMs taylored for
|
||||
Redhat and Fedora. You can download Simon's RPMs from <a target="_top"
|
||||
href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||||
<br>
|
||||
Thanks, Simon!<br>
|
||||
<br>
|
||||
<span style="font-weight: bold;"><a name="2_2_0_RC3"></a>12/30/2004 -
|
||||
Shorewall 2.2.0 RC3<br>
|
||||
</span><br>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>The following error message could appear during "shorewall stop"
|
||||
or "shorewall clear":<br>
|
||||
|
||||
<br>
|
||||
|
||||
local: lo:: bad variable name<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The rate limiting example in /etc/shorewall/rules has been
|
||||
changed to use the RATE LIMIT column.</li>
|
||||
<li>Entries in /etc/shorewall/masq with the INTERFACE column
|
||||
containing <ifname>:: (e.g., "eth0::") would generate a progress
|
||||
message but would not generate an iptables rule.</li>
|
||||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"></span>
|
||||
<p><br>
|
||||
</p>
|
||||
<p><span style="font-weight: bold;">12/24/2004 -
|
||||
Shorewall 2.2.0 RC2<br>
|
||||
<br>
|
||||
</span>New Features:<br>
|
||||
|
||||
@ -22,7 +22,7 @@ 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>2005-01-14<br>
|
||||
<p>2005-01-26<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p><b>I strongly urge you to read and print a copy of the <a
|
||||
@ -63,7 +63,12 @@ one</u> of the modules:</p>
|
||||
his site</a>.</li>
|
||||
<li>Jack Coates provides RPMs taylored for <span
|
||||
style="font-weight: bold;">Mandrake.</span> You can <a
|
||||
href="http://www.monkeynoodle.org/tmp">download them from his site</a>.<br>
|
||||
href="http://www.monkeynoodle.org/tmp">download them from his site</a>.</li>
|
||||
<li>Marc Zonzon provides a package for <span
|
||||
style="font-weight: bold;">OpenWRT</span> (Open firmware for Linksys®
|
||||
WRT54G). You can <a
|
||||
href="http://www.iut-lannion.fr/ZONZON/memos_index.php?part=Network&section=WRTMemo&subsec=shorewall">download
|
||||
it from his site</a>.<br>
|
||||
</li>
|
||||
<li>If you run a <b>SuSE, </b><b>Linux
|
||||
PPC</b>, <span style="font-weight: bold;">Trustix</span> or <b>
|
||||
@ -72,7 +77,10 @@ use the standard RPM version (note: the RPM should also work with other
|
||||
distributions that store init scripts in /etc/init.d and that include
|
||||
chkconfig or insserv). If you find that it works in other cases, let <a
|
||||
href="mailto:teastep@shorewall.net"> me</a> know so that I can mention
|
||||
them here. See the <a href="Install.htm">Installation Instructions</a>
|
||||
them here (Note: the standard RPM is known to work on Redhat, Fedora
|
||||
and Mandrake with issues ranging from trivial (Redhat and Fedora) to
|
||||
moderate (Mandrake)). See the <a href="Install.htm">Installation
|
||||
Instructions</a>
|
||||
if you have problems installing the RPM.</li>
|
||||
<li>If you are running LEAF Bering or Bering uClibc, download the
|
||||
.lrp file<br>
|
||||
@ -106,6 +114,10 @@ Simon Matter: <a href="http://www.invoca.ch/pub/packages/shorewall/">http://www.
|
||||
<br>
|
||||
<span style="font-weight: bold;">Mandrake</span> RPMS provided by Jack
|
||||
Coates: <a href="http://www.monkeynoodle.org/tmp">http://www.monkeynoodle.org/tmp</a><br>
|
||||
<br>
|
||||
<span style="font-weight: bold;">OpenWRT</span> package provided by
|
||||
Marc Zonzon: <a
|
||||
href="http://www.iut-lannion.fr/ZONZON/memos_index.php?part=Network&section=WRTMemo&subsec=shorewall">http://www.iut-lannion.fr/ZONZON/memos_index.php?part=Network&section=WRTMemo&subsec=shorewall</a><br>
|
||||
</div>
|
||||
<blockquote>
|
||||
<table style="border-collapse: collapse;" border="2" cellpadding="2">
|
||||
|
||||
@ -15,9 +15,17 @@ when there is nothing left to add, but rather when there is nothing
|
||||
left to take away.</span><br>
|
||||
<br>
|
||||
<div style="text-align: center;"> - Antoine de Saint-Exupery<br>
|
||||
<div style="text-align: left;"><br>
|
||||
<span style="font-style: italic;">Fragmentation is like classful
|
||||
addressing -- an interesting early architectural error that shows how
|
||||
much experimentation was going on while IP was being designed.</span><br>
|
||||
<div style="text-align: center;"><br>
|
||||
- Paul Vixie</div>
|
||||
<br>
|
||||
</div>
|
||||
</div>
|
||||
<br>
|
||||
Copyright © 2001-2003 Thomas M. Eastep<br>
|
||||
Copyright © 2001-2005 Thomas M. Eastep<br>
|
||||
<br>
|
||||
<p>Permission is granted to copy, distribute and/or modify this
|
||||
document under the terms of the GNU Free Documentation License, Version
|
||||
@ -27,11 +35,12 @@ 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-11-18<br>
|
||||
<p>2005-01-24<br>
|
||||
</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<p style="text-align: left;"><img src="images/Tom.jpg"
|
||||
alt="Aging Geek - June 2003" border="3" height="240" width="320"> </p>
|
||||
alt="Aging Geek - June 2003"
|
||||
style="border: 3px solid ; width: 320px; height: 240px;"> </p>
|
||||
<div style="text-align: left;">"The Aging Geek" -- June 2003<br>
|
||||
</div>
|
||||
<p align="center"><br>
|
||||
|
||||
@ -28,20 +28,16 @@ to 2.x releases of Shorewall. For older versions:</p>
|
||||
target="_top">here</a>. </p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>The current 2.0 Stable Release is 2.0.15 -- Here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.0/shorewall-2.0.15/releasenotes.txt">release
|
||||
notes</a>.<br>
|
||||
The current Developement Release is 2.2.0 RC5 -- Here
|
||||
are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-RC5/releasenotes.txt">release
|
||||
<p>The current 2.2 Stable Release is 2.2.0 -- Here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.0/releasenotes.txt">release
|
||||
notes</a> and here are the <a
|
||||
href="http://shorewall.net/pub/shorewall/2.2-Beta/shorewall-2.2.0-RC5/known_problems.txt">known
|
||||
href="http://shorewall.net/pub/shorewall/2.2/shorewall-2.2.0/known_problems.txt">known
|
||||
problems</a>.<br>
|
||||
</p>
|
||||
<p><a
|
||||
href="http://lists.shorewall.net/pipermail/shorewall-announce/2004-December/000451.html"><span
|
||||
style="font-weight: bold;">Preparing for Shorewall 2.2 -- End of
|
||||
support life for Shorewall 1.4 is Near! </span></a><br>
|
||||
style="font-weight: bold;">End of
|
||||
support life for Shorewall 1.4 -- Upgrading to Shorewall 2.2</span></a><br>
|
||||
<br>
|
||||
Copyright © 2001-2005 Thomas M. Eastep</p>
|
||||
<p>Permission is granted to copy, distribute and/or modify this
|
||||
@ -51,7 +47,7 @@ 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 “<a href="GnuCopyright.htm" target="_self">GNU
|
||||
Free Documentation License</a>”.</p>
|
||||
<p>2005-01-17</p>
|
||||
<p>2005-02-01</p>
|
||||
<hr>
|
||||
<h3>Table of Contents</h3>
|
||||
<p style="margin-left: 0.42in; margin-bottom: 0in;"><a href="#Intro">Introduction
|
||||
@ -66,23 +62,14 @@ Shorewall</a><br>
|
||||
Shorewall on Mandrake® with a two-interface setup?</a><br>
|
||||
<a href="#License">License</a></p>
|
||||
<p style="margin-bottom: 0in; margin-left: 40px;"><a href="#2_0_10">News</a></p>
|
||||
<p style="margin-left: 0.83in; margin-bottom: 0in;"><a href="#2_2_0_RC5">Shorewall
|
||||
2.2.0-RC5</a><br>
|
||||
<a href="#Mirrors">New
|
||||
Shorewall Mirrors</a><br>
|
||||
<a href="#2_0_15">Shorewall
|
||||
2.0.15</a><br>
|
||||
<a href="#2_2_0_RC4">Shorewall
|
||||
2.2.0-RC4</a><br>
|
||||
<a href="#2_0_14">Shorewall
|
||||
2.0.14</a><br>
|
||||
<a href="#MandrakeRPMS">Mandrake-specific RPMs available</a><br>
|
||||
<a href="#Redhat_Fedora">Redhat/Fedora-specific RPMs available</a><br>
|
||||
<a href="#2_2_0_RC3">Shorewall
|
||||
2.2.0 RC3</a><a href="#2_2_0_RC2"></a><br>
|
||||
<p style="margin-left: 0.83in; margin-bottom: 0in;"><span
|
||||
style="text-decoration: underline;"></span><a href="#2_2_0">Shorewall
|
||||
2.2.0</a><br>
|
||||
<br>
|
||||
</p>
|
||||
<div style="margin-left: 40px;"><a href="#Leaf">Leaf</a><br>
|
||||
<br>
|
||||
<a href="#OpenWRT">OpenWRT</a><br>
|
||||
</div>
|
||||
<p style="margin-left: 40px;"><a href="#Donations">Donations</a></p>
|
||||
<h2><a name="Intro"></a>Introduction to Shorewall</h2>
|
||||
@ -171,123 +158,690 @@ of the license is included in the section entitled "GNU Free
|
||||
Documentation License". </p>
|
||||
<hr>
|
||||
<h2><a name="News"></a>News</h2>
|
||||
<span style="font-weight: bold;"><a name="2_2_0_RC5"></a>01/17/2005 -
|
||||
Shorewall 2.2.0 RC5<br>
|
||||
<span style="font-weight: bold;"><a name="2_2_0"></a>02/01/2005
|
||||
Shorewall 2.2.0<br>
|
||||
<br>
|
||||
</span>Problems Corrected:<br>
|
||||
</span>New Features:<br>
|
||||
<ol>
|
||||
<li>The AllowTrcrt action has been changed to allow up to 30 hops
|
||||
(same as default for 'traceroute'). Previously, the action was
|
||||
documented as allowing 20 hops but actually only allowed for 6 hops.<br>
|
||||
<li>ICMP packets that are in the INVALID state are now dropped by the
|
||||
Reject and Drop default actions. They do so using the new 'dropInvalid'
|
||||
builtin action. An 'allowInvalid' builtin action is also provided which
|
||||
accepts packets in that state.</li>
|
||||
<li>The /etc/shorewall/masq file INTERFACE column now allows
|
||||
additional options.<br>
|
||||
<br>
|
||||
Normally MASQUERADE/SNAT rules are evaluated after one-to-one NAT rules
|
||||
defined in the /etc/shorewall/nat file. If you preceed the interface
|
||||
name with a plus sign ("+") then the rule will be evaluated before
|
||||
one-to-one NAT.<br>
|
||||
<br>
|
||||
Examples:<br>
|
||||
<br>
|
||||
+eth0<br>
|
||||
+eth1:192.0.2.32/27<br>
|
||||
<br>
|
||||
Also, the effect of ADD_SNAT_ALIASES=Yes can be negated for an entry by
|
||||
following the interface name by ":" but no digit. <br>
|
||||
<br>
|
||||
Examples:<br>
|
||||
<br>
|
||||
eth0:<br>
|
||||
eth1::192.0.2.32/27<br>
|
||||
+eth3:<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Using some lightweight shells, valid entries in
|
||||
/etc/shorewall/ecn produce startup errors.</li>
|
||||
<li>Similar to 2), the /etc/shorewall/nat file INTERFACE column now
|
||||
allows you to override the setting of ADD_IP_ALIASES=Yes by following
|
||||
the interface name with ":" but no digit.</li>
|
||||
<li>All configuration files in the Shorewall distribution with the
|
||||
exception of shorewall.conf are now empty. In particular, the
|
||||
/etc/shorewall/zones, /etc/shorewall/policy and /etc/shorewall/tos
|
||||
files now have no active entries. Hopefully this will stop the
|
||||
questions on the support and development lists regarding why the
|
||||
default entries are the way they are.</li>
|
||||
<li>Previously, including a log level (and optionally a log tag) on a
|
||||
rule that specified a user-defined (or Shorewall-defined) action would
|
||||
log all traffic passed to the action. Beginning with this release,
|
||||
specifying a log level in a rule that specifies a user- or
|
||||
Shorewall-defined action will cause each rule in the action to be
|
||||
logged with the specified level (and tag).<br>
|
||||
<br>
|
||||
The extent to which logging of action rules occurs is goverend by the
|
||||
following:</li>
|
||||
<ul>
|
||||
<li>When you invoke an action and specify a log level, only those
|
||||
rules in the action that have no log level will be changed to log at
|
||||
the level specified at the action invocation.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
/etc/shorewall/action.foo:<br>
|
||||
<br>
|
||||
ACCEPT - -
|
||||
tcp 22<br>
|
||||
bar:info<br>
|
||||
<br>
|
||||
/etc/shorewall/rules:<br>
|
||||
<br>
|
||||
foo:debug fw net<br>
|
||||
<br>
|
||||
Logging in the invoked 'foo' action will be:<br>
|
||||
<br>
|
||||
ACCEPT:debug - -
|
||||
tcp 22<br>
|
||||
bar:info<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>If you follow the log level with "!" then logging will be at
|
||||
that level for all rules recursively invoked by the action<br>
|
||||
<br>
|
||||
Example: /etc/shorewall/action.foo:<br>
|
||||
<br>
|
||||
ACCEPT - -
|
||||
tcp 22<br>
|
||||
bar:info<br>
|
||||
<br>
|
||||
/etc/shorewall/rules:<br>
|
||||
<br>
|
||||
foo:debug! fw net<br>
|
||||
<br>
|
||||
Logging in the invoke 'foo' action will be:<br>
|
||||
<br>
|
||||
ACCEPT:debug - -
|
||||
tcp 22<br>
|
||||
bar:debug!<br>
|
||||
<br>
|
||||
</li>
|
||||
</ul>
|
||||
</ol>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>A new AllowInvalid standard built-in action has been added. This
|
||||
action accepts packets that are in the INVALID connection-tracking
|
||||
state.</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="Mirrors"></a>01/16/2005 - New
|
||||
Shorewall Mirrors<br>
|
||||
<div style="margin-left: 40px;">This change has an effect on extension
|
||||
scripts used with user-defined actions. If you define an action 'acton'
|
||||
and you have an /etc/shorewall/acton script then when that script is
|
||||
invoked, the following three variables will be set for use by the
|
||||
script:<br>
|
||||
<br>
|
||||
</span>Thanks to Lorenzo Martignoni and Nick Slikey, there are now
|
||||
Shorewall <a href="shorewall_mirrors.htm">mirrors</a> in Milan Italy
|
||||
and in Austin Texas. Thanks Lorenzo
|
||||
and Nick!<br>
|
||||
<span style="font-weight: bold;"><br>
|
||||
<a name="2_0_15"></a>01/12/2005 -
|
||||
Shorewall 2.0.15<br>
|
||||
</span><br>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>The range of ports opened by the AllowTrcrt action has been
|
||||
expanded to 33434:33524 to allow for a maximum of 30 hops.</li>
|
||||
<li>Code mis-ported from 2.2.0 in release 2.0.14 caused the following
|
||||
error during "shorewall start" where SYN rate-limiting is present in
|
||||
/etc/shorewall/policy:<br>
|
||||
<br>
|
||||
Bad argument `DROP'<br>
|
||||
Try `iptables -h' or 'iptables --help'
|
||||
for more information.<br>
|
||||
</li>
|
||||
<div style="margin-left: 40px;">$CHAIN = the name of the chain where
|
||||
your rules are to be placed. When logging is used on an action
|
||||
invocation, Shorewall creates a chain with a slightly different name
|
||||
from the action itself.<br>
|
||||
$LEVEL = Log level. If empty, no logging was specified.<br>
|
||||
$TAG = Log Tag.<br>
|
||||
<br>
|
||||
</div>
|
||||
Example:<br>
|
||||
<br>
|
||||
/etc/shorewall/rules:<br>
|
||||
<br>
|
||||
acton:info:test<br>
|
||||
<br>
|
||||
Your /etc/shorewall/acton file will be run with:<br>
|
||||
<br>
|
||||
<div style="margin-left: 40px;">$CHAIN="%acton1<br>
|
||||
$LEVEL="info"<br>
|
||||
$TAG="test"<br>
|
||||
</div>
|
||||
</div>
|
||||
<br>
|
||||
<ol start="6">
|
||||
<li>The /etc/shorewall/startup_disabled file is no longer created
|
||||
when
|
||||
Shorewall is first installed. Rather, the variable STARTUP_ENABLED is
|
||||
set to 'No' in /etc/shorewall/shorewall.conf. In order to get Shorewall
|
||||
to start, that variable's value must be set to 'Yes'. This change
|
||||
accomplishes two things:</li>
|
||||
<ul>
|
||||
<li>It prevents Shorewall from being started prematurely by the
|
||||
user's initialization scripts.</li>
|
||||
<li>It causes /etc/shorewall/shorewall.conf to be modified so that
|
||||
it won't be replaced by upgrades using RPM.<br>
|
||||
<br>
|
||||
</li>
|
||||
</ul>
|
||||
<li>Support has been added for the 2.6 Kernel IPSEC implementation.
|
||||
To use this support, you must have installed the IPSEC policy match
|
||||
patch and the four IPSEC/Netfilter patches from Patch-0-Matic-ng. The
|
||||
policy match patch affects both your kernel and iptables. There are two
|
||||
ways to specify that IPSEC is to be used when communicating with a set
|
||||
of hosts; both methods involve the new /etc/shorewall/ipsec file:</li>
|
||||
<ol style="list-style-type: lower-alpha;">
|
||||
<li>If encrypted communication is used with all hosts in a zone,
|
||||
then you can designate the zone as an "ipsec" zone by placing 'Yes" in
|
||||
the IPSEC ONLY column in /etc/shorewall/ipsec:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">#ZONE
|
||||
IPSEC OPTIONS ...</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">#
|
||||
ONLY</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
Yes</span><span
|
||||
style="font-family: sans-serif;"></span><br>
|
||||
<br>
|
||||
The hosts in the zone (if any) must be specified in
|
||||
/etc/shorewall/hosts but you do not need to specify the 'ipsec' option
|
||||
on the entries in that file (see below). Dynamic zones involving IPSEC
|
||||
must use that technique.<br>
|
||||
<br>
|
||||
Example:Under 2.4 Kernel FreeS/Wan:<br>
|
||||
<br>
|
||||
/etc/shorewall/zones:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
Net The big bad Internet</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
VPN Remote Network</span><br>
|
||||
<br>
|
||||
/etc/shorewall/interfaces:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
eth0 ...</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
ipsec0 ...</span><br>
|
||||
<br>
|
||||
Under 2.6 Kernel with this new support:<br>
|
||||
<br>
|
||||
/etc/shorewall/zones:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
Net The big bad Internet</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
VPN Remote Network</span><br>
|
||||
<br>
|
||||
/etc/shorewall/interfaces:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
eth0 ...</span><br>
|
||||
<br>
|
||||
/etc/shorewall/hosts:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">vpn
|
||||
eth0:0.0.0.0/0</span><br>
|
||||
<br>
|
||||
/etc/shorewall/ipsec<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">vpn Yes<br>
|
||||
<br>
|
||||
</span> </li>
|
||||
<li>If only part of the hosts in a zone require encrypted
|
||||
communication, you may use of the new 'ipsec' option in
|
||||
/etc/shorewall/hosts to designate those hosts.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
Under 2.4 Kernel FreeS/Wan:<br>
|
||||
<br>
|
||||
/etc/shorewall/zones:<br>
|
||||
<pre>net Net The big bad Internet<br>loc Local Extended local zone</pre>
|
||||
/etc/shorewall/interfaces:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
eth0 ...</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">loc
|
||||
eth1 ...</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">loc
|
||||
ipsec0 ...</span><br>
|
||||
<br>
|
||||
Under 2.6 Kernel with this new support:<br>
|
||||
<br>
|
||||
/etc/shorewall/zones:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
Net The big bad Internet</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
VPN Remote Network</span><br>
|
||||
<br>
|
||||
/etc/shorewall/interfaces:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">net
|
||||
eth0 ...</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">loc
|
||||
eth1 ...</span><br>
|
||||
<br>
|
||||
/etc/shorewall/hosts:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">vpn
|
||||
eth0:0.0.0.0/0 ipsec,...</span></li>
|
||||
</ol>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="2_2_0_RC4"></a>01/06/2005 -
|
||||
Shorewall 2.2.0 RC4<br>
|
||||
</span><br>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>A listing of loaded iptables kernel modules is now included in
|
||||
the output of "shorewall status".<br>
|
||||
<div style="margin-left: 40px;">Regardless of which technique you
|
||||
choose, you can specify additional SA options for the zone in the
|
||||
/etc/shorewall/ipsec entry.<br>
|
||||
<br>
|
||||
The OPTIONS, IN OPTIONS and OUT OPTIONS columns specify the
|
||||
input-output, input and output characteristics of the security
|
||||
associations to be used to decrypt (input) or encrypt (output) traffic
|
||||
to/from the zone.<br>
|
||||
<br>
|
||||
The available options are:<br>
|
||||
</div>
|
||||
<ul>
|
||||
<ul>
|
||||
<li>reqid[!]=<number> where <number> is specified using
|
||||
setkey(8) using the 'unique:<number>' option for the SPD level.</li>
|
||||
<li>spi[!]=<number> where <number> is the SPI of the
|
||||
SA. Since different SAs are used to encrypt and decrypt traffic, this
|
||||
option should only be listed in the IN OPTIONS and OUT OPTIONS columns.</li>
|
||||
<li>proto[!]=ah|esp|ipcomp</li>
|
||||
<li>mss=<number> (sets the MSS value in TCP SYN packets and
|
||||
is not related to policy matching)</li>
|
||||
<li>mode[!]=transport|tunnel</li>
|
||||
<li>tunnel-src[!]=<address>[/<mask>] (only available
|
||||
with mode=tunnel)</li>
|
||||
<li>tunnel-dst[!]=<address>[/<mask>] (only available
|
||||
with mode=tunnel). Because tunnel source and destination are dependent
|
||||
on the direction of the traffic, these options should only appear in
|
||||
the IN OPTIONS and OUT OPTIONS columns.</li>
|
||||
<li>strict (if specified, packets must match all policies;
|
||||
policies are delimited by 'next').</li>
|
||||
<li>next (only available with strict)</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<div style="margin-left: 40px;">Examples:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">#ZONE
|
||||
IPSEC OPTIONS
|
||||
|
||||
IN
|
||||
OUT</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">#
|
||||
ONLY
|
||||
|
||||
OPTIONS OPTIONS</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">vpn
|
||||
Yes mode=tunnel,proto=esp
|
||||
spi=1000 spi=1001</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">loc
|
||||
No reqid=44,mode=transport</span><br>
|
||||
<br>
|
||||
The /etc/shorewall/masq file has a new IPSEC column added. If you
|
||||
specify Yes or yes in that column then the unencrypted packets will
|
||||
have their source address changed. Otherwise, the unencrypted packets
|
||||
will not have their source addresses changed. This column may also
|
||||
contain a comma-separated list of the options specified above in which
|
||||
case only those packets that will be encrypted by an SA matching the
|
||||
given options will have their source address changed.<br>
|
||||
</div>
|
||||
<ol start="8">
|
||||
<li>To improve interoperability, tunnels of type 'ipsec' no longer
|
||||
enforce the use of source port 500 for ISAKMP and OpenVPN tunnels no
|
||||
longer enforce use of the specified port as both the source and
|
||||
destination ports.</li>
|
||||
<li>A new 'allowBcast' builtin action has been added -- it silently
|
||||
allows broadcasts and multicasts.</li>
|
||||
<li>The -c option in /sbin/shorewall commands is now deprecated. The
|
||||
commands where -c was previously allowed now permit you to specify a
|
||||
configuration directory after the command:<br>
|
||||
<br>
|
||||
shorewall check [
|
||||
<configuration-directory> ]<br>
|
||||
shorewall restart [
|
||||
<configuration-directory> ]<br>
|
||||
shorewall start [
|
||||
<configuration-directory> ]<br>
|
||||
<br>
|
||||
</li>
|
||||
</ol>
|
||||
Problems Corrected.<br>
|
||||
<ol>
|
||||
<li>Several problems associated with processing the IPSEC colummn in
|
||||
/etc/shorewall/masq have been corrected.<br>
|
||||
<li>Normally, when SNAT or MASQUERADE is applied to a tcp or udp
|
||||
connection, Netfilter attempts to retain the source port number. If it
|
||||
has to change to port number to avoid <source
|
||||
address>,<source port> conflicts, it tries to do so within
|
||||
port ranges ( < 512, 512-1023, and > 1023). You may now specify
|
||||
an explicit range of source ports to be used by following the address
|
||||
or address range (if any) in the ADDRESS column with ":" and a port
|
||||
range in the format <low-port>-<high-port>. You must
|
||||
specify either "tcp" or "udp" in the PROTO column.<br>
|
||||
<br>
|
||||
Examples 1 -- MASQUERADE with tcp source ports 4000-5000:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;"> #INTERFACE
|
||||
SUBNET
|
||||
ADDRESS PROTO</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth0 192.168.1.0/24
|
||||
:4000-5000 tcp</span><br
|
||||
style="font-family: monospace;">
|
||||
<br>
|
||||
Example 2 -- SNAT with udp source ports 7000-8000:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">#INTERFACE
|
||||
SUBNET
|
||||
ADDRESS
|
||||
|
||||
PROTO</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth0
|
||||
10.0.0.0/8
|
||||
192.0.2.44:7000-8000 udp<br>
|
||||
<br>
|
||||
</span></li>
|
||||
<li>You may now account by user/group ID for outbound traffic from
|
||||
the firewall itself with entries in /etc/shorewall/accounting. Such
|
||||
accounting rules must be placed in the OUTPUT chain. See the comments
|
||||
at the top of /etc/shorewall/accounting for details.</li>
|
||||
<li>Shorewall now verifies that your kernel and iptables have physdev
|
||||
match support if BRIDGING=Yes in shorewall.conf.</li>
|
||||
<li>Beginning with this release, if your kernel and iptables have
|
||||
iprange match support (see the output from "shorewall check"), then
|
||||
with the exception of the /etc/shorewall/netmap file, anywhere that a
|
||||
network address may appear an IP address range of the form <low
|
||||
address>-<high address> may also appear.</li>
|
||||
<li>Support has been added for the iptables CLASSIFY target. That
|
||||
target allows you to classify packets for traffic shaping directly
|
||||
rather than indirectly through fwmark. Simply enter the
|
||||
<major>:<minor> classification in the first column of
|
||||
/etc/shorewall/tcrules:<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">#MARK/
|
||||
SOURCE
|
||||
DEST PROTO PORT(S)</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">#CLASSIFY</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">1:30
|
||||
-
|
||||
eth0 tcp
|
||||
25</span><br>
|
||||
<br>
|
||||
Note that when using this form of rule, it is acceptable to include the
|
||||
name of an interface in the DEST column.<br>
|
||||
<br>
|
||||
Marking using the CLASSIFY target always occurs in the POSTROUTING
|
||||
chain of the mangle table and is not affected by the setting of
|
||||
MARK_IN_FORWARD_CHAIN in shorewall.conf.</li>
|
||||
<li>During "shorewall start", IP addresses to be added as a
|
||||
consequence of ADD_IP_ALIASES=Yes and ADD_SNAT_ALIASES=Yes are quietly
|
||||
deleted when /etc/shorewall/nat and /etc/shorewall/masq are processed
|
||||
then they are re-added later. This is done to help ensure that the
|
||||
addresses can be added with the specified labels but can have the
|
||||
undesirable side effect of causing routes to be quietly deleted. A new
|
||||
RETAIN_ALIASES option has been added to shorewall.conf; when this
|
||||
option is set to Yes, existing addresses will not be deleted.
|
||||
Regardless of the setting of RETAIN_ALIASES, addresses added during
|
||||
"shorewall start" are still deleted at a subsequent "shorewall stop" or
|
||||
"shorewall restart".</li>
|
||||
<li>Users with a large black list (from /etc/shorewall/blacklist) may
|
||||
want to set the new DELAYBLACKLISTLOAD option in shorewall.conf. When
|
||||
DELAYBLACKLISTLOAD=Yes, Shorewall will enable new connections before
|
||||
loading the blacklist rules. While this may allow connections from
|
||||
blacklisted hosts to slip by during construction of the blacklist, it
|
||||
can substantially reduce the time that all new connections are disabled
|
||||
during "shorewall [re]start".</li>
|
||||
<li>Using the default LOGFORMAT, chain names longer than 11
|
||||
characters (such as in user-defined actions) may result in log prefix
|
||||
truncation. A new shorewall.conf action LOGTAGONLY has been added
|
||||
to deal with this problem. When LOGTAGONLY=Yes, logging rules that
|
||||
specify a log tag will substitute the tag for the chain name in the log
|
||||
prefix.<br>
|
||||
<br>
|
||||
Example -- file /etc/shorewall/action.thisisaverylogactionname:<br>
|
||||
<br>
|
||||
Rule:<br>
|
||||
<br>
|
||||
<span
|
||||
style="font-family: monospace;">DROP:info:ftp
|
||||
0.0.0.0/0 0.0.0.0/0
|
||||
tcp 21</span><br>
|
||||
<br>
|
||||
Log prefix with LOGTAGONLY=No:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">Shorewall:thisisaverylongacti</span><br>
|
||||
<br>
|
||||
Log prefix with LOGTAGONLY=Yes:<br>
|
||||
<br>
|
||||
<span
|
||||
style="font-family: monospace;">Shorewall:ftp:DROP</span><br>
|
||||
<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="2_0_14"></a>01/03/2005 -
|
||||
Shorewall 2.0.14<br>
|
||||
</span><br>
|
||||
New Features:<br>
|
||||
<ol>
|
||||
<li>Shorewall now resets the 'accept_source_route' flag for all
|
||||
interfaces. If you wish to accept source routing on an interface, you
|
||||
must specify the new 'sourceroute' interface option in
|
||||
/etc/shorewall/interfaces.</li>
|
||||
<li>The default Drop and Reject actions now invoke the new standard
|
||||
action 'AllowICMPs'. This new action accepts critical ICMP types:<br>
|
||||
<br>
|
||||
Type 3 code 4 (fragmentation needed)<br>
|
||||
Type 11 (TTL
|
||||
exceeded)<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Explicit control over the kernel's Martian logging is now
|
||||
provided using the new 'logmartians' interface option. If you include
|
||||
'logmartians' in the interface option list then logging of Martian
|
||||
packets on will be enabled on the specified interface. If you wish to
|
||||
globally enable martian logging, you can set LOG_MARTIANS=Yes in
|
||||
shorewall.conf.</li>
|
||||
<li>You may now cause Shorewall to use the '--set-mss' option of the
|
||||
TCPMSS target. In other words, you can cause Shorewall to set the MSS
|
||||
field of SYN packets passing through the firewall to the value you
|
||||
specify. This feature extends the existing CLAMPMSS option in
|
||||
/etc/shorewall/shorewall.conf by allowing that option to have a numeric
|
||||
value as well as the values "Yes" and "No".<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
CLAMPMSS=1400<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Shorewall now includes support for the ipp2p match facility. This
|
||||
is a departure from my usual policy in that the ipp2p match facility is
|
||||
included in Patch-O-Matic-NG and is unlikely to ever be included in the
|
||||
kernel.org source tree. Questions about how to install the patch or how
|
||||
to build your kernel and/or iptables should not be posted on the
|
||||
Shorewall mailing lists.<br>
|
||||
<br>
|
||||
In the following files, the "PROTO" or "PROTOCOL" column may contain
|
||||
"ipp2p":<br>
|
||||
<br>
|
||||
/etc/shorewall/rules<br>
|
||||
/etc/shorewall/tcrules<br>
|
||||
/etc/shorewall/accounting<br>
|
||||
<br>
|
||||
When the PROTO or PROTOCOL column contains "ipp2p" then the DEST
|
||||
PORT(S) or PORT(S) column may contain a recognized ipp2p option; for a
|
||||
list of the options and their meaning, at a root prompt:<br>
|
||||
<br>
|
||||
iptables -m ipp2p --help<br>
|
||||
<br>
|
||||
You must not include the leading "--" on the option; Shorewall will
|
||||
supply those characters for you. If you do not include an option then
|
||||
"ipp2p" is assumed (Shorewall will generate "-m ipp2p --ipp2p").</li>
|
||||
<li>Shorewall now has support for the CONNMARK target from iptables.
|
||||
See the /etc/shorewall/tcrules file for details.</li>
|
||||
<li>A new debugging option LOGALLNEW has been added to
|
||||
shorewall.conf. When set to a log level, this option causes Shorewall
|
||||
to generaate a logging rule as the first rule in each builtin chain.<br>
|
||||
<br>
|
||||
- The table name is used as the chain name in the
|
||||
log prefix.<br>
|
||||
- The chain name is used as the target in the log
|
||||
prefix.<br>
|
||||
<br>
|
||||
Example: Using the default LOGFORMAT, the log prefix for logging from
|
||||
the nat table's PREROUTING chain is:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">Shorewall:nat:PREROUTING</span><br>
|
||||
<br>
|
||||
IMPORTANT: There is no rate limiting on these logging rules so use
|
||||
LOGALLNEW at your own risk; it may cause high CPU and disk utilization
|
||||
and you may not be able to control your firewall after you enable this
|
||||
option.<br>
|
||||
<br>
|
||||
DANGER: DO NOT USE THIS OPTION IF THE RESULTING LOG MESSAGES WILL BE
|
||||
SENT TO ANOTHER SYSTEM.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The SUBNET column in /etc/shorewall/rfc1918 has been renamed
|
||||
SUBNETS and it is now possible to specify a list of addresses in that
|
||||
column.</li>
|
||||
<li>The AllowNNTP action now also allows NNTP over SSL/TLS (NNTPS).</li>
|
||||
<li>For consistency, the CLIENT PORT(S) column in the tcrules file
|
||||
has been renamed SOURCE PORT(S).</li>
|
||||
<li>The contents of /proc/sys/net/ip4/icmp_echo_ignore_all is now
|
||||
shown in the output of "shorewall status".</li>
|
||||
<li>A new IPTABLES option has been added to shorewall.conf. IPTABLES
|
||||
can be used to designate the iptables executable to be used by
|
||||
Shorewall. If not specified, the iptables executable determined by the
|
||||
PATH setting is used.</li>
|
||||
<li>You can now use the "shorewall show zones" command to display the
|
||||
current contents of the zones. This is particularly useful if you use
|
||||
dynamic zones (DYNAMIC_ZONES=Yes in shorewall.conf).<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">ursa:/etc/shorewall
|
||||
# shorewall show zones</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
Shorewall-2.2.0-Beta7 Zones at ursa - Sat Nov 27 11:18:25 PST 2004</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> </span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> loc</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth0:192.168.1.0/24</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth1:1.2.3.4</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
net </span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth0:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> WiFi</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> sec</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
eth1:0.0.0.0/0</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> </span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
ursa:/etc/shorewall #</span><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>Variable expansion may now be used with the INCLUDE directive.<br>
|
||||
<br>
|
||||
Example:<br>
|
||||
<br>
|
||||
/etc/shorewall/params<br>
|
||||
<br>
|
||||
<span
|
||||
style="font-family: monospace;">FILE=/etc/foo/bar</span><br>
|
||||
<br>
|
||||
Any other config file:<br>
|
||||
<br>
|
||||
<span
|
||||
style="font-family: monospace;">INCLUDE $FILE</span><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The output of "shorewall status" now includes the results of "ip
|
||||
-stat link ls". This helps diagnose performance problems caused by link
|
||||
errors.</li>
|
||||
<li>Previously, when rate-limiting was specified in
|
||||
/etc/shorewall/policy (LIMIT:BURST column), any traffic which exceeded
|
||||
the specified rate was silently dropped. Now, if a log level is given
|
||||
in the entry (LEVEL column) then drops are logged at that level at a
|
||||
rate of 5/min with a burst of 5.<br>
|
||||
</li>
|
||||
</ol>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>A typo in the /etc/shorewall/interfaces file has been fixed.</li>
|
||||
<li>"bad variable" error messages occurring during "shorewall stop"
|
||||
and "shorewall clear" have been eliminated.</li>
|
||||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.
|
||||
The TYPE column for an IPIP tunnel should contain "ipip" rather than
|
||||
"ip".<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"><a name="MandrakeRPMS"></a>12/31/2004
|
||||
- Mandrake-specific RPMs available<br>
|
||||
<br>
|
||||
</span>Jack Coates has generously volunteered to provide Shorewall RPMs
|
||||
for use under Mandrake. You can download Jack's RPMs from <a
|
||||
target="_top" href="http://www.monkeynoodle.org/tmp/">http://www.monkeynoodle.org/tmp/</a><br>
|
||||
<br>
|
||||
<span style="font-weight: bold;"><a name="Redhat_Fedora"></a>12/31/2004
|
||||
- Redhat/Fedora-specific RPMs available<br>
|
||||
</span><br>
|
||||
Simon Matter has graciously volunteered to provide RPMs taylored for
|
||||
Redhat and Fedora. You can download Simon's RPMs from <a target="_top"
|
||||
href="http://www.invoca.ch/pub/packages/shorewall/">http://www.invoca.ch/pub/packages/shorewall/</a><br>
|
||||
<br>
|
||||
Thanks, Simon!<br>
|
||||
<br>
|
||||
<span style="font-weight: bold;"><a name="2_2_0_RC3"></a>12/30/2004 -
|
||||
Shorewall 2.2.0 RC3<br>
|
||||
</span><br>
|
||||
Problems Corrected:<br>
|
||||
<ol>
|
||||
<li>The following error message could appear during "shorewall stop"
|
||||
or "shorewall clear":<br>
|
||||
|
||||
rate of 5/min with a burst of 5.</li>
|
||||
<li>Recent 2.6 kernels include code that evaluates TCP packets based
|
||||
on TCP Window analysis. This can cause packets that were previously
|
||||
classified as NEW or ESTABLISHED to be classified as INVALID.<br>
|
||||
<br>
|
||||
|
||||
local: lo:: bad variable name<br>
|
||||
The new kernel code can be disabled by including this command in your
|
||||
/etc/shorewall/init file:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">echo 1 >
|
||||
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal</span><br>
|
||||
<br>
|
||||
Additional kernel logging about INVALID TCP packets may be obtained by
|
||||
adding this command to /etc/shorewall/init:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">echo 1 >
|
||||
/proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid</span><br>
|
||||
<br>
|
||||
Traditionally, Shorewall has dropped INVALID TCP packets early. The new
|
||||
DROPINVALID option allows INVALID packets to be passed through the
|
||||
normal rules chains by setting DROPINVALID=No.<br>
|
||||
<br>
|
||||
If not specified or if specified as empty (e.g., DROPINVALID="") then
|
||||
DROPINVALID=Yes is assumed.<br>
|
||||
<br>
|
||||
</li>
|
||||
<li>The rate limiting example in /etc/shorewall/rules has been
|
||||
changed to use the RATE LIMIT column.</li>
|
||||
<li>Entries in /etc/shorewall/masq with the INTERFACE column
|
||||
containing <ifname>:: (e.g., "eth0::") would generate a progress
|
||||
message but would not generate an iptables rule.</li>
|
||||
<li>A misleading typo in /etc/shorewall/tunnels has been corrected.<br>
|
||||
<li>The "shorewall add" and "shorewall delete" commands now accept a
|
||||
list of hosts to add or delete.<br>
|
||||
<br>
|
||||
Examples:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;"> shorewall add
|
||||
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> shorewall delete
|
||||
eth1:1.2.3.4 eth1:2.3.4.5 z12</span><br>
|
||||
<br>
|
||||
The above commands may also be written:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">shorewall add
|
||||
eth1:1.2.3.4,2.3.4.5 z12</span><br style="font-family: monospace;">
|
||||
<span style="font-family: monospace;"> shorewall delete
|
||||
eth1:1.2.3.4,2.3.4.5 z12</span><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>TCP OpenVPN tunnels are now supported using the 'openvpn' tunnel
|
||||
type. OpenVPN entries in /etc/shorewall/tunnels have this format:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">openvpn[:{tcp|udp}][:<port>]
|
||||
<zone> <gateway></span><br>
|
||||
<br>
|
||||
Examples:<br>
|
||||
<br>
|
||||
<span style="font-family: monospace;">openvpn:tcp
|
||||
net
|
||||
1.2.3.4 # TCP tunnel on port 1194</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
openvpn:3344 net
|
||||
1.2.3.4 # UDP on port 3344</span><br
|
||||
style="font-family: monospace;">
|
||||
<span style="font-family: monospace;">
|
||||
openvpn:tcp:4455 net
|
||||
1.2.3.4 # TCP on port 4455</span><br>
|
||||
<br>
|
||||
</li>
|
||||
<li>A new 'ipsecvpn' script is included in the tarball and in the
|
||||
RPM. The RPM installs the file in the Documentation directory
|
||||
(/usr/share/doc/packages/shorewall-2.2.0-0RC1).<br>
|
||||
<br>
|
||||
This script is intended for use on Roadwarrior laptops for establishing
|
||||
an IPSEC SA to/from remote networks. The script has some limitations:</li>
|
||||
</ol>
|
||||
<ul>
|
||||
<ul>
|
||||
<li>Only one instance of the script may be used at a time.</li>
|
||||
<li>Only the first SPD accessed will be instantiated at the remote
|
||||
gateway. So while the script creates SPDs to/from the remote gateway
|
||||
and each network listed in the NETWORKS setting at the front of the
|
||||
script, only one of these may be used at a time.</li>
|
||||
</ul>
|
||||
</ul>
|
||||
<ol start="39">
|
||||
<li>The output of "shorewall status" now lists the loaded netfilter
|
||||
kernel modules.</li>
|
||||
<li>The range of UDP ports opened by the AllowTrcrt action has been
|
||||
increased to 33434:33524.</li>
|
||||
<li>The IANA has recently registered port 1194 for use by OpenVPN. In
|
||||
previous versions of Shorewall (and OpenVPN), the default port was 5000
|
||||
but has been changed to 1194 to conform to the new OpenVPN default.<br>
|
||||
</li>
|
||||
</ol>
|
||||
<span style="font-weight: bold;"></span>
|
||||
<p><a href="News.htm">More News</a></p>
|
||||
<hr>
|
||||
<h2><a name="Leaf"></a>Leaf</h2>
|
||||
@ -297,6 +851,14 @@ message but would not generate an iptables rule.</li>
|
||||
LEAF is an open source project which provides a Firewall/router on a
|
||||
floppy, CD or CF. Several LEAF distributions including Bering and
|
||||
Bering-uClibc use Shorewall as their Netfilter configuration tool.</p>
|
||||
<hr style="width: 100%; height: 2px;">
|
||||
<h2><a name="OpenWRT"></a>OpenWRT</h2>
|
||||
<a href="http://openwrt.org"><img alt="(OpenWRT Logo)"
|
||||
src="images/openwrt.png"
|
||||
style="border: 0px solid ; width: 88px; height: 31px;" hspace="4"></a>OpenWRT
|
||||
is a project which provides open source firmware for Linksys WRT54G
|
||||
wireless routers. Two different Shorewall packages are available for
|
||||
OpenWRT.<br>
|
||||
<hr>
|
||||
<h2><a name="Donations"></a>Donations</h2>
|
||||
<p align="left"><a href="http://www.alz.org/" target="_top"><font
|
||||
|
||||
Loading…
Reference in New Issue
Block a user