<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall Setup Guide</title><link rel="stylesheet" href="html.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title"><a id="IPIP"></a>Shorewall Setup Guide</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2005 Thomas M. Eastep</p></div><div><div class="legalnotice"><a id="id286316"></a><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a class="ulink" href="GnuCopyright.htm" target="_self">GNU Free Documentation
License</a></span>”.</p></div></div><div><p class="pubdate">2008/12/15</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#Introduction">Introduction</a></span></dt><dt><span class="section"><a href="#Concepts">Shorewall Concepts</a></span></dt><dt><span class="section"><a href="#Interfaces">Network Interfaces</a></span></dt><dt><span class="section"><a href="#Addressing">Addressing, Subnets and Routing</a></span></dt><dd><dl><dt><span class="section"><a href="#Addresses">IP Addresses</a></span></dt><dt><span class="section"><a href="#Subnets">Subnets</a></span></dt><dt><span class="section"><a href="#Routing">Routing</a></span></dt><dt><span class="section"><a href="#ARP">Address Resolution Protocol (ARP)</a></span></dt><dt><span class="section"><a href="#RFC1918">RFC 1918</a></span></dt></dl></dd><dt><span class="section"><a href="#Options">Setting Up Your Network</a></span></dt><dd><dl><dt><span class="section"><a href="#Routed">Routed</a></span></dt><dt><span class="section"><a href="#NonRouted">Non-routed</a></span></dt><dd><dl><dt><span class="section"><a href="#SNAT">SNAT</a></span></dt><dt><span class="section"><a href="#dnat">DNAT</a></span></dt><dt><span class="section"><a href="#ProxyARP">Proxy ARP</a></span></dt><dt><span class="section"><a href="#NAT">One-to-one NAT</a></span></dt></dl></dd><dt><span class="section"><a href="#Rules">Rules</a></span></dt><dt><span class="section"><a href="#OddsAndEnds">Odds and Ends</a></span></dt></dl></dd><dt><span class="section"><a href="#DNS">DNS</a></span></dt><dt><span class="section"><a href="#Other">Some Things to Keep in Mind</a></span></dt><dt><span class="section"><a href="#StartingAndStopping">Starting and Stopping the Firewall</a></span></dt></dl></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>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.</strong></span></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Introduction"></a>Introduction</h2></div></div></div><p>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 <a class="ulink" href="shorewall_quickstart_guide.htm" target="_self">single-address guides</a>.
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.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>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 <span class="bold"><strong>ip</strong></span>
program on your firewall system. As root, you can use the
“<span class="quote">which</span>” command to check for this program:</p><pre class="programlisting">[root@gateway root]# <span class="command"><strong>which ip</strong></span>
/sbin/ip
[root@gateway root]#</pre><p>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 <img src="images/BD21298_.gif" />.</p></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>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.</p><div class="itemizedlist"><ul type="disc"><li><p><a class="ulink" href="http://www.simtel.net/pub/pd/51438.html" target="_self">Windows
Version of dos2unix</a></p></li><li><p><a class="ulink" href="http://www.megaloman.com/%7Ehany/software/hd2u/" target="_self">Linux Version
of dos2unix</a></p></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Concepts"></a>Shorewall Concepts</h2></div></div></div><p><img src="images/BD21298_.gif" /></p><p>The configuration files for Shorewall are contained in the directory
<code class="filename">/etc/shorewall</code> -- 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 <a class="ulink" href="Install.htm" target="_self">Installation Process</a>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p><span class="bold"><strong>Note to Debian Users</strong></span></p><p>If you install using the .deb, you will find that your <code class="filename">/etc/shorewall</code> directory is empty. This
is intentional. The released configuration file skeletons may be found
on your system in the directory <code class="filename">/usr/share/doc/shorewall-common/default-config</code>.
Simply copy the files you need from that directory to <code class="filename">/etc/shorewall</code> and modify the
copies.</p><p>Note that you must copy <code class="filename">/usr/share/doc/shorewall-common/default-config/shorewall.conf</code>
and /usr/share/doc/shorewall-common/default-config/modules to <code class="filename">/etc/shorewall</code> even if you do not modify
those files.</p></div><p>As each file is introduced, I suggest that you look through the
actual file on your system -- each file contains detailed configuration
instructions.</p><p>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 <code class="filename">/etc/shorewall/hosts</code>, or as an entire
interface in <code class="filename">/etc/shorewall/interfaces</code>. In this guide, we
will use the following zones:</p><div class="variablelist"><dl><dt><span class="term">fw</span></dt><dd><p>The firewall system itself.</p></dd><dt><span class="term">net</span></dt><dd><p>The public Internet.</p></dd><dt><span class="term">loc</span></dt><dd><p>A private local network using private IP addresses.</p></dd><dt><span class="term">dmz</span></dt><dd><p>A Demilitarized Zone holding publicly-accessible
servers.</p></dd></dl></div><p>Zones are defined in the file <code class="filename"><a class="ulink" href="manpages/shorewall-zones.html" target="_self"><code class="filename">/etc/shorewall/zones</code></a></code>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>The <code class="filename">/etc/shorewall/zones</code> 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:</p><pre class="programlisting">#ZONE TYPE OPTIONS
fw firewall
net ipv4
loc ipv4
dmz ipv4</pre></div><p>Note that Shorewall recognizes the firewall system as its own zone -
The above example follows the usual convention of naming the Firewall zone
<span class="bold"><strong>fw</strong></span>. The name specified for the firewall
zone (<span class="bold"><strong>fw</strong></span> in the above example) is stored
in the shell variable <em class="firstterm">$FW</em> 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 “<span class="quote">because this is
the Internet zone</span>” or “<span class="quote">because that is the
DMZ</span>”.</p><p><img src="images/BD21298_.gif" /></p><p>Edit the /etc/shorewall/zones file and make any changes
necessary.</p><p>Rules about what traffic to allow and what traffic to deny are
expressed in terms of zones.</p><div class="itemizedlist"><ul type="disc"><li><p>You express your default policy for connections from one zone to
another zone in the <code class="filename"><a class="ulink" href="manpages/shorewall-policy.html" target="_self">/etc/shorewall/policy</a></code>
file.</p></li><li><p>You define exceptions to those default policies in the
<code class="filename"><a class="ulink" href="manpages/shorewall-rules.html" target="_self">/etc/shorewall/rules</a></code>.</p></li></ul></div><p>Shorewall is built on top of the <a class="ulink" href="http://www.netfilter.org" target="_self">Netfilter</a> kernel facility.
Netfilter implements a <a class="ulink" href="http://www.cs.princeton.edu/~jns/security/iptables/iptables_conntrack.html" target="_self">connection
tracking function</a> 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:</p><div class="orderedlist"><ol type="1"><li><p>Identify the source (client) zone.</p></li><li><p>Identify destination (server) zone.</p></li><li><p>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.</p></li><li><p>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.</p></li></ol></div><p>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
<span class="bold"><strong>DOES NOT mean that these connections are allowed
from zone A to zone B</strong></span> (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.</p><p>For each connection request entering the firewall, the request is
first checked against the <code class="filename">/etc/shorewall/rules</code> file.
If no rule in that file matches the connection request then the first
policy in <code class="filename">/etc/shorewall/policy</code> that matches the
request is applied after the request is passed to the appropriate <a class="ulink" href="Actions.html" target="_self">default action</a> (if any).</p><p>Prior to Shorewall 2.2.0, the default
<code class="filename">/etc/shorewall/policy</code> file had the following
policies:</p><pre class="programlisting">#SOURCE ZONE DESTINATION ZONE POLICY LOG LIMIT:BURST
# LEVEL
loc net ACCEPT
net all DROP info
all all REJECT info</pre><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>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.</p></div><p>The above policies will:</p><div class="orderedlist"><ol type="1"><li><p>allow all connection requests from your local network to the
Internet</p></li><li><p>drop (ignore) all connection requests from the Internet to your
firewall or local network and log a message at the info level (<a class="ulink" href="shorewall_logging.html" target="_self">here is a description of log
levels</a>).</p></li><li><p>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.</p></li></ol></div><p><img src="images/BD21298_.gif" /></p><p>At this point, edit your <code class="filename">/etc/shorewall/policy
</code>and make any changes that you wish.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Interfaces"></a>Network Interfaces</h2></div></div></div><p>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.</p><p>In this diagram:</p><div class="itemizedlist"><ul type="disc"><li><p>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.</p></li><li><p>The Local Zone consists of systems Local 1, Local 2 and Local
3.</p></li><li><p>All systems from the ISP outward comprise the Internet
Zone.</p></li></ul></div><div align="center"><img src="images/dmz3.png" align="middle" /></div><p>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 <a class="ulink" href="manpages/shorewall-interfaces.html" target="_self">/etc/shorewall/interfaces</a> file.
The firewall illustrated above has three network interfaces. Where
Internet connectivity is through a cable or DSL “<span class="quote">Modem</span>”, the
<span class="emphasis"><em>External Interface</em></span> will be the Ethernet adapter that
is connected to that “<span class="quote">Modem</span>” (e.g., <code class="filename">eth0</code>) 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.,
<code class="filename">ppp0</code>). If you connect via a
regular modem, your External Interface will also be <code class="filename">ppp0</code>. If you connect using ISDN, you
external interface will be <code class="filename">ippp0</code>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external interface is <code class="filename">ppp0</code> or <code class="filename">ippp0</code> then you will want to set CLAMPMSS=yes
in <code class="filename"><a class="ulink" href="manpages/shorewall.conf.htmlig" target="_self">/etc/shorewall/shorewall.conf</a></code>.</p><p>Your <span class="emphasis"><em>Local Interface</em></span> will be an Ethernet
adapter (<code class="filename">eth0</code>,
<code class="filename">eth1</code> or <code class="filename">eth2</code>)
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).</p><p>Your <span class="emphasis"><em>DMZ Interface</em></span> will also be an Ethernet
adapter (<code class="filename">eth0</code>, <code class="filename">eth1</code> or <code class="filename">eth2</code>) 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).</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>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 <span class="bold"><strong>arp_filter</strong></span> option or the <span class="bold"><strong>arp_ignore</strong></span> option in
<code class="filename">/etc/shorewall/interfaces</code> for all interfaces
connected to the common hub/switch. Using such a setup with a production
firewall is strongly recommended against.</p></div><p>For the remainder of this Guide, we will assume that:</p><div class="itemizedlist"><ul type="disc"><li><p>The External Interface is <code class="filename">eth0</code>.</p></li><li><p>The Local Interface <code class="filename">eth1</code>.</p></li><li><p>The DMZ Interface <code class="filename">eth2</code>.</p></li></ul></div><p>The Shorewall default configuration does not define the contents of
any zone. To define the above configuration using the <a class="ulink" href="manpages/shorewall-interfaces.html" target="_self">/etc/shorewall/interfaces </a>file,
that file would might contain:</p><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect norfc1918
loc eth1 detect
dmz eth2 detect</pre><p>Note that the <span class="bold"><strong>$FW</strong></span> zone has no entry
in the /etc/shorewall/interfaces file.</p><p><img src="images/BD21298_.gif" /></p><p>Edit the <code class="filename">/etc/shorewall/interfaces</code> 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.</p><div class="example"><a id="multi"></a><p class="title"><b>Example 1. Multiple Interfaces to a Zone</b></p><div class="example-contents"><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect norfc1918
loc eth1 detect
loc eth2 detect</pre></div></div><br class="example-break" /><p><img src="images/BD21298_.gif" /></p><p>You may define more complicated zones using the<code class="filename"> <a class="ulink" href="manpages/shorewall-hosts.html" target="_self">/etc/shorewall/hosts</a></code> file
but in most cases, that isn't necessary. See <a class="ulink" href="Shorewall_and_Aliased_Interfaces.html" target="_self">Shorewall_and_Aliased_Interfaces.html</a>
and <a class="ulink" href="Multiple_Zones.html" target="_self">Multiple_Zones.html</a> for
examples.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Addressing"></a>Addressing, Subnets and Routing</h2></div></div></div><p>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.</p><p>If you are thoroughly familiar with IP addressing and routing, you
may go to the next section.</p><p>The following discussion barely scratches the surface of addressing
and routing. If you are interested in learning more about this subject, I
highly recommend “<span class="quote"><span class="emphasis"><em>IP Fundamentals: What Everyone Needs to
Know about Addressing & Routing</em></span></span>”, Thomas A. Maufer,
Prentice-Hall, 1999, ISBN 0-13-975483-0.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Addresses"></a>IP Addresses</h3></div></div></div><p>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
“<span class="quote">w</span>”, the next byte has value “<span class="quote">x</span>”, etc. If we
take the address 192.0.2.14 and express it in hexadecimal, we
get:</p><pre class="programlisting">C0.00.02.0E</pre><p>or looking at it as a
32-bit integer</p><pre class="programlisting">C000020E</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Subnets"></a>Subnets</h3></div></div></div><p>You will still hear the terms “<span class="quote">Class A network</span>”,
“<span class="quote">Class B network</span>” and “<span class="quote">Class C network</span>”. In
the early days of IP, networks only came in three sizes (there were also
Class D networks but they were used differently):</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Class A - netmask 255.0.0.0, size = 2 ** 24</td></tr><tr><td>Class B - netmask 255.255.0.0, size = 2 ** 16</td></tr><tr><td>Class C - netmask 255.255.255.0, size = 256</td></tr></table><p>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.</p><p>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 <span class="emphasis"><em>Classless InterDomain
Routing</em></span> (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.</p><p>A <span class="emphasis"><em>subnetwork</em></span> (often referred to as a
<span class="emphasis"><em>subnet</em></span>) is a contiguous set of IP addresses such
that:</p><div class="orderedlist"><ol type="1"><li><p>The number of addresses in the set is a power of 2; and</p></li><li><p>The first address in the set is a multiple of the set
size.</p></li><li><p>The first address in the subnet is reserved and is referred to
as the <span class="emphasis"><em>subnet address</em></span>.</p></li><li><p>The last address in the subnet is reserved as the subnet's
<span class="emphasis"><em>broadcast address</em></span>.</p></li></ol></div><p>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.</p><p>Since n is a power of two, we can easily calculate the
<span class="emphasis"><em>Base-2 Logarithm</em></span> (log2) of n. For the more common
subnet sizes, the size and its base-2 logarithm are given in the
following table:</p><div class="table"><a id="Logs"></a><p class="title"><b>Table 1. Base-2 Logarithms</b></p><div class="table-contents"><table summary="Base-2 Logarithms" border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>n</strong></span></td><td><span class="bold"><strong>log2 n</strong></span></td><td><span class="bold"><strong>(32 - log2 n)</strong></span></td></tr><tr><td>8</td><td>3</td><td>29</td></tr><tr><td>16</td><td>4</td><td>28</td></tr><tr><td>32</td><td>5</td><td>27</td></tr><tr><td>64</td><td>6</td><td>26</td></tr><tr><td>128</td><td>7</td><td>25</td></tr><tr><td>256</td><td>8</td><td>24</td></tr><tr><td>512</td><td>9</td><td>23</td></tr><tr><td>1024</td><td>10</td><td>22</td></tr><tr><td>2048</td><td>11</td><td>21</td></tr><tr><td>4096</td><td>12</td><td>20</td></tr><tr><td>8192</td><td>13</td><td>19</td></tr><tr><td>16384</td><td>14</td><td>18</td></tr><tr><td>32768</td><td>15</td><td>17</td></tr><tr><td>65536</td><td>16</td><td>16</td></tr></tbody></table></div></div><br class="table-break" /><p>You will notice that the above table also contains a column for
(32 - log2 <span class="bold"><strong>n)</strong></span>. That number is the
<span class="emphasis"><em>Variable Length Subnet Mask</em></span> (VLSM) for a network of
size n. From the above table, we can derive the following one which is a
little easier to use.</p><div class="table"><a id="vlsm"></a><p class="title"><b>Table 2. VLSM</b></p><div class="table-contents"><table summary="VLSM" border="1"><colgroup><col /><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Subnet Size</strong></span></td><td><span class="bold"><strong>VLSM</strong></span></td><td><span class="bold"><strong>Subnet Mask</strong></span></td></tr><tr><td>8</td><td>/29</td><td>255.255.255.248</td></tr><tr><td>16</td><td>/28</td><td>255.255.255.240</td></tr><tr><td>32</td><td>/27</td><td>255.255.255.224</td></tr><tr><td>64</td><td>/26</td><td>255.255.255.192</td></tr><tr><td>128</td><td>/25</td><td>255.255.255.128</td></tr><tr><td>256</td><td>/24</td><td>255.255.255.0</td></tr><tr><td>512</td><td>/23</td><td>255.255.254.0</td></tr><tr><td>1024</td><td>/22</td><td>255.255.252.0</td></tr><tr><td>2048</td><td>/21</td><td>255.255.248.0</td></tr><tr><td>4096</td><td>/20</td><td>255.255.240.0</td></tr><tr><td>8192</td><td>/19</td><td>255.255.224.0</td></tr><tr><td>16384</td><td>/18</td><td>255.255.192.0</td></tr><tr><td>32768</td><td>/17</td><td>255.255.128.0</td></tr><tr><td>65536</td><td>/16</td><td>255.255.0.0</td></tr><tr><td>2 ** 24</td><td>/8</td><td>255.0.0.0</td></tr></tbody></table></div></div><br class="table-break" /><p>Notice that the VLSM is written with a slash (“<span class="quote">/</span>”) --
you will often hear a subnet of size 64 referred to as a “<span class="quote">slash
26</span>” subnet and one of size 8 referred to as a “<span class="quote">slash
29</span>”.</p><p>The subnet's mask (also referred to as its
<span class="emphasis"><em>netmask</em></span>) is simply a 32-bit number with the first
“<span class="quote">VLSM</span>” 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:</p><pre class="programlisting">11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0 = 255.255.255.192</pre><p>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.</p><p>For a subnetwork whose address is <span class="bold"><strong>a.b.c.d</strong></span> and whose Variable Length Subnet Mask is
<span class="bold"><strong>/v</strong></span>, we denote the subnetwork as
“<span class="quote"><span class="bold"><strong>a.b.c.d/v</strong></span></span>” using
<span class="emphasis"><em>CIDR Notation</em></span>. Example:</p><div class="table"><a id="Subnet"></a><p class="title"><b>Table 3. Subnet</b></p><div class="table-contents"><table summary="Subnet" border="1"><colgroup><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Subnet:</strong></span></td><td>10.10.10.0 - 10.10.10.127</td></tr><tr><td><span class="bold"><strong>Subnet Size:</strong></span></td><td>128</td></tr><tr><td><span class="bold"><strong>Subnet Address:</strong></span></td><td>10.10.10.0</td></tr><tr><td><span class="bold"><strong>Broadcast
Address:</strong></span></td><td>10.10.10.127</td></tr><tr><td><span class="bold"><strong>CIDR Notation:</strong></span></td><td>10.10.10.0/25</td></tr></tbody></table></div></div><br class="table-break" /><p>There are two degenerate subnets that need mentioning; namely, the
subnet with one member and the subnet with 2 ** 32 members.</p><div class="table"><a id="degenerate"></a><p class="title"><b>Table 4. /32 and /0</b></p><div class="table-contents"><table summary="/32 and /0" border="1"><colgroup><col /><col /><col /><col /></colgroup><tbody><tr><td><span class="bold"><strong>Subnet Size</strong></span></td><td><span class="bold"><strong>VLSM Length</strong></span></td><td><span class="bold"><strong>Subnet Mask</strong></span></td><td><span class="bold"><strong>CIDR Notation</strong></span></td></tr><tr><td>1</td><td>32</td><td>255.255.255.255</td><td>a.b.c.d/32</td></tr><tr><td>32</td><td>0</td><td>0.0.0.0</td><td>0.0.0.0/0</td></tr></tbody></table></div></div><br class="table-break" /><p>So any address <span class="bold"><strong>a.b.c.d</strong></span> may also
be written <span class="bold"><strong>a.b.c.d/32</strong></span> and the set of
all possible IP addresses is written <span class="bold"><strong>0.0.0.0/0</strong></span>.</p><p class="bold">A Shorewall user has contributed a <a class="ulink" href="http://shorewall.net/pub/shorewall/contrib/IPSubNetMask.html" target="_self">useful
graphical summary</a> of the above information.</p><p>Later in this guide, you will see the notation <span class="bold"><strong>a.b.c.d/v</strong></span> used to describe the ip configuration
of a network interface (the “<span class="quote">ip</span>” utility also uses this
syntax). This simply means that the interface is configured with ip
address <span class="bold"><strong>a.b.c.d</strong></span> and with the netmask
that corresponds to VLSM /<span class="bold"><strong>v</strong></span>.</p><div class="example"><a id="Example0"></a><p class="title"><b>Example 2. 192.0.2.65/29</b></p><div class="example-contents"><p>The interface is configured with IP address 192.0.2.65 and
netmask 255.255.255.248.</p></div></div><br class="example-break" /><p>/sbin/shorewall supports an ipcalc command that automatically
calculates information about a [sub]network.</p><div class="example"><a id="Example1"></a><p class="title"><b>Example 3. Using the <span class="command">ipcalc </span>command</b></p><div class="example-contents"><pre class="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
</pre></div></div><br class="example-break" /><div class="example"><a id="Example2"></a><p class="title"><b>Example 4. Using the <span class="command">ipcalc</span> command</b></p><div class="example-contents"><pre class="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</pre></div></div><br class="example-break" /></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Routing"></a>Routing</h3></div></div></div><p>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):</p><pre class="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]#</pre><p>The device <span class="emphasis"><em>texas</em></span> is a GRE tunnel to a peer
site in the Dallas, Texas area.</p><p>The first three routes are <span class="emphasis"><em>host routes</em></span> since
they indicate how to get to a single host. In the “<span class="quote">netstat</span>”
output this can be seen by the “<span class="quote">Genmask</span>” (Subnet Mask) of
255.255.255.255 and the “<span class="quote">H</span>” in the Flags column. The
remainder are <span class="emphasis"><em>“<span class="quote">net</span>” routes</em></span> since they
tell the kernel how to route packets to a subnetwork. The last route is
the <span class="emphasis"><em>default route </em></span>and the gateway mentioned in that
route is called the <span class="emphasis"><em>default gateway</em></span>.</p><p>When the kernel is trying to send a packet to IP address <span class="bold"><strong>A</strong></span>, it starts at the top of the routing table
and:</p><div class="itemizedlist"><ul type="disc"><li><p><span class="bold"><strong>A</strong></span> is logically ANDed with the
“<span class="quote">Genmask</span>” value in the table entry.</p></li><li><p>The result is compared with the “<span class="quote">Destination</span>”
value in the table entry.</p></li><li><p>If the result and the “<span class="quote">Destination</span>” value are the
same, then:</p><div class="itemizedlist"><ul type="circle"><li><p>If the “<span class="quote">Gateway</span>” column is non-zero, the
packet is sent to the gateway over the interface named in the
“<span class="quote">Iface</span>” column.</p></li><li><p>Otherwise, the packet is sent directly to <span class="bold"><strong>A</strong></span> over the interface named in the
“<span class="quote">iface</span>” column.</p></li></ul></div></li><li><p>Otherwise, the above steps are repeated on the next entry in
the table.</p></li></ul></div><p>Since the default route matches any IP address (<span class="bold"><strong>A </strong></span>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:</p><pre class="programlisting">192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2</pre><p>So to route a packet to 192.168.1.5, the packet is sent directly
over eth2.</p><p>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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="ARP"></a>Address Resolution Protocol (ARP)</h3></div></div></div><p>When sending packets over Ethernet, IP addresses aren't used.
Rather Ethernet addressing is based on <span class="emphasis"><em>Media Access
Control</em></span> (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
“<span class="quote">ip</span>” utility:</p><pre class="programlisting">[root@gateway root]# <span class="command"><strong>ip addr show eth0</strong></span>
2: eth0: <BROADCAST,MULTICAST,UP> 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]#
</pre><p>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 <span class="emphasis"><em>Address Resolution
Protocol </em></span>(ARP). Here is ARP in action:</p><pre class="programlisting">[root@gateway root]# <span class="command"><strong>tcpdump -nei eth2 arp</strong></span>
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]#</pre><p>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.</p><p>In order to avoid having to exchange ARP information each time
that an IP packet is to be sent, systems maintain an <span class="emphasis"><em>ARP
cache</em></span> of IP<->MAC correspondences. You can see the ARP
cache on your system (including your Windows system) using the
“<span class="quote">arp</span>” command:</p><pre class="programlisting">[root@gateway root]# <span class="command"><strong>arp -na</strong></span>
? (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</pre><p>The leading question marks are a result of my having specified the
“<span class="quote">n</span>” option (Windows “<span class="quote">arp</span>” doesn't allow that
option) which causes the “<span class="quote">arp</span>” program to forgo IP->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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="RFC1918"></a>RFC 1918</h3></div></div></div><p>IP addresses are allocated by the <a class="ulink" href="http://www.iana.org/" target="_self">Internet Assigned Number Authority</a>
(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 <a class="ulink" href="http://www.arin.net/" target="_self">American Registry for Internet
Numbers</a> (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:</p><pre class="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</pre><p>The addresses reserved by RFC 1918 are sometimes referred to as
<em class="firstterm">non-routable</em> 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.</p><p>When selecting addresses from these ranges, there's a couple of
things to keep in mind:</p><div class="itemizedlist"><ul type="disc"><li><p>As the IPv4 address space becomes depleted, more and more
organizations (including ISPs) are beginning to use RFC 1918
addresses in their infrastructure.</p></li><li><p>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.</p></li></ul></div><p>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.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p><span class="bold"><strong>In this document, external
“<span class="quote">real</span>” 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.</strong></span></p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Options"></a>Setting Up Your Network</h2></div></div></div><p>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:</p><div class="itemizedlist"><ul type="disc"><li><p><span class="bold"><strong>Routed</strong></span> - 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.</p></li><li><p><span class="bold"><strong>Non-routed</strong></span> - Your ISP will send
traffic to each of your addresses directly.</p></li></ul></div><p>In the subsections that follow, we'll look at each of these
separately.</p><p>Before we begin, there is one thing for you to check:</p><p><img src="images/BD21298_.gif" /></p><p>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:</p><div class="itemizedlist"><ul type="disc"><li><p>IP_FORWARDING=On</p></li></ul></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Routed"></a>Routed</h3></div></div></div><p>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.</p><div align="center"><img src="images/dmz4.png" align="middle" /></div><p>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.</p><p>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.</p><p>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:</p><pre class="programlisting">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</pre><p>This means that DMZ 1 will send an ARP “<span class="quote">who-has
192.0.2.65</span>” 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 <span class="underline">DMZ
Interface</span>!! DMZ 1 can then send Ethernet frames addressed to
that MAC address and the frames will be received (correctly) by the
firewall/router.</p><p>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 “<span class="quote">here-is</span>” response reaches the
sender first.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="NonRouted"></a>Non-routed</h3></div></div></div><p>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 “<span class="quote">proxyarp</span>” option on all three
firewall interfaces in the /etc/shorewall/interfaces file.</p><p>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).</p><p><span class="bold"><strong>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.</strong></span></p><p>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.</p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Source Network Address Translation</em></span>
(SNAT).</p></li><li><p><span class="emphasis"><em>Destination Network Address Translation</em></span>
(DNAT) also known as <span class="emphasis"><em>Port Forwarding</em></span>.</p></li><li><p><span class="emphasis"><em>Proxy ARP</em></span>.</p></li><li><p><span class="emphasis"><em>Network Address Translation</em></span> (NAT) also
referred to as <span class="emphasis"><em>One-to-one NA</em></span>T.</p></li></ul></div><p>Often a combination of these techniques is used. Each of these
will be discussed in the sections that follow.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="SNAT"></a>SNAT</h4></div></div></div><p>With SNAT, an internal LAN segment is configured using RFC 1918
addresses. When a host <span class="bold"><strong>A</strong></span> on this
internal segment initiates a connection to host <span class="bold"><strong>B</strong></span> 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 <span class="bold"><strong>B</strong></span> responds
and the response is received by the firewall, the firewall changes the
destination address back to the RFC 1918 address of <span class="bold"><strong>A</strong></span> and forwards the response back to <span class="bold"><strong>A.</strong></span></p><p>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.</p><div align="center"><img src="images/dmz5.png" align="middle" /></div><p>The local zone has been subnetted as 192.168.201.0/29 (netmask
255.255.255.248).</p><table class="simplelist" border="0" summary="Simple list"><tr><td><img src="images/BD21298_.gif" /></td></tr><tr><td>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).</td></tr><tr><td><img src="images/BD21298_.gif" /></td></tr><tr><td>SNAT is configured in Shorewall using the <code class="filename"><a class="ulink" href="manpages/shorewall-masq.html" target="_self">/etc/shorewall/masq</a></code>
file.</td></tr></table><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.201.0/29 192.0.2.176</pre><p>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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="dnat"></a>DNAT</h4></div></div></div><p>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.</p><p><img src="images/BD21298_.gif" /></p><p>Suppose that your daughter wants to run a web server on her
system “<span class="quote">Local 3</span>”. You could allow connections to the
Internet to her server by adding the following entry in
<code class="filename"><a class="ulink" href="manpages/shorewall-rules.html" target="_self">/etc/shorewall/rules</a></code>:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT(S) PORT(S) DEST
DNAT net loc:192.168.201.4 tcp www</pre><p>If one of your daughter's friends at address <span class="bold"><strong>A</strong></span> 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 <span class="bold"><strong>A</strong></span>.</p><p>This example used the firewall's external IP address for DNAT.
You can use another of your public IP addresses (place it in the
ORIGINAL DEST column in the rule above) but Shorewall will not add
that address to the firewall's external interface for you.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>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!</p><p>For DNAT troubleshooting tips, <a class="ulink" href="FAQ.htm#faq1a" target="_self">see
FAQs 1a and 1b</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="ProxyARP"></a>Proxy ARP</h4></div></div></div><p>The idea behind Proxy ARP is that:</p><div class="itemizedlist"><ul type="disc"><li><p>A host <span class="bold"><strong>H</strong></span> behind your
firewall is assigned one of your public IP addresses (<span class="bold"><strong>A</strong></span>), and is assigned the same netmask
(<span class="bold"><strong>M</strong></span>) as the firewall's external
interface.</p></li><li><p>The firewall responds to ARP “<span class="quote">who has</span>” requests
for <span class="bold"><strong>A</strong></span> from machines outside of
the firewall.</p></li><li><p>When <span class="bold"><strong>H</strong></span> issues an ARP
“<span class="quote">who has</span>” request for a machine with an address in
the network defined by <span class="bold"><strong>M</strong></span> where
the target machine is outside of the firewall, the firewall will
respond to <span class="bold"><strong>H</strong></span> (with the MAC of the
firewall interface that <span class="bold"><strong>H</strong></span> is
connected to).</p></li></ul></div><p>For a more complete description of how Proxy ARP works, please
see the <a class="ulink" href="ProxyARP.htm" target="_self">Shorewall Proxy
Documentation</a>.</p><p>Let us suppose that we decide to use Proxy ARP on the DMZ in our
example network.</p><div align="center"><img src="images/dmz6.png" align="middle" /></div><p>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.</p><p><img src="images/BD21298_.gif" /></p><p>The Shorewall configuration of Proxy ARP is done using the<a class="ulink" href="ProxyARP.htm" target="_self"><code class="filename">/etc/shorewall/proxyarp</code></a>
file.</p><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVE ROUTE PERSISTENT
192.0.2.177 eth2 eth0 No
192.0.2.178 eth2 eth0 No</pre><p>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.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span class="bold"><strong>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.</strong></span></p></div><p>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:</p><div class="orderedlist"><ol type="1"><li><p>(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
Illustrated, Vol 1 reveals that a</p><div class="blockquote"><blockquote class="blockquote"><p>“<span class="quote">gratuitous</span>” 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,...</p><p>“<span class="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.</span>”</p></blockquote></div><p>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 “<span class="quote">arping</span>”, whose “<span class="quote">-U</span>” flag does
just that:</p><pre class="programlisting"><span class="command"><strong>arping -U -I <net if> <newly proxied IP></strong></span>
<span class="command"><strong>arping -U -I eth0 66.58.99.83</strong></span> # for example</pre><p>Stevens
goes on to mention that not all systems respond correctly to
gratuitous ARPs, but googling for “<span class="quote">arping -U</span>” seems
to support the idea that it works most of the time.</p></li><li><p>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.</p></li></ol></div><p>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:</p><pre class="programlisting"><span class="command"><strong>tcpdump -nei eth0 icmp</strong></span></pre><p>Now from 192.0.2.177, ping the ISP's gateway (which we will
assume is 192.0.2.254):</p><pre class="programlisting"><span class="command"><strong>ping 192.0.2.254</strong></span></pre><p>We can now observe the tcpdump output:</p><pre class="programlisting">13:35:12.159321 <span class="bold"><strong>0:4:e2:20:20:33</strong></span> 0:0:77:95:dd:19 ip 98:
192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 <span class="bold"><strong>0:c0:a8:50:b2:57</strong></span> ip 98:
192.0.2.254 > 192.0.2.177 : icmp: echo reply</pre><p>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.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="NAT"></a>One-to-one NAT</h4></div></div></div><p>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.</p><div align="center"><img src="images/dmz6.png" align="middle" /></div><p>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
<code class="filename">/etc/shorewall/masq</code>:</p><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.201.0/29 192.0.2.176</pre><p><img src="images/BD21298_.gif" /></p><p>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 <code class="filename"><a class="ulink" href="NAT.htm" target="_self">/etc/shorewall/nat</a></code>.</p><pre class="programlisting">#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
192.0.2.179 eth0 192.168.201.4 No No</pre><p>With this entry in place, you daughter has her own IP address
and the other two local systems share the firewall's IP
address.</p><p><img src="images/BD21298_.gif" /></p><p>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:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT(S) PORT(S) DEST
ACCEPT net loc:192.168.201.4 tcp www</pre><p>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:</p><div class="orderedlist"><ol type="1"><li><p>(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
Illustrated, Vol 1 reveals that a</p><div class="blockquote"><blockquote class="blockquote"><p>“<span class="quote">gratuitous</span>” 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,...</p><p>“<span class="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.</span>”</p></blockquote></div><p>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 “<span class="quote">arping</span>”, whose
“<span class="quote">-U</span>” flag does just that:</p><pre class="programlisting"><span class="command"><strong>arping -U -I <net if> <newly proxied IP>
</strong></span>
<span class="command"><strong>arping -U -I eth0 66.58.99.83</strong></span> # for example</pre><p>Stevens
goes on to mention that not all systems respond correctly to
gratuitous ARPs, but googling for “<span class="quote">arping -U</span>” seems
to support the idea that it works most of the time.</p></li><li><p>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.</p></li></ol></div><p>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:</p><pre class="programlisting"><span class="command"><strong>tcpdump -nei eth0 icmp</strong></span></pre><p>Now from 192.0.2.177, ping the ISP's gateway (which we will
assume is 192.0.2.254):</p><pre class="programlisting"><span class="command"><strong>ping 192.0.2.254</strong></span></pre><p>We can now observe the tcpdump output:</p><pre class="programlisting">13:35:12.159321 <span class="bold"><strong>0:4:e2:20:20:33</strong></span> 0:0:77:95:dd:19 ip 98:
192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 <span class="bold"><strong>0:c0:a8:50:b2:57</strong></span> ip 98:
192.0.2.254 > 192.0.2.177 : icmp: echo reply</pre><p>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.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Rules"></a>Rules</h3></div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Shorewall has a <a class="ulink" href="Macros.html" target="_self">macro facility</a>
that includes macros for many standard applications. This section does
not use those macros but rather defines the rules directly.</p></div><p><img src="images/BD21298_.gif" /></p><p>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.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Since the SOURCE PORT(S) and ORIG. DEST. Columns aren't used in
this section, they won't be shown</p></div><p>You probably want to allow ping between your zones:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net dmz icmp echo-request
ACCEPT net loc icmp echo-request
ACCEPT dmz loc icmp echo-request
ACCEPT loc dmz icmp echo-request</pre><p>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:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST COMMENTS
# PORT(S)
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</pre><p>If you run a public DNS server on 192.0.2.177, you would need to
add the following rules:</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST COMMENTS
# PORT(S)
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</pre><p>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.</p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST COMMENTS
# PORT(S)
ACCEPT loc dmz tcp ssh #SSH to the DMZ
ACCEPT net $FW tcp ssh #SSH to the
#Firewall</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="OddsAndEnds"></a>Odds and Ends</h3></div></div></div><p>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.</p><p><img src="images/BD21298_.gif" /></p><p>If you haven't already, it would be a good idea to browse through
<a class="ulink" href="manpages/shorewall.conf.htmlig" target="_self"><code class="filename">/etc/shorewall/shorewall.conf</code></a>
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.</p><p>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.</p><p><code class="filename">/etc/shorewall/interfaces</code> (The
“<span class="quote">options</span>” will be very site-specific).</p><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect norfc1918,routefilter
loc eth1 detect
dmz eth2 detect</pre><p>The setup described here requires that your network interfaces be
brought up before Shorewall can start. This opens a short window during
which you have no firewall protection. If you replace
“<span class="quote">detect</span>” with the actual broadcast addresses in the entries
above, you can bring up Shorewall before you bring up your network
interfaces.</p><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 192.0.2.255 norfc1918
loc eth1 192.168.201.7
dmz eth2 192.168.202.7</pre><p><code class="filename">/etc/shorewall/masq</code> - Local Subnet</p><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.201.0/29 192.0.2.176</pre><p><code class="filename">/etc/shorewall/proxyarp</code> - DMZ</p><pre class="programlisting">#ADDRESS EXTERNAL INTERFACE HAVE ROUTE
192.0.2.177 eth2 eth0 No
192.0.2.178 eth2 eth0 No</pre><p><code class="filename">/etc/shorewall/nat</code>- Daughter's System</p><pre class="programlisting">#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
192.0.2.179 eth0 192.168.201.4 No No</pre><p><code class="filename">/etc/shorewall/rules</code></p><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST COMMENTS
# PORT(S)
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</pre></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DNS"></a>DNS</h2></div></div></div><p>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.</p><p>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.</p><p>The <code class="filename">/etc/named.conf </code>file would look like
this:</p><pre class="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
<secondary NS IP>; };
};
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";
};
};</pre><p>Here are the files in <code class="filename">/var/named</code> (those not shown are usually
included in your bind distribution).</p><p><code class="filename">db.192.0.2.176</code> - This is the reverse zone for
the firewall's external interface</p><pre class="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 <name of secondary ns>.
;
; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.</pre><p><code class="filename">db.192.0.2.177</code> - Reverse zone www server</p><pre class="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 <name of secondary ns>.
;
; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.</pre><p><code class="filename">db.192.0.2.178</code> - Reverse zone for the mail
server</p><pre class="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 <name of secondary ns>.
;
; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.</pre><p><code class="filename">db.192.0.2.179</code> - Reverse zone for Daughter's
public web server</p><pre class="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 <name of secondary ns>.
;
; ############################################################
; Inverse Address Arpa Records (PTR's)
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.</pre><p><code class="filename">int/db.127.0.0</code> - Reverse zone for
localhost</p><pre class="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.</pre><p><code class="filename">int/db.192.168.201</code> - Reverse zone for the local
network. This is only shown to internal clients.</p><pre class="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.</pre><p><code class="filename">int/db.192.168.202</code> - Reverse zone for the
firewall's DMZ Interface</p><pre class="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.</pre><p><code class="filename">int/db.foobar </code>- Forward zone for internal
clients.</p><pre class="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</pre><p><code class="filename">ext/db.foobar </code>- Forward zone for external
clients.</p><pre class="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 <secondary NS>.
;############################################################
; 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 <backup MX>.</pre></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Other"></a>Some Things to Keep in Mind</h2></div></div></div><div class="itemizedlist"><ul type="disc"><li><p><span class="bold"><strong>You cannot test your firewall from the
inside</strong></span>. 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 “<span class="quote">net</span>” zone. Any
traffic that you generate from the local network will be associated
with your local interface and will be treated as loc->$FW
traffic.</p></li><li><p><span class="bold"><strong>IP addresses are properties of systems,
not of interfaces</strong></span>. 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.</p></li><li><p><span class="bold"><strong>All IP addresses configured on firewall
interfaces are in the $FW (fw) zone</strong></span>. If 192.168.1.254 is
the IP address of your internal interface then you can write
“<span class="quote"><span class="bold"><strong>$FW:192.168.1.254</strong></span></span>” in a
rule but you may not write “<span class="quote"><span class="bold"><strong>loc:192.168.1.254</strong></span></span>”. Similarly, it is
nonsensical to add 192.168.1.254 to the <span class="bold"><strong>loc</strong></span> zone using an entry in
<code class="filename">/etc/shorewall/hosts</code>.</p></li><li><p><span class="bold"><strong>Reply packets do NOT automatically follow
the reverse path of the one taken by the original request</strong></span>.
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.</p></li><li><p><span class="bold"><strong>Shorewall itself has no notion of inside
or outside</strong></span>. These concepts are embodied in how Shorewall is
configured.</p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="StartingAndStopping"></a>Starting and Stopping the Firewall</h2></div></div></div><p>The <a class="ulink" href="Install.htm" target="_self">Installation procedure</a>
configures your system to start Shorewall at system boot.</p><p>The firewall is started using the “<span class="quote">shorewall start</span>”
command and stopped using “<span class="quote">shorewall stop</span>”. When the firewall
is stopped, routing is enabled on those hosts that have an entry in
<code class="filename"><a class="ulink" href="manpages/shorewall-routestopped.html" target="_self">/etc/shorewall/routestopped</a></code>.
A running firewall may be restarted using the “<span class="quote">shorewall
restart</span>” command. If you want to totally remove any trace of
Shorewall from your Netfilter configuration, use “<span class="quote">shorewall
clear</span>”.</p><p><img src="images/BD21298_.gif" /></p><p>Edit the <code class="filename"><a class="ulink" href="manpages/shorewall-routestopped.html" target="_self">/etc/shorewall/routestopped</a></code>
file and configure those systems that you want to be able to access the
firewall when it is stopped.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>If you are connected to your firewall from the Internet, do not
issue a “<span class="quote">shorewall stop</span>” command unless you have added an
entry for the IP address that you are connected from to <code class="filename"><a class="ulink" href="manpages/shorewall-routestopped.html" target="_self">/etc/shorewall/routestopped</a></code>.
Also, I don't recommend using “<span class="quote">shorewall restart</span>”; it is
better to create an <a class="ulink" href="starting_and_stopping_shorewall.htm" target="_self"><span class="emphasis"><em>an alternate
configuration</em></span></a> and test it using the
“<span class="quote"><a class="ulink" href="starting_and_stopping_shorewall.htm" target="_self"><span class="command"><strong>shorewall
try</strong></span></a></span>” command.</p></div></div></div></body></html>
