shorewall_code/docs/shorewall_setup_guide.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="IPIP">
  <!--$Id$-->

  <articleinfo>
    <title>Shorewall Setup Guide</title>

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

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

    <pubdate><?dbtimestamp format="Y/m/d"?></pubdate>

    <copyright>
      <year>2001-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>

  <caution>
    <para><emphasis role="bold">This article applies to Shorewall 3.0 and
    later. If you are running a version of Shorewall earlier than Shorewall
    3.0.0 then please see the documentation for that
    release.</emphasis></para>
  </caution>

  <section id="Introduction">
    <title>Introduction</title>

    <para>This guide is intended for users who are setting up Shorewall in an
    environment where a set of public IP addresses must be managed or who want
    to know more about Shorewall than is contained in the <ulink
    url="shorewall_quickstart_guide.htm">single-address guides</ulink>.
    Because the range of possible applications is so broad, the Guide will
    give you general guidelines and will point you to other resources as
    necessary.</para>

    <caution>
      <para>Shorewall requires that the iproute/iproute2 package be installed
      (on RedHat, the package is called iproute). You can tell if this package
      is installed by the presence of an <emphasis role="bold">ip</emphasis>
      program on your firewall system. As root, you can use the
      <quote>which</quote> command to check for this program:</para>

      <programlisting>[root@gateway root]# <command>which ip</command>
/sbin/ip
[root@gateway root]#</programlisting>

      <para>I recommend that you first read through the guide to familiarize
      yourself with what's involved then go back through it again making your
      configuration changes. Points at which configuration changes are
      recommended are flagged with <inlinegraphic
      fileref="images/BD21298_.gif"/>.</para>
    </caution>

    <caution>
      <para>If you edit your configuration files on a Windows system, you must
      save them as Unix files if your editor supports that option or you must
      run them through dos2unix before trying to use them with Shorewall.
      Similarly, if you copy a configuration file from your Windows hard drive
      to a floppy disk, you must run dos2unix against the copy before using it
      with Shorewall.</para>

      <itemizedlist>
        <listitem>
          <para><ulink url="http://www.simtel.net/pub/pd/51438.html">Windows
          Version of dos2unix</ulink></para>
        </listitem>

        <listitem>
          <para><ulink
          url="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux Version
          of dos2unix</ulink></para>
        </listitem>
      </itemizedlist>
    </caution>
  </section>

  <section id="Concepts">
    <title>Shorewall Concepts</title>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>The configuration files for Shorewall are contained in the directory
    <filename class="directory">/etc/shorewall</filename> -- for most setups,
    you will only need to deal with a few of these as described in this guide.
    Skeleton files are created during the Shorewall <ulink
    url="Install.htm">Installation Process</ulink>.<warning>
        <para><emphasis role="bold">Note to Debian Users</emphasis></para>

        <para>If you install using the .deb, you will find that your <filename
        class="directory">/etc/shorewall</filename> directory is almost empty.
        This is intentional. The released configuration file skeletons may be
        found on your system in the directory <filename
        class="directory">/usr/share/doc/shorewall/default-config</filename>.
        Simply copy the files you need from that directory to <filename
        class="directory">/etc/shorewall</filename> and modify the
        copies.</para>
      </warning></para>

    <para>As each file is introduced, I suggest that you look through the
    actual file on your system -- each file contains detailed configuration
    instructions.</para>

    <para>Shorewall views the network where it is running as being composed of
    a set of zones. A zone is one or more hosts, which can be defined as
    individual hosts or networks in <filename
    class="directory">/etc/shorewall/hosts</filename>, or as an entire
    interface in <filename
    class="directory">/etc/shorewall/interfaces</filename>. In this guide, we
    will use the following zones:</para>

    <variablelist>
      <varlistentry>
        <term>fw</term>

        <listitem>
          <para>The firewall system itself.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>net</term>

        <listitem>
          <para>The public Internet.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>loc</term>

        <listitem>
          <para>A private local network using private IP addresses.</para>
        </listitem>
      </varlistentry>

      <varlistentry>
        <term>dmz</term>

        <listitem>
          <para>A Demilitarized Zone holding publicly-accessible
          servers.</para>
        </listitem>
      </varlistentry>
    </variablelist>

    <para>Zones are defined in the file <filename><ulink
    url="manpages/shorewall-zones.html"><filename>/etc/shorewall/zones</filename></ulink></filename>.</para>

    <important>
      <para>The <filename>/etc/shorewall/zones</filename> file included in the
      release is empty. You can create the standard set of zones described
      above by copying and pasting the following into the file:</para>

      <programlisting>#ZONE   TYPE             OPTIONS
fw      firewall
net     ipv4
loc     ipv4
dmz     ipv4</programlisting>
    </important>

    <para>Note that Shorewall recognizes the firewall system as its own zone -
    The above example follows the usual convention of naming the Firewall zone
    <emphasis role="bold">fw</emphasis>. The name specified for the firewall
    zone (<emphasis role="bold">fw</emphasis> in the above example) is stored
    in the shell variable <firstterm>$FW</firstterm> when the
    /etc/shorewall/zones file is processed. With the exception of the name
    assigned to the firewall zone, Shorewall attaches absolutely no meaning to
    zone names. Zones are entirely what YOU make of them. That means that you
    should not expect Shorewall to do something special <quote>because this is
    the Internet zone</quote> or <quote>because that is the
    DMZ</quote>.</para>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>Edit the /etc/shorewall/zones file and make any changes
    necessary.</para>

    <para>Rules about what traffic to allow and what traffic to deny are
    expressed in terms of zones.</para>

    <itemizedlist>
      <listitem>
        <para>You express your default policy for connections from one zone to
        another zone in the <filename><ulink
        url="manpages/shorewall-policy.html">/etc/shorewall/policy</ulink></filename>
        file.</para>
      </listitem>

      <listitem>
        <para>You define exceptions to those default policies in the
        <filename><ulink
        url="manpages/shorewall-rules.html">/etc/shorewall/rules</ulink></filename>.</para>
      </listitem>
    </itemizedlist>

    <para>Shorewall is built on top of the <ulink
    url="http://www.netfilter.org">Netfilter</ulink> kernel facility.
    Netfilter implements a <ulink
    url="http://www.cs.princeton.edu/~jns/security/iptables/iptables_conntrack.html">connection
    tracking function</ulink> that allows what is often referred to as
    stateful inspection of packets. This stateful property allows firewall
    rules to be defined in terms of connections rather than in terms of
    packets. With Shorewall, you:</para>

    <orderedlist>
      <listitem>
        <para>Identify the source (client) zone.</para>
      </listitem>

      <listitem>
        <para>Identify destination (server) zone.</para>
      </listitem>

      <listitem>
        <para>If the POLICY from the client's zone to the server's zone is
        what you want for this client/server pair, you need do nothing
        further.</para>
      </listitem>

      <listitem>
        <para>If the POLICY is not what you want, then you must add a rule.
        That rule is expressed in terms of the client's zone and the server's
        zone.</para>
      </listitem>
    </orderedlist>

    <para>Just because connections of a particular type are allowed from zone
    A to the firewall and are also allowed from the firewall to zone B
    <emphasis role="bold">DOES NOT mean that these connections are allowed
    from zone A to zone B</emphasis> (in other words, policies and rules
    involving the firewall zone are not transitive). It rather means that you
    can have a proxy running on the firewall that accepts a connection from
    zone A and then establishes its own separate connection from the firewall
    to zone B.</para>

    <para>For each connection request entering the firewall, the request is
    first checked against the <filename>/etc/shorewall/rules</filename> file.
    If no rule in that file matches the connection request then the first
    policy in <filename>/etc/shorewall/policy</filename> that matches the
    request is applied after the request is passed to the appropriate <ulink
    url="Actions.html">default action</ulink> (if any).</para>

    <para>Prior to Shorewall 2.2.0, the default
    <filename>/etc/shorewall/policy</filename> file had the following
    policies:</para>

    <programlisting>#SOURCE          DEST                POLICY     LOGLEVEL     LIMIT
