forked from extern/shorewall_code
xml beautification (xxe)
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1009 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
mhnoyes
parent
63779f4b9d
commit
72bf5c591e
@ -1,148 +1,182 @@
|
|||||||
<?xml version="1.0" encoding="UTF-8"?>
|
<?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">
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||||||
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||||
<!-- $Id$ -->
|
<!-- $Id$ -->
|
||||||
<article id="upgrade_issues">
|
<article id="upgrade_issues">
|
||||||
|
<!--$Id$-->
|
||||||
|
|
||||||
<articleinfo>
|
<articleinfo>
|
||||||
<title>Upgrade Issues</title>
|
<title>Upgrade Issues</title>
|
||||||
|
|
||||||
<author>
|
<author>
|
||||||
<firstname>Tom</firstname>
|
<firstname>Tom</firstname>
|
||||||
|
|
||||||
<surname>Eastep</surname>
|
<surname>Eastep</surname>
|
||||||
</author>
|
</author>
|
||||||
<pubdate>2003/12/23</pubdate>
|
|
||||||
|
<pubdate>2003/12/23</pubdate>
|
||||||
|
|
||||||
<copyright>
|
<copyright>
|
||||||
<year>2003</year>
|
<year>2003</year>
|
||||||
|
|
||||||
<holder>Thomas M. Eastep</holder>
|
<holder>Thomas M. Eastep</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
|
||||||
<legalnotice>
|
<legalnotice>
|
||||||
<para>
|
<para>Permission is granted to copy, distribute and/or modify this
|
||||||
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
|
document under the terms of the GNU Free Documentation License, Version
|
||||||
url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.
|
1.2 or any later version published by the Free Software Foundation; with
|
||||||
</para>
|
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 url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||||
</legalnotice>
|
</legalnotice>
|
||||||
</articleinfo>
|
</articleinfo>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Important</title>
|
<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>It is important that you read all of the sections on this page where
|
||||||
</para>
|
the version number mentioned in the section title is later than what you
|
||||||
<para>
|
are currently running.</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>
|
||||||
<para>
|
refers to a particular network or subnetwork (which may be
|
||||||
Examples:
|
<literal>0.0.0.0/0</literal> or it may be a host address) accessed through
|
||||||
</para>
|
a particular interface.</para>
|
||||||
|
|
||||||
|
<para>Examples:</para>
|
||||||
|
|
||||||
<simplelist columns="1" type="vert">
|
<simplelist columns="1" type="vert">
|
||||||
<member>
|
<member><literal>eth0:0.0.0.0/0</literal></member>
|
||||||
<literal>eth0:0.0.0.0/0</literal>
|
|
||||||
</member>
|
<member><literal>eth2:192.168.1.0/24</literal></member>
|
||||||
<member>
|
|
||||||
<literal>eth2:192.168.1.0/24</literal>
|
<member><literal>eth3:192.0.2.123</literal></member>
|
||||||
</member>
|
|
||||||
<member>
|
|
||||||
<literal>eth3:192.0.2.123</literal>
|
|
||||||
</member>
|
|
||||||
</simplelist>
|
</simplelist>
|
||||||
<para>
|
|
||||||
You can use the <command moreinfo="none">shorewall check</command> command to see the groups associated with each of your zones.
|
<para>You can use the <command moreinfo="none">shorewall check</command>
|
||||||
</para>
|
command to see the groups associated with each of your zones.</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.4.8</title>
|
<title>Version >= 1.4.8</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>The meaning of <varname>ROUTE_FILTER=Yes</varname> has changed.
|
||||||
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.
|
Previously this setting was documented as causing route filtering to
|
||||||
</para>
|
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>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.4.6</title>
|
<title>Version >= 1.4.6</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>The <varname>NAT_ENABLED</varname>, <varname>MANGLE_ENABLED</varname>
|
||||||
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.
|
and <varname>MULTIPORT</varname> options have been removed from
|
||||||
</para>
|
<filename>shorewall.conf</filename>. These capabilities are now
|
||||||
|
automatically detected by Shorewall.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>An undocumented feature previously allowed entries in the host
|
||||||
An undocumented feature previously allowed entries in the host file as follows:
|
file as follows: <synopsis>
|
||||||
<synopsis>
|
|
||||||
zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
|
zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
|
||||||
</synopsis>
|
</synopsis> This capability was never documented and has been removed in
|
||||||
This capability was never documented and has been removed in 1.4.6 to allow entries of the following format:
|
1.4.6 to allow entries of the following format: <synopsis>
|
||||||
<synopsis>
|
|
||||||
zone eth1:192.168.1.0/24,192.168.2.0/24
|
zone eth1:192.168.1.0/24,192.168.2.0/24
|
||||||
</synopsis>
|
</synopsis></para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<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>, then you must set the new <varname>LOGFORMAT</varname> variable appropriately and remove your setting of <varname>LOGMARKER</varname>.
|
<para>If you are upgrading from 1.4.3 and have set the <varname>LOGMARKER</varname>
|
||||||
</para>
|
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>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version 1.4.4</title>
|
<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>
|
<para>If you have zone names that are 5 characters long, you may
|
||||||
<listitem>
|
experience problems starting Shorewall because the <option>--log-prefix</option>
|
||||||
<para>
|
in a logging rule is too long. Upgrade to Version 1.4.4a to fix this
|
||||||
<ulink url="FAQ.htm#faq2">In FAQ #2</ulink>
|
problem.</para>
|
||||||
</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>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.4.1</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>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<title>Version >= 1.4.1</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>Beginning with Version 1.4.1, traffic between groups in the same
|
||||||
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.
|
zone is accepted by default. Previously, traffic from a zone to itself
|
||||||
</para>
|
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">
|
<orderedlist numeration="arabic">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you have a Z Z ACCEPT policy for a zone to allow traffic
|
||||||
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.
|
between two interfaces to the same zone, that policy can be
|
||||||
</para>
|
removed and traffic between the interfaces will traverse fewer
|
||||||
|
rules than previously.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you have a Z Z DROP or Z Z REJECT policy or you have
|
||||||
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.
|
Z->Z rules then your configuration should not require any
|
||||||
</para>
|
change.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you are currently relying on a implicit policy (one that
|
||||||
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.
|
has "all" in either the SOURCE or DESTINATION column) to
|
||||||
</para>
|
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>
|
</listitem>
|
||||||
</orderedlist>
|
</orderedlist>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>Sometimes, you want two separate zones on one interface but you
|
||||||
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.
|
don't want Shorewall to set up any infrastructure to handle
|
||||||
<example>
|
traffic between them. <example><title>The <filename>zones</filename>,
|
||||||
<title>The <filename>zones</filename>, <filename>interfaces</filename> and, <filename>hosts</filename> file contents</title>
|
<filename>interfaces</filename> and, <filename>hosts</filename> file
|
||||||
<programlisting>
|
contents</title><programlisting>
|
||||||
<filename class="directory">/etc/shorewall/</filename><filename>zones</filename>
|
<filename class="directory">/etc/shorewall/</filename><filename>zones</filename>
|
||||||
z1 Zone1 The first Zone
|
z1 Zone1 The first Zone
|
||||||
z2 Zone2 The second Zone
|
z2 Zone2 The second Zone
|
||||||
@ -152,159 +186,139 @@ z2 eth1 192.168.1.255
|
|||||||
|
|
||||||
<filename class="directory">/etc/shorewall/</filename><filename>hosts</filename>
|
<filename class="directory">/etc/shorewall/</filename><filename>hosts</filename>
|
||||||
z1 eth1:192.168.1.3
|
z1 eth1:192.168.1.3
|
||||||
</programlisting>
|
</programlisting></example> Here, zone z1 is nested in zone z2 and the
|
||||||
</example>
|
firewall is not going to be involved in any traffic between these two
|
||||||
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:
|
zones. Beginning with Shorewall 1.4.1, you can prevent Shorewall from
|
||||||
<example>
|
setting up any infrastructure to handle traffic between z1 and z2 by
|
||||||
<title>The contents of <filename>policy</filename></title>
|
using the new NONE policy: <example><title>The contents of
|
||||||
<programlisting>
|
<filename>policy</filename></title><programlisting>
|
||||||
<filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
<filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
|
||||||
z1 z2 NONE
|
z1 z2 NONE
|
||||||
z2 z1 NONE
|
z2 z1 NONE
|
||||||
</programlisting>
|
</programlisting></example> Note that NONE policies are generally used in
|
||||||
</example>
|
pairs unless there is asymetric routing where only the traffic on one
|
||||||
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.
|
direction flows through the firewall and you are using a NONE polciy
|
||||||
</para>
|
in the other direction.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version 1.4.1</title>
|
<title>Version 1.4.1</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>In Version 1.4.1, Shorewall will never create rules to deal with
|
||||||
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.
|
traffic from a given group back to itself. The <varname>multi</varname>
|
||||||
</para>
|
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>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.4.0</title>
|
<title>Version >= 1.4.0</title>
|
||||||
|
|
||||||
<important>
|
<important>
|
||||||
<para>
|
<para>Shorewall >=1.4.0 requires the <command>iproute</command>
|
||||||
Shorewall >=1.4.0 requires the <command>iproute</command> package ('<literal>ip</literal>' utility).
|
package ('<literal>ip</literal>' utility).</para>
|
||||||
</para>
|
|
||||||
</important>
|
</important>
|
||||||
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>Unfortunately, some distributions call this package
|
||||||
Unfortunately, some distributions call this package <command>iproute2</command> which will cause the upgrade of Shorewall to fail with the diagnostic:
|
<command>iproute2</command> which will cause the upgrade of Shorewall to
|
||||||
<synopsis>
|
fail with the diagnostic: <synopsis>
|
||||||
error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||||
</synopsis>
|
</synopsis> This may be worked around by using the <option>--nodeps</option>
|
||||||
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>).
|
option of <command>rpm</command> (<command>rpm -Uvh --nodeps
|
||||||
</para>
|
<filename>your_shorewall_rpm.rpm</filename></command>).</para>
|
||||||
</note>
|
</note>
|
||||||
<para>
|
|
||||||
If you are upgrading from a version < 1.4.0, then:
|
<para>If you are upgrading from a version < 1.4.0, then: <itemizedlist
|
||||||
<itemizedlist mark="bullet">
|
mark="bullet"><listitem><para>The <varname>noping</varname> and
|
||||||
<listitem>
|
<varname>forwardping</varname> interface options are no longer supported
|
||||||
<para>
|
nor is the <varname>FORWARDPING</varname> option in <filename>shorewall.conf</filename>.
|
||||||
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.
|
ICMP echo-request (ping) packets are treated just like any other
|
||||||
</para>
|
connection request and are subject to rules and policies.</para></listitem><listitem><para>Interface
|
||||||
</listitem>
|
names of the form <varname><device>:<integer></varname> in
|
||||||
<listitem>
|
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
|
||||||
<para>
|
now generate a Shorewall error at startup (they always have produced
|
||||||
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>).
|
warnings in <application class="software">iptables</application>).</para></listitem><listitem><para>The
|
||||||
</para>
|
<varname>MERGE_HOSTS</varname> variable has been removed from
|
||||||
</listitem>
|
<filename>shorewall.conf</filename>. Shorewall 1.4 behaves like 1.3 did
|
||||||
<listitem>
|
when <varname>MERGE_HOSTS=Yes</varname>; that is zone contents are
|
||||||
<para>
|
determined by <emphasis>BOTH</emphasis> the interfaces and hosts files
|
||||||
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.
|
when there are entries for the zone in both files.</para></listitem><listitem><para>The
|
||||||
</para>
|
<varname>routestopped</varname> option in the interfaces and hosts file
|
||||||
</listitem>
|
has been eliminated; use entries in the <filename>routestopped</filename>
|
||||||
<listitem>
|
file instead.</para></listitem><listitem><para>The Shorewall 1.2 syntax
|
||||||
<para>
|
for <varname>DNAT</varname> and <varname>REDIRECT</varname> rules is no
|
||||||
The <varname>routestopped</varname> option in the interfaces and hosts file has been eliminated; use entries in the <filename>routestopped</filename> file instead.
|
longer accepted; you must convert to using the new syntax.</para></listitem><listitem><para>The
|
||||||
</para>
|
<varname>ALLOWRELATED</varname> variable in <filename>shorewall.conf</filename>
|
||||||
</listitem>
|
is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
|
||||||
<listitem>
|
<varname>ALLOWRELATED=Yes</varname>.</para></listitem><listitem><para>Late-arriving
|
||||||
<para>
|
DNS replies are now dropped by default; there is no need for your own
|
||||||
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.
|
<filename class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||||
</para>
|
file simply to avoid logging these packets.</para></listitem><listitem><para>The
|
||||||
</listitem>
|
<filename>firewall</filename>, <filename>functions</filename> and
|
||||||
<listitem>
|
<filename>version</filename> files have been moved to <filename
|
||||||
<para>
|
class="directory">/usr/share/shorewall</filename>.</para></listitem><listitem><para>The
|
||||||
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>.
|
<filename>icmp.def</filename> file has been removed. If you include it
|
||||||
</para>
|
from <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>,
|
||||||
</listitem>
|
you will need to modify that file.</para></listitem><listitem><para>If you
|
||||||
<listitem>
|
followed the advice in FAQ #2 and call <varname>find_interface_address</varname>
|
||||||
<para>
|
in <filename class="directory">/etc/shorewall/</filename><filename>params</filename>,
|
||||||
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.
|
that code should be moved to <filename class="directory">/etc/shorewall/</filename><filename>init</filename>.</para></listitem></itemizedlist></para>
|
||||||
</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>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version 1.4.0</title>
|
<title>Version 1.4.0</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>The <varname>multi</varname> interface option is no longer
|
||||||
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:
|
supported. Shorewall will generate rules for sending packets back out
|
||||||
<itemizedlist mark="hollow">
|
the same interface that they arrived on in two cases: <itemizedlist
|
||||||
<listitem>
|
mark="hollow"><listitem><para>There is an <emphasis>explicit</emphasis>
|
||||||
<para>
|
policy for the source zone to or from the destination zone. An
|
||||||
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.
|
explicit policy names both zones and does not use the
|
||||||
</para>
|
<varname>all</varname> reserved word.</para></listitem><listitem><para>There
|
||||||
</listitem>
|
are one or more rules for traffic for the source zone to or from the
|
||||||
<listitem>
|
destination zone including rules that use the <varname>all</varname>
|
||||||
<para>
|
reserved word. Exception: if the source zone and destination zone are
|
||||||
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.
|
the same then the rule must be explicit - it must name the zone in
|
||||||
</para>
|
both the <varname>SOURCE</varname> and <varname>DESTINATION</varname>
|
||||||
</listitem>
|
columns.</para></listitem></itemizedlist></para>
|
||||||
</itemizedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.3.14</title>
|
<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>:
|
<para>Beginning in version 1.3.14, Shorewall treats entries in <filename
|
||||||
<itemizedlist mark="bullet">
|
class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||||
<listitem>
|
differently. The change involves entries with an <emphasis role="bold">interface
|
||||||
<para>
|
name</emphasis> in the <varname>SUBNET</varname> (second) <emphasis
|
||||||
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.
|
role="bold">column</emphasis>: <itemizedlist mark="bullet"><listitem><para>Prior
|
||||||
</para>
|
to 1.3.14, Shorewall would detect the FIRST subnet on the interface (as
|
||||||
</listitem>
|
shown by <quote>ip addr show interface</quote>) and would masquerade
|
||||||
<listitem>
|
traffic from that subnet. Any other subnets that routed through
|
||||||
<para>
|
<literal>eth1</literal> needed their own entry in <filename
|
||||||
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.
|
class="directory">/etc/shorewall/</filename><filename>masq</filename> to
|
||||||
</para>
|
be masqueraded or to have <acronym>SNAT</acronym> applied.</para></listitem><listitem><para>Beginning
|
||||||
</listitem>
|
with Shorewall 1.3.14, Shorewall uses the firewall's routing table to
|
||||||
</itemizedlist>
|
determine ALL subnets routed through the named interface. Traffic
|
||||||
You will need to make a change to your configuration if:
|
originating in ANY of those subnets is masqueraded or has SNAT applied.</para></listitem></itemizedlist>
|
||||||
<orderedlist numeration="arabic">
|
You will need to make a change to your configuration if: <orderedlist
|
||||||
<listitem>
|
numeration="arabic"><listitem><para>You have one or more entries in
|
||||||
<para>
|
<filename class="directory">/etc/shorewall/</filename><filename>masq</filename>
|
||||||
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
|
with an interface name in the <varname>SUBNET</varname> (second) column;
|
||||||
</para>
|
and</para></listitem><listitem><para>That interface connects to more than
|
||||||
</listitem>
|
one subnetwork.</para></listitem></orderedlist> Two examples: <example
|
||||||
<listitem>
|
label="1"><title>Suppose that your current config is as follows:</title><programlisting>
|
||||||
<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 -->
|
<!-- I added a space below the end of the config file for clarity -->
|
||||||
[root@gateway test]# cat /etc/shorewall/masq
|
[root@gateway test]# cat /etc/shorewall/masq
|
||||||
#INTERFACE SUBNET ADDRESS
|
#INTERFACE SUBNET ADDRESS
|
||||||
@ -316,12 +330,10 @@ eth0 192.168.10.0/24 206.124.146.176
|
|||||||
192.168.1.0/24 scope link
|
192.168.1.0/24 scope link
|
||||||
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||||||
[root@gateway test]#
|
[root@gateway test]#
|
||||||
</programlisting>
|
</programlisting></example> In this case, the second entry in <filename
|
||||||
</example>
|
class="directory">/etc/shorewall/</filename><filename>masq</filename> is
|
||||||
In this case, the second entry in <filename class="directory">/etc/shorewall/</filename><filename>masq</filename> is no longer required.
|
no longer required. <example label="2"><title>What if your current
|
||||||
<example label="2">
|
configuration is like this?</title><programlisting>
|
||||||
<title>What if your current configuration is like this?</title>
|
|
||||||
<programlisting>
|
|
||||||
[root@gateway test]# cat /etc/shorewall/masq
|
[root@gateway test]# cat /etc/shorewall/masq
|
||||||
#INTERFACE SUBNET ADDRESS
|
#INTERFACE SUBNET ADDRESS
|
||||||
eth0 eth2 206.124.146.176
|
eth0 eth2 206.124.146.176
|
||||||
@ -331,92 +343,108 @@ eth0 eth2 206.124.146.176
|
|||||||
192.168.1.0/24 scope link
|
192.168.1.0/24 scope link
|
||||||
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
192.168.10.0/24 proto kernel scope link src 192.168.10.254
|
||||||
[root@gateway test]#
|
[root@gateway test]#
|
||||||
</programlisting>
|
</programlisting></example> In this case, you would want to change the
|
||||||
</example>
|
entry in /etc/shorewall/masq to: <programlisting>
|
||||||
In this case, you would want to change the entry in /etc/shorewall/masq to:
|
|
||||||
<programlisting>
|
|
||||||
#INTERFACE SUBNET ADDRESS
|
#INTERFACE SUBNET ADDRESS
|
||||||
eth0 192.168.1.0/24 206.124.146.176
|
eth0 192.168.1.0/24 206.124.146.176
|
||||||
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
|
||||||
</programlisting>
|
</programlisting> Version 1.3.14 also introduced simplified ICMP
|
||||||
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.
|
echo-request (ping) handling. The option <varname>OLD_PING_HANDLING=Yes</varname>
|
||||||
</para>
|
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>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version 1.3.10</title>
|
<title>Version 1.3.10</title>
|
||||||
|
|
||||||
<itemizedlist mark="bullet">
|
<itemizedlist mark="bullet">
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you have installed the 1.3.10 Beta 1 RPM and are now
|
||||||
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:
|
upgrading to version 1.3.10, you will need to use the
|
||||||
<programlisting>
|
<option>--force</option> option: <programlisting>
|
||||||
rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
|
||||||
</programlisting>
|
</programlisting></para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.3.9</title>
|
<title>Version >= 1.3.9</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>The <filename>functions</filename> file has moved to <filename
|
||||||
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.
|
class="directory">/usr/lib/shorewall/</filename><filename>functions</filename>.
|
||||||
</para>
|
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>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.3.8</title>
|
<title>Version >= 1.3.8</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you have a pair of firewall systems configured for failover
|
||||||
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.
|
or if you have asymmetric routing, you will need to modify your
|
||||||
</para>
|
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>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.3.7</title>
|
<title>Version >= 1.3.7</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>Users specifying <varname>ALLOWRELATED=No</varname> in <filename
|
||||||
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):
|
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>
|
<programlisting>
|
||||||
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
|
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 source-quench -j ACCEPT
|
||||||
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -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 time-exceeded -j ACCEPT
|
||||||
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
||||||
</programlisting>
|
</programlisting> Users having an <filename class="directory">/etc/shorewall/</filename><filename>icmpdef</filename>
|
||||||
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.
|
file may remove the <command>./etc/shorewall/icmp.def</command>
|
||||||
</para>
|
command from that file since the <filename>icmp.def</filename> file is
|
||||||
|
now empty.</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Upgrading Bering to Shorewall >= 1.3.3</title>
|
<title>Upgrading Bering to Shorewall >= 1.3.3</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>To properly upgrade with Shorewall version 1.3.3 and later:
|
||||||
To properly upgrade with Shorewall version 1.3.3 and later:
|
<orderedlist numeration="arabic"><listitem><para>Be sure you have a
|
||||||
<orderedlist numeration="arabic">
|
backup -- you will need to transcribe any Shorewall configuration
|
||||||
<listitem>
|
changes that you have made to the new configuration.</para></listitem><listitem><para>Replace
|
||||||
<para>
|
the <filename>shorwall.lrp</filename> package provided on the Bering
|
||||||
Be sure you have a backup -- you will need to transcribe any Shorewall configuration changes that you have made to the new configuration.
|
floppy with the later one. If you did not obtain the later version
|
||||||
</para>
|
from Jacques's site, see additional instructions below.</para></listitem><listitem><para>Edit
|
||||||
</listitem>
|
the <filename class="directory">/var/lib/lrpkg/</filename><filename>root.exclude.list</filename>
|
||||||
<listitem>
|
file and remove the <filename>/var/lib/shorewall</filename> entry if
|
||||||
<para>
|
present. Then do not forget to backup <filename>root.lrp</filename>!</para></listitem></orderedlist>
|
||||||
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.
|
The .lrp that I release isn't set up for a two-interface firewall
|
||||||
</para>
|
like Jacques's. You need to follow the instructions for setting up
|
||||||
</listitem>
|
a two-interface firewall plus you also need to add the following two
|
||||||
<listitem>
|
Bering-specific rules to <filename class="directory">/etc/shorewall/</filename><filename>rules</filename>:
|
||||||
<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>
|
<programlisting>
|
||||||
# Bering specific rules:
|
# Bering specific rules:
|
||||||
# allow loc to fw udp/53 for dnscache to work
|
# allow loc to fw udp/53 for dnscache to work
|
||||||
@ -424,82 +452,71 @@ run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
|
|||||||
#
|
#
|
||||||
ACCEPT loc fw udp 53
|
ACCEPT loc fw udp 53
|
||||||
ACCEPT loc fw tcp 80
|
ACCEPT loc fw tcp 80
|
||||||
</programlisting>
|
</programlisting></para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version 1.3.6 and 1.3.7</title>
|
<title>Version 1.3.6 and 1.3.7</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>If you have a pair of firewall systems configured for failover
|
||||||
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
|
or if you have asymmetric routing, you will need to modify your
|
||||||
<orderedlist>
|
firewall setup slightly under Shorewall versions 1.3.6 and 1.3.7
|
||||||
<listitem>
|
<orderedlist><listitem><para>Create the file <filename
|
||||||
<para>
|
class="directory">/etc/shorewall/</filename><filename>newnotsyn</filename>
|
||||||
Create the file <filename class="directory">/etc/shorewall/</filename><filename>newnotsyn</filename> and in it add the following rule:
|
and in it add the following rule: <!-- The following code wraps off of the document. I have added the comment above the command. -->
|
||||||
<!-- The following code wraps off of the document. I have added the comment above the command. -->
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
# So that the connection tracking table can be rebuilt
|
# So that the connection tracking table can be rebuilt
|
||||||
# from non-SYN packets after takeover.
|
# from non-SYN packets after takeover.
|
||||||
run_iptables -A newnotsyn -j RETURN
|
run_iptables -A newnotsyn -j RETURN
|
||||||
</programlisting>
|
</programlisting></para></listitem><listitem><para>Create <filename
|
||||||
</para>
|
class="directory">/etc/shorewall/</filename><filename>common</filename>
|
||||||
</listitem>
|
(if you don't already have that file) and include the following:
|
||||||
<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>
|
<programlisting>
|
||||||
#Accept Acks to rebuild connection tracking table.
|
#Accept Acks to rebuild connection tracking table.
|
||||||
run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
|
run_iptables -A common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
|
||||||
|
|
||||||
./etc/shorewall/common.def
|
./etc/shorewall/common.def
|
||||||
</programlisting>
|
</programlisting></para></listitem></orderedlist></para>
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</orderedlist>
|
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Versions >= 1.3.5</title>
|
<title>Versions >= 1.3.5</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>Some forms of pre-1.3.0 rules file syntax are no longer
|
||||||
Some forms of pre-1.3.0 rules file syntax are no longer supported.
|
supported. <example label="1"><title></title><programlisting>
|
||||||
<example label="1">
|
|
||||||
<title />
|
|
||||||
<programlisting>
|
|
||||||
ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
|
ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
|
||||||
</programlisting>
|
</programlisting></example> Must be replaced with:
|
||||||
</example>
|
|
||||||
Must be replaced with:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
DNAT net loc:192.168.1.12:22 tcp 11111
|
DNAT net loc:192.168.1.12:22 tcp 11111
|
||||||
</programlisting>
|
</programlisting> <example label="2"><title></title><programlisting>
|
||||||
<example label="2">
|
|
||||||
<title />
|
|
||||||
<programlisting>
|
|
||||||
ACCEPT loc fw::3128 tcp 80 - all
|
ACCEPT loc fw::3128 tcp 80 - all
|
||||||
</programlisting>
|
</programlisting></example> Must be replaced with:
|
||||||
</example>
|
|
||||||
Must be replaced with:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
REDIRECT loc 3128 tcp 80
|
REDIRECT loc 3128 tcp 80
|
||||||
</programlisting>
|
</programlisting></para>
|
||||||
</para>
|
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
<title>Version >= 1.3.2</title>
|
<title>Version >= 1.3.2</title>
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>The functions and versions files together with the <filename
|
||||||
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.
|
class="symlink">firewall</filename> symbolic link have moved from
|
||||||
</para>
|
<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>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user