mirror of
https://gitlab.com/shorewall/code.git
synced 2024-12-17 20:01:09 +01:00
b37e367832
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1055 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2246 lines
93 KiB
XML
2246 lines
93 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
<article id="IPIP">
|
|
<!--$Id$-->
|
|
|
|
<articleinfo>
|
|
<title>Shorewall Setup Guide</title>
|
|
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Tom</firstname>
|
|
|
|
<surname>Eastep</surname>
|
|
</author>
|
|
</authorgroup>
|
|
|
|
<pubdate>2003-12-24</pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2003</year>
|
|
|
|
<holder>Thomas M. Eastep</holder>
|
|
</copyright>
|
|
|
|
<legalnotice>
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License, Version
|
|
1.2 or any later version published by the Free Software Foundation; with
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
|
|
</legalnotice>
|
|
</articleinfo>
|
|
|
|
<section 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>If you run LEAF Bering, your Shorewall configuration is NOT what I
|
|
release -- I suggest that you consider installing a stock Shorewall lrp
|
|
from the shorewall.net site before you proceed. 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]# which ip
|
|
/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>.</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 and some contain default entries.</para>
|
|
|
|
<para>Shorewall views the network where it is running as being composed of
|
|
a set of zones. In the default installation, the following zone names are
|
|
used:</para>
|
|
|
|
<table>
|
|
<title>Zones</title>
|
|
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry align="left"><emphasis role="bold">Name</emphasis></entry>
|
|
|
|
<entry align="left" role="underline"><emphasis role="bold">Description</emphasis></entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>net</entry>
|
|
|
|
<entry>The Internet</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>loc</entry>
|
|
|
|
<entry>Your Local Network</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>dmz</entry>
|
|
|
|
<entry>Demilitarized Zone</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>Zones are defined in the file <filename><ulink
|
|
url="Documentation.htm#Zones"><filename>/etc/shorewall/zones</filename></ulink></filename>.</para>
|
|
|
|
<para>Shorewall also recognizes the firewall system as its own zone - by
|
|
default, the firewall itself is known as <emphasis role="bold">fw</emphasis>
|
|
but that may be changed in the <ulink url="Documentation.htm#Config"><filename>/etc/shorewall/shorewall.conf</filename></ulink>
|
|
file. In this guide, the default name (<emphasis role="bold">fw</emphasis>)
|
|
will be used. With the exception of <emphasis role="bold">fw</emphasis>,
|
|
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="Documentation.htm#Policy">/etc/shorewall/policy</ulink></filename>
|
|
file.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>You define exceptions to those default policies in the
|
|
<filename><ulink url="Documentation.htm#Rules">/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 zone.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Identify destination 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>. 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. If that policy is REJECT or DROP the request is first
|
|
checked against the rules in <filename>/etc/shorewall/common.def</filename>.</para>
|
|
|
|
<para>The default <filename>/etc/shorewall/policy</filename> file has the
|
|
following policies:</para>
|
|
|
|
<programlisting>#SOURCE ZONE DESTINATION ZONE POLICY LOG LIMIT:BURST
|
|
# LEVEL
|
|
fw net ACCEPT
|
|
net all DROP info
|
|
all all REJECT info</programlisting>
|
|
|
|
<para>The above policy 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 (here is
|
|
a description of log levels).</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 simply associate the zone
|
|
name (previously defined in /etc/shorewall/zones) with a network
|
|
interface. This is done in the <ulink url="Documentation.htm#Interfaces">/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="Documentation.htm#Config">/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 AND you are running Shorewall version 1.4.7
|
|
or later. When using these recent versions, you can test using this kind
|
|
of configuration if you specify the <emphasis role="bold">arp_filter</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="Documentation.htm#Interfaces">/etc/shorewall/interfaces </ulink>file,
|
|
that file would might contain:</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
net eth0 detect rfc1918
|
|
loc eth1 detect
|
|
dmz eth2 detect</programlisting>
|
|
|
|
<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>
|
|
<title>Multiple Interfaces to a Zone</title>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
net eth0 detect rfc1918
|
|
loc eth1 detect
|
|
loc eth2 detect</programlisting>
|
|
</example>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /></para>
|
|
|
|
<para>You may define more complicated zones using the<filename> <ulink
|
|
url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink></filename> file
|
|
but in most cases, that isn't necessary.</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>Natural Logarithm</emphasis> (log2) of n. For the more common
|
|
subnet sizes, the size and its natural logarithm are given in the
|
|
following table:</para>
|
|
|
|
<table>
|
|
<title>Natural 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>
|
|
<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>
|
|
<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>
|
|
<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">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>
|
|
<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>Beginning with Shorewall 1.4.6, /sbin/shorewall supports an ipcalc
|
|
command that automatically calculates information about a [sub]network.</para>
|
|
|
|
<example>
|
|
<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>
|
|
<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 mis-conception 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>
|
|
<title id="ARP">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 it's 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 forego
|
|
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
|
|
non-routable 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.</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>
|
|
|
|
<note>
|
|
<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. These
|
|
addresses are not to be confused with addresses in 192.168.0.0/16; as
|
|
described above, these addresses are reserved by RFC 1918 for private
|
|
use.</emphasis></para>
|
|
</note>
|
|
</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>NAT_ENABLED=Yes (Shorewall versions earlier than 1.4.6)</para>
|
|
</listitem>
|
|
|
|
<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="Documentation.htm#Masq">/etc/shorewall/masq</ulink></filename>
|
|
file.</member>
|
|
</simplelist>
|
|
|
|
<programlisting>#INTERFACE SUBNET ADDRESS
|
|
eth0 192.168.201.0/29 192.0.2.176</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="Documentation.htm#Rules">/etc/shorewall/rules</ulink></filename>:</para>
|
|
|
|
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
|
|
# PORT(S) PORT(S) DEST
|
|
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 but Shorewall
|
|
will not add that address to the firewall's external interface for
|
|
you.</para>
|
|
</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>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When <emphasis role="bold">H</emphasis> <emphasis
|
|
role="bold">A </emphasis>andissues an ARP <quote>who has</quote>
|
|
request for an address in the subnetwork defined by <emphasis
|
|
role="bold">M</emphasis>, the firewall will respond (with the MAC
|
|
if the firewall interface) to <emphasis role="bold">H</emphasis>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<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 EXTERNAL INTERFACE HAVE ROUTE
|
|
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>
|
|
<title id="NAT">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 SUBNET ADDRESS
|
|
eth0 192.168.201.0/29 192.0.2.176</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 ALL INTERFACES 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 SOURCE ORIGINAL
|
|
# PORT(S) PORT(S) DEST
|
|
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>
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /></para>
|
|
|
|
<para>With the default policies, your local systems (Local 1-3) can
|
|
access any servers 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 SOURCE PORT(S) and ORIG. DEST. 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 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</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 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</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 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</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 DEST COMMENTS
|
|
# PORT(S)
|
|
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 it's 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="Documentation.htm#Config"><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>#ZONE INTERFACE BROADCAST OPTIONS
|
|
net eth0 detect rfc1918,routefilter
|
|
loc eth1 detect
|
|
dmz eth2 detect</programlisting>
|
|
|
|
<para>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 <quote>detect</quote>
|
|
with the actual broadcast addresses in the entries above, you can bring
|
|
up Shorewall before you bring up your network interfaces.</para>
|
|
|
|
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
|
|
net eth0 192.0.2.255 rfc1918
|
|
loc eth1 192.168.201.7
|
|
dmz eth2 192.168.202.7</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><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 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</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 it's 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; };
|
|
};
|
|
|
|
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; };
|
|
allow-transfer { <secondary NS IP>; };
|
|
file "ext/db.foobar";
|
|
};
|
|
|
|
zone "176.2.0.192.in-addr.arpa" in {
|
|
type master;
|
|
notify yes;
|
|
allow-update { none; };
|
|
allow-transfer { <secondary NS IP>; };
|
|
file "db.192.0.2.176";
|
|
};
|
|
|
|
zone "177.2.0.192.in-addr.arpa" in {
|
|
type master;
|
|
notify yes;
|
|
allow-update { none; };
|
|
allow-transfer { <secondary NS IP>; };
|
|
file "db.192.0.2.177";
|
|
};
|
|
|
|
zone "178.2.0.192.in-addr.arpa" in {
|
|
type master;
|
|
notify yes;
|
|
allow-update { none; };
|
|
allow-transfer { <secondary NS IP>; };
|
|
file "db.192.0.2.178";
|
|
};
|
|
|
|
zone "179.2.0.192.in-addr.arpa" in {
|
|
type master;
|
|
notify yes;
|
|
allow-update { none; };
|
|
allow-transfer { <secondary NS IP>; };
|
|
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 disbribution).</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>.
|
|
;
|
|
; ############################################################
|
|
; Iverse 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>.
|
|
;
|
|
; ############################################################
|
|
; Iverse 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>.
|
|
;
|
|
; ############################################################
|
|
; Iverse 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>.
|
|
;
|
|
; ############################################################
|
|
; Iverse 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.
|
|
|
|
; ############################################################
|
|
; Iverse 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.
|
|
; ############################################################
|
|
; Iverse 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.
|
|
|
|
; ############################################################
|
|
; Iverse 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
|
|
www 86400 IN A 192.0.2.177
|
|
|
|
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</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="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 entry in
|
|
<filename><ulink url="Documentation.htm#Routestopped">/etc/shorewall/routestopped</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="Documentation.htm#Routestopped">/etc/shorewall/routestopped</ulink></filename>
|
|
file and configure 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
|
|
entry for the IP address that you are connected from to
|
|
<filename><ulink url="Documentation.htm#Routestopped">/etc/shorewall/routestopped</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> |