loc              net                 ACCEPT
net              all                 DROP       info
all              all                 REJECT     info</programlisting>

    <important>
      <para>The currently released policy file is empty. You can copy and
      paste the above entries to create a starting point from which to
      customize your policies.</para>
    </important>

    <para>The above policies will:</para>

    <orderedlist>
      <listitem>
        <para>allow all connection requests from your local network to the
        Internet</para>
      </listitem>

      <listitem>
        <para>drop (ignore) all connection requests from the Internet to your
        firewall or local network and log a message at the info level (<ulink
        url="shorewall_logging.html">here is a description of log
        levels</ulink>).</para>
      </listitem>

      <listitem>
        <para>reject all other connection requests and log a message at the
        info level. When a request is rejected, the firewall will return an
        RST (if the protocol is TCP) or an ICMP port-unreachable packet for
        other protocols.</para>
      </listitem>
    </orderedlist>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>At this point, edit your <filename>/etc/shorewall/policy
    </filename>and make any changes that you wish.</para>
  </section>

  <section id="Interfaces">
    <title>Network Interfaces</title>

    <para>For the remainder of this guide, we'll refer to the following
    diagram. While it may not look like your own network, it can be used to
    illustrate the important aspects of Shorewall configuration.</para>

    <para>In this diagram:</para>

    <itemizedlist>
      <listitem>
        <para>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ is used
        to isolate your Internet-accessible servers from your local systems so
        that if one of those servers is compromised, you still have the
        firewall between the compromised system and your local systems.</para>
      </listitem>

      <listitem>
        <para>The Local Zone consists of systems Local 1, Local 2 and Local
        3.</para>
      </listitem>

      <listitem>
        <para>All systems from the ISP outward comprise the Internet
        Zone.</para>
      </listitem>
    </itemizedlist>

    <graphic align="center" fileref="images/dmz3.png"/>

    <para>The simplest way to define zones is to associate the zone name
    (previously defined in /etc/shorewall/zones) with a network interface.
    This is done in the <ulink
    url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces</ulink>
    file. The firewall illustrated above has three network interfaces. Where
    Internet connectivity is through a cable or DSL <quote>Modem</quote>, the
    <emphasis>External Interface</emphasis> will be the Ethernet adapter that
    is connected to that <quote>Modem</quote> (e.g., <filename
    class="devicefile">eth0</filename>) unless you connect via Point-to-Point
    Protocol over Ethernet (PPPoE) or Point-to-Point Tunneling Protocol (PPTP)
    in which case the External Interface will be a ppp interface (e.g.,
    <filename class="devicefile">ppp0</filename>). If you connect via a
    regular modem, your External Interface will also be <filename
    class="devicefile">ppp0</filename>. If you connect using ISDN, you
    external interface will be <filename
    class="devicefile">ippp0</filename>.</para>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>If your external interface is <filename
    class="devicefile">ppp0</filename> or <filename
    class="devicefile">ippp0</filename> then you will want to set CLAMPMSS=yes
    in <filename><ulink
    url="manpages/shorewall.conf.html">/etc/shorewall/shorewall.conf</ulink></filename>.</para>

    <para>Your <emphasis>Local Interface</emphasis> will be an Ethernet
    adapter (<filename class="devicefile">eth0</filename>,
    <filename>eth1</filename> or <filename class="devicefile">eth2</filename>)
    and will be connected to a hub or switch. Your local computers will be
    connected to the same switch (note: If you have only a single local
    system, you can connect the firewall directly to the computer using a
    cross-over cable).</para>

    <para>Your <emphasis>DMZ Interface</emphasis> will also be an Ethernet
    adapter (<filename class="devicefile">eth0</filename>, <filename
    class="devicefile">eth1</filename> or <filename
    class="devicefile">eth2</filename>) and will be connected to a hub or
    switch. Your DMZ computers will be connected to the same switch (note: If
    you have only a single DMZ system, you can connect the firewall directly
    to the computer using a cross-over cable).</para>

    <caution>
      <para>Do not connect the internal and external interface to the same hub
      or switch except for testing. You can test using this kind of
      configuration if you specify the <emphasis
      role="bold">arp_filter</emphasis> option or the <emphasis
      role="bold">arp_ignore</emphasis> option in
      <filename>/etc/shorewall/interfaces</filename> for all interfaces
      connected to the common hub/switch. Using such a setup with a production
      firewall is strongly recommended against.</para>
    </caution>

    <para>For the remainder of this Guide, we will assume that:</para>

    <itemizedlist>
      <listitem>
        <para>The External Interface is <filename
        class="devicefile">eth0</filename>.</para>
      </listitem>

      <listitem>
        <para>The Local Interface <filename
        class="devicefile">eth1</filename>.</para>
      </listitem>

      <listitem>
        <para>The DMZ Interface <filename
        class="devicefile">eth2</filename>.</para>
      </listitem>
    </itemizedlist>

    <para>The Shorewall default configuration does not define the contents of
    any zone. To define the above configuration using the <ulink
    url="manpages/shorewall-interfaces.html">/etc/shorewall/interfaces
    </ulink>file, that file would might contain:</para>

    <programlisting>?FORMAT 2
#ZONE    INTERFACE      OPTIONS
net      eth0
loc      eth1
dmz      eth2</programlisting>

    <para>Note that the <emphasis role="bold">$FW</emphasis> zone has no entry
    in the /etc/shorewall/interfaces file.</para>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>Edit the <filename>/etc/shorewall/interfaces</filename> file and
    define the network interfaces on your firewall and associate each
    interface with a zone. If you have a zone that is interfaced through more
    than one interface, simply include one entry for each interface and repeat
    the zone name as many times as necessary.</para>

    <example id="multi">
      <title>Multiple Interfaces to a Zone</title>

      <programlisting>?FORMAT 2
