<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Upgrade Issues</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="upgrade_issues"></a>Upgrade Issues</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div><div><p class="copyright">Copyright © 2002, 2003, 2004, 2005, 2006, 2007 Thomas M. Eastep, </p></div><div><div class="legalnotice"><a id="id279479"></a><p>Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. A copy of the license is included in the section entitled “<span class="quote"><a class="ulink" href="copyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Important">Important</a></span></dt><dt><span class="section"><a href="#V4.0.0">Versions >= 4.0.0-Beta7</a></span></dt><dt><span class="section"><a href="#V3.4.0">Versions >= 3.4.0-Beta1</a></span></dt><dt><span class="section"><a href="#V3.2.0">Version >= 3.2.0</a></span></dt><dt><span class="section"><a href="#V3.0.0">Version >= 3.0.0</a></span></dt><dt><span class="section"><a href="#V2.4.0">Version >= 2.4.0</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Important"></a>Important</h2></div></div></div><p>It is important that you read all of the sections on this page where the version number mentioned in the section title is later than what you are currently running.</p><p>In the descriptions that follows, the term <span class="emphasis"><em>group</em></span> refers to a particular network or subnetwork (which may be <code class="literal">0.0.0.0/0</code> or it may be a host address) accessed through a particular interface.</p><p>Examples:</p><table class="simplelist" border="0" summary="Simple list"><tr><td><code class="literal">eth0:0.0.0.0/0</code></td></tr><tr><td><code class="literal">eth2:192.168.1.0/24</code></td></tr><tr><td><code class="literal">eth3:192.0.2.123</code></td></tr></table><p>You can use the <span class="command"><strong>shorewall check</strong></span> command to see the groups associated with each of your zones.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="V4.0.0"></a>Versions >= 4.0.0-Beta7</h2></div></div></div><div class="orderedlist"><ol type="1"><li><p>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.</p><p>Although the names of the packages are changing, you can upgrade without having to uninstall/reinstall.</p><p>To repeat: <span class="bold"><strong>You do not need to uninstall any existing package.</strong></span></p><p>If you attempt to upgrade using the shorewall-common RPM, you get this result:</p><pre class="programlisting">gateway:~ # <span class="command"><strong>rpm -Uvh shorewall-common-4.0.0.noarch.rpm </strong></span> error: Failed dependencies: shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch gateway:~ #</pre><p>You must either:</p><pre class="programlisting"><span class="command"><strong>rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm</strong></span></pre><p>or</p><pre class="programlisting"><span class="command"><strong>rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpm</strong></span></pre><p>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:</p><pre class="programlisting"><span class="command"><strong>rpm -e shorewall-shell</strong></span></pre><p>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:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>ERROR: No Shorewall compiler is installed</td></tr></table><p>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.</p><p>Example 1: You have 'shorewall' installed and you want to continue to use the shorewall-shell compiler.</p><pre class="programlisting"><span class="command"><strong>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</strong></span></pre><p>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.</p><pre class="programlisting"><span class="command"><strong>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</strong></span></pre><p> 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.</p></li><li><p>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.</p></li><li><p>The <code class="option">:noah</code> option is now the default for ipsec tunnels. Tunnels that use AH (protocol 51) must specify <code class="option">ipsec:ah</code> in the TYPE column.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="V3.4.0"></a>Versions >= 3.4.0-Beta1</h2></div></div></div><div class="orderedlist"><ol type="1"><li><p>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:</p><div class="orderedlist"><ol type="a"><li><p>Relieve log congestion. Default actions typically include rules to silently drop or reject traffic that would otherwise be logged when the policy is enforced.</p></li><li><p>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.</p></li></ol></div><p>In prior Shorewall versions, default actions (action.Drop and action.Reject) were defined for DROP and REJECT policies in <code class="filename">/usr/share/shorewall/actions.std</code>. These could be overridden in <code class="filename">/etc/shorewall/actions</code>.</p><p>This approach has two drawbacks:</p><div class="orderedlist"><ol type="a"><li><p>All DROP policies must use the same default action and all REJECT policies must use the same default action.</p></li><li><p>Now that we have <a class="ulink" href="Modularization.html" target="_self">modularized action processing</a>, we need a way to define default rules for a policy that does not involve actions.</p></li></ol></div><p>If you have not overridden the defaults using entries in <code class="filename">/etc/shorewall/actions</code> 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.</p><p>The change in version 3.4 is two-fold:</p><div class="itemizedlist"><ul type="disc"><li><p>Four new options have been added to the <code class="filename">/etc/shorewall/shorewall.conf</code> file that allow specifying the default action for DROP, REJECT, ACCEPT and QUEUE.</p><p>The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT and QUEUE_DEFAULT.</p><p>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:</p><div class="orderedlist"><ol type="a"><li><p>The name of an action.</p></li><li><p>The name of a macro.</p></li><li><p>'None' or 'none'</p></li></ol></div><p>The default values are:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>DROP_DEFAULT="Drop"</td></tr><tr><td>REJECT_DEFAULT="Reject"</td></tr><tr><td>ACCEPT_DEFAULT=none</td></tr><tr><td>QUEUE_DEFAULT=none</td></tr></table><p>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.</p><p>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 <code class="filename">/etc/shorewall/policy</code>.</p></li><li><p>The POLICY column in /etc/shorewall/policy has been extended.</p><p>In <code class="filename">/etc/shorewall/policy</code>, when the POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be followed by ":" and one of the following:</p><div class="orderedlist"><ol type="a"><li><p>The word "None" or "none". This causes any default action defined in <code class="filename">/etc/shorewall/shorewall.conf</code> to be omitted for this policy.</p></li><li><p>The name of an action (requires that USE_ACTIONS=Yes in <code class="filename">shorewall.conf</code>). That action will be invoked before the policy is enforced.</p></li><li><p>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.</p></li></ol></div></li></ul></div><p>Example:</p><pre class="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</pre></li><li><p>The 'Limit' action is now a builtin. If you have 'Limit' listed in <code class="filename">/etc/shorewall/actions</code>, remove the entry. Also remove the files <code class="filename">/etc/shorewall/action.Limit</code> and/or <code class="filename">/etc/shorewall/Limit</code> if you have them.</p></li><li><p>This issue only applies if you have entries in <code class="filename">/etc/shorewall/providers</code>.</p><p>Previously, Shorewall has not attempted to undo the changes it has made to the firewall's routing as a result of entries in <code class="filename">/etc/shorewall/providers</code> and <code class="filename">/etc/shorewall/routes</code>. 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.</p><p>The steps to correcting this after you have installed version 3.4 or later of Shorewall are as follows:</p><div class="orderedlist"><ol type="a"><li><p><span class="command"><strong>shorewall[-lite] stop</strong></span></p></li><li><p>Remove the files <code class="filename">/var/lib/shorewall[-lite]/default_route</code> and <code class="filename">/var/lib/shorewall[-lite]/undo_routing</code> if they exist.</p></li><li><p>Either restart networking or reboot.</p></li><li><p><span class="command"><strong>shorewall[-lite] start</strong></span></p></li></ol></div></li><li><p>This issue only applies if you run Shorewall Lite.</p><p>The <code class="filename">/etc/shorewall-lite/shorewall.conf</code> file has been renamed <code class="filename">/etc/shorewall-lite/shorewall-lite.conf</code>. When you upgrade, your <code class="filename">shorewall.conf</code> file will be renamed <code class="filename">shorewall-lite.conf</code>.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="V3.2.0"></a>Version >= 3.2.0</h2></div></div></div><div class="orderedlist"><ol type="1"><li><p>If you are upgrading from version 2.4 or earlier, please read the 3.0.0 upgrade considerations below.</p></li><li><p>A number of macros have been split into two. The macros affected are:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>IMAP</td></tr><tr><td>LDAP</td></tr><tr><td>NNTP</td></tr><tr><td>POP3</td></tr><tr><td>SMTP</td></tr></table><p>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.</p><p>These changes have been made to ensure no unexpected ports are opened due to the use of macros.</p></li><li><p>In previous Shorewall releases, DNAT and REDIRECT rules supported a special syntax for exclusion of a subnet from the effect of the rule.</p><p>Example:</p><div class="blockquote"><blockquote class="blockquote"><p>Z2 is a subzone of Z1:</p><pre class="programlisting">DNAT Z1!Z2 loc:192.168.1.4 ...</pre></blockquote></div><p>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:</p><pre class="programlisting">DNAT Z1:!<list of exclusions> loc:192.168.1.4 ...</pre><p>Beginning with Shorewall 3.2.0, the special exclusion syntax will no longer be supported.</p></li><li><p>Important if you use the QUEUE target.</p><p>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).</p><p>As part of this change, Shorewall no longer adds the "--syn" option to TCP rules that specify QUEUE as their target.</p></li><li><p>Extension Scripts may require change</p><p>In previous releases, extension scripts were executed during <span class="command"><strong>[re]start</strong></span> by using the Bourne Shell "." operator. In addition to executing commands during <span class="command"><strong>[re]start</strong></span>, these scripts had to "save" the commands to be executed during <span class="command"><strong>shorewall restore</strong></span>.</p><p>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 <span class="command"><strong>start</strong></span>, <span class="command"><strong>restart</strong></span> and <span class="command"><strong>restore</strong></span>. This applies to all extension scripts except those associated with a chain or action -- those extension scripts continue to be processed at compile time.</p><p>This new approach has two implications for existing scripts.</p><div class="orderedlist"><ol type="a"><li><p>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:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>save_command() - does nothing</td></tr><tr><td>run_and_save_command() - runs the passed command</td></tr><tr><td>ensure_and_save_command() - runs the passed command and stops the firewall if the command fails.</td></tr></table><p>These functions should provide for transparent migration of scripts that use them until you can get around to eliminating their use completely.</p></li><li><p>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.</p></li></ol></div></li><li><p>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:</p><div class="orderedlist"><ol type="a"><li><p>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).</p></li><li><p>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).</p></li></ol></div></li><li><p>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:</p><div class="orderedlist"><ol type="a"><li><p><code class="filename">/usr/share/shorewall/modules</code> -- the former <code class="filename">/etc/shorewall/modules</code></p></li><li><p>/usr/share/shorewall/xmodules -- a new file that support xtables.</p></li></ol></div><p>If you wish to use the new file, then simply execute this command:</p><p><span class="command"><strong>cp -f /usr/share/shorewall/xmodules /etc/shorewall/modules</strong></span></p></li><li><p>(<span class="bold"><strong>Versions >= 3.2.3</strong></span>) 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.</p><p>With correctly-coded rulesets, this change should have no effect. Users having incorrectly-coded tcrules may need to change them.</p><p>Example:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#MARK/ SOURCE DEST PROTO DEST SOURCE #CLASSIFY PORTS(S) PORT(S) 1:110 $FW eth3 tcp - 22</pre></blockquote></div><p>While the user may have expected this rule to only affect traffic from the firewall itself, the rule was really equivalent to this one:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">#MARK/ SOURCE DEST PROTO DEST SOURCE #CLASSIFY PORTS(S) PORT(S) 1:110 0.0.0.0/0 eth3 tcp - 22</pre></blockquote></div><p>So after this change, the second rule will be required rather than the first if that is what was really wanted.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="V3.0.0"></a>Version >= 3.0.0</h2></div></div></div><div class="orderedlist"><ol type="1"><li><p>The "monitor" command has been eliminated.</p></li><li><p>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.</p><p>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.</p><p>Adhering to the principle of least astonishment, the old <code class="filename">/etc/shorewall/ipsec</code> 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.</p><p>The shorewall.conf file included in this release sets IPSECFILE=zones so that new users are expected to use the <a class="ulink" href="manpages/shorewall-zones.html" target="_self">new zone file format</a>.</p></li><li><p>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.</p></li><li><p>The 'nobogons' interface and hosts option as well as the BOGON_LOG_LEVEL option have been eliminated.</p></li><li><p>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.</p><p>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'.</p></li><li><p>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.</p></li><li><p>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 <a class="ulink" href="http://shorewall.net/starting_and_stopping_shorewall.htm" target="_self">http://shorewall.net/starting_and_stopping_shorewall.htm</a>. In addition to the state, the time and date at which that state was entered is shown.</p><p>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.</p></li><li><p>The "shorewall forget" command now removes the dynamic blacklist save file (/var/lib/shorewall/save).</p></li><li><p>In previous versions of Shorewall, the rules generated by entries in <code class="filename">/etc/shorewall/tunnels</code> preceded those rules generated by entries in <code class="filename">/etc/shorewall/rules</code>. 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 <a class="ulink" href="http://www.shorewall.net/VPNBasics.html" target="_self">http://www.shorewall.net/VPNBasics.html</a> for information on the rules generated by entries in the tunnels file.</p></li><li><p>The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have been removed as have the 'newnotsyn' options in <code class="filename">/etc/shorewall/interfaces</code> and <code class="filename">/etc/shorewall/hosts</code>.</p><p>TCP new-not-syn packets may be blocked using the 'dropNotSyn' or 'rejNotSyn' built-in actions.</p><p>Example: Reject all new-not-syn packets from the net and log them at the 'info' level.</p><pre class="programlisting">#ACTION SOURCE DEST PROTO SECTION NEW rejNotSyn:info net all tcp</pre><p>Note that the rule is added at the front of the NEW section of the rules file.</p></li><li><p>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.</p><p>Users who currently use an <code class="filename">/etc/shorewall/tcstart</code> file and wish to continue to do so should set TC_SCRIPT=/etc/shorewall/tcstart in shorewall.conf.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="V2.4.0"></a>Version >= 2.4.0</h2></div></div></div><div class="orderedlist"><ol type="1"><li><p>Shorewall now enforces the restriction that mark values used in <code class="filename"> /etc/shorewall/tcrules</code> are less than 256. If you are using mark values >= 256, you must change your configuration before you upgrade.</p></li><li><p>The value "ipp2p" is no longer accepted in the PROTO column of the <code class="filename">/etc/shorewall/rules</code> 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.</p></li><li><p>LEAF/Bering packages for 2.4.0 and later releases are not available from shorewall.net. See the <a class="ulink" href="http://leaf.sourceforge.net" target="_self">LEAF site</a> for those packages.</p></li></ol></div></div></div></body></html>