2003-12-25 01:12:43 +01:00
|
|
|
<?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">
|
|
|
|
|
<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 "<ulink
|
|
|
|
|
url="GnuCopyright.htm">GNU Free Documentation License</ulink>".</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>
|
|
|
|
|
|
2003-12-25 17:40:17 +01:00
|
|
|
<para></para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<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 'which' 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
|
2003-12-25 17:40:17 +01:00
|
|
|
fileref="images/BD21298_.gif" />.</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
</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" /> The configuration
|
|
|
|
|
files for Shorewall are contained in the directory /etc/shorewall -- 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 <ulink url="Documentation.htm#Zones">/etc/shorewall/zones</ulink>.</para>
|
|
|
|
|
|
|
|
|
|
<para>Shorewall also recognizes the firewall system as its own zone - by
|
2003-12-25 17:40:17 +01:00
|
|
|
default, the firewall itself is known as <emphasis role="bold">fw</emphasis>
|
|
|
|
|
but that may be changed in the <ulink url="Documentation.htm#Config">/etc/shorewall/shorewall.conf</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 "because this is the internet zone" or
|
|
|
|
|
"because that is the DMZ".</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> 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 <ulink url="Documentation.htm#Policy">/etc/shorewall/policy</ulink>
|
|
|
|
|
file.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>You define exceptions to those default policies in the <ulink
|
|
|
|
|
url="Documentation.htm#Rules">/etc/shorewall/rules</ulink>.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
2003-12-25 17:40:17 +01:00
|
|
|
<para>Shorewall is built on top of the <ulink
|
2003-12-25 01:12:43 +01:00
|
|
|
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>
|
2003-12-25 17:40:17 +01:00
|
|
|
<para>If the POLICY from the client's zone to the server's
|
2003-12-25 01:12:43 +01:00
|
|
|
zone is what you want for this client/server pair, you need do nothing
|
|
|
|
|
further.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
2003-12-25 17:40:17 +01:00
|
|
|
<para>If the POLICY is not what you want, then you must add a rule.
|
2003-12-25 01:12:43 +01:00
|
|
|
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 /etc/shorewall/rules file. If no rule in that
|
|
|
|
|
file matches the connection request then the first policy in
|
|
|
|
|
/etc/shorewall/policy that matches the request is applied. If that policy
|
|
|
|
|
is REJECT or DROP the request is first checked against the rules in
|
|
|
|
|
/etc/shorewall/common.def.</para>
|
|
|
|
|
|
|
|
|
|
<para>The default /etc/shorewall/policy file has the following policies:</para>
|
|
|
|
|
|
|
|
|
|
<table>
|
|
|
|
|
<title>/etc/shorewall/policy</title>
|
|
|
|
|
|
|
|
|
|
<tgroup cols="5">
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><emphasis role="bold">SOURCE ZONE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">DESTINATION ZONE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">POLICY</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">LOG LEVEL</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">LIMIT:BURST</emphasis></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>all</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DROP</entry>
|
|
|
|
|
|
|
|
|
|
<entry>info</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>all</entry>
|
|
|
|
|
|
|
|
|
|
<entry>all</entry>
|
|
|
|
|
|
|
|
|
|
<entry>REJECT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>info</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<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" /> At this point, edit
|
|
|
|
|
your /etc/shorewall/policy 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 "Modem", the
|
|
|
|
|
<emphasis>External Interface</emphasis> will be the Ethernet adapter that
|
|
|
|
|
is connected to that "Modem" (e.g., <emphasis role="bold">eth0</emphasis>)
|
|
|
|
|
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., <emphasis role="bold">ppp0</emphasis>).
|
|
|
|
|
If you connect via a regular modem, your External Interface will also be
|
|
|
|
|
<emphasis role="bold">ppp0</emphasis>. If you connect using ISDN, you
|
|
|
|
|
external interface will be <emphasis role="bold">ippp0</emphasis>.</para>
|
|
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> If your external
|
|
|
|
|
interface is <emphasis role="bold">ppp0</emphasis> or <emphasis
|
|
|
|
|
role="bold">ippp0</emphasis> then you will want to set CLAMPMSS=yes in
|
|
|
|
|
<ulink url="Documentation.htm#Config">/etc/shorewall/shorewall.conf</ulink>.</para>
|
|
|
|
|
|
|
|
|
|
<para>Your <emphasis>Local Interface</emphasis> will be an Ethernet
|
|
|
|
|
adapter (<emphasis role="bold">eth0</emphasis>, <emphasis role="bold">eth1</emphasis>
|
|
|
|
|
or <emphasis role="bold">eth2</emphasis>) 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 (<emphasis role="bold">eth0</emphasis>, <emphasis role="bold">eth1</emphasis>
|
|
|
|
|
or <emphasis role="bold">eth2</emphasis>) 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 arp_filter option in
|
|
|
|
|
/etc/shorewall/interfaces 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 <emphasis role="bold">eth0</emphasis>.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>The Local Interface <emphasis role="bold">eth1</emphasis>.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>The DMZ Interface <emphasis role="bold">eth2</emphasis>.</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>
|
|
|
|
|
|
|
|
|
|
<table>
|
|
|
|
|
<title>/etc/shorewall/interfaces</title>
|
|
|
|
|
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><emphasis role="bold">ZONE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">INTERFACE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">BROADCAST</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">OPTIONS</emphasis></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry>rfc1918</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth1</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> Edit the
|
|
|
|
|
/etc/shorewall/interfaces 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>
|
|
|
|
|
|
|
|
|
|
<para>Example:</para>
|
|
|
|
|
|
|
|
|
|
<table>
|
|
|
|
|
<title>/etc/shorewall/interfaces</title>
|
|
|
|
|
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry><emphasis role="bold">ZONE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">INTERFACE</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">BROADCAST</emphasis></entry>
|
|
|
|
|
|
|
|
|
|
<entry><emphasis role="bold">OPTIONS</emphasis></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry>rfc1918</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth1</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dhcp</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> You may define more
|
|
|
|
|
complicated zones using the <ulink url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink>
|
|
|
|
|
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 "<emphasis>IP Fundamentals: What Everyone Needs to
|
|
|
|
|
Know about Addressing & Routing</emphasis>", 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
|
|
|
|
|
"w", the next byte has value "x", 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 "Class A network",
|
|
|
|
|
"Class B network" and "Class C network". 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 ("/") -- you
|
|
|
|
|
will often hear a subnet of size 64 referred to as a "slash 26"
|
|
|
|
|
subnet and one of size 8 referred to as a "slash 29".</para>
|
|
|
|
|
|
|
|
|
|
<para>The subnet's mask (also referred to as its
|
|
|
|
|
<emphasis>netmask</emphasis>) is simply a 32-bit number with the first
|
|
|
|
|
"VLSM" 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 "<emphasis role="bold">a.b.c.d/v</emphasis>"
|
|
|
|
|
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 'ip' 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>
|
|
|
|
|
|
|
|
|
|
<para>Example: 192.0.2.65/29<programlisting> The interface is configured with IP address 192.0.2.65 and netmask 255.255.255.248.
|
|
|
|
|
</programlisting>Beginning with Shorewall 1.4.6, /sbin/shorewall supports an
|
|
|
|
|
ipcalc command that automatically calculates information about a
|
|
|
|
|
[sub]network.</para>
|
|
|
|
|
|
|
|
|
|
<para>Example 1:<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 2:<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></para>
|
|
|
|
|
</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:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting> [root@gateway root]# netstat -nr
|
|
|
|
|
Kernel IP routing table
|
|
|
|
|
Destination Gateway Genmask Flags MSS Window 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 'netstat'
|
|
|
|
|
output this can be seen by the "Genmask" (Subnet Mask) of
|
|
|
|
|
255.255.255.255 and the "H" in the Flags column. The remainder
|
|
|
|
|
are <emphasis>'net' 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
|
|
|
|
|
'Genmask' value in the table entry.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>The result is compared with the 'Destination' value in
|
|
|
|
|
the table entry.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>If the result and the 'Destination' value are the
|
|
|
|
|
same, then:</para>
|
|
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>If the 'Gateway' column is non-zero, the packet is
|
|
|
|
|
sent to the gateway over the interface named in the
|
|
|
|
|
'Iface' column.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Otherwise, the packet is sent directly to <emphasis
|
|
|
|
|
role="bold">A</emphasis> over the interface named in the
|
|
|
|
|
'iface' column.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
</listitem>
|
|
|
|
|
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>Otherwise, the above steps are repeated on the next entry in
|
2003-12-25 17:40:17 +01:00
|
|
|
the table.</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
</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 'ip'
|
|
|
|
|
utility:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting> [root@gateway root]# ip addr show eth0
|
|
|
|
|
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
|
2003-12-25 17:40:17 +01:00
|
|
|
Protocol </emphasis>(ARP). Here is ARP in action:</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<programlisting> [root@gateway root]# tcpdump -nei eth2 arp
|
|
|
|
|
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 paquets received by filter
|
|
|
|
|
0 paquets 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 'arp' command:</para>
|
|
|
|
|
|
|
|
|
|
<programlisting> [root@gateway root]# arp -na
|
|
|
|
|
? (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
|
|
|
|
|
'n' option (Windows 'arp' doesn't allow that option)
|
|
|
|
|
which causes the 'arp' 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
|
2003-12-25 17:40:17 +01:00
|
|
|
of things to keep in mind:</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<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 "real"
|
|
|
|
|
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" /> 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
|
2003-12-25 17:40:17 +01:00
|
|
|
routing table on DMZ 1 will look like this:</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<programlisting> Kernel IP routing table
|
|
|
|
|
Destination Gateway Genmask Flags MSS Window irtt Iface
|
|
|
|
|
192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0
|
|
|
|
|
0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0</programlisting>
|
|
|
|
|
|
|
|
|
|
<para>This means that DMZ 1 will send an ARP "who-has
|
|
|
|
|
192.0.2.65" 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 "here-is" 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 "proxyarp" 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
|
2003-12-25 17:40:17 +01:00
|
|
|
problem.</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<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" /> 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" /> SNAT is
|
|
|
|
|
configured in Shorewall using the <ulink
|
|
|
|
|
url="Documentation.htm#Masq">/etc/shorewall/masq</ulink> file.</member>
|
|
|
|
|
</simplelist>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SUBNET</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ADDRESS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.0/29</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.0.2.176</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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" /> Suppose that
|
|
|
|
|
your daughter wants to run a web server on her system "Local
|
|
|
|
|
3". You could allow connections to the internet to her server by
|
|
|
|
|
adding the following entry in <ulink url="Documentation.htm#Rules">/etc/shorewall/rules</ulink>:</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="7">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ORIGINAL DEST</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>DNAT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc:192.168.201.4</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>www</entry>
|
|
|
|
|
|
|
|
|
|
<entry>-</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.0.2.176</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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 "who has" 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 "who has"
|
|
|
|
|
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" /> The Shorewall
|
|
|
|
|
configuration of Proxy ARP is done using the<ulink url="ProxyARP.htm">/etc/shorewall/proxyarp</ulink>
|
|
|
|
|
file.</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ADDRESS</entry>
|
|
|
|
|
|
|
|
|
|
<entry>EXTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>HAVE ROUTE</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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>"gratuitous" 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>"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."</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 "arping", whose "-U" flag does just that:</para>
|
|
|
|
|
|
|
|
|
|
<para><programlisting> arping -U -I <net if> <newly proxied IP>
|
|
|
|
|
arping -U -I eth0 66.58.99.83 # for example</programlisting>Stevens
|
|
|
|
|
goes on to mention that not all systems respond correctly to
|
|
|
|
|
gratuitous ARPs, but googling for "arping -U" 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> tcpdump -nei eth0 icmp</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> ping 192.0.2.254</programlisting></para>
|
|
|
|
|
|
|
|
|
|
<para>We can now observe the tcpdump output:</para>
|
|
|
|
|
|
|
|
|
|
<para><programlisting> 13:35:12.159321 <emphasis
|
|
|
|
|
role="underline">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="underline">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
|
|
|
|
|
/etc/shorewall/masq:</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SUBNET</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ADDRESS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.0/29</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.0.2.176</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> 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 <ulink url="NAT.htm">/etc/shorewall/nat</ulink>.</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="5">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>EXTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ALL INTERFACES</entry>
|
|
|
|
|
|
|
|
|
|
<entry>LOCAL</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.179</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.4</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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" /> 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>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="7">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ORIGINAL DEST</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc:192.168.201.4</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>www</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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>"gratuitous" 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>"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."</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 "arping", whose
|
|
|
|
|
"-U" flag does just that:</para>
|
|
|
|
|
|
|
|
|
|
<para><programlisting> arping -U -I <net if> <newly proxied IP>
|
|
|
|
|
arping -U -I eth0 66.58.99.83 # for example</programlisting>Stevens
|
|
|
|
|
goes on to mention that not all systems respond correctly to
|
|
|
|
|
gratuitous ARPs, but googling for "arping -U" 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> tcpdump -nei eth0 icmp</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> ping 192.0.2.254</programlisting></para>
|
|
|
|
|
|
|
|
|
|
<para>We can now observe the tcpdump output:</para>
|
|
|
|
|
|
|
|
|
|
<para><programlisting> 13:35:12.159321 <emphasis
|
|
|
|
|
role="underline">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="underline">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" /> 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 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>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="5">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="6">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>COMMENTS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>pop3</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Pop3 from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>pop3</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Pop3 from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mails to Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>http</entry>
|
|
|
|
|
|
|
|
|
|
<entry># WWW from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>https</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Secure HTTP from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>htp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>https</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Secure HTTP from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para>If you run a public DNS server on 192.0.2.177, you would need to
|
|
|
|
|
add the following rules:</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="6">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>COMMENTS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS from the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS from the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS to the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS to the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="6">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>COMMENTS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ssh</entry>
|
|
|
|
|
|
|
|
|
|
<entry># SSH to the DMZ</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ssh</entry>
|
|
|
|
|
|
|
|
|
|
<entry># SSH to the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
</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" /> If you haven't
|
|
|
|
|
already, it would be a good idea to browse through <ulink
|
|
|
|
|
url="Documentation.htm#Config">/etc/shorewall/shorewall.conf</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>/etc/shorewall/interfaces (The "options" will be very
|
2003-12-25 17:40:17 +01:00
|
|
|
site-specific).</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ZONE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>BROADCAST</entry>
|
|
|
|
|
|
|
|
|
|
<entry>OPTIONS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry>norfc1918,routefilter</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth1</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>detect</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<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 'detect'
|
|
|
|
|
with the actual broadcast addresses in the entries above, you can bring
|
|
|
|
|
up Shorewall before you bring up your network interfaces.</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ZONE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>BROADCAST</entry>
|
|
|
|
|
|
|
|
|
|
<entry>OPTIONS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.0.2.255</entry>
|
|
|
|
|
|
|
|
|
|
<entry>norfc1918,routefilter</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth1</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.7</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.202.7</entry>
|
|
|
|
|
|
|
|
|
|
<entry></entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para>/etc/shorewall/masq - Local Subnet</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="3">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SUBNET</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ADDRESS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.0/29</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.0.2.176</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para>/etc/shorewall/proxyarp - DMZ</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="4">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ADDRESS</entry>
|
|
|
|
|
|
|
|
|
|
<entry>EXTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>HAVE ROUTE</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth2</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para>/etc/shorewall/nat- Daughter's System</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="5">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>EXTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERFACE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>INTERNAL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ALL INTERFACES</entry>
|
|
|
|
|
|
|
|
|
|
<entry>LOCAL</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>192.0.2.179</entry>
|
|
|
|
|
|
|
|
|
|
<entry>eth0</entry>
|
|
|
|
|
|
|
|
|
|
<entry>192.168.201.4</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
|
|
|
|
|
<entry>No</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
|
|
|
|
|
<para>/etc/shorewall/rules</para>
|
|
|
|
|
|
|
|
|
|
<informaltable>
|
|
|
|
|
<tgroup cols="6">
|
|
|
|
|
<thead>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACTION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>SOURCE</entry>
|
|
|
|
|
|
|
|
|
|
<entry>DESTINATION</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PROTOCOL</entry>
|
|
|
|
|
|
|
|
|
|
<entry>PORT(S)</entry>
|
|
|
|
|
|
|
|
|
|
<entry>COMMENTS</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</thead>
|
|
|
|
|
|
|
|
|
|
<tbody>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>pop3</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Pop3 from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>pop3</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Pop3 from the Local network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mail from the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.178</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>smtp</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Mails to Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>http</entry>
|
|
|
|
|
|
|
|
|
|
<entry># WWW from the Net</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>https</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Secure HTTP from the Net</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>htp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>https</entry>
|
|
|
|
|
|
|
|
|
|
<entry># Secure HTTP from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS from the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS from the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS depuis le firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS depuis le Réseau Local</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS from the Local Network</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>udp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># UDP DNS to the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz:192.0.2.177</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>domain</entry>
|
|
|
|
|
|
|
|
|
|
<entry># TCP DNS to the Internet</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
|
|
|
|
|
<entry>Ping</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>net</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
|
|
|
|
|
<entry>"</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
|
|
|
|
|
<entry>"</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>icmp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>echo-request</entry>
|
|
|
|
|
|
|
|
|
|
<entry>"</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>dmz</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ssh</entry>
|
|
|
|
|
|
|
|
|
|
<entry># SSH to the DMZ</entry>
|
|
|
|
|
</row>
|
|
|
|
|
|
|
|
|
|
<row>
|
|
|
|
|
<entry>ACCEPT</entry>
|
|
|
|
|
|
|
|
|
|
<entry>loc</entry>
|
|
|
|
|
|
|
|
|
|
<entry>fw</entry>
|
|
|
|
|
|
|
|
|
|
<entry>tcp</entry>
|
|
|
|
|
|
|
|
|
|
<entry>ssh</entry>
|
|
|
|
|
|
|
|
|
|
<entry># SSH to the firewall</entry>
|
|
|
|
|
</row>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</informaltable>
|
|
|
|
|
</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>
|
|
|
|
|
|
2003-12-25 17:40:17 +01:00
|
|
|
<para>The /etc/named.conf file would look like this:</para>
|
2003-12-25 01:12:43 +01:00
|
|
|
|
|
|
|
|
<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 /var/named (those not shown are usually
|
|
|
|
|
included in your bind disbribution).</para>
|
|
|
|
|
|
|
|
|
|
<para>db.192.0.2.176 - 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>db.192.0.2.177 - Reverse zone www/DNS 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>db.192.0.2.178 - 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.<optional></optional></programlisting>
|
|
|
|
|
|
|
|
|
|
<para>db.192.0.2.179 - 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>int/db.127.0.0 - 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>int/db.192.168.201 - 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>int/db.192.168.202 - 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>int/db.foobar - 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>ext/db.foobar - 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 "shorewall start" command
|
|
|
|
|
and stopped using "shorewall stop". When the firewall is stopped,
|
|
|
|
|
routing is enabled on those hosts that have an entry in <ulink
|
|
|
|
|
url="Documentation.htm#Routestopped">/etc/shorewall/routestopped</ulink>.
|
|
|
|
|
A running firewall may be restarted using the "shorewall restart"
|
|
|
|
|
command. If you want to totally remove any trace of Shorewall from your
|
|
|
|
|
Netfilter configuration, use "shorewall clear".</para>
|
|
|
|
|
|
|
|
|
|
<para><inlinegraphic fileref="images/BD21298_.gif" /> Edit the <ulink
|
|
|
|
|
url="Documentation.htm#Routestopped">/etc/shorewall/routestopped</ulink>
|
|
|
|
|
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 "shorewall stop" command unless you have added an entry
|
|
|
|
|
for the IP address that you are connected from to <ulink
|
|
|
|
|
url="Documentation.htm#Routestopped">/etc/shorewall/routestopped</ulink>.
|
|
|
|
|
Also, I don't recommend using "shorewall restart"; it is
|
|
|
|
|
better to create an <ulink url="starting_and_stopping_shorewall.htm"><emphasis>an
|
|
|
|
|
alternate configuration</emphasis></ulink>  and test it using the
|
|
|
|
|
"<ulink url="starting_and_stopping_shorewall.htm">shorewall try</ulink>"
|
|
|
|
|
command.</para>
|
|
|
|
|
</caution>
|
|
|
|
|
</section>
|
|
|
|
|
</article>
|
