<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall and Routing</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="id257527"></a>Shorewall and Routing</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2005, 2006, 2007 Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id257916"></a><p>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
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Routing">Routing vs. Firewalling.</a></span></dt><dt><span class="section"><a href="#Netfilter">Routing and Netfilter</a></span></dt><dd><dl><dt><span class="section"><a href="#Ingress">Packets Entering the Firewall from Outside</a></span></dt><dt><span class="section"><a href="#Local">Packets Originating on the Firewall</a></span></dt></dl></dd><dt><span class="section"><a href="#RoutingTables">Alternate Routing Table Configuration</a></span></dt><dt><span class="section"><a href="#ProxyArp">Routing and Proxy ARP</a></span></dt><dt><span class="section"><a href="#MultiISP">Multiple Internet Connection Support in Shorewall 2.4.2 and
Later</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Routing"></a>Routing vs. Firewalling.</h2></div></div></div><p>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.</p><p>As a general principle:</p><div class="orderedlist"><ol type="1"><li><p>Routing determines where packets are to be sent.</p></li><li><p>Once routing determines where the packet is to go, the firewall
(Shorewall) determines if the packet is allowed to go there.</p></li></ol></div><p>There are ways that Shorewall can affect routing which are described
in the following sections.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Netfilter"></a>Routing and Netfilter</h2></div></div></div><p>The following diagram shows the relationship between routing
decisions and Netfilter.</p><div align="center"><img src="images/Netfilter.png" align="middle" /></div><p>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.</p><p>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.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Ingress"></a>Packets Entering the Firewall from Outside</h3></div></div></div><p>When a packet arrives from outside, it first undergoes Netfilter
PREROUTING processing. In Shorewall terms:</p><div class="orderedlist"><ol type="1"><li><p>Packets may be marked using entries in the <a class="ulink" href="???" target="_self">/etc/shorewall/tcrules</a> 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
<code class="filename">/etc/shorewall/shorewall.conf</code>. These marks may
be used to specify that the packet should be routed using an
<em class="firstterm">alternate routing table</em>; see the <a class="ulink" href="Shorewall_Squid_Usage.html" target="_self">Shorewall Squid
documentation</a> for examples.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>Marking packets then using the <span class="emphasis"><em>fwmark</em></span>
selector in your "<span class="bold"><strong>ip rule add</strong></span>"
commands should NOT be your first choice. In most cases, you can
use the <span class="emphasis"><em>from</em></span> or <span class="emphasis"><em>dev</em></span>
selector instead.</p></div></li><li><p>The destination IP address may be rewritten as a consequence
of:</p><div class="itemizedlist"><ul type="disc"><li><p>DNAT[-] rules.</p></li><li><p>REDIRECT[-] rules.</p></li><li><p>Entries in <code class="filename">/etc/shorewall/nat</code>.</p></li></ul></div></li></ol></div><p>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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Local"></a>Packets Originating on the Firewall</h3></div></div></div><p>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:</p><div class="orderedlist"><ol type="1"><li><p>Packets may be marked using entries in the <a class="ulink" href="???" target="_self">/etc/shorewall/tcrules</a> 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.</p></li><li><p>The destination IP address may be rewritten as a consequence
of:</p><div class="itemizedlist"><ul type="disc"><li><p>DNAT[-] rules that specify $FW as the SOURCE.</p></li><li><p>Entries in <code class="filename">/etc/shorewall/nat</code> that
have "Yes" in LOCAL column.</p></li></ul></div></li></ol></div><p>So again in this case, the only influence that Shorewall has over
the packet destination is NAT or marking.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="RoutingTables"></a>Alternate Routing Table Configuration</h2></div></div></div><p>The Shorewall 2.x <a class="ulink" href="http://www.shorewall.net/2.0/Shorewall_Squid_Usage.html#Local" target="_self">Shorewall
Squid documentation</a> shows how alternate routing tables can be
created and used. That documentation shows how you can use logic in
<code class="filename">/etc/shorewall/init</code> 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 (<code class="filename">/etc/init.d/shorewall</code>) to
configure your alternate routing table at boot time and that <span class="bold"><strong>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.</strong></span></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ProxyArp"></a>Routing and Proxy ARP</h2></div></div></div><p>There is one instance where Shorewall creates main routing table
entries. When an entry in <code class="filename">/etc/shorewall/proxyarp</code>
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. <span class="bold"><strong>This is the only case
where Shorewall directly manipulates the main routing
table</strong></span>.</p><p>Example:</p><p><code class="filename">/etc/shorewall/proxyarp</code>:</p><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
206.124.146.177 eth1 eth0 No
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre><p>The above entry will cause Shorewall to execute the following
command:</p><pre class="programlisting"><span class="bold"><strong>ip route add 206.124.146.177 dev eth1</strong></span></pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="MultiISP"></a>Multiple Internet Connection Support in Shorewall 2.4.2 and
Later</h2></div></div></div><p>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.</p><p>Shorewall multi-ISP support is now covered in a <a class="ulink" href="MultiISP.html" target="_self">separate article</a>.</p></div></div></body></html>