#ZONE    INTERFACE      BROADCAST     OPTIONS
net      eth0
loc      eth1
loc      eth2</programlisting>
    </example>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>You may define more complicated zones using the<filename> <ulink
    url="manpages/shorewall-hosts.html">/etc/shorewall/hosts</ulink></filename>
    file but in most cases, that isn't necessary. See <ulink
    url="Shorewall_and_Aliased_Interfaces.html">Shorewall_and_Aliased_Interfaces.html</ulink>
    and <ulink url="Multiple_Zones.html">Multiple_Zones.html</ulink> for
    examples.</para>
  </section>

  <section id="Addressing">
    <title>Addressing, Subnets and Routing</title>

    <para>Normally, your ISP will assign you a set of Public IP addresses. You
    will configure your firewall's external interface to use one of those
    addresses permanently and you will then have to decide how you are going
    to use the rest of your addresses. Before we tackle that question though,
    some background is in order.</para>

    <para>If you are thoroughly familiar with IP addressing and routing, you
    may go to the next section.</para>

    <para>The following discussion barely scratches the surface of addressing
    and routing. If you are interested in learning more about this subject, I
    highly recommend <quote><emphasis>IP Fundamentals: What Everyone Needs to
    Know about Addressing &amp; Routing</emphasis></quote>, Thomas A. Maufer,
    Prentice-Hall, 1999, ISBN 0-13-975483-0.</para>

    <section id="Addresses">
      <title>IP Addresses</title>

      <para>IP version 4 (IPv4) addresses are 32-bit numbers. The notation
      w.x.y.z refers to an address where the high-order byte has value
      <quote>w</quote>, the next byte has value <quote>x</quote>, etc. If we
      take the address 192.0.2.14 and express it in hexadecimal, we
      get:</para>

      <para><programlisting>C0.00.02.0E</programlisting>or looking at it as a
      32-bit integer</para>

      <para><programlisting>C000020E</programlisting></para>
    </section>

    <section id="Subnets">
      <title>Subnets</title>

      <para>You will still hear the terms <quote>Class A network</quote>,
      <quote>Class B network</quote> and <quote>Class C network</quote>. In
      the early days of IP, networks only came in three sizes (there were also
      Class D networks but they were used differently):</para>

      <simplelist>
        <member>Class A - netmask 255.0.0.0, size = 2 ** 24</member>

        <member>Class B - netmask 255.255.0.0, size = 2 ** 16</member>

        <member>Class C - netmask 255.255.255.0, size = 256</member>
      </simplelist>

      <para>The class of a network was uniquely determined by the value of the
      high order byte of its address so you could look at an IP address and
      immediately determine the associated netmask. The netmask is a number
      that when logically ANDed with an address isolates the network number;
      the remainder of the address is the host number. For example, in the
      Class C address 192.0.2.14, the network number is hex C00002 and the
      host number is hex 0E.</para>

      <para>As the Internet grew, it became clear that such a gross
      partitioning of the 32-bit address space was going to be very limiting
      (early on, large corporations and universities were assigned their own
      class A network!). After some false starts, the current technique of
      subnetting these networks into smaller subnetworks evolved; that
      technique is referred to as <emphasis>Classless InterDomain
      Routing</emphasis> (CIDR). Today, any system that you are likely to work
      with will understand CIDR and Class-based networking is largely a thing
      of the past.</para>

      <para>A <emphasis>subnetwork</emphasis> (often referred to as a
      <emphasis>subnet</emphasis>) is a contiguous set of IP addresses such
      that:</para>

      <orderedlist>
        <listitem>
          <para>The number of addresses in the set is a power of 2; and</para>
        </listitem>

        <listitem>
          <para>The first address in the set is a multiple of the set
          size.</para>
        </listitem>

        <listitem>
          <para>The first address in the subnet is reserved and is referred to
          as the <emphasis>subnet address</emphasis>.</para>
        </listitem>

        <listitem>
          <para>The last address in the subnet is reserved as the subnet's
          <emphasis>broadcast address</emphasis>.</para>
        </listitem>
      </orderedlist>

      <para>As you can see by this definition, in each subnet of size n there
      are (n - 2) usable addresses (addresses that can be assigned to hosts).
      The first and last address in the subnet are used for the subnet address
      and subnet broadcast address respectively. Consequently, small
      subnetworks are more wasteful of IP addresses than are large
      ones.</para>

      <para>Since n is a power of two, we can easily calculate the
      <emphasis>Base-2 Logarithm</emphasis> (log2) of n. For the more common
      subnet sizes, the size and its base-2 logarithm are given in the
      following table:</para>

      <table id="Logs">
        <title>Base-2 Logarithms</title>

        <tgroup cols="3">
          <tbody>
            <row>
              <entry><emphasis role="bold">n</emphasis></entry>

              <entry><emphasis role="bold">log2 n</emphasis></entry>

              <entry><emphasis role="bold">(32 - log2 n)</emphasis></entry>
            </row>

            <row>
              <entry>8</entry>

              <entry>3</entry>

              <entry>29</entry>
            </row>

            <row>
              <entry>16</entry>

              <entry>4</entry>

              <entry>28</entry>
            </row>

            <row>
              <entry>32</entry>

              <entry>5</entry>

              <entry>27</entry>
            </row>

            <row>
              <entry>64</entry>

              <entry>6</entry>

              <entry>26</entry>
            </row>

            <row>
              <entry>128</entry>

              <entry>7</entry>

              <entry>25</entry>
            </row>

            <row>
              <entry>256</entry>

              <entry>8</entry>

              <entry>24</entry>
            </row>

            <row>
              <entry>512</entry>

              <entry>9</entry>

              <entry>23</entry>
            </row>

            <row>
              <entry>1024</entry>

              <entry>10</entry>

              <entry>22</entry>
            </row>

            <row>
              <entry>2048</entry>

              <entry>11</entry>

              <entry>21</entry>
            </row>

            <row>
              <entry>4096</entry>

              <entry>12</entry>

              <entry>20</entry>
            </row>

            <row>
              <entry>8192</entry>

              <entry>13</entry>

              <entry>19</entry>
            </row>

            <row>
              <entry>16384</entry>

              <entry>14</entry>

              <entry>18</entry>
            </row>

            <row>
              <entry>32768</entry>

              <entry>15</entry>

              <entry>17</entry>
            </row>

            <row>
              <entry>65536</entry>

              <entry>16</entry>

              <entry>16</entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <para>You will notice that the above table also contains a column for
      (32 - log2 <emphasis role="bold">n)</emphasis>. That number is the
      <emphasis>Variable Length Subnet Mask</emphasis> (VLSM) for a network of
      size n. From the above table, we can derive the following one which is a
      little easier to use.</para>

      <table id="vlsm">
        <title>VLSM</title>

        <tgroup cols="3">
          <tbody>
            <row>
              <entry><emphasis role="bold">Subnet Size</emphasis></entry>

              <entry><emphasis role="bold">VLSM</emphasis></entry>

              <entry><emphasis role="bold">Subnet Mask</emphasis></entry>
            </row>

            <row>
              <entry>8</entry>

              <entry>/29</entry>

              <entry>255.255.255.248</entry>
            </row>

            <row>
              <entry>16</entry>

              <entry>/28</entry>

              <entry>255.255.255.240</entry>
            </row>

            <row>
              <entry>32</entry>

              <entry>/27</entry>

              <entry>255.255.255.224</entry>
            </row>

            <row>
              <entry>64</entry>

              <entry>/26</entry>

              <entry>255.255.255.192</entry>
            </row>

            <row>
              <entry>128</entry>

              <entry>/25</entry>

              <entry>255.255.255.128</entry>
            </row>

            <row>
              <entry>256</entry>

              <entry>/24</entry>

              <entry>255.255.255.0</entry>
            </row>

            <row>
              <entry>512</entry>

              <entry>/23</entry>

              <entry>255.255.254.0</entry>
            </row>

            <row>
              <entry>1024</entry>

              <entry>/22</entry>

              <entry>255.255.252.0</entry>
            </row>

            <row>
              <entry>2048</entry>

              <entry>/21</entry>

              <entry>255.255.248.0</entry>
            </row>

            <row>
              <entry>4096</entry>

              <entry>/20</entry>

              <entry>255.255.240.0</entry>
            </row>

            <row>
              <entry>8192</entry>

              <entry>/19</entry>

              <entry>255.255.224.0</entry>
            </row>

            <row>
              <entry>16384</entry>

              <entry>/18</entry>

              <entry>255.255.192.0</entry>
            </row>

            <row>
              <entry>32768</entry>

              <entry>/17</entry>

              <entry>255.255.128.0</entry>
            </row>

            <row>
              <entry>65536</entry>

              <entry>/16</entry>

              <entry>255.255.0.0</entry>
            </row>

            <row>
              <entry>2 ** 24</entry>

              <entry>/8</entry>

              <entry>255.0.0.0</entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <para>Notice that the VLSM is written with a slash (<quote>/</quote>) --
      you will often hear a subnet of size 64 referred to as a <quote>slash
      26</quote> subnet and one of size 8 referred to as a <quote>slash
      29</quote>.</para>

      <para>The subnet's mask (also referred to as its
      <emphasis>netmask</emphasis>) is simply a 32-bit number with the first
      <quote>VLSM</quote> bits set to one and the remaining bits set to zero.
      For example, for a subnet of size 64, the subnet mask has 26 leading one
      bits:</para>

      <para><programlisting>11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192</programlisting>The
      subnet mask has the property that if you logically AND the subnet mask
      with an address in the subnet, the result is the subnet address. Just as
      important, if you logically AND the subnet mask with an address outside
      the subnet, the result is NOT the subnet address. As we will see below,
      this property of subnet masks is very useful in routing.</para>

      <para>For a subnetwork whose address is <emphasis
      role="bold">a.b.c.d</emphasis> and whose Variable Length Subnet Mask is
      <emphasis role="bold">/v</emphasis>, we denote the subnetwork as
      <quote><emphasis role="bold">a.b.c.d/v</emphasis></quote> using
      <emphasis>CIDR Notation</emphasis>. Example:</para>

      <table id="Subnet">
        <title>Subnet</title>

        <tgroup cols="2">
          <tbody>
            <row>
              <entry><emphasis role="bold">Subnet:</emphasis></entry>

              <entry>10.10.10.0 - 10.10.10.127</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Subnet Size:</emphasis></entry>

              <entry>128</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Subnet Address:</emphasis></entry>

              <entry>10.10.10.0</entry>
            </row>

            <row>
              <entry><emphasis role="bold">Broadcast
              Address:</emphasis></entry>

              <entry>10.10.10.127</entry>
            </row>

            <row>
              <entry><emphasis role="bold">CIDR Notation:</emphasis></entry>

              <entry>10.10.10.0/25</entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <para>There are two degenerate subnets that need mentioning; namely, the
      subnet with one member and the subnet with 2 ** 32 members.</para>

      <table id="degenerate">
        <title>/32 and /0</title>

        <tgroup cols="4">
          <tbody>
            <row>
              <entry><emphasis role="bold">Subnet Size</emphasis></entry>

              <entry><emphasis role="bold">VLSM Length</emphasis></entry>

              <entry><emphasis role="bold">Subnet Mask</emphasis></entry>

              <entry><emphasis role="bold">CIDR Notation</emphasis></entry>
            </row>

            <row>
              <entry>1</entry>

              <entry>32</entry>

              <entry>255.255.255.255</entry>

              <entry>a.b.c.d/32</entry>
            </row>

            <row>
              <entry>32</entry>

              <entry>0</entry>

              <entry>0.0.0.0</entry>

              <entry>0.0.0.0/0</entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <para>So any address <emphasis role="bold">a.b.c.d</emphasis> may also
      be written <emphasis role="bold">a.b.c.d/32</emphasis> and the set of
      all possible IP addresses is written <emphasis
      role="bold">0.0.0.0/0</emphasis>.</para>

      <para role="bold">A Shorewall user has contributed a <ulink
      url="http://shorewall.net/pub/shorewall/contrib/IPSubNetMask.html">useful
      graphical summary</ulink> of the above information.</para>

      <para>Later in this guide, you will see the notation <emphasis
      role="bold">a.b.c.d/v</emphasis> used to describe the ip configuration
      of a network interface (the <quote>ip</quote> utility also uses this
      syntax). This simply means that the interface is configured with ip
      address <emphasis role="bold">a.b.c.d</emphasis> and with the netmask
      that corresponds to VLSM /<emphasis role="bold">v</emphasis>.</para>

      <example id="Example0">
        <title>192.0.2.65/29</title>

        <para>The interface is configured with IP address 192.0.2.65 and
        netmask 255.255.255.248.</para>
      </example>

      <para>/sbin/shorewall supports an ipcalc command that automatically
      calculates information about a [sub]network.</para>

      <example id="Example1">
        <title>Using the <command>ipcalc </command>command</title>

        <programlisting>shorewall ipcalc 10.10.10.0/25
   CIDR=10.10.10.0/25
   NETMASK=255.255.255.128
   NETWORK=10.10.10.0
   BROADCAST=10.10.10.127
</programlisting>
      </example>

      <example id="Example2">
        <title>Using the <command>ipcalc</command> command</title>

        <programlisting>shorewall ipcalc 10.10.10.0 255.255.255.128
   CIDR=10.10.10.0/25
   NETMASK=255.255.255.128
   NETWORK=10.10.10.0
   BROADCAST=10.10.10.127</programlisting>
      </example>
    </section>

    <section id="Routing">
      <title>Routing</title>

      <para>One of the purposes of subnetting is that it forms the basis for
      routing. Here's the routing table on my firewall (compressed for
      PDF):</para>

      <programlisting>[root@gateway root]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flgs MSS Win irtt Iface
