mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-04 21:41:15 +01:00
665381f194
Signed-off-by: Tom Eastep <teastep@shorewall.net>
231 lines
8.5 KiB
XML
231 lines
8.5 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article>
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Shorewall and Routing</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
|
|
|
<copyright>
|
|
<year>2005</year>
|
|
|
|
<year>2006</year>
|
|
|
|
<year>2007</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
|
License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section id="Routing">
|
|
<title>Routing vs. Firewalling.</title>
|
|
|
|
<para>One of the most misunderstood aspects of Shorewall is its
|
|
relationship with routing. This article attempts to clear some of the fog
|
|
that surrounds this issue.</para>
|
|
|
|
<para>As a general principle:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Routing determines where packets are to be sent.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Once routing determines where the packet is to go, the firewall
|
|
(Shorewall) determines if the packet is allowed to go there.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>There are ways that Shorewall can affect routing which are described
|
|
in the following sections.</para>
|
|
</section>
|
|
|
|
<section id="Netfilter">
|
|
<title>Routing and Netfilter</title>
|
|
|
|
<para>The following diagram shows the relationship between routing
|
|
decisions and Netfilter.</para>
|
|
|
|
<graphic align="center" fileref="images/Netfilter.png"/>
|
|
|
|
<para>The light blue boxes indicate where routing decisions are made. Upon
|
|
exit from one of these boxes, if the packet is being sent to another
|
|
system then the interface and the next hop have been uniquely
|
|
determined.</para>
|
|
|
|
<para>The green boxes show where Netfilter processing takes place (as
|
|
directed by Shorewall). You will notice that there are two different paths
|
|
through this maze, depending on where the packet originates. We will look
|
|
at each of these separately.</para>
|
|
|
|
<section id="Ingress">
|
|
<title>Packets Entering the Firewall from Outside</title>
|
|
|
|
<para>When a packet arrives from outside, it first undergoes Netfilter
|
|
PREROUTING processing. In Shorewall terms:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Packets may be marked using entries in the <ulink
|
|
url="manpages/shorewall-mangle.html">/etc/shorewall/mangle</ulink>
|
|
(<ulink
|
|
url="manpages4/manpages/shorewall-tcrules.html">/etc/shorewall/tcrules</ulink>)
|
|
file. Entries in that file containing ":P" in the mark column are
|
|
applied here as are rules that default to the
|
|
MARK_IN_FORWARD_CHAIN=No setting in
|
|
<filename>/etc/shorewall/shorewall.conf</filename>. These marks may
|
|
be used to specify that the packet should be routed using an
|
|
<firstterm>alternate routing table</firstterm>; see the <ulink
|
|
url="Shorewall_Squid_Usage.html">Shorewall Squid
|
|
documentation</ulink> for examples.</para>
|
|
|
|
<caution>
|
|
<para>Marking packets then using the <emphasis>fwmark</emphasis>
|
|
selector in your "<emphasis role="bold">ip rule add</emphasis>"
|
|
commands should NOT be your first choice. In most cases, you can
|
|
use the <emphasis>from</emphasis> or <emphasis>dev</emphasis>
|
|
selector instead.</para>
|
|
</caution>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The destination IP address may be rewritten as a consequence
|
|
of:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>DNAT[-] rules.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>REDIRECT[-] rules.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Entries in <filename>/etc/shorewall/nat</filename>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>So the only influence that Shorewall has over where these packets
|
|
go is via NAT or by marking them so that they may be routed using an
|
|
alternate routing table.</para>
|
|
</section>
|
|
|
|
<section id="Local">
|
|
<title>Packets Originating on the Firewall</title>
|
|
|
|
<para>Processing of packets that originate on the firewall itself are
|
|
initially routed using the default routing table then passed through the
|
|
OUTPUT chains. Shorewall can influence what happens here:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Packets may be marked using entries in the <ulink
|
|
url="manpages4/manpages/shorewall-tcrules.html">/etc/shorewall/mangle</ulink>
|
|
(<ulink
|
|
url="manpages4/manpages/shorewall-tcrules.html">/etc/shorewall/tcrules</ulink>)
|
|
file (rules with "$FW" in the SOURCE column). These marks may be
|
|
used to specify that the packet should be re-routed using an
|
|
alternate routing table.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>The destination IP address may be rewritten as a consequence
|
|
of:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>DNAT[-] rules that specify $FW as the SOURCE.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Entries in <filename>/etc/shorewall/nat</filename> that
|
|
have "Yes" in LOCAL column.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>So again in this case, the only influence that Shorewall has over
|
|
the packet destination is NAT or marking.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section id="RoutingTables">
|
|
<title>Alternate Routing Table Configuration</title>
|
|
|
|
<para>The Shorewall 2.x <ulink
|
|
url="http://www.shorewall.net/2.0/Shorewall_Squid_Usage.html#Local">Shorewall
|
|
Squid documentation</ulink> shows how alternate routing tables can be
|
|
created and used. That documentation shows how you can use logic in
|
|
<filename>/etc/shorewall/init</filename> to create and populate an
|
|
alternate table and to add a routing rule for its use. It is fine to use
|
|
that technique so long as you understand that you are basically just using
|
|
the Shorewall init script (<filename>/etc/init.d/shorewall</filename>) to
|
|
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.2.</emphasis></para>
|
|
</section>
|
|
|
|
<section id="ProxyArp">
|
|
<title>Routing and Proxy ARP</title>
|
|
|
|
<para>There is one instance where Shorewall creates main routing table
|
|
entries. When an entry in <filename>/etc/shorewall/proxyarp</filename>
|
|
contains "No" in the HAVEROUTE column then Shorewall will create a host
|
|
route to the IP address listed in the ADDRESS column through the interface
|
|
named in the INTERFACE column. <emphasis role="bold">This is the only case
|
|
where Shorewall directly manipulates the main routing
|
|
table</emphasis>.</para>
|
|
|
|
<para>Example:</para>
|
|
|
|
<para><filename>/etc/shorewall/proxyarp</filename>:</para>
|
|
|
|
<programlisting>#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
|
|
206.124.146.177 eth1 eth0 No</programlisting>
|
|
|
|
<para>The above entry will cause Shorewall to execute the following
|
|
command:</para>
|
|
|
|
<programlisting><emphasis role="bold">ip route add 206.124.146.177 dev eth1</emphasis></programlisting>
|
|
</section>
|
|
|
|
<section id="MultiISP">
|
|
<title>Multiple Internet Connection Support in Shorewall 2.4.2 and
|
|
Later</title>
|
|
|
|
<para>Beginning with Shorewall 2.3.2, support is included for multiple
|
|
Internet connections. If you wish to use this feature, we recommend
|
|
strongly that you upgrade to version 2.4.2 or later.</para>
|
|
|
|
<para>Shorewall multi-ISP support is now covered in a <ulink
|
|
url="MultiISP.html">separate article</ulink>.</para>
|
|
</section>
|
|
</article>
|