mirror of
https://gitlab.com/shorewall/code.git
synced 2025-08-09 07:31:00 +02:00
Shorewall-1.4.6
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@672 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
@ -1,441 +1,471 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||||
<html>
|
||||
<head>
|
||||
|
||||
|
||||
<meta http-equiv="Content-Type"
|
||||
content="text/html; charset=windows-1252">
|
||||
<title>Upgrade Issues</title>
|
||||
|
||||
|
||||
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
|
||||
|
||||
|
||||
<meta name="ProgId" content="FrontPage.Editor.Document">
|
||||
|
||||
|
||||
<meta name="Microsoft Theme" content="none">
|
||||
</head>
|
||||
<body>
|
||||
|
||||
|
||||
<table border="0" cellpadding="0" cellspacing="0"
|
||||
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
|
||||
bgcolor="#400169" height="90">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="100%">
|
||||
|
||||
bgcolor="#3366ff" height="90">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td width="100%">
|
||||
|
||||
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
<p>For upgrade instructions see the <a
|
||||
href="Install.htm">Install/Upgrade page</a>.<br>
|
||||
</p>
|
||||
|
||||
<p>It is important that you read all of the sections on this page where the
|
||||
version number mentioned in the section title is later than what you
|
||||
are currently running.<br>
|
||||
</p>
|
||||
|
||||
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
|
||||
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
|
||||
be a host address) accessed through a particular interface.<br>
|
||||
</p>
|
||||
|
||||
<p>Examples:<br>
|
||||
<20><><EFBFBD> <br>
|
||||
<20><><EFBFBD> eth0:0.0.0.0/0<br>
|
||||
<20><><EFBFBD> eth2:192.168.1.0/24<br>
|
||||
<20><><EFBFBD> eth3:192.0.2.123<br>
|
||||
</p>
|
||||
|
||||
<p> You can use the "shorewall check" command to see the groups associated
|
||||
with each of your zones.<br>
|
||||
</p>
|
||||
|
||||
<h3> </h3>
|
||||
|
||||
<h3>Version >= 1.4.4</h3>
|
||||
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
|
||||
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
|
||||
you must set the new LOGFORMAT variable appropriately and remove your setting
|
||||
of LOGMARKER<br>
|
||||
<br>
|
||||
<h3>Version 1.4.4<br>
|
||||
</h3>
|
||||
If you have zone names that are 5 characters long, you may experience problems
|
||||
starting Shorewall because the --log-prefix in a logging rule is too long.
|
||||
Upgrade to Version 1.4.4a to fix this problem..<br>
|
||||
|
||||
<h3>Version >= 1.4.2</h3>
|
||||
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:<br>
|
||||
|
||||
<ol>
|
||||
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
|
||||
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
|
||||
proxy in your local zone.</a></li>
|
||||
|
||||
</ol>
|
||||
If you have either of these cases, you will want to review the current
|
||||
documentation and change your configuration accordingly.<br>
|
||||
|
||||
<h3>Version >= 1.4.1</h3>
|
||||
|
||||
<ul>
|
||||
<li>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.</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<blockquote>
|
||||
<ol>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>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.<br>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
</blockquote>
|
||||
|
||||
<ul>
|
||||
<li> 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. </li>
|
||||
|
||||
</ul>
|
||||
|
||||
<blockquote>Example:<br>
|
||||
|
||||
<blockquote>
|
||||
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
|
||||
</blockquote>
|
||||
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:<br>
|
||||
|
||||
<blockquote>
|
||||
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
|
||||
</blockquote>
|
||||
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.<2E></blockquote>
|
||||
</p>
|
||||
|
||||
<h3>Version 1.4.1<br>
|
||||
</h3>
|
||||
<p>It is important that you read all of the sections on this page where the
|
||||
version number mentioned in the section title is later than what you
|
||||
are currently running.<br>
|
||||
</p>
|
||||
|
||||
<p> In the descriptions that follows, the term <b><i>group </i></b>refers
|
||||
to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
|
||||
be a host address) accessed through a particular interface.<br>
|
||||
</p>
|
||||
|
||||
<p>Examples:<br>
|
||||
<20><><EFBFBD> <br>
|
||||
<20><><EFBFBD> eth0:0.0.0.0/0<br>
|
||||
<20><><EFBFBD> eth2:192.168.1.0/24<br>
|
||||
<20><><EFBFBD> eth3:192.0.2.123<br>
|
||||
</p>
|
||||
|
||||
<p> You can use the "shorewall check" command to see the groups associated
|
||||
with each of your zones.<br>
|
||||
</p>
|
||||
|
||||
<h3> </h3>
|
||||
|
||||
<h3>Version >= 1.4.6</h3>
|
||||
|
||||
<ul>
|
||||
<li> The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
|
||||
from shorewall.conf. These capabilities are now automatically detected by
|
||||
Shorewall.</li>
|
||||
<li>An undocumented <i>feature</i> previously allowed entries in the host
|
||||
file as follows:<br>
|
||||
<br>
|
||||
<i>zone</i> <20> <20>eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
|
||||
<br>
|
||||
This capability was never documented and has been removed in 1.4.6 to allow
|
||||
entries of the following format:<br>
|
||||
<br>
|
||||
<i>zone</i> <20> eth1:192.168.1.0/24,192.168.2.0/24<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>Version >= 1.4.4</h3>
|
||||
If you are upgrading from 1.4.3 and have set the LOGMARKER variable
|
||||
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
|
||||
you must set the new LOGFORMAT variable appropriately and remove your setting
|
||||
of LOGMARKER<br>
|
||||
<br>
|
||||
|
||||
<h3>Version 1.4.4<br>
|
||||
</h3>
|
||||
If you have zone names that are 5 characters long, you may experience
|
||||
problems starting Shorewall because the --log-prefix in a logging rule
|
||||
is too long. Upgrade to Version 1.4.4a to fix this problem..<br>
|
||||
|
||||
<h3>Version >= 1.4.2</h3>
|
||||
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:<br>
|
||||
|
||||
<ol>
|
||||
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
|
||||
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a
|
||||
transparent proxy in your local zone.</a></li>
|
||||
|
||||
</ol>
|
||||
If you have either of these cases, you will want to review the current
|
||||
documentation and change your configuration accordingly.<br>
|
||||
|
||||
<h3>Version >= 1.4.1</h3>
|
||||
|
||||
<ul>
|
||||
<li>In Version 1.4.1, Shorewall will never create rules to deal
|
||||
with traffic from a given group back to itself. The <i>multi</i> 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 'routeback' interface or host option.<2E></li>
|
||||
|
||||
<li>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.</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<blockquote>
|
||||
<ol>
|
||||
<li>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.</li>
|
||||
<li>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.</li>
|
||||
<li>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.<br>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
</blockquote>
|
||||
|
||||
<ul>
|
||||
<li> 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. </li>
|
||||
|
||||
</ul>
|
||||
|
||||
<blockquote>Example:<br>
|
||||
|
||||
<blockquote>
|
||||
<pre>/etc/shorewall/zones<br><br>z1 Zone1 The first Zone<br>z2 Zone2 The secont Zone<br><br>/etc/shorewall/interfaces<br><br>z2 eth1 192.168.1.255<br><br>/etc/shorewall/hosts<br><br>z1 eth1:192.168.1.3<br></pre>
|
||||
</blockquote>
|
||||
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:<br>
|
||||
|
||||
<blockquote>
|
||||
<pre>/etc/shorewall/policy<br><pre>z1 z2 NONE<br>z2 z1 NONE</pre></pre>
|
||||
</blockquote>
|
||||
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.<2E></blockquote>
|
||||
|
||||
<h3>Version 1.4.1<br>
|
||||
</h3>
|
||||
|
||||
<ul>
|
||||
<li>In Version 1.4.1, Shorewall will never create rules to
|
||||
deal with traffic from a given group back to itself. The <i>multi</i>
|
||||
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 'routeback' interface or host option.<2E></li>
|
||||
|
||||
</ul>
|
||||
|
||||
<h3>Version >= 1.4.0</h3>
|
||||
<b>IMPORTANT: Shorewall >=1.4.0 </b><b>requires</b> <b>the
|
||||
iproute package ('ip' utility).</b><br>
|
||||
<b>IMPORTANT: Shorewall >=1.4.0 </b><b>requires</b> <b>the
|
||||
iproute package ('ip' utility).</b><br>
|
||||
<br>
|
||||
<b>Note: </b>Unfortunately, some distributions call this package
|
||||
iproute2 which will cause the upgrade of Shorewall to fail with the
|
||||
diagnostic:<br>
|
||||
<br>
|
||||
<20> <20> <20>error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||
<br>
|
||||
<b>Note: </b>Unfortunately, some distributions call this package
|
||||
iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:<br>
|
||||
<br>
|
||||
<EFBFBD> <20> <20>error: failed dependencies:iproute is needed by shorewall-1.4.0-1
|
||||
<br>
|
||||
<br>
|
||||
This may be worked around by using the --nodeps option of rpm (rpm
|
||||
-Uvh --nodeps <shorewall rpm>).<br>
|
||||
<br>
|
||||
If you are upgrading from a version < 1.4.0, then:<br>
|
||||
|
||||
<br>
|
||||
This may be worked around by using the --nodeps option of rpm
|
||||
(rpm -Uvh --nodeps <shorewall rpm>).<br>
|
||||
<br>
|
||||
If you are upgrading from a version < 1.4.0, then:<br>
|
||||
|
||||
<ul>
|
||||
<li>The <b>noping </b>and <b>forwardping</b> interface options
|
||||
are no longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf.
|
||||
ICMP echo-request (ping) packets are treated just like any other connection
|
||||
request and are subject to rules and policies.</li>
|
||||
<li>Interface names of the form <device>:<integer>
|
||||
in /etc/shorewall/interfaces now generate a Shorewall error at startup
|
||||
(they always have produced warnings in iptables).</li>
|
||||
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
|
||||
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
|
||||
contents are determined by BOTH the interfaces and hosts files when there
|
||||
are entries for the zone in both files.</li>
|
||||
<li>The <b>routestopped</b> option in the interfaces and
|
||||
hosts file has been eliminated; use entries in the routestopped file
|
||||
instead.</li>
|
||||
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
|
||||
is no longer accepted; you must convert to using the new syntax.</li>
|
||||
<li value="6">The ALLOWRELATED variable in shorewall.conf
|
||||
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
|
||||
<li>The <b>noping </b>and <b>forwardping</b> interface
|
||||
options are no longer supported nor is the <b>FORWARDPING </b>option
|
||||
in shorewall.conf. ICMP echo-request (ping) packets are treated just
|
||||
like any other connection request and are subject to rules and policies.</li>
|
||||
<li>Interface names of the form <device>:<integer>
|
||||
in /etc/shorewall/interfaces now generate a Shorewall error at startup
|
||||
(they always have produced warnings in iptables).</li>
|
||||
<li>The MERGE_HOSTS variable has been removed from shorewall.conf.
|
||||
Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
|
||||
contents are determined by BOTH the interfaces and hosts files when
|
||||
there are entries for the zone in both files.</li>
|
||||
<li>The <b>routestopped</b> option in the interfaces
|
||||
and hosts file has been eliminated; use entries in the routestopped
|
||||
file instead.</li>
|
||||
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
|
||||
is no longer accepted; you must convert to using the new syntax.</li>
|
||||
<li value="6">The ALLOWRELATED variable in shorewall.conf
|
||||
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
|
||||
with ALLOWRELATED=Yes.</li>
|
||||
<li value="6">Late-arriving DNS replies are now dropped
|
||||
by default; there is no need for your own /etc/shorewall/common file
|
||||
simply to avoid logging these packets.</li>
|
||||
<li value="6">The 'firewall', 'functions' and 'version'
|
||||
file have been moved to /usr/share/shorewall.</li>
|
||||
<li value="6">The icmp.def file has been removed. If you
|
||||
include it from /etc/shorewall/icmpdef, you will need to modify that
|
||||
file.</li>
|
||||
|
||||
<li value="6">Late-arriving DNS replies are now dropped
|
||||
by default; there is no need for your own /etc/shorewall/common file
|
||||
simply to avoid logging these packets.</li>
|
||||
<li value="6">The 'firewall', 'functions' and 'version'
|
||||
file have been moved to /usr/share/shorewall.</li>
|
||||
<li value="6">The icmp.def file has been removed. If you
|
||||
include it from /etc/shorewall/icmpdef, you will need to modify that
|
||||
file.</li>
|
||||
|
||||
<ul>
|
||||
|
||||
|
||||
</ul>
|
||||
<li>If you followed the advice in FAQ #2 and call find_interface_address
|
||||
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
|
||||
</li>
|
||||
|
||||
<li>If you followed the advice in FAQ #2 and call find_interface_address
|
||||
in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.<br>
|
||||
</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<h3>Version 1.4.0</h3>
|
||||
|
||||
|
||||
<ul>
|
||||
<li value="8">The 'multi' interface option is no longer supported.
|
||||
<20>Shorewall will generate rules for sending packets back out the same
|
||||
interface that they arrived on in two cases:</li>
|
||||
|
||||
<li value="8">The 'multi' interface option is no longer supported.
|
||||
<EFBFBD>Shorewall will generate rules for sending packets back out the same
|
||||
interface that they arrived on in two cases:</li>
|
||||
|
||||
</ul>
|
||||
|
||||
<blockquote>
|
||||
|
||||
<blockquote>
|
||||
<ul>
|
||||
<li>There is an <u>explicit</u> policy for the source zone to
|
||||
or from the destination zone. An explicit policy names both zones and
|
||||
does not use the 'all' reserved word.</li>
|
||||
|
||||
<li>There is an <u>explicit</u> policy for the source zone
|
||||
to or from the destination zone. An explicit policy names both zones
|
||||
and does not use the 'all' reserved word.</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
||||
<ul>
|
||||
<li>There are one or more rules for traffic for the source zone
|
||||
to or from the destination zone including rules that use the 'all' 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 SOURCE
|
||||
and DESTINATION columns.</li>
|
||||
|
||||
<li>There are one or more rules for traffic for the source
|
||||
zone to or from the destination zone including rules that use the 'all'
|
||||
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 SOURCE and DESTINATION columns.</li>
|
||||
|
||||
</ul>
|
||||
</blockquote>
|
||||
|
||||
</blockquote>
|
||||
|
||||
<h3>Version >= 1.3.14</h3>
|
||||
<img src="images/BD21298_3.gif" alt="" width="13"
|
||||
<img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
<20><> <20> Beginning in version 1.3.14, Shorewall treats entries
|
||||
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
|
||||
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
|
||||
(second) <b>column</b>:<br>
|
||||
|
||||
<EFBFBD><EFBFBD> <20> Beginning in version 1.3.14, Shorewall treats entries
|
||||
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
|
||||
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
|
||||
(second) <b>column</b>:<br>
|
||||
|
||||
<ul>
|
||||
<li>Prior to 1.3.14, Shorewall would detect the FIRST
|
||||
subnet on the interface (as shown by "ip addr show <i>interface</i>")
|
||||
and would masquerade traffic from that subnet. Any other subnets that
|
||||
routed through eth1 needed their own entry in /etc/shorewall/masq to
|
||||
be masqueraded or to have SNAT applied.</li>
|
||||
<li>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.</li>
|
||||
|
||||
<li>Prior to 1.3.14, Shorewall would detect the FIRST
|
||||
subnet on the interface (as shown by "ip addr show <i>interface</i>")
|
||||
and would masquerade traffic from that subnet. Any other subnets that
|
||||
routed through eth1 needed their own entry in /etc/shorewall/masq to
|
||||
be masqueraded or to have SNAT applied.</li>
|
||||
<li>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.</li>
|
||||
|
||||
</ul>
|
||||
You will need to make a change to your configuration if:<br>
|
||||
|
||||
You will need to make a change to your configuration
|
||||
if:<br>
|
||||
|
||||
<ol>
|
||||
<li>You have one or more entries in /etc/shorewall/masq
|
||||
with an interface name in the SUBNET (second) column; and</li>
|
||||
<li>That interface connects to more than one subnetwork.</li>
|
||||
|
||||
<li>You have one or more entries in /etc/shorewall/masq
|
||||
with an interface name in the SUBNET (second) column; and</li>
|
||||
<li>That interface connects to more than one subnetwork.</li>
|
||||
|
||||
</ol>
|
||||
Two examples:<br>
|
||||
<br>
|
||||
<20><b>Example 1</b> -- Suppose that your current config is
|
||||
as follows:<br>
|
||||
<20><> <br>
|
||||
|
||||
Two examples:<br>
|
||||
<br>
|
||||
<EFBFBD><b>Example 1</b> -- Suppose that your current config
|
||||
is as follows:<br>
|
||||
<EFBFBD><EFBFBD> <br>
|
||||
|
||||
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE<43><45><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> SUBNET<45><54><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> ADDRESS<br> eth0<68><30><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> eth2<68><32><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 206.124.146.176<br> eth0<68><30><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 192.168.10.0/24<32><34><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24<32> scope link<br> 192.168.10.0/24<32> proto kernel<65> scope link<6E> src 192.168.10.254<br> [root@gateway test]#</pre>
|
||||
|
||||
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
|
||||
required.<br>
|
||||
</blockquote>
|
||||
<b>Example 2</b>-- What if your current configuration is
|
||||
like this?<br>
|
||||
|
||||
|
||||
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
|
||||
required.<br>
|
||||
</blockquote>
|
||||
<b>Example 2</b>-- What if your current configuration
|
||||
is like this?<br>
|
||||
|
||||
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE<43><45><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> SUBNET<45><54><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> ADDRESS <br> eth0<68><30><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> eth2<68><32><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24<32> scope link<br> 192.168.10.0/24<32> proto kernel<65> scope link<6E> src 192.168.10.254 <br> [root@gateway test]#</pre>
|
||||
|
||||
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
|
||||
to:<br>
|
||||
</blockquote>
|
||||
|
||||
|
||||
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
|
||||
to:<br>
|
||||
</blockquote>
|
||||
|
||||
<pre> #INTERFACE<43><45><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> SUBNET<45><54><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> ADDRESS <br> eth0<68><30><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 192.168.1.0/24<32><34><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
|
||||
<img src="images/BD21298_3.gif" alt="" width="13"
|
||||
<img src="images/BD21298_3.gif" alt="" width="13"
|
||||
height="13">
|
||||
<20><><EFBFBD> Version 1.3.14 also introduced simplified ICMP echo-request
|
||||
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
|
||||
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 /etc/shorewall/shorewall.conf
|
||||
then OLD_PING_HANDLING=Yes 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 <a href="ping.html">'Ping'
|
||||
handling documentation</a> for details.<br>
|
||||
|
||||
<EFBFBD><EFBFBD><EFBFBD> Version 1.3.14 also introduced simplified ICMP echo-request
|
||||
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
|
||||
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 /etc/shorewall/shorewall.conf
|
||||
then OLD_PING_HANDLING=Yes 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 <a href="ping.html">'Ping'
|
||||
handling documentation</a> for details.<br>
|
||||
|
||||
<h3>Version 1.3.10</h3>
|
||||
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 '--force' option:<br>
|
||||
<br>
|
||||
|
||||
<blockquote>
|
||||
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 '--force'
|
||||
option:<br>
|
||||
<br>
|
||||
|
||||
<blockquote>
|
||||
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm<70></pre>
|
||||
</blockquote>
|
||||
|
||||
</blockquote>
|
||||
|
||||
<h3>Version >= 1.3.9</h3>
|
||||
The 'functions' file has moved to /usr/lib/shorewall/functions.
|
||||
If you have an application that uses functions from that file, your
|
||||
application will need to be changed to reflect this change of location.<br>
|
||||
|
||||
The 'functions' file has moved to /usr/lib/shorewall/functions.
|
||||
If you have an application that uses functions from that file, your
|
||||
application will need to be changed to reflect this change of location.<br>
|
||||
|
||||
<h3>Version >= 1.3.8</h3>
|
||||
|
||||
<p>If you have a pair of firewall systems configured for failover
|
||||
or if you have asymmetric routing, you will need to modify
|
||||
|
||||
<p>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 NEWNOTSYN=Yes in your
|
||||
/etc/shorewall/shorewall.conf file.</p>
|
||||
|
||||
versions >= 1.3.8. Beginning with version 1.3.8,
|
||||
you must set NEWNOTSYN=Yes in your
|
||||
/etc/shorewall/shorewall.conf file.</p>
|
||||
|
||||
<h3>Version >= 1.3.7</h3>
|
||||
|
||||
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
|
||||
will need to include the following
|
||||
rules in their /etc/shorewall/icmpdef file (creating this
|
||||
file if necessary):</p>
|
||||
|
||||
|
||||
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
|
||||
will need to include the following
|
||||
rules in their /etc/shorewall/icmpdef file (creating this
|
||||
file if necessary):</p>
|
||||
|
||||
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
|
||||
|
||||
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
|
||||
command from that file since the icmp.def file is now empty.</p>
|
||||
|
||||
|
||||
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
|
||||
command from that file since the icmp.def file is now empty.</p>
|
||||
|
||||
<h3><b><a name="Bering">Upgrading </a>Bering to Shorewall >= 1.3.3</b></h3>
|
||||
|
||||
|
||||
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
|
||||
|
||||
|
||||
<ol>
|
||||
<li>Be sure you have
|
||||
a backup -- you will need to transcribe
|
||||
any Shorewall configuration changes
|
||||
that you have made to the new configuration.</li>
|
||||
<li>Replace the shorwall.lrp
|
||||
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.</li>
|
||||
<li>Edit the /var/lib/lrpkg/root.exclude.list
|
||||
file and remove the /var/lib/shorewall
|
||||
entry if present. Then do not
|
||||
<li>Be sure you
|
||||
have a backup -- you will need
|
||||
to transcribe any Shorewall configuration
|
||||
changes that you have made to the new
|
||||
configuration.</li>
|
||||
<li>Replace the
|
||||
shorwall.lrp 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.</li>
|
||||
<li>Edit the /var/lib/lrpkg/root.exclude.list
|
||||
file and remove the /var/lib/shorewall
|
||||
entry if present. Then do not
|
||||
forget to backup root.lrp !</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
<p>The .lrp that I release isn't set up for a two-interface firewall like
|
||||
Jacques's. You need to follow the <a
|
||||
href="two-interface.htm">instructions for setting up a two-interface
|
||||
firewall</a> plus you also need to add the following two Bering-specific
|
||||
rules to /etc/shorewall/rules:</p>
|
||||
|
||||
<blockquote>
|
||||
|
||||
<p>The .lrp that I release isn't set up for a two-interface firewall like
|
||||
Jacques's. You need to follow the <a
|
||||
href="two-interface.htm">instructions for setting up a two-interface
|
||||
firewall</a> plus you also need to add the following two Bering-specific
|
||||
rules to /etc/shorewall/rules:</p>
|
||||
|
||||
<blockquote>
|
||||
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
|
||||
</blockquote>
|
||||
|
||||
</blockquote>
|
||||
|
||||
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
|
||||
|
||||
<p align="left">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</p>
|
||||
|
||||
|
||||
<p align="left">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</p>
|
||||
|
||||
<ol>
|
||||
<li>
|
||||
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
|
||||
the following rule<br>
|
||||
<br>
|
||||
<font face="Courier">run_iptables -A newnotsyn
|
||||
-j RETURN # So that the connection tracking table can
|
||||
be rebuilt<br>
|
||||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> # from
|
||||
non-SYN packets after takeover.<br>
|
||||
<20></font> </p>
|
||||
</li>
|
||||
<li>
|
||||
<p align="left">Create /etc/shorewall/common (if you don't already
|
||||
have that file) and include the following:<br>
|
||||
<br>
|
||||
<font face="Courier">run_iptables -A common
|
||||
-p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT #Accept
|
||||
Acks to rebuild connection<br>
|
||||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
||||
#tracking table. <br>
|
||||
. /etc/shorewall/common.def</font> </p>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
|
||||
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
|
||||
the following rule<br>
|
||||
<br>
|
||||
<font face="Courier">run_iptables -A
|
||||
newnotsyn -j RETURN # So that the connection tracking
|
||||
table can be rebuilt<br>
|
||||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
||||
# from non-SYN packets after takeover.<br>
|
||||
<20></font> </p>
|
||||
</li>
|
||||
<li>
|
||||
|
||||
<p align="left">Create /etc/shorewall/common (if you don't already
|
||||
have that file) and include the following:<br>
|
||||
<br>
|
||||
<font face="Courier">run_iptables -A
|
||||
common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
|
||||
#Accept Acks to rebuild connection<br>
|
||||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
||||
#tracking table. <br>
|
||||
. /etc/shorewall/common.def</font> </p>
|
||||
</li>
|
||||
|
||||
</ol>
|
||||
|
||||
|
||||
<h3 align="left">Versions >= 1.3.5</h3>
|
||||
|
||||
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
|
||||
supported. </p>
|
||||
|
||||
|
||||
<p align="left">Some forms of pre-1.3.0 rules file syntax are no longer
|
||||
supported. </p>
|
||||
|
||||
<p align="left">Example 1:</p>
|
||||
|
||||
<div align="left">
|
||||
|
||||
<div align="left">
|
||||
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<p align="left">Must be replaced with:</p>
|
||||
|
||||
<div align="left">
|
||||
|
||||
<div align="left">
|
||||
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Example 2:</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">Must be replaced with:</p>
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
</div>
|
||||
|
||||
<div align="left">
|
||||
<pre> REDIRECT loc 3128 tcp 80</pre>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<h3 align="left">Version >= 1.3.2</h3>
|
||||
|
||||
<p align="left">The functions and versions files together with the 'firewall'
|
||||
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
|
||||
If you have applications that access these files, those applications
|
||||
should be modified accordingly.</p>
|
||||
|
||||
<p><font size="2"> Last updated 5/27/2003 - <a href="support.htm">Tom Eastep</a></font>
|
||||
</p>
|
||||
|
||||
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
|
||||
<20> <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
|
||||
</p>
|
||||
|
||||
<p align="left">The functions and versions files together with the 'firewall'
|
||||
symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
|
||||
If you have applications that access these files, those
|
||||
applications should be modified accordingly.</p>
|
||||
|
||||
<p><font size="2"> Last updated 6/29/2003 - <a href="support.htm">Tom
|
||||
Eastep</a></font> </p>
|
||||
|
||||
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
|
||||
<EFBFBD> <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
|
||||
</p>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
Reference in New Issue
Block a user