mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-24 08:33:40 +01:00
737 lines
33 KiB
XML
737 lines
33 KiB
XML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
|
|
"http://www.oasis-open.org/docbook/xml/4.2/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>
|
||
|
|
|
||
|
|
<holder>Thomas M. Eastep</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>
|
||
|
|
<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 check</command>
|
||
|
|
command to see the groups associated with each of your zones.</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 2.0.2 RC1</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>If you are upgrading from Shorewall 1.4.x and you have commands
|
||
|
|
in your <filename>/etc/shorewall/common</filename> file that are not
|
||
|
|
directly related to the <emphasis role="bold">common</emphasis> chain
|
||
|
|
then you will want to move those commands to <filename>/etc/shorewall/initdone</filename>.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 2.0.2 Beta 1</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>Extension Scripts - In order for extension scripts to work
|
||
|
|
properly with the new iptables-save/restore integration introduced in
|
||
|
|
Shorewall 2.0.2 Beta 1, some change may be required to your extension
|
||
|
|
scripts.</para>
|
||
|
|
|
||
|
|
<para>If your extension scripts are executing commands other than
|
||
|
|
<command>iptables</command> then those commands must also be written
|
||
|
|
to the restore file (a temporary file in <filename class="directory">/var/lib/shorewall</filename>
|
||
|
|
that is renamed <filename>/var/lib/shorewall/restore-base</filename>
|
||
|
|
at the completeion of the <filename>/sbin/shorewall</filename>
|
||
|
|
command). The following functions should be of help:</para>
|
||
|
|
|
||
|
|
<orderedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>save_command() -- saves the passed command to the restore
|
||
|
|
file.</para>
|
||
|
|
|
||
|
|
<para>Example: <programlisting>save_command echo Operation Complete</programlisting></para>
|
||
|
|
|
||
|
|
<para>That command would simply write "echo Operation
|
||
|
|
Complete" to the restore file.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>run_and_save_command() -- saves the passed command to the
|
||
|
|
restore file then executes it. The return value is the exit status
|
||
|
|
of the command. Example: <programlisting>run_and_save_command "echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all"</programlisting></para>
|
||
|
|
|
||
|
|
<para>Note that as in this example, when the command involves file
|
||
|
|
redirection then the entire command must be enclosed in quotes.
|
||
|
|
This applies to all of the functions described here.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>ensure_and_save_command() -- runs the passed command. If the
|
||
|
|
command fails, the firewall is restored to it's prior saved
|
||
|
|
state and the operation is terminated. If the command succeeds,
|
||
|
|
the command is written to the restore file</para>
|
||
|
|
</listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>Dynamic Zone support. - If you don't need to use the
|
||
|
|
<command>shorewall add</command> and <command>shorewall delete</command>
|
||
|
|
commands, you should set DYNAMIC_ZONES=No in <filename>/etc/shorewall/shorewall.conf</filename>.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 2.0.1</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>The function of 'norfc1918' is now split between that
|
||
|
|
option and a new 'nobogons' option. The rfc1918 file released
|
||
|
|
with Shorewall now contains entries for only those three address
|
||
|
|
ranges reserved by RFC 1918. A 'nobogons' interface option has
|
||
|
|
been added which handles bogon source addresses (those which are
|
||
|
|
reserved by the IANA, those reserved for DHCP auto-configuration and
|
||
|
|
the class C test-net reserved for testing and documentation examples).
|
||
|
|
This will allow users to perform RFC 1918 filtering without having to
|
||
|
|
deal with out of date data from IANA. Those who are willing to update
|
||
|
|
their <filename>/usr/share/shorewall/bogons</filename> file regularly
|
||
|
|
can specify the 'nobogons' option in addition to
|
||
|
|
'norfc1918'. The level at which bogon packets are logged is
|
||
|
|
specified in the new BOGON_LOG_LEVEL variable in shorewall.conf. If
|
||
|
|
that option is not specified or is specified as empty (e.g,
|
||
|
|
BOGON_LOG_LEVEL="") then bogon packets whose TARGET is
|
||
|
|
'logdrop' in <filename>/usr/share/shorewall/bogons</filename>
|
||
|
|
are logged at the 'info' level.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>VERSION >= 2.0.0-Beta1</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>The 'dropunclean' and 'logunclean' interface
|
||
|
|
options are no longer supported. If either option is specified in
|
||
|
|
<filename>/etc/shorewall/interfaces</filename>, a threatening message
|
||
|
|
will be generated.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The NAT_BEFORE_RULES option has been removed from
|
||
|
|
<filename>shorewall.conf</filename>. The behavior of Shorewall 2.0 is
|
||
|
|
as if NAT_BEFORE_RULES=No had been specified. In other words, DNAT
|
||
|
|
rules now always take precidence over one-to-one NAT specifications.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The default value for the ALL INTERFACES column in
|
||
|
|
<filename>/etc/shorewall/nat</filename> has changed. In Shorewall 1.*,
|
||
|
|
if the column was left empty, a value of "Yes" was assumed.
|
||
|
|
This has been changed so that a value of "No" is now assumed.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The following files don't exist in Shorewall 2.0:</para>
|
||
|
|
|
||
|
|
<simplelist>
|
||
|
|
<member><filename>/etc/shorewall/common.def</filename></member>
|
||
|
|
|
||
|
|
<member><filename>/etc/shorewall/common</filename></member>
|
||
|
|
|
||
|
|
<member><filename>/etc/shorewall/icmpdef</filename></member>
|
||
|
|
|
||
|
|
<member><filename>/etc/shorewall/action.template</filename> (moved
|
||
|
|
to <filename>/usr/share/shorewall/action.template</filename>)</member>
|
||
|
|
</simplelist>
|
||
|
|
|
||
|
|
<para>The <filename>/etc/shorewall/action</filename> file now allows
|
||
|
|
an action to be designated as the "common" action for a
|
||
|
|
particular policy type by following the action name with ":"
|
||
|
|
and the policy (DROP, REJECT or ACCEPT).</para>
|
||
|
|
|
||
|
|
<para>The file /usr/share/shorewall/actions.std has been added to
|
||
|
|
define those actions that are released as part of Shorewall 2.0 In
|
||
|
|
that file are two actions as follows:</para>
|
||
|
|
|
||
|
|
<simplelist>
|
||
|
|
<member>Drop:DROP</member>
|
||
|
|
|
||
|
|
<member>Reject:REJECT</member>
|
||
|
|
</simplelist>
|
||
|
|
|
||
|
|
<para>The <quote>Drop</quote> action is the common action for DROP
|
||
|
|
policies while the <quote>Reject</quote> action is the default action
|
||
|
|
for REJECT policies. These actions will be performed on packets prior
|
||
|
|
to applying the DROP or REJECT policy respectively. In the first
|
||
|
|
release, the difference between "Reject" and "Drop" is
|
||
|
|
that "Reject" REJECTs SMB traffic while "Drop"
|
||
|
|
silently drops such traffic.</para>
|
||
|
|
|
||
|
|
<para>As described above, Shorewall allows a common action for ACCEPT
|
||
|
|
policies but does not specify such an action in the default
|
||
|
|
configuration.</para>
|
||
|
|
|
||
|
|
<para>For more information see the <ulink
|
||
|
|
url="User_defined_Actions.html">User-defined Action Page</ulink>.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The <filename>/etc/shorewall</filename> directory no longer
|
||
|
|
contains <filename>users</filename> file or a <filename>usersets</filename>
|
||
|
|
file. Similar functionality is now available using user-defined
|
||
|
|
actions.</para>
|
||
|
|
|
||
|
|
<para>Now, action files created by copying <filename>/usr/share/shorewall/action.template</filename>
|
||
|
|
may now specify a USER and or GROUP name/id in the final column just
|
||
|
|
like in the rules file (see below). It is thus possible to create
|
||
|
|
actions that control traffic from a list of users and/or groups.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The last column in <filename>/etc/shorewall/rules</filename> is
|
||
|
|
now labeled USER/GROUP and may contain:</para>
|
||
|
|
|
||
|
|
<simplelist>
|
||
|
|
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||
|
|
|
||
|
|
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||
|
|
|
||
|
|
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||
|
|
|
||
|
|
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||
|
|
|
||
|
|
<member>[!]<<emphasis>user number</emphasis>>:<<emphasis>group
|
||
|
|
number</emphasis>></member>
|
||
|
|
|
||
|
|
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||
|
|
number</emphasis>></member>
|
||
|
|
|
||
|
|
<member>[!]<<emphasis>user inumber</emphasis>>:<<emphasis>group
|
||
|
|
name</emphasis>></member>
|
||
|
|
|
||
|
|
<member>[!]<<emphasis>user name</emphasis>>:<<emphasis>group
|
||
|
|
name</emphasis>></member>
|
||
|
|
</simplelist>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>If your kernel has IPV6 support (recent <trademark>SuSe</trademark>
|
||
|
|
for example), and you don't use IPV6 then you will probably want
|
||
|
|
to set DISABLE_IPV6=Yes in <ulink url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
|
||
|
|
You must have ipv6tables installed.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.8</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>The meaning of <varname>ROUTE_FILTER=Yes</varname> has changed.
|
||
|
|
Previously this setting was documented as causing route filtering to
|
||
|
|
occur on all network interfaces; this didn't work. Beginning with
|
||
|
|
this release, <varname>ROUTE_FILTER=Yes</varname> causes route
|
||
|
|
filtering to occur on all interfaces brought up while Shorewall is
|
||
|
|
running. This means that it may be appropriate to set
|
||
|
|
<varname>ROUTE_FILTER=Yes</varname> and use the routefilter option in
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||
|
|
entries.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.6</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>The <varname>NAT_ENABLED</varname>, <varname>MANGLE_ENABLED</varname>
|
||
|
|
and <varname>MULTIPORT</varname> options have been removed from
|
||
|
|
<filename>shorewall.conf</filename>. These capabilities are now
|
||
|
|
automatically detected by Shorewall.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>An undocumented feature previously allowed entries in the host
|
||
|
|
file as follows: <synopsis>
|
||
|
|
zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
|
||
|
|
</synopsis> This capability was never documented and has been removed in
|
||
|
|
1.4.6 to allow entries of the following format: <synopsis>
|
||
|
|
zone eth1:192.168.1.0/24,192.168.2.0/24
|
||
|
|
</synopsis></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.4</title>
|
||
|
|
|
||
|
|
<para>If you are upgrading from 1.4.3 and have set the <varname>LOGMARKER</varname>
|
||
|
|
variable in <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>,
|
||
|
|
then you must set the new <varname>LOGFORMAT</varname> variable
|
||
|
|
appropriately and remove your setting of <varname>LOGMARKER</varname>.</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version 1.4.4</title>
|
||
|
|
|
||
|
|
<para>If you have zone names that are 5 characters long, you may
|
||
|
|
experience problems starting Shorewall because the <option>--log-prefix</option>
|
||
|
|
in a logging rule is too long. Upgrade to Version 1.4.4a to fix this
|
||
|
|
problem.</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.2</title>
|
||
|
|
|
||
|
|
<para>There are some cases where you may want to handle traffic from a
|
||
|
|
particular group to itself. While I personally think that such a setups
|
||
|
|
are ridiculous, there are two cases covered in this documentation where it
|
||
|
|
can occur: <itemizedlist><listitem><para><ulink url="FAQ.htm#faq2">In FAQ
|
||
|
|
#2</ulink></para></listitem><listitem><para><ulink
|
||
|
|
url="Shorewall_Squid_Usage.html">When running <application>Squid</application>
|
||
|
|
as a transparent proxy in your local zone.</ulink></para></listitem></itemizedlist>
|
||
|
|
If you have either of these cases, you will want to review the current
|
||
|
|
documentation and change your configuration accordingly.</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.1</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>Beginning with Version 1.4.1, traffic between groups in the same
|
||
|
|
zone is accepted by default. Previously, traffic from a zone to itself
|
||
|
|
was treated just like any other traffic; any matching rules were
|
||
|
|
applied followed by enforcement of the appropriate policy. With 1.4.1
|
||
|
|
and later versions, unless you have explicit rules for traffic from Z
|
||
|
|
to Z or you have an explicit Z to Z policy (where "Z" is some
|
||
|
|
zone) then traffic between the groups in zone Z will be accepted. If
|
||
|
|
you do have one or more explicit rules for Z to Z or if you have an
|
||
|
|
explicit Z to Z policy then the behavior is as it was in prior
|
||
|
|
versions.</para>
|
||
|
|
|
||
|
|
<orderedlist numeration="arabic">
|
||
|
|
<listitem>
|
||
|
|
<para>If you have a Z Z ACCEPT policy for a zone to allow traffic
|
||
|
|
between two interfaces to the same zone, that policy can be
|
||
|
|
removed and traffic between the interfaces will traverse fewer
|
||
|
|
rules than previously.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>If you have a Z Z DROP or Z Z REJECT policy or you have
|
||
|
|
Z->Z rules then your configuration should not require any
|
||
|
|
change.</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>If you are currently relying on a implicit policy (one that
|
||
|
|
has "all" in either the SOURCE or DESTINATION column) to
|
||
|
|
prevent traffic between two interfaces to a zone Z and you have no
|
||
|
|
rules for Z->Z then you should add an explicit DROP or REJECT
|
||
|
|
policy for Z to Z.</para>
|
||
|
|
</listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>Sometimes, you want two separate zones on one interface but you
|
||
|
|
don't want Shorewall to set up any infrastructure to handle
|
||
|
|
traffic between them. <example><title>The <filename>zones</filename>,
|
||
|
|
<filename>interfaces</filename> and, <filename>hosts</filename> file
|
||
|
|
contents</title><programlisting>
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>zones</filename>
|
||
|
|
z1 Zone1 The first Zone
|
||
|
|
z2 Zone2 The second Zone
|
||
|
|
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||
|
|
z2 eth1 192.168.1.255
|
||
|
|
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>hosts</filename>
|
||
|
|
z1 eth1:192.168.1.3
|
||
|
|
</programlisting></example> Here, zone z1 is nested in zone z2 and the
|
||
|
|
firewall is not going to be involved in any traffic between these two
|
||
|
|
zones. Beginning with Shorewall 1.4.1, you can prevent Shorewall from
|
||
|
|
setting up any infrastructure to handle traffic between z1 and z2 by
|
||
|
|
using the new NONE policy: <example><title>The contents of
|
||
|
|
<filename>policy</filename></title><programlisting>
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||
|
|
z1 z2 NONE
|
||
|
|
z2 z1 NONE
|
||
|
|
</programlisting></example> Note that NONE policies are generally used in
|
||
|
|
pairs unless there is asymetric routing where only the traffic on one
|
||
|
|
direction flows through the firewall and you are using a NONE polciy
|
||
|
|
in the other direction.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version 1.4.1</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>In Version 1.4.1, Shorewall will never create rules to deal with
|
||
|
|
traffic from a given group back to itself. The <varname>multi</varname>
|
||
|
|
interface option is no longer available so if you want to route
|
||
|
|
traffic between two subnetworks on the same interface then I recommend
|
||
|
|
that you upgrade to Version 1.4.2 and use the <varname>routeback</varname>
|
||
|
|
interface or host option.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.4.0</title>
|
||
|
|
|
||
|
|
<important>
|
||
|
|
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||
|
|
package ('<literal>ip</literal>' utility).</para>
|
||
|
|
</important>
|
||
|
|
|
||
|
|
<note>
|
||
|
|
<para>Unfortunately, some distributions call this package
|
||
|
|
<command>iproute2</command> which will cause the upgrade of Shorewall to
|
||
|
|
fail with the diagnostic: <synopsis>
|
||
|
|
error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||
|
|
</synopsis> This may be worked around by using the <option>--nodeps</option>
|
||
|
|
option of <command>rpm</command> (<command>rpm -Uvh --nodeps
|
||
|
|
<filename>your_shorewall_rpm.rpm</filename></command>).</para>
|
||
|
|
</note>
|
||
|
|
|
||
|
|
<para>If you are upgrading from a version < 1.4.0, then: <itemizedlist
|
||
|
|
mark="bullet"><listitem><para>The <varname>noping</varname> and
|
||
|
|
<varname>forwardping</varname> interface options are no longer supported
|
||
|
|
nor is the <varname>FORWARDPING</varname> option in <filename>shorewall.conf</filename>.
|
||
|
|
ICMP echo-request (ping) packets are treated just like any other
|
||
|
|
connection request and are subject to rules and policies.</para></listitem><listitem><para>Interface
|
||
|
|
names of the form <varname><device>:<integer></varname> in
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||
|
|
now generate a Shorewall error at startup (they always have produced
|
||
|
|
warnings in <application class="software">iptables</application>).</para></listitem><listitem><para>The
|
||
|
|
<varname>MERGE_HOSTS</varname> variable has been removed from
|
||
|
|
<filename>shorewall.conf</filename>. Shorewall 1.4 behaves like 1.3 did
|
||
|
|
when <varname>MERGE_HOSTS=Yes</varname>; that is zone contents are
|
||
|
|
determined by <emphasis>BOTH</emphasis> the interfaces and hosts files
|
||
|
|
when there are entries for the zone in both files.</para></listitem><listitem><para>The
|
||
|
|
<varname>routestopped</varname> option in the interfaces and hosts file
|
||
|
|
has been eliminated; use entries in the <filename>routestopped</filename>
|
||
|
|
file instead.</para></listitem><listitem><para>The Shorewall 1.2 syntax
|
||
|
|
for <varname>DNAT</varname> and <varname>REDIRECT</varname> rules is no
|
||
|
|
longer accepted; you must convert to using the new syntax.</para></listitem><listitem><para>The
|
||
|
|
<varname>ALLOWRELATED</varname> variable in <filename>shorewall.conf</filename>
|
||
|
|
is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||
|
|
<varname>ALLOWRELATED=Yes</varname>.</para></listitem><listitem><para>Late-arriving
|
||
|
|
DNS replies are now dropped by default; there is no need for your own
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||
|
|
file simply to avoid logging these packets.</para></listitem><listitem><para>The
|
||
|
|
<filename>firewall</filename>, <filename>functions</filename> and
|
||
|
|
<filename>version</filename> files have been moved to <filename
|
||
|
|
class="directory">/usr/share/shorewall</filename>.</para></listitem><listitem><para>The
|
||
|
|
<filename>icmp.def</filename> file has been removed. If you include it
|
||
|
|
from <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>,
|
||
|
|
you will need to modify that file.</para></listitem><listitem><para>If you
|
||
|
|
followed the advice in FAQ #2 and call <varname>find_interface_address</varname>
|
||
|
|
in <filename class="directory">/etc/shorewall/</filename><filename>params</filename>,
|
||
|
|
that code should be moved to <filename class="directory">/etc/shorewall/</filename><filename>init</filename>.</para></listitem></itemizedlist></para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version 1.4.0</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>The <varname>multi</varname> interface option is no longer
|
||
|
|
supported. Shorewall will generate rules for sending packets back out
|
||
|
|
the same interface that they arrived on in two cases: <itemizedlist
|
||
|
|
mark="hollow"><listitem><para>There is an <emphasis>explicit</emphasis>
|
||
|
|
policy for the source zone to or from the destination zone. An
|
||
|
|
explicit policy names both zones and does not use the
|
||
|
|
<varname>all</varname> reserved word.</para></listitem><listitem><para>There
|
||
|
|
are one or more rules for traffic for the source zone to or from the
|
||
|
|
destination zone including rules that use the <varname>all</varname>
|
||
|
|
reserved word. Exception: if the source zone and destination zone are
|
||
|
|
the same then the rule must be explicit - it must name the zone in
|
||
|
|
both the <varname>SOURCE</varname> and <varname>DESTINATION</varname>
|
||
|
|
columns.</para></listitem></itemizedlist></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.3.14</title>
|
||
|
|
|
||
|
|
<para>Beginning in version 1.3.14, Shorewall treats entries in <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||
|
|
differently. The change involves entries with an <emphasis role="bold">interface
|
||
|
|
name</emphasis> in the <varname>SUBNET</varname> (second) <emphasis
|
||
|
|
role="bold">column</emphasis>: <itemizedlist mark="bullet"><listitem><para>Prior
|
||
|
|
to 1.3.14, Shorewall would detect the FIRST subnet on the interface (as
|
||
|
|
shown by <quote>ip addr show interface</quote>) and would masquerade
|
||
|
|
traffic from that subnet. Any other subnets that routed through
|
||
|
|
<literal>eth1</literal> needed their own entry in <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>masq</filename> to
|
||
|
|
be masqueraded or to have <acronym>SNAT</acronym> applied.</para></listitem><listitem><para>Beginning
|
||
|
|
with Shorewall 1.3.14, Shorewall uses the firewall's routing table to
|
||
|
|
determine ALL subnets routed through the named interface. Traffic
|
||
|
|
originating in ANY of those subnets is masqueraded or has SNAT applied.</para></listitem></itemizedlist>
|
||
|
|
You will need to make a change to your configuration if: <orderedlist
|
||
|
|
numeration="arabic"><listitem><para>You have one or more entries in
|
||
|
|
<filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||
|
|
with an interface name in the <varname>SUBNET</varname> (second) column;
|
||
|
|
and</para></listitem><listitem><para>That interface connects to more than
|
||
|
|
one subnetwork.</para></listitem></orderedlist> Two examples: <example
|
||
|
|
label="1"><title>Suppose that your current config is as follows:</title><programlisting>
|
||
|
|
<!-- I added a space below the end of the config file for clarity -->
|
||
|
|
[root@gateway test]# cat /etc/shorewall/masq
|
||
|
|
#INTERFACE SUBNET ADDRESS
|
||
|
|
eth0 eth2 206.124.146.176
|
||
|
|
eth0 192.168.10.0/24 206.124.146.176
|
||
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
|
|
||
|
|
[root@gateway test]# ip route show dev eth2
|
||
|
|
192.168.1.0/24 scope link
|
||
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||
|
|
[root@gateway test]#
|
||
|
|
</programlisting></example> In this case, the second entry in <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>masq</filename> is
|
||
|
|
no longer required. <example label="2"><title>What if your current
|
||
|
|
configuration is like this?</title><programlisting>
|
||
|
|
[root@gateway test]# cat /etc/shorewall/masq
|
||
|
|
#INTERFACE SUBNET ADDRESS
|
||
|
|
eth0 eth2 206.124.146.176
|
||
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
|
|
||
|
|
[root@gateway test]# ip route show dev eth2
|
||
|
|
192.168.1.0/24 scope link
|
||
|
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||
|
|
[root@gateway test]#
|
||
|
|
</programlisting></example> In this case, you would want to change the
|
||
|
|
entry in /etc/shorewall/masq to: <programlisting>
|
||
|
|
#INTERFACE SUBNET ADDRESS
|
||
|
|
eth0 192.168.1.0/24 206.124.146.176
|
||
|
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||
|
|
</programlisting> Version 1.3.14 also introduced simplified ICMP
|
||
|
|
echo-request (ping) handling. The option <varname>OLD_PING_HANDLING=Yes</varname>
|
||
|
|
in <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||
|
|
is used to specify that the old (pre-1.3.14) ping handling is to be used
|
||
|
|
(If the option is not set in your <filename class="directory">/etc/shorewall/</filename>shorewall.conf
|
||
|
|
then <varname>OLD_PING_HANDLING=Yes</varname> is assumed). I don't
|
||
|
|
plan on supporting the old handling indefinitely so I urge current users
|
||
|
|
to migrate to using the new handling as soon as possible. See the
|
||
|
|
'Ping' handling documentation for details.</para>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version 1.3.10</title>
|
||
|
|
|
||
|
|
<itemizedlist mark="bullet">
|
||
|
|
<listitem>
|
||
|
|
<para>If you have installed the 1.3.10 Beta 1 RPM and are now
|
||
|
|
upgrading to version 1.3.10, you will need to use the
|
||
|
|
<option>--force</option> option: <programlisting>
|
||
|
|
rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
||
|
|
</programlisting></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.3.9</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>The <filename>functions</filename> file has moved to <filename
|
||
|
|
class="directory">/usr/lib/shorewall/</filename><filename>functions</filename>.
|
||
|
|
If you have an application that uses functions from that file, your
|
||
|
|
application will need to be changed to reflect this change of
|
||
|
|
location.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.3.8</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>If you have a pair of firewall systems configured for failover
|
||
|
|
or if you have asymmetric routing, you will need to modify your
|
||
|
|
firewall setup slightly under Shorewall versions >= 1.3.8.
|
||
|
|
Beginning with version 1.3.8, you must set <varname>NEWNOTSYN=Yes</varname>
|
||
|
|
in your <filename class="directory">/etc/shorewall/</filename><filename>shorewall.conf</filename>
|
||
|
|
file.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.3.7</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>Users specifying <varname>ALLOWRELATED=No</varname> in <filename
|
||
|
|
class="directory">/etc/</filename><filename>shorewall.conf</filename>
|
||
|
|
will need to include the following rules in their <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||
|
|
file (creating this file if necessary):
|
||
|
|
<programlisting>
|
||
|
|
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
|
||
|
|
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
|
||
|
|
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
|
||
|
|
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
|
||
|
|
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
||
|
|
</programlisting> Users having an <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||
|
|
file may remove the <command>./etc/shorewall/icmp.def</command>
|
||
|
|
command from that file since the <filename>icmp.def</filename> file is
|
||
|
|
now empty.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Upgrading Bering to Shorewall >= 1.3.3</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>To properly upgrade with Shorewall version 1.3.3 and later:
|
||
|
|
<orderedlist numeration="arabic"><listitem><para>Be sure you have a
|
||
|
|
backup -- you will need to transcribe any Shorewall configuration
|
||
|
|
changes that you have made to the new configuration.</para></listitem><listitem><para>Replace
|
||
|
|
the <filename>shorwall.lrp</filename> package provided on the Bering
|
||
|
|
floppy with the later one. If you did not obtain the later version
|
||
|
|
from Jacques's site, see additional instructions below.</para></listitem><listitem><para>Edit
|
||
|
|
the <filename class="directory">/var/lib/lrpkg/</filename><filename>root.exclude.list</filename>
|
||
|
|
file and remove the <filename>/var/lib/shorewall</filename> entry if
|
||
|
|
present. Then do not forget to backup <filename>root.lrp</filename>!</para></listitem></orderedlist>
|
||
|
|
The .lrp that I release isn't set up for a two-interface firewall
|
||
|
|
like Jacques's. You need to follow the instructions for setting up
|
||
|
|
a two-interface firewall plus you also need to add the following two
|
||
|
|
Bering-specific rules to <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>:
|
||
|
|
<programlisting>
|
||
|
|
# Bering specific rules:
|
||
|
|
# allow loc to fw udp/53 for dnscache to work
|
||
|
|
# allow loc to fw tcp/80 for weblet to work
|
||
|
|
#
|
||
|
|
ACCEPT loc fw udp 53
|
||
|
|
ACCEPT loc fw tcp 80
|
||
|
|
</programlisting></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version 1.3.6 and 1.3.7</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>If you have a pair of firewall systems configured for failover
|
||
|
|
or if you have asymmetric routing, you will need to modify your
|
||
|
|
firewall setup slightly under Shorewall versions 1.3.6 and 1.3.7
|
||
|
|
<orderedlist><listitem><para>Create the file <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>newnotsyn</filename>
|
||
|
|
and in it add the following rule: <!-- The following code wraps off of the document. I have added the comment above the command. -->
|
||
|
|
<programlisting>
|
||
|
|
# So that the connection tracking table can be rebuilt
|
||
|
|
# from non-SYN packets after takeover.
|
||
|
|
run_iptables -A newnotsyn -j RETURN
|
||
|
|
</programlisting></para></listitem><listitem><para>Create <filename
|
||
|
|
class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||
|
|
(if you don't already have that file) and include the following:
|
||
|
|
<programlisting>
|
||
|
|
#Accept Acks to rebuild connection tracking table.
|
||
|
|
run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
|
||
|
|
|
||
|
|
./etc/shorewall/common.def
|
||
|
|
</programlisting></para></listitem></orderedlist></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Versions >= 1.3.5</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>Some forms of pre-1.3.0 rules file syntax are no longer
|
||
|
|
supported. <example label="1"><title></title><programlisting>
|
||
|
|
ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
|
||
|
|
</programlisting></example> Must be replaced with:
|
||
|
|
<programlisting>
|
||
|
|
DNAT net loc:192.168.1.12:22 tcp 11111
|
||
|
|
</programlisting> <example label="2"><title></title><programlisting>
|
||
|
|
ACCEPT loc fw::3128 tcp 80 - all
|
||
|
|
</programlisting></example> Must be replaced with:
|
||
|
|
<programlisting>
|
||
|
|
REDIRECT loc 3128 tcp 80
|
||
|
|
</programlisting></para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Version >= 1.3.2</title>
|
||
|
|
|
||
|
|
<itemizedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>The functions and versions files together with the <filename
|
||
|
|
class="symlink">firewall</filename> symbolic link have moved from
|
||
|
|
<filename class="directory">/etc/shorewall</filename> to <filename
|
||
|
|
class="directory">/var/lib/shorewall</filename>. If you have
|
||
|
|
applications that access these files, those applications should be
|
||
|
|
modified accordingly.</para>
|
||
|
|
</listitem>
|
||
|
|
</itemizedlist>
|
||
|
|
</section>
|
||
|
|
</article>
|