mirror of
https://gitlab.com/shorewall/code.git
synced 2024-11-22 07:33:43 +01:00
More doc updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2142 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
parent
2cdb52aa50
commit
bb6f10818e
@ -17,7 +17,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-10</pubdate>
|
||||
<pubdate>2005-05-18</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2005</year>
|
||||
@ -1263,7 +1263,8 @@ LOGBURST=""</programlisting>
|
||||
<para>Anyone with two Internet connections MUST read and understand
|
||||
<ulink url="Shorewall_and_Routing.html">this article on Shorewall and
|
||||
Routing</ulink>. If you don't, you will be completely lost trying to
|
||||
make this work.</para>
|
||||
make this work. And that article should be all that you need if you
|
||||
are running Shorewall 2.3.2 or later.</para>
|
||||
</important>
|
||||
|
||||
<para>Setting this up in Shorewall is easy; setting up the routing is a
|
||||
@ -2249,4 +2250,4 @@ Verifying Configuration...
|
||||
...</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
</article>
|
||||
</article>
|
@ -80,7 +80,7 @@
|
||||
|
||||
<para>The following figure represents a Proxy ARP environment.</para>
|
||||
|
||||
<graphic fileref="images/proxyarp.png" />
|
||||
<graphic align="center" fileref="images/proxyarp.png" />
|
||||
|
||||
<para>Proxy ARP can be used to make the systems with addresses
|
||||
130.252.100.18 and 130.252.100.19 appear to be on the upper
|
||||
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-16</pubdate>
|
||||
<pubdate>2005-05-19</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2003-2005</year>
|
||||
@ -173,7 +173,7 @@ REDIRECT loc 3128 tcp www - !206.124.146.
|
||||
a web server running on 192.168.1.3. It is assumed that web access is
|
||||
already enabled from the local zone to the internet.</para>
|
||||
|
||||
<para>If you are running a Shorewall version earlier than 2.3.3 OR your
|
||||
<para>If you are running a Shorewall version earlier than 2.3.2 OR your
|
||||
kernel and/or iptables do not have <ulink
|
||||
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink> then:</para>
|
||||
@ -211,30 +211,29 @@ fi</command></programlisting>
|
||||
|
||||
<programlisting><command>run_and_save_command "/etc/shorewall/addroutes"</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.2 or later:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Add this entry to your /etc/shorewall/providers file.</para>
|
||||
|
||||
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
|
||||
Squid 1 202 - eth1 192.168.1.3 -</programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>Regardless of your Shorewall version, you need the
|
||||
following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>In <filename>/etc/shorewall/start</filename> add:</para>
|
||||
|
||||
<programlisting><command>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.3 or later and your kernel and
|
||||
iptables have <ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE
|
||||
target support</ulink> then add this entry to
|
||||
/etc/shorewall/routes:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
|
||||
# PORT(S)
|
||||
eth1 0.0.0.0/0 tcp 80 - - eth1 192.168.1.3</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>Regardless of your Shorewall version or your kernel and iptables
|
||||
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink>, you need the following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>In
|
||||
<filename><filename>/etc/shorewall/interfaces</filename></filename>:</para>
|
||||
@ -285,7 +284,7 @@ chkconfig --level 35 iptables on</command></programlisting>
|
||||
192.0.2.177. You want to run both a web server and Squid on that system.
|
||||
Your DMZ interface is eth1 and your local interface is eth2.</para>
|
||||
|
||||
<para>If you are running a Shorewall version earlier than 2.3.3 OR your
|
||||
<para>If you are running a Shorewall version earlier than 2.3.2 OR your
|
||||
kernel and/or iptables do not have <ulink
|
||||
url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink> then:</para>
|
||||
@ -323,7 +322,27 @@ fi</command></programlisting>
|
||||
|
||||
<programlisting><command>run_and_save_command "/etc/shorewall/addroutes"</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.2 or later:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Add this entry in
|
||||
<filename>/etc/shorewall/providers</filename>:</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
|
||||
Squid 1 202 - eth1 192.0.2.177 -
|
||||
</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>Regardless of your Shorewall version, you need the
|
||||
following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Do <emphasis role="bold">one</emphasis> of the
|
||||
following:</para>
|
||||
@ -354,24 +373,7 @@ fi</command></programlisting>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>If you are running Shorewall 2.3.3 or later and your kernel and
|
||||
iptables have <ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE
|
||||
target support</ulink> then add this entry to
|
||||
/etc/shorewall/routes:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>#SOURCE DEST PROTO PORT(S) SOURCE TEST INTERFACE GATEWAY
|
||||
# PORT(S)
|
||||
eth2 0.0.0.0/0 tcp 80 - - eth1 192.0.2.177</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>Regardless of your Shorewall version or your kernel and iptables
|
||||
<ulink url="Shorewall_and_Routing.html#RouteTarget">ROUTE target
|
||||
support</ulink>, you need the following:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>In <filename>/etc/shorewall/rules</filename>, you will
|
||||
need:</para>
|
||||
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-18</pubdate>
|
||||
<pubdate>2005-05-19</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2005</year>
|
||||
@ -178,7 +178,7 @@
|
||||
configure your alternate routing table at boot time and that <emphasis
|
||||
role="bold">other than as described in the previous section, there is no
|
||||
connection between Shorewall and routing when using Shorewall versions
|
||||
prior to 2.3.3.</emphasis></para>
|
||||
prior to 2.3.2.</emphasis></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -206,19 +206,21 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Multiple Internet Connection Support in Shorewall 2.3.3 and
|
||||
<title>Multiple Internet Connection Support in Shorewall 2.3.2 and
|
||||
Later</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.3.3, support is included for multiple
|
||||
<para>Beginning with Shorewall 2.3.2, support is included for multiple
|
||||
internet connections.</para>
|
||||
|
||||
<section>
|
||||
<title>Overview</title>
|
||||
|
||||
<para>Let's assume that a firewall is connected via two separate
|
||||
ethernet interfaces to two different ISP as in the following
|
||||
ethernet interfaces to two different ISPs as in the following
|
||||
diagram.</para>
|
||||
|
||||
<graphic fileref="images/TwoISPs.png" />
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>eth0 connects to ISP1. The IP address of eth0 is
|
||||
@ -272,8 +274,21 @@
|
||||
</itemizedlist>
|
||||
</caution>
|
||||
|
||||
<para>Use of this feature requires that your kernel and iptables support
|
||||
CONNMARK target and conntrack match as well as extended MARK support. It
|
||||
does NOT require the ROUTE target extension.</para>
|
||||
|
||||
<warning>
|
||||
<para>The current version of iptables (1.3.1) is broken with respect
|
||||
to CONNMARK and iptables-save/iptables-restore. This means that if you
|
||||
configure multiple ISPs, <command>shorewall restore</command> will
|
||||
fail. You must patch your iptables using the patch at <ulink
|
||||
url="http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff">http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff</ulink>.</para>
|
||||
</warning>
|
||||
|
||||
<para>The <filename>/etc/shorewall/providers</filename> file can also be
|
||||
used in other routing senarios. See the Squid documentation for an
|
||||
used in other routing senarios. See the <ulink
|
||||
url="Shorewall_Squid_Usage.html">Squid documentation</ulink> for an
|
||||
example.</para>
|
||||
</section>
|
||||
|
||||
@ -358,7 +373,7 @@
|
||||
<glossdef>
|
||||
<para>If specified, connections FROM this interface are to
|
||||
be tracked so that responses may be routed back out this
|
||||
same interface. </para>
|
||||
same interface.</para>
|
||||
|
||||
<para>You want specify 'track' if internet hosts will be
|
||||
connecting to local servers through this provider.</para>
|
||||
@ -384,18 +399,41 @@
|
||||
<title>Example</title>
|
||||
|
||||
<para>The configuration in the figure at the top of this section would
|
||||
be specified as follows:</para>
|
||||
be specified in <filename>/etc/shorewall/providers</filename> as
|
||||
follows:</para>
|
||||
|
||||
<programlisting>#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
|
||||
ISP1 1 1 main eth0 206.124.146.254 track,balance
|
||||
ISP2 2 2 main eth1 130.252.99.254 track,balance</programlisting>
|
||||
|
||||
<para>Other configuration files go something like this:</para>
|
||||
|
||||
<para><filename>/etc/shorewall/interfaces</filename>:</para>
|
||||
|
||||
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
||||
net eth0 detect …
|
||||
net eth1 detect …</programlisting>
|
||||
|
||||
<para><filename>/etc/shorewall/policy</filename>:</para>
|
||||
|
||||
<programlisting>#SOURCE DESTINATION POLICY LIMIT:BURST
|
||||
net net DROP</programlisting>
|
||||
|
||||
<para>If you have masqueraded hosts, be sure to update
|
||||
<filename>/etc/shorewall/masq</filename> to masquerade to both ISPs. For
|
||||
example, if you masquerade all hosts connected to <filename
|
||||
class="devicefile">eth2</filename> then:</para>
|
||||
|
||||
<programlisting>#INTERFACE SUBNET ADDRESS
|
||||
eth0 eth2 206.124.146.176
|
||||
eth1 eth2 130.252.99.27</programlisting>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section id="RouteTarget">
|
||||
<title>Experimental Routing with Shorewall 2.3.3 and Later</title>
|
||||
<title>Experimental Routing with Shorewall 2.3.2 and Later</title>
|
||||
|
||||
<para>Beginning with Shorewall 2.2.3, Shorewall is integrated with the
|
||||
<para>Beginning with Shorewall 2.3.2, Shorewall is integrated with the
|
||||
ROUTE target extension available from Netfilter Patch-O-Matic-NG (<ulink
|
||||
url="http://www.netfilter.org">http://www.netfilter.org</ulink>).</para>
|
||||
|
||||
@ -411,7 +449,7 @@ ISP2 2 2 main eth1 130.252.99.254 track,ba
|
||||
|
||||
<para>See <ulink url="FAQ.htm#faq42">Shorewall FAQ 42</ulink> for
|
||||
information about determining if your kernel and iptables have this
|
||||
support enabled. You must be running Shorewall 2.3.3 or later to make this
|
||||
support enabled. You must be running Shorewall 2.3.2 or later to make this
|
||||
determination.</para>
|
||||
|
||||
<para>Routing with Shorewall is specified through entries in
|
||||
|
@ -15,10 +15,10 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-05-28</pubdate>
|
||||
<pubdate>2005-05-19</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
<year>2004-2005</year>
|
||||
|
||||
<holder>Thomas M. Eastep</holder>
|
||||
</copyright>
|
||||
@ -29,7 +29,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 url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
||||
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||||
License</ulink></quote>.</para>
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
@ -40,7 +41,8 @@
|
||||
Suppose that two organizations, A and B, need to be linked and that both
|
||||
organizations have allocated the 192.168.1.0/24 subnetwork. There is a
|
||||
need to connect the two networks so that all systems in A can access the
|
||||
192.168.1.0/24 network in B and vice versa without any re-addressing.</para>
|
||||
192.168.1.0/24 network in B and vice versa without any
|
||||
re-addressing.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -69,7 +71,8 @@
|
||||
<listitem>
|
||||
<para>Your kernel must have NETMAP support. 2.6 Kernels have NETMAP
|
||||
support without patching while 2.4 kernels must be patched using
|
||||
Patch-O-Matic from <ulink url="http://www.netfilter.org">netfilter.org</ulink>.</para>
|
||||
Patch-O-Matic from <ulink
|
||||
url="http://www.netfilter.org">netfilter.org</ulink>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
@ -83,8 +86,9 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>Network mapping is defined using the <filename>/etc/shorewall/netmap</filename>
|
||||
file. Columns in this file are:</para>
|
||||
<para>Network mapping is defined using the
|
||||
<filename>/etc/shorewall/netmap</filename> file. Columns in this file
|
||||
are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
@ -94,12 +98,12 @@
|
||||
<para>Must be DNAT or SNAT.</para>
|
||||
|
||||
<para>If DNAT, traffic entering INTERFACE and addressed to NET1 has
|
||||
it's destination address rewritten to the corresponding address
|
||||
in NET2.</para>
|
||||
it's destination address rewritten to the corresponding address in
|
||||
NET2.</para>
|
||||
|
||||
<para>If SNAT, traffic leaving INTERFACE with a source address in
|
||||
NET1 has it's source address rewritten to the corresponding
|
||||
address in NET2.</para>
|
||||
NET1 has it's source address rewritten to the corresponding address
|
||||
in NET2.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -107,7 +111,8 @@
|
||||
<term>NET1</term>
|
||||
|
||||
<listitem>
|
||||
<para>Must be expressed in CIDR format (e.g., 192.168.1.0/24).</para>
|
||||
<para>Must be expressed in CIDR format (e.g.,
|
||||
192.168.1.0/24).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -116,7 +121,8 @@
|
||||
|
||||
<listitem>
|
||||
<para>A firewall interface. This interface must have been defined in
|
||||
<ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
|
||||
<ulink
|
||||
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -132,15 +138,34 @@
|
||||
<para>Referring to the figure above, lets suppose that systems in the top
|
||||
cloud are going to access the 192.168.1.0/24 network in the bottom cloud
|
||||
using addresses in 10.10.10.0/24 and that systems in the bottom could will
|
||||
access 192.168.1.0/24 in the top could using addresses in 10.10.11.0.<important><para>You
|
||||
must arrange for routing as follows:</para><itemizedlist><listitem><para>Traffic
|
||||
from the top cloud to 10.10.10.0/24 must be routed to eth0 on firewall 1.</para></listitem><listitem><para>Firewall
|
||||
1 must route traffic to 10.10.10.0/24 through firewall 2.</para></listitem><listitem><para>Traffic
|
||||
from the bottom cloud to 10.10.11.0/24 must be routed to eth0 on firewall
|
||||
2.</para></listitem><listitem><para>Firewall 2 must route traffic to
|
||||
10.10.11.0/24 through firewall 1.</para></listitem></itemizedlist></important>
|
||||
The entries in <filename><filename>/etc/shorewall/netmap</filename></filename>
|
||||
in firewall1 would be as follows:</para>
|
||||
access 192.168.1.0/24 in the top could using addresses in
|
||||
10.10.11.0.<important>
|
||||
<para>You must arrange for routing as follows:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Traffic from the top cloud to 10.10.10.0/24 must be routed
|
||||
to eth0 on firewall 1.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Firewall 1 must route traffic to 10.10.10.0/24 through
|
||||
firewall 2.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Traffic from the bottom cloud to 10.10.11.0/24 must be
|
||||
routed to eth0 on firewall 2.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Firewall 2 must route traffic to 10.10.11.0/24 through
|
||||
firewall 1.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</important> The entries in
|
||||
<filename><filename>/etc/shorewall/netmap</filename></filename> in
|
||||
firewall1 would be as follows:</para>
|
||||
|
||||
<programlisting>#TYPE NET1 INTERFACE NET2
|
||||
SNAT 192.168.1.0/24 vpn 10.10.11.0/24 #RULE 1A
|
||||
@ -160,44 +185,132 @@ SNAT 192.168.1.0/24 vpn 10.10.10.0/24 #RULE 2B</programlist
|
||||
<para>In order to make this connection, the client attempts a connection
|
||||
to 10.10.10.27. The following table shows how the source and destination
|
||||
IP addresses are modified as requests are sent and replies are returned.
|
||||
The RULE column refers to the above <filename>/etc/shorewall/netmap</filename>
|
||||
entries and gives the rule which transforms the source and destination
|
||||
IP addresses to those shown on the next line.
|
||||
<informaltable><tgroup cols="5"><thead><row><entry>FROM</entry><entry>TO</entry><entry>SOURCE
|
||||
IP ADDRESS</entry><entry>DESTINATION IP ADDRESS</entry><entry>RULE</entry></row></thead><tbody><row><entry>192.168.1.4
|
||||
in upper cloud</entry><entry>Firewall 1</entry><entry>192.168.1.4</entry><entry>10.10.10.27</entry><entry>1A</entry></row><row><entry>Firewall
|
||||
1</entry><entry>Firewall 2</entry><entry>10.10.11.4</entry><entry>10.10.10.27</entry><entry>2A</entry></row><row><entry>Filrewall
|
||||
2</entry><entry>192.168.1.27 in lower cloud</entry><entry>10.10.11.4</entry><entry>192.168.1.27</entry><entry></entry></row><row><entry>192.168.1.27
|
||||
in the lower cloud</entry><entry>Firewall 2</entry><entry>192.168.1.27</entry><entry>10.10.11.4</entry><entry>2B</entry></row><row><entry>Firewall
|
||||
2</entry><entry>Firewall 1</entry><entry>10.10.10.27</entry><entry>10.10.11.4</entry><entry>1B</entry></row><row><entry>Firewall
|
||||
1</entry><entry>192.168.1.4 in upper cloud</entry><entry>10.10.10.27</entry><entry>192.168.1.4</entry><entry></entry></row></tbody></tgroup></informaltable></para>
|
||||
The RULE column refers to the above
|
||||
<filename>/etc/shorewall/netmap</filename> entries and gives the rule
|
||||
which transforms the source and destination IP addresses to those shown
|
||||
on the next line. <informaltable>
|
||||
<tgroup cols="5">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>FROM</entry>
|
||||
|
||||
<entry>TO</entry>
|
||||
|
||||
<entry>SOURCE IP ADDRESS</entry>
|
||||
|
||||
<entry>DESTINATION IP ADDRESS</entry>
|
||||
|
||||
<entry>RULE</entry>
|
||||
</row>
|
||||
</thead>
|
||||
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>192.168.1.4 in upper cloud</entry>
|
||||
|
||||
<entry>Firewall 1</entry>
|
||||
|
||||
<entry>192.168.1.4</entry>
|
||||
|
||||
<entry>10.10.10.27</entry>
|
||||
|
||||
<entry>1A</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Firewall 1</entry>
|
||||
|
||||
<entry>Firewall 2</entry>
|
||||
|
||||
<entry>10.10.11.4</entry>
|
||||
|
||||
<entry>10.10.10.27</entry>
|
||||
|
||||
<entry>2A</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Filrewall 2</entry>
|
||||
|
||||
<entry>192.168.1.27 in lower cloud</entry>
|
||||
|
||||
<entry>10.10.11.4</entry>
|
||||
|
||||
<entry>192.168.1.27</entry>
|
||||
|
||||
<entry></entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>192.168.1.27 in the lower cloud</entry>
|
||||
|
||||
<entry>Firewall 2</entry>
|
||||
|
||||
<entry>192.168.1.27</entry>
|
||||
|
||||
<entry>10.10.11.4</entry>
|
||||
|
||||
<entry>2B</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Firewall 2</entry>
|
||||
|
||||
<entry>Firewall 1</entry>
|
||||
|
||||
<entry>10.10.10.27</entry>
|
||||
|
||||
<entry>10.10.11.4</entry>
|
||||
|
||||
<entry>1B</entry>
|
||||
</row>
|
||||
|
||||
<row>
|
||||
<entry>Firewall 1</entry>
|
||||
|
||||
<entry>192.168.1.4 in upper cloud</entry>
|
||||
|
||||
<entry>10.10.10.27</entry>
|
||||
|
||||
<entry>192.168.1.4</entry>
|
||||
|
||||
<entry></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable></para>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Author's Notes</title>
|
||||
<title>Author's Notes</title>
|
||||
|
||||
<para>This could all be made a bit simpler by eliminating the TYPE field
|
||||
and have Shorewall generate both the SNAT and DNAT rules from a single
|
||||
entry. I have chosen to include the TYPE in order to make the
|
||||
implementation a bit more flexible. If you find cases where you can use an
|
||||
SNAT or DNAT entry by itself, please let <ulink
|
||||
url="mailto:webmaster@shorewall.net">me</ulink> know and I'll add the
|
||||
url="mailto:webmaster@shorewall.net">me</ulink> know and I'll add the
|
||||
example to this page.</para>
|
||||
|
||||
<para>In the previous section, the table in the example contains a bit of
|
||||
a lie. Because of Netfilter's connection tracking, rules 2B and 1A
|
||||
aren't needed to handle the replies. They ARE needed though for hosts
|
||||
in the bottom cloud to be able to establish connections with the
|
||||
192.168.1.0/24 network in the top cloud.</para>
|
||||
a lie. Because of Netfilter's connection tracking, rules 2B and 1B aren't
|
||||
needed to handle the replies. They ARE needed though for hosts in the
|
||||
bottom cloud to be able to establish connections with the 192.168.1.0/24
|
||||
network in the top cloud.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Can't I do this with one router? Why do I need two?</title>
|
||||
<title>Can't I do this with one router? Why do I need two?</title>
|
||||
|
||||
<para>The single router would have to be able to route to two different
|
||||
192.168.1.0/24 networks. In Netfilter parlance, that would mean that the
|
||||
destination IP address would have to be rewritten after the packet had
|
||||
been routed; Netfilter doesn't have that capability.</para>
|
||||
been routed; Netfilter doesn't have that capability.</para>
|
||||
|
||||
<para>Note that if you do it with two routers, then adding a third is
|
||||
easy. There's no reason why you can't have yet another network that is
|
||||
192.168.1.0/24 on the inside, but you can allocated it 10.10.12.0/24 for
|
||||
everybody else.</para>
|
||||
</section>
|
||||
</article>
|
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2005-05-14</pubdate>
|
||||
<pubdate>2005-05-19</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2005</year>
|
||||
@ -40,6 +40,13 @@
|
||||
</legalnotice>
|
||||
</articleinfo>
|
||||
|
||||
<section>
|
||||
<title>Notice</title>
|
||||
|
||||
<para>Effective May 18, 2005 the original Shorewall designer and author is
|
||||
no longer providing Shorewall support.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Before Reporting a Problem or Asking a Question</title>
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user