192.168.9.1     0.0.0.0         255.255.255.255 UH   40  0      0 texas
206.124.146.177 0.0.0.0         255.255.255.255 UH   40  0      0 eth1
206.124.146.180 0.0.0.0         255.255.255.255 UH   40  0      0 eth3
192.168.3.0     0.0.0.0         255.255.255.0   U    40  0      0 eth3
192.168.2.0     0.0.0.0         255.255.255.0   U    40  0      0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U    40  0      0 eth2
206.124.146.0   0.0.0.0         255.255.255.0   U    40  0      0 eth0
192.168.9.0     192.0.2.223     255.255.255.0   UG   40  0      0 texas
127.0.0.0       0.0.0.0         255.0.0.0       U    40  0      0 lo
0.0.0.0         206.124.146.254 0.0.0.0         UG   40  0      0 eth0
[root@gateway root]#</programlisting>

      <para>The device <emphasis>texas</emphasis> is a GRE tunnel to a peer
      site in the Dallas, Texas area.</para>

      <para>The first three routes are <emphasis>host routes</emphasis> since
      they indicate how to get to a single host. In the <quote>netstat</quote>
      output this can be seen by the <quote>Genmask</quote> (Subnet Mask) of
      255.255.255.255 and the <quote>H</quote> in the Flags column. The
      remainder are <emphasis><quote>net</quote> routes</emphasis> since they
      tell the kernel how to route packets to a subnetwork. The last route is
      the <emphasis>default route </emphasis>and the gateway mentioned in that
      route is called the <emphasis>default gateway</emphasis>.</para>

      <para>When the kernel is trying to send a packet to IP address <emphasis
      role="bold">A</emphasis>, it starts at the top of the routing table
      and:</para>

      <itemizedlist>
        <listitem>
          <para><emphasis role="bold">A</emphasis> is logically ANDed with the
          <quote>Genmask</quote> value in the table entry.</para>
        </listitem>

        <listitem>
          <para>The result is compared with the <quote>Destination</quote>
          value in the table entry.</para>
        </listitem>

        <listitem>
          <para>If the result and the <quote>Destination</quote> value are the
          same, then:</para>

          <itemizedlist>
            <listitem>
              <para>If the <quote>Gateway</quote> column is non-zero, the
              packet is sent to the gateway over the interface named in the
              <quote>Iface</quote> column.</para>
            </listitem>

            <listitem>
              <para>Otherwise, the packet is sent directly to <emphasis
              role="bold">A</emphasis> over the interface named in the
              <quote>iface</quote> column.</para>
            </listitem>
          </itemizedlist>
        </listitem>

        <listitem>
          <para>Otherwise, the above steps are repeated on the next entry in
          the table.</para>
        </listitem>
      </itemizedlist>

      <para>Since the default route matches any IP address (<emphasis
      role="bold">A </emphasis>LAND 0.0.0.0 = 0.0.0.0), packets that don't
      match any of the other routing table entries are sent to the default
      gateway which is usually a router at your ISP. Lets take an example.
      Suppose that we want to route a packet to 192.168.1.5. That address
      clearly doesn't match any of the host routes in the table but if we
      logically and that address with 255.255.255.0, the result is 192.168.1.0
      which matches this routing table entry:</para>

      <para><programlisting>192.168.1.0   0.0.0.0       255.255.255.0   U     40  0         0 eth2</programlisting></para>

      <para>So to route a packet to 192.168.1.5, the packet is sent directly
      over eth2.</para>

      <para>One more thing needs to be emphasized -- all outgoing packet are
      sent using the routing table and reply packets are not a special case.
      There seems to be a common misconception whereby people think that
      request packets are like salmon and contain a genetic code that is
      magically transferred to reply packets so that the replies follow the
      reverse route taken by the request. That isn't the case; the replies may
      take a totally different route back to the client than was taken by the
      requests -- they are totally independent.</para>
    </section>

    <section id="ARP">
      <title>Address Resolution Protocol (ARP)</title>

      <para>When sending packets over Ethernet, IP addresses aren't used.
      Rather Ethernet addressing is based on <emphasis>Media Access
      Control</emphasis> (MAC) addresses. Each Ethernet device has its own
      unique MAC address which is burned into a PROM on the device during
      manufacture. You can obtain the MAC of an Ethernet device using the
      <quote>ip</quote> utility:</para>

      <programlisting>[root@gateway root]# <command>ip addr show eth0</command>
2: eth0: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#
</programlisting>

      <para>As you can see from the above output, the MAC is 6 bytes (48 bits)
      wide. A card's MAC is usually also printed on a label attached to the
      card itself. Because IP uses IP addresses and Ethernet uses MAC
      addresses, a mechanism is required to translate an IP address into a MAC
      address; that is the purpose of the <emphasis>Address Resolution
      Protocol </emphasis>(ARP). Here is ARP in action:</para>

      <programlisting>[root@gateway root]# <command>tcpdump -nei eth2 arp</command>
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42:
                arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60:
                arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0

2 packets received by filter
0 packets dropped by kernel
[root@gateway root]#</programlisting>

      <para>In this exchange, 192.168.1.254 (MAC 2:0:8:e3:4c:48) wants to know
      the MAC of the device with IP address 192.168.1.19. The system having
      that IP address is responding that the MAC address of the device with IP
      address 192.168.1.19 is 0:6:25:aa:8a:f0.</para>

      <para>In order to avoid having to exchange ARP information each time
      that an IP packet is to be sent, systems maintain an <emphasis>ARP
      cache</emphasis> of IP&lt;-&gt;MAC correspondences. You can see the ARP
      cache on your system (including your Windows system) using the
      <quote>arp</quote> command:</para>

      <programlisting>[root@gateway root]# <command>arp -na</command>
? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2</programlisting>

      <para>The leading question marks are a result of my having specified the
      <quote>n</quote> option (Windows <quote>arp</quote> doesn't allow that
      option) which causes the <quote>arp</quote> program to forgo IP-&gt;DNS
      name translation. Had I not given that option, the question marks would
      have been replaced with the FQDN corresponding to each IP address.
      Notice that the last entry in the table records the information we saw
      using tcpdump above.</para>
    </section>

    <section id="RFC1918">
      <title>RFC 1918</title>

      <para>IP addresses are allocated by the <ulink
      url="http://www.iana.org/">Internet Assigned Number Authority</ulink>
      (IANA) who delegates allocations on a geographic basis to Regional
      Internet Registries (RIRs). For example, allocation for the Americas and
      for sub-Sahara Africa is delegated to the <ulink
      url="http://www.arin.net/">American Registry for Internet
      Numbers</ulink> (ARIN). These RIRs may in turn delegate to national
      registries. Most of us don't deal with these registrars but rather get
      our IP addresses from our ISP. It's a fact of life that most of us can't
      afford as many Public IP addresses as we have devices to assign them to
      so we end up making use of Private IP addresses. RFC 1918 reserves
      several IP address ranges for this purpose:</para>

      <programlisting>10.0.0.0    - 10.255.255.255
172.16.0.0  - 172.31.255.255
192.168.0.0 - 192.168.255.255</programlisting>

      <para>The addresses reserved by RFC 1918 are sometimes referred to as
      <firstterm>non-routable</firstterm> because the Internet backbone
      routers don't forward packets which have an RFC-1918 destination
      address. This is understandable given that anyone can select any of
      these addresses for their private use but the term non-routable is
      somewhat unfortunate because it leads people to the erroneous conclusion
      that traffic destined for one of these addresses can't be sent through a
      router. This is definitely not true; private routers (including your
      Shorewall-based firewall) can forward RFC 1918 addressed traffic just
      fine.</para>

      <para>When selecting addresses from these ranges, there's a couple of
      things to keep in mind:</para>

      <itemizedlist>
        <listitem>
          <para>As the IPv4 address space becomes depleted, more and more
          organizations (including ISPs) are beginning to use RFC 1918
          addresses in their infrastructure.</para>
        </listitem>

        <listitem>
          <para>You don't want to use addresses that are being used by your
          ISP or by another organization with whom you want to establish a VPN
          relationship.</para>
        </listitem>
      </itemizedlist>

      <para>So it's a good idea to check with your ISP to see if they are
      using (or are planning to use) private addresses before you decide the
      addresses that you are going to use.</para>

      <warning>
        <para><emphasis role="bold">In this document, external
        <quote>real</quote> IP addresses are of the form 192.0.2.x.
        192.0.2.0/24 is reserved by RFC 3330 for use as public IP addresses in
        printed examples and test networks. These "real" addresses are not to
        be confused with addresses in 192.168.0.0/16; as described above,
        those addresses are reserved by RFC 1918 for private
        use.</emphasis></para>
      </warning>
    </section>
  </section>

  <section id="Options">
    <title>Setting Up Your Network</title>

    <para>The choice of how to set up your network depends primarily on how
    many Public IP addresses you have vs. how many addressable entities you
    have in your network. Regardless of how many addresses you have, your ISP
    will handle that set of addresses in one of two ways:</para>

    <itemizedlist>
      <listitem>
        <para><emphasis role="bold">Routed</emphasis> - Traffic to any of your
        addresses will be routed through a single gateway address. This will
        generally only be done if your ISP has assigned you a complete subnet
        (/29 or larger). In this case, you will assign the gateway address as
        the IP address of your firewall/router's external interface.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Non-routed</emphasis> - Your ISP will send
        traffic to each of your addresses directly.</para>
      </listitem>
    </itemizedlist>

    <para>In the subsections that follow, we'll look at each of these
    separately.</para>

    <para>Before we begin, there is one thing for you to check:</para>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>If you are using the Debian package, please check your
    shorewall.conf file to ensure that the following are set correctly; if
    they are not, change them appropriately:</para>

    <itemizedlist>
      <listitem>
        <para>IP_FORWARDING=On</para>
      </listitem>
    </itemizedlist>

    <section id="Routed">
      <title>Routed</title>

      <para>Let's assume that your ISP has assigned you the subnet
      192.0.2.64/28 routed through 192.0.2.65. That means that you have IP
      addresses 192.0.2.64 - 192.0.2.79 and that your firewall's external IP
      address is 192.0.2.65. Your ISP has also told you that you should use a
      netmask of 255.255.255.0 (so your /28 is part of a larger /24). With
      this many IP addresses, you are able to subnet your /28 into two /29's
      and set up your network as shown in the following diagram.</para>

      <graphic align="center" fileref="images/dmz4.png"/>

      <para>Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local
      network is 192.0.2.72/29. The default gateway for hosts in the DMZ would
      be configured to 192.0.2.66 and the default gateway for hosts in the
      local network would be 192.0.2.73.</para>

      <para>Notice that this arrangement is rather wasteful of public IP
      addresses since it is using 192.0.2.64 and 192.0.2.72 for subnet
      addresses, 192.0.2.71 and 192.0.2.79 for subnet broadcast addresses and
      192.0.2.66 and 168.0.2.73 for internal addresses on the firewall/router.
      Nevertheless, it shows how subnetting can work and if we were dealing
      with a /24 rather than a /28 network, the use of 6 IP addresses out of
      256 would be justified because of the simplicity of the setup.</para>

      <para>The astute reader may have noticed that the Firewall/Router's
      external interface is actually part of the DMZ subnet (192.0.2.64/29).
      What if DMZ 1 (192.0.2.67) tries to communicate with 192.0.2.65? The
      routing table on DMZ 1 will look like this:</para>

      <programlisting format="linespecific">Kernel IP routing table
