forked from extern/shorewall_code
2429 lines
98 KiB
XML
2429 lines
98 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
<article id="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 & 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: <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]#
|
|
</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<->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->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 (/etc/shorewall/snat 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 <net if> <newly proxied IP></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 > 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 > 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 <net if> <newly proxied IP>
|
|
</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 > 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 > 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
|
|
<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";
|
|
};
|
|
};</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 <name of secondary ns>.
|
|
;
|
|
; ############################################################
|
|
; 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 <name of secondary ns>.
|
|
;
|
|
; ############################################################
|
|
; 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 <name of secondary ns>.
|
|
;
|
|
; ############################################################
|
|
; 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 <name of secondary ns>.
|
|
;
|
|
; ############################################################
|
|
; 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 <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>.</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->$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>
|