mirror of
https://gitlab.com/shorewall/code.git
synced 2025-02-08 14:01:47 +01:00
Update upgrade issues for 2.2.0
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1741 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
3ff377ef38
commit
8e49c10488
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-10-27</pubdate>
|
||||
<pubdate>2004-10-31</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001</year>
|
||||
@ -523,6 +523,10 @@ tar -xzvf /mnt/package2.lrp
|
||||
instructions! :-)</para>
|
||||
</note>
|
||||
</blockquote>
|
||||
|
||||
<para>For information on other LEAF/Bering upgrade tools, check out <ulink
|
||||
url="http://cvs.sourceforge.net/viewcvs.py/*checkout*/leaf/devel/alexrh/lck/READM">this
|
||||
article by Alex Rhomberg</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="Config_Files">
|
||||
|
||||
@ -30,7 +30,8 @@
|
||||
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>
|
||||
<quote><ulink type="" url="copyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -41,10 +42,10 @@
|
||||
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>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>
|
||||
|
||||
@ -61,20 +62,127 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 2.0.2 RC1</title>
|
||||
<title>Version >= 2.2.0 Beta 1</title>
|
||||
|
||||
<para></para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Shorewall configuration files except shorewall.conf are now
|
||||
empty (they contain only comments). If you wish to retain the defaults
|
||||
in any of the following files, you should copy these files before
|
||||
upgrading them then restore them after the upgrade:</para>
|
||||
|
||||
<simplelist>
|
||||
<member>/etc/shorewall/zones</member>
|
||||
|
||||
<member>/etc/shorewall/policy</member>
|
||||
|
||||
<member>/etc/shorewall/tos</member>
|
||||
</simplelist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The following builtin actions have been removed and have been
|
||||
replaced by the new action logging implementation described in the new
|
||||
features below.</para>
|
||||
|
||||
<simplelist>
|
||||
<member>logNotSyn</member>
|
||||
|
||||
<member>rLogNotSyn</member>
|
||||
|
||||
<member>dLogNotSyn</member>
|
||||
</simplelist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para> If shorewall.conf is upgraded to the latest version, it needs
|
||||
to be modified to set STARTUP_ENABLED=Yes.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The Leaf/Bering version of Shorewall was previously
|
||||
named:</para>
|
||||
|
||||
<simplelist>
|
||||
<member>shorwall-<version>.lrp</member>
|
||||
</simplelist>
|
||||
|
||||
<para>Beginning with 2.1, that file will now be named:</para>
|
||||
|
||||
<simplelist>
|
||||
<member>shorewall-lrp-<version>.tgz</member>
|
||||
</simplelist>
|
||||
|
||||
<para>Simply rename that file to 'shorwall.lrp' when installing it on
|
||||
your LEAF/Bering system.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The ORIGINAL DEST column of the /etc/shorewall/rules file may no
|
||||
longer contain a second (SNAT) address. You must use an entry in
|
||||
/etc/shorewall/masq instead. </para>
|
||||
|
||||
<para>Example from Shorewall FAQ #1:</para>
|
||||
|
||||
<blockquote>
|
||||
<para>Prior to Shorewall 2.1:</para>
|
||||
|
||||
<para>/etc/shorewall/interfaces</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth1 detect routeback</programlisting>
|
||||
|
||||
<para>/etc/shorewall/rules</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
|
||||
# PORT DEST
|
||||
DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69:192.168.1.254 </programlisting>
|
||||
|
||||
<para> Shorewall 2.1 and Later:</para>
|
||||
|
||||
<para>/etc/shorewall/interfaces</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
loc eth1 detect routeback</programlisting>
|
||||
|
||||
<para>/etc/shorewall/masq:</para>
|
||||
|
||||
<programlisting>#INTERFACE SUBNETS ADDRESS PROTO PORT(S)
|
||||
eth1 eth1 192.168.1.254 tcp 80</programlisting>
|
||||
|
||||
<para>/etc/shorewall/rules:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
|
||||
# PORT DEST
|
||||
DNAT loc loc:192.168.1.12 tcp 80 - 130.252.100.69</programlisting>
|
||||
</blockquote>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>The 'logunclean' and 'dropunclean' options that were deprecated
|
||||
in Shorewall 2.0 have now been removed completely.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</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>
|
||||
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>
|
||||
<title>Version >= 2.0.2 Beta 1</title>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
@ -85,10 +193,11 @@
|
||||
|
||||
<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>
|
||||
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>
|
||||
@ -97,14 +206,14 @@
|
||||
|
||||
<para>Example: <programlisting>save_command echo Operation Complete</programlisting></para>
|
||||
|
||||
<para>That command would simply write "echo Operation
|
||||
Complete" to the restore file.</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>
|
||||
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.
|
||||
@ -113,54 +222,55 @@
|
||||
|
||||
<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>
|
||||
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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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
|
||||
<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>
|
||||
@ -169,18 +279,19 @@
|
||||
<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>
|
||||
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>
|
||||
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>
|
||||
<para>The following files don't exist in Shorewall 2.0:</para>
|
||||
|
||||
<simplelist>
|
||||
<member><filename>/etc/shorewall/common.def</filename></member>
|
||||
@ -190,13 +301,14 @@
|
||||
<member><filename>/etc/shorewall/icmpdef</filename></member>
|
||||
|
||||
<member><filename>/etc/shorewall/action.template</filename> (moved
|
||||
to <filename>/usr/share/shorewall/action.template</filename>)</member>
|
||||
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>
|
||||
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
|
||||
@ -212,28 +324,29 @@
|
||||
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>
|
||||
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>
|
||||
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>
|
||||
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>
|
||||
<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>
|
||||
@ -241,64 +354,69 @@
|
||||
now labeled USER/GROUP and may contain:</para>
|
||||
|
||||
<simplelist>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
<member>[!]<<emphasis>user number</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
<member>[!]<<emphasis>user name</emphasis>>[:]</member>
|
||||
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group number</emphasis>></member>
|
||||
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
<member>[!]:<<emphasis>group name</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user number</emphasis>>:<<emphasis>group
|
||||
number</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
|
||||
name</emphasis>>:<<emphasis>group
|
||||
number</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
<member>[!]<<emphasis>user
|
||||
inumber</emphasis>>:<<emphasis>group
|
||||
name</emphasis>></member>
|
||||
|
||||
<member>[!]<<emphasis>user name</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>.
|
||||
<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>
|
||||
<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
|
||||
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>
|
||||
<filename
|
||||
class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||
entries.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.6</title>
|
||||
<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>
|
||||
<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>
|
||||
@ -314,39 +432,48 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Version >= 1.4.4</title>
|
||||
<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>,
|
||||
<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>
|
||||
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>
|
||||
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>
|
||||
<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>
|
||||
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>
|
||||
<title>Version >= 1.4.1</title>
|
||||
|
||||
<itemizedlist mark="bullet">
|
||||
<listitem>
|
||||
@ -355,11 +482,10 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
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>
|
||||
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>
|
||||
@ -371,26 +497,29 @@ zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||
|
||||
<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
|
||||
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>
|
||||
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>
|
||||
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
|
||||
@ -400,17 +529,21 @@ 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>
|
||||
</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
|
||||
</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>
|
||||
@ -423,21 +556,21 @@ z2 z1 NONE
|
||||
<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>
|
||||
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>
|
||||
<title>Version >= 1.4.0</title>
|
||||
|
||||
<important>
|
||||
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||||
package ('<literal>ip</literal>' utility).</para>
|
||||
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||||
package ('<literal>ip</literal>' utility).</para>
|
||||
</important>
|
||||
|
||||
<note>
|
||||
@ -445,46 +578,89 @@ z2 z1 NONE
|
||||
<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
|
||||
</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>
|
||||
<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>
|
||||
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>
|
||||
@ -495,242 +671,24 @@ error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||
<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">
|
||||
mark="hollow">
|
||||
<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>
|
||||
<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>
|
||||
</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>
|
||||
<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>
|
||||
</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>
|
||||
</itemizedlist></para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user