Destination    Gateway     Genmask         Flags MSS Window irtt Iface
192.0.2.64     0.0.0.0     255.255.255.248 U     40  0         0 eth0
0.0.0.0        192.0.2.66  0.0.0.0         UG    40  0         0 eth0</programlisting>

      <para>This means that DMZ 1 will send an ARP <quote>who-has
      192.0.2.65</quote> request and no device on the DMZ Ethernet segment has
      that IP address. Oddly enough, the firewall will respond to the request
      with the MAC address of its <emphasis role="underline">DMZ
      Interface</emphasis>!! DMZ 1 can then send Ethernet frames addressed to
      that MAC address and the frames will be received (correctly) by the
      firewall/router.</para>

      <para>It is this rather unexpected ARP behavior on the part of the Linux
      Kernel that prompts the warning earlier in this guide regarding the
      connecting of multiple firewall/router interfaces to the same hub or
      switch. When an ARP request for one of the firewall/router's IP
      addresses is sent by another system connected to the hub/switch, all of
      the firewall's interfaces that connect to the hub/switch can respond! It
      is then a race as to which <quote>here-is</quote> response reaches the
      sender first.</para>
    </section>

    <section id="NonRouted">
      <title>Non-routed</title>

      <para>If you have the above situation but it is non-routed, you can
      configure your network exactly as described above with one additional
      twist; simply specify the <quote>proxyarp</quote> option on all three
      firewall interfaces in the /etc/shorewall/interfaces file.</para>

      <para>Most of us don't have the luxury of having enough public IP
      addresses to set up our networks as shown in the preceding example (even
      if the setup is routed).</para>

      <para><emphasis role="bold">For the remainder of this section, assume
      that your ISP has assigned you IP addresses 192.0.2.176-180 and has told
      you to use netmask 255.255.255.0 and default gateway
      192.0.2.254.</emphasis></para>

      <para>Clearly, that set of addresses doesn't comprise a subnetwork and
      there aren't enough addresses for all of the network interfaces. There
      are four different techniques that can be used to work around this
      problem.</para>

      <itemizedlist>
        <listitem>
          <para><emphasis>Source Network Address Translation</emphasis>
          (SNAT).</para>
        </listitem>

        <listitem>
          <para><emphasis>Destination Network Address Translation</emphasis>
          (DNAT) also known as <emphasis>Port Forwarding</emphasis>.</para>
        </listitem>

        <listitem>
          <para><emphasis>Proxy ARP</emphasis>.</para>
        </listitem>

        <listitem>
          <para><emphasis>Network Address Translation</emphasis> (NAT) also
          referred to as <emphasis>One-to-one NA</emphasis>T.</para>
        </listitem>
      </itemizedlist>

      <para>Often a combination of these techniques is used. Each of these
      will be discussed in the sections that follow.</para>

      <section id="SNAT">
        <title>SNAT</title>

        <para>With SNAT, an internal LAN segment is configured using RFC 1918
        addresses. When a host <emphasis role="bold">A</emphasis> on this
        internal segment initiates a connection to host <emphasis
        role="bold">B</emphasis> on the Internet, the firewall/router rewrites
        the IP header in the request to use one of your public IP addresses as
        the source address. When <emphasis role="bold">B</emphasis> responds
        and the response is received by the firewall, the firewall changes the
        destination address back to the RFC 1918 address of <emphasis
        role="bold">A</emphasis> and forwards the response back to <emphasis
        role="bold">A.</emphasis></para>

        <para>Let's suppose that you decide to use SNAT on your local zone and
        use public address 192.0.2.176 as both your firewall's external IP
        address and the source IP address of Internet requests sent from that
        zone.</para>

        <graphic align="center" fileref="images/dmz5.png"/>

        <para>The local zone has been subnetted as 192.168.201.0/29 (netmask
        255.255.255.248).</para>

        <simplelist>
          <member><inlinegraphic fileref="images/BD21298_.gif"/></member>

          <member>The systems in the local zone would be configured with a
          default gateway of 192.168.201.1 (the IP address of the firewall's
          local interface).</member>

          <member><inlinegraphic fileref="images/BD21298_.gif"/></member>

          <member>SNAT is configured in Shorewall using the <filename><ulink
          url="manpages/shorewall-masq.html">/etc/shorewall/masq</ulink></filename>
          file (<ulink
          url="manpages/shorewall-snat.html">/etc/shorewall/snat</ulink> when
          running Shorewall 5.0.14 or later):</member>
        </simplelist>

        <programlisting>#INTERFACE     SOURCE               ADDRESS
eth0           192.168.201.0/29     192.0.2.176</programlisting>

        <para>When running Shorewall 5.0.14 or later, the equivalent
        <filename>/etc/shorewall/snat</filename> is:</para>

        <programlisting>#ACTION                SOURCE            DEST                PROTO   PORT
SNAT(192.0.2.176)      192.168.201.0/24  eth0</programlisting>

        <para>This example used the normal technique of assigning the same
        public IP address for the firewall external interface and for SNAT. If
        you wanted to use a different IP address, you would either have to use
        your distributions network configuration tools to add that IP address
        to the external interface or you could set ADD_SNAT_ALIASES=Yes in
        /etc/shorewall/shorewall.conf and Shorewall will add the address for
        you.</para>
      </section>

      <section id="dnat">
        <title>DNAT</title>

        <para>When SNAT is used, it is impossible for hosts on the Internet to
        initiate a connection to one of the internal systems since those
        systems do not have a public IP address. DNAT provides a way to allow
        selected connections from the Internet.</para>

        <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

        <para>Suppose that your daughter wants to run a web server on her
        system <quote>Local 3</quote>. You could allow connections to the
        Internet to her server by adding the following entry in
        <filename><ulink
        url="manpages/shorewall-rules.html">/etc/shorewall/rules</ulink></filename>:</para>

        <programlisting>#ACTION  SOURCE  DEST               PROTO  DPORT   SPORT     ORIGDEST
