mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-25 17:13:11 +01:00
1172 lines
46 KiB
XML
1172 lines
46 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<!-- $Id$ -->
|
|
<article id="upgrade_issues">
|
|
<articleinfo>
|
|
<title>Upgrade Issues</title>
|
|
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2002</year>
|
|
|
|
<year>2003</year>
|
|
|
|
<year>2004</year>
|
|
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<year>2007</year>
|
|
|
|
<year>2008</year>
|
|
|
|
<year>2009</year>
|
|
|
|
<year>2012</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
|
|
<holder/>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>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
|
|
<quote><ulink type="" url="copyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section id="Important">
|
|
<title>Important</title>
|
|
|
|
<para>It is important that you read all of the sections on this page where
|
|
the version number mentioned in the section title is later than what you
|
|
are currently running.</para>
|
|
|
|
<para>In the descriptions that follows, the term
|
|
<emphasis>group</emphasis> refers to a particular network or subnetwork
|
|
(which may be <literal>0.0.0.0/0</literal> or it may be a host address)
|
|
accessed through a particular interface.</para>
|
|
|
|
<para>Examples:</para>
|
|
|
|
<simplelist columns="1" type="vert">
|
|
<member><literal>eth0:0.0.0.0/0</literal></member>
|
|
|
|
<member><literal>eth2:192.168.1.0/24</literal></member>
|
|
|
|
<member><literal>eth3:192.0.2.123</literal></member>
|
|
</simplelist>
|
|
|
|
<para>You can use the <command moreinfo="none">shorewall show
|
|
zones</command> command to see the groups associated with each of your
|
|
zones.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Versions >= 4.5.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Shorewall, Shorewall6, Shorewall-lite and Shorewall6-lite now
|
|
depend on the new package Shorewall-core. If you use the Shorewall
|
|
installers, you must install Shorewall-core prior to installing or
|
|
upgrading any of the other packages.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The BLACKLIST section of the rules file has been eliminated. If
|
|
you have entries in that file section, you must move them to the
|
|
blrules file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This version of Shorewall requires the Digest::SHA1 Perl
|
|
module.</para>
|
|
|
|
<simplelist>
|
|
<member>Debian: libdigest-sha1-perl</member>
|
|
|
|
<member>Fedora: perl-Digest-SHA1</member>
|
|
|
|
<member>OpenSuSE: perl-Digest-SHA1</member>
|
|
</simplelist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The generated firewall script now maintains the
|
|
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING and
|
|
by LSM.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Versions >= 4.4.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If you are using Shorewall-perl, there are no additional upgrade
|
|
issues. If you are using Shorewall-shell or are upgrading from a
|
|
Shorewall version earlier than 4.0.0 then you will need to <ulink
|
|
url="Shorewall-perl.html">migrate to Shorewall-perl</ulink>.
|
|
Shorewall-4.3.5 and later only use the perl-based compiler.</para>
|
|
|
|
<para>If you have specified "SHOREWALL_COMPILER=shell" in
|
|
shorewall.conf, then you must either:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>change that specification to "SHOREWALL_COMPILER=perl";
|
|
or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>change that specification to "SHOREWALL_COMPILER=";
|
|
or</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>delete the specification altogether.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Failure to do so will result in the following
|
|
warning:<blockquote>
|
|
<para>WARNING: SHOREWALL_COMPILER=shell ignored. Support for
|
|
Shorwall-shell has been removed in this release.</para>
|
|
</blockquote></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The <command>shorewall stop</command>, <command>shorewall
|
|
clear</command>, <command>shorewall6 stop</command> and
|
|
<command>shorewall6 clear</command> commands no longer read the
|
|
<filename>routestopped</filename> file. The
|
|
<filename>routestopped</filename> file used is the one that was
|
|
present at the last <command>start</command>,
|
|
<command>restart</command> or <command>restore</command>
|
|
command.<important>
|
|
<para>If you modify the routestopped file, you must restart
|
|
Shorewall before the changes to that file will take effect.</para>
|
|
</important></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The old macro parameter syntax (e.g., SSH/ACCEPT) is now
|
|
deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.3
|
|
documentation uses the new syntax exclusively, although the old syntax
|
|
continues to be supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Support for the SAME target in /etc/shorewall/masq and
|
|
/etc/shorewall/rules has been removed, following the removal of the
|
|
underlying support in the Linux kernel.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Supplying an interface name in the SOURCE column of
|
|
/etc/shorewall/masq is now deprecated. Entering the name of an
|
|
interface there will result in a compile-time warning:</para>
|
|
|
|
<para>WARNING: Using an interface as the masq SOURCE requires the
|
|
interface to be up and configured when Shorewall
|
|
starts/restarts</para>
|
|
|
|
<para>To avoid this warning, replace interface names by the
|
|
corresponding netwok(s) in CIDR format (e.g.,
|
|
192.168.144.0/24).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Previously, Shorewall has treated traffic shaping class IDs as
|
|
decimal numbers (or pairs of decimal numbers). That worked fine until
|
|
IPMARK was implemented. IPMARK requires Shorewall to generate class
|
|
Ids in numeric sequence. In 4.3.9, that didn't work correctly because
|
|
Shorewall was generating the sequence "..8,9,10,11..." when the
|
|
correct sequence was "...8,9,a,b,...". Shorewall now treats class IDs
|
|
as hex, like 'tc' and 'iptables' do.</para>
|
|
|
|
<para>This should only be an issue if you have more than 9 interfaces
|
|
defined in <filename>/etc/shorewall/tcdevices</filename> and if you
|
|
use class IDs in <filename>/etc/shorewall/tcrules</filename>. You will
|
|
need to renumber the class IDs for devices 10 and greater.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Support for the 'norfc1918' interface and host option has been
|
|
removed. If 'norfc1918' is specified for an entry in either the
|
|
interfaces or the hosts file, a warning is issued and the option is
|
|
ignored. Simply remove the option to avoid the warning.</para>
|
|
|
|
<para>Similarly, if RFC1918_STRICT=Yes or a non-empty
|
|
RFC1918_LOG_LEVEL is given in shorewall.conf, a warning will be issued
|
|
and the option will be ignored.</para>
|
|
|
|
<para>You may simply delete the RFC1918-related options from your
|
|
shorewall.conf file if you are seeing warnings regarding them.</para>
|
|
|
|
<para>Users who currently use 'norfc1918' are encouraged to consider
|
|
using NULL_ROUTE_RFC1918=Yes instead.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The install.sh scripts in the Shorewall and Shorewall6 packages
|
|
no longer create a backup copy of the existing configuration. If you
|
|
want your configuration backed up prior to upgrading, you will need to
|
|
do that yourself. As part of this change, the fallback.sh scripts are
|
|
no longer released.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Previously, if an ipsec zone was defined as a sub-zone of an
|
|
ipv4 or ipv6 zone using the special <child>:<parent>,...
|
|
syntax, CONTINUE policies for the sub-zone did not work as expected.
|
|
Traffic that was not matched by a sub-zone rule was not compared
|
|
against the parent zone(s) rules. In 4.4.0, such traffic IS compared
|
|
against the parent zone rules.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name <emphasis role="bold">any</emphasis> is now reserved
|
|
and may not be used as a zone name.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Perl module initialization has changed in Shorewall 4.4.1.
|
|
Previously, each Shorewall Perl package would initialize its global
|
|
variables for IPv4 in an INIT block. Then, if the compilation turned
|
|
out to be for IPv6, Shorewall::Compiler::compiler() would reinitialize
|
|
them for IPv6.</para>
|
|
|
|
<para>Beginning in Shorewall 4.4.1, the modules do not initialize
|
|
themselves in an INIT block. So if you use Shorewall modules outside
|
|
of the Shorewall compilation environment, then you must explicitly
|
|
call the module's 'initialize' function after the module has been
|
|
loaded.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Checking for zone membership has been tighened up. Previously, a
|
|
zone could contain <interface>:0.0.0.0/0 along with other hosts;
|
|
now, if the zone has <interface>:0.0.0.0/0 (even with
|
|
exclusions), then it may have no additional members in <ulink
|
|
url="manpages/shorewall-hosts.html">/etc/shorewall/hosts</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>ADD_IP_ALIASES=No is now the setting in the released<ulink
|
|
url="manpages/shorewall.conf.html"> shorewall.conf</ulink> and in all
|
|
of the samples. This will not affect you during upgrade unless you
|
|
choose to replace your current shorewall.conf with the one from the
|
|
release (not recommended).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The names of interface configuration variables in generated
|
|
scripts have been changed to ensure uniqueness. These names now begin
|
|
with SW_. This change will only affect you if your extension scripts
|
|
are using one or more of these variables.</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>Old Variable Name</entry>
|
|
|
|
<entry>New Variable Name</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_address</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_ADDRESS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_BCASTS</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_BCASTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_ACASTS</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_CASTS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_GATEWAY</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_NETWORKS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_ADDRESSES</entry>
|
|
|
|
<entry>SW_<literal>iface</literal>_ADDRESSES</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_NETWORKS</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_NETWORKS</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>iface</replaceable>_MAC</entry>
|
|
|
|
<entry>SW_<replaceable>iface</replaceable>_MAC</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry><replaceable>provider</replaceable>_IS_USABLE</entry>
|
|
|
|
<entry>SW_<replaceable>provider</replaceable>_IS_USABLE</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>were <replaceable>iface</replaceable> is a capitalized interface
|
|
name (e.g., ETH0) and <replaceable>provider</replaceable> isthe
|
|
capitalized name of a provider.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If your <ulink
|
|
url="manpages/shorewall-params.html">/etc/shorewall/params</ulink> (or
|
|
<ulink
|
|
url="manpages6/shorewall6-params.html">/etc/shorewall6/params</ulink>)
|
|
file sends output to Standard Output, you need to be aware that the
|
|
output will be redirected to Standard Error beginning with Shorewall
|
|
4.4.16.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
|
|
deprecated. With EXPORTPARAMS=No, the variables set by <ulink
|
|
url="manpages/shorewall-params.html">/etc/shorewall/params</ulink>
|
|
(<ulink
|
|
url="manpages6/shorewall6-params.html">/etc/shorewall6/params</ulink>)
|
|
at compile time are now available in the compiled firewall
|
|
script.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The <command>iprange</command> and <command>ipaddr</command>
|
|
commands require the 'bc' utility.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and
|
|
HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS,
|
|
MASK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. See the <ulink
|
|
url="PacketMarking.html#Values">Packet Marking using
|
|
/etc/shorewall/tcrules</ulink> article. The <command>shorewall
|
|
update</command> (<command>shorewall6 update</command>) command will
|
|
automatically generate the correct values for these new options
|
|
depending on your settings of WIDE_TC_MARKS and
|
|
HIGH_ROUTE_MARKS.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Be sure to check the latest 4.4 Release Notes linked from the <ulink
|
|
url="index.htm">home page</ulink>.</para>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Versions >= 4.2.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed
|
|
non-zero mark values < 256 to be assigned in the OUTPUT chain. This
|
|
has been changed so that only high mark values may be assigned there.
|
|
Packet marking rules for traffic shaping of packets originating on the
|
|
firewall must be coded in the POSTROUTING table.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Previously, Shorewall did not range-check the value of the
|
|
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2: a) A
|
|
VERBOSITY setting outside the range -1 through 2 is rejected. b) After
|
|
the -v and -q options are applied, the resulting value is adjusted to
|
|
fall within the range -1 through 2.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Specifying a destination zone in a NAT-only rule now generates a
|
|
warning and the destination zone is ignored. NAT-only rules
|
|
are:<simplelist>
|
|
<member>NONAT</member>
|
|
|
|
<member>REDIRECT-</member>
|
|
|
|
<member>DNAT-</member>
|
|
</simplelist></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The default value for LOG_MARTIANS has been changed. Previously,
|
|
the defaults were: Shorewall-perl - 'Off' Shorewall-shell - 'No' The
|
|
new default values are:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Shorewall-perl</term>
|
|
|
|
<listitem>
|
|
<para>'On.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term>Shorewall-shell</term>
|
|
|
|
<listitem>
|
|
<para>'Yes'</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Shorewall-perl users may:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Accept the new default -- martians will be logged from all
|
|
interfaces with route filtering except those with log_martians=0
|
|
in /etc/shorewall/interfaces.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Explicitly set LOG_MARTIANS=Off to maintain compatibility
|
|
with prior versions of Shorewall.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>Shorewall-shell users may:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Accept the new default -- martians will be logged from all
|
|
interfaces with the route filtering enabled.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Explicitly set LOG_MARTIANS=No to maintain compatibility
|
|
with prior versions of Shorewall.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The value of IMPLICIT_CONTINUE in shorewall.conf (and samples)
|
|
has been changed from Yes to No. If you are a Debian or Ubuntu user
|
|
and you select replacement of shorewall.conf during upgrade to
|
|
Shorewall 4.2, you will want to change IMPLICIT_CONTINUE back to 'Yes'
|
|
if you have nested zones that rely on IMPLICIT_CONTINUE=Yes for proper
|
|
operation.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 'norfc1918' option is deprecated. Use explicit rules
|
|
instead. Note that there is a new 'Rfc1918' macro that acts on
|
|
addresses reserved by RFC 1918.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use
|
|
ipset-based zones instead.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V4.0.0">
|
|
<title>Versions >= 4.0.0-Beta7</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Beginning with Shorewall 4.0.0, there is no single 'shorewall'
|
|
package. Rather there are two compiler packages (shorewall-shell and
|
|
shorewall-perl) and a set of base files (shorewall-common) required by
|
|
either compiler package.</para>
|
|
|
|
<para>Although the names of the packages are changing, you can upgrade
|
|
without having to uninstall/reinstall.</para>
|
|
|
|
<para>To repeat: <emphasis role="bold">You do not need to uninstall
|
|
any existing package.</emphasis></para>
|
|
|
|
<para>If you attempt to upgrade using the shorewall-common RPM, you
|
|
get this result:<programlisting>gateway:~ # <command>rpm -Uvh shorewall-common-4.0.0.noarch.rpm </command>
|
|
error: Failed dependencies:
|
|
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
|
|
gateway:~ #</programlisting>You must either:<programlisting><command>rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm</command></programlisting>or<programlisting><command>rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm</command></programlisting>If
|
|
you don't want shorewall-shell, you must use the second command
|
|
(installing both shorewall-shell and shorewall-perl) then remove
|
|
shorewall-shell using this command:<programlisting><command>rpm -e shorewall-shell</command></programlisting>If
|
|
you are upgrading using the tarball, you must install shorewall-shell
|
|
and/or shorewall-perl before you upgrade using shorewall-common.
|
|
Otherwise, the install.sh script fails with:<simplelist>
|
|
<member>ERROR: No Shorewall compiler is installed</member>
|
|
</simplelist>The shorewall-shell and shorewall-perl packages are
|
|
installed from the tarball in the expected way; untar the package, and
|
|
run the install.sh script.</para>
|
|
|
|
<para>Example 1: You have 'shorewall' installed and you want to
|
|
continue to use the shorewall-shell compiler.<programlisting><command>tar -jxf shorewall-common-4.0.0.tar.bz2
|
|
tar -jxf shorewall-shell-4.0.0.tar.bz2
|
|
|
|
pushd shorewall-shell-4.0.0
|
|
./install.sh
|
|
popd
|
|
pushd shorewall-common-4.0.0
|
|
./install.sh
|
|
shorewall check
|
|
shorewall restart</command></programlisting>Example 2: You have shorewall
|
|
3.4.4 and shorewall-perl 4.0.0-Beta7 installed and you want to upgrade
|
|
to 4.0. You do not need the shell-based compiler.<programlisting><command>tar -jxf shorewall-common-4.0.0.tar.bz2
|
|
tar -jxf shorewall-perl-4.0.0.tar.bz2
|
|
|
|
pushd shorewall-perl-4.0.0
|
|
./install.sh
|
|
popd
|
|
pushd /shorewall-common-4.0.0
|
|
./install.sh
|
|
shorewall check
|
|
shorewall restart</command></programlisting> The RPMs are set up so that if
|
|
you upgrade an existing Shorewall installation as part of a
|
|
distribution upgrade and you have not already installed
|
|
shorewall-perl, then you will end up with Shorewall-common and
|
|
Shorewall-shell installed.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work
|
|
slightly differently in Shorewall 4.0.0. In prior releases, leaving
|
|
these options empty was equivalent to setting them to 'No' which
|
|
caused the corresponding flag in /proc to be reset for all interfaces.
|
|
Beginning in Shorewall 4.0.0, leaving these options empty causes
|
|
Shorewall to leave the flags in /proc as they are. You must set the
|
|
option to 'No' in order to obtain the old behavior.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The <option>:noah</option> option is now the default for ipsec
|
|
tunnels. Tunnels that use AH (protocol 51) must specify
|
|
<option>ipsec:ah</option> in the TYPE column.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Users upgrading from Debian Etch (Shorewall 3.2.6) to Debian
|
|
Lenny (Shoreall 4.0.15) report finding an issue with VOIP (Asterisk)
|
|
traffic. See <ulink url="FAQ.htm#faq77">Shorewall FAQ 77</ulink> for
|
|
details.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.4.0">
|
|
<title>Versions >= 3.4.0-Beta1</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Shorewall supports the notion of "default actions". A default
|
|
action defines a set of rules that are applied before a policy is
|
|
enforced. Default actions accomplish two goals:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Relieve log congestion. Default actions typically include
|
|
rules to silently drop or reject traffic that would otherwise be
|
|
logged when the policy is enforced.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Insure correct operation. Default actions can also avoid
|
|
common pitfalls like dropping connection requests on TCP port 113.
|
|
If these connections are dropped (rather than rejected) then you
|
|
may encounter problems connecting to Internet services that
|
|
utilize the AUTH protocol of client authentication.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>In prior Shorewall versions, default actions (action.Drop and
|
|
action.Reject) were defined for DROP and REJECT policies in
|
|
<filename>/usr/share/shorewall/actions.std</filename>. These could be
|
|
overridden in <filename>/etc/shorewall/actions</filename>.</para>
|
|
|
|
<para>This approach has two drawbacks:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>All DROP policies must use the same default action and all
|
|
REJECT policies must use the same default action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Now that we have <ulink
|
|
url="Modularization.html">modularized action processing</ulink>,
|
|
we need a way to define default rules for a policy that does not
|
|
involve actions.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you have not overridden the defaults using entries in
|
|
<filename>/etc/shorewall/actions</filename> then you need make no
|
|
changes to migrate to Shorewall version 3.4. If you have overridden
|
|
either of these entries, then please read on.</para>
|
|
|
|
<para>The change in version 3.4 is two-fold:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Four new options have been added to the
|
|
<filename>/etc/shorewall/shorewall.conf</filename> file that allow
|
|
specifying the default action for DROP, REJECT, ACCEPT and
|
|
QUEUE.</para>
|
|
|
|
<para>The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT
|
|
and QUEUE_DEFAULT.</para>
|
|
|
|
<para>DROP_DEFAULT describes the rules to be applied before a
|
|
connection request is dropped by a DROP policy; REJECT_DEFAULT
|
|
describes the rules to be applied if a connection request is
|
|
rejected by a REJECT policy. The other two are similar for ACCEPT
|
|
and QUEUE policies. The value assigned to these may be:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The name of an action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of a macro.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>'None' or 'none'</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>The default values are:</para>
|
|
|
|
<simplelist>
|
|
<member>DROP_DEFAULT="Drop"</member>
|
|
|
|
<member>REJECT_DEFAULT="Reject"</member>
|
|
|
|
<member>ACCEPT_DEFAULT=none</member>
|
|
|
|
<member>QUEUE_DEFAULT=none</member>
|
|
</simplelist>
|
|
|
|
<para>If USE_ACTIONS=Yes, then these values refer to action.Drop
|
|
and action.Reject respectively. If USE_ACTIONS=No, then these
|
|
values refer to macro.Drop and macro.Reject.</para>
|
|
|
|
<para>If you set the value of either option to "None" then no
|
|
default action will be used and the default action or macro (if
|
|
any) must be specified in
|
|
<filename>/etc/shorewall/policy</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The POLICY column in /etc/shorewall/policy has been
|
|
extended.</para>
|
|
|
|
<para>In <filename>/etc/shorewall/policy</filename>, when the
|
|
POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be
|
|
followed by ":" and one of the following:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>The word "None" or "none". This causes any default
|
|
action defined in
|
|
<filename>/etc/shorewall/shorewall.conf</filename> to be
|
|
omitted for this policy.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of an action (requires that USE_ACTIONS=Yes in
|
|
<filename>shorewall.conf</filename>). That action will be
|
|
invoked before the policy is enforced.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The name of a macro. The rules in that macro will be
|
|
applied before the policy is enforced. This does not require
|
|
USE_ACTIONS=Yes.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Example:</para>
|
|
|
|
<programlisting>#SOURCE DEST POLICY LOG
|
|
# LEVEL
|
|
loc net ACCEPT
|
|
net all DROP:MyDrop info
|
|
#
|
|
# THE FOLLOWING POLICY MUST BE LAST
|
|
#
|
|
all all REJECT:MyReject info</programlisting>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 'Limit' action is now a builtin. If you have 'Limit' listed
|
|
in <filename>/etc/shorewall/actions</filename>, remove the entry. Also
|
|
remove the files <filename>/etc/shorewall/action.Limit</filename>
|
|
and/or <filename>/etc/shorewall/Limit</filename> if you have
|
|
them.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This issue only applies if you have entries in
|
|
<filename>/etc/shorewall/providers</filename>.</para>
|
|
|
|
<para>Previously, Shorewall has not attempted to undo the changes it
|
|
has made to the firewall's routing as a result of entries in
|
|
<filename>/etc/shorewall/providers</filename> and
|
|
<filename>/etc/shorewall/routes</filename>. Beginning with this
|
|
release, Shorewall will attempt to undo these changes. This change can
|
|
present a migration issue in that the initial routing configuration
|
|
when this version of Shorewall is installed has probably been changed
|
|
by Shorewall already. Hence, when Shorewall restores the original
|
|
configuration, it will be installing a configuration that the
|
|
previously-installed version has already modified.</para>
|
|
|
|
<para>The steps to correcting this after you have installed version
|
|
3.4 or later of Shorewall are as follows:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para><command>shorewall[-lite] stop</command></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Remove the files
|
|
<filename>/var/lib/shorewall[-lite]/default_route</filename> and
|
|
<filename>/var/lib/shorewall[-lite]/undo_routing</filename> if
|
|
they exist.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Either restart networking or reboot.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>shorewall[-lite] start</command></para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>This issue only applies if you run Shorewall Lite.</para>
|
|
|
|
<para>The <filename>/etc/shorewall-lite/shorewall.conf</filename> file
|
|
has been renamed
|
|
<filename>/etc/shorewall-lite/shorewall-lite.conf</filename>. When you
|
|
upgrade, your <filename>shorewall.conf</filename> file will be renamed
|
|
<filename>shorewall-lite.conf</filename>.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.2.0">
|
|
<title>Version >= 3.2.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>If you are upgrading from version 2.4 or earlier, please read
|
|
the 3.0.0 upgrade considerations below.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A number of macros have been split into two. The macros affected
|
|
are:</para>
|
|
|
|
<simplelist>
|
|
<member>IMAP</member>
|
|
|
|
<member>LDAP</member>
|
|
|
|
<member>NNTP</member>
|
|
|
|
<member>POP3</member>
|
|
|
|
<member>SMTP</member>
|
|
</simplelist>
|
|
|
|
<para>Each of these macros now handles only traffic on the native
|
|
(plaintext) port. There is a corresponding macro with S added to the
|
|
end of the name for the SSL version of the same protocol. Thus each
|
|
macro results in the insertion of only one port per invocation. The
|
|
Web macro has not been split, but two new macros, HTTP and HTTPS have
|
|
been created. The Web macro is deprecated in favour of these new
|
|
macros, and may be removed from future Shorewall releases.</para>
|
|
|
|
<para>These changes have been made to ensure no unexpected ports are
|
|
opened due to the use of macros.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In previous Shorewall releases, DNAT and REDIRECT rules
|
|
supported a special syntax for exclusion of a subnet from the effect
|
|
of the rule.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<blockquote>
|
|
<para>Z2 is a subzone of Z1:</para>
|
|
|
|
<programlisting>DNAT Z1!Z2 loc:192.168.1.4 ...</programlisting>
|
|
</blockquote>
|
|
|
|
<para>That feature has never worked correctly when Z2 is a dynamic
|
|
zone. Furthermore, now that Shorewall supports exclusion lists, the
|
|
capability is redundant since the above rule can now be written in the
|
|
form:</para>
|
|
|
|
<programlisting>DNAT Z1:!<list of exclusions> loc:192.168.1.4 ...</programlisting>
|
|
|
|
<para>Beginning with Shorewall 3.2.0, the special exclusion syntax
|
|
will no longer be supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Important if you use the QUEUE target.</para>
|
|
|
|
<para>In the /etc/shorewall/rules file and in actions, you may now
|
|
specify 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to
|
|
'tcp' but also requires that the SYN flag is set and the RST, FIN and
|
|
ACK flags be off ("--syn" is added to the iptables rule).</para>
|
|
|
|
<para>As part of this change, Shorewall no longer adds the "--syn"
|
|
option to TCP rules that specify QUEUE as their target.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Extension Scripts may require change</para>
|
|
|
|
<para>In previous releases, extension scripts were executed during
|
|
<command>[re]start</command> by using the Bourne Shell "." operator.
|
|
In addition to executing commands during <command>[re]start</command>,
|
|
these scripts had to "save" the commands to be executed during
|
|
<command>shorewall restore</command>.</para>
|
|
|
|
<para>This clumsiness has been eliminated in Shorewall 3.2. In
|
|
Shorewall 3.2, extension scripts are copied in-line into the compiled
|
|
program and are executed in-line during <command>start</command>,
|
|
<command>restart</command> and <command>restore</command>. This
|
|
applies to all extension scripts except those associated with a chain
|
|
or action -- those extension scripts continue to be processed at
|
|
compile time.</para>
|
|
|
|
<para>This new approach has two implications for existing
|
|
scripts.</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>It is no longer necessary to save the commands; so functions
|
|
like 'save_command', 'run_and_save_command' and
|
|
'ensure_and_save_command' need no longer be called. The generated
|
|
program will contain functions with these names:</para>
|
|
|
|
<simplelist>
|
|
<member>save_command() - does nothing</member>
|
|
|
|
<member>run_and_save_command() - runs the passed
|
|
command</member>
|
|
|
|
<member>ensure_and_save_command() - runs the passed command and
|
|
stops the firewall if the command fails.</member>
|
|
</simplelist>
|
|
|
|
<para>These functions should provide for transparent migration of
|
|
scripts that use them until you can get around to eliminating
|
|
their use completely.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When the extension script is copied into the compiled
|
|
program, it is indented to line up with the surrounding code. If
|
|
you have 'awk' installed on your system, the Shorewall compiler
|
|
will correctly handle line continuation (last character on the
|
|
line = "\"). If you do not have awk, it will not be possible to
|
|
use line-continuation in your extension scripts. In no case is it
|
|
possible to continue a quoted string over multiple lines without
|
|
having additional whitespace inserted into the string.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Beginning with this release, the way in which packet marking in
|
|
the PREROUTING chain interacts with the 'track' option in
|
|
/etc/shorewall/providers has changed in two ways:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para>Packets arriving on a tracked interface are now passed to
|
|
the PREROUTING marking chain so that they may be marked with a
|
|
mark other than the 'track' mark (the connection still retains the
|
|
'track' mark).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on
|
|
packets in the PREROUTING chain (i.e., you can specify a mark
|
|
value of zero).</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Kernel version 2.6.16 introduces 'xtables', a new common packet
|
|
filtering and connection tracking facility that supports both IPv4 and
|
|
IPv6. Because a different set of kernel modules must be loaded for
|
|
xtables, Shorewall now includes two 'modules' files:</para>
|
|
|
|
<orderedlist numeration="loweralpha">
|
|
<listitem>
|
|
<para><filename>/usr/share/shorewall/modules</filename> -- the
|
|
former <filename>/etc/shorewall/modules</filename></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>/usr/share/shorewall/xmodules -- a new file that support
|
|
xtables.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If you wish to use the new file, then simply execute this
|
|
command:</para>
|
|
|
|
<para><command>cp -f /usr/share/shorewall/xmodules
|
|
/etc/shorewall/modules</command></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(<emphasis role="bold">Versions >= 3.2.3</emphasis>)
|
|
Previously, CLASSIFY tcrules were always processed out of the
|
|
POSTROUTING chain. Beginning with this release, they are processed out
|
|
of the POSTROUTING chain *except* when the SOURCE is
|
|
$FW[:<address>] in which case the rule is processed out of the
|
|
OUTPUT chain.</para>
|
|
|
|
<para>With correctly-coded rulesets, this change should have no
|
|
effect. Users having incorrectly-coded tcrules may need to change
|
|
them.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#MARK/ SOURCE DEST PROTO DEST SOURCE
|
|
#CLASSIFY PORTS(S) PORT(S)
|
|
1:110 $FW eth3 tcp - 22</programlisting>
|
|
</blockquote>
|
|
|
|
<para>While the user may have expected this rule to only affect
|
|
traffic from the firewall itself, the rule was really equivalent to
|
|
this one:</para>
|
|
|
|
<blockquote>
|
|
<programlisting>#MARK/ SOURCE DEST PROTO DEST SOURCE
|
|
#CLASSIFY PORTS(S) PORT(S)
|
|
1:110 0.0.0.0/0 eth3 tcp - 22</programlisting>
|
|
</blockquote>
|
|
|
|
<para>So after this change, the second rule will be required rather
|
|
than the first if that is what was really wanted.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V3.0.0">
|
|
<title>Version >= 3.0.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>The "monitor" command has been eliminated.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones
|
|
file have been removed and have been replaced by the former columns of
|
|
the /etc/shorewall/ipsec file. The latter file has been
|
|
removed.</para>
|
|
|
|
<para>Additionally the FW option in shorewall.conf has been deprecated
|
|
and is no longer set to 'fw' by default. New users are expected to
|
|
define the firewall zone in /etc/shorewall/zones.</para>
|
|
|
|
<para>Adhering to the principle of least astonishment, the old
|
|
<filename>/etc/shorewall/ipsec</filename> file will continue to be
|
|
supported. A new IPSECFILE variable in /etc/shorewall/shorewall.conf
|
|
determines the name of the file that Shorewall looks in for IPSEC
|
|
information. If that variable is not set or is set to the empty value
|
|
then IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do
|
|
something idiotic like replace your current shorewall.conf file with
|
|
the new one, your old configuration will continue to work. A dummy
|
|
'ipsec' file is included in the release so that your package manager
|
|
(e.g., rpm) won't remove your existing file.</para>
|
|
|
|
<para>The shorewall.conf file included in this release sets
|
|
IPSECFILE=zones so that new users are expected to use the <ulink
|
|
url="manpages/shorewall-zones.html">new zone file
|
|
format</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The DROPINVALID option has been removed from shorewall.conf. The
|
|
behavior will be as if DROPINVALID=No had been specified. If you wish
|
|
to drop invalid state packets, use the dropInvalid built-in
|
|
action.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The 'nobogons' interface and hosts option as well as the
|
|
BOGON_LOG_LEVEL option have been eliminated.</para>
|
|
</listitem>
|
|
|
|
<listitem id="MAPOLDACTIONS">
|
|
<para>Most of the standard actions have been replaced by parameterized
|
|
macros (see below). So for example, the action.AllowSMTP and
|
|
action.DropSMTP have been removed an a parameterized macro macro.SMTP
|
|
has been added to replace them.</para>
|
|
|
|
<para>In order that current users don't have to immediately update
|
|
their rules and user-defined actions, Shorewall can substitute an
|
|
invocation of the a new macro for an existing invocation of one of the
|
|
old actions. So if your rules file calls AllowSMTP, Shorewall will
|
|
replace that call with SMTP(ACCEPT). Because this substitution is
|
|
expensive, it is conditional based on the setting of MAPOLDACTIONS in
|
|
shorewall.conf. If this option is set to YES or if it is not set (such
|
|
as if you are using your old shorewall.conf file) then Shorewall will
|
|
perform the substitution. Once you have converted to use the new
|
|
macros, you can set MAPOLDACTIONS=No and invocations of those actions
|
|
will go much quicker during 'shorewall [re]start'.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The STATEDIR variable in /etc/shorewall/shorewall.conf has been
|
|
removed. STATEDIR is now fixed at /var/lib/shorewall. If you have
|
|
previously set STATEDIR to another directory, please copy the files
|
|
from that directory to /var/lib/shorewall/ before [re]starting
|
|
Shorewall after the upgrade to this version.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "shorewall status" command now just gives the status of
|
|
Shorewall (started or not-started). The previous status command has
|
|
been renamed "dump". The command also shows the state relative to the
|
|
state diagram at <ulink
|
|
url="http://shorewall.net/starting_and_stopping_shorewall.htm">http://shorewall.net/starting_and_stopping_shorewall.htm</ulink>.
|
|
In addition to the state, the time and date at which that state was
|
|
entered is shown.</para>
|
|
|
|
<para>Note that at least one "shorewall [re]start" must be issued
|
|
after upgrading to this release before "shorewall status" will show
|
|
anything but "Unknown" for the state.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The "shorewall forget" command now removes the dynamic blacklist
|
|
save file (/var/lib/shorewall/save).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>In previous versions of Shorewall, the rules generated by
|
|
entries in <filename>/etc/shorewall/tunnels</filename> preceded those
|
|
rules generated by entries in
|
|
<filename>/etc/shorewall/rules</filename>. Beginning with this
|
|
release, the rules generated by entries in the tunnels file will
|
|
appear *AFTER* the rules generated by the rules file. This may cause
|
|
you problems if you have REJECT, DENY or CONTINUE rules in your rules
|
|
file that would cause the tunnel transport packets to not reach the
|
|
rules that ACCEPT them. See <ulink
|
|
url="http://www.shorewall.net/VPNBasics.html">http://www.shorewall.net/VPNBasics.html</ulink>
|
|
for information on the rules generated by entries in the tunnels
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have
|
|
been removed as have the 'newnotsyn' options in
|
|
<filename>/etc/shorewall/interfaces</filename> and
|
|
<filename>/etc/shorewall/hosts</filename>.</para>
|
|
|
|
<para>TCP new-not-syn packets may be blocked using the 'dropNotSyn' or
|
|
'rejNotSyn' built-in actions.</para>
|
|
|
|
<para>Example: Reject all new-not-syn packets from the net and log
|
|
them at the 'info' level.</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO
|
|
SECTION NEW
|
|
rejNotSyn:info net all tcp</programlisting>
|
|
|
|
<para>Note that the rule is added at the front of the NEW section of
|
|
the rules file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A new TC_SCRIPT option replaces TC_ENABLED in shorewall.conf. If
|
|
the option is not set then the internal shaper (tc4shorewall by Arne
|
|
Bernin) is used. Otherwise, the script named in the variable is
|
|
used.</para>
|
|
|
|
<para>Users who currently use an
|
|
<filename>/etc/shorewall/tcstart</filename> file and wish to continue
|
|
to do so should set TC_SCRIPT=/etc/shorewall/tcstart in
|
|
shorewall.conf.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
|
|
<section id="V2.4.0">
|
|
<title>Version >= 2.4.0</title>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Shorewall now enforces the restriction that mark values used in
|
|
<filename> /etc/shorewall/tcrules</filename> are less than 256. If you
|
|
are using mark values >= 256, you must change your configuration
|
|
before you upgrade.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The value "ipp2p" is no longer accepted in the PROTO column of
|
|
the <filename>/etc/shorewall/rules</filename> file. This support has
|
|
never worked as intended and cannot be made to work in a consistent
|
|
way. A "Howto" article on filtering P2P with Shorewall and ipp2p will
|
|
be forthcoming.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>LEAF/Bering packages for 2.4.0 and later releases are not
|
|
available from shorewall.net. See the <ulink
|
|
url="http://leaf.sourceforge.net">LEAF site</ulink> for those
|
|
packages.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
</section>
|
|
</article>
|