shorewall_code/Shorewall-docs2/Shorewall_and_Routing.xml

<?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">
<article>
  <!--$Id$-->

  <articleinfo>
    <title>Shorewall and Routing</title>

    <authorgroup>
      <author>
        <firstname>Tom</firstname>

        <surname>Eastep</surname>
      </author>
    </authorgroup>

    <pubdate>2005-05-15</pubdate>

    <copyright>
      <year>2005</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>
    <title>Routing vs. Firewalling.</title>

    <para>One of the most misunderstood aspects of Shorewall is its
    releationship 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>
    <title>Routing and Netfilter</title>

    <para>The following diagram shows the relationship between routing
    decisions and Netfilter.</para>

    <graphic 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>
      <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="???">/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>
      <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="???">/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>
    <title>Alternate Routing Table Configuration</title>

    <para>The <ulink url="Shorewall_Squid_Usage.html">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.3.</emphasis> </para>
  </section>

  <section>
    <title>Routing and Proxy ARP</title>

    <para>There is one instance where Shorewall creates 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 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
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</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>
    <title>Routing with Shorewall 2.3.3 and Later</title>

    <para>Beginning with Shorewall 2.2.3, 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>

    <warning>
      <para>As of this writing, I know of no distribution that is shipping a
      kernel or iptables with the ROUTE target patch included. This means that
      you must patch and build your own kernel and iptables. </para>
    </warning>

    <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
    determination.</para>

    <para>Routing with Shorewall is specified through entries in
    /etc/shorewall/routes. Columns in this file are as follows:</para>

    <glosslist>
      <glossentry>
        <glossterm>SOURCE</glossterm>

        <glossdef>
          <para>Source of the packet. May be any of the following:</para>

          <itemizedlist>
            <listitem>
              <para>A host or network address</para>
            </listitem>

            <listitem>
              <para>A network interface name.</para>
            </listitem>

            <listitem>
              <para>The name of an ipset prefaced with "+"</para>
            </listitem>

            <listitem>
              <para>$FW (for packets originating on the firewall)</para>
            </listitem>

            <listitem>
              <para>A MAC address in Shorewall format</para>
            </listitem>

            <listitem>
              <para>A range of IP addresses (assuming that your kernel and
              iptables support range match)</para>
            </listitem>

            <listitem>
              <para>A network interface name followed by ":" and an address or
              address range.</para>
            </listitem>
          </itemizedlist>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>DEST</glossterm>

        <glossdef>
          <para>Destination of the packet. May be any of the following:</para>

          <itemizedlist>
            <listitem>
              <para>A host or network address</para>
            </listitem>

            <listitem>
              <para>A network interface name (determined from routing
              table(s))</para>
            </listitem>

            <listitem>
              <para>The name of an ipset prefaced with "+"</para>
            </listitem>

            <listitem>
              <para>A network interface name followed by ":" and an address or
              address range.</para>
            </listitem>
          </itemizedlist>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>PROTO</glossterm>

        <glossdef>
          <para>Protocol - Must be a protocol listed in /etc/protocols, a
          number or "ipp2p", a number, or "all". "ipp2p" require ipp2p match
          support in your kernel and iptables.</para>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>PORT(S)</glossterm>

        <glossdef>
          <para>Destination Ports. A comma-separated list of Port names (from
          /etc/services), port numbers or port ranges; if the protocol is
          "icmp", this column is interpreted as the destination
          icmp-type(s).</para>

          <para>If the protocol is ipp2p, this column is interpreted as an
          ipp2p option without the leading "--" (example "bit" for
          bit-torrent). If no PORT is given, "ipp2p" is assumed.</para>

          <para>This column is ignored if PROTOCOL = all but must be entered
          if any of the following field is supplied. In that case, it is
          suggested that this field contain "-"</para>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>SOURCE PORT(S)</glossterm>

        <glossdef>
          <para>Optional) Source port(s). If omitted, any source port is
          acceptable. Specified as a comma-separated list of port names, port
          numbers or port ranges. </para>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>INTERFACE</glossterm>

        <glossdef>
          <para>The interface that the packet is to be routed out of. If you
          do not specify this field then you must place "-" in this column and
          enter an IP address in the GATEWAY column.</para>
        </glossdef>
      </glossentry>

      <glossentry>
        <glossterm>GATEWAY</glossterm>

        <glossdef>
          <para>The gateway that the packet is to be forewarded
          through.</para>
        </glossdef>
      </glossentry>
    </glosslist>

    <para>The idea here is that traffic that matches the SOURCE, DEST, PROTO,
    PORT(S) and SOURCE PORT(S) columns is routed out of the INTERFACE through
    the optional GATEWAY.</para>

    <blockquote>
      <para>Example:</para>

      <para>Your local interface is eth1 and your DMZ interface is eth2. You
      want to run Squid as a transparent proxy for HTTP on 192.168.3.22 in
      your DMZ. You would use the following entry in
      /etc/shorewall/routes:</para>

      <programlisting>#SOURCE                 DEST            PROTO   PORT(S) SOURCE  INTERFACE       GATEWAY
#                                                       PORT(S)
eth1                    0.0.0.0/0       tcp     80      -       eth1            192.168.3.22</programlisting>

      <para>This entry specifies that "traffic coming in through eth1 to TCP
      port 80 is to be routed out of eth1 to gateway 192.168.3.22".</para>
    </blockquote>

    <para>Note that entries in the /etc/shorewall/routes file override the
    routing specified in your routing tables. These rules generate Netfilter
    rules in the mangle tables FORWARD chain or OUTPUT chain (see figure
    above).</para>
  </section>
</article>