DNAT     net     loc:192.168.201.4  tcp    www</programlisting>

        <para>If one of your daughter's friends at address <emphasis
        role="bold">A</emphasis> wants to access your daughter's server, she
        can connect to http://192.0.2.176 (the firewall's external IP address)
        and the firewall will rewrite the destination IP address to
        192.168.201.4 (your daughter's system) and forward the request. When
        your daughter's server responds, the firewall will rewrite the source
        address back to 192.0.2.176 and send the response back to <emphasis
        role="bold">A</emphasis>.</para>

        <para>This example used the firewall's external IP address for DNAT.
        You can use another of your public IP addresses (place it in the
        ORIGDEST column in the rule above) but Shorewall will not add that
        address to the firewall's external interface for you.</para>

        <important>
          <para>When testing DNAT rules like those shown above, you must test
          from a client OUTSIDE YOUR FIREWALL (in the 'net' zone). You cannot
          test these rules from inside the firewall!</para>

          <para>For DNAT troubleshooting tips, <ulink url="FAQ.htm#faq1a">see
          FAQs 1a and 1b</ulink>.</para>
        </important>
      </section>

      <section id="ProxyARP">
        <title>Proxy ARP</title>

        <para>The idea behind Proxy ARP is that:</para>

        <itemizedlist>
          <listitem>
            <para>A host <emphasis role="bold">H</emphasis> behind your
            firewall is assigned one of your public IP addresses (<emphasis
            role="bold">A</emphasis>), and is assigned the same netmask
            (<emphasis role="bold">M</emphasis>) as the firewall's external
            interface.</para>
          </listitem>

          <listitem>
            <para>The firewall responds to ARP <quote>who has</quote> requests
            for <emphasis role="bold">A</emphasis> from machines outside of
            the firewall.</para>
          </listitem>

          <listitem>
            <para>When <emphasis role="bold">H</emphasis> issues an ARP
            <quote>who has</quote> request for a machine with an address in
            the network defined by <emphasis role="bold">M</emphasis> where
            the target machine is outside of the firewall, the firewall will
            respond to <emphasis role="bold">H</emphasis> (with the MAC of the
            firewall interface that <emphasis role="bold">H</emphasis> is
            connected to).</para>
          </listitem>
        </itemizedlist>

        <para>For a more complete description of how Proxy ARP works, please
        see the <ulink url="ProxyARP.htm">Shorewall Proxy
        Documentation</ulink>.</para>

        <para>Let us suppose that we decide to use Proxy ARP on the DMZ in our
        example network.</para>

        <graphic align="center" fileref="images/dmz6.png"/>

        <para>Here, we've assigned the IP addresses 192.0.2.177 to system DMZ
        1 and 192.0.2.178 to DMZ 2. Notice that we've just assigned an
        arbitrary RFC 1918 IP address and subnet mask to the DMZ interface on
        the firewall. That address and netmask isn't relevant - just be sure
        it doesn't overlap another subnet that you've defined.</para>

        <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

        <para>The Shorewall configuration of Proxy ARP is done using the<ulink
        url="ProxyARP.htm"><filename>/etc/shorewall/proxyarp</filename></ulink>
        file.</para>

        <programlisting>#ADDRESS     INTERFACE    EXTERNAL      HAVEROUTE            PERSISTENT
192.0.2.177  eth2         eth0          No
192.0.2.178  eth2         eth0          No</programlisting>

        <para>Because the HAVE ROUTE column contains No, Shorewall will add
        host routes thru eth2 to 192.0.2.177 and 192.0.2.178. The Ethernet
        interfaces on DMZ 1 and DMZ 2 should be configured to have the IP
        addresses shown but should have the same default gateway as the
        firewall itself -- namely 192.0.2.254. In other words, they should be
        configured just like they would be if they were parallel to the
        firewall rather than behind it.</para>

        <caution>
          <para><emphasis role="bold">Do not add the Proxy ARP'ed address(es)
          (192.0.2.177 and 192.0.2.178 in the above example) to the external
          interface (eth0 in this example) of the firewall.</emphasis></para>
        </caution>

        <para>A word of warning is in order here. ISPs typically configure
        their routers with a long ARP cache timeout. If you move a system from
        parallel to your firewall to behind your firewall with Proxy ARP, it
        will probably be HOURS before that system can communicate with the
        Internet. There are a couple of things that you can try:</para>

        <orderedlist>
          <listitem>
            <para>(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
            Illustrated, Vol 1 reveals that a</para>

            <blockquote>
              <para><quote>gratuitous</quote> ARP packet should cause the
              ISP's router to refresh their ARP cache (section 4.7). A
              gratuitous ARP is simply a host requesting the MAC address for
              its own IP; in addition to ensuring that the IP address isn't a
              duplicate,...</para>

              <para><quote>if the host sending the gratuitous ARP has just
              changed its hardware address..., this packet causes any other
              host...that has an entry in its cache for the old hardware
              address to update its ARP cache entry
              accordingly.</quote></para>
            </blockquote>

            <para>Which is, of course, exactly what you want to do when you
            switch a host from being exposed to the Internet to behind
            Shorewall using proxy ARP (or one-to-one NAT for that matter).
            Happily enough, recent versions of Redhat's iputils package
            include <quote>arping</quote>, whose <quote>-U</quote> flag does
            just that:</para>

            <para><programlisting><command>arping -U -I &lt;net if&gt; &lt;newly proxied IP&gt;</command>

<command>arping -U -I eth0 66.58.99.83</command> # for example</programlisting>Stevens
            goes on to mention that not all systems respond correctly to
            gratuitous ARPs, but googling for <quote>arping -U</quote> seems
            to support the idea that it works most of the time.</para>
          </listitem>

          <listitem>
            <para>You can call your ISP and ask them to purge the stale ARP
            cache entry but many either can't or won't purge individual
            entries.</para>
          </listitem>
        </orderedlist>

        <para>You can determine if your ISP's gateway ARP cache is stale using
        ping and tcpdump. Suppose that we suspect that the gateway router has
        a stale ARP cache entry for 192.0.2.177. On the firewall, run tcpdump
        as follows:</para>

        <para><programlisting><command>tcpdump -nei eth0 icmp</command></programlisting></para>

        <para>Now from 192.0.2.177, ping the ISP's gateway (which we will
        assume is 192.0.2.254):</para>

        <para><programlisting><command>ping 192.0.2.254</command></programlisting></para>

        <para>We can now observe the tcpdump output:</para>

        <para><programlisting>13:35:12.159321 <emphasis role="bold">0:4:e2:20:20:33</emphasis> 0:0:77:95:dd:19 ip 98:
                192.0.2.177 &gt; 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 <emphasis role="bold">0:c0:a8:50:b2:57</emphasis> ip 98:
                192.0.2.254 &gt; 192.0.2.177 : icmp: echo reply</programlisting>Notice
        that the source MAC address in the echo request is different from the
        destination MAC address in the echo reply!! In this case
        0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
        0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the
        gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1
        rather than with the firewall's eth0.</para>
      </section>

      <section id="NAT">
        <title>One-to-one NAT</title>

        <para>With one-to-one NAT, you assign local systems RFC 1918 addresses
        then establish a one-to-one mapping between those addresses and public
        IP addresses. For outgoing connections SNAT (Source Network Address
        Translation) occurs and on incoming connections DNAT (Destination
        Network Address Translation) occurs. Let's go back to our earlier
        example involving your daughter's web server running on system Local
        3.</para>

        <graphic align="center" fileref="images/dmz6.png"/>

        <para>Recall that in this setup, the local network is using SNAT and
        is sharing the firewall external IP (192.0.2.176) for outbound
        connections. This is done with the following entry in
        <filename>/etc/shorewall/masq</filename>:</para>

        <programlisting>#INTERFACE     SOURCE               ADDRESS
eth0           192.168.201.0/29     192.0.2.176</programlisting>

        <para>When running Shorewall 5.0.14 or later, the equivalent
        <filename>/etc/shorewall/snat</filename> is:</para>

        <programlisting>#ACTION                SOURCE            DEST                PROTO   PORT
SNAT(192.0.2.176)      192.168.201.0/24  eth0</programlisting>

        <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

        <para>Suppose now that you have decided to give your daughter her own
        IP address (192.0.2.179) for both inbound and outbound connections.
        You would do that by adding an entry in <filename><ulink
        url="NAT.htm">/etc/shorewall/nat</ulink></filename>.</para>

        <programlisting>#EXTERNAL   INTERFACE   INTERNAL       ALLINTS          LOCAL
192.0.2.179 eth0        192.168.201.4  No               No</programlisting>

        <para>With this entry in place, you daughter has her own IP address
        and the other two local systems share the firewall's IP
        address.</para>

        <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

        <para>Once the relationship between 192.0.2.179 and 192.168.201.4 is
        established by the nat file entry above, it is no longer appropriate
        to use a DNAT rule for you daughter's web server -- you would rather
        just use an ACCEPT rule:</para>

        <programlisting>#ACTION  SOURCE  DEST               PROTO  DEST    SPORT     ORIGDEST
ACCEPT   net     loc:192.168.201.4  tcp    www</programlisting>

        <para>A word of warning is in order here. ISPs typically configure
        their routers with a long ARP cache timeout. If you move a system from
        parallel to your firewall to behind your firewall with one-to-one NAT,
        it will probably be HOURS before that system can communicate with the
        Internet. There are a couple of things that you can try:</para>

        <orderedlist>
          <listitem>
            <para>(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
            Illustrated, Vol 1 reveals that a</para>

            <blockquote>
              <para><quote>gratuitous</quote> ARP packet should cause the
              ISP's router to refresh their ARP cache (section 4.7). A
              gratuitous ARP is simply a host requesting the MAC address for
              its own IP; in addition to ensuring that the IP address isn't a
              duplicate,...</para>

              <para><quote>if the host sending the gratuitous ARP has just
              changed its hardware address..., this packet causes any other
              host...that has an entry in its cache for the old hardware
              address to update its ARP cache entry
              accordingly.</quote></para>
            </blockquote>

            <para>Which is, of course, exactly what you want to do when you
            switch a host from being exposed to the Internet to behind
            Shorewall using one-to-one NAT. Happily enough, recent versions of
            Redhat's iputils package include <quote>arping</quote>, whose
            <quote>-U</quote> flag does just that:</para>

            <para><programlisting><command>arping -U -I &lt;net if&gt; &lt;newly proxied IP&gt;
</command>
<command>arping -U -I eth0 66.58.99.83</command> # for example</programlisting>Stevens
            goes on to mention that not all systems respond correctly to
            gratuitous ARPs, but googling for <quote>arping -U</quote> seems
            to support the idea that it works most of the time.</para>
          </listitem>

          <listitem>
            <para>You can call your ISP and ask them to purge the stale ARP
            cache entry but many either can't or won't purge individual
            entries.</para>
          </listitem>
        </orderedlist>

        <para>You can determine if your ISP's gateway ARP cache is stale using
        ping and tcpdump. Suppose that we suspect that the gateway router has
        a stale ARP cache entry for 192.0.2.177. On the firewall, run tcpdump
        as follows:</para>

        <para><programlisting><command>tcpdump -nei eth0 icmp</command></programlisting></para>

        <para>Now from 192.0.2.177, ping the ISP's gateway (which we will
        assume is 192.0.2.254):</para>

        <para><programlisting><command>ping 192.0.2.254</command></programlisting></para>

        <para>We can now observe the tcpdump output:</para>

        <para><programlisting>13:35:12.159321 <emphasis role="bold">0:4:e2:20:20:33</emphasis> 0:0:77:95:dd:19 ip 98:
                192.0.2.177 &gt; 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 <emphasis role="bold">0:c0:a8:50:b2:57</emphasis> ip 98:
                192.0.2.254 &gt; 192.0.2.177 : icmp: echo reply</programlisting>Notice
        that the source MAC address in the echo request is different from the
        destination MAC address in the echo reply!! In this case
        0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
        0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the
        gateway's ARP cache still associates 192.0.2.177 with the NIC in DMZ 1
        rather than with the firewall's eth0.</para>
      </section>
    </section>

    <section id="Rules">
      <title>Rules</title>

      <note>
        <para>Shorewall has a <ulink url="Macros.html">macro facility</ulink>
        that includes macros for many standard applications. This section does
        not use those macros but rather defines the rules directly.</para>
      </note>

      <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

      <para>With the default policies described earlier in this document, your
      local systems (Local 1-3) can access any server on the Internet and the
      DMZ can't access any other host (including the firewall). With the
      exception of DNAT rules which cause address translation and allow the
      translated connection request to pass through the firewall, the way to
      allow connection requests through your firewall is to use ACCEPT
      rules.</para>

      <note>
        <para>Since the SPORT and ORIGDEST. Columns aren't used in this
        section, they won't be shown</para>
      </note>

      <para>You probably want to allow ping between your zones:</para>

      <programlisting>#ACTION  SOURCE  DEST               PROTO  DPORT   
ACCEPT   net     dmz                icmp   echo-request
ACCEPT   net     loc                icmp   echo-request
ACCEPT   dmz     loc                icmp   echo-request
ACCEPT   loc     dmz                icmp   echo-request</programlisting>

      <para>Let's suppose that you run mail and pop3 servers on DMZ 2 and a
      Web Server on DMZ 1. The rules that you would need are:</para>

      <programlisting>#ACTION  SOURCE          DEST               PROTO  DPORT
ACCEPT   net             dmz:192.0.2.178    tcp    smtp    #Mail from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.178    tcp    pop3    #Pop3 from
                                                           #Internet
ACCEPT   loc             dmz:192.0.2.178    tcp    smtp    #Mail from local
                                                           #Network
ACCEPT   loc             dmz:192.0.2.178    tcp    pop3    #Pop3 from local
                                                           #Network
ACCEPT   $FW             dmz:192.0.2.178    tcp    smtp    #Mail from the
                                                           #Firewall
ACCEPT   dmz:192.0.2.178 net                tcp    smtp    #Mail to the
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    http    #WWW from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from Internet
ACCEPT   loc             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from local
                                                           #Network</programlisting>

      <para>If you run a public DNS server on 192.0.2.177, you would need to
      add the following rules:</para>

      <programlisting>#ACTION  SOURCE          DEST               PROTO  DPORT
ACCEPT   net             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Internet
ACCEPT   loc             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Local Network
ACCEPT   loc             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Local Network
ACCEPT   $FW             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #the Firewall
ACCEPT   $FW             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #the Firewall
ACCEPT   dmz:192.0.2.177 net                udp    domain  #UDP DNS to
                                                           #the Internet
ACCEPT   dmz:192.0.2.177 net                tcp    domain  #TCPP DNS to
                                                           #the Internet</programlisting>

      <para>You probably want some way to communicate with your firewall and
      DMZ systems from the local network -- I recommend SSH which through its
      scp utility can also do publishing and software update
      distribution.</para>

      <programlisting>#ACTION  SOURCE          DEST               PROTO  DPORT
ACCEPT   loc             dmz                tcp    ssh     #SSH to the DMZ
ACCEPT   net             $FW                tcp    ssh     #SSH to the
                                                           #Firewall</programlisting>
    </section>

    <section id="OddsAndEnds">
      <title>Odds and Ends</title>

      <para>The above discussion reflects my personal preference for using
      Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I
      prefer to use NAT only in cases where a system that is part of an RFC
      1918 subnet needs to have its own public IP.</para>

      <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

      <para>If you haven't already, it would be a good idea to browse through
      <ulink
      url="manpages/shorewall.conf.htmlig"><filename>/etc/shorewall/shorewall.conf</filename></ulink>
      just to see if there is anything there that might be of interest. You
      might also want to look at the other configuration files that you
      haven't touched yet just to get a feel for the other things that
      Shorewall can do.</para>

      <para>In case you haven't been keeping score, here's the final set of
      configuration files for our sample network. Only those that were
      modified from the original installation are shown.</para>

      <para><filename>/etc/shorewall/interfaces</filename> (The
      <quote>options</quote> will be very site-specific).</para>

      <programlisting>?FORMAT 2
#ZONE    INTERFACE      OPTIONS
net      eth0           routefilter
loc      eth1
dmz      eth2</programlisting>

      <para><filename>/etc/shorewall/masq</filename> - Local Subnet</para>

      <programlisting>#INTERFACE     SUBNET               ADDRESS
eth0           192.168.201.0/29     192.0.2.176</programlisting>

      <para>When running Shorewall 5.0.14 or later, the equivalent
      <filename>/etc/shorewall/snat</filename> is:</para>

      <programlisting>#ACTION                SOURCE            DEST                PROTO   PORT
SNAT(192.02.176)       192.168.201.0/24  eth0</programlisting>

      <para><filename>/etc/shorewall/proxyarp</filename> - DMZ</para>

      <programlisting>#ADDRESS     EXTERNAL     INTERFACE     HAVE ROUTE
192.0.2.177  eth2         eth0          No
192.0.2.178  eth2         eth0          No</programlisting>

      <para><filename>/etc/shorewall/nat</filename>- Daughter's System</para>

      <programlisting>#EXTERNAL   INTERFACE   INTERNAL       ALL INTERFACES   LOCAL
192.0.2.179 eth0        192.168.201.4  No               No</programlisting>

      <para><filename>/etc/shorewall/rules</filename></para>

      <programlisting>#ACTION  SOURCE          DEST               PROTO  DPORT
ACCEPT   net             dmz                icmp   echo-request
ACCEPT   net             loc                icmp   echo-request
ACCEPT   dmz             loc                icmp   echo-request
ACCEPT   loc             dmz                icmp   echo-request
ACCEPT   net             loc:192.168.201.4  tcp    www     #Daughter's
                                                           #Server
ACCEPT   net             dmz:192.0.2.178    tcp    smtp    #Mail from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.178    tcp    pop3    #Pop3 from
                                                           #Internet
ACCEPT   loc             dmz:192.0.2.178    tcp    smtp    #Mail from local
                                                           #Network
ACCEPT   loc             dmz:192.0.2.178    tcp    pop3    #Pop3 from local
                                                           #Network
ACCEPT   $FW             dmz:192.0.2.178    tcp    smtp    #Mail from the
                                                           #Firewall
ACCEPT   dmz:192.0.2.178 net                tcp    smtp    #Mail to the
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    http    #WWW from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from Internet
ACCEPT   loc             dmz:192.0.2.177    tcp    https   #Secure WWW
                                                           #from local
                                                           #Network
ACCEPT   net             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Internet
ACCEPT   net             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Internet
ACCEPT   loc             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #Local Network
ACCEPT   loc             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #Local Network
ACCEPT   $FW             dmz:192.0.2.177    udp    domain  #UDP DNS from
                                                           #the Firewall
ACCEPT   $FW             dmz:192.0.2.177    tcp    domain  #TCP DNS from
                                                           #the Firewall
ACCEPT   dmz:192.0.2.177 net                udp    domain  #UDP DNS to
                                                           #the Internet
ACCEPT   dmz:192.0.2.177 net                tcp    domain  #TCPP DNS to
                                                           #the Internet
ACCEPT   loc             dmz                tcp    ssh     #SSH to the DMZ
ACCEPT   net             $FW                tcp    ssh     #SSH to the
                                                           #Firewall</programlisting>
    </section>
  </section>

  <section id="DNS">
    <title>DNS</title>

    <para>Given the collection of RFC 1918 and public addresses in this setup,
    it only makes sense to have separate internal and external DNS servers.
    You can combine the two into a single BIND 9 server using Views. If you
    are not interested in Bind 9 views, you can go to the next section.</para>

    <para>Suppose that your domain is foobar.net and you want the two DMZ
    systems named www.foobar.net and mail.foobar.net and you want the three
    local systems named "winken.foobar.net, blinken.foobar.net and
    nod.foobar.net. You want your firewall to be known as firewall.foobar.net
    externally and its interface to the local network to be know as
    gateway.foobar.net and its interface to the dmz as dmz.foobar.net. Let's
    have the DNS server on 192.0.2.177 which will also be known by the name
    ns1.foobar.net.</para>

    <para>The <filename>/etc/named.conf </filename>file would look like
    this:</para>

    <programlisting>

options {
        directory "/var/named";
        listen-on { 127.0.0.1 ; 192.0.2.177; };
        transfer-format many-answers;
        max-transfer-time-in 60;

allow-transfer {
        // Servers allowed to request zone transfers 
       &lt;secondary NS IP&gt;; };
};

logging {
        channel xfer-log {
                file "/var/log/named/bind-xfer.log";
                print-category yes;
                print-severity yes;
                print-time yes;
                severity info;
};

        category xfer-in { xfer-log; };
        category xfer-out { xfer-log; };
        category notify { xfer-log; };
};

#
# This is the view presented to our internal systems
#

view "internal" {
        #
        # These are the clients that see this view
        #
        match-clients { 192.168.201.0/29;
                        192.168.202.0/29;
                        127.0.0.0/8;
                        192.0.2.176/32; 
                        192.0.2.178/32;
                        192.0.2.179/32;
                        192.0.2.180/32; };
        #
        # If this server can't complete the request, it should use
        # outside servers to do so
        #
        recursion yes;

        zone "." in {
                type hint;
                file "int/root.cache";
        };

        zone "foobar.net" in {
                type master;
                notify no;
                allow-update { none; };
                file "int/db.foobar";
        };

        zone "0.0.127.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "int/db.127.0.0";
        };

        zone "201.168.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "int/db.192.168.201";
        };

        zone "202.168.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "int/db.192.168.202";
        };

        zone "176.2.0.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "db.192.0.2.176";
        };
 
        zone "177.2.0.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "db.192.0.2.177";
        };

        zone "178.2.0.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "db.192.0.2.178";
        };

        zone "179.2.0.192.in-addr.arpa" in {
                type master;
                notify no;
                allow-update { none; };
                file "db.206.124.146.179";
        };

};
#
# This is the view that we present to the outside world
#
view "external" {
         match-clients { any; };
         #
         # If we can't answer the query, we tell the client so
         #
         recursion no;

         zone "foobar.net" in {
                 type master;
                 notify yes;
                 allow-update {none; };
                 file "ext/db.foobar";
         };

         zone "176.2.0.192.in-addr.arpa" in {
                 type master;
                 notify yes;
                 allow-update { none; };
                 file "db.192.0.2.176";
         };

         zone "177.2.0.192.in-addr.arpa" in {
                 type master;
                 notify yes;
                 allow-update { none; };
                 file "db.192.0.2.177";
         };

         zone "178.2.0.192.in-addr.arpa" in {
                 type master;
                 notify yes;
                 allow-update { none; };
                 file "db.192.0.2.178";
         };

         zone "179.2.0.192.in-addr.arpa" in {
                 type master;
                 notify yes;
                 allow-update { none; };
                 file "db.192.0.2.179";
         };
};</programlisting>

    <para>Here are the files in <filename
    class="directory">/var/named</filename> (those not shown are usually
    included in your bind distribution).</para>

    <para><filename>db.192.0.2.176</filename> - This is the reverse zone for
    the firewall's external interface</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
; Filename: db.192.0.2.176
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                        2001102303 ; serial
                        10800 ; refresh (3 hour)
                        3600 ; retry (1 hour)
                        604800 ; expire (7 days)
                        86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@        604800  IN NS   ns1.foobar.net.
@        604800  IN NS   &lt;name of secondary ns&gt;.
;
; ############################################################
; Inverse Address Arpa Records (PTR's) 
; ############################################################
176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.</programlisting>

    <para><filename>db.192.0.2.177</filename> - Reverse zone www server</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
; Filename: db.192.0.2.177
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                        2001102303 ; serial
                        10800 ; refresh (3 hour)
                        3600 ; retry (1 hour)
                        604800 ; expire (7 days)
                        86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@        604800  IN NS   ns1.foobar.net.
@        604800  IN NS   &lt;name of secondary ns&gt;.
;
; ############################################################
; Inverse Address Arpa Records (PTR's) 
; ############################################################
177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.</programlisting>

    <para><filename>db.192.0.2.178</filename> - Reverse zone for the mail
    server</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
; Filename: db.192.0.2.178
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                      2001102303 ; serial
                      10800 ; refresh (3 hour)
                      3600 ; retry (1 hour)
                      604800 ; expire (7 days)
                      86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@        604800  IN NS   ns1.foobar.net.
@        604800  IN NS   &lt;name of secondary ns&gt;.
;
; ############################################################
; Inverse Address Arpa Records (PTR's) 
; ############################################################
178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.</programlisting>

    <para><filename>db.192.0.2.179</filename> - Reverse zone for Daughter's
    public web server</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
; Filename: db.192.0.2.179
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                      2001102303 ; serial
                      10800 ; refresh (3 hour)
                      3600 ; retry (1 hour)
                      604800 ; expire (7 days)
                      86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@        604800  IN NS   ns1.foobar.net.
@        604800  IN NS   &lt;name of secondary ns&gt;.
;
; ############################################################
; Inverse Address Arpa Records (PTR's) 
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.</programlisting>

    <para><filename>int/db.127.0.0</filename> - Reverse zone for
    localhost</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
; Filename: db.127.0.0
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                             2001092901 ; serial
                             10800 ; refresh (3 hour)
                             3600 ; retry (1 hour)
                             604800 ; expire (7 days)
                             86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@     604800          IN NS   ns1.foobar.net.

; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
1       86400           IN PTR  localhost.foobar.net.</programlisting>

    <para><filename>int/db.192.168.201</filename> - Reverse zone for the local
    network. This is only shown to internal clients.</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
; Filename: db.192.168.201
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
                                2002032501 ; serial
                                10800 ; refresh (3 hour)
                                3600 ; retry (1 hour)
                                604800 ; expire (7 days)
                                86400 ) ; minimum (1 day)

; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@       604800          IN NS   ns1.foobar.net.
; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
1       86400           IN PTR  gateway.foobar.net.
2       86400           IN PTR  winken.foobar.net.
3       86400           IN PTR  blinken.foobar.net.
4       86400           IN PTR  nod.foobar.net.</programlisting>

    <para><filename>int/db.192.168.202</filename> - Reverse zone for the
    firewall's DMZ Interface</para>

    <programlisting>; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
; Filename: db.192.168.202
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
                                2002032501 ; serial
                                10800 ; refresh (3 hour)
                                3600 ; retry (1 hour)
                                604800 ; expire (7 days)
                                86400 ) ; minimum (1 day)

; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@             604800  IN NS   ns1.foobar.net.

; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
1               86400 IN PTR  dmz.foobar.net.</programlisting>

    <para><filename>int/db.foobar </filename>- Forward zone for internal
    clients.</para>

    <programlisting>;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                        2002071501 ; serial
                        10800 ; refresh (3 hour)
                        3600 ; retry (1 hour)
                        604800 ; expire (7 days)
                        86400 ); minimum (1 day)
;############################################################
; foobar.net Nameserver Records (NS)
;############################################################
@                 604800  IN NS   ns1.foobar.net.

;############################################################
; Foobar.net Office Records (ADDRESS)
;############################################################
localhost 86400   IN A    127.0.0.1

firewall       86400   IN A    192.0.2.176
www            86400   IN A    192.0.2.177
ns1            86400   IN A    192.0.2.177
mail           86400   IN A    192.0.2.178 

gateway        86400   IN A    192.168.201.1
winken         86400   IN A    192.168.201.2
blinken        86400   IN A    192.168.201.3
nod            86400   IN A    192.168.201.4

dmz            86400   IN A    192.168.202.1</programlisting>

    <para><filename>ext/db.foobar </filename>- Forward zone for external
    clients.</para>

    <programlisting>;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
                        2002052901 ; serial
                        10800 ; refresh (3 hour)
                        3600 ; retry (1 hour)
                        604800 ; expire (7 days)
                        86400 ); minimum (1 day)
;############################################################
; Foobar.net Nameserver Records (NS)
;############################################################
@                86400   IN NS   ns1.foobar.net.
@                86400   IN NS   &lt;secondary NS&gt;.
;############################################################
; Foobar.net        Foobar Wa Office Records (ADDRESS)
;############################################################
localhost         86400   IN A    127.0.0.1
;
; The firewall itself
;
firewall          86400   IN A    192.0.2.176
;
; The DMZ
;
ns1               86400   IN A    192.0.2.177
www               86400   IN A    192.0.2.177
mail              86400   IN A    192.0.2.178
;
; The Local Network
;
nod             86400   IN A    192.0.2.179

;############################################################
; Current Aliases for foobar.net (CNAME)
;############################################################

;############################################################
; foobar.net MX Records (MAIL EXCHANGER)
;############################################################
foobar.net.      86400   IN A    192.0.2.177
                 86400   IN MX 0 mail.foobar.net.
                 86400   IN MX 1 &lt;backup MX&gt;.</programlisting>
  </section>

  <section id="Other">
    <title>Some Things to Keep in Mind</title>

    <itemizedlist>
      <listitem>
        <para><emphasis role="bold">You cannot test your firewall from the
        inside</emphasis>. Just because you send requests to your firewall
        external IP address does not mean that the request will be associated
        with the external interface or the <quote>net</quote> zone. Any
        traffic that you generate from the local network will be associated
        with your local interface and will be treated as loc-&gt;$FW
        traffic.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">IP addresses are properties of systems,
        not of interfaces</emphasis>. It is a mistake to believe that your
        firewall is able to forward packets just because you can ping the IP
        address of all of the firewall's interfaces from the local network.
        The only conclusion you can draw from such pinging success is that the
        link between the local system and the firewall works and that you
        probably have the local system's default gateway set correctly.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">All IP addresses configured on firewall
        interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
        the IP address of your internal interface then you can write
        <quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
        rule but you may not write <quote><emphasis
        role="bold">loc:192.168.1.254</emphasis></quote>. Similarly, it is
        nonsensical to add 192.168.1.254 to the <emphasis
        role="bold">loc</emphasis> zone using an entry in
        <filename>/etc/shorewall/hosts</filename>.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Reply packets do NOT automatically follow
        the reverse path of the one taken by the original request</emphasis>.
        All packets are routed according to the routing table of the host at
        each step of the way. This issue commonly comes up when people install
        a Shorewall firewall parallel to an existing gateway and try to use
        DNAT through Shorewall without changing the default gateway of the
        system receiving the forwarded requests. Requests come in through the
        Shorewall firewall where the destination IP address gets rewritten but
        replies go out unmodified through the old gateway.</para>
      </listitem>

      <listitem>
        <para><emphasis role="bold">Shorewall itself has no notion of inside
        or outside</emphasis>. These concepts are embodied in how Shorewall is
        configured.</para>
      </listitem>
    </itemizedlist>
  </section>

  <section id="StartingAndStopping">
    <title>Starting and Stopping the Firewall</title>

    <para>The <ulink url="Install.htm">Installation procedure</ulink>
    configures your system to start Shorewall at system boot.</para>

    <para>The firewall is started using the <quote>shorewall start</quote>
    command and stopped using <quote>shorewall stop</quote>. When the firewall
    is stopped, routing is enabled on those hosts that have an ACCEPT entry in
    <filename><ulink
    url="manpages/shorewall-stoppedrules.html">/etc/shorewall/stoppedrules</ulink></filename>.
    A running firewall may be restarted using the <quote>shorewall
    restart</quote> command. If you want to totally remove any trace of
    Shorewall from your Netfilter configuration, use <quote>shorewall
    clear</quote>.</para>

    <para><inlinegraphic fileref="images/BD21298_.gif"/></para>

    <para>Edit the <filename><ulink
    url="manpages/shorewall-stoppedrules.html">/etc/shorewall/stoppedrules</ulink></filename>
    file and add ACCEPT rules for those systems that you want to be able to
    access the firewall when it is stopped.</para>

    <caution>
      <para>If you are connected to your firewall from the Internet, do not
      issue a <quote>shorewall stop</quote> command unless you have added an
      ACCEPT entry for the IP address that you are connected from to
      <filename><ulink
      url="manpages/shorewall-stoppedrules.html">/etc/shorewall/stoppedrules</ulink></filename>.
      Also, I don't recommend using <quote>shorewall restart</quote>; it is
      better to create an <ulink
      url="starting_and_stopping_shorewall.htm"><emphasis>an alternate
      configuration</emphasis></ulink> and test it using the <quote><ulink
      url="starting_and_stopping_shorewall.htm"><command>shorewall
      try</command></ulink></quote> command.</para>
    </caution>
  </section>
</article>