extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-22 07:33:43 +01:00
Code Issues Packages Projects Releases Wiki Activity

Shorewall 2.0.0+

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1196 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-03-17 15:03:46 +00:00
parent 1a3c0cef13
commit 4f45eeff82
33 changed files with 164482 additions and 5094 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

928
Shorewall-docs2/Documentation.html
View File

@ -1,928 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall 2.0 Reference</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><meta name="description" content="This documentation is intended primarily for reference.&#10; Step-by-step instructions for configuring Shorewall in common setups may&#10; be found in the QuickStart&#10; Guides." /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="Documentation"></a>Shorewall 2.0 Reference</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-03</p></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>This documentation is intended primarily for reference.
Step-by-step instructions for configuring Shorewall in common setups may
be found in the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart
Guides</a>.</p></div></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807627">Components</a></span></dt><dt><span class="section"><a href="#Variables">/etc/shorewall/params</a></span></dt><dt><span class="section"><a href="#Zones">/etc/shorewall/zones</a></span></dt><dt><span class="section"><a href="#Interfaces">/etc/shorewall/interfaces</a></span></dt><dt><span class="section"><a href="#Hosts">/etc/shorewall/hosts Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#Nested">Nested and Overlapping Zones</a></span></dt></dl></dd><dt><span class="section"><a href="#Policy">/etc/shorewall/policy Configuration</a></span></dt><dd><dl><dt><span class="section"><a href="#id2866348">Intra-Zone Traffic</a></span></dt><dt><span class="section"><a href="#CONTINUE">The CONTINUE policy</a></span></dt></dl></dd><dt><span class="section"><a href="#Rules">/etc/shorewall/rules</a></span></dt><dt><span class="section"><a href="#Masq">/etc/shorewall/masq</a></span></dt><dt><span class="section"><a href="#ProxyArp">/etc/shorewall/proxyarp</a></span></dt><dt><span class="section"><a href="#NAT">/etc/shorewall/nat</a></span></dt><dt><span class="section"><a href="#Tunnels">/etc/shorewall/tunnels</a></span></dt><dt><span class="section"><a href="#Conf">/etc/shorewall/shorewall.conf</a></span></dt><dt><span class="section"><a href="#modules">/etc/shorewall/modules Configuration</a></span></dt><dt><span class="section"><a href="#TOS">/etc/shorewall/tos Configuration</a></span></dt><dt><span class="section"><a href="#Blacklist">/etc/shorewall/blacklist</a></span></dt><dt><span class="section"><a href="#rfc1918">/etc/shorewall/rfc1918 (Added in Version 1.3.1)</a></span></dt><dt><span class="section"><a href="#Routestopped">/etc/shorewall/routestopped (Added in Version 1.3.4)</a></span></dt><dt><span class="section"><a href="#Maclist">/etc/shorewall/maclist (Added in Version 1.3.10)</a></span></dt><dt><span class="section"><a href="#ECN">/etc/shorewall/ecn (Added in Version 1.4.0)</a></span></dt><dt><span class="section"><a href="#Accounting">/etc/shorewall/accounting</a></span></dt><dt><span class="appendix"><a href="#id2875179">A. Revision History</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807627"></a>Components</h2></div></div><div></div></div><p>Shorewall consists of the following components:</p><div class="variablelist"><dl><dt><span class="term"><a href="#Variables" title="/etc/shorewall/params">params</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
that can be used to establish the values of shell variables for use
in other files.</p></dd><dt><span class="term"><a href="#Conf" title="/etc/shorewall/shorewall.conf">shorewall.conf</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
that is used to set several firewall parameters.</p></dd><dt><span class="term"><a href="#Zones" title="/etc/shorewall/zones">zones</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
that defines a network partitioning into “<span class="quote">zones</span>”</p></dd><dt><span class="term"><a href="#Policy" title="/etc/shorewall/policy Configuration">policy</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
that establishes overall firewall policy.</p></dd><dt><span class="term"><a href="#Rules" title="/etc/shorewall/rules">rules</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to express firewall rules that are exceptions to the
high-level policies established in /etc/shorewall/policy.</p></dd><dt><span class="term"><a href="#Blacklist" title="/etc/shorewall/blacklist">blacklist</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to list blacklisted IP/subnet/MAC addresses.</p></dd><dt><span class="term"><a href="#ECN" title="/etc/shorewall/ecn (Added in Version 1.4.0)">ecn</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to selectively disable Explicit Congestion Notification
(ECN - RFC 3168).</p></dd><dt><span class="term">functions</span></dt><dd><p>a set of shell functions used by both the firewall and
shorewall shell programs. Installed in <tt class="filename">/usr/share/shorewall</tt>.</p></dd><dt><span class="term"><a href="#modules" title="/etc/shorewall/modules Configuration">modules</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and that specifies kernel modules and their parameters. Shorewall
will automatically load the modules specified in this file.</p></dd><dt><span class="term"><a href="#TOS" title="/etc/shorewall/tos Configuration">tos</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
that is used to specify how the Type of Service (TOS) field in
packets is to be set.</p></dd><dt><span class="term">init.sh and init.debian.sh</span></dt><dd><p>a shell script installed in <tt class="filename">/etc/init.d
</tt>to automatically start Shorewall during boot. The
particular script installed depends on which distribution you are
running.</p></dd><dt><span class="term"><a href="#Interfaces" title="/etc/shorewall/interfaces">interfaces</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to describe the interfaces on the firewall system.</p></dd><dt><span class="term"><a href="#Hosts" title="/etc/shorewall/hosts Configuration">hosts</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to describe individual hosts or subnetworks in zones.</p></dd><dt><span class="term"><a href="#Maclist" title="/etc/shorewall/maclist (Added in Version 1.3.10)">maclist</a></span></dt><dd><p>a parameter file installed in <tt class="filename">/etc/shorewall</tt>
and used to verify the MAC address (and possibly also the IP
address(es)) of devices.</p></dd><dt><span class="term"><a href="#Masq" title="/etc/shorewall/masq">masq</a></span></dt><dd><p>This file also describes IP masquerading under Shorewall and
is installed in <tt class="filename">/etc/shorewall</tt>.</p></dd><dt><span class="term">firewall</span></dt><dd><p>a shell program that reads the configuration files in
<tt class="filename">/etc/shorewall</tt> and configures
your firewall. This file is installed in <tt class="filename">/usr/share/shorewall</tt>.</p></dd><dt><span class="term"><a href="#NAT" title="/etc/shorewall/nat">nat</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define <a href="#NAT" title="/etc/shorewall/nat">one-to-one NAT</a>.</p></dd><dt><span class="term"><a href="#ProxyArp" title="/etc/shorewall/proxyarp">proxyarp</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define <a href="#ProxyArp" title="/etc/shorewall/proxyarp">Proxy Arp</a>.</p></dd><dt><span class="term"><a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">rfc1918</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define the treatment of packets under the <a href="#Interfaces" title="/etc/shorewall/interfaces">norfc1918 interface option</a>.</p></dd><dt><span class="term"><a href="#Routestopped" title="/etc/shorewall/routestopped (Added in Version 1.3.4)">routestopped</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define those hosts that can access the firewall when
Shorewall is stopped.</p></dd><dt><span class="term"><a href="traffic_shaping.htm#tcrules" target="_self">tcrules</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall
</tt>used to define rules for classifying packets for <a href="traffic_shaping.htm" target="_self">Traffic Shaping/Control</a>.</p></dd><dt><span class="term"><a href="#Tunnels" title="/etc/shorewall/tunnels">tunnels</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define IPSec tunnels.</p></dd><dt><span class="term">shorewall</span></dt><dd><p>a shell program (requiring a Bourne shell or derivative) used
to control and monitor the firewall. This should be placed in
<tt class="filename">/sbin</tt> or in <tt class="filename">/usr/sbin</tt> (the install.sh script and
the rpm install this file in <tt class="filename">/sbin</tt>).</p></dd><dt><span class="term"><a href="Accounting.html" target="_self">accounting</a></span></dt><dd><p>a parameter file in <tt class="filename">/etc/shorewall</tt>
used to define traffic accounting rules. This file was added in
version 1.4.7.</p></dd><dt><span class="term">version</span></dt><dd><p>a file created in <tt class="filename">/usr/share/shorewall</tt>
that describes the version of Shorewall installed on your system.</p></dd><dt><span class="term"><a href="User_defined_Actions.html" target="_self">actions and
action.template</a></span></dt><dd><p>files in /etc/shorewall that allow you to define your own
actions for rules in <a href="#Rules" title="/etc/shorewall/rules">/etc/shorewall/rules</a>.</p></dd><dt><span class="term">actions.std and action.*</span></dt><dd><p>files in <tt class="filename">/etc/shorewall</tt>
that define the actions included as a standard part of Shorewall.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Variables"></a>/etc/shorewall/params</h2></div></div><div></div></div><p>You may use the file <tt class="filename">/etc/shorewall/params</tt> file
to set shell variables that you can then use in some of the other
configuration files.</p><p>It is suggested that variable names begin with an upper case letter
to distinguish them from variables used internally within the Shorewall
programs</p><div class="example"><a id="id2859972"></a><p class="title"><b>Example 1. shell variables</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">NET_IF=eth0 NET_BCAST=130.252.100.255
NET_OPTIONS=blacklist,norfc1918</pre></td></tr></table></div><div class="example"><a id="id2859990"></a><p class="title"><b>Example 2. /etc/shorewall/interfaces record</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net $NET_IF $NET_BCAST $NET_OPTIONS</pre></td></tr></table></div><p>The result will be the same as if the record had been written</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net eth0 130.252.100.255 blacklist,norfc1918</pre></td></tr></table><p>Variables may be used anywhere in the other configuration files.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Zones"></a>/etc/shorewall/zones</h2></div></div><div></div></div><p>This file is used to define the network zones. There is one entry in
<tt class="filename">/etc/shorewall/zones</tt> for each zone; Columns in an
entry are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>short name for the zone. The name should be 5 characters or
less in length (4 characters or less if you are running Shorewall
1.4.4 or later) and consist of lower-case letters or numbers. Short
names must begin with a letter and the name assigned to the firewall
is reserved for use by Shorewall itself. Note that the output
produced by iptables is much easier to read if you select short
names that are three characters or less in length. The name
“<span class="quote">all</span>” may not be used as a zone name nor may the zone
name assigned to the firewall itself via the FW variable in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</p></dd><dt><span class="term">DISPLAY</span></dt><dd><p>The name of the zone as displayed during Shorewall startup.</p></dd><dt><span class="term">COMMENTS</span></dt><dd><p>Any comments that you want to make about the zone. Shorewall
ignores these comments.</p></dd></dl></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
dmz DMZ Demilitarized zone</pre></td></tr></table><p>You may add, delete and modify entries in the <tt class="filename">/etc/shorewall/zones</tt>
file as desired so long as you have at least one zone defined.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you rename or delete a zone, you should perform “<span class="quote"><span><b class="command">shorewall
stop; shorewall start</b></span></span>” to install the change rather
than “<span class="quote"><span><b class="command">shorewall restart</b></span></span>”.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The order of entries in the <tt class="filename">/etc/shorewall/zones</tt>
file is significant <a href="#Nested" title="Nested and Overlapping Zones">in some cases</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Interfaces"></a>/etc/shorewall/interfaces</h2></div></div><div></div></div><p>This file is used to tell the firewall which of your firewall's
network interfaces are connected to which zone. There will be one entry in
/etc/shorewall/interfaces for each of your interfaces. Columns in an entry
are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>A zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file or
“<span class="quote">-</span>”. If you specify “<span class="quote">-</span>”, you must use the
<a href="#Hosts">/etc/shorewall/hosts</a> file to define the zones accessed via this
interface.</p></dd><dt><span class="term">INTERFACE</span></dt><dd><p>the name of the interface (examples: eth0, ppp0, ipsec+). Each
interface can be listed on only one record in this file.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>You do not need to include the loopback interface (lo) in
this file.</p></div></dd><dt><span class="term">BROADCAST</span></dt><dd><p>the broadcast address(es) for the sub-network(s) attached to
the interface. This should be left empty for P-T-P interfaces (ppp*,
ippp*); if you need to specify options for such an interface, enter
“<span class="quote">-</span>” in this column. If you supply the special value
“<span class="quote">detect</span>” in this column, the firewall will
automatically determine the broadcast address. In order to use
“<span class="quote">detect</span>”:</p><div class="itemizedlist"><ul type="disc"><li><p>the interface must be up before you start your firewall</p></li><li><p>the interface must only be attached to a single
sub-network (i.e., there must have a single broadcast address).</p></li></ul></div></dd><dt><span class="term">OPTIONS</span></dt><dd><p>a comma-separated list of options. Possible options include:</p><div class="variablelist"><dl><dt><span class="term">arp_filter</span></dt><dd><p>(Added in version 1.4.7) - This option causes
<tt class="filename">/proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter</tt>
to be set with the result that this interface will only answer
ARP “<span class="quote">who-has</span>” requests from hosts that are routed
out of that interface. Setting this option facilitates testing
of your firewall where multiple firewall interfaces are
connected to the same HUB/Switch (all interface connected to
the single HUB/Switch should have this option specified). Note
that using such a configuration in a production environment is
strongly recommended against.</p></dd><dt><span class="term">newnotsyn</span></dt><dd><p>(Added in version 1.4.6) - This option overrides <a href="#Conf" title="/etc/shorewall/shorewall.conf">NEWNOTSYN=No</a> for packets arriving on
this interface. In other words, packets coming in on this
interface are processed as if NEWNOTSYN=Yes had been specified
in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</p></dd><dt><span class="term">routeback</span></dt><dd><p>(Added in version 1.4.2) - This option causes Shorewall
to set up handling for routing packets that arrive on this
interface back out the same interface. If this option is
specified, the ZONE column may not contain “<span class="quote">-</span>”.</p></dd><dt><span class="term">tcpflags</span></dt><dd><p>(added in version 1.3.11) - This option causes Shorewall
to make sanity checks on the header flags in TCP packets
arriving on this interface. Checks include Null flags,
SYN+FIN, SYN+RST and FIN+URG+PSH; these flag combinations are
typically used for “<span class="quote">silent</span>” port scans. Packets
failing these checks are logged according to the
TCP_FLAGS_LOG_LEVEL option in <a href="#Conf">/etc/shorewall/shorewall.conf</a> and are
disposed of according to the TCP_FLAGS_DISPOSITION option.</p></dd><dt><span class="term">blacklist</span></dt><dd><p>This option causes incoming packets on this interface to
be checked against the <a href="#Blacklist" title="/etc/shorewall/blacklist">blacklist</a>.</p></dd><dt><span class="term">dhcp</span></dt><dd><p>The interface is assigned an IP address via DHCP or is
used by a DHCP server running on the firewall. The firewall
will be configured to allow DHCP traffic to and from the
interface even when the firewall is stopped. You may also wish
to use this option if you have a static IP but you are on a
LAN segment that has a lot of Laptops that use DHCP and you
select the <span class="bold"><b>norfc1918</b></span> option
(see below).</p></dd><dt><span class="term">norfc1918</span></dt><dd><p>Packets arriving on this interface and that have a
source address that is reserved in RFC 1918 or in other RFCs
will be dropped after being optionally logged. If <a href="#Conf" title="/etc/shorewall/shorewall.conf">packet mangling is enabled in
<tt class="filename">/etc/shorewall/shorewall.conf</tt></a> ,
then packets arriving on this interface that have a
destination address that is reserved by one of these RFCs will
also be logged and dropped.</p><p>Addresses blocked by the standard <a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">rfc1918 file</a> include those addresses
reserved by RFC1918 plus other ranges reserved by the IANA or
by other RFCs.</p><p>Beware that as IPv4 addresses become in increasingly
short supply, ISPs are beginning to use RFC 1918 addresses
within their own infrastructure. Also, many cable and DSL
“<span class="quote">modems</span>” have an RFC 1918 address that can be
used through a web browser for management and monitoring
functions. If you want to specify <span class="bold"><b>norfc1918</b></span>
on your external interface but need to allow access to certain
addresses from the above list, see <a href="FAQ.htm#faq14" target="_self">FAQ
14</a>.</p></dd><dt><span class="term">routefilter</span></dt><dd><p>Invoke the Kernel's route filtering (anti-spoofing)
facility on this interface. The kernel will reject any packets
incoming on this interface that have a source address that
would be routed outbound through another interface on the
firewall.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you specify this option for an interface then the
interface must be up prior to starting the firewall.</p></div></dd><dt><span class="term">proxyarp</span></dt><dd><p>(Added in version 1.3.5) - This option causes Shorewall
to set /proc/sys/net/ipv4/conf/&lt;<span class="emphasis"><em>interface</em></span>&gt;/proxy_arp
and is used when implementing Proxy ARP Sub-netting as
described at <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>.
Do <span class="bold"><b>not</b></span> set this option if you
are implementing Proxy ARP through entries in <a href="#ProxyArp">/etc/shorewall/proxyarp</a>.</p></dd><dt><span class="term">maclist</span></dt><dd><p>(Added in version 1.3.10) - If this option is specified,
all connection requests from this interface are subject to
<a href="MAC_Validation.html" target="_self">MAC Verification</a>. May
only be specified for ethernet interfaces.</p></dd></dl></div><div class="variablelist"><dl><dt><span class="term">detectnets</span></dt><dd><p>(Added in version 1.4.10) - If this option is specified,
the zone named in the ZONE column will contain only the hosts
routed through the interface named in the INTERFACE column.
<span class="bold"><b>Do not set this option on your external
(Internet) interface!</b></span> The interface must be in the
UP state when Shorewall is [re]started.</p></dd><dt><span class="term">nosmurfs</span></dt><dd><p>(Added in version 2.0.0) - If this option is specified,
incoming connection requests will be checked to ensure that
they do not have a broadcast or multicast address as their
source. Any such packets will be dropped after being
optionally logged according to the setting of SMURF_LOG_LEVEL
in <a href="#Conf" title="/etc/shorewall/shorewall.conf">/etc/shorewall/shorewall.conf</a>.</p></dd></dl></div><p>My recommendations concerning options:</p><div class="itemizedlist"><ul type="disc"><li><p>External Interface -- <span class="bold"><b>tcpflags,blacklist,norfc1918,routefilter,nosmurfs</b></span></p></li><li><p>Wireless Interface -- <span class="bold"><b>maclist,routefilter,tcpflags,detectnets,nosmurfs</b></span></p></li><li><p>Use <span class="bold"><b>dhcp</b></span> and <span class="bold"><b>proxyarp</b></span> when needed.</p></li></ul></div></dd></dl></div><div class="example"><a id="id2865298"></a><p class="title"><b>Example 3. You have a conventional firewall setup in which eth0 connects to
a Cable or DSL modem and eth1 connects to your local network and eth0
gets its IP address via DHCP. You want to check all packets entering
from the internet against the <a href="#Blacklist" title="/etc/shorewall/blacklist">black list</a>.
Your /etc/shorewall/interfaces file would be as follows:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,norfc1918,blacklist</pre></td></tr></table></div><div class="example"><a id="id2865327"></a><p class="title"><b>Example 4. You have a standalone dialup GNU/Linux System. Your
/etc/shorewall/interfaces file would be:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net ppp0</pre></td></tr></table></div><div class="example"><a id="id2865345"></a><p class="title"><b>Example 5. You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 192.168.1.255,192.168.12.255</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Hosts"></a>/etc/shorewall/hosts Configuration</h2></div></div><div></div></div><p>For most applications, specifying zones entirely in terms of network
interfaces is sufficient. There may be times though where you need to
define a zone to be a more general collection of hosts. This is the
purpose of the <tt class="filename">/etc/shorewall/hosts</tt> file.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The only times that you need entries in <tt class="filename">/etc/shorewall/hosts</tt>
are:</p><div class="orderedlist"><ol type="1"><li><p>You have <a href="Multiple_Zones.html" target="_self">more than one zone
connecting through a single interface</a>; or</p></li><li><p>You have a <a href="Shorewall_and_Aliased_Interfaces.html" target="_self">zone
that has multiple subnetworks that connect through a single
interface</a> and you want the Shorewall box to route traffic
between those subnetworks.</p></li></ol></div><p><span class="bold"><b>IF YOU DON'T HAVE EITHER OF THOSE
SITUATIONS THEN DON'T TOUCH THIS FILE!!</b></span></p></div><p>Columns in this file are:</p><div class="variablelist"><dl><dt><span class="term">ZONE</span></dt><dd><p>A zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file.</p></dd><dt><span class="term">HOST(S)</span></dt><dd><p>The name of a network interface followed by a colon (“<span class="quote">:</span>”)
followed by a comma-separated list either:</p><div class="orderedlist"><ol type="1"><li><p>An IP address (example - eth1:192.168.1.3)</p></li><li><p>A subnet in CIDR notation (example - eth2:192.168.2.0/24)</p></li></ol></div><p>The interface name much match an entry in
<tt class="filename">/etc/shorewall/interfaces</tt>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you are running a version of Shorewall earlier than
1.4.6, only a single host/subnet address may be specified in an
entry in <tt class="filename">/etc/shorewall/hosts</tt>.</p></div></dd><dt><span class="term">OPTIONS</span></dt><dd><p>A comma-separated list of option</p><div class="variablelist"><dl><dt><span class="term">routeback</span></dt><dd><p>(Added in version 1.4.2) - This option causes Shorewall
to set up handling for routing packets sent by this host group
back back to the same group.</p></dd><dt><span class="term">maclist</span></dt><dd><p>Added in version 1.3.10. If specified, connection
requests from the hosts specified in this entry are subject to
<a href="MAC_Validation.html" target="_self">MAC Verification</a>.
This option is only valid for ethernet interfaces.</p></dd></dl></div></dd></dl></div><p>If you don't define any hosts for a zone, the hosts in the zone
default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the
interfaces to the zone.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>You probably DON'T want to specify any hosts for your internet
zone since the hosts that you specify will be the only ones that you
will be able to access without adding additional rules.</p></div><div class="example"><a id="id2865682"></a><p class="title"><b>Example 6. Your local interface is eth1 and you have two groups of local
hosts that you want to make into separate zones:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">192.168.1.0/25 192.168.1.128/25</pre></td></tr></table><p>Your /etc/shorewall/interfaces file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,norfc1918
- eth1 192.168.1.127,192.168.1.255</pre></td></tr></table><p>The “<span class="quote">-</span>” in the ZONE column for eth1 tells Shorewall
that eth1 interfaces to multiple zones.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
loc1 eth1:192.168.1.0/25
loc2 eth1:192.168.1.128/25</pre></td></tr></table></div><div class="example"><a id="id2865731"></a><p class="title"><b>Example 7. You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</b></p><p>Your /etc/shorewall/interfaces file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,norfc1918
- eth1 192.168.1.255,192.168.12.255</pre></td></tr></table><p>Your /etc/shorewall/hosts file might look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
loc eth1:192.168.1.0/24
loc eth1:192.168.12.0/24</pre></td></tr></table><p>If you are running Shorewall 1.4.6 or later, your hosts file may
look like:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
loc eth1:192.168.1.0/24,192.168.12.0/24</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Nested"></a>Nested and Overlapping Zones</h3></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/interfaces</tt> and
<tt class="filename">/etc/shorewall/hosts</tt> file allow you to define
nested or overlapping zones. Such overlapping/nested zones are allowed
and Shorewall processes zones in the order that they appear in the
<tt class="filename">/etc/shorewall/zones</tt> file. So if you have nested
zones, you want the sub-zone to appear before the super-zone and in the
case of overlapping zones, the rules that will apply to hosts that
belong to both zones is determined by which zone appears first in
<tt class="filename">/etc/shorewall/zones</tt>.</p><p>Hosts that belong to more than one zone may be managed by the
rules of all of those zones. This is done through use of the special
<a href="#CONTINUE" title="The CONTINUE policy">CONTINUE policy</a> described below.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Policy"></a>/etc/shorewall/policy Configuration</h2></div></div><div></div></div><p>This file is used to describe the firewall policy regarding
establishment of connections. Connection establishment is described in
terms of <span class="emphasis"><em>clients</em></span> who initiate connections and
<span class="emphasis"><em>servers</em></span> who receive those connection requests.
Policies defined in <tt class="filename">/etc/shorewall/policy </tt>describe
which zones are allowed to establish connections with other zones.</p><p>Policies established in <tt class="filename">/etc/shorewall/policy </tt>can
be viewed as default policies. If no rule in /etc/shorewall/rules applies
to a particular connection request then the policy from
<tt class="filename">/etc/shorewall/policy</tt> is applied.</p><p>Five policies are defined:</p><div class="variablelist"><dl><dt><span class="term">ACCEPT</span></dt><dd><p>The connection is allowed.</p></dd><dt><span class="term">DROP</span></dt><dd><p>The connection request is ignored.</p></dd><dt><span class="term">REJECT</span></dt><dd><p>The connection request is rejected with an RST (TCP) or an
ICMP destination-unreachable packet being returned to the client.</p></dd><dt><span class="term">CONTINUE</span></dt><dd><p>The connection is neither ACCEPTed, DROPped nor REJECTed.
CONTINUE may be used when one or both of the zones named in the
entry are sub-zones of or intersect with another zone. For more
information, see below.</p></dd><dt><span class="term">NONE</span></dt><dd><p>(Added in version 1.4.1) - Shorewall should not set up any
infrastructure for handling traffic from the SOURCE zone to the DEST
zone. When this policy is specified, the <span class="bold"><b>LOG
LEVEL</b></span> and <span class="bold"><b>BURST:LIMIT</b></span>
columns must be left blank.</p></dd></dl></div><p>For each policy specified in /etc/shorewall/policy, you can indicate
that you want a message sent to your system log each time that the policy
is applied.</p><p>Entries in /etc/shorewall/policy have four columns as follows:</p><div class="variablelist"><dl><dt><span class="term">SOURCE</span></dt><dd><p>The name of a client zone (a zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file , the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the
firewall zone</a> or “<span class="quote">all</span>”).</p></dd><dt><span class="term">DEST</span></dt><dd><p>The name of a destination zone (a zone defined in the <a href="#Zones">/etc/shorewall/zones</a> file , the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the
firewall zone</a> or “<span class="quote">all</span>”). Shorewall automatically
allows all traffic from the firewall to itself so the <a href="#Conf" title="/etc/shorewall/shorewall.conf">name of the firewall zone</a> cannot appear in
both the SOURCE and DEST columns.</p></dd><dt><span class="term">POLICY</span></dt><dd><p>The default policy for connection requests from the SOURCE
zone to the DESTINATION zone.</p></dd><dt><span class="term">LOG LEVEL</span></dt><dd><p>Optional. If left empty, no log message is generated when the
policy is applied. Otherwise, this column should contain an integer
or name indicating a <a href="shorewall_logging.html" target="_self">syslog
level</a>.</p></dd><dt><span class="term">LIMIT:BURST - optional</span></dt><dd><p>If left empty, TCP connection requests from the <span class="bold"><b>SOURCE</b></span> zone to the <span class="bold"><b>DEST</b></span>
zone will not be rate-limited. Otherwise, this column specifies the
maximum rate at which TCP connection requests will be accepted
followed by a colon (“<span class="quote">:</span>”) followed by the maximum burst
size that will be tolerated. Example: <span class="bold"><b>10/sec:40</b></span>
specifies that the maximum rate of TCP connection requests allowed
will be 10 per second and a burst of 40 connections will be
tolerated. Connection requests in excess of these limits will be
dropped. See the <a href="#Rules" title="/etc/shorewall/rules">rules file documentation</a>
for an explaination of how rate limiting works.</p></dd></dl></div><p>In the SOURCE and DEST columns, you can enter “<span class="quote">all</span>” to
indicate all zones.</p><p>The default <tt class="filename">/etc/shorewall/policy</tt> file is as
follows.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT info</pre></td></tr></table><p>This table may be interpreted as follows:</p><div class="itemizedlist"><ul type="disc"><li><p>All connection requests from the local network to hosts on the
internet are accepted.</p></li><li><p>All connection requests originating from the internet are
ignored and logged at level KERNEL.INFO.</p></li><li><p>All other connection requests are rejected and logged.</p></li></ul></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>The firewall script processes the <tt class="filename">/etc/shorewall/policy</tt>
file from top to bottom and <span class="bold"><b>uses the first
applicable policy that it finds</b></span>. For example, in the
following policy file, the policy for (loc, loc) connections would be
ACCEPT as specified in the first entry even though the third entry in
the file specifies REJECT.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc all ACCEPT
net all DROP info
loc loc REJECT info</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2866348"></a>Intra-Zone Traffic</h3></div></div><div></div></div><p>Shorewall allows a zone to be associated with more than one
interface or with multiple networks that interface through a single
interface. Beginning with Shorewall 1.4.1, Shorewall will ACCEPT all
traffic from a zone to itself provided that there is no explicit policy
governing traffic from that zone to itself (an explicit policy does not
specify “<span class="quote">all</span>” in either the SOURCE or DEST column) and that
there are no rules concerning connections from that zone to itself. If
there is an explicit policy or if there are one or more rules, then
traffic within the zone is handled just like traffic between zones is.</p><p>Any time that you have multiple interfaces associated with a
single zone, you should ask yourself if you really want traffic routed
between those interfaces. Cases where you might not want that behavior
are:</p><div class="orderedlist"><ol type="1"><li><p>Multiple “<span class="quote">net</span>” interfaces to different ISPs. You
don't want to route traffic from one ISP to the other through
your firewall.</p></li><li><p>Multiple VPN clients. You don't necessarily want them to
all be able to communicate between themselves using your
gateway/router.</p></li></ol></div><p>Beginning with Shorewall 2.0.0, you can control the traffic from
the firewall to itself. As with any zone, fw-&gt;fw traffic is enabled
by default. It is not necessary to define the loopback interface (lo) in
<a href="#Interfaces" title="/etc/shorewall/interfaces">/etc/shorewall/interfaces</a> in order to
define fw-&gt;fw rules or a fw-&gt;fw policy.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>So long as there are no intra-zone rules for a zone, all
intra-zone traffic for that zone is accepted. As soon as you add a
single rule from the zone to itself, then ALL traffic from that zone
to itself is controlled by the rules and the first policy in
<tt class="filename">/etc/shorewall/policy</tt> that matches the zone to
itself.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="CONTINUE"></a>The CONTINUE policy</h3></div></div><div></div></div><p>Where zones are <a href="#Nested" title="Nested and Overlapping Zones">nested or overlapping</a>,
the CONTINUE policy allows hosts that are within multiple zones to be
managed under the rules of all of these zones. Let's look at an
example:</p><p><tt class="filename">/etc/shorewall/zones</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
sam Sam Sam's system at home
net Internet The Internet
loc Local Local Network</pre></td></tr></table><p><tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
- eth0 detect dhcp,norfc1918
loc eth1 detect</pre></td></tr></table><p><tt class="filename">/etc/shorewall/hosts</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
net eth0:0.0.0.0/0
sam eth0:206.191.149.197</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Sam's home system is a member of both the <span class="bold"><b>sam</b></span> zone and the <span class="bold"><b>net</b></span>
zone and <a href="#Nested" title="Nested and Overlapping Zones">as described above</a> , that means
that <span class="bold"><b>sam</b></span> must be listed before
<span class="bold"><b>net</b></span> in <tt class="filename">/etc/shorewall/zones</tt>.</p></div><p><tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL
loc net ACCEPT
sam all CONTINUE
net all DROP info
all all REJECT info</pre></td></tr></table><p>The second entry above says that when Sam is the client,
connection requests should first be process under rules where the source
zone is <span class="bold"><b>sam</b></span> and if there is no match
then the connection request should be treated under rules where the
source zone is <span class="bold"><b>net</b></span>. It is important
that this policy be listed BEFORE the next policy (<span class="bold"><b>net</b></span>
to <span class="bold"><b>all</b></span>).</p><p>Partial <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
...
DNAT sam loc:192.168.1.3 tcp ssh
DNAT net loc:192.168.1.5 tcp www
...</pre></td></tr></table><p>Given these two rules, Sam can connect to the firewall's
internet interface with ssh and the connection request will be forwarded
to 192.168.1.3. Like all hosts in the <span class="bold"><b>net</b></span>
zone, Sam can connect to the firewall's internet interface on TCP
port 80 and the connection request will be forwarded to 192.168.1.5. The
order of the rules is not significant.</p><p><a id="Exclude"></a>Sometimes it is necessary to suppress port forwarding
for a sub-zone. For example, suppose that all hosts can SSH to the
firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects
to the firewall's external IP, he should be connected to the
firewall itself. Because of the way that Netfilter is constructed, this
requires two rules as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
...
DNAT sam fw tcp ssh
DNAT net loc:192.168.1.3 tcp ssh
...</pre></td></tr></table><p>The first rule allows Sam SSH access to the firewall. The second
rule says that any clients from the net zone with the exception of those
in the “<span class="quote">sam</span>” zone should have their connection port
forwarded to 192.168.1.3. If you need to exclude more than one zone in
this way, you can list the zones separated by commas (e.g.,
net!sam,joe,fred). This technique also may be used when the ACTION is
REDIRECT.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Rules"></a>/etc/shorewall/rules</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/rules</tt> file defines
exceptions to the policies established in the <tt class="filename">/etc/shorewall/policy</tt>
file. There is one entry in /etc/shorewall/rules for each of these rules.
Entries in this file only govern the establishment of new connections —
packets that are part of an existing connection or that establish a
connection that is related to an existing connection are automatically
accepted.</p><p>Rules for each pair of zones (source zone, destination zone) are
evaluated in the order that they appear in the file — the first match
determines the disposition of the connection request with a couple of
caveats:</p><div class="itemizedlist"><ul type="disc"><li><p>LOG rules cause the connection request to be logged then
processing continues with the next rule in the file.</p></li><li><p>QUEUE rules cause the connection request to be passed to
user-space -- the user-space application can later insert them back
into the stream for further processing by following rules.</p></li><li><p>CONTINUE rules may cause the connection request to be
reprocessed using a different (source zone, destination zone) pair.</p></li></ul></div><p>Entries in the file have the following columns:</p><div class="variablelist"><dl><dt><span class="term">ACTION</span></dt><dd><div class="variablelist"><dl><dt><span class="term">ACCEPT, DROP, REJECT, CONTINUE</span></dt><dd><p>These have the same meaning here as in the policy file
above.</p></dd><dt><span class="term">DNAT</span></dt><dd><p>Causes the connection request to be forwarded to the
system specified in the DEST column (port forwarding).
“<span class="quote">DNAT</span>” stands for “<span class="quote"><span class="bold"><b>D</b></span>estination
<span class="bold"><b>N</b></span>etwork <span class="bold"><b>A</b></span>ddress
<span class="bold"><b>T</b></span>ranslation</span>”</p></dd><dt><span class="term">DNAT-</span></dt><dd><p>The above ACTION (DNAT) generates two iptables rules:</p><div class="orderedlist"><ol type="1"><li><p>a header-rewriting rule in the Netfilter
“<span class="quote">nat</span>” table</p></li><li><p>an ACCEPT rule in the Netfilter “<span class="quote">filter</span>”
table.</p></li></ol></div><p>DNAT- works like DNAT but only generates the
header-rewriting rule.</p></dd><dt><span class="term">REDIRECT</span></dt><dd><p>Causes the connection request to be redirected to a port
on the local (firewall) system.</p></dd><dt><span class="term">REDIRECT-</span></dt><dd><p>The above ACTION (REDIRECT) generates two iptables
rules:</p><div class="orderedlist"><ol type="1"><li><p>a header-rewriting rule in the Netfilter
“<span class="quote">nat</span>” table</p></li><li><p>an ACCEPT rule in the Netfilter “<span class="quote">filter</span>”
table.</p></li></ol></div><p>REDIRECT- works like REDIRECT but only generates the
header-rewriting rule.</p></dd><dt><span class="term">LOG</span></dt><dd><p>Log the packet -- requires a syslog level (see below).</p></dd><dt><span class="term">QUEUE</span></dt><dd><p>Forward the packet to a user-space application. This
facility is provided to allow interfacing to <a href="http://p2pwall.sourceforge.net" target="_self">ftwall</a> for <a href="Shorewall_and_Kazaa.html" target="_self">Kazaa filtering</a>.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When the protocol specified in the PROTO column is TCP
(“<span class="quote">tcp</span>”, “<span class="quote">TCP</span>” or “<span class="quote">6</span>”),
Shorewall will only pass connection requests (SYN packets)
to user space. This is for compatibility with ftwall.</p></div></dd><dt><span class="term"><a href="User_defined_Actions.html" target="_self">&lt;defined
action&gt;</a></span></dt><dd><p>(Shorewall 1.4.9 and later) - An action defined in the
<tt class="filename"><a href="User_defined_Actions.html" target="_self">/etc/shorewall/actions</a></tt>
file.</p></dd></dl></div><p>The ACTION may optionally be followed by “<span class="quote">:</span>” and
a <a href="shorewall_logging.html" target="_self">syslog level</a> (example:
REJECT:info or ACCEPT:debug). This causes the packet to be logged at
the specified level prior to being processed according to the
specified ACTION. Note: if the ACTION is LOG then you MUST specify a
syslog level.</p><p>The use of DNAT or REDIRECT requires that you have NAT enabled
in your <a href="kernel.htm" target="_self">kernel configuration</a>.</p></dd><dt><span class="term">SOURCE</span></dt><dd><p>Describes the source hosts to which the rule applies.. The
contents of this field must begin with the name of a zone defined in
/etc/shorewall/zones, $FW or “<span class="quote">all</span>”. If the ACTION is
DNAT or REDIRECT, sub-zones may be excluded from the rule by
following the initial zone name with “<span class="quote">!</span>” and a
comma-separated list of those sub-zones to be excluded. There is an
<a href="#Exclude">example</a> above.</p><p>If the source is not “<span class="quote">all</span>” then the source may be
further restricted by adding a colon (“<span class="quote">:</span>”) followed by
a comma-separated list of qualifiers. Qualifiers are may include:</p><div class="variablelist"><dl><dt><span class="term">interface name</span></dt><dd><p>refers to any connection requests arriving on the
specified interface (example loc:eth4). Beginning with
Shorwall 1.3.9, the interface name may optionally be followed
by a colon (“<span class="quote">:</span>”) and an IP address or subnet
(examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).</p></dd><dt><span class="term">IP address</span></dt><dd><p>refers to a connection request from the host with the
specified address (example net:155.186.235.151). If the ACTION
is DNAT, this must not be a DNS name.</p></dd><dt><span class="term">MAC Address</span></dt><dd><p>in <a href="configuration_file_basics.htm#MAC" target="_self">Shorewall
format</a>.</p></dd><dt><span class="term">subnet</span></dt><dd><p>refers to a connection request from any host in the
specified subnet (example net:155.186.235.0/24).</p></dd></dl></div></dd><dt><span class="term">DEST</span></dt><dd><p>Describes the destination host(s) to which the rule applies.
May take most of the forms described above for SOURCE plus the
following two additional forms:</p><div class="itemizedlist"><ul type="disc"><li><p>An IP address followed by a colon and the port <span class="bold"><b>number</b></span> that the server is listening on
(service names from /etc/services are not allowed - example
loc:192.168.1.3:80).</p></li><li><p>A single port number (again, service names are not
allowed) -- this form is only allowed if the ACTION is REDIRECT
and refers to a server running on the firewall itself and
listening on the specified port.</p></li></ul></div><p>Restrictions:</p><div class="itemizedlist"><ul type="disc"><li><p>MAC addresses may not be specified.</p></li><li><p>In DNAT rules, only IP addresses may be given -- DNS names
are not permitted.</p></li><li><p>You may not specify both an IP address and an interface
name in the DEST column.</p></li></ul></div><p>Unlike in the SOURCE column, a range of IP addresses may be
specified in the DEST column as &lt;<span class="emphasis"><em>first address</em></span>&gt;-&lt;<span class="emphasis"><em>last
address</em></span>&gt;. When the ACTION is DNAT or DNAT-,
connections will be assigned to the addresses in the range in a
round-robin fashion (load-balancing). <span class="bold"><b>This
feature is available with DNAT rules only with Shorewall 1.4.6 and
later versions; it is available with DNAT- rules in all versions
that support DNAT-.</b></span></p></dd><dt><span class="term">PROTO</span></dt><dd><p>Protocol. Must be a protocol name from /etc/protocols, a
number or “<span class="quote">all</span>”. Specifies the protocol of the
connection request.</p></dd><dt><span class="term">DEST PORT(S)</span></dt><dd><p>Port or port range (&lt;low port&gt;:&lt;high port&gt;)
being connected to. May only be specified if the protocol is tcp,
udp or icmp. For icmp, this column's contents are interpreted as
an icmp type. If you don't want to specify DEST PORT(S) but need
to include information in one of the columns to the right, enter
“<span class="quote">-</span>” in this column. You may give a list of ports and/or
port ranges separated by commas. Port numbers may be either integers
or service names from /etc/services.</p></dd><dt><span class="term">SOURCE PORTS(S)</span></dt><dd><p>May be used to restrict the rule to a particular client port
or port range (a port range is specified as &lt;low port
number&gt;:&lt;high port number&gt;). If you don't want to
restrict client ports but want to specify something in the next
column, enter “<span class="quote">-</span>” in this column. If you wish to
specify a list of port number or ranges, separate the list elements
with commas (with no embedded white space). Port numbers may be
either integers or service names from /etc/services.</p></dd><dt><span class="term">ORIGINAL DEST</span></dt><dd><p>This column may only be non-empty if the ACTION is DNAT or
REDIRECT.</p><p>If DNAT or REDIRECT is the ACTION and the ORIGINAL DEST column
is left empty, any connection request arriving at the firewall from
the SOURCE that matches the rule will be forwarded or redirected.
This works fine for connection requests arriving from the internet
where the firewall has only a single external IP address. When the
firewall has multiple external IP addresses or when the SOURCE is
other than the internet, there will usually be a desire for the rule
to only apply to those connection requests directed to particular IP
addresses (see Example 2 below for another usage). Those IP
addresses are specified in the ORIGINAL DEST column as a
comma-separated list.</p><p>The IP address(es) may be optionally followed by
“<span class="quote">:</span>” and a second IP address. This latter address, if
present, is used as the source address for packets forwarded to the
server (This is called “<span class="quote">Source NAT</span>” or SNAT.</p><p>If this list begins with “<span class="quote">!</span>” then the rule will
only apply if the original destination address matches none of the
addresses listed.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When using SNAT, it is a good idea to qualify the source
with an IP address or subnet. Otherwise, it is likely that SNAT
will occur on connections other than those described in the rule.
The reason for this is that SNAT occurs in the Netfilter
POSTROUTING hook where it is not possible to restrict the scope of
a rule by incoming interface.</p><div class="example"><a id="id2876539"></a><p class="title"><b>Example 8. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT(S) PORT(S) DEST
DNAT loc:<span class="bold"><b>192.168.1.0/24</b></span> loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3</pre></td></tr></table></div></div><p>If SNAT is not used (no “<span class="quote">:</span>” and second IP
address), the original source address is used. If you want any
destination address to match the rule but want to specify SNAT,
simply use a colon followed by the SNAT address.</p></dd><dt><span class="term">RATE LIMIT</span></dt><dd><p>Beginning with Shorewall version 1.4.7, you may rate-limit
ACCEPT, DNAT[-], REDIRECT[-] or LOG rules with an entry in this
column. Entries have the form</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;]</pre></td></tr></table><p>where &lt;rate&gt; is the number of connections per
&lt;interval&gt; (“<span class="quote">sec</span>” or “<span class="quote">min</span>”) and
&lt;burst&gt; is the largest burst permitted. If no burst value is
given, a value of 5 is assumed.</p><p>There may be no whitespace embedded in the specification.</p><div class="example"><a id="id2876631"></a><p class="title"><b>Example 9. Let's take</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT&lt;2/sec:4&gt; net dmz tcp 80</pre></td></tr></table><p>The first time this rule is reached, the packet will be
accepted; in fact, since the burst is 4, the first four packets
will be accepted. After this, it will be 500ms (1 second divided
by the rate of 2) before a packet will be accepted from this rule,
regardless of how many packets reach it. Also, every 500ms which
passes without matching a packet, one of the bursts will be
regained; if no packets hit the rule for 2 second, the burst will
be fully recharged; back where we started.</p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>When rate limiting is specified on a rule with
“<span class="quote">all</span>” in the SOURCE or DEST fields below, the limit
will apply to each pair of zones individually rather than as a
single limit for all pairs of zones covered by the rule.</p></div><p>If you want to specify any following columns but no rate
limit, place “<span class="quote">-</span>” in this column.</p></dd><dt><span class="term">USER/GROUP</span></dt><dd><p>Beginning with Shorewall release 1.4.7, output rules from the
firewall itself may be restricted to a particular set of users
and/or user groups. See the <a href="UserSets.html" target="_self">User Set
Documentation</a> for details.</p></dd></dl></div><div class="example"><a id="id2876723"></a><p class="title"><b>Example 10. You wish to forward all ssh connection requests from the internet
to local system 192.168.1.3. You wish to limit the number of connections
to 4/minute with a burst of 8 (Shorewall 1.4.7 and later only):</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT&lt;4/min:8&gt; net loc:192.168.1.3 tcp ssh</pre></td></tr></table></div><div class="example"><a id="id2876744"></a><p class="title"><b>Example 11. You want to redirect all local www connection requests EXCEPT
those to your own http server (206.124.146.177) to a Squid transparent
proxy running on the firewall and listening on port 3128. Squid will of
course require access to remote web servers. This example shows yet
another use for the ORIGINAL DEST column; here, connection requests that
were NOT (notice the “<span class="quote">!</span>”) originally destined to
206.124.146.177 are redirected to local port 3128.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
REDIRECT loc 3128 tcp www - !206.124.146.177
ACCEPT fw net tcp www</pre></td></tr></table></div><div class="example"><a id="id2876777"></a><p class="title"><b>Example 12. You want to run a web server at 155.186.235.222 in your DMZ and
have it accessible remotely and locally. the DMZ is managed by Proxy ARP
or by classical sub-netting.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net dmz:155.186.235.222 tcp www
ACCEPT loc dmz:155.186.235.222 tcp www</pre></td></tr></table></div><div class="example"><a id="id2876799"></a><p class="title"><b>Example 13. You want to run wu-ftpd on 192.168.2.2 in your masqueraded DMZ.
Your internet interface address is 155.186.235.151 and you want the FTP
server to be accessible from the internet in addition to the local
192.168.1.0/24 and dmz 192.168.2.0/24 subnetworks.</b></p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>since the server is in the 192.168.2.0/24 subnetwork,
we can assume that access to the server from that subnet will not
involve the firewall (<a href="FAQ.htm#faq2" target="_self">but see FAQ 2</a>)</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>unless
you have more than one external IP address, you can leave the ORIGINAL
DEST column blank in the first rule. You cannot leave it blank in the
second rule though because then all ftp connections originating in the
local subnet 192.168.1.0/24 would be sent to 192.168.2.2 regardless of
the site that the user was trying to connect to. That is clearly not
what you want.</p></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT net dmz:192.168.2.2 tcp ftp
DNAT loc:192.168.1.0/24 dmz:192.168.2.2 tcp ftp - 155.186.235.151</pre></td></tr></table><p>If you are running wu-ftpd, you should restrict the range of
passive in your /etc/ftpaccess file. I only need a few simultaneous FTP
sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry
is appropriate:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">passive ports 0.0.0.0/0 65500 65534</pre></td></tr></table><p>If you are running pure-ftpd, you would include “<span class="quote">-p
65500:65534</span>” on the pure-ftpd runline.</p><p>The important point here is to ensure that the port range used for
FTP passive connections is unique and will not overlap with any usage on
the firewall system.</p></div><div class="example"><a id="id2876887"></a><p class="title"><b>Example 14. You wish to allow unlimited DMZ access to the host with MAC
address 02:00:08:E3:FA:55.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc:~02-00-08-E3-FA-55 dmz all</pre></td></tr></table></div><div class="example"><a id="id2876906"></a><p class="title"><b>Example 15. You wish to allow access to the SMTP server in your DMZ from all
zones.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT all dmz tcp 25</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>When “<span class="quote">all</span>” is used as a source or
destination, intra-zone traffic is not affected. In this example, if
there were two DMZ interfaces then the above rule would NOT enable SMTP
traffic between hosts on these interfaces.</p></div></div><div class="example"><a id="id2876940"></a><p class="title"><b>Example 16. Your firewall's external interface has several IP addresses
but you only want to accept SSH connections on address 206.124.146.176.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net fw:206.124.146.176 tcp 22</pre></td></tr></table></div><div class="example"><a id="id2876962"></a><p class="title"><b>Example 17. (For advanced users running Shorewall version 1.3.13 or later).
From the internet, you with to forward tcp port 25 directed to
192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also
want to allow access from the internet directly to tcp port 25 on
192.0.2.177.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT- net dmz:192.0.2.177 tcp 25 - 192.0.2.178
DNAT- net dmz:192.0.2.177 tcp 25 - 192.0.2.179
ACCEPT net dmz:192.0.2.177 tcp 25</pre></td></tr></table><p>Using “<span class="quote">DNAT-</span>” rather than “<span class="quote">DNAT</span>” avoids
two extra copies of the third rule from being generated.</p></div><div class="example"><a id="id2877003"></a><p class="title"><b>Example 18. (Shorewall version 1.4.6 or later). You have 9 http servers
behind a Shorewall firewall and you want connection requests to be
distributed among your servers. The servers are
192.168.1.101-192.168.1.109.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net loc:192.168.1.101-192.168.1.109 tcp 80</pre></td></tr></table></div><p><a href="ports.htm" target="_self">Look here for information on other services.</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Masq"></a>/etc/shorewall/masq</h2></div></div><div></div></div><p>The /etc/shorewall/masq file is used to define classical IP
Masquerading and Source Network Address Translation (SNAT). There is one
entry in the file for each subnet that you want to masquerade. In order to
make use of this feature, you must have NAT enabled.</p><p>Columns are:</p><div class="variablelist"><dl><dt><span class="term">INTERFACE</span></dt><dd><p>The interface that will masquerade the subnet; this is
normally your internet interface. This interface name can be
optionally qualified by adding “<span class="quote">:</span>” and a subnet or host
IP. When this qualification is added, only packets addressed to that
host or subnet will be masqueraded. Beginning with Shorewall version
1.4.10, the interface name can be qualified with &quot;:&quot;
followed by a comma separated list of hosts and/or subnets. If this
list begins with “<span class="quote">!</span>” (e.g., “<span class="quote">eth0:!192.0.2.8/29,192.0.2.32/29</span>”)
then only packets addressed to destinations <span class="bold"><b>not</b></span>
listed will be masqueraded; otherwise (e.g., “<span class="quote">eth0:192.0.2.8/29,192.0.2.32/29</span>”),
traffic will be masqueraded if it <span class="bold"><b>does</b></span>
match one of the listed addresses.</p><p>Beginning with Shorewall version 1.3.14, if you have set
ADD_SNAT_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>, you can cause
Shorewall to create an alias <span class="emphasis"><em>label</em></span> of the form
<span class="emphasis"><em>interfacename:digit</em></span> (e.g., eth0:0) by placing
that label in this column. See example 5 below. Alias labels created
in this way allow the alias to be visible to the ipconfig utility.
<span class="bold"><b>THAT IS THE ONLY THING THAT THIS LABEL IS GOOD
FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL
CONFIGURATION.</b></span></p></dd><dt><span class="term">SUBNET</span></dt><dd><p>The subnet that you want to have masqueraded through the
INTERFACE. This may be expressed as a single IP address, a subnet or
an interface name. In the latter instance, the interface must be
configured and started before Shorewall is started as Shorewall will
determine the subnet based on information obtained from the
“<span class="quote">ip</span>” utility.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>When using Shorewall 1.3.13 or earlier, when an interface
name is specified, Shorewall will only masquerade traffic from the
first subnetwork on the named interface; if the interface
interfaces to more that one subnetwork, you will need to add
additional entries to this file for each of those other
subnetworks. Beginning with Shorewall 1.3.14, shorewall will
masquerade/SNAT traffic from any host that is routed through the
named interface.</p></div><p>The subnet may be optionally followed by “<span class="quote">!</span>” and
a comma-separated list of addresses and/or subnets that are to be
excluded from masquerading.</p></dd><dt><span class="term">ADDRESS</span></dt><dd><p>The source address to be used for outgoing packets. This
column is optional and if left blank, the current primary IP address
of the interface in the first column is used. If you have a static
IP on that interface, listing it here makes processing of output
packets a little less expensive for the firewall. If you specify an
address in this column, it must be an IP address configured on the
INTERFACE or you must have ADD_SNAT_ALIASES enabled in <a href="#Conf">/etc/shorewall/shorewall.conf</a>. Beginning with Shorewall version 1.4.6, you may
include a range of IP addresses in this column to indicate that
Netfilter should use the addresses in the range in round-robin
fashion. Beginning with Shorewall version 1.4.7, you may include a
list of ranges and/or addresses in this column; again, Netfilter
will use all listed ranges/addresses in rounde-robin fashion.</p></dd></dl></div><div class="example"><a id="id2877263"></a><p class="title"><b>Example 19. You have eth0 connected to a cable modem and eth1 connected to
your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq file
would look like:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.9.0/24</pre></td></tr></table></div><div class="example"><a id="id2877282"></a><p class="title"><b>Example 20. You have a number of IPSEC tunnels through ipsec0 and you want to
masquerade traffic from your 192.168.9.0/24 subnet to the remote subnet
10.1.0.0/16 only.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
ipsec0:10.1.0.0/16 192.168.9.0/24</pre></td></tr></table></div><div class="example"><a id="id2877302"></a><p class="title"><b>Example 21. You have a DSL line connected on eth0 and a local network
(192.168.10.0/24) connected to eth1. You want all local-&gt;net
connections to use source address 206.124.146.176.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.10.0/24 206.124.146.176</pre></td></tr></table></div><div class="example"><a id="id2877324"></a><p class="title"><b>Example 22. Same as example 3 except that you wish to exclude 192.168.10.44
and 192.168.10.45 from the SNAT rule.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.10.0/24!192.168.10.44,192.168.10.45 206.124.146.176</pre></td></tr></table></div><div class="example"><a id="id2877343"></a><p class="title"><b>Example 23. <span class="bold">(Shorewall version &gt;= 1.3.14):</span>
You have a second IP address (206.124.146.177) assigned to you and wish
to use it for SNAT of the subnet 192.168.12.0/24. You want to give that
address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0:0 192.168.12.0/24 206.124.146.177</pre></td></tr></table></div><div class="example"><a id="id2877377"></a><p class="title"><b>Example 24. <span class="bold">(Shorewall version &gt;= 1.4.7):</span>
You want to use both 206.124.146.177 and 206.124.146.179 for SNAT of the
subnet 192.168.12.0/24. Each address will be used on alternate outbound
connections.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 192.168.12.0/24 206.124.146.177,206.124.146.179</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ProxyArp"></a>/etc/shorewall/proxyarp</h2></div></div><div></div></div><p>If you want to use proxy ARP on an entire sub-network, I suggest
that you look at the <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">Proxy ARP Subnet
Mini HOWTO</a>. If you decide to use the technique described in that
HOWTO, you can set the proxy_arp flag for an interface (<tt class="filename">/proc/sys/net/ipv4/conf/</tt>&lt;<span class="emphasis"><em>interface</em></span>&gt;<tt class="filename">/proxy_arp</tt>)
by including the <span class="bold"><b>proxyarp</b></span> option in the
interface's record in <a href="#Interfaces">/etc/shorewall/interfaces</a>. When using Proxy
ARP sub-netting, you do <span class="bold"><b>NOT</b></span> include any
entries in /etc/shorewall/proxyarp.</p><p>The <tt class="filename">/etc/shorewall/proxyarp </tt>file is used to
define <a href="ProxyARP.htm" target="_self">Proxy ARP</a>. The file is typically
used for enabling Proxy ARP on a small set of systems since you need one
entry in this file for each system using proxy ARP. Columns are:</p><div class="variablelist"><dl><dt><span class="term">ADDRESS</span></dt><dd><p>address of the system.</p></dd><dt><span class="term">INTERFACE</span></dt><dd><p>the interface that connects to the system. If the interface is
obvious from the subnetting, you may enter “<span class="quote">-</span>” in this
column.</p></dd><dt><span class="term">EXTERNAL</span></dt><dd><p>the external interface that you want to honor ARP requests for
the ADDRESS specified in the first column.</p></dd><dt><span class="term">HAVEROUTE</span></dt><dd><p>If you already have a route through INTERFACE to ADDRESS, this
column should contain “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”. If
you want Shorewall to add the route, the column should contain
“<span class="quote">No</span>” or “<span class="quote">no</span>”.</p></dd><dt><span class="term">PERSISTENT</span></dt><dd><p>If you specify &quot;No&quot; or &quot;no&quot; in the HAVEROUTE
column, Shorewall will automatically add a route to the host in the
ADDRESS column through the interface in the INTERFACE column. If you
enter “<span class="quote">No</span>” or “<span class="quote">no</span>” in the PERSISTENT
column or if you leave the column empty, that route will be deleted
if you issue a <span><b class="command">shorewall stop</b></span> or
<span><b class="command">shorewall clear</b></span> command. If you place
“<span class="quote">Yes</span>” or “<span class="quote">yes</span>” in the PERSISTENT column,
then those commands will not cause the route to be deleted.</p></dd></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>After you have made a change to the <tt class="filename">/etc/shorewall/proxyarp
file</tt>, you may need to flush the ARP cache of all routers on
the LAN segment connected to the interface specified in the EXTERNAL
column of the change/added entry(s). If you are having problems
communicating between an individual host (A) on that segment and a
system whose entry has changed, you may need to flush the ARP cache on
host A as well.</p><p>ISPs typically have ARP configured with long TTL (hours!) so if
your ISPs router has a stale cache entry (as seen using “<span class="quote">tcpdump
-nei &lt;external interface&gt; host &lt;IP addr&gt;</span>”), it
may take a long while to time out. I personally have had to contact my
ISP and ask them to delete a stale entry in order to restore a system to
working order after changing my proxy ARP settings.</p></div><div class="example"><a id="id2877697"></a><p class="title"><b>Example 25. You have public IP addresses 155.182.235.0/28. You configure your
firewall as follows:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">eth0 - 155.186.235.1 (internet connection) eth1 -
192.168.9.0/24 (masqueraded local systems) eth2 - 192.168.10.1
(interface to your DMZ)</pre></td></tr></table><p>In your DMZ, you want to install a Web/FTP server with public
address 155.186.235.4. On the Web server, you subnet just like the
firewall's eth0 and you configure 155.186.235.1 as the default
gateway. In your <tt class="filename">/etc/shorewall/proxyarp</tt> file, you
will have:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE
155.186.235.4 eth2 eth0 NO</pre></td></tr></table><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You may want to configure the servers in your DMZ with
a subnet that is smaller than the subnet of your internet interface. See
the <a href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/" target="_self">Proxy
ARP Subnet Mini HOWTO</a> for details. In this case you will want to
place “<span class="quote">Yes</span>” in the HAVEROUTE column.</p></div></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Do not use Proxy ARP and FreeS/Wan on the same system unless you
are prepared to suffer the consequences. If you start or restart
Shorewall with an IPSEC tunnel active, the proxied IP addresses are
mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to
the interface that you specify in the INTERFACE column of
<tt class="filename">/etc/shorewall/proxyarp</tt>. I haven't had the time
to debug this problem so I can't say if it is a bug in the Kernel or
in FreeS/Wan.</p><p>You <span class="bold"><b>might</b></span> be able to work around
this problem using the following (I haven't tried it):</p><p>In <tt class="filename">/etc/shorewall/init</tt>, include:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">qt /etc/init.d/ipsec stop</b></span></pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/start</tt>, include:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">qt /etc/init.d/ipsec start</b></span></pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="NAT"></a>/etc/shorewall/nat</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/nat</tt> file is used to define
one-to-one NAT. There is one entry in the file for each one-to-one NAT
relationship that you wish to define. In order to make use of this
feature, you must have NAT enabled.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>If all you want to do is forward ports to servers behind your
firewall, you do NOT want to use one-to-one NAT. Port forwarding can be
accomplished with simple entries in the <a href="#Rules" title="/etc/shorewall/rules">rules file</a>.
Also, in most cases <a href="#ProxyArp" title="/etc/shorewall/proxyarp">Proxy ARP</a> provides a
superior solution to one-to-one NAT because the internal systems are
accessed using the same IP address internally and externally.</p></div><p>Columns in an entry are:</p><div class="variablelist"><dl><dt><span class="term">EXTERNAL</span></dt><dd><p>External IP address</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>This should NOT be the primary IP address of the interface
named in the next column.</p></div></dd><dt><span class="term">INTERFACE</span></dt><dd><p>Interface that you want the EXTERNAL IP address to appear on.
Beginning with Shorewall version 1.3.14, if you have set
ADD_IP_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>, you can specify an
alias label of the form <span class="emphasis"><em>interfacename:digit</em></span>
(e.g., eth0:0) and Shorewall will create the alias with that label.
Alias labels created in this way allow the alias to be visible to
the ipconfig utility. <span class="bold"><b>THAT IS THE ONLY THING
THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN
YOUR SHOREWALL CONFIGURATION.</b></span></p></dd><dt><span class="term">INTERNAL</span></dt><dd><p>Internal IP address.</p></dd><dt><span class="term">ALL INTERFACES</span></dt><dd><p>If “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”, NAT will be
effective from all hosts. If “<span class="quote">No</span>” or “<span class="quote">no</span>”
(or if left empty) then NAT will be effective only through the
interface named in the INTERFACE column.</p></dd><dt><span class="term">LOCAL</span></dt><dd><p>If Yes or yes and the ALL INTERFACES column contains Yes or
yes, NAT will be effective from the firewall system.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>For this to work, you must be running kernel 2.4.19 or later
and iptables 1.2.6a or later and you must have enabled <span class="bold"><b>CONFIG_IP_NF_NAT_LOCAL</b></span> in your kernel.</p></div></dd></dl></div><p><a href="NAT.htm" target="_self">Look here for additional information and an
example.</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Tunnels"></a>/etc/shorewall/tunnels</h2></div></div><div></div></div><p>The /etc/shorewall/tunnels file allows you to define IPSec, GRE,
IPIP, <a href="http://openvpn.sourceforge.net/" target="_self">OpenVPN</a>, PPTP
and 6to4.tunnels with end-points on your firewall. To use ipsec, you must
install version 1.9, 1.91 or the current <a href="http://www.xs4all.nl/%7Efreeswan/" target="_self">FreeS/WAN</a> development
snapshot.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>For kernels 2.4.4 and above, you will need to use version 1.91 or
a development snapshot as patching with version 1.9 results in kernel
compilation errors.</p></div><p>Instructions for setting up <a href="IPSEC.htm" target="_self">IPSEC tunnels</a>
may be found here, instructions for <a href="IPIP.htm" target="_self">IPIP and GRE
tunnels</a> are here, instructions for <a href="OPENVPN.html" target="_self">OpenVPN
tunnels</a> are here, instructions for <a href="PPTP.htm" target="_self">PPTP
tunnels</a> are here, instructions for <a href="6to4.htm" target="_self">6to4
tunnels</a> are here, and instructions for <a href="GenericTunnels.html" target="_self">integrating Shorewall with other types of
tunnels</a> are here.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Conf"></a>/etc/shorewall/shorewall.conf</h2></div></div><div></div></div><p>This file is used to set the following firewall parameters:</p><div class="variablelist"><dl><dt><span class="term">SMURF_LOG_LEVEL</span></dt><dd><p>(Added at version 2.0.0) - Specifies the logging level for
smurf packets (see the <span class="bold"><b>nosmurfs</b></span>
option in <a href="#Interfaces" title="/etc/shorewall/interfaces">/etc/shorewall/interfaces</a>).
If set to the empty value ( SMURF_LOG_LEVEL=&quot;&quot; ) then smurfs
are not logged.</p></dd><dt><span class="term">MODULE_SUFFIX</span></dt><dd><p>(Added at version 1.4.9) - The value of this variable
determines the possible file extensions of kernel modules. The
default value is &quot;o gz ko and o.gz&quot;. See <a href="#modules">/etc/shorewall/modules</a> for more details.</p></dd><dt><span class="term">ADMINISABSENTMINDED</span></dt><dd><p>(Added at version 1.4.7) - The value of this variable affects
Shorewall's <a href="starting_and_stopping_shorewall.htm" target="_self">stopped
state</a>. When ADMINISABSENTMINDES=No, only traffic to/from
those addresses listed in /etc/shorewall/routestopped is accepted
when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in addition
to traffic to/from addresses in /etc/shorewall/routestopped,
connections that were active when Shorewall stopped continue to work
and all new connections from the firewall system itself are allowed.
If this variable is not set or is given the empty value then
ADMINISABSENTMINDED=No is assumed.</p></dd><dt><span class="term">SHOREWALL_SHELL</span></dt><dd><p>(Added at version 1.4.6) - This parameter is used to specify
the shell program to be used to interpret the firewall script
(/usr/share/shorewall/firewall). If not specified or specified as a
null value, /bin/sh is assumed.</p></dd><dt><span class="term">LOGFORMAT</span></dt><dd><p>(Added at version 1.4.4) - The value of this variable generate
the --log-prefix setting for Shorewall logging rules. It contains a
“<span class="quote">printf</span>” formatting template which accepts three
arguments (the chain name, logging rule number (optional) and the
disposition). To use LOGFORMAT with <a href="http://www.fireparse.com" target="_self">fireparse</a>, set it as:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGFORMAT=&quot;fp=%s:%d a=%s &quot;</pre></td></tr></table><p>If the LOGFORMAT value contains the substring “<span class="quote">%d</span>”
then the logging rule number is calculated and formatted in that
position; if that substring is not included then the rule number is
not included. If not supplied or supplied as empty
(LOGFORMAT=&quot;&quot;) then “<span class="quote">Shorewall:%s:%s:</span>” is
assumed.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p><span><b class="command">/sbin/shorewall</b></span> uses the leading part of
the LOGFORMAT string (up to but not including the first
“<span class="quote">%</span>”) to find log messages in the “<span class="quote">show log</span>”,
“<span class="quote">status</span>” and “<span class="quote">hits</span>” commands. This part
should not be omitted (the LOGFORMAT should not begin with
“<span class="quote">%</span>”) and the leading part should be sufficiently
unique for <span><b class="command">/sbin/shorewall</b></span> to identify
Shorewall messages.</p></div></dd><dt><span class="term">CLEAR_TC</span></dt><dd><p>(Added at version 1.3.13) - If this option is set to
“<span class="quote">No</span>” then Shorewall won't clear the current traffic
control rules during [re]start. This setting is intended for use by
people that prefer to configure traffic shaping when the network
interfaces come up rather than when the firewall is started. If that
is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do
not supply an <tt class="filename">/etc/shorewall/tcstart</tt> file. That
way, your traffic shaping rules can still use the “<span class="quote">fwmark</span>”
classifier based on packet marking defined in
/etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is assumed.</p></dd><dt><span class="term">MARK_IN_FORWARD_CHAIN</span></dt><dd><p>(Added at version 1.3.12) - If your kernel has a FORWARD chain
in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes to cause
the marking specified in the <a href="traffic_shaping.htm#tcrules" target="_self">tcrules file</a> to occur in
that chain rather than in the PREROUTING chain. This permits you to
mark inbound traffic based on its destination address when SNAT or
Masquerading are in use. To determine if your kernel has a FORWARD
chain in the mangle table, use the “<span class="quote"><span><b class="command">/sbin/shorewall
show mangle</b></span></span>” command; if a FORWARD chain is
displayed then your kernel will support this option. If this option
is not specified or if it is given the empty value (e.g.,
MARK_IN_FORWARD_CHAIN=&quot;&quot;) then MARK_IN_FORWARD_CHAIN=No is
assumed.</p></dd><dt><span class="term">RFC1918_LOG_LEVEL</span></dt><dd><p>(Added at version 1.3.12) - This parameter determines the
level at which packets logged under the <a href="#rfc1918" title="/etc/shorewall/rfc1918 (Added in Version 1.3.1)">“<span class="quote">norfc1918</span>”
mechanism</a> are logged. The value must be a valid <a href="shorewall_logging.html" target="_self">syslog level</a> and if no level is
given, then info is assumed. Prior to Shorewall version 1.3.12,
these packets are always logged at the info level.</p></dd><dt><span class="term">TCP_FLAGS_DISPOSITION</span></dt><dd><p>(Added in Version 1.3.11) - Determines the disposition of TCP
packets that fail the checks enabled by the <a href="#Interfaces" title="/etc/shorewall/interfaces">tcpflags</a> interface option and must have
a value of ACCEPT (accept the packet), REJECT (send an RST response)
or DROP (ignore the packet). If not set or if set to the empty value
(e.g., TCP_FLAGS_DISPOSITION=&quot;&quot;) then
TCP_FLAGS_DISPOSITION=DROP is assumed.</p></dd><dt><span class="term">TCP_FLAGS_LOG_LEVEL</span></dt><dd><p>(Added in Version 1.3.11) - Determines the <a href="shorewall_logging.html" target="_self">syslog level</a> for logging
packets that fail the checks enabled by the <a href="#Interfaces" title="/etc/shorewall/interfaces">tcpflags</a> interface option.The value must
be a valid syslogd log level. If you don't want to log these
packets, set to the empty value (e.g.,
TCP_FLAGS_LOG_LEVEL=&quot;&quot;).</p></dd><dt><span class="term">MACLIST_DISPOSITION</span></dt><dd><p>(Added in Version 1.3.10) - Determines the disposition of
connections requests that fail <a href="MAC_Validation.html" target="_self">MAC
Verification</a> and must have the value ACCEPT (accept the
connection request anyway), REJECT (reject the connection request)
or DROP (ignore the connection request). If not set or if set to the
empty value (e.g., MACLIST_DISPOSITION=&quot;&quot;) then
MACLIST_DISPOSITION=REJECT is assumed.</p></dd><dt><span class="term">MACLIST_LOG_LEVEL</span></dt><dd><p>(Added in Version 1.3.10) - Determines the <a href="shorewall_logging.html" target="_self">syslog level</a> for logging
connection requests that fail <a href="MAC_Validation.html" target="_self">MAC
Verification</a>. The value must be a valid syslogd log level.
If you don't want to log these connection requests, set to the
empty value (e.g., MACLIST_LOG_LEVEL=&quot;&quot;).</p></dd><dt><span class="term">NEWNOTSYN</span></dt><dd><p>(Added in Version 1.3.8) - When set to “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>”, Shorewall will filter TCP packets that are not
part of an established connention and that are not SYN packets (SYN
flag on - ACK flag off). If set to “<span class="quote">No</span>”, Shorewall will
silently drop such packets. If not set or set to the empty value
(e.g., “<span class="quote">NEWNOTSYN=</span>”), NEWNOTSYN=No is assumed.</p><p>If you have a HA setup with failover to another firewall, you
should have NEWNOTSYN=Yes on both firewalls. You should also select
NEWNOTSYN=Yes if you have asymmetric routing.</p></dd><dt><span class="term">LOGNEWNOTSYN</span></dt><dd><p>(Added in Version 1.3.6) - Beginning with version 1.3.6,
Shorewall drops non-SYN TCP packets that are not part of an existing
connection. If you would like to log these packets, set LOGNEWNOTSYN
to the <a href="shorewall_logging.html" target="_self">syslog level</a> at
which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Packets logged under this option are usually the result of
broken remote IP stacks rather than the result of any sort of
attempt to breach your firewall.</p></div></dd><dt><span class="term">DETECT_DNAT_ADDRS</span></dt><dd><p>(Added in Version 1.3.4) - If set to “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>”, Shorewall will detect the first IP address of
the interface to the source zone and will include this address in
DNAT rules as the original destination IP address. If set to
“<span class="quote">No</span>” or “<span class="quote">no</span>”, Shorewall will not detect
this address and any destination IP address will match the DNAT
rule. If not specified or empty, “<span class="quote">DETECT_DNAT_ADDRS=Yes</span>”
is assumed.</p></dd><dt><span class="term">NAT_BEFORE_RULES</span></dt><dd><p>If set to “<span class="quote">No</span>” or “<span class="quote">no</span>”, port
forwarding rules can override the contents of the <a href="#NAT">/etc/shorewall/nat</a> file. If set to “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>”, port forwarding rules cannot override one-to-one
NAT. If not set or set to an empty value, “<span class="quote">Yes</span>” is
assumed.</p></dd><dt><span class="term">FW</span></dt><dd><p>This parameter specifies the name of the firewall zone. If not
set or if set to an empty string, the value “<span class="quote">fw</span>” is
assumed.</p></dd><dt><span class="term">SUBSYSLOCK</span></dt><dd><p>This parameter should be set to the name of a file that the
firewall should create if it starts successfully and remove when it
stops. Creating and removing this file allows Shorewall to work with
your distribution's initscripts. For RedHat, this should be set
to /var/lock/subsys/shorewall. For Debian, the value is
/var/state/shorewall and in LEAF it is /var/run/shorwall. Example:
SUBSYSLOCK=/var/lock/subsys/shorewall.</p></dd><dt><span class="term">STATEDIR</span></dt><dd><p>This parameter specifies the name of a directory where
Shorewall stores state information. If the directory doesn't
exist when Shorewall starts, it will create the directory. Example:
STATEDIR=/tmp/shorewall.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you change the STATEDIR variable while the firewall is
running, create the new directory if necessary then copy the
contents of the old directory to the new directory.</p></div></dd><dt><span class="term">MODULESDIR</span></dt><dd><p>This parameter specifies the directory where your kernel
netfilter modules may be found. If you leave the variable empty,
Shorewall will supply the value &quot;/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter.</p></dd><dt><span class="term">LOGRATE and LOGBURST</span></dt><dd><p>These parameters set the match rate and initial burst size for
logged packets. Please see the iptables man page for a description
of the behavior of these parameters (the iptables option --limit is
set by LOGRATE and --limit-burst is set by LOGBURST). If both
parameters are set empty, no rate-limiting will occur.</p><div class="example"><a id="id2879060"></a><p class="title"><b>Example 26. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGRATE=10/minute LOGBURST=5</pre></td></tr></table></div></dd><dt><span class="term">LOGFILE</span></dt><dd><p>This parameter tells the /sbin/shorewall program where to look
for Shorewall messages when processing the “<span class="quote">show log</span>”,
“<span class="quote">monitor</span>”, “<span class="quote">status</span>” and “<span class="quote">hits</span>”
commands. If not assigned or if assigned an empty value,
/var/log/messages is assumed.</p></dd><dt><span class="term">IP_FORWARDING</span></dt><dd><p>This parameter determines whether Shorewall enables or
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
Possible values are:</p><div class="variablelist"><dl><dt><span class="term">On or on</span></dt><dd><p>packet forwarding will be enabled.</p></dd><dt><span class="term">Off or off</span></dt><dd><p>packet forwarding will be disabled.</p></dd><dt><span class="term">Keep or keep</span></dt><dd><p>Shorewall will neither enable nor disable packet
forwarding.</p></dd></dl></div><p>If this variable is not set or is given an empty value
(IP_FORWARD=&quot;&quot;) then IP_FORWARD=On is assumed.</p></dd><dt><span class="term">ADD_IP_ALIASES</span></dt><dd><p>This parameter determines whether Shorewall automatically adds
the <span class="emphasis"><em>external</em></span> address(es) in <a href="#NAT">/etc/shorewall/nat</a>.
If the variable is set to “<span class="quote">Yes</span>” or “<span class="quote">yes</span>”
then Shorewall automatically adds these aliases. If it is set to
“<span class="quote">No</span>” or “<span class="quote">no</span>”, you must add these aliases
yourself using your distribution's network configuration tools.</p><p>If this variable is not set or is given an empty value
(ADD_IP_ALIASES=&quot;&quot;) then ADD_IP_ALIASES=Yes is assumed.</p></dd><dt><span class="term">ADD_SNAT_ALIASES</span></dt><dd><p>This parameter determines whether Shorewall automatically adds
the SNAT <span class="emphasis"><em>ADDRESS</em></span> in <a href="#Masq">/etc/shorewall/masq</a>. If
the variable is set to “<span class="quote">Yes</span>” or “<span class="quote">yes</span>” then
Shorewall automatically adds these addresses. If it is set to
“<span class="quote">No</span>” or “<span class="quote">no</span>”, you must add these addresses
yourself using your distribution's network configuration tools.</p><p>If this variable is not set or is given an empty value
(ADD_SNAT_ALIASES=&quot;&quot;) then ADD_SNAT_ALIASES=No is assumed.</p></dd><dt><span class="term">LOGUNCLEAN</span></dt><dd><p>This parameter determines the logging level of mangled/invalid
packets controlled by the “<span class="quote">dropunclean and logunclean</span>”
interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets
selected by “<span class="quote">dropclean</span>” are dropped silently (“<span class="quote">logunclean</span>”
packets are logged under the “<span class="quote">info</span>” log level).
Otherwise, these packets are logged at the specified level (Example:
LOGUNCLEAN=debug).</p></dd><dt><span class="term">BLACKLIST_DISPOSITION</span></dt><dd><p>This parameter determines the disposition of packets from
blacklisted hosts. It may have the value DROP if the packets are to
be dropped or REJECT if the packets are to be replied with an ICMP
port unreachable reply or a TCP RST (tcp only). If you do not assign
a value or if you assign an empty value then DROP is assumed.</p></dd><dt><span class="term">BLACKLIST_LOGLEVEL</span></dt><dd><p>This paremter determines if packets from blacklisted hosts are
logged and it determines the syslog level that they are to be logged
at. Its value is a <a href="shorewall_logging.html" target="_self">syslog level</a>
(Example: BLACKLIST_LOGLEVEL=debug). If you do not assign a value or
if you assign an empty value then packets from blacklisted hosts are
not logged.</p></dd><dt><span class="term">CLAMPMSS</span></dt><dd><p>This parameter enables the TCP Clamp MSS to PMTU feature of
Netfilter and is usually required when your internet connection is
through PPPoE or PPTP. If set to “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>”, the feature is enabled. If left blank or set to
“<span class="quote">No</span>” or “<span class="quote">no</span>”, the feature is not enabled.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This option requires CONFIG_IP_NF_TARGET_TCPMSS <a href="kernel.htm" target="_self">in your kernel</a>.</p></div></dd><dt><span class="term">ROUTE_FILTER</span></dt><dd><p>If this parameter is given the value “<span class="quote">Yes</span>” or
“<span class="quote">yes</span>” then route filtering (anti-spoofing) is enabled
on all network interfaces which are brought up while Shorewall is in
the started state. The default value is “<span class="quote">no</span>”.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="modules"></a>/etc/shorewall/modules Configuration</h2></div></div><div></div></div><p>The file <tt class="filename">/etc/shorewall/modules</tt> contains
commands for loading the kernel modules required by Shorewall-defined
firewall rules. Shorewall will source this file during start/restart
provided that it exists and that the directory specified by the MODULESDIR
parameter exists (see <a href="#Conf">/etc/shorewall/shorewall.conf</a> above).</p><p>The file that is released with Shorewall calls the Shorewall
function “<span class="quote">loadmodule</span>” for the set of modules that I load.</p><p>The <span class="emphasis"><em>loadmodule</em></span> function is called as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">loadmodule &lt;<span class="emphasis"><em>modulename</em></span>&gt; [ &lt;<span class="emphasis"><em>module parameters</em></span>&gt; ]</pre></td></tr></table><p>where</p><div class="variablelist"><dl><dt><span class="term">&lt;<span class="emphasis"><em>modulename</em></span>&gt;</span></dt><dd><p>is the name of the modules without the trailing
“<span class="quote">.o</span>” (example ip_conntrack).</p></dd><dt><span class="term">&lt;<span class="emphasis"><em>module parameters</em></span>&gt;</span></dt><dd><p>Optional parameters to the insmod utility.</p></dd></dl></div><p>The function determines if the module named by &lt;<span class="emphasis"><em>modulename</em></span>&gt;
is already loaded and if not then the function determines if the
“<span class="quote">.o</span>” file corresponding to the module exists in the
<span class="emphasis"><em>&lt;moduledirectory&gt;</em></span>; if so, then the following
command is executed:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em>&lt;moduledirectory</em></span>&gt;/&lt;<span class="emphasis"><em>modulename</em></span>&gt;.o &lt;<span class="emphasis"><em>module parameters</em></span>&gt;</pre></td></tr></table><p>If the file doesn't exist, the function determines of the
“<span class="quote">.o.gz</span>” file corresponding to the module exists in the
<span class="emphasis"><em>moduledirectory</em></span>. If it does, the function assumes
that the running configuration supports compressed modules and execute the
following command:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em>&lt;moduledirectory</em></span>&gt;/&lt;<span class="emphasis"><em>modulename</em></span>&gt;.o.gz &lt;<span class="emphasis"><em>module parameters</em></span>&gt;</pre></td></tr></table><p>Beginning with the 1.4.9 Shorewall release, the value of the
MODULE_SUFFIX option in determines which files the loadmodule function
looks for if the named module doesn't exist. For each file
<span class="emphasis"><em>&lt;extension&gt;</em></span> listed in MODULE_SUFFIX (default
&quot;o gz ko o.gz&quot;), the function will append a period (&quot;.&quot;)
and the extension and if the resulting file exists then the following
command will be executed:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">insmod <span class="emphasis"><em>moduledirectory</em></span>/&lt;<span class="emphasis"><em>modulename</em></span>&gt;.<span class="emphasis"><em>&lt;extension&gt;</em></span> &lt;<span class="emphasis"><em>module parameters</em></span>&gt;</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="TOS"></a>/etc/shorewall/tos Configuration</h2></div></div><div></div></div><p>The <tt class="filename">/etc/shorewall/tos</tt> file allows you to set
the Type of Service field in packet headers based on packet source, packet
destination, protocol, source port and destination port. In order for this
file to be processed by Shorewall, you must have mangle support enabled.</p><p>Entries in the file have the following columns:</p><div class="variablelist"><dl><dt><span class="term">SOURCE</span></dt><dd><p>The source zone. May be qualified by following the zone name
with a colon (“<span class="quote">:</span>”) and either an IP address, an IP
subnet, a MAC address <a href="configuration_file_basics.htm#MAC" target="_self">in
Shorewall Format</a> or the name of an interface. This column
may also contain the name of the firewall zone to indicate packets
originating on the firewall itself or “<span class="quote">all</span>” to indicate
any source.</p></dd><dt><span class="term">DEST</span></dt><dd><p>The destination zone. May be qualified by following the zone
name with a colon (“<span class="quote">:</span>”) and either an IP address or an
IP subnet. Because packets are marked prior to routing, you may not
specify the name of an interface. This column may also contain
“<span class="quote">all</span>” to indicate any destination.</p></dd><dt><span class="term">PROTOCOL</span></dt><dd><p>The name of a protocol in <tt class="filename">/etc/protocols </tt>or
the protocol's number.</p></dd><dt><span class="term">SOURCE PORT(S)</span></dt><dd><p>The source port or a port range. For all ports, place a hyphen
(“<span class="quote">-</span>”) in this column.</p></dd><dt><span class="term">DEST PORT(S)</span></dt><dd><p>The destination port or a port range. To indicate all ports,
place a hyphen (“<span class="quote">-</span>”) in this column.</p></dd><dt><span class="term">TOS</span></dt><dd><p>The type of service. Must be one of the following:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Minimize-Delay (16)</td></tr><tr><td>Maximize-Throughput (8)</td></tr><tr><td>Maximize-Reliability (4)</td></tr><tr><td>Minimize-Cost (2)</td></tr><tr><td>Normal-Service (0)</td></tr></table></dd></dl></div><p><tt class="filename">/etc/shorewall/tos</tt> file that is included with
Shorewall</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST PROTOCOL SOURCE PORTS(S) DEST PORTS(S) TOS
all all tcp - ssh 16
all all tcp ssh - 16
all all tcp - ftp 16
all all tcp ftp - 16
all all tcp - ftp-data 8
all all tcp ftp-data - 8</pre></td></tr></table><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Users have reported that odd routing problems result from adding
the ESP and AH protocols to the <tt class="filename">/etc/shorewall/tos</tt>
file.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Blacklist"></a>/etc/shorewall/blacklist</h2></div></div><div></div></div><p>Each line in <tt class="filename">/etc/shorewall/blacklist</tt> contains
an IP address, a MAC address in Shorewall Format or subnet address.</p><div class="example"><a id="id2880054"></a><p class="title"><b>Example 27. </b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">130.252.100.69
206.124.146.0/24</pre></td></tr></table></div><p>Packets <span class="bold"><b>from</b></span> hosts listed in the
blacklist file will be disposed of according to the value assigned to the
<a href="#Conf" title="/etc/shorewall/shorewall.conf">BLACKLIST_DISPOSITION</a> and <a href="#Conf" title="/etc/shorewall/shorewall.conf">BLACKLIST_LOGLEVEL</a>
variables in /etc/shorewall/shorewall.conf. Only packets arriving on
interfaces that have the “<span class="quote"><a href="#Interfaces" title="/etc/shorewall/interfaces">blacklist</a></span>”
option in <tt class="filename">/etc/shorewall/interfaces</tt> are checked
against the blacklist. The black list is designed to prevent listed
hosts/subnets from accessing services on <span class="bold"><b>your</b></span>
network.</p><p>Beginning with Shorewall 1.3.8, the blacklist file has three
columns:</p><div class="variablelist"><dl><dt><span class="term">ADDRESS/SUBNET</span></dt><dd><p>As described above.</p></dd><dt><span class="term">PROTOCOL</span></dt><dd><p>Optional. If specified, only packets specifying this protocol
will be blocked.</p></dd><dt><span class="term">PORTS</span></dt><dd><p>Optional; may only be given if PROTOCOL is tcp, udp or icmp.
Expressed as a comma-separated list of port numbers or service names
(from /etc/services). If present, only packets destined for the
specified protocol and one of the listed ports are blocked. When the
PROTOCOL is icmp, the PORTS column contains a comma-separated list
of ICMP type numbers or names (see “<span class="quote">iptables -h icmp</span>”).</p></dd></dl></div><p>Shorewall also has a <a href="blacklisting_support.htm" target="_self">dynamic
blacklist capability</a>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>The Shorewall blacklist file is <span class="bold"><b>NOT</b></span>
designed to police your users' web browsing -- to do that, I suggest
that you install and configure <a href="http://www.squid-cache.org" target="_self">Squid</a>
with <a href="http://www.squidguard.org/" target="_self">SquidGuard</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</h2></div></div><div></div></div><p>This file lists the subnets affected by the <a href="#Interfaces" title="/etc/shorewall/interfaces">norfc1918 interface option</a>. Columns in the
file are:</p><div class="variablelist"><dl><dt><span class="term">SUBNET</span></dt><dd><p>The subnet using VLSM notation (e.g., 192.168.0.0/16).</p></dd><dt><span class="term">TARGET</span></dt><dd><p>What to do with packets to/from the SUBNET:</p><div class="variablelist"><dl><dt><span class="term">RETURN</span></dt><dd><p>Process the packet normally thru the rules and policies.</p></dd><dt><span class="term">DROP</span></dt><dd><p>Silently drop the packet.</p></dd><dt><span class="term">logdrop</span></dt><dd><p>Log then drop the packet -- see the <a href="#Conf" title="/etc/shorewall/shorewall.conf">RFC1918_LOG_LEVEL</a>
parameter above.</p></dd></dl></div></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Routestopped"></a>/etc/shorewall/routestopped (Added in Version 1.3.4)</h2></div></div><div></div></div><p>This file defines the hosts that are accessible from the firewall
when the firewall is stopped. Columns in the file are:</p><div class="variablelist"><dl><dt><span class="term">INTERFACE</span></dt><dd><p>The firewall interface through which the host(s) comminicate
with the firewall.</p></dd><dt><span class="term">HOST(S) - (Optional)</span></dt><dd><p>A comma-separated list of IP/Subnet addresses. If not supplied
or supplied as “<span class="quote">-</span>” then 0.0.0.0/0 is assumed.</p></dd></dl></div><div class="example"><a id="id2875076"></a><p class="title"><b>Example 28. When your firewall is stopped, you want firewall accessibility
from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces
through eth1 and your local hosts through eth2.</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE HOST(S)
eth2 192.168.1.0/24
eth1 -</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Maclist"></a>/etc/shorewall/maclist (Added in Version 1.3.10)</h2></div></div><div></div></div><p>This file is described in the <a href="MAC_Validation.html" target="_self">MAC
Validation Documentation</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="ECN"></a>/etc/shorewall/ecn (Added in Version 1.4.0)</h2></div></div><div></div></div><p>This file is described in the <a href="ECN.html" target="_self">ECN Control
Documentation</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Accounting"></a>/etc/shorewall/accounting</h2></div></div><div></div></div><p>This file is described in the <a href="Accounting.html" target="_self">Traffic
Accounting Documentation</a>.</p></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2875179"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.14</td><td align="left">2004-02-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
a note about the order of rules.</td></tr><tr><td align="left">Revision 1.13</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Update
for Shorewall 2.0.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-21</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
masquerade destination list.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-18</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Correct
typo.</td></tr><tr><td align="left">Revision 1.11</td><td align="left">2004-01-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Standards
Compliance</td></tr><tr><td align="left">Revision 1.10</td><td align="left">2004-01-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Improved
formatting of DNAT- and REDIRECT- for clarity</td></tr><tr><td align="left">Revision 1.9</td><td align="left">2003-12-25</td><td align="left">MN</td></tr><tr><td align="left" colspan="3">Initial
Docbook Conversion Complete</td></tr></table></div></div></div></body></html>

35
Shorewall-docs2/Documentation.xml
View File

@ -221,7 +221,7 @@
<term><link linkend="rfc1918">rfc1918</link></term>
<listitem>
<para>a parameter file in <filename class="directory">/etc/shorewall</filename>
<para>a parameter file in <filename class="directory">/usr/share/shorewall</filename>
used to define the treatment of packets under the <link
linkend="Interfaces">norfc1918 interface option</link>.</para>
</listitem>
@ -708,25 +708,12 @@ loc eth1 192.168.1.255,192.168.12.255</programlisting>
purpose of the <filename>/etc/shorewall/hosts</filename> file.</para>
<warning>
<para>The only times that you need entries in <filename>/etc/shorewall/hosts</filename>
are:</para>
<para>The only time that you need entries in <filename>/etc/shorewall/hosts</filename>
is where you have <ulink url="Multiple_Zones.html">more than one zone
connecting through a single interface</ulink>.</para>
<orderedlist>
<listitem>
<para>You have <ulink url="Multiple_Zones.html">more than one zone
connecting through a single interface</ulink>; or</para>
</listitem>
<listitem>
<para>You have a <ulink url="Shorewall_and_Aliased_Interfaces.html">zone
that has multiple subnetworks that connect through a single
interface</ulink> and you want the Shorewall box to route traffic
between those subnetworks.</para>
</listitem>
</orderedlist>
<para><emphasis role="bold">IF YOU DON&#39;T HAVE EITHER OF THOSE
SITUATIONS THEN DON&#39;T TOUCH THIS FILE!!</emphasis></para>
<para><emphasis role="bold">IF YOU DON&#39;T HAVE THIS SITUATION THEN
DON&#39;T TOUCH THIS FILE!!</emphasis></para>
</warning>
<para>Columns in this file are:</para>
@ -2863,7 +2850,8 @@ all all tcp ftp-data - 8</programlisting
</section>
<section id="rfc1918" xreflabel="/etc/shorewall/rfc1918">
<title>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</title>
<title>/etc/shorewall/rfc1918 — Moved to /usr/share/shorewall in Version
2.0.0</title>
<para>This file lists the subnets affected by the <link
linkend="Interfaces">norfc1918 interface option</link>. Columns in the
@ -2913,6 +2901,10 @@ all all tcp ftp-data - 8</programlisting
</listitem>
</varlistentry>
</variablelist>
<para>If you want to modify this file, DO NOT MODIFY <filename>/usr/share/shorewall/rfc1918</filename>.
Rather copy that file to <filename>/etc/shorewall/rfc1918 </filename>and
modify the copy.</para>
</section>
<section id="Routestopped" xreflabel="/etc/shorewall/routestopped">
@ -2976,7 +2968,8 @@ eth1 -</programlisting>
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.14</revnumber><date>2004-02-13</date><authorinitials>TE</authorinitials><revremark>Add
<para><revhistory><revision><revnumber>1.15</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
the rfc1918 file to /usr/share/shorewall.</revremark></revision><revision><revnumber>1.14</revnumber><date>2004-02-13</date><authorinitials>TE</authorinitials><revremark>Add
a note about the order of rules.</revremark></revision><revision><revnumber>1.13</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
for Shorewall 2.0.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-01-21</date><authorinitials>TE</authorinitials><revremark>Add
masquerade destination list.</revremark></revision><revision><revnumber>1.12</revnumber><date>2004-01-18</date><authorinitials>TE</authorinitials><revremark>Correct

640
Shorewall-docs2/FAQ.html
View File

@ -1,640 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Shorewall FAQs</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>Shorewall FAQs</h1></div><div><div class="authorgroup"><h3 class="corpauthor">Shorewall Community</h3><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-03</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807299">Installing Shorewall</a></span></dt><dd><dl><dt><span class="section"><a href="#id2807598">Where do I find Step by Step Installation and Configuration
Instructions?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2807623">Port Forwarding</a></span></dt><dd><dl><dt><span class="section"><a href="#faq1">(FAQ 1) I want to forward UDP port 7777 to my my personal PC with
IP address 192.168.1.5. I've looked everywhere and can't find
how to do it.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq1a">(FAQ 1a) Ok -- I followed those instructions but it doesn't
work</a></span></dt><dt><span class="section"><a href="#faq1b">(FAQ 1b) I'm still having problems with port forwarding</a></span></dt><dt><span class="section"><a href="#faq1c">(FAQ 1c) From the internet, I want to connect to port 1022 on
my firewall and have the firewall forward the connection to port 22 on
local system 192.168.1.3. How do I do that?</a></span></dt></dl></dd><dt><span class="section"><a href="#faq30">(FAQ 30) I'm confused about when to use DNAT rules and when
to use ACCEPT rules.</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859491">DNS and Port Forwarding/NAT</a></span></dt><dd><dl><dt><span class="section"><a href="#faq2">(FAQ 2) I port forward www requests to www.mydomain.com (IP
130.151.100.69) to system 192.168.1.5 in my local network. External
clients can browse http://www.mydomain.com but internal clients
can't.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq2a">(FAQ 2a) I have a zone Z with an RFC1918 subnet
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
Z. Hosts in Z cannot communicate with each other using their external
(non-RFC1918 addresses) so they can't access each other using
their DNS names.</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2859698">Netmeeting/MSN</a></span></dt><dd><dl><dt><span class="section"><a href="#faq3">(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with
Shorewall. What do I do?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859801">Open Ports</a></span></dt><dd><dl><dt><span class="section"><a href="#faq4">(FAQ 4) I just used an online port scanner to check my firewall
and it shows some ports as closed rather than
blocked. Why?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq4a">(FAQ 4a) I just ran an nmap UDP scan of my firewall and it
showed 100s of ports as open!!!!</a></span></dt><dt><span class="section"><a href="#faq4b">(FAQ 4b) I have a port that I can't close no matter how I
change my rules.</a></span></dt><dt><span class="section"><a href="#faq4c">(FAQ 4c) How to I use Shorewall with PortSentry?</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2806601">Connection Problems</a></span></dt><dd><dl><dt><span class="section"><a href="#faq5">(FAQ 5) I've installed Shorewall and now I can't ping
through the firewall</a></span></dt><dt><span class="section"><a href="#faq15">(FAQ 15) My local systems can't see out to the net</a></span></dt><dt><span class="section"><a href="#faq29">(FAQ 29) FTP Doesn't Work</a></span></dt><dt><span class="section"><a href="#id2806829">(FAQ 33) From clients behind the firewall, connections to some
sites fail. Connections to the same sites from the firewall itself work
fine. What's wrong.</a></span></dt></dl></dd><dt><span class="section"><a href="#id2806863">Logging</a></span></dt><dd><dl><dt><span class="section"><a href="#faq6">(FAQ 6) Where are the log messages written and how do I change
the destination?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq6a">(FAQ 6a) Are there any log parsers that work with Shorewall?</a></span></dt><dt><span class="section"><a href="#faq6b">(FAQ 2b) DROP messages on port 10619 are flooding the logs with
their connect requests. Can i exclude these error messages for this
port temporarily from logging in Shorewall?</a></span></dt><dt><span class="section"><a href="#faq6c">(FAQ 6c) All day long I get a steady flow of these DROP
messages from port 53 to some high numbered port. They get dropped,
but what the heck are they?</a></span></dt><dt><span class="section"><a href="#faq6d">(FAQ 6d) Why is the MAC address in Shorewall log messages so
long? I thought MAC addresses were only 6 bytes in length.</a></span></dt></dl></dd><dt><span class="section"><a href="#faq16">(FAQ 16) Shorewall is writing log messages all over my console
making it unusable!</a></span></dt><dt><span class="section"><a href="#faq17">(FAQ 17) What does this log message mean?</a></span></dt><dt><span class="section"><a href="#faq21">(FAQ 21) I see these strange log entries occasionally; what are
they?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2875168">Routing</a></span></dt><dd><dl><dt><span class="section"><a href="#faq32">(FAQ 32) My firewall has two connections to the internet from two
different ISPs. How do I set this up in Shorewall?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2875693">Starting and Stopping</a></span></dt><dd><dl><dt><span class="section"><a href="#faq7">(FAQ 7) When I stop Shorewall using shorewall stop,
I can't connect to anything. Why doesn't that command work?</a></span></dt><dt><span class="section"><a href="#faq8">(FAQ 8) When I try to start Shorewall on RedHat, I get messages
about insmod failing -- what's wrong?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq8a">(FAQ 8a) When I try to start Shorewall on RedHat I get a
message referring me to FAQ #8</a></span></dt></dl></dd><dt><span class="section"><a href="#faq9">(FAQ 9) Why can't Shorewall detect my interfaces properly at
startup?</a></span></dt><dt><span class="section"><a href="#faq22">(FAQ 22) I have some iptables commands that I want to run when
Shorewall starts. Which file do I put them in?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2876004">About Shorewall</a></span></dt><dd><dl><dt><span class="section"><a href="#faq10">(FAQ 10) What Distributions does it work with?</a></span></dt><dt><span class="section"><a href="#faq11">(FAQ 11) What Features does it have?</a></span></dt><dt><span class="section"><a href="#faq12">(FAQ 12) Is there a GUI?</a></span></dt><dt><span class="section"><a href="#faq13">(FAQ 13) Why do you call it Shorewall?</a></span></dt><dt><span class="section"><a href="#faq23">(FAQ 23) Why do you use such ugly fonts on your web site?</a></span></dt><dt><span class="section"><a href="#faq25">(FAQ 25) How to I tell which version of Shorewall I am running?</a></span></dt><dt><span class="section"><a href="#faq31">(FAQ 31) Does Shorewall provide protection against....</a></span></dt><dt><span class="section"><a href="#id2865341">Given that the Debian Stable Release includes Shorewall 1.2.12,
how can you not support that version?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2865362">RFC 1918</a></span></dt><dd><dl><dt><span class="section"><a href="#faq14">(FAQ 14) I'm connected via a cable modem and it has an
internal web server that allows me to configure/monitor it but as
expected if I enable rfc1918 blocking for my eth0 interface (the
internet one), it also blocks the cable modems web server.</a></span></dt><dd><dl><dt><span class="section"><a href="#faq14a">(FAQ 14a) Even though it assigns public IP addresses, my
ISP's DHCP server has an RFC 1918 address. If I enable RFC 1918
filtering on my external interface, my DHCP client cannot renew its
lease.</a></span></dt></dl></dd></dl></dd><dt><span class="section"><a href="#id2865509">Alias IP Addresses/Virtual Interfaces</a></span></dt><dd><dl><dt><span class="section"><a href="#faq18">(FAQ 18) Is there any way to use aliased ip addresses with
Shorewall, and maintain separate rulesets for different IPs?</a></span></dt></dl></dd><dt><span class="section"><a href="#id2865549">Miscellaneous</a></span></dt><dd><dl><dt><span class="section"><a href="#faq19">(FAQ 19) I have added entries to /etc/shorewall/tcrules but they
don't seem to do anything. Why?</a></span></dt><dt><span class="section"><a href="#faq20">(FAQ 20) I have just set up a server. Do I have to change
Shorewall to allow access to my server from the internet?</a></span></dt><dt><span class="section"><a href="#faq24">(FAQ 24) How can I allow conections to let's say the ssh port
only from specific IP Addresses on the internet?</a></span></dt><dt><span class="section"><a href="#faq26">(FAQ 26) When I try to use any of the SYN options in nmap on or
behind the firewall, I get operation not permitted. How
can I use nmap with Shorewall?&quot;</a></span></dt><dd><dl><dt><span class="section"><a href="#faq26a">(FAQ 26a) When I try to use the -O option of
nmap from the firewall system, I get operation not permitted.
How do I allow this option?</a></span></dt></dl></dd><dt><span class="section"><a href="#faq27">(FAQ 27) I'm compiling a new kernel for my firewall. What
should I look out for?</a></span></dt><dd><dl><dt><span class="section"><a href="#faq27a">(FAQ 27a) I just built and installed a new kernel and now
Shorewall won't start. I know that my kernel options are correct.</a></span></dt></dl></dd><dt><span class="section"><a href="#faq28">(FAQ 28) How do I use Shorewall as a Bridging Firewall?</a></span></dt></dl></dd><dt><span class="appendix"><a href="#id2865882">A. Revision History</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807299"></a>Installing Shorewall</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807598"></a>Where do I find Step by Step Installation and Configuration
Instructions?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Check out the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart Guides</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807623"></a>Port Forwarding</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq1"></a>(FAQ 1) I want to forward UDP port 7777 to my my personal PC with
IP address 192.168.1.5. I've looked everywhere and can't find
how to do it.</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> The first example in the
<a href="Documentation.htm#Rules" target="_self">rules file documentation</a>
shows how to do port forwarding under Shorewall. The format of a
port-forwarding rule to a local system is as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:&lt;l<span class="emphasis"><em>ocal IP address</em></span>&gt;[:&lt;<span class="emphasis"><em>local port</em></span>&gt;] &lt;<span class="emphasis"><em>protocol</em></span>&gt; &lt;<span class="emphasis"><em>port #</em></span>&gt;</pre></td></tr></table><p>So to forward UDP port 7777 to internal system 192.168.1.5, the
rule is:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:192.168.1.5 udp 7777</pre></td></tr></table><p>If you want to forward requests directed to a particular address (
<span class="emphasis"><em>&lt;external IP&gt;</em></span> ) on your firewall to an
internal system:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT net loc:&lt;l<span class="emphasis"><em>ocal IP address</em></span>&gt;[:&lt;<span class="emphasis"><em>local port</em></span>&gt;] &lt;<span class="emphasis"><em>protocol</em></span>&gt; &lt;<span class="emphasis"><em>port #</em></span>&gt; - &lt;<span class="emphasis"><em>external IP</em></span>&gt;</pre></td></tr></table><p>Finally, if you need to forward a range of ports, in the PORT
column specify the range as <span class="emphasis"><em>&lt;low-port&gt;:&lt;high-port&gt;</em></span>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1a"></a>(FAQ 1a) Ok -- I followed those instructions but it doesn't
work</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> That is usually the
result of one of four things:</p><div class="itemizedlist"><ul type="disc"><li><p>You are trying to test from inside your firewall (no, that
won't work -- see <a href="#faq2" title="(FAQ 2) I port forward www requests to www.mydomain.com (IP&#10; 130.151.100.69) to system 192.168.1.5 in my local network. External&#10; clients can browse http://www.mydomain.com but internal clients&#10; can't.">the section called “(FAQ 2) I port forward www requests to www.mydomain.com (IP
130.151.100.69) to system 192.168.1.5 in my local network. External
clients can browse http://www.mydomain.com but internal clients
can't.”</a>).</p></li><li><p>You have a more basic problem with your local system (the
one that you are trying to forward to) such as an incorrect
default gateway (it should be set to the IP address of your
firewall's internal interface).</p></li><li><p>Your ISP is blocking that particular port inbound.</p></li><li><p>You are running Mandrake Linux and have configured Internet
Connection Sharing. In that case, the name of your local zone is
'masq' rather than 'loc' (change all instances of
'loc' to 'masq' in your rules). You may want to
consider re-installing Shorewall in a configuration which matches
the Shorewall documentation. See the <a href="two-interface.htm" target="_self">two-interface QuickStart Guide</a> for
details.</p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1b"></a>(FAQ 1b) I'm still having problems with port forwarding</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> To further diagnose
this problem:</p><div class="itemizedlist"><ul type="disc"><li><p>As root, type “<span class="quote"><span><b class="command">iptables -t nat -Z</b></span></span>”.
This clears the NetFilter counters in the nat table.</p></li><li><p>Try to connect to the redirected port from an external host.</p></li><li><p>As root type “<span class="quote"><span><b class="command">shorewall show nat</b></span></span>”</p></li><li><p>Locate the appropriate DNAT rule. It will be in a chain
called <span class="emphasis"><em>&lt;source zone&gt;</em></span>_dnat (“<span class="quote">net_dnat</span>”
in the above examples).</p></li><li><p>Is the packet count in the first column non-zero? If so, the
connection request is reaching the firewall and is being
redirected to the server. In this case, the problem is usually a
missing or incorrect default gateway setting on the local system
(the system you are trying to forward to -- its default gateway
should be the IP address of the firewall's interface to that
system).</p></li><li><p>If the packet count is zero:</p><div class="itemizedlist"><ul type="circle"><li><p>the connection request is not reaching your server
(possibly it is being blocked by your ISP); or</p></li><li><p>you are trying to connect to a secondary IP address on
your firewall and your rule is only redirecting the primary IP
address (You need to specify the secondary IP address in the
“<span class="quote">ORIG. DEST.</span>” column in your DNAT rule); or</p></li><li><p>your DNAT rule doesn't match the connection request
in some other way. In that case, you may have to use a packet
sniffer such as tcpdump or ethereal to further diagnose the
problem.</p></li></ul></div></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq1c"></a>(FAQ 1c) From the internet, I want to connect to port 1022 on
my firewall and have the firewall forward the connection to port 22 on
local system 192.168.1.3. How do I do that?</h4></div></div><div></div></div><p>In /<tt class="filename">etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:192.168.3:22 tcp 1022</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq30"></a>(FAQ 30) I'm confused about when to use DNAT rules and when
to use ACCEPT rules.</h3></div></div><div></div></div><p>It would be a good idea to review the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart Guide</a>
appropriate for your setup; the guides cover this topic in a tutorial
fashion. DNAT rules should be used for connections that need to go the
opposite direction from SNAT/MASQUERADE. So if you masquerade or use
SNAT from your local network to the internet then you will need to use
DNAT rules to allow connections from the internet to your local network.
In all other cases, you use ACCEPT unless you need to hijack connections
as they go through your firewall and handle them on the firewall box
itself; in that case, you use a REDIRECT rule.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859491"></a>DNS and Port Forwarding/NAT</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq2"></a>(FAQ 2) I port forward www requests to www.mydomain.com (IP
130.151.100.69) to system 192.168.1.5 in my local network. External
clients can browse http://www.mydomain.com but internal clients
can't.</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> I have two objections to
this setup.</p><div class="itemizedlist"><ul type="disc"><li><p>Having an internet-accessible server in your local network is
like raising foxes in the corner of your hen house. If the server is
compromised, there's nothing between that server and your other
internal systems. For the cost of another NIC and a cross-over
cable, you can put your server in a DMZ such that it is isolated
from your local systems - assuming that the Server can be located
near the Firewall, of course :-)</p></li><li><p>The accessibility problem is best solved using <a href="shorewall_setup_guide.htm#DNS" target="_self">Bind Version 9 “<span class="quote">views</span>”</a>
(or using a separate DNS server for local clients) such that
www.mydomain.com resolves to 130.141.100.69 externally and
192.168.1.5 internally. That's what I do here at shorewall.net
for my local systems that use one-to-one NAT.</p></li></ul></div><p>If you insist on an IP solution to the accessibility problem
rather than a DNS solution, then assuming that your external interface
is eth0 and your internal interface is eth1 and that eth1 has IP address
192.168.1.254 with subnet 192.168.1.0/24.</p><p>If you are running Shorewall 1.4.0 or earlier see the <a href="1.3/FAQ.htm#faq2" target="_self">1.3 FAQ</a> for instructions suitable for
those releases.</p><p>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
upgrade to Shorewall 1.4.2 or later.</p><p>Otherwise:</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>In this configuration, all loc-&gt;loc
traffic will look to the server as if it came from the firewall rather
than from the original client!</p></div><div class="itemizedlist"><ul type="disc"><li><p>In <tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect <span class="bold"><b>routeback</b></span></pre></td></tr></table></li><li><p>In <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69:192.168.1.254</pre></td></tr></table><p>That rule only works of course if you have a static external
IP address. If you have a dynamic IP address and are running
Shorewall 1.3.4 or later then include this in <tt class="filename">/etc/shorewall/init</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">ETH0_IP=`find_interface_address eth0`</b></span></pre></td></tr></table><p>and make your DNAT rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc loc:192.168.1.5 tcp www - $ETH0_IP:192.168.1.254</pre></td></tr></table><p>Using this technique, you will want to configure your
DHCP/PPPoE client to automatically restart Shorewall each time that
you get a new IP address.</p></li></ul></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq2a"></a>(FAQ 2a) I have a zone “<span class="quote">Z</span>” with an RFC1918 subnet
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
Z. Hosts in Z cannot communicate with each other using their external
(non-RFC1918 addresses) so they can't access each other using
their DNS names.</h4></div></div><div></div></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If the ALL INTERFACES column in /etc/shorewall/nat is empty or
contains “<span class="quote">Yes</span>”, you will also see log messages like the
following when trying to access a host in Z from another host in Z
using the destination hosts's public address:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Oct 4 10:26:40 netgw kernel:
Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0</pre></td></tr></table></div><p><span class="bold"><b>Answer:</b></span> This is another problem
that is best solved using Bind Version 9 “<span class="quote">views</span>”. It
allows both external and internal clients to access a NATed host using
the host's DNS name.</p><p>Another good way to approach this problem is to switch from
one-to-one NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918
addresses and can be accessed externally and internally using the same
address.</p><p>If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p><div class="orderedlist"><ol type="1"><li><p>Set the Z-&gt;Z policy to ACCEPT.</p></li><li><p>Masquerade Z to itself.</p></li><li><p>Set the routeback option on the interface to Z.</p></li><li><p>Set the ALL INTERFACES column in the nat file to
“<span class="quote">Yes</span>”.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>In this configuration, all Z-&gt;Z traffic will look to
the server as if it came from the firewall rather than from the
original client! I DO NOT RECOMMEND THIS SETUP.</p></div></li></ol></div><div class="example"><a id="id2810035"></a><p class="title"><b>Example 1. Example:</b></p><div class="literallayout"><p>Zone: dmz Interface: eth2 Subnet: 192.168.2.0/24</p></div><p>In <tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
loc eth2 192.168.2.255 <span class="bold"><b>routeback</b></span></pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LIMIT:BURST
dmz dmz ACCEPT</pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/masq</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth2 192.168.2.0/24</pre></td></tr></table><p>In <tt class="filename">/etc/shorewall/na</tt>t, be sure that you
have “<span class="quote">Yes</span>” in the ALL INTERFACES column.</p></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859698"></a>Netmeeting/MSN</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq3"></a>(FAQ 3) I want to use Netmeeting or MSN Instant Messenger with
Shorewall. What do I do?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> There is an <a href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/" target="_self">H.323
connection tracking/NAT module</a> that helps with Netmeeting. Note
however that one of the Netfilter developers recently posted the
following:</p><div class="blockquote"><blockquote class="blockquote"><p>&gt; I know PoM -ng is going to address this issue, but till it
is ready, and &gt; all the extras are ported to it, is there any way
to use the h.323 &gt; contrack module kernel patch with a 2.6 kernel?
&gt; Running 2.6.1 - no 2.4 kernel stuff on the system, so downgrade
is not &gt; an option... The module is not ported yet to 2.6, sorry.
&gt; Do I have any options besides a gatekeeper app (does not work in
my &gt; network) or a proxy (would prefer to avoid them)? I suggest
everyone to setup a proxy (gatekeeper) instead: the module is really
dumb and does not deserve to exist at all. It was an excellent tool to
debug/develop the newnat interface.</p></blockquote></div><p>Look <a href="http://linux-igd.sourceforge.net" target="_self">here</a>
for a solution for MSN IM but be aware that there are significant
security risks involved with this solution. Also check the Netfilter
mailing list archives at <a href="http://www.netfilter.org" target="_self">http://www.netfilter.org</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859801"></a>Open Ports</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq4"></a>(FAQ 4) I just used an online port scanner to check my firewall
and it shows some ports as “<span class="quote">closed</span>” rather than
“<span class="quote">blocked</span>”. Why?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> (Shorewall versions prior
to 2.0.0 only). The common.def included with version 1.3.x always
rejects connection requests on TCP port 113 rather than dropping them.
This is necessary to prevent outgoing connection problems to services
that use the “<span class="quote">Auth</span>” mechanism for identifying requesting
users. Shorewall also rejects TCP ports 135, 137, 139 and 445 as well as
UDP ports 137-139. These are ports that are used by Windows (Windows
<span class="emphasis"><em>can</em></span> be configured to use the DCE cell locator on
port 135). Rejecting these connection requests rather than dropping them
cuts down slightly on the amount of Windows chatter on LAN segments
connected to the Firewall.</p><p>If you are seeing port 80 being “<span class="quote">closed</span>”, that's
probably your ISP preventing you from running a web server in violation
of your Service Agreement.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You can change the default behavior of Shorewall through use of
an /etc/shorewall/common file. See the <a href="shorewall_extension_scripts.htm" target="_self">Extension Script Section</a>.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Beginning with Shorewall 1.4.9, Shorewall no longer rejects the
Windows SMB ports (135-139 and 445) by default and silently drops them
instead.</p></div><p><span class="bold"><b>Answer:</b></span> (Shorewall versions 2.0.0
and later). The default Shorewall setup invokes the <span class="bold"><b>Drop</b></span> action prior to enforcing a DROP policy and
the default policy to all zone from the internet is DROP. The Drop
action is defined in <tt class="filename">/etc/shorewall/action.Drop</tt>
which in turn invokes the <span class="bold"><b>RejectAuth</b></span>
action (defined in <tt class="filename">/etc/shorewall/action.RejectAuth</tt>).
This is necessary to prevent outgoing connection problems to services
that use the “<span class="quote">Auth</span>” mechanism for identifying requesting
users. That is the only service which the default setup rejects.</p><p>If you are seeing closed TCP ports other than 113 (auth) then
either you have added rules to REJECT those ports or a router outside of
your firewall is responding to connection requests on those ports.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4a"></a>(FAQ 4a) I just ran an nmap UDP scan of my firewall and it
showed 100s of ports as open!!!!</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Take a deep breath and
read the nmap man page section about UDP scans. If nmap gets <span class="bold"><b>nothing</b></span> back from your firewall then it reports
the port as open. If you want to see which UDP ports are really open,
temporarily change your net-&gt;all policy to REJECT, restart
Shorewall and do the nmap UDP scan again.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4b"></a>(FAQ 4b) I have a port that I can't close no matter how I
change my rules.</h4></div></div><div></div></div><p>I had a rule that allowed telnet from my local network to my
firewall; I removed that rule and restarted Shorewall but my telnet
session still works!!!</p><p><span class="bold"><b>Answer:</b></span> Rules only govern the
establishment of new connections. Once a connection is established
through the firewall it will be usable until disconnected (tcp) or
until it times out (other protocols). If you stop telnet and try to
establish a new session your firerwall will block that attempt.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq4c"></a>(FAQ 4c) How to I use Shorewall with PortSentry?</h4></div></div><div></div></div><p><a href="http://www.shorewall.net/pub/shorewall/contrib/PortsentryHOWTO.txt" target="_self">Here's
a writeup</a> on a nice integration of Shorewall and PortSentry.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806601"></a>Connection Problems</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq5"></a>(FAQ 5) I've installed Shorewall and now I can't ping
through the firewall</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> If you want your firewall
to be totally open for “<span class="quote">ping</span>”,</p><div class="orderedlist"><ol type="1"><li><p>Create <tt class="filename">/etc/shorewall/common</tt> if it
doesn't already exist.</p></li><li><p>Be sure that the first command in the file is “<span class="quote">.
<tt class="filename">/etc/shorewall/common.de</tt>f</span>”</p></li><li><p>Add the following to <tt class="filename">/etc/shorewall/common</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -A icmpdef -p ICMP --icmp-type echo-request -j ACCEPT</b></span></pre></td></tr></table></li></ol></div><p>For a complete description of Shorewall “<span class="quote">ping</span>”
management, see <a href="ping.html" target="_self">this page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq15"></a>(FAQ 15) My local systems can't see out to the net</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Every time I read
“<span class="quote">systems can't see out to the net</span>”, I wonder where the
poster bought computers with eyes and what those computers will
“<span class="quote">see</span>” when things are working properly. That aside, the
most common causes of this problem are:</p><div class="orderedlist"><ol type="1"><li><p>The default gateway on each local system isn't set to the
IP address of the local firewall interface.</p></li><li><p>The entry for the local network in the /etc/shorewall/masq
file is wrong or missing.</p></li><li><p>The DNS settings on the local systems are wrong or the user is
running a DNS server on the firewall and hasn't enabled UDP and
TCP port 53 from the firewall to the internet.</p></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq29"></a>(FAQ 29) FTP Doesn't Work</h3></div></div><div></div></div><p>See the <a href="FTP.html" target="_self">Shorewall and FTP page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2806829"></a>(FAQ 33) From clients behind the firewall, connections to some
sites fail. Connections to the same sites from the firewall itself work
fine. What's wrong.</h3></div></div><div></div></div><p><span class="bold"><b>Answer</b></span>: Most likely, you need to
set CLAMPMSS=Yes in <a href="Documentation.htm#Conf" target="_self">/etc/shorewall/shorewall.conf</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806863"></a>Logging</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq6"></a>(FAQ 6) Where are the log messages written and how do I change
the destination?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> NetFilter uses the
kernel's equivalent of syslog (see “<span class="quote">man syslog</span>”) to log
messages. It always uses the LOG_KERN (kern) facility (see
“<span class="quote">man openlog</span>”) and you get to choose the log level (again,
see “<span class="quote">man syslog</span>”) in your <a href="Documentation.htm#Policy" target="_self">policies</a> and <a href="Documentation.htm#Rules" target="_self">rules</a>. The destination for
messaged logged by syslog is controlled by <tt class="filename">/etc/syslog.conf</tt>
(see “<span class="quote">man syslog.conf</span>”). When you have changed
/etc/syslog.conf, be sure to restart syslogd (on a RedHat system,
“<span class="quote">service syslog restart</span>”).</p><p>By default, older versions of Shorewall ratelimited log messages
through <a href="Documentation.htm#Conf" target="_self">settings</a> in
<tt class="filename">/etc/shorewall/shorewall.conf</tt> -- If you want to log
all messages, set:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGLIMIT=&quot;&quot;
LOGBURST=&quot;&quot;</pre></td></tr></table><p>Beginning with Shorewall version 1.3.12, you can <a href="shorewall_logging.html" target="_self">set up Shorewall to log all of its messages
to a separate file</a>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6a"></a>(FAQ 6a) Are there any log parsers that work with Shorewall?</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Here are several links
that may be helpful:</p><div class="literallayout"><p><a href="http://www.shorewall.net/pub/shorewall/parsefw/" target="_self">http://www.shorewall.net/pub/shorewall/parsefw/</a><br />
<a href="http://www.fireparse.com" target="_self">http://www.fireparse.com</a><br />
<a href="http://cert.uni-stuttgart.de/projects/fwlogwatch" target="_self">http://cert.uni-stuttgart.de/projects/fwlogwatch</a><br />
<a href="http://www.logwatch.org" target="_self">http://www.logwatch.org</a><br />
<a href="http://gege.org/iptables" target="_self">http://gege.org/iptables</a><br />
<a href="http://home.regit.org/ulogd-php.html" target="_self">http://home.regit.org/ulogd-php.html</a></p></div><p>I personnaly use Logwatch. It emails me a report each day from
my various systems with each report summarizing the logged activity on
the corresponding system.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6b"></a>(FAQ 2b) DROP messages on port 10619 are flooding the logs with
their connect requests. Can i exclude these error messages for this
port temporarily from logging in Shorewall?</h4></div></div><div></div></div><p>Temporarily add the following rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">DROP net fw udp 10619</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6c"></a>(FAQ 6c) All day long I get a steady flow of these DROP
messages from port 53 to some high numbered port. They get dropped,
but what the heck are they?</h4></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Jan 8 15:50:48 norcomix kernel:
Shorewall:net2all:DROP:IN=eth0 OUT=
MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00 SRC=208.138.130.16
DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00 TTL=251 ID=8288 DF
PROTO=UDP SPT=53 DPT=40275 LEN=33</pre></td></tr></table><p><span class="bold"><b>Answer:</b></span> There are two
possibilities:</p><div class="orderedlist"><ol type="1"><li><p>They are late-arriving replies to DNS queries.</p></li><li><p>They are corrupted reply packets.</p></li></ol></div><p>You can distinguish the difference by setting the <span class="bold"><b>logunclean</b></span> option (<tt class="filename"><a href="Documentation.htm#Interfaces" target="_self">/etc/shorewall/interfaces</a></tt>)
on your external interface (eth0 in the above example). If they get
logged twice, they are corrupted. I solve this problem by using an
/etc/shorewall/common file like this:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#
# Include the standard common.def file
#
<span><b class="command">. /etc/shorewall/common.def</b></span>
#
# The following rule is non-standard and compensates for tardy
# DNS replies
#
<span><b class="command">run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</b></span></pre></td></tr></table><p>The above file is also include in all of my sample
configurations available in the <a href="shorewall_quickstart_guide.htm" target="_self">Quick Start Guides</a> and in
the common.def file in Shorewall 1.4.0 and later.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq6d"></a>(FAQ 6d) Why is the MAC address in Shorewall log messages so
long? I thought MAC addresses were only 6 bytes in length.</h4></div></div><div></div></div><p>What is labeled as the MAC address in a Shorewall log message is
actually the Ethernet frame header. It contains:</p><div class="itemizedlist"><ul type="disc"><li><p>the destination MAC address (6 bytes)</p></li><li><p>the source MAC address (6 bytes)</p></li><li><p>the ethernet frame type (2 bytes)</p></li></ul></div><div class="example"><a id="id2806108"></a><p class="title"><b>Example 2. Example</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00</pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Destination
MAC address = 00:04:4c:dc:e2:28</p></li><li><p>Source
MAC address = 00:b0:8e:cf:3c:4c</p></li><li><p>Ethernet
Frame Type = 08:00 (IP Version 4)</p></li></ul></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq16"></a>(FAQ 16) Shorewall is writing log messages all over my console
making it unusable!</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> If you are running
Shorewall version 1.4.4 or 1.4.4a then check the <a href="errata.htm" target="_self">errata</a>.
Otherwise:</p><div class="itemizedlist"><ul type="disc"><li><p>Find where klogd is being started (it will be from one of the
files in /etc/init.d -- sysklogd, klogd, ...). Modify that file or
the appropriate configuration file so that klogd is started with
“<span class="quote">-c <span class="emphasis"><em>&lt;n&gt;</em></span></span>” where
<span class="emphasis"><em>&lt;n&gt;</em></span> is a log level of 5 or less; or</p></li><li><p>See the “<span class="quote">dmesg</span>” man page (“<span class="quote">man dmesg</span>”).
You must add a suitable “<span class="quote">dmesg</span>” command to your startup
scripts or place it in /etc/shorewall/start.</p></li></ul></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under RedHat and Mandrake, the max <a href="shorewall_logging.html" target="_self">log level</a> that is sent to the
console is specified in /etc/sysconfig/init in the LOGLEVEL variable.
Set “<span class="quote">LOGLEVEL=5</span>” to suppress info (log level 6) messages
on the console.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under Debian, you can set KLOGD=“<span class="quote">-c 5</span>” in
<tt class="filename">/etc/init.d/klogd</tt> to suppress info (log level 6)
messages on the console.</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>Under SuSE, add “<span class="quote">-c 5</span>” to KLOGD_PARAMS in
/etc/sysconfig/syslog to suppress info (log level 6) messages on the
console.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq17"></a>(FAQ 17) What does this log message mean?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Logging occurs out of a
number of chains (as indicated in the log message) in Shorewall:</p><div class="variablelist"><dl><dt><span class="term">man1918 or logdrop</span></dt><dd><p>The destination address is listed in <tt class="filename">/etc/shorewall/rfc1918</tt>
with a <span class="bold"><b>logdrop</b></span> target -- see
<tt class="filename"><a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a></tt>.</p></dd><dt><span class="term">rfc1918 or logdrop</span></dt><dd><p>The source address is listed in <tt class="filename">/etc/shorewall/rfc1918</tt>
with a <span class="bold"><b>logdrop</b></span> target -- see
<tt class="filename"><a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a></tt>.</p></dd><dt><a id="all2all"></a><span class="term">all2&lt;zone&gt;, &lt;zone&gt;2all or all2all</span></dt><dd><p>You have a <a href="Documentation.htm#Policy" target="_self">policy</a>
that specifies a log level and this packet is being logged under
that policy. If you intend to ACCEPT this traffic then you need a
<a href="Documentation.htm#Rules" target="_self">rule</a> to that effect.</p></dd><dt><span class="term">&lt;zone1&gt;2&lt;zone2&gt;</span></dt><dd><p>Either you have a <a href="Documentation.htm#Policy" target="_self">policy</a>
for <span class="bold"><b>&lt;zone1&gt;</b></span> to <span class="bold"><b>&lt;zone2&gt;</b></span> that specifies a log level
and this packet is being logged under that policy or this packet
matches a <a href="Documentation.htm#Rules" target="_self">rule</a> that
includes a log level.</p></dd><dt><span class="term">&lt;interface&gt;_mac</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>maclist</b></span>
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd><dt><span class="term">logpkt</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>logunclean</b></span>
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd><dt><span class="term">badpkt</span></dt><dd><p>The packet is being logged under the <span class="bold"><b>dropunclean</b></span>
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>
as specified in the <span class="bold"><b>LOGUNCLEAN</b></span>
setting in <a href="Documentation.htm#Conf" target="_self"><tt class="filename">/etc/shorewall/shorewall.conf</tt></a>.</p></dd><dt><span class="term">blacklst</span></dt><dd><p>The packet is being logged because the source IP is
blacklisted in the <tt class="filename"><a href="Documentation.htm#Blacklist" target="_self">/etc/shorewall/blacklist</a></tt>
file.</p></dd><dt><span class="term">newnotsyn</span></dt><dd><p>The packet is being logged because it is a TCP packet that
is not part of any current connection yet it is not a syn packet.
Options affecting the logging of such packets include <span class="bold"><b>NEWNOTSYN</b></span> and <span class="bold"><b>LOGNEWNOTSYN</b></span>
in <a href="Documentation.htm#Conf" target="_self"><tt class="filename">/etc/shorewall/shorewall.conf</tt></a>.</p></dd><dt><span class="term">INPUT or FORWARD</span></dt><dd><p>The packet has a source IP address that isn't in any of
your defined zones (“<span class="quote">shorewall check</span>” and look at the
printed zone definitions) or the chain is FORWARD and the
destination IP isn't in any of your defined zones. Also see
<a href="#faq2a" title="(FAQ 2a) I have a zone Z with an RFC1918 subnet&#10; and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in&#10; Z. Hosts in Z cannot communicate with each other using their external&#10; (non-RFC1918 addresses) so they can't access each other using&#10; their DNS names.">the section called “(FAQ 2a) I have a zone Z with an RFC1918 subnet
and I use one-to-one NAT to assign non-RFC1918 addresses to hosts in
Z. Hosts in Z cannot communicate with each other using their external
(non-RFC1918 addresses) so they can't access each other using
their DNS names.”</a> for another cause of packets being logged
in the FORWARD chain.</p></dd><dt><span class="term">logflags</span></dt><dd><p>The packet is being logged because it failed the checks
implemented by the <span class="bold"><b>tcpflags</b></span>
<a href="Documentation.htm#Interfaces" target="_self">interface option</a>.</p></dd></dl></div><div class="example"><a id="id2874848"></a><p class="title"><b>Example 3. Here is an example:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Jun 27 15:37:56 gateway kernel:
Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2
DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
SPT=1803 DPT=53 LEN=47</pre></td></tr></table><p>Let's look at the important parts of this message:</p><div class="variablelist"><dl><dt><span class="term">all2all:REJECT</span></dt><dd><p>This packet was REJECTed out of the <span class="bold"><b>all2all</b></span>
chain -- the packet was rejected under the “<span class="quote">all</span>”-&gt;“<span class="quote">all</span>”
REJECT policy (<a href="#all2all">all2&lt;zone&gt;, &lt;zone&gt;2all or all2all</a> above).</p></dd><dt><span class="term">IN=eth2</span></dt><dd><p>the packet entered the firewall via eth2. If you see
“<span class="quote">IN=</span>” with no interface name, the packet originated
on the firewall itself.</p></dd><dt><span class="term">OUT=eth1</span></dt><dd><p>if accepted, the packet would be sent on eth1. If you see
“<span class="quote">OUT=</span>” with no interface name, the packet would be
processed by the firewall itself.</p></dd><dt><span class="term">SRC=192.168.2.2</span></dt><dd><p>the packet was sent by 192.168.2.2</p></dd><dt><span class="term">DST=192.168.1.3</span></dt><dd><p>the packet is destined for 192.168.1.3</p></dd><dt><span class="term">PROTO=UDP</span></dt><dd><p>UDP Protocol</p></dd><dt><span class="term">DPT=53</span></dt><dd><p>The destination port is 53 (DNS)</p></dd></dl></div><p>For additional information about the log message, see <a href="http://logi.cc/linux/netfilter-log-format.php3" target="_self">http://logi.cc/linux/netfilter-log-format.php3</a>.</p><p>In this case, 192.168.2.2 was in the “<span class="quote">dmz</span>” zone and
192.168.1.3 is in the “<span class="quote">loc</span>” zone. I was missing the rule:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT dmz loc udp 53</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq21"></a>(FAQ 21) I see these strange log entries occasionally; what are
they?</h3></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Nov 25 18:58:52 linux kernel:
Shorewall:net2all:DROP:IN=eth1 OUT=
MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]</pre></td></tr></table><p>192.0.2.3 is external on my firewall... 172.16.0.0/24 is my
internal LAN</p><p><span class="bold"><b>Answer:</b></span> While most people
associate the Internet Control Message Protocol (ICMP) with
“<span class="quote">ping</span>”, ICMP is a key piece of the internet. ICMP is used
to report problems back to the sender of a packet; this is what is
happening here. Unfortunately, where NAT is involved (including SNAT,
DNAT and Masquerade), there are a lot of broken implementations. That is
what you are seeing with these messages.</p><p>Here is my interpretation of what is happening -- to confirm this
analysis, one would have to have packet sniffers placed a both ends of
the connection.</p><p>Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS
query to 192.0.2.3 and your DNS server tried to send a response (the
response information is in the brackets -- note source port 53 which
marks this as a DNS reply). When the response was returned to to
206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and
forwarded the packet to 172.16.1.10 who no longer had a connection on
UDP port 2857. This causes a port unreachable (type 3, code 3) to be
generated back to 192.0.2.3. As this packet is sent back through
206.124.146.179, that box correctly changes the source address in the
packet to 206.124.146.179 but doesn't reset the DST IP in the
original DNS response similarly. When the ICMP reaches your firewall
(192.0.2.3), your firewall has no record of having sent a DNS reply to
172.16.1.10 so this ICMP doesn't appear to be related to anything
that was sent. The final result is that the packet gets logged and
dropped in the all2all chain. I have also seen cases where the source IP
in the ICMP itself isn't set back to the external IP of the remote
NAT gateway; that causes your firewall to log and drop the packet out of
the rfc1918 chain because the source IP is reserved by RFC 1918.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2875168"></a>Routing</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq32"></a>(FAQ 32) My firewall has two connections to the internet from two
different ISPs. How do I set this up in Shorewall?</h3></div></div><div></div></div><p>Setting this up in Shorewall is easy; setting up the routing is a
bit harder.</p><p>Assuming that <tt class="filename">eth0</tt> and
<tt class="filename">eth1</tt> are the interfaces to the
two ISPs then:</p><p><tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect
net eth1 detect</pre></td></tr></table><p><tt class="filename">/etc/shorewall/policy</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LIMIT:BURST
net net DROP</pre></td></tr></table><p>If you have masqueraded hosts, be sure to update
<tt class="filename">/etc/shorewall/masq</tt> to masquerade to both ISPs. For
example, if you masquerade all hosts connected to <tt class="filename">eth2</tt> then:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0 eth2
eth1 eth2</pre></td></tr></table><p><i class="citetitle">There was an article in SysAdmin covering this topic.
It may be found at <a href="http://www.samag.com/documents/s=1824/sam0201h/" target="_self">http://www.samag.com/documents/s=1824/sam0201h/</a></i></p><p><i class="citetitle">The following information regarding setting up routing
for this configuration is reproduced from the <a href="http://www.lartc.org" target="_self">LARTC HOWTO</a> and has not been verified
by the author. If you have questions or problems with the instructions
given below, please post to the <a href="http://www.lartc.org/#mailinglist" target="_self">LARTC mailing list</a>.</i></p><div class="sidebar"><p>A common configuration is the following, in which there are two
providers that connect a local network (or even a single machine) to
the big Internet.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"> ________
+------------+ /
| | |
+-------------+ Provider 1 +-------
__ | | | /
___/ \_ +------+-------+ +------------+ |
_/ \__ | if1 | /
/ \ | | |
| Local network -----+ Linux router | | Internet
\_ __/ | | |
\__ __/ | if2 | \
\___/ +------+-------+ +------------+ |
| | | \
+-------------+ Provider 2 +-------
| | |
+------------+ \________
</pre></td></tr></table><p>There are usually two questions given this setup.</p><p><span class="bold"><b>Split access</b></span></p><p>The first is how to route answers to packets coming in over a
particular provider, say Provider 1, back out again over that same
provider.</p><p>Let us first set some symbolical names. Let <span class="bold"><b>$IF1</b></span> be the name of the first interface (if1 in
the picture above) and <span class="bold"><b>$IF2</b></span> the name
of the second interface. Then let <span class="bold"><b>$IP1</b></span>
be the IP address associated with <span class="bold"><b>$IF1</b></span>
and <span class="bold"><b>$IP2</b></span> the IP address associated
with <span class="bold"><b>$IF2</b></span>. Next, let <span class="bold"><b>$P1</b></span> be the IP address of the gateway at
Provider 1, and <span class="bold"><b>$P2</b></span> the IP address of
the gateway at provider 2. Finally, let <span class="bold"><b>$P1_NET</b></span>
be the IP network <span class="bold"><b>$P1</b></span> is in, and
<span class="bold"><b>$P2_NET</b></span> the IP network <span class="bold"><b>$P2</b></span> is in.</p><p>One creates two additional routing tables, say <span class="bold"><b>T1</b></span> and <span class="bold"><b>T2</b></span>.
These are added in /etc/iproute2/rt_tables. Then you set up routing in
these tables as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2</pre></td></tr></table><p>Nothing spectacular, just build a route to the gateway and build
a default route via that gateway, as you would do in the case of a
single upstream provider, but put the routes in a separate table per
provider. Note that the network route suffices, as it tells you how to
find any host in that network, which includes the gateway, as
specified above.</p><p>Next you set up the main routing table. It is a good idea to
route things to the direct neighbour through the interface connected
to that neighbour. Note the `src' arguments, they make sure the
right outgoing IP address is chosen.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2</pre></td></tr></table><p>Then, your preference for default route:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add default via $P1</pre></td></tr></table><p>Next, you set up the routing rules. These actually choose what
routing table to route with. You want to make sure that you route out
a given interface if you already have the corresponding source
address:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip rule add from $IP1 table T1
ip rule add from $IP2 table T2</pre></td></tr></table><p>This set of commands makes sure all answers to traffic coming in
on a particular interface get answered from that interface.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>'If $P0_NET is the local network and $IF0 is its
interface, the following additional entries are desirable:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add $P0_NET dev $IF0 table T1
ip route add $P2_NET dev $IF2 table T1
ip route add 127.0.0.0/8 dev lo table T1
ip route add $P0_NET dev $IF0 table T2
ip route add $P1_NET dev $IF1 table T2
ip route add 127.0.0.0/8 dev lo table T2</pre></td></tr></table></div><p>Now, this is just the very basic setup. It will work for all
processes running on the router itself, and for the local network, if
it is masqueraded. If it is not, then you either have IP space from
both providers or you are going to want to masquerade to one of the
two providers. In both cases you will want to add rules selecting
which provider to route out from based on the IP address of the
machine in the local network.</p><p><span class="bold"><b>Load balancing</b></span></p><p>The second question is how to balance traffic going out over the
two providers. This is actually not hard if you already have set up
split access as above.</p><p>Instead of choosing one of the two providers as your default
route, you now set up the default route to be a multipath route. In
the default kernel this will balance routes over the two providers. It
is done as follows (once more building on the example in the section
on split-access):</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1</pre></td></tr></table><p>This will balance the routes over both providers. The <span class="bold"><b>weight</b></span> parameters can be tweaked to favor one
provider over the other.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>balancing will not be perfect, as it is route based, and
routes are cached. This means that routes to often-used sites will
always be over the same provider.</p></div><p>Furthermore, if you really want to do this, you probably also
want to look at Julian Anastasov's patches at <a href="http://www.ssi.bg/%7Eja/#routes" target="_self">http://www.ssi.bg/~ja/#routes</a>
, Julian's route patch page. They will make things nicer to work
with.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2875693"></a>Starting and Stopping</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq7"></a>(FAQ 7) When I stop Shorewall using “<span class="quote">shorewall stop</span>”,
I can't connect to anything. Why doesn't that command work?</h3></div></div><div></div></div><p>The “<span class="quote"><span><b class="command">stop</b></span></span>” command is intended to
place your firewall into a safe state whereby only those hosts listed in
<tt class="filename">/etc/shorewall/routestopped</tt>' are activated. If
you want to totally open up your firewall, you must use the
“<span class="quote"><span><b class="command">shorewall clear</b></span></span>” command.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq8"></a>(FAQ 8) When I try to start Shorewall on RedHat, I get messages
about insmod failing -- what's wrong?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> The output you will see
looks something like this:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.</pre></td></tr></table><p>This problem is usually corrected through the following sequence
of commands</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">service ipchains stop
chkconfig --delete ipchains
rmmod ipchains</pre></td></tr></table><p>Also, be sure to check the <a href="errata.htm" target="_self">errata</a>
for problems concerning the version of iptables (v1.2.3) shipped with
RH7.2.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq8a"></a>(FAQ 8a) When I try to start Shorewall on RedHat I get a
message referring me to FAQ #8</h4></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> This is usually cured
by the sequence of commands shown above in <a href="#faq8" title="(FAQ 8) When I try to start Shorewall on RedHat, I get messages&#10; about insmod failing -- what's wrong?">the section called “(FAQ 8) When I try to start Shorewall on RedHat, I get messages
about insmod failing -- what's wrong?”</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq9"></a>(FAQ 9) Why can't Shorewall detect my interfaces properly at
startup?</h3></div></div><div></div></div><p>I just installed Shorewall and when I issue the start command, I
see the following:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
<span class="bold"><b>Net Zone: eth0:0.0.0.0/0
</b></span><span class="bold"><b>Local Zone: eth1:0.0.0.0/0</b></span>
Deleting user chains...
Creating input Chains...
...</pre></td></tr></table><p>Why can't Shorewall detect my interfaces properly?</p><p><span class="bold"><b>Answer:</b></span> The above output is
perfectly normal. The Net zone is defined as all hosts that are
connected through eth0 and the local zone is defined as all hosts
connected through <tt class="filename">eth1</tt>. If you
are running Shorewall 1.4.10 or later, you can consider setting the
<a href="Documentation.htm#Interfaces" target="_self"><span class="bold"><b>detectnets</b></span>
interface option</a> on your local interface (<tt class="filename">eth1</tt> in the above example). That will
cause Shorewall to restrict the local zone to only those networks routed
through that interface.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq22"></a>(FAQ 22) I have some iptables commands that I want to run when
Shorewall starts. Which file do I put them in?</h3></div></div><div></div></div><p>You can place these commands in one of the <a href="shorewall_extension_scripts.htm" target="_self">Shorewall Extension Scripts</a>.
Be sure that you look at the contents of the chain(s) that you will be
modifying with your commands to be sure that the commands will do what
they are intended. Many iptables commands published in HOWTOs and other
instructional material use the -A command which adds the rules to the
end of the chain. Most chains that Shorewall constructs end with an
unconditional DROP, ACCEPT or REJECT rule and any rules that you add
after that will be ignored. Check “<span class="quote">man iptables</span>” and look
at the -I (--insert) command.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2876004"></a>About Shorewall</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq10"></a>(FAQ 10) What Distributions does it work with?</h3></div></div><div></div></div><p>Shorewall works with any GNU/Linux distribution that includes the
<a href="shorewall_prerequisites.htm" target="_self">proper prerequisites</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq11"></a>(FAQ 11) What Features does it have?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> See the <a href="shorewall_features.htm" target="_self">Shorewall Feature List</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq12"></a>(FAQ 12) Is there a GUI?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Yes. Shorewall support is
included in Webmin 1.060 and later versions. See <a href="http://www.webmin.com" target="_self">http://www.webmin.com</a></p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq13"></a>(FAQ 13) Why do you call it “<span class="quote">Shorewall</span>”?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Shorewall is a
concatenation of “<span class="quote"><span class="emphasis"><em>Shore</em></span>line</span>” (<a href="http://www.cityofshoreline.com" target="_self">the city where I live</a>) and
“<span class="quote">Fire<span class="emphasis"><em>wall</em></span></span>”. The full name of the
product is actually “<span class="quote">Shoreline Firewall</span>” but
“<span class="quote">Shorewall</span>” is must more commonly used.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq23"></a>(FAQ 23) Why do you use such ugly fonts on your web site?</h3></div></div><div></div></div><p>The Shorewall web site is almost font neutral (it doesn't
explicitly specify fonts except on a few pages) so the fonts you see are
largely the default fonts configured in your browser. If you don't
like them then reconfigure your browser.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq25"></a>(FAQ 25) How to I tell which version of Shorewall I am running?</h3></div></div><div></div></div><p>At the shell prompt, type:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">/sbin/shorewall version</b></span></pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq31"></a>(FAQ 31) Does Shorewall provide protection against....</h3></div></div><div></div></div><div class="variablelist"><dl><dt><span class="term">IP Spoofing: Sending packets over the WAN interface using an
internal LAP IP address as the source address?</span></dt><dd><p>Answer: Yes.</p></dd><dt><span class="term">Tear Drop: Sending packets that contain overlapping fragments?</span></dt><dd><p>Answer: This is the responsibility of the IP stack, not the
Netfilter-based firewall since fragment reassembly occurs before
the stateful packet filter ever touches each packet.</p></dd><dt><span class="term">Smurf and Fraggle: Sending packets that use the WAN or LAN
broadcast address as the source address?</span></dt><dd><p>Answer: Shorewall can be configured to do that using the
<a href="blacklisting_support.htm" target="_self">blacklisting</a>
facility.</p></dd><dt><span class="term">Land Attack: Sending packets that use the same address as the
source and destination address?</span></dt><dd><p>Answer: Yes, if the <a href="Documentation.htm#Interfaces" target="_self">routefilter interface option</a>
is selected.</p></dd><dt><span class="term">DOS: - SYN Dos - ICMP Dos - Per-host Dos protection</span></dt><dd><p>Answer: Shorewall has facilities for limiting SYN and ICMP
packets. Netfilter as included in standard Linux kernels
doesn't support per-remote-host limiting except by explicit
rule that specifies the host IP address; that form of limiting is
supported by Shorewall.</p></dd></dl></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2865341"></a>Given that the Debian Stable Release includes Shorewall 1.2.12,
how can you not support that version?</h3></div></div><div></div></div><p>The first release of Shorewall was in March of 2001. Shorewall
1.2.12 was released in May of 2002. It is now the year 2004 and soon
Shorewall 2.0 will be available. Shorewall 1.2.12 is poorly documented
and is missing many of the features that Shorewall users find essential
today.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865362"></a>RFC 1918</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq14"></a>(FAQ 14) I'm connected via a cable modem and it has an
internal web server that allows me to configure/monitor it but as
expected if I enable rfc1918 blocking for my eth0 interface (the
internet one), it also blocks the cable modems web server.</h3></div></div><div></div></div><p>Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1 address of the
modem in/out but still block all other rfc1918 addresses?</p><p><span class="bold"><b>Answer:</b></span> If you are running a
version of Shorewall earlier than 1.3.1, create /etc/shorewall/start and
in it, place the following:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</b></span></pre></td></tr></table><p>If you are running version 1.3.1 or later, simply add the
following to <a href="Documentation.htm#rfc1918" target="_self">/etc/shorewall/rfc1918</a>:</p><p>Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
192.168.100.1 RETURN</pre></td></tr></table><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you add a second IP address to your external firewall
interface to correspond to the modem address, you must also make an
entry in /etc/shorewall/rfc1918 for that address. For example, if you
configure the address 192.168.100.2 on your firewall, then you would
add two entries to /etc/shorewall/rfc1918:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
192.168.100.1 RETURN
192.168.100.2 RETURN</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq14a"></a>(FAQ 14a) Even though it assigns public IP addresses, my
ISP's DHCP server has an RFC 1918 address. If I enable RFC 1918
filtering on my external interface, my DHCP client cannot renew its
lease.</h4></div></div><div></div></div><p>The solution is the same as <a href="#faq14" title="(FAQ 14) I'm connected via a cable modem and it has an&#10; internal web server that allows me to configure/monitor it but as&#10; expected if I enable rfc1918 blocking for my eth0 interface (the&#10; internet one), it also blocks the cable modems web server.">the section called “(FAQ 14) I'm connected via a cable modem and it has an
internal web server that allows me to configure/monitor it but as
expected if I enable rfc1918 blocking for my eth0 interface (the
internet one), it also blocks the cable modems web server.”</a> above.
Simply substitute the IP address of your ISPs DHCP server.</p></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865509"></a>Alias IP Addresses/Virtual Interfaces</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq18"></a>(FAQ 18) Is there any way to use aliased ip addresses with
Shorewall, and maintain separate rulesets for different IPs?</h3></div></div><div></div></div><p><span class="bold"><b>Answer:</b></span> Yes. See <a href="Shorewall_and_Aliased_Interfaces.html" target="_self">Shorewall and Aliased
Interfaces</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865549"></a>Miscellaneous</h2></div></div><div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq19"></a>(FAQ 19) I have added entries to /etc/shorewall/tcrules but they
don't seem to do anything. Why?</h3></div></div><div></div></div><p>You probably haven't set TC_ENABLED=Yes in
/etc/shorewall/shorewall.conf so the contents of the tcrules file are
simply being ignored.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq20"></a>(FAQ 20) I have just set up a server. Do I have to change
Shorewall to allow access to my server from the internet?</h3></div></div><div></div></div><p>Yes. Consult the <a href="shorewall_quickstart_guide.htm" target="_self">QuickStart
guide</a> that you used during your initial setup for information
about how to set up rules for your server.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq24"></a>(FAQ 24) How can I allow conections to let's say the ssh port
only from specific IP Addresses on the internet?</h3></div></div><div></div></div><p>In the SOURCE column of the rule, follow “<span class="quote">net</span>” by a
colon and a list of the host/subnet addresses as a comma-separated list.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">net:&lt;ip1&gt;,&lt;ip2&gt;,...</pre></td></tr></table><div class="example"><a id="id2865645"></a><p class="title"><b>Example 4. Example:</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22</pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq26"></a>(FAQ 26) When I try to use any of the SYN options in nmap on or
behind the firewall, I get “<span class="quote">operation not permitted</span>”. How
can I use nmap with Shorewall?&quot;</h3></div></div><div></div></div><p>Edit /etc/shorewall/shorewall.conf and change “<span class="quote">NEWNOTSYN=No</span>”
to “<span class="quote">NEWNOTSYN=Yes</span>” then restart Shorewall.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq26a"></a>(FAQ 26a) When I try to use the “<span class="quote">-O</span>” option of
nmap from the firewall system, I get “<span class="quote">operation not permitted</span>”.
How do I allow this option?</h4></div></div><div></div></div><p>Add this command to your /etc/shorewall/start file:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP</b></span></pre></td></tr></table></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq27"></a>(FAQ 27) I'm compiling a new kernel for my firewall. What
should I look out for?</h3></div></div><div></div></div><p>First take a look at the <a href="kernel.htm" target="_self">Shorewall kernel
configuration page</a>. You probably also want to be sure that you
have selected the “<span class="quote"><span class="bold"><b>NAT of local connections
(READ HELP)</b></span></span>” on the Netfilter Configuration menu.
Otherwise, DNAT rules with your firewall as the source zone won't
work with your new kernel.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="faq27a"></a>(FAQ 27a) I just built and installed a new kernel and now
Shorewall won't start. I know that my kernel options are correct.</h4></div></div><div></div></div><p>The last few lines of <a href="troubleshoot.htm" target="_self">a startup
trace</a> are these:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">+ run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.
0/0 -j MASQUERADE' ']'
+ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
iptables: Invalid argument
+ '[' -z '' ']'
+ stop_firewall
+ set +x</pre></td></tr></table><p><span class="bold"><b>Answer:</b></span> Your new kernel
contains headers that are incompatible with the ones used to compile
your <span><b class="command">iptables</b></span> utility. You need to rebuild
<span><b class="command">iptables</b></span> using your new kernel source.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="faq28"></a>(FAQ 28) How do I use Shorewall as a Bridging Firewall?</h3></div></div><div></div></div><p>Basically, you don't. While there are kernel patches that
allow you to route bridge traffic through Netfilter, the environment is
so different from the Layer 3 firewalling environment that very little
of Shorewall works. In fact, so much of Shorewall doesn't work that
my official position is that “<span class="quote">Shorewall doesn't work with
Layer 2 Bridging</span>”.</p></div></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2865882"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.17</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
FAQ 33.</td></tr><tr><td align="left">Revision 1.16</td><td align="left">2004-02-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Updated
for Shorewall 2.0.</td></tr><tr><td align="left">Revision 1.15</td><td align="left">2004-01-25</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Updated
FAQ 32 to mention masquerading. Remove tables.</td></tr><tr><td align="left">Revision 1.14</td><td align="left">2004-01-24</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
FAQ 27a regarding kernel/iptables incompatibility.</td></tr><tr><td align="left">Revision 1.13</td><td align="left">2004-01-24</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
a note about the <span class="bold"><b>detectnets</b></span> interface
option in FAQ 9.</td></tr><tr><td align="left">Revision 1.12</td><td align="left">2004-01-20</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Improve
FAQ 16 answer.</td></tr><tr><td align="left">Revision 1.11</td><td align="left">2004-01-14</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
broken link</td></tr><tr><td align="left">Revision 1.10</td><td align="left">2004-01-09</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
a couple of more legacy FAQ numbers.</td></tr><tr><td align="left">Revision 1.9</td><td align="left">2004-01-08</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
typo in FAQ 26a. Added warning to FAQ 2 regarding source address of
redirected requests.</td></tr><tr><td align="left">Revision 1.8</td><td align="left">2003-12-31</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Additions
to FAQ 4.</td></tr><tr><td align="left">Revision 1.7</td><td align="left">2003-12-30</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Remove
dead link from FAQ 1.</td></tr><tr><td align="left">Revision 1.6</td><td align="left">2003.12-18</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
external link reference to FAQ 17.</td></tr><tr><td align="left">Revision 1.5</td><td align="left">2003-12-16</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
a link to a Sys Admin article about multiple internet interfaces. Added
Legal Notice. Moved &quot;abstract&quot; to the body of the document. Moved
Revision History to this Appendix.</td></tr><tr><td align="left">Revision 1.4</td><td align="left">2003-12-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Corrected
formatting problems</td></tr><tr><td align="left">Revision 1.3</td><td align="left">2003-12-10</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Changed
the title of FAQ 17</td></tr><tr><td align="left">Revision 1.2</td><td align="left">2003-12-09</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
Copyright and legacy FAQ numbers</td></tr><tr><td align="left">Revision 1.1</td><td align="left">2003-12-04</td><td align="left">MN</td></tr><tr><td align="left" colspan="3">Converted
to Simplified DocBook XML</td></tr><tr><td align="left">Revision 1.0</td><td align="left">2002-08-13</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Initial
revision</td></tr></table></div></div></div></body></html>

76
Shorewall-docs2/FAQ.xml
View File

@ -17,7 +17,7 @@
</author>
</authorgroup>
<pubdate>2004-02-03</pubdate>
<pubdate>2004-03-05</pubdate>
<copyright>
<year>2001-2004</year>
@ -570,6 +570,19 @@ eth2 192.168.2.0/24</programlisting>
<para><emphasis role="bold">Answer</emphasis>: Most likely, you need to
set CLAMPMSS=Yes in <ulink url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.</para>
</section>
<section id="faq35">
<title>(FAQ 35) I have two Ethernet interfaces to my local network which
I have bridged. When Shorewall is started, I&#39;m unable to pass
traffic through the bridge. I have defined the bridge interface (br0) as
the local interface in /etc/shorewall/interfaces; the bridged Ethernet
interfaces are not defined to Shorewall. How do I tell Shorewall to
allow traffic through the bridge?</title>
<para>Answer: Add the <firstterm>routeback</firstterm> option to
<filename class="devicefile">br0</filename> in <ulink
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
</section>
</section>
<section>
@ -617,7 +630,7 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
<ulink url="http://gege.org/iptables">http://gege.org/iptables</ulink>
<ulink url="http://home.regit.org/ulogd-php.html">http://home.regit.org/ulogd-php.html</ulink></literallayout>
<para>I personnaly use Logwatch. It emails me a report each day from
<para>I personally use Logwatch. It emails me a report each day from
my various systems with each report summarizing the logged activity on
the corresponding system.</para>
</section>
@ -763,9 +776,9 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
<term>man1918 or logdrop</term>
<listitem>
<para>The destination address is listed in <filename>/etc/shorewall/rfc1918</filename>
<para>The destination address is listed in <filename>/usr/share/shorewall/rfc1918</filename>
with a <emphasis role="bold">logdrop</emphasis> target -- see
<filename><ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink></filename>.</para>
<filename><ulink url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>
</listitem>
</varlistentry>
@ -773,9 +786,10 @@ url="http://www.shorewall.net/pub/shorewall/parsefw/">http://www.shorewall.net/p
<term>rfc1918 or logdrop</term>
<listitem>
<para>The source address is listed in <filename>/etc/shorewall/rfc1918</filename>
with a <emphasis role="bold">logdrop</emphasis> target -- see
<filename><ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink></filename>.</para>
<para>The source or destination address is listed in
<filename>/usr/share/shorewall/rfc1918</filename> with a <emphasis
role="bold">logdrop</emphasis> target -- see <filename><ulink
url="Documentation.htm#rfc1918">/usr/share/shorewall/rfc1918</ulink></filename>.</para>
</listitem>
</varlistentry>
@ -1226,9 +1240,9 @@ Perhaps iptables or your kernel needs to be upgraded.</programlisting>
<para>This problem is usually corrected through the following sequence
of commands</para>
<programlisting>service ipchains stop
<programlisting><command>service ipchains stop
chkconfig --delete ipchains
rmmod ipchains</programlisting>
rmmod ipchains</command></programlisting>
<para>Also, be sure to check the <ulink url="errata.htm">errata</ulink>
for problems concerning the version of iptables (v1.2.3) shipped with
@ -1295,6 +1309,16 @@ Creating input Chains...
after that will be ignored. Check <quote>man iptables</quote> and look
at the -I (--insert) command.</para>
</section>
<section id="faq34">
<title>(FAQ 34) How can I speed up start (restart)?</title>
<para>Using a light-weight shell such as <command>ash</command> can
dramatically decrease the time required to <emphasis role="bold">start</emphasis>
or <emphasis role="bold">restart</emphasis> Shorewall. See the
SHOREWALL_SHELL variable in <filename><ulink
url="Documentation.htm#Conf">shorewall.conf</ulink></filename>.</para>
</section>
</section>
<section>
@ -1380,7 +1404,9 @@ Creating input Chains...
<listitem>
<para>Answer: Shorewall can be configured to do that using the
<ulink url="blacklisting_support.htm">blacklisting</ulink>
facility.</para>
facility. Shorewall versions 2.0.0 and later filter these packets
under the <firstterm>nosmurfs</firstterm> interface option in
<ulink url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
</listitem>
</varlistentry>
@ -1414,10 +1440,11 @@ Creating input Chains...
how can you not support that version?</title>
<para>The first release of Shorewall was in March of 2001. Shorewall
1.2.12 was released in May of 2002. It is now the year 2004 and soon
Shorewall 2.0 will be available. Shorewall 1.2.12 is poorly documented
and is missing many of the features that Shorewall users find essential
today.</para>
1.2.12 was released in May of 2002. It is now the year 2004 and
Shorewall 2.0 is available. Shorewall 1.2.12 is poorly documented and is
missing many of the features that Shorewall users find essential today
and it is silly to continue to run it simply because it is bundled with
an ancient Debian release.</para>
</section>
</section>
@ -1440,8 +1467,11 @@ Creating input Chains...
<programlisting><command>run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</command></programlisting>
<para>If you are running version 1.3.1 or later, simply add the
following to <ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink>:</para>
<para>If you are running version 1.3.1 or later, add the following to
<ulink url="Documentation.htm#rfc1918">/etc/shorewall/rfc1918</ulink>
(Note: If you are running Shorewall 2.0.0 or later, you may need to
first copy <filename>/usr/share/shorewall/rfc1918</filename> to
<filename>/etc/shorewall/rfc1918</filename>):</para>
<para>Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.</para>
@ -1583,19 +1613,19 @@ iptables: Invalid argument
<section id="faq28">
<title>(FAQ 28) How do I use Shorewall as a Bridging Firewall?</title>
<para>Basically, you don&#39;t. While there are kernel patches that
allow you to route bridge traffic through Netfilter, the environment is
so different from the Layer 3 firewalling environment that very little
of Shorewall works. In fact, so much of Shorewall doesn&#39;t work that
my official position is that <quote>Shorewall doesn&#39;t work with
Layer 2 Bridging</quote>.</para>
<para>Experimental Shorewall Bridging Firewall support is available —
<ulink url="bridge.html">check here for details</ulink>.</para>
</section>
</section>
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.17</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Added
<para><revhistory><revision><revnumber>1.20</revnumber><date>2004-03-05</date><authorinitials>TE</authorinitials><revremark>Added
Bridging link.</revremark></revision><revision><revnumber>1.20</revnumber><date>2004-02-27</date><authorinitials>TE</authorinitials><revremark>Added
FAQ 35.</revremark></revision><revision><revnumber>1.19</revnumber><date>2004-02-22</date><authorinitials>TE</authorinitials><revremark>Added
mention of nosmurfs option under FAQ 31.</revremark></revision><revision><revnumber>1.18</revnumber><date>2004-02-15</date><authorinitials>TE</authorinitials><revremark>Added
FAQ 34.</revremark></revision><revision><revnumber>1.17</revnumber><date>2004-02-11</date><authorinitials>TE</authorinitials><revremark>Added
FAQ 33.</revremark></revision><revision><revnumber>1.16</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Updated
for Shorewall 2.0.</revremark></revision><revision><revnumber>1.15</revnumber><date>2004-01-25</date><authorinitials>TE</authorinitials><revremark>Updated
FAQ 32 to mention masquerading. Remove tables.</revremark></revision><revision><revnumber>1.14</revnumber><date>2004-01-24</date><authorinitials>TE</authorinitials><revremark>Added

158
Shorewall-docs2/Install.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2003-04-08</pubdate>
<pubdate>2004-03-01</pubdate>
<copyright>
<year>2001</year>
@ -24,6 +24,8 @@
<year>2003</year>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -37,22 +39,15 @@
</legalnotice>
</articleinfo>
<important>
<para>Before upgrading, be sure to review the <ulink
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
</important>
<important>
<para>Before attempting installation, I strongly urge you to read and
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
QuickStart</ulink> Guide for the configuration that most closely matches
your own.</para>
</important>
<section id="Install_RPM">
<title>Install using RPM</title>
<para>To install Shorewall using the RPM:</para>
<important>
<para>Before attempting installation, I strongly urge you to read and
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
QuickStart</ulink> Guide for the configuration that most closely matches
your own.</para>
</important>
<warning>
<para>If you have RedHat 7.2 and are running iptables version 1.2.3 (at
@ -63,18 +58,20 @@
page</ulink> before attempting to start Shorewall.</para>
</warning>
<para>To install Shorewall using the RPM:</para>
<orderedlist>
<listitem>
<para>Install the RPM</para>
<programlisting>rpm -ivh &#60;shorewall rpm&#62;</programlisting>
<programlisting><command>rpm -ivh &#60;shorewall rpm&#62;</command></programlisting>
<note>
<para>Some SuSE users have encountered a problem whereby rpm reports
a conflict with kernel &#60;= 2.2 even though a 2.4 kernel is
installed. If this happens, simply use the --nodeps option to rpm.</para>
<programlisting>rpm -ivh --nodeps &#60;shorewall rpm&#62;</programlisting>
<programlisting><filename><command>rpm -ivh --nodeps &#60;shorewall rpm&#62;</command></filename></programlisting>
</note>
<note>
@ -87,7 +84,7 @@
<para>This may be worked around by using the --nodeps option of rpm.</para>
<programlisting>rpm -ivh --nodeps &#60;shorewall rpm&#62;</programlisting>
<programlisting><command>rpm -ivh --nodeps &#60;shorewall rpm&#62;</command></programlisting>
</note>
</listitem>
@ -109,7 +106,7 @@
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
<programlisting><command>shorewall start</command></programlisting>
</listitem>
</orderedlist>
</section>
@ -117,6 +114,13 @@
<section id="Install_Tarball">
<title>Install using tarball</title>
<important>
<para>Before attempting installation, I strongly urge you to read and
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
QuickStart</ulink> Guide for the configuration that most closely matches
your own.</para>
</important>
<para>To install Shorewall using the tarball and install script:</para>
<orderedlist>
@ -135,33 +139,11 @@
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
url="http://www.corel.com">Corel</ulink>, <ulink
url="http://www.slackware.com/">Slackware</ulink> or <ulink
url="http://www.debian.org">Debian</ulink> then type</para>
url="http://www.suse.com">SuSe</ulink>,<ulink
url="http://www.slackware.com/"> Slackware</ulink> or <ulink
url="http://www.debian.org">Debian/Gentoo</ulink> then type</para>
<programlisting>./install.sh</programlisting>
<orderedlist numeration="loweralpha">
<listitem>
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
then type</para>
<programlisting>./install.sh /etc/init.d</programlisting>
</listitem>
<listitem>
<para>If your distribution has directory /etc/rc.d/init.d or
/etc/init.d then type</para>
<programlisting>./install.sh</programlisting>
</listitem>
<listitem>
<para>For other distributions, determine where your distribution
installs init scripts and type</para>
<programlisting>./install.sh &#60;init script directory&#62;</programlisting>
</listitem>
</orderedlist>
<programlisting><command>./install.sh</command></programlisting>
</listitem>
<listitem>
@ -169,10 +151,16 @@
to match your configuration.</para>
</listitem>
<listitem>
<para>Enable Startup by removing <filename>/etc/shorewall/startup_disabled</filename>
(Debian users will edit <filename>/etc/default/shorewall</filename>
and set startup=1).</para>
</listitem>
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
<programlisting><command>shorewall start</command></programlisting>
</listitem>
<listitem>
@ -186,6 +174,13 @@
<section id="LRP">
<title>Install the .lrp</title>
<important>
<para>Before attempting installation, I strongly urge you to read and
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
QuickStart</ulink> Guide for the configuration that most closely matches
your own.</para>
</important>
<para>To install my version of Shorewall on a fresh Bering disk, simply
replace the <quote>shorwall.lrp</quote> file on the image with the file
that you downloaded. See the <ulink url="two-interface.htm">two-interface
@ -195,6 +190,11 @@
<section id="Upgrade_RPM">
<title>Upgrade using RPM</title>
<important>
<para>Before upgrading, be sure to review the <ulink
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
</important>
<para>If you already have the Shorewall RPM installed and are upgrading to
a new version:</para>
@ -212,24 +212,14 @@
<listitem>
<para>Upgrade the RPM</para>
<programlisting>rpm -Uvh &#60;shorewall rpm file&#62;</programlisting>
<note>
<para>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the <quote>--oldpackage</quote>
option to rpm.</para>
<informalexample>
<programlisting>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</programlisting>
</informalexample>
</note>
<programlisting><command>rpm -Uvh &#60;shorewall rpm file&#62;</command></programlisting>
<note>
<para>Some SuSE users have encountered a problem whereby rpm reports
a conflict with kernel &#60;= 2.2 even though a 2.4 kernel is
installed. If this happens, simply use the --nodeps option to rpm.</para>
<programlisting>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</programlisting>
<programlisting><command>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</command></programlisting>
</note>
<note>
@ -242,7 +232,7 @@
<para>This may be worked around by using the --nodeps option of rpm.</para>
<programlisting>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</programlisting>
<programlisting><command>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</command></programlisting>
</note>
</listitem>
@ -250,13 +240,13 @@
<para>See if there are any incompatibilities between your
configuration and the new Shorewall version and correct as necessary.</para>
<programlisting>shorewall check</programlisting>
<programlisting><command>shorewall check</command></programlisting>
</listitem>
<listitem>
<para>Restart the firewall.</para>
<programlisting>shorewall restart</programlisting>
<programlisting><command>shorewall restart</command></programlisting>
</listitem>
</orderedlist>
</section>
@ -264,6 +254,11 @@
<section id="Upgrade_Tarball">
<title>Upgrade using tarball</title>
<important>
<para>Before upgrading, be sure to review the <ulink
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
</important>
<para>If you already have Shorewall installed and are upgrading to a new
version using the tarball:</para>
@ -281,7 +276,7 @@
<listitem>
<para>unpack the tarball.</para>
<programlisting>tar -zxf shorewall-x.y.z.tgz</programlisting>
<programlisting><command>tar -zxf shorewall-x.y.z.tgz</command></programlisting>
</listitem>
<listitem>
@ -295,46 +290,24 @@
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
url="http://www.corel.com">Corel</ulink>, <ulink
url="http://www.suse.com">SuSe</ulink>, <ulink
url="http://www.slackware.com/">Slackware</ulink> or <ulink
url="http://www.debian.org">Debian</ulink> then type</para>
url="http://www.debian.org">Debian/Gentoo</ulink> then type</para>
<programlisting>./install.sh</programlisting>
<orderedlist numeration="loweralpha">
<listitem>
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
then type</para>
<programlisting>./install.sh /etc/init.d</programlisting>
</listitem>
<listitem>
<para>If your distribution has directory /etc/rc.d/init.d or
/etc/init.d then type</para>
<programlisting>./install.sh</programlisting>
</listitem>
<listitem>
<para>For other distributions, determine where your distribution
installs init scripts and type</para>
<programlisting>./install.sh &#60;init script directory&#62;</programlisting>
</listitem>
</orderedlist>
<programlisting><command>./install.sh</command></programlisting>
</listitem>
<listitem>
<para>See if there are any incompatibilities between your
configuration and the new Shorewall version and correct as necessary.</para>
<programlisting>shorewall check</programlisting>
<programlisting><command>shorewall check</command></programlisting>
</listitem>
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
<programlisting><command>shorewall start</command></programlisting>
</listitem>
<listitem>
@ -348,10 +321,13 @@
<section id="LRP_Upgrade">
<title>Upgrade the .lrp</title>
<para>If you already have a running Bering installation and wish to
upgrade to a later version of Shorewall:</para>
<important>
<para>Before upgrading, be sure to review the <ulink
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
</important>
<remark>UNDER CONSTRUCTION...</remark>
<para>There appears to be no standard method for upgrading LEAF/Bering
packages — Sorry to be so unhelpful.</para>
</section>
<section id="Config_Files">

13
Shorewall-docs2/Introduction.xml
View File

@ -13,7 +13,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-02-03</pubdate>
<pubdate>2004-02-17</pubdate>
<copyright>
<year>2003-2004</year>
@ -141,11 +141,12 @@
file. If no rule in that file matches the connection request then the
first policy in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
that matches the request is applied. If there is a common action defined
for the policy in /etc/shorewall/actions then that action is invoked
before the policy is enforces. In the standard Shorewall distribution, the
DROP policy has a common action called <emphasis role="bold">Drop</emphasis>
and the REJECT policy has a common action called <emphasis role="bold">Reject</emphasis>.
Common actions are used primarily to discard </para>
for the policy in /etc/shorewall/actions (or <filename>/usr/share/shorewall/actions.std</filename>)
then that action is invoked before the policy is enforces. In the standard
Shorewall distribution, the DROP policy has a common action called
<emphasis role="bold">Drop</emphasis> and the REJECT policy has a common
action called <emphasis role="bold">Reject</emphasis>. Common actions are
used primarily to discard</para>
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
file included with the three-interface sample has the following policies:

22
Shorewall-docs2/Multiple_Zones.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-02-07</pubdate>
<pubdate>2004-03-15</pubdate>
<copyright>
<year>2003</year>
@ -304,8 +304,9 @@ loc1 loc NONE</programlisting>
(More on that topic may be found <ulink
url="Shorewall_and_Aliased_Interfaces.html">here</ulink>). Hosts in the
<quote>loc</quote> zone are configured with their default gateway set to
the Shorewall router&#39;s RFC1918 address.<graphic
fileref="images/MultiZone3.png" /></para>
the Shorewall router&#39;s RFC1918 address.</para>
<para><graphic fileref="images/MultiZone3.png" /></para>
<para><filename>/etc/shorewall/zones</filename></para>
@ -324,7 +325,18 @@ net eth0 detect</programlisting>
<para><filename>/etc/shorewall/hosts</filename></para>
<programlisting>#ZONE HOSTS
loc eth0:192.168.1.0/24</programlisting>
<programlisting>#ZONE HOSTS OPTIONS
loc eth0:192.168.1.0/24 maclist</programlisting>
<para><filename><filename>/etc/shorewall/masq</filename></filename></para>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0:!192.168.1.0/24 192.168.1.0/24</programlisting>
<para>Note that the maclist option is specified in <filename>/etc/shorewall/interfaces</filename>.
This is to help protect your router from unauthorized access by your
friends and neighbors. Start without maclist then add it and configure
your <ulink url="MAC_Validation.html"><filename>/etc/shorewall/maclist</filename></ulink>
file when everything else is working.</para>
</section>
</article>

7
Shorewall-docs2/NetfilterOverview.xml
View File

@ -15,11 +15,13 @@
</author>
</authorgroup>
<pubdate>2003-10-14</pubdate>
<pubdate>2004-03-12</pubdate>
<copyright>
<year>2003</year>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -81,6 +83,9 @@
<para><quote>Local Process</quote> means a process running on the
Shorewall system itself.</para>
<para>A more elaborate version of this flow is available <ulink
url="http://shorewall.net/pub/shorewall/misc/netfilterflow.pdf">here</ulink>.</para>
<para>In the above diagram are boxes similar to this:</para>
<graphic fileref="images/Legend.png" />

8
Shorewall-docs2/Shorewall_Doesnt.xml
View File

@ -13,11 +13,13 @@
<surname>Eastep</surname>
</author>
<pubdate>2003-10-07</pubdate>
<pubdate>2004-03-05</pubdate>
<copyright>
<year>2003</year>
<year>2004</year>
<holder>Thomas M Eastep</holder>
</copyright>
@ -36,7 +38,9 @@
<itemizedlist>
<listitem>
<para>Be used to filter traffic through a Layer 2 Bridge</para>
<para>Be used to filter traffic through a Layer 2 Bridge (although
experimental Shorewall Bridge code is available — check <ulink
url="bridge.html">here</ulink> for details).</para>
</listitem>
<listitem>

76
Shorewall-docs2/Shorewall_Squid_Usage.html
View File

@ -1,76 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Using Shorewall with Squid</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="Shorewall_Squid_Usage"></a>Using Shorewall with Squid</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2003-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-04</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807725">Squid as a Transparent Proxy</a></span></dt><dt><span class="section"><a href="#id2807811">Configurations</a></span></dt><dd><dl><dt><span class="section"><a href="#Firewall">Squid (transparent) Running on the Firewall</a></span></dt><dt><span class="section"><a href="#Local">Squid (transparent) Running in the local network</a></span></dt><dt><span class="section"><a href="#DMZ">Squid (transparent) Running in the DMZ</a></span></dt></dl></dd><dt><span class="section"><a href="#id2859624">Squid as a Manual Proxy</a></span></dt></dl></div><p></p><p>This page covers Shorewall configuration to use with <a href="http://www.squid-cache.org" target="_self">Squid</a> running as a Transparent
Proxy or as a Manual Proxy.</p><p>If you are running Shorewall 1.3, please see <a href="1.3/Shorewall_Squid_Usage.html" target="_self">this documentation</a>.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807725"></a>Squid as a Transparent Proxy</h2></div></div><div></div></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>Please observe the following general requirements:</p><div class="itemizedlist"><ul type="disc"><li><p>In all cases, Squid should be configured to run as a transrent
proxy as described at
http://tldp.org/HOWTO/mini/TransparentProxy.html.</p></li><li><p>The following instructions mention the files
/etc/shorewall/start and /etc/shorewall/init -- if you don't
have those files, siimply create them.</p></li><li><p>When the Squid server is in the DMZ zone or in the local zone,
that zone must be defined ONLY by its interface -- no
/etc/shorewall/hosts file entries. That is because the packets being
routed to the Squid server still have their original destination IP
addresses.</p></li><li><p>You must have iptables installed on your Squid server.</p></li><li><p>If you run a Shorewall version earlier than 1.4.6, you must
have NAT and MANGLE enabled in your /etc/shorewall/conf file</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">NAT_ENABLED=Yes
MANGLE_ENABLED=Yes</pre></td></tr></table></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807811"></a>Configurations</h2></div></div><div></div></div><p>Three different configurations are covered:</p><table class="simplelist" border="0" summary="Simple list"><tr><td>Squid (transparent) Running on the Firewall</td></tr><tr><td>Squid (transparent) Running in the local Network</td></tr><tr><td>Squid (transparent) Running in a DMZ</td></tr></table><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Firewall"></a>Squid (transparent) Running on the Firewall</h3></div></div><div></div></div><p>You want to redirect all local www connection requests EXCEPT
those to your own http server (206.124.146.177) to a Squid transparent
proxy running on the firewall and listening on port 3128. Squid will of
course require access to remote web servers.</p><p>In <tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
REDIRECT loc 3228 tcp www - !206.124.146.177
ACCEPT fw net tcp www</pre></td></tr></table><p>There may be a requirement to exclude additional destination hosts
or networks from being redirected. For example, you might also want
requests destined for 130.252.100.0/24 to not be routed to Squid.</p><p>If you are running Shorewall version 1.4.5 or later, you may just
add the additional hosts/networks to the ORIGINAL DEST column in your
REDIRECT rule.</p><p><tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
REDIRECT loc 3228 tcp www - !206.124.146.177,130.252.100.0/24</pre></td></tr></table><p>If you are running a Shorewall version earlier than 1.4.5, you
must add a manual rule in /etc/shorewall/start:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN</b></span></pre></td></tr></table><p>To exclude additional hosts or networks, just add additional
similar rules.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Local"></a>Squid (transparent) Running in the local network</h3></div></div><div></div></div><p>You want to redirect all local www connection requests to a Squid
transparent proxy running in your local zone at 192.168.1.3 and
listening on port 3128. Your local interface is eth1. There may also be
a web server running on 192.168.1.3. It is assumed that web access is
already enabled from the local zone to the internet..</p><div class="orderedlist"><ol type="1"><li><p>* On your firewall system, issue the following command</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</b></span></pre></td></tr></table></li><li><p>In /etc/shorewall/init, put:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">if [ -z &quot;`ip rule list | grep www.out`&quot; ] ; then
ip rule add fwmark 202 table www.out
ip route add default via 192.168.1.3 dev eth1 table www.out
ip route flush cache
echo 0 &gt; /proc/sys/net/ipv4/conf/eth1/send_redirects
fi</b></span></pre></td></tr></table></li><li><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a,
please upgrade to Shorewall 1.4.2 or later.</p></div><p>If you are running Shorewall 1.4.2 or later, then in
<tt class="filename">/etc/shorewall/interfaces</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect <span class="bold"><b>routeback</b></span> </pre></td></tr></table></li><li><p>In /etc/shorewall/rules:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc loc tcp www</pre></td></tr></table><div class="orderedlist"><ol type="a"><li><p>Alternativfely, if you are running Shorewall 1.4.0 you can
have the following policy in place of the above rule.</p><p><tt class="filename">/etc/shorewall/policy</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY
loc loc ACCEPT</pre></td></tr></table></li></ol></div></li><li><p>In <tt class="filename">/etc/shorewall/start</tt> add:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</b></span></pre></td></tr></table></li><li><p>On 192.168.1.3, arrange for the following command to be
executed after networking has come up</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></span></pre></td></tr></table><p>If you are running RedHat on the server, you can simply
execute the following commands after you have typed the iptables
command above:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables-save &gt; /etc/sysconfig/iptables
chkconfig --level 35 iptables on</b></span></pre></td></tr></table></li></ol></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="DMZ"></a>Squid (transparent) Running in the DMZ</h3></div></div><div></div></div><p>You have a single Linux system in your DMZ with IP address
192.0.2.177. You want to run both a web server and Squid on that system.
Your DMZ interface is eth1 and your local interface is eth2.</p><div class="orderedlist"><ol type="1"><li><p>On your firewall system, issue the following command</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</b></span></pre></td></tr></table></li><li><p>In /etc/shorewall/init, put:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">if [ -z &quot;`ip rule list | grep www.out`&quot; ] ; then
ip rule add fwmark 202 table www.out
ip route add default via 192.0.2.177 dev eth1 table www.out
ip route flush cache
fi</b></span></pre></td></tr></table></li><li><p>Do <span class="bold"><b>one</b></span> of the following:</p><div class="orderedlist"><ol type="a"><li><p>In <tt class="filename">/etc/shorewall/start</tt> add</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</b></span></pre></td></tr></table></li><li><p>Set MARK_IN_FORWARD_CHAIN=No in <tt class="filename">/etc/shorewall/shorewall.conf</tt>
and add the following entry in <tt class="filename">/etc/shorewall/tcrules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT
202 eth2 0.0.0.0 tcp 80</pre></td></tr></table></li><li><p>Run Shorewall 1.3.14 or later and add the following entry
in <tt class="filename">/etc/shorewall/tcrules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#MARK SOURCE DESTINATION PROTOCOL PORT
202:P eth2 0.0.0.0 tcp 80</pre></td></tr></table></li></ol></div></li><li><p>In <tt class="filename">/etc/shorewall/rules</tt>, you will need:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc dmz tcp 80
ACCEPT dmz net tcp 80</pre></td></tr></table></li><li><p>On 192.0.2.177 (your Web/Squid server), arrange for the
following command to be executed after networking has come up</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></span></pre></td></tr></table><p>If you are running RedHat on the server, you can simply
execute the following commands after you have typed the iptables
command above:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting"><span><b class="command">iptables-save &gt; /etc/sysconfig/iptables
chkconfig --level 35 iptables on</b></span></pre></td></tr></table></li></ol></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859624"></a>Squid as a Manual Proxy</h2></div></div><div></div></div><p>Assume that Squid is running in zone SZ and listening on port SP;
all web sites that are to be accessed through Squid are in the
“<span class="quote">net</span>” zone. Then for each zone Z that needs access to the
Squid server.</p><p><tt class="filename">/etc/shorewall/rules</tt>:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT Z SZ tcp SP
ACCEPT SZ net tcp 80</pre></td></tr></table><div class="example"><a id="id2809851"></a><p class="title"><b>Example 1. Squid on the firewall listening on port 8080 with access from the
“<span class="quote">loc</span>” zone:</b></p><p><tt class="filename">/etc/shorewall/rules:</tt></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc fw tcp 8080
ACCEPT fw net tcp 80</pre></td></tr></table></div></div></div></body></html>

392
Shorewall-docs2/User_defined_Actions.xml
View File

@ -15,10 +15,12 @@
</author>
</authorgroup>
<pubdate>2004-02-14</pubdate>
<pubdate>2004-03-10</pubdate>
<copyright>
<year>2003-2004</year>
<year>2003</year>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
@ -33,217 +35,267 @@
</legalnotice>
</articleinfo>
<para>Prior to Shorewall version 1.4.9, rules in <filename>/etc/shorewall/rules</filename>
were limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
Beginning with Shorewall version 1.4.9, users may use sequences of these
elementary operations to define more complex actions.</para>
<section>
<title>Creating a New Action</title>
<para>To define a new action:</para>
<para>Prior to Shorewall version 1.4.9, rules in <filename>/etc/shorewall/rules</filename>
were limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
Beginning with Shorewall version 1.4.9, users may use sequences of these
elementary operations to define more complex actions.</para>
<orderedlist>
<listitem>
<para>Add a line to <filename><filename>/etc/shorewall/actions</filename></filename>
that names your new action. Action names must be valid shell variable
names as well as valid Netfilter chain names. It is recommended that the
name you select for a new action begins with with a capital letter; that
way, the name won&#39;t conflict with a Shorewall-defined chain name.</para>
<para>To define a new action:</para>
<para>Beginning with Shorewall-2.0.0-Beta1, the name of the action may
be optionally followed by a colon (<quote>:</quote>) and ACCEPT, DROP or
REJECT. When this is done, the named action will become the
<emphasis>common action </emphasis>for policies of type ACCEPT, DROP or
REJECT respectively. The common action is applied immediately before the
policy is enforced (before any logging is done under that policy) and is
used mainly to suppress logging of uninteresting traffic which would
otherwise clog your logs. The same policy name can appear in multiple
actions; the last such action for each policy name is the one which
Shorewall will use.</para>
<orderedlist>
<listitem>
<para>Add a line to <filename><filename>/etc/shorewall/actions</filename></filename>
that names your new action. Action names must be valid shell variable
names as well as valid Netfilter chain names. It is recommended that
the name you select for a new action begins with with a capital
letter; that way, the name won&#39;t conflict with a Shorewall-defined
chain name.</para>
<para>Shorewall includes pre-defined actions for DROP and REJECT -- see
below.</para>
</listitem>
<para>Beginning with Shorewall-2.0.0-Beta1, the name of the action may
be optionally followed by a colon (<quote>:</quote>) and ACCEPT, DROP
or REJECT. When this is done, the named action will become the
<emphasis>common action </emphasis>for policies of type ACCEPT, DROP
or REJECT respectively. The common action is applied immediately
before the policy is enforced (before any logging is done under that
policy) and is used mainly to suppress logging of uninteresting
traffic which would otherwise clog your logs. The same policy name can
appear in multiple actions; the last such action for each policy name
is the one which Shorewall will use.</para>
<listitem>
<para>Once you have defined your new action name (ActionName), then copy
/usr/share/shorewall/action.template to <filename>/etc/shorewall/action.ActionName</filename>
(for example, if your new action name is <quote>Foo</quote> then copy
<filename>/usr/share/shorewall/action.template</filename> to
<filename>/etc/shorewall/action.Foo</filename>).</para>
</listitem>
<para>Shorewall includes pre-defined actions for DROP and REJECT --
see below.</para>
</listitem>
<listitem>
<para>Now modify the new file to define the new action.</para>
</listitem>
</orderedlist>
<listitem>
<para>Once you have defined your new action name (ActionName), then
copy /usr/share/shorewall/action.template to <filename>/etc/shorewall/action.ActionName</filename>
(for example, if your new action name is <quote>Foo</quote> then copy
<filename>/usr/share/shorewall/action.template</filename> to
<filename>/etc/shorewall/action.Foo</filename>).</para>
</listitem>
<para>Columns in the action.template file are as follows:</para>
<listitem>
<para>Now modify the new file to define the new action.</para>
</listitem>
</orderedlist>
<itemizedlist>
<listitem>
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, QUEUE or &#60;<emphasis>action</emphasis>&#62;
where &#60;<emphasis>action</emphasis>&#62; is a previously-defined
action (that is, it must precede the action being defined in this file
in your <filename>/etc/shorewall/actions</filename> file). The TARGET
may optionally be followed by a colon (<quote>:</quote>) and a syslog
log level (e.g, REJECT:info or ACCEPT:debugging). This causes the packet
to be logged at the specified level. You may also specify ULOG (must be
in upper case) as a log level.This will log to the ULOG target for
routing to a separate log through use of ulogd (<ulink
url="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</ulink>).</para>
</listitem>
<para>Columns in the action.template file are as follows:</para>
<listitem>
<para>SOURCE - Source hosts to which the rule applies. A comma-separated
list of subnets and/or hosts. Hosts may be specified by IP or MAC
address; mac addresses must begin with <quote>~</quote> and must use
<quote>-</quote> as a separator.</para>
<itemizedlist>
<listitem>
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, CONTINUE, QUEUE or
&#60;<emphasis>action</emphasis>&#62; where &#60;<emphasis>action</emphasis>&#62;
is a previously-defined action (that is, it must precede the action
being defined in this file in your <filename>/etc/shorewall/actions</filename>
file). These actions have the same meaning as they do in the
<filename>/etc/shorewall/rules</filename> file (CONTINUE terminates
processing of the current action and returns to the point where that
action was invoked). The TARGET may optionally be followed by a colon
(<quote>:</quote>) and a syslog log level (e.g, REJECT:info or
ACCEPT:debugging). This causes the packet to be logged at the
specified level. You may also specify ULOG (must be in upper case) as
a log level.This will log to the ULOG target for routing to a separate
log through use of ulogd (<ulink
url="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</ulink>).</para>
</listitem>
<para>Alternatively, clients may be specified by interface name. For
example, eth1 specifies a client that communicates with the firewall
system through eth1. This may be optionally followed by another colon (<quote>:</quote>)
and an IP/MAC/subnet address as described above (e.g.,
eth1:192.168.1.5).</para>
</listitem>
<listitem>
<para>SOURCE - Source hosts to which the rule applies. A
comma-separated list of subnets and/or hosts. Hosts may be specified
by IP or MAC address; mac addresses must begin with <quote>~</quote>
and must use <quote>-</quote> as a separator.</para>
<listitem>
<para>DEST - Location of Server. Same as above with the exception that
MAC addresses are not allowed.</para>
<para>Alternatively, clients may be specified by interface name. For
example, eth1 specifies a client that communicates with the firewall
system through eth1. This may be optionally followed by another colon
(<quote>:</quote>) and an IP/MAC/subnet address as described above
(e.g., eth1:192.168.1.5).</para>
</listitem>
<para>Unlike in the SOURCE column, you may specify a range of up to 256
IP addresses using the syntax &#60;<emphasis>first ip</emphasis>&#62;-&#60;<emphasis>last
ip</emphasis>&#62;.</para>
</listitem>
<listitem>
<para>DEST - Location of Server. Same as above with the exception that
MAC addresses are not allowed.</para>
<listitem>
<para>PROTO - Protocol - Must be <quote>tcp</quote>, <quote>udp</quote>,
<quote>icmp</quote>, a number, or <quote>all</quote>.</para>
</listitem>
<para>Unlike in the SOURCE column, you may specify a range of up to
256 IP addresses using the syntax &#60;<emphasis>first ip</emphasis>&#62;-&#60;<emphasis>last
ip</emphasis>&#62;.</para>
</listitem>
<listitem>
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
names (from <filename>/etc/services</filename>), port numbers or port
ranges; if the protocol is <quote>icmp</quote>, this column is
interpreted as the destination icmp-type(s).</para>
<listitem>
<para>PROTO - Protocol - Must be <quote>tcp</quote>, <quote>udp</quote>,
<quote>icmp</quote>, a number, or <quote>all</quote>.</para>
</listitem>
<para>A port range is expressed as &#60;<emphasis>low port</emphasis>&#62;:&#60;<emphasis>high
port</emphasis>&#62;.</para>
<listitem>
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
names (from <filename>/etc/services</filename>), port numbers or port
ranges; if the protocol is <quote>icmp</quote>, this column is
interpreted as the destination icmp-type(s).</para>
<para>This column is ignored if PROTOCOL = all but must be entered if
any of the following ields are supplied. In that case, it is suggested
that this field contain <quote>-</quote>.</para>
<para>A port range is expressed as &#60;<emphasis>low port</emphasis>&#62;:&#60;<emphasis>high
port</emphasis>&#62;.</para>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the
CLIENT PORT(S) list below:</para>
<para>This column is ignored if PROTOCOL = all but must be entered if
any of the following ields are supplied. In that case, it is suggested
that this field contain <quote>-</quote>.</para>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the
CLIENT PORT(S) list below:</para>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<listitem>
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
source port is acceptable. Specified as a comma-separated list of port
names, port numbers or port ranges.</para>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<para>If you don&#39;t want to restrict client ports but need to specify
an ADDRESS in the next column, then place &#34;-&#34; in this column.</para>
<listitem>
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
source port is acceptable. Specified as a comma-separated list of port
names, port numbers or port ranges.</para>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the DEST
PORT(S) list above:</para>
<para>If you don&#39;t want to restrict client ports but need to
specify an ADDRESS in the next column, then place &#34;-&#34; in this
column.</para>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the
DEST PORT(S) list above:</para>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<listitem>
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
this column:</para>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<para><programlisting> &#60;<emphasis>rate</emphasis>&#62;/&#60;<emphasis>interval</emphasis>&#62;[:&#60;<emphasis>burst</emphasis>&#62;]</programlisting>where
&#60;<emphasis>rate</emphasis>&#62; is the number of connections per
&#60;<emphasis>interval</emphasis>&#62; (<quote>sec</quote> or
<quote>min</quote>) and &#60;<emphasis>burst</emphasis>&#62; is the
largest burst permitted. If no &#60;<emphasis>burst</emphasis>&#62; is
given, a value of 5 is assumed. There may be no whitespace embedded in
the specification.</para>
<listitem>
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
this column:</para>
<para><programlisting> Example: 10/sec:20</programlisting></para>
</listitem>
<para><programlisting> &#60;<emphasis>rate</emphasis>&#62;/&#60;<emphasis>interval</emphasis>&#62;[:&#60;<emphasis>burst</emphasis>&#62;]</programlisting>where
&#60;<emphasis>rate</emphasis>&#62; is the number of connections per
&#60;<emphasis>interval</emphasis>&#62; (<quote>sec</quote> or
<quote>min</quote>) and &#60;<emphasis>burst</emphasis>&#62; is the
largest burst permitted. If no &#60;<emphasis>burst</emphasis>&#62; is
given, a value of 5 is assumed. There may be no whitespace embedded in
the specification.</para>
<listitem>
<para>USER/GROUP - For output rules (those with the firewall as their
source), you may control connections based on the effective UID and/or
GID of the process requesting the connection. This column can contain
any of the following:</para>
<para><programlisting> Example: 10/sec:20</programlisting></para>
</listitem>
<simplelist>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;[:]</member>
<listitem>
<para>USER/GROUP - For output rules (those with the firewall as their
source), you may control connections based on the effective UID and/or
GID of the process requesting the connection. This column can contain
any of the following:</para>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;[:]</member>
<simplelist>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;[:]</member>
<member>[!]:&#60;<emphasis>group number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;[:]</member>
<member>[!]:&#60;<emphasis>group name</emphasis>&#62;</member>
<member>[!]:&#60;<emphasis>group number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]:&#60;<emphasis>group name</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user inumber</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
</simplelist>
</listitem>
</itemizedlist>
<member>[!]&#60;<emphasis>user inumber</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
<para>Example:</para>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
</simplelist>
</listitem>
</itemizedlist>
<para><filename>/etc/shorewall/actions</filename>:</para>
<para>Example:</para>
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
<para><filename>/etc/shorewall/actions</filename>:</para>
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
ACCEPT</programlisting></para>
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
defined actions. These defined actions are listed in <filename>/usr/share/shorewall/actions.std</filename>.</para>
<para>To use your action, in <filename>/etc/shorewall/rules</filename> you
might do something like:</para>
<para>The <filename>/usr/share/shorewall/actions.std</filename> file
includes the common actions <quote>Drop</quote> for DROP policies and
<quote>Reject</quote> for REJECT policies.</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
LogAndAccept loc fw tcp 22</programlisting>
</section>
<para><filename>/usr/share/shorewall/actions.std</filename> is processed
before <filename>/etc/shorewall/actions</filename> and if you have any
actions defined with the same name as one in <filename>/usr/share/shorewall/actions.std</filename>,
your version in <filename class="directory">/etc/shorewall</filename> will
be the one used. So if you wish to modify a standard action, simply copy the
associated action file from <filename class="directory">/usr/share/shorewall
</filename>to <filename class="directory">/etc/shorewall and modify</filename>
it to suit your needs. The next <command>shorewall restart</command> will
cause your action to be installed in place of the standard one. In
particular, if you want to modify the common actions <quote>Drop</quote> or
<quote>Reject</quote>, simply copy <filename>action.Drop</filename> or
<filename>Action.Reject</filename> to <filename class="directory">/etc/shorewall</filename>
and modify that copy as desired.</para>
<section>
<title>Standard Actions In Shorewall 2.0</title>
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
defined actions. These defined actions are listed in <filename>/usr/share/shorewall/actions.std</filename>.</para>
<para>The <filename>/usr/share/shorewall/actions.std</filename> file
includes the common actions <quote>Drop</quote> for DROP policies and
<quote>Reject</quote> for REJECT policies.</para>
<example>
<title>Example of Using a Standard Action</title>
<para>Suppose that you wish to enable ftp from your local network to
your firewall. In <filename>/etc/shorewall/rules</filename>:</para>
<programlisting>#ACTION SOURCE DEST PROTO ...
AllowFTP loc fw</programlisting>
</example>
<para><filename>/usr/share/shorewall/actions.std</filename> is processed
before <filename>/etc/shorewall/actions</filename> and if you have any
actions defined with the same name as one in <filename>/usr/share/shorewall/actions.std</filename>,
your version in <filename class="directory">/etc/shorewall</filename> will
be the one used. So if you wish to modify a standard action, simply copy
the associated action file from <filename class="directory">/usr/share/shorewall
</filename>to <filename class="directory">/etc/shorewall and modify</filename>
it to suit your needs. The next <command>shorewall restart</command> will
cause your action to be installed in place of the standard one. In
particular, if you want to modify the common actions <quote>Drop</quote>
or <quote>Reject</quote>, simply copy <filename>action.Drop</filename> or
<filename>Action.Reject</filename> to <filename class="directory">/etc/shorewall</filename>
and modify that copy as desired.</para>
</section>
<section>
<title>Creating an Action using an Extension Script</title>
<para>There may be cases where you wish to create a chain with rules that
can&#39;t be constructed using the tools defined in the action.template.
In that case, you can use an extension script.<note><para>If you actually
need an action to drop broadcast packets, use the <command>dropBcast</command>
standard action rather than create one like this.</para></note></para>
<example>
<title>An action to drop all broadcast packets</title>
<para>/etc/shorewall/actions<programlisting>DropBcasts</programlisting></para>
<para>/etc/shorewall/action.DropBcasts<programlisting># This file is empty</programlisting></para>
<para>/etc/shorewall/DropBcasts<programlisting>run_iptables -A DropBcasts -m pkttype --pkttype broadcast -j DROP</programlisting></para>
</example>
</section>
</article>

16
Shorewall-docs2/blacklisting_support.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-01-17</pubdate>
<pubdate>2004-02-17</pubdate>
<copyright>
<year>2002-2004</year>
@ -57,7 +57,19 @@
</listitem>
</orderedlist>
<para>Only the source address is checked against the blacklists.</para>
<important>
<para><emphasis role="bold">Only the source address is checked against
the blacklists</emphasis>. Blacklists only stop blacklisted hosts from
connecting to you — they do not stop you or your users from connecting
to blacklisted hosts .</para>
</important>
<important>
<para><emphasis role="bold">Neither form of Shorewall blacklisting is
appropriate for blacklisting 1,000s of different addresses</emphasis>.
The blacklists will take forever to load and will have a very negative
effect on firewall performance.</para>
</important>
</section>
<section>

283
Shorewall-docs2/bridge.xml Executable file
View File

@ -0,0 +1,283 @@
<?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$-->
<articleinfo>
<title>Shorewall and Bridged Firewalls</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-03-06</pubdate>
<copyright>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Background</title>
<para>Systems where Shorewall runs normally function as
<firstterm>routers</firstterm>. In the context of the Open System
Interconnect (OSI) reference model, a router operates at layer 3.
Beginning with Shorewall version 2.0.1, Shorewall may also be deployed on
a GNU Linux System that acts as a <firstterm>bridge</firstterm>. Bridges
are layer-2 devices in the OSI model (think of a bridge as an ethernet
switch).</para>
<para>Some differences between routers and bridges are:</para>
<orderedlist>
<listitem>
<para>Routers determine packet destination based on the destination IP
address while bridges route traffic based on the destination MAC
address in the ethernet frame.</para>
</listitem>
<listitem>
<para>As a consequence of the first difference, routers can be
connected to more than one IP network while a bridge may be part of
only a single network.</para>
</listitem>
<listitem>
<para>A router cannot forward broadcast packets while a bridge can.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Requirements</title>
<para>In order to use Shorewall with a bridging firewall, your kernel must
meet the following requirements:</para>
<itemizedlist>
<listitem>
<para>It must contain bridge support (CONFIG_BRIDGE=m or
CONFIG_BRIDGE=y).</para>
</listitem>
<listitem>
<para>It must contain Netfilter physdev match support
(CONFIG_IP_NF_MATCH_PHYSDEV=m or CONFIG_IP_NF_MATCH_PHYSDEV=y).
Physdev match is available in the 2.6 kernel series but must be
patched into the 2.4 kernels (see <ulink url="http://bridge.sf.net">http://bridge.sf.net</ulink>).</para>
</listitem>
<listitem>
<para>Your iptables must contain physdev match support. iptables 1.2.9
and later contain this support.</para>
</listitem>
<listitem>
<para>You must have the bridge utilities (bridge-utils) package
installed.</para>
</listitem>
</itemizedlist>
<para>You must also be running Shorewall 2.0.1 or later (users running
Shorewall 2.0.0-RC* or Shorewall-2.0.0 may find the necessary updated
files at <ulink url="http://shorewall.net/pub/shorewall/Bridging">http://shorewall.net/pub/shorewall/Bridging</ulink>).</para>
</section>
<section>
<title>Application</title>
<para>The following diagram shows a typical application of a
bridge/firewall. There is already an existing router in place whose
internal interface supports a network and you want to insert a firewall
between the router and the systems in the local network. In the example
shown, the network uses RFC 1918 addresses but that is not a requirement;
the bridge would work exactly the same if public IP addresses were used
(remember that the bridge doesn&#39;t deal with IP addresses).</para>
<graphic fileref="images/bridge.png" />
<para>There are a several key differences in this setup and a normal
Shorewall configuration:</para>
<itemizedlist>
<listitem>
<para>The Shorewall system (the Bridge/Firewall) has only a single IP
address even though it has two ethernet interfaces! The IP address is
configured on the bridge itself rather than on either of the network
cards.</para>
</listitem>
<listitem>
<para>The systems connected to the LAN are configured with the
router&#39;s IP address (192.168.1.254 in the above diagram) as their
default gateway.</para>
</listitem>
<listitem>
<para><command>traceroute</command> doesn&#39;t detect the
Bridge/Firewall as an intermediate router.</para>
</listitem>
<listitem>
<para>If the router runs a DHCP server, the hosts connected to the LAN
can use that server without having <command>dhcrelay</command> running
on the Bridge/Firewall.</para>
</listitem>
</itemizedlist>
<para>There are other possibilities here -- there could be a hub or switch
between the router and the Bridge/Firewall and there could be other
systems connected to that switch. All of the systems on the local side of
the router would still be configured with IP addresses in 192.168.1.0/24.</para>
</section>
<section>
<title>Configuring the Bridge</title>
<para>Configuring the bridge itself is quite simple and used the
<command>brctl</command> utility from the bridge-utils package. Bridge
configuration information may be found at <ulink
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
<para>Unfortunately, Linux distributions don&#39;t have good bridge
configuration tools and the network configuration GUIs don&#39;t detect
the presence of bridge devices. You may refer to <ulink
url="http://shorewall.net/2.0/myfiles.htm">my configuration files</ulink>
for an example of configuring a bridge at system boot under
<trademark>SuSE</trademark>. Here is an excerpt from a Debian
<filename>/etc/network/interfaces</filename> file for a bridge:</para>
<programlisting>auto br0
iface br0 inet static
address 192.168.1.253
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /sbin/ip link set eth0 up
pre-up /sbin/ip link set eth1 up
pre-up /usr/sbin/brctl addbr br0
pre-up /usr/sbin/brctl addif br0 eth0
pre-up /usr/sbin/brctl addif br0 eth1
gateway:/etc/network#</programlisting>
<para>While it is not a requirement to give the bridge an IP address,
doing so allows the bridge/firewall to access other systems and allows the
bridge/firewall to be managed remotely. I have not tested Shorewall with a
bridge configured without an IP address so if you try it and it
doesn&#39;t work do not be surprised.</para>
</section>
<section>
<title>Configuring Shorewall</title>
<para>Bridging in Shorewall is enabled using the BRIDGING option in
<filename>/etc/shorewall/shorewall.conf</filename>:</para>
<programlisting>BRIDGING=Yes</programlisting>
<para>In the scenario pictured above, there would probably be two zones
defined -- one for the internet and one for the local LAN so in
<filename>/etc/shorewall/zones</filename>:</para>
<programlisting>#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
<para>A conventional two-zone policy file is appropriate here —
<filename>/etc/shorewall/policy</filename>:</para>
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT info
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
<para>Only the bridge device itself is configured with an IP address so
only that device is defined to Shorewall in <filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
- br0 192.168.1.255
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para>The zones are defined using the <filename>/etc/shorewall/hosts</filename>
file. Assuming that the router is connected to <filename
class="devicefile">eth0</filename> and the switch to <filename
class="devicefile">eth1</filename>:</para>
<programlisting>#ZONE HOST(S) OPTIONS
net br0:eth0
loc br0:eth1
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</programlisting>
<para>When Shorewall is stopped, you want to allow only local traffic
through the bridge — <filename><filename>/etc/shorewall/routestopped</filename></filename>:</para>
<programlisting>#INTERFACE HOST(S) OPTIONS
br0 192.168.1.0/24 routeback
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
<para>The <filename>/etc/shorewall/rules</filename> file from the
two-interface sample is a good place to start for defining a set of
firewall rules.</para>
</section>
<section>
<title>Combination Router/Bridge</title>
<para>A system running Shorewall doesn&#39;t have to be exclusively a
bridge or a router -- it can act as both. Here&#39;s an example:<graphic
fileref="images/bridge2.png" /></para>
<para>This is basically the same setup as shown in the <ulink
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink> with the
exception that the DMZ is bridged rather than using Proxy ARP. Changes in
the configuration shown in the Setup Guide are as follows:</para>
<orderedlist>
<listitem>
<para>The <filename>/etc/shorewall/proxyarp</filename> file is empty
in this confiiguration.</para>
</listitem>
<listitem>
<para>The <filename>/etc/shorewall/interfaces</filename> file is as
follows:<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
- br0 detect rfc1918,routefilter
loc eth1 detect</programlisting></para>
</listitem>
<listitem>
<para>The <filename>/etc/shorewall/hosts</filename> file would have:</para>
<programlisting>#ZONE HOSTS OPTIONS
net br0:eth0
dmz br0:eth2</programlisting>
</listitem>
</orderedlist>
</section>
<section>
<title>Limitations</title>
<para>Bridging doesn&#39; t work with some wireless cards — see <ulink
url="http://bridge.sf.net">http://bridge.sf.net</ulink>.</para>
</section>
</article>

17
Shorewall-docs2/configuration_file_basics.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-02-15</pubdate>
<pubdate>2004-02-20</pubdate>
<copyright>
<year>2001-2004</year>
@ -80,9 +80,8 @@
- define IP traffic accounting rules</para></listitem><listitem><para><filename>/etc/shorewall/actions</filename>
and <filename>/usr/share/shorewall/action.template</filename> - define
your own actions for rules in /etc/shorewall/rules (shorewall 1.4.9 and
later).</para></listitem><listitem><para><filename>/etc/shorewall/actions.std</filename>
- Actions defined by Shorewall. Included using the <link linkend="INCLUDE">INCLUDE
command</link> by <filename>/etc/shorewall/actions</filename>.</para></listitem><listitem><para><filename>/etc/shorewall/actions.*</filename>
later).</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.std</filename>
- Actions defined by Shorewall.</para></listitem><listitem><para><filename>/usr/share/shorewall/actions.*</filename>
- Details of actions defined by Shorewall.</para></listitem></itemizedlist></para>
</section>
@ -121,9 +120,9 @@ smtp,www,pop3,imap #Services running on the firewall</programlisting>
<para>Beginning with Shorewall version 1.4.2, any file may contain INCLUDE
directives. An INCLUDE directive consists of the word INCLUDE followed by
a file name and causes the contents of the named file to be logically
included into the file containing the INCLUDE. File names given in an
INCLUDE directive are assumed to reside in /etc/shorewall or in an
a path name and causes the contents of the named file to be logically
included into the file containing the INCLUDE. Relative path names given
in an INCLUDE directive are assumed to reside in /etc/shorewall or in an
alternate configuration directory if one has been specified for the
command.</para>
@ -385,7 +384,7 @@ DNAT net loc:192.168.1.3 tcp 4000:4100</programlisting>
numbers separated by colons.</para>
<example>
<title>MAC Address of a NIC</title>
<title>MAC Address of an Ethernet Controller</title>
<programlisting> &#x00A0;&#x00A0;&#x00A0;&#x00A0; [root@gateway root]# <command>ifconfig eth0</command>
&#x00A0;&#x00A0;&#x00A0;&#x00A0; eth0 Link encap:Ethernet HWaddr <emphasis
@ -404,7 +403,7 @@ role="bold">02:00:08:E3:FA:55</emphasis>
Shorewall requires MAC addresses to be written in another way. In
Shorewall, MAC addresses begin with a tilde (<quote>~</quote>) and consist
of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in
the example above would be written <quote>~02-00-08-E3-FA-55</quote>.</para>
the example above would be written <emphasis role="bold">~02-00-08-E3-FA-55</emphasis>.</para>
<note>
<para>It is not necessary to use the special Shorewall notation in the

12
Shorewall-docs2/errata.xml
View File

@ -13,7 +13,7 @@
</author>
</authorgroup>
<pubdate>2004-02-03</pubdate>
<pubdate>2004-03-15</pubdate>
<copyright>
<year>2001-2004</year>
@ -74,11 +74,17 @@
<title>Problems in Version 2.0</title>
<section>
<title>Shorewall 2.0.0-Beta 1</title>
<title>Shorewall 2.0.0</title>
<itemizedlist>
<listitem>
<para></para>
<para>When using an Action in the ACTIONS column of a rule, you may
receive a warning message about the rule being a policy. While this
warning may be safely ignored, it can be eliminated by installing
<ulink
url="http://shorewall.net/pub/shorewall/errata/2.0.0/firewall">this
corrected firewall script</ulink> in /usr/share/shorewall as
described above.</para>
</listitem>
</itemizedlist>
</section>

BIN
Shorewall-docs2/images/bridge.png Executable file
View File

Binary file not shown.

36671
Shorewall-docs2/images/bridge.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/bridge2.png Executable file
View File

Binary file not shown.

53411
Shorewall-docs2/images/bridge2.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/network.png
View File

Binary file not shown.

4093
Shorewall-docs2/images/network.vdx
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/network1.png Executable file
View File

Binary file not shown.

71311
Shorewall-docs2/images/network1.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

457
Shorewall-docs2/myfiles.html
View File

@ -1,457 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>About My Network</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>About My Network</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-13</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2815839">My Current Network</a></span></dt><dd><dl><dt><span class="section"><a href="#id2805857">Shorewall.conf</a></span></dt><dt><span class="section"><a href="#id2805874">Params File (Edited)</a></span></dt><dt><span class="section"><a href="#id2805900">Zones File</a></span></dt><dt><span class="section"><a href="#id2807778">Interfaces File</a></span></dt><dt><span class="section"><a href="#id2807811">Hosts File</a></span></dt><dt><span class="section"><a href="#id2807838">Routestopped File</a></span></dt><dt><span class="section"><a href="#RFC1918">RFC1918 File</a></span></dt><dt><span class="section"><a href="#id2810254">Blacklist File (Partial)</a></span></dt><dt><span class="section"><a href="#id2810278">Policy File</a></span></dt><dt><span class="section"><a href="#id2810297">Masq File</a></span></dt><dt><span class="section"><a href="#id2809846">NAT File</a></span></dt><dt><span class="section"><a href="#ProxyARP">Proxy ARP File</a></span></dt><dt><span class="section"><a href="#id2809906">Tunnels File (Shell variable TEXAS set in /etc/shorewall/params)</a></span></dt><dt><span class="section"><a href="#Actions">Actions File</a></span></dt><dt><span class="section"><a href="#id2809963">action.Mirrors File</a></span></dt><dt><span class="section"><a href="#id2809999">action.MyDrop</a></span></dt><dt><span class="section"><a href="#id2810040">action.MyReject</a></span></dt><dt><span class="section"><a href="#id2810089">Rules File (The shell variables are set in /etc/shorewall/params)</a></span></dt><dt><span class="section"><a href="#id2810110">/etc/network/interfaces</a></span></dt><dt><span class="section"><a href="#Dhcpd">/etc/dhcpd.conf (MAC Addresses Omitted)</a></span></dt></dl></dd></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2815839"></a>My Current Network</h2></div></div><div></div></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>I use a combination of One-to-one NAT and Proxy ARP, neither of
which are relevant to a simple configuration with a single public IP
address. If you have just a single public IP address, most of what you
see here won't apply to your setup so beware of copying parts of
this configuration and expecting them to work for you. What you copy may
or may not work in your configuration.</p></div><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>The configuration shown here corresponds to Shorewall version
2.0.0-Beta1. It may use features not available in earlier Shorewall
releases.</p></div><p>I have DSL service and have 5 static IP addresses
(206.124.146.176-180). My DSL “<span class="quote">modem</span>” (Fujitsu Speedport) is
connected to eth0. I have a local network connected to eth2 (subnet
192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a
Wireless network connected to eth3 (192.168.3.0/24). Note that the IP
address of eth1 is a duplicate of one on eth0.</p><p>I use:</p><div class="itemizedlist"><ul type="disc"><li><p>One-to-one NAT for Ursa (my personal system that dual-boots
Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5 and
external address 206.124.146.178.</p></li><li><p>One-to-one NAT for EastepLaptop (My work system -- Windows XP
SP2). Internal address 192.168.1.7 and external address
206.124.146.180.</p></li><li><p>SNAT through 206.124.146.179 for  my SuSE 9.0 Linux
system (Wookie), my Wife's Windows XP system (Tarry), and
our  Windows XP laptop (Tipper) which connects through the
Wireless Access Point (wap) via a Wireless Bridge (bridge).</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>While
the distance between the WAP and where I usually use the laptop
isn't very far (25 feet or so), using a WAC11 (CardBus wireless
card) has proved very unsatisfactory (lots of lost connections). By
replacing the WAC11 with the WET11 wireless bridge, I have virtually
eliminated these problems (Being an old radio tinkerer (K7JPV), I was
also able to eliminate the disconnects by hanging a piece of aluminum
foil on the family room wall. Needless to say, my wife Tarry rejected
that as a permanent solution :-).</p></div></li></ul></div><p>The firewall runs on a 256MB PII/233 with Debian Sarge (Testing).</p><p>Wookie, Ursa and the Firewall all run Samba and the Firewall acts as
a WINS server.</p><p>The wireless network connects to eth3 via a LinkSys WAP11. 
In additional to using the rather weak WEP 40-bit encryption (64-bit with
the 24-bit preamble), I use <a href="MAC_Validation.html" target="_self">MAC
verification</a>. This is still a weak combination and if I lived near
a wireless “<span class="quote">hot spot</span>”, I would probably add IPSEC or
something similar to my WiFi-&gt;local connections.</p><p>The single system in the DMZ (address 206.124.146.177) runs postfix,
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
server (Pure-ftpd) under RedHat 9.0. The system also runs fetchmail to
fetch our email from our old and current ISPs. That server is managed
through Proxy ARP.</p><p>The firewall system itself runs a DHCP server that serves the local
network.</p><p>All administration and publishing is done using ssh/scp. I have a
desktop environment installed on the firewall but I am not usually logged
in to it. X applications tunnel through SSH to Ursa. The server also has a
desktop environment installed and that desktop environment is available
via XDMCP from the local zone. For the most part though, X tunneled
through SSH is used for server administration and the server runs at run
level 3 (multi-user console mode on RedHat).</p><p>I run an SNMP server on my firewall to serve <a href="http://www.ee.ethz.ch/~oetiker/webtools/mrtg/" target="_self">MRTG</a> running
in the DMZ.</p><div align="center"><img src="images/network.png" align="middle" /></div><p>The
ethernet interface in the Server is configured with IP address
206.124.146.177, netmask 255.255.255.0. The server's default gateway
is 206.124.146.254 (Router at my ISP. This is the same default gateway
used by the firewall itself). On the firewall, an entry in my
/etc/network/interfaces file (see below) adds a host route to
206.124.146.177 through eth1 when that interface is brought up.</p><p>Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for
Road Warrior access.</p><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805857"></a>Shorewall.conf</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">LOGFILE=/var/log/messages
LOGRATE=
LOGBURST=
LOGUNCLEAN=$LOG
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=$LOG
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
RFC1918_LOG_LEVEL=$LOG
SMURF_LOG_LEVEL=
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SHOREWALL_SHELL=/bin/ash
SUBSYSLOCK= #I run Debian which doesn't use service locks
STATEDIR=/var/state/shorewall
MODULESDIR=
FW=fw
IP_FORWARDING=On
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=Yes
TC_ENABLED=Yes
CLEAR_TC=No
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=Yes
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
BLACKLISTNEWONLY=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805874"></a>Params File (Edited)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">MIRRORS=&lt;list of shorewall mirror ip addresses&gt;
NTPSERVERS=&lt;list of the NTP servers I sync with&gt;
TEXAS=&lt;ip address of gateway in Dallas&gt;
LOG=info</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2805900"></a>Zones File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE DISPLAY COMMENTS
net Internet Internet
WiFi Wireless Wireless Network on eth3
dmz DMZ Demilitarized zone
loc Local Local networks
tx Texas Peer Network in Dallas
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807778"></a>Interfaces File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is set up so that I can start the firewall before bringing
up my Ethernet interfaces.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE INERFACE BROADCAST OPTIONS
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags,nosmurfs
loc eth2 192.168.1.255 dhcp,detectnets
dmz eth1 -
WiFi eth3 192.168.3.255 dhcp,maclist,detectnets
- texas 192.168.9.255
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807811"></a>Hosts File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ZONE HOST(S) OPTIONS
tx              texas:192.168.8.0/22
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807838"></a>Routestopped File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE HOST(S)
eth1 206.124.146.177
eth2 -
eth3 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="RFC1918"></a>RFC1918 File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>I use a stripped-down file which doesn't have to be updated
when the IANA allocates a block of IP addresses.</p></blockquote></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SUBNET TARGET
169.254.0.0/16 DROP # DHCP autoconfig
172.16.0.0/12 logdrop # RFC 1918
192.0.2.0/24 logdrop # Example addresses
192.168.0.0/16 logdrop # RFC 1918
10.24.60.56 DROP # Some idiot in my broadcast domain
# has a box configured with this
# address.
10.0.0.0/8 logdrop # Reserved (RFC 1918)</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810254"></a>Blacklist File (Partial)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS/SUBNET PROTOCOL PORT
0.0.0.0/0 udp 1434
0.0.0.0/0 tcp 1433
0.0.0.0/0 tcp 8081
0.0.0.0/0 tcp 57
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810278"></a>Policy File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DESTINATION POLICY LOG LEVEL BURST:LIMIT
fw fw ACCEPT # For testing fw-&gt;fw rules
loc net ACCEPT # Allow all net traffic from local net
$FW loc ACCEPT # Allow local access from the firewall
$FW tx ACCEPT # Allow firewall access to texas
loc tx ACCEPT # Allow local net access to texas
loc fw REJECT $LOG # Reject loc-&gt;fw and log
WiFi net ACCEPT # Allow internet access from wirless
net all DROP $LOG 10/sec:40 # Rate limit and
# DROP net-&gt;all
all all REJECT $LOG # Reject and log the rest
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810297"></a>Masq File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>Although most of our internal systems use one-to-one NAT, my
wife's system (192.168.1.4) uses IP Masquerading (actually SNAT)
as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
visitors with laptops.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#INTERFACE SUBNET ADDRESS
eth0:2 eth2 206.124.146.179
eth0 eth3 206.124.146.179
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809846"></a>NAT File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0:0 192.168.1.5 No No
206.124.146.180 eth0:1 192.168.1.7 No No
#
# The following entry allows the server to be accessed through an address in
# the local network. This is convenient when I'm on the road and connected
# to the PPTP server. By doing this, I don't need to set my client's default
# gateway to route through the tunnel.
#
192.168.1.193 eth2:0 206.124.146.177 No No
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="ProxyARP"></a>Proxy ARP File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
206.124.146.177 eth1 eth0 Yes
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809906"></a>Tunnels File (Shell variable TEXAS set in /etc/shorewall/params)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TYPE ZONE GATEWAY GATEWAY ZONE PORT
gre net $TEXAS
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Actions"></a>Actions File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION
DropSMB #Silently Drops Microsoft SMB Traffic
RejectSMB #Silently Reject Microsoft SMB Traffic
DropUPnP #Silently Drop UPnP Probes
RejectAuth #Silently Reject Auth
DropPing #Silently Drop Ping
DropDNSrep #Silently Drop DNS Replies
AllowPing #Accept Ping
Mirrors #Accept traffic from the Shorewall Mirror sites
MyDrop:DROP #My DROP common action
MyReject:REJECT #My REJECT common action
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809963"></a>action.Mirrors File</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>The $MIRRORS variable expands to a list of approximately 10 IP
addresses. So moving these checks into a separate chain reduces the
number of rules that most net-&gt;dmz traffic needs to traverse.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
ACCEPT $MIRRORS
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2809999"></a>action.MyDrop</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is my common action for the DROP policy. It is like the
standard <span class="bold"><b>Reject</b></span> action except that it
allows “<span class="quote">Ping</span>”.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT(S) PORT(S) LIMIT GROUP
RejectAuth
AllowPing
dropBcast
DropSMB
DropUPnP
dropNonSyn
DropDNSrep</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810040"></a>action.MyReject</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This is my common action for the REJECT policy. It is like the
standard <span class="bold"><b>Drop</b></span> action except that it
allows “<span class="quote">Ping</span>”.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#TARGET SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT(S) PORT(S) LIMIT GROUP
RejectAuth
AllowPing
dropBcast
RejectSMB
DropUPnP
dropNonSyn
DropDNSrep
DROP loc:eth2:!192.168.1.0/24 #So that my braindead Windows[tm] XP system doesn't flood my log
#with NTP requests with a source address in 16.0.0.0/8 (address of
#its PPTP tunnel to HP).</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810089"></a>Rules File (The shell variables are set in /etc/shorewall/params)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">###############################################################################################################################################################################
#RESULT CLIENT(S) SERVER(S) PROTO PORT(S) CLIENT ORIGINAL RATE USER
# PORT(S) DEST:SNAT SET
###############################################################################################################################################################################
# Local Network to Internet - Reject attempts by Trojans to call home
#
REJECT:$LOG loc net tcp 6667
#
# Stop NETBIOS crap since our policy is ACCEPT
#
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
#
DROP loc:!192.168.1.0/24 net
QUEUE loc net udp
QUEUE loc fw udp
QUEUE loc net tcp
###############################################################################################################################################################################
# Local Network to Firewall
#
DROP loc:!192.168.1.0/24 fw
ACCEPT loc fw tcp ssh,time,10000,swat,137,139,445
ACCEPT loc fw udp snmp,ntp,445
ACCEPT loc fw udp 137:139
ACCEPT loc fw udp 1024: 137
###############################################################################################################################################################################
# Local Network to DMZ
#
DROP loc:!192.168.1.0/24 dmz
REJECT loc dmz tcp 465
ACCEPT loc dmz udp domain,xdmcp
ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,10027,pop3 -
###############################################################################################################################################################################
# Internet to DMZ
#
DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179,206.124.146.178
ACCEPT net dmz tcp smtp,www,ftp,imaps,domain,cvspserver,https -
ACCEPT net dmz udp domain
ACCEPT net dmz udp 33434:33436
Mirrors net dmz tcp rsync
#ACCEPT:$LOG net dmz tcp 32768:61000 20
###############################################################################################################################################################################
#
# Net to Local
#
# When I'm &quot;on the road&quot;, the following two rules allow me VPN access back home.
#
ACCEPT net loc:192.168.1.5 tcp 1723
ACCEPT net loc:192.168.1.5 gre
#
# ICQ
#
ACCEPT net loc:192.168.1.5 tcp 4000:4100
#
# Real Audio
#
ACCEPT net loc:192.168.1.5 udp 6970:7170
#
# Overnet
#
#ACCEPT net loc:192.168.1.5 tcp 4662
#ACCEPT net loc:192.168.1.5 udp 12112
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
ACCEPT dmz net udp domain
ACCEPT dmz net:$POPSERVERS tcp pop3
#ACCEPT dmz net:206.191.151.2 tcp pop3
#ACCEPT dmz net:66.216.26.115 tcp pop3
#
# Something is wrong with the FTP connection tracking code or there is some client out there
# that is sending a PORT command which that code doesn't understand. Either way,
# the following works around the problem.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# DMZ to Firewall -- ntp &amp; snmp, Silently reject Auth
#
ACCEPT dmz fw udp ntp ntp
ACCEPT dmz fw tcp snmp,ssh
ACCEPT dmz fw udp snmp
REJECT dmz fw tcp auth
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
ACCEPT dmz net udp domain
ACCEPT dmz net:$POPSERVERS tcp pop3
#ACCEPT dmz net:206.191.151.2 tcp pop3
#ACCEPT dmz net:66.216.26.115 tcp pop3
#
# Something is wrong with the FTP connection tracking code or there is some client out there
# that is sending a PORT command which that code doesn't understand. Either way,
# the following works around the problem.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# DMZ to Firewall -- ntp &amp; snmp, Silently reject Auth
#
ACCEPT dmz fw udp ntp ntp
ACCEPT dmz fw tcp snmp,ssh
ACCEPT dmz fw udp snmp
REJECT dmz fw tcp auth
###############################################################################################################################################################################
#
# DMZ to Local Network
#
ACCEPT dmz loc tcp smtp,6001:6010
ACCEPT dmz loc tcp 111
ACCEPT dmz loc udp
###############################################################################################################################################################################
# Internet to Firewall
#
REJECT net fw tcp www
ACCEPT net dmz udp 33434:33435
###############################################################################################################################################################################
# WIFI to Firewall
#
ACCEPT WiFi fw tcp ssh,137,139,445
ACCEPT WiFi fw udp 137:139,445
ACCEPT WiFi fw udp 1024: 137
ACCEPT WiFi fw udp ntp ntp
###############################################################################################################################################################################
# Firewall to WIFI
#
ACCEPT fw WiFi tcp 137,139,445
ACCEPT fw WiFi udp 137:139,445
ACCEPT fw WiFi udp 1024: 137
ACCEPT fw WiFi udp ntp ntp
##############################################################################################################################################################################
# WIFI to DMZ
#
DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193
ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh,8080 -
ACCEPT WiFi dmz udp domain
##############################################################################################################################################################################
# WIFI to loc
#
ACCEPT WiFi loc udp 137:139
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
ACCEPT WiFi loc udp 1024: 137
ACCEPT WiFi loc udp 177
##############################################################################################################################################################################
# loc to WiFi
#
ACCEPT loc WiFi udp 137:139
ACCEPT loc WiFi tcp 137,139,445
ACCEPT loc WiFi udp 1024: 137
ACCEPT loc WiFi tcp 6000:6010
###############################################################################################################################################################################
# Firewall to Internet
#
ACCEPT fw net:$NTPSERVERS udp ntp ntp
#ACCEPT fw net:$POPSERVERS tcp pop3
ACCEPT fw net udp domain
ACCEPT fw net tcp domain,www,https,ssh,1723,whois,1863,ftp,2702,2703,7
ACCEPT fw net udp 33435:33535
ACCEPT fw net icmp
###############################################################################################################################################################################
# Firewall to DMZ
#
ACCEPT fw dmz tcp www,ftp,ssh,smtp
ACCEPT fw dmz udp domain
REJECT fw dmz udp 137:139
###############################################################################################################################################################################
# Ping
#
ACCEPT all all icmp 8
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810110"></a>/etc/network/interfaces</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>This file is Debian specific. My additional entry (which is
displayed in <span class="bold"><b>bold type</b></span>) adds a route
to my DMZ server when eth1 is brought up. It allows me to enter
“<span class="quote">Yes</span>” in the HAVEROUTE column of <a href="#ProxyARP" title="Proxy ARP File">my
Proxy ARP file</a>.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">...
auto eth1
iface eth1 inet static
address 206.124.146.176
netmask 255.255.255.255
broadcast 0.0.0.0
<span class="bold"><b>up ip route add 206.124.146.177 dev eth1
</b></span>...</pre></td></tr></table></blockquote></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="Dhcpd"></a>/etc/dhcpd.conf (MAC Addresses Omitted)</h3></div></div><div></div></div><div class="blockquote"><blockquote class="blockquote"><p>While this is a little off-topic, I've included it to show
how to set up DHCP on two interfaces.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">default-lease-time 67200; max-lease-time 67200;
get-lease-hostnames on;
group {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option ntp-servers 192.168.1.254;
option domain-name-servers 192.168.1.193;
option netbios-name-servers 192.168.1.254;
option domain-name &quot;shorewall.net&quot;;
option netbios-dd-server 192.168.1.254;
option netbios-node-type 8;
option netbios-scope &quot;&quot;;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.11 192.168.1.20;
}
host ursa.shorewall.net {
hardware ethernet …;
fixed-address 192.168.1.5;
}
host eastept1 {
hardware ethernet …;
fixed-address 192.168.1.7;
}
host tarry {
hardware ethernet …;
fixed-address 192.168.1.4;
}
host wookie.shorewall.net {
hardware ethernet …;
fixed-address 192.168.1.3;
}
host testws.shorewall.net {
hardware ethernet …;
fixed-address 192.168.1.6;
}
host printer.shorewall.net {
hardware ethernet …;
fixed-address 192.168.1.10;
}
}
group {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.3.255;
option routers 192.168.3.254;
option ntp-servers 192.168.3.254;
option domain-name-servers 206.124.146.177;
option netbios-name-servers 192.168.3.254;
option domain-name &quot;shorewall.net&quot;;
option netbios-dd-server 192.168.3.254;
option netbios-node-type 8;
option netbios-scope &quot;&quot;;
subnet 192.168.3.0 netmask 255.255.255.0 {
range 192.168.3.11 192.168.3.20;
}
host easteplaptop {
hardware ethernet …;
fixed-address 192.168.3.7;
}
host tipper.shorewall.net {
hardware ethernet …;
fixed-address 192.168.3.8;
}</pre></td></tr></table></blockquote></div></div></div></div></body></html>

371
Shorewall-docs2/myfiles.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-02-14</pubdate>
<pubdate>2004-03-16</pubdate>
<copyright>
<year>2001-2004</year>
@ -47,37 +47,37 @@
<caution>
<para>The configuration shown here corresponds to Shorewall version
2.0.0-Beta2. It may use features not available in earlier Shorewall
releases.</para>
2.0.1 (that&#39;s right -- I am running a version of Shorewall that is
not yet released). My configuration uses features not available in
earlier Shorewall releases.</para>
</caution>
<para>I have DSL service and have 5 static IP addresses
(206.124.146.176-180). My DSL <quote>modem</quote> (Fujitsu Speedport) is
connected to eth0. I have a local network connected to eth2 (subnet
192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a
Wireless network connected to eth3 (192.168.3.0/24). Note that the IP
address of eth1 is a duplicate of one on eth0.</para>
192.168.1.0/24) and a DMZ connected to eth1 (206.124.146.176/32). Note
that the IP address of eth1 is a duplicate of one on eth0.</para>
<para>I use:</para>
<para>In this configuration:</para>
<itemizedlist>
<listitem>
<para>One-to-one NAT for Ursa (my personal system that dual-boots
Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5 and
external address 206.124.146.178.</para>
<para>I use one-to-one NAT for Ursa (my personal system that
dual-boots Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5
and external address 206.124.146.178.</para>
</listitem>
<listitem>
<para>One-to-one NAT for EastepLaptop (My work system -- Windows XP
SP2). Internal address 192.168.1.7 and external address
<para>I use one-to-one NAT for EastepLaptop (My work system -- Windows
XP SP2). Internal address 192.168.1.7 and external address
206.124.146.180.</para>
</listitem>
<listitem>
<para>SNAT through 206.124.146.179 for&#x00A0; my SuSE 9.0 Linux
<para>I use SNAT through 206.124.146.179 for&#x00A0; my SuSE 9.0 Linux
system (Wookie), my Wife&#39;s Windows XP system (Tarry), and
our&#x00A0; Windows XP laptop (Tipper) which connects through the
Wireless Access Point (wap) via a Wireless Bridge (bridge).<note><para>While
Wireless Access Point (wap) via a Wireless Bridge (wet).<note><para>While
the distance between the WAP and where I usually use the laptop
isn&#39;t very far (25 feet or so), using a WAC11 (CardBus wireless
card) has proved very unsatisfactory (lots of lost connections). By
@ -89,17 +89,24 @@
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>I have Wookie (193.168.1.3) configured as a 3-port bridge. Squid
runs on this system and is configured as a transparent proxy.</para>
</listitem>
</itemizedlist>
<para>The firewall runs on a 256MB PII/233 with Debian Sarge (Testing).</para>
<para>Wookie, Ursa and the Firewall all run Samba and the Firewall acts as
a WINS server.</para>
<para>Wookie and Ursa run Samba and the Wookie acts as a WINS server.</para>
<para>The wireless network connects to eth3 via a LinkSys WAP11.&#x00A0;
In additional to using the rather weak WEP 40-bit encryption (64-bit with
the 24-bit preamble), I use <ulink url="MAC_Validation.html">MAC
verification</ulink>. This is still a weak combination and if I lived near
a wireless <quote>hot spot</quote>, I would probably add IPSEC or
something similar to my WiFi-&#62;local connections.</para>
<para>The wireless network connects to Wookie&#39;s eth2 via a LinkSys
WAP11.&#x00A0; In additional to using the rather weak WEP 40-bit
encryption (64-bit with the 24-bit preamble), I use <ulink
url="MAC_Validation.html">MAC verification</ulink>. This is still a weak
combination and if I lived near a wireless <quote>hot spot</quote>, I
would probably add IPSEC or something similar to my WiFi-&#62;local
connections.</para>
<para>The single system in the DMZ (address 206.124.146.177) runs postfix,
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
@ -130,6 +137,10 @@
<para>Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for
Road Warrior access.</para>
</section>
<section>
<title>Firewall Configuration</title>
<section>
<title>Shorewall.conf</title>
@ -187,7 +198,6 @@ LOG=info</programlisting></para>
<blockquote>
<programlisting>#ZONE DISPLAY COMMENTS
net Internet Internet
WiFi Wireless Wireless Network on eth3
dmz DMZ Demilitarized zone
loc Local Local networks
tx Texas Peer Network in Dallas
@ -206,7 +216,6 @@ tx Texas Peer Network in Dallas
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags,nosmurfs
loc eth2 192.168.1.255 dhcp,detectnets
dmz eth1 -
WiFi eth3 192.168.3.255 dhcp,maclist,detectnets
- texas 192.168.9.255
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
@ -229,7 +238,6 @@ tx&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A
<programlisting>#INTERFACE HOST(S)
eth1 206.124.146.177
eth2 -
eth3 192.168.3.0/24
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
</blockquote>
</section>
@ -262,6 +270,7 @@ eth3 192.168.3.0/24
<programlisting>#ADDRESS/SUBNET PROTOCOL PORT
0.0.0.0/0 udp 1434
0.0.0.0/0 tcp 1433
0.0.0.0/0 tcp 3127
0.0.0.0/0 tcp 8081
0.0.0.0/0 tcp 57
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</programlisting>
@ -279,7 +288,6 @@ $FW loc ACCEPT # Allo
$FW tx ACCEPT # Allow firewall access to texas
loc tx ACCEPT # Allow local net access to texas
loc fw REJECT $LOG # Reject loc-&#62;fw and log
WiFi net ACCEPT # Allow internet access from wirless
net all DROP $LOG 10/sec:40 # Rate limit and
# DROP net-&#62;all
all all REJECT $LOG # Reject and log the rest
@ -293,12 +301,11 @@ all all REJECT $LOG # Reje
<blockquote>
<para>Although most of our internal systems use one-to-one NAT, my
wife&#39;s system (192.168.1.4) uses IP Masquerading (actually SNAT)
as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
as do my SuSE system (192.168.1.3), our laptop (192.168.3.8) and
visitors with laptops.</para>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0:2 eth2 206.124.146.179
eth0 eth3 206.124.146.179
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
</programlisting>
</blockquote>
@ -428,23 +435,17 @@ REJECT:$LOG loc net tcp
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
#
DROP loc:!192.168.1.0/24 net
QUEUE loc net udp
QUEUE loc fw udp
QUEUE loc net tcp
###############################################################################################################################################################################
# Local Network to Firewall
#
DROP loc:!192.168.1.0/24 fw
ACCEPT loc fw tcp ssh,time,10000,swat,137,139,445
ACCEPT loc fw udp snmp,ntp,445
ACCEPT loc fw udp 137:139
ACCEPT loc fw udp 1024: 137
ACCEPT loc fw tcp ssh,time
ACCEPT loc fw udp snmp,ntp
###############################################################################################################################################################################
# Local Network to DMZ
#
DROP loc:!192.168.1.0/24 dmz
REJECT loc dmz tcp 465
ACCEPT loc dmz udp domain,xdmcp
ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,10027,pop3 -
@ -500,72 +501,17 @@ ACCEPT dmz fw tcp
ACCEPT dmz fw udp snmp
REJECT dmz fw tcp auth
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080
ACCEPT dmz net udp domain
ACCEPT dmz net:$POPSERVERS tcp pop3
#ACCEPT dmz net:206.191.151.2 tcp pop3
#ACCEPT dmz net:66.216.26.115 tcp pop3
#
# Something is wrong with the FTP connection tracking code or there is some client out there
# that is sending a PORT command which that code doesn&#39;t understand. Either way,
# the following works around the problem.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# DMZ to Firewall -- ntp &#38; snmp, Silently reject Auth
#
ACCEPT dmz fw udp ntp ntp
ACCEPT dmz fw tcp snmp,ssh
ACCEPT dmz fw udp snmp
REJECT dmz fw tcp auth
###############################################################################################################################################################################
#
# DMZ to Local Network
#
ACCEPT dmz loc tcp smtp,6001:6010
ACCEPT dmz loc tcp 111
ACCEPT dmz loc udp
ACCEPT dmz:206.124.146.177 loc:192.168.1.3 tcp 111
ACCEPT dmz:206.124.146.177 loc:192.168.1.3 udp
###############################################################################################################################################################################
# Internet to Firewall
#
REJECT net fw tcp www
ACCEPT net dmz udp 33434:33435
###############################################################################################################################################################################
# WIFI to Firewall
#
ACCEPT WiFi fw tcp ssh,137,139,445
ACCEPT WiFi fw udp 137:139,445
ACCEPT WiFi fw udp 1024: 137
ACCEPT WiFi fw udp ntp ntp
###############################################################################################################################################################################
# Firewall to WIFI
#
ACCEPT fw WiFi tcp 137,139,445
ACCEPT fw WiFi udp 137:139,445
ACCEPT fw WiFi udp 1024: 137
ACCEPT fw WiFi udp ntp ntp
##############################################################################################################################################################################
# WIFI to DMZ
#
DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193
ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh,8080 -
ACCEPT WiFi dmz udp domain
##############################################################################################################################################################################
# WIFI to loc
#
ACCEPT WiFi loc udp 137:139
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
ACCEPT WiFi loc udp 1024: 137
ACCEPT WiFi loc udp 177
##############################################################################################################################################################################
# loc to WiFi
#
ACCEPT loc WiFi udp 137:139
ACCEPT loc WiFi tcp 137,139,445
ACCEPT loc WiFi udp 1024: 137
ACCEPT loc WiFi tcp 6000:6010
###############################################################################################################################################################################
# Firewall to Internet
#
@ -694,4 +640,241 @@ group {
</blockquote>
</section>
</section>
<section>
<title>Bridge (Wookie) Configuration</title>
<para>As mentioned above, Wookie acts as a bridge. It&#39;s view of the
network is diagrammed in the following figure.</para>
<graphic fileref="images/network1.png" />
<para>I&#39;ve included the files that I used to configure that system --
some of them are SuSE-specific.</para>
<para>The configuration on Wookie can be modified to test various bridging
features -- otherwise, it serves to isolate the Wireless network from the
rest of our systems.</para>
<section>
<title>shorewall.conf</title>
<blockquote>
<para>Only the changes from the defaults are shown.</para>
<programlisting>BRIDGING=Yes</programlisting>
</blockquote>
</section>
<section>
<title>zones</title>
<blockquote>
<programlisting>#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
WiFi WireLess Wireless Network
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
</programlisting>
</blockquote>
</section>
<section>
<title>policy</title>
<blockquote>
<programlisting>#SOURCE DEST POLICY LOG LIMIT:BURST
fw fw ACCEPT
loc net ACCEPT
net loc ACCEPT
net fw ACCEPT
loc fw ACCEPT
loc WiFi ACCEPT
fw WiFi ACCEPT
fw net ACCEPT
fw loc ACCEPT
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT info
#LAST LINE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>interfaces</title>
<blockquote>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
- br0 192.168.1.255
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>hosts</title>
<blockquote>
<programlisting>#ZONE HOST(S) OPTIONS
net br0:eth1
loc br0:eth0
WiFi br0:eth2 maclist
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>rules</title>
<blockquote>
<para>The first rule allows a transparent WWW proxy (Squid) to run on
my bridge/firewall. Squid listens on port 3128.</para>
<para>The remaining rules protect the local systems and bridge from
the WiFi network. Note that we don&#39;t restrict WiFi→net traffic
since the only directly-accessible system in the net zone is the
firewall (Wookie and the Firewall are connected by a cross-over
cable).</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
REDIRECT loc 3128 tcp www - !192.168.1.0/24
ACCEPT WiFi loc udp 137:139
ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389
ACCEPT WiFi loc udp 1024: 137
ACCEPT WiFi loc udp 177
ACCEPT loc WiFi udp 137:139
ACCEPT loc WiFi tcp 137,139,445
ACCEPT loc WiFi udp 1024: 137
ACCEPT loc WiFi tcp 6000:6010
ACCEPT WiFi fw tcp ssh,137,139,445
ACCEPT WiFi fw udp 137:139,445
ACCEPT WiFi fw udp 1024: 137
ACCEPT WiFi fw udp ntp
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>routestopped</title>
<blockquote>
<programlisting>#INTERFACE HOST(S) OPTIONS
br0 0.0.0.0/0 routeback
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>maclist</title>
<blockquote>
<programlisting>#INTERFACE MAC IP ADDRESSES (Optional)
br0:eth2 00:A0:1C:DB:0C:A0 192.168.1.7 #Work Laptop
br0:eth2 00:04:59:0e:85:b9 #WAP11
br0:eth2 00:06:D5:45:33:3c #WET11
br0:eth2 00:0b:c1:53:cc:97 192.168.1.8 #TIPPER
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</blockquote>
</section>
<section>
<title>/etc/init.d/bridge</title>
<blockquote>
<para>This file is SuSE-specific and creates the bridge device
<filename class="devicefile">br0</filename>. A script for other
disbributions would be similar.</para>
<programlisting>#!/bin/sh
################################################################################
# Script to create a bridge between eth0, eth1 and eth2
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# (c) 2004 - Tom Eastep (teastep@shorewall.net)
#
# Modify the following variables to match your configuration
#
# chkconfig: 2345 05 89
# description: Layer 2 Bridge
#
################################################################################
PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
do_stop() {
echo &#34;Stopping Bridge&#34;
brctl delbr br0
ip link set eth0 down
ip link set eth1 down
ip link set eth2 down
}
do_start() {
echo &#34;Starting Bridge&#34;
ip link set eth0 up
ip link set eth1 up
ip link set eth2 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
brctl addif br0 eth2
}
case &#34;$1&#34; in
start)
do_start
;;
stop)
do_stop
;;
restart)
do_stop
sleep 1
do_start
;;
*)
echo &#34;Usage: $0 {start|stop|restart}&#34;
exit 1
esac
exit 0</programlisting>
</blockquote>
</section>
<section>
<title>/etc/sysconfig/network/ifcfg-br0</title>
<blockquote>
<para>This file is SuSE-specific</para>
<programlisting>BOOTPROTO=&#39;static&#39;
BROADCAST=&#39;192.168.1.255&#39;
IPADDR=&#39;192.168.1.3&#39;
NETWORK=&#39;192.168.1.0&#39;
NETMASK=&#39;255.255.255.0&#39;
REMOTE_IPADDR=&#39;&#39;
STARTMODE=&#39;onboot&#39;
UNIQUE=&#39;3hqH.MjuOqWfSZ+C&#39;
WIRELESS=&#39;no&#39;
MTU=&#39;&#39;</programlisting>
</blockquote>
</section>
<section>
<title>/etc/sysconfig/network/routes</title>
<blockquote>
<para>This file is SuSE-specific</para>
<programlisting>192.168.1.0 - 255.255.255.0 br0
default 192.168.1.254 - -</programlisting>
</blockquote>
</section>
</section>
</article>

75
Shorewall-docs2/ports.html
View File

@ -1,75 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Ports Required for Various Services/Applications</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /><meta name="description" content="In addition to those applications described in the&#10; /etc/shorewall/rules documentation, here are some other&#10; services/applications that you may need to configure your firewall to&#10; accommodate." /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="id2590562"></a>Ports Required for Various Services/Applications</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2001-2002, 2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-12</p></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>In addition to those applications described in the
/etc/shorewall/rules documentation, here are some other
services/applications that you may need to configure your firewall to
accommodate.</p></div></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2807696">Auth (identd)</a></span></dt><dt><span class="section"><a href="#id2807721">DNS</a></span></dt><dt><span class="section"><a href="#id2807755">FTP</a></span></dt><dt><span class="section"><a href="#id2807785">ICQ</a></span></dt><dt><span class="section"><a href="#id2807824">IMAP</a></span></dt><dt><span class="section"><a href="#id2807860">IPSEC</a></span></dt><dt><span class="section"><a href="#id2805799">NFS</a></span></dt><dt><span class="section"><a href="#id2805858">NTP (Network Time Protocol)</a></span></dt><dt><span class="section"><a href="#id2805883">PCAnywhere</a></span></dt><dt><span class="section"><a href="#id2810144">Pop3</a></span></dt><dt><span class="section"><a href="#id2810185">PPTP</a></span></dt><dt><span class="section"><a href="#id2810236">rdate</a></span></dt><dt><span class="section"><a href="#id2810261">SSH</a></span></dt><dt><span class="section"><a href="#id2810287">SMB/NMB (Samba/Windows Browsing/File Sharing)</a></span></dt><dt><span class="section"><a href="#id2859431">SMTP</a></span></dt><dt><span class="section"><a href="#id2859455">Telnet</a></span></dt><dt><span class="section"><a href="#id2859481">Traceroute</a></span></dt><dt><span class="section"><a href="#id2859520">Usenet (NNTP)</a></span></dt><dt><span class="section"><a href="#id2859550">VNC</a></span></dt><dt><span class="section"><a href="#id2859615">Web Access</a></span></dt><dt><span class="section"><a href="#id2809845">Other Source of Port Information</a></span></dt><dt><span class="appendix"><a href="#id2809872">A. Revision History</a></span></dt></dl></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Beginning with Shorewall 2.0.0, the Shorewall distribution contains
a library of user-defined actions that allow for easily allowing or
blocking a particular application. Check your <tt class="filename">/etc/shorewall/actions.std</tt>
file for a list of the actions in your distribution. If you find what you
need, you simply use the action in a rule. For example, to allow DNS
queries from the <span class="bold"><b>dmz</b></span> zone to the
<span class="bold"><b>net</b></span> zone:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION
AllowPing dmz net</pre></td></tr></table></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>In the rules that are shown in this document, the ACTION is shown as
ACCEPT. You may need to use DNAT (see <a href="FAQ.htm#faq30" target="_self">FAQ 30</a>)
or you may want DROP or REJECT if you are trying to block the application.</p><p>Example: You want to port forward FTP from the net to your server at
192.168.1.4 in your DMZ. The FTP section below gives you:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 21</pre></td></tr></table><p>You would code your rule as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
DNAT net dmz:192.168.1.4 tcp 21</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807696"></a>Auth (identd)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 113</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807721"></a>DNS</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> udp 53
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 53</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807755"></a>FTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 21</pre></td></tr></table><p>Look <a href="FTP.html" target="_self">here</a> for much more information.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807785"></a>ICQ</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> udp 4000
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 4000:4100</pre></td></tr></table><p>UDP Port 4000. You will also need to open a range of TCP ports which
you can specify to your ICQ client. By default, clients use 4000-4100.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807824"></a>IMAP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 143 #Unsecure IMAP
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 993 #Secure IMAP</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2807860"></a>IPSEC</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em> &lt;destination&gt;</em></span> 50
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em> &lt;destination&gt;</em></span> 51
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em> &lt;destination&gt;</em></span> udp 500
ACCEPT <span class="emphasis"><em>&lt;destination&gt;</em></span> <span class="emphasis"><em>&lt;source&gt;</em></span> 50
ACCEPT <span class="emphasis"><em>&lt;destination&gt;</em></span> <span class="emphasis"><em>&lt;source&gt;</em></span> 51
ACCEPT <span class="emphasis"><em>&lt;destination&gt;</em></span> <span class="emphasis"><em>&lt;source&gt;</em></span> udp 500</pre></td></tr></table><p>Lots more information <a href="IPSEC.htm" target="_self">here</a> and <a href="VPN.htm" target="_self">here</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805799"></a>NFS</h2></div></div><div></div></div><p>I personally use the following rules for opening access from zone z1
to a server with IP address a.b.c.d in zone z2. I have found though that
different distributions behave differently so your milage may vary.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;z1&gt;</em></span> <span class="emphasis"><em> &lt;z2&gt;</em></span>:a.b.c.d tcp 111
ACCEPT <span class="emphasis"><em>&lt;z1&gt;</em></span> <span class="emphasis"><em> &lt;z2&gt;</em></span>:a.b.c.d udp 111
ACCEPT <span class="emphasis"><em>&lt;z1&gt;</em></span> <span class="emphasis"><em> &lt;z2&gt;</em></span>:a.b.c.d udp 2049
ACCEPT <span class="emphasis"><em>&lt;z1&gt;</em></span> <span class="emphasis"><em> &lt;z2&gt;</em></span>:a.b.c.d udp 32700:</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805858"></a>NTP (Network Time Protocol)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> udp 123</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2805883"></a><span class="trademark">PCAnywhere</span>™</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> udp 5632
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 5631</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810144"></a>Pop3</h2></div></div><div></div></div><p>TCP Port 110 (Secure Pop3 is TCP Port 995)</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 110 #Unsecure Pop3
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 995 #Secure Pop3</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810185"></a>PPTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> 47
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 1723</pre></td></tr></table><p>Lots more information <a href="PPTP.htm" target="_self">here</a> and <a href="VPN.htm" target="_self">here</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810236"></a>rdate</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 37</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810261"></a>SSH</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 22</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810287"></a>SMB/NMB (Samba/Windows Browsing/File Sharing)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em> &lt;destination&gt;</em></span> tcp 137,139,445
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em> &lt;destination&gt;</em></span> udp 137:139
ACCEPT <span class="emphasis"><em>&lt;destination&gt;</em></span> <span class="emphasis"><em>&lt;source&gt;</em></span> tcp 137,139,445
ACCEPT <span class="emphasis"><em>&lt;destination&gt;</em></span> <span class="emphasis"><em>&lt;source&gt;</em></span> udp 137:139</pre></td></tr></table><p>Also, see <a href="samba.htm" target="_self">this page</a>.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859431"></a>SMTP</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 25</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859455"></a>Telnet</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 23</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859481"></a>Traceroute</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> udp 33434:33443 #Good for 10 hops
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> icmp 8</pre></td></tr></table><p>UDP traceroute uses ports 33434 through 33434+&lt;max number of
hops&gt;-1</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859520"></a>Usenet (NNTP)</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 119</pre></td></tr></table><p>TCP Port 119</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859550"></a>VNC</h2></div></div><div></div></div><p>Vncviewer to Vncserver -- TCP port 5900 + &lt;display number&gt;.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 5901 #Display Number 1
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 5902 #Display Number 2
...</pre></td></tr></table><p>Vncserver to Vncviewer in listen mode -- TCP port 5500.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 5500</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859615"></a>Web Access</h2></div></div><div></div></div><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 80 #Insecure HTTP
ACCEPT <span class="emphasis"><em>&lt;source&gt;</em></span> <span class="emphasis"><em>&lt;destination&gt;</em></span> tcp 443 #Secure HTTP</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2809845"></a>Other Source of Port Information</h2></div></div><div></div></div><p>Didn't find what you are looking for -- have you looked in your
own /etc/services file?</p><p>Still looking? Try <a href="http://www.networkice.com/advice/Exploits/Ports" target="_self">http://www.networkice.com/advice/Exploits/Ports</a></p></div><div class="appendix" lang="en" xml:lang="en"><h2 class="title" style="clear: both"><a id="id2809872"></a>A. Revision History</h2><div class="revhistory"><table border="0" width="100%" summary="Revision history"><tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr><tr><td align="left">Revision 1.6</td><td align="left">2004-01-26</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
PCAnywhere.</td></tr><tr><td align="left">Revision 1.5</td><td align="left">2004-02-05</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Added
information about VNC viewers in listen mode.</td></tr><tr><td align="left">Revision 1.4</td><td align="left">2004-01-26</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Correct
ICQ.</td></tr><tr><td align="left">Revision 1.3</td><td align="left">2004-01-04</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Alphabetize</td></tr><tr><td align="left">Revision 1.2</td><td align="left">2004-01-03</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Add
rules file entries.</td></tr><tr><td align="left">Revision 1.1</td><td align="left">2002-07-30</td><td align="left">TE</td></tr><tr><td align="left" colspan="3">Initial
version converted to Docbook XML</td></tr></table></div></div></div></body></html>

17
Shorewall-docs2/ports.xml
View File

@ -13,7 +13,7 @@
</author>
</authorgroup>
<pubdate>2004-02-12</pubdate>
<pubdate>2004-02-18</pubdate>
<copyright>
<year>2001-2002</year>
@ -131,15 +131,9 @@ ACCEPT <emphasis>&#60;destination&#62;</emphasis> <emphasis>&#60;source&#62
<section>
<title>NFS</title>
<para>I personally use the following rules for opening access from zone z1
to a server with IP address a.b.c.d in zone z2. I have found though that
different distributions behave differently so your milage may vary.</para>
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <emphasis>&#60;z1&#62;</emphasis> <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d tcp 111
ACCEPT <emphasis>&#60;z1&#62;</emphasis> <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d udp 111
ACCEPT <emphasis>&#60;z1&#62;</emphasis> <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d udp 2049
ACCEPT <emphasis>&#60;z1&#62;</emphasis> <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d udp 32700:</programlisting>
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <emphasis>&#60;z1&#62;</emphasis>:&#60;list of client IPs&#62; <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d tcp 111
ACCEPT <emphasis>&#60;z1&#62;</emphasis>:&#60;list of client IPs&#62; <emphasis> &#60;z2&#62;</emphasis>:a.b.c.d udp</programlisting>
</section>
<section>
@ -275,7 +269,8 @@ ACCEPT <emphasis>&#60;source&#62;</emphasis> <emphasis>&#60;destination&#62
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.6</revnumber><date>2004-01-26</date><authorinitials>TE</authorinitials><revremark>Add
<para><revhistory><revision><revnumber>1.7</revnumber><date>2004-02-18</date><authorinitials>TE</authorinitials><revremark>Make
NFS work for everyone.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-14</date><authorinitials>TE</authorinitials><revremark>Add
PCAnywhere.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Added
information about VNC viewers in listen mode.</revremark></revision><revision><revnumber>1.4</revnumber><date>2004-01-26</date><authorinitials>TE</authorinitials><revremark>Correct
ICQ.</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-04</date><authorinitials>TE</authorinitials><revremark>Alphabetize</revremark></revision><revision><revnumber>1.2</revnumber><date>2004-01-03</date><authorinitials>TE</authorinitials><revremark>Add

16
Shorewall-docs2/standalone.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-02-05</pubdate>
<pubdate>2004-02-16</pubdate>
<copyright>
<year>2002-2004</year>
@ -261,9 +261,11 @@ all all REJECT info</programlisting>
<tip>
<para>If you specify <emphasis>norfc1918</emphasis> for your external
interface, you will want to check the <ulink url="errata.htm">Shorewall
Errata</ulink> periodically for updates to the <filename>/etc/shorewall/rfc1918
file</filename>. Alternatively, you can <ulink url="myfiles.htm#RFC1918">strip
down your <filename>/etc/shorewall/rfc1918</filename> file as I do</ulink>.</para>
Errata</ulink> periodically for updates to the <filename>/usr/share/shorewall/rfc1918
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
file as I do</ulink>.</para>
</tip>
</section>
@ -300,8 +302,7 @@ all all REJECT info</programlisting>
actions included in your version of Shorewall in the file
<filename>/etc/shorewall/actions.std</filename>.</para>
<para>Those actions that allow a connection begin with <quote>Allow</quote>.
</para>
<para>Those actions that allow a connection begin with <quote>Allow</quote>.</para>
<para>If you wish to enable connections from the internet to your firewall
and you find an appropriate <quote>Allow</quote> action in
@ -406,7 +407,8 @@ AllowSSH net fw </programlisting>
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.6</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Update
<para><revhistory><revision><revnumber>1.7</revnumber><date>2004-02-16</date><authorinitials>TE</authorinitials><revremark>Move
/etc/shorewall/rfc1918 to /usr/share/shorewall.</revremark></revision><revision><revnumber>1.6</revnumber><date>2004-02-05</date><authorinitials>TE</authorinitials><revremark>Update
for Shorewall 2.0</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-05</date><authorinitials>TE</authorinitials><revremark>Standards
Changes</revremark></revision><revision><revnumber>1.4</revnumber><date>2003-12-30</date><authorinitials>TE</authorinitials><revremark>Add
tip about /etc/shorewall/rfc1918 updates.</revremark></revision><revision><revnumber>1.3</revnumber><date>2003-11-15</date><authorinitials>TE</authorinitials><revremark>Initial

24
Shorewall-docs2/support.xml
View File

@ -15,7 +15,7 @@
</author>
</authorgroup>
<pubdate>2004-01-01</pubdate>
<pubdate>2004-03-15</pubdate>
<copyright>
<year>2001-2004</year>
@ -121,6 +121,12 @@
questions but we can&#39;t do your job for you.</para>
</listitem>
<listitem>
<para>Please do NOT include the output of <command>iptables -L</command>
— the output of <emphasis role="bold">shorewall show</emphasis> or
<command>shorewall status</command> is much more useful.</para>
</listitem>
<listitem>
<para>When reporting a problem, <emphasis role="bold">ALWAYS</emphasis>
include this information:</para>
@ -254,11 +260,6 @@
please post your question or problem to <ulink
url="mailto:leaf-user@lists.sourceforge.net">the LEAF Users mailing list</ulink>.</para>
<para><emphasis role="bold">If you are new to Shorewall and have a
question or need help with a problem</emphasis>, please post to the <ulink
url="mailto:shorewall-newbies@lists.shorewall.net">Shorewall Newbies
mailing list</ulink>.</para>
<para><emphasis role="bold">If you run Shorewall under MandrakeSoft Multi
Network Firewall (MNF) and you have not purchased an MNF license from
MandrakeSoft then you can post non MNF-specific Shorewall questions to the
@ -272,13 +273,6 @@
included in any replies.</para>
</section>
<section>
<title>Subscribing to the Newbies Mailing List</title>
<para>To Subscribe to the mailing list go to <ulink
url="https://lists.shorewall.net/mailman/listinfo/shorewall-newbies">https://lists.shorewall.net/mailman/listinfo/shorewall-newbies</ulink>.</para>
</section>
<section>
<title>Subscribing to the Users Mailing List</title>
@ -296,7 +290,9 @@
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.2</revnumber><date>2003-01-01</date><authorinitials>TE</authorinitials><revremark>Removed
<para><revhistory><revision><revnumber>1.4</revnumber><date>2003-03-15</date><authorinitials>TE</authorinitials><revremark>Remove
Newbies Mailing List.</revremark></revision><revision><revnumber>1.3</revnumber><date>2003-02-19</date><authorinitials>TE</authorinitials><revremark>Admonish
against including &#34;iptables -L&#34; output.</revremark></revision><revision><revnumber>1.2</revnumber><date>2003-01-01</date><authorinitials>TE</authorinitials><revremark>Removed
.GIF and moved note about unsupported releases. Move Revision History to
this Appendix.</revremark></revision><revision><revnumber>1.1</revnumber><date>2003-12-19</date><authorinitials>TE</authorinitials><revremark>Corrected
URL for Newbies List</revremark></revision></revhistory></para>

342
Shorewall-docs2/three-interface.html
View File

@ -1,342 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Three-Interface Firewall</title><meta name="generator" content="DocBook XSL Stylesheets V1.62.4" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="three-interface"></a>Three-Interface Firewall</h1></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Tom</span> <span class="surname">Eastep</span></h3></div></div></div><div><p class="copyright">Copyright © 2002-2004 Thomas M. Eastep</p></div><div><div class="legalnotice"><p>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
“<span class="quote"><a href="GnuCopyright.htm" target="_self">GNU Free Documentation License</a></span>”.</p></div></div><div><p class="pubdate">2004-02-12</p></div></div><div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id2803947">Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="#id2807729">Requirements</a></span></dt><dt><span class="section"><a href="#id2807804">Before you start</a></span></dt><dt><span class="section"><a href="#id2810224">Conventions</a></span></dt></dl></dd><dt><span class="section"><a href="#id2810263">PPTP/ADSL</a></span></dt><dt><span class="section"><a href="#id2810295">Shorewall Concepts</a></span></dt><dt><span class="section"><a href="#id2859594">Network Interfaces</a></span></dt><dt><span class="section"><a href="#id2859977">IP Addresses</a></span></dt><dt><span class="section"><a href="#id2806632">IP Masquerading (SNAT)</a></span></dt><dt><span class="section"><a href="#id2806881">Port Forwarding (DNAT)</a></span></dt><dt><span class="section"><a href="#id2865302">Domain Name Server (DNS)</a></span></dt><dt><span class="section"><a href="#id2865536">Other Connections</a></span></dt><dt><span class="section"><a href="#id2865767">Starting and Stopping Your Firewall</a></span></dt><dt><span class="section"><a href="#id2865997">Additional Recommended Reading</a></span></dt></dl></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2803947"></a>Introduction</h2></div></div><div></div></div><p>Setting up a Linux system as a firewall for a small network with DMZ
is a fairly straight-forward task if you understand the basics and follow
the documentation.</p><p>This guide doesn't attempt to acquaint you with all of the
features of Shorewall. It rather focuses on what is required to configure
Shorewall in one of its more popular configurations:</p><div class="itemizedlist"><ul type="disc"><li><p>Linux system used as a firewall/router for a small local
network.</p></li><li><p>Single public IP address.</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>If you have more than one public IP address, this is not the
guide you want -- see the <a href="shorewall_setup_guide.htm" target="_self">Shorewall
Setup Guide</a> instead.</p></div></li><li><p>DMZ connected to a separate ethernet interface.</p></li><li><p>Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up,
...</p></li></ul></div><p>Here is a schematic of a typical installation.</p><div class="figure"><a id="id2807700"></a><p class="title"><b>Figure 1. schematic of a typical installation</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="schematic of a typical installation" /></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807729"></a>Requirements</h3></div></div><div></div></div><p>Shorewall requires that you have the <span><b class="command">iproute</b></span>/<span><b class="command">iproute2</b></span>
package installed (on <span class="trademark">RedHat</span>™, the package is
called <span><b class="command">iproute</b></span>). You can tell if this package is
installed by the presence of an <span><b class="command">ip</b></span> program on your
firewall system. As <tt class="systemitem">root</tt>, you
can use the <span><b class="command">which</b></span> command to check for this program:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">[root@gateway root]# <span><b class="command">which ip</b></span>
/sbin/ip
[root@gateway root]#</pre></td></tr></table></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2807804"></a>Before you start</h3></div></div><div></div></div><p>I recommend that you first read through the guide to familiarize
yourself with what's involved then go back through it again making
your configuration changes.</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>If you edit your configuration files on a
<span class="trademark">Windows</span>™ system, you must save them as
<span class="trademark">Unix</span>™ files if your editor supports that option
or you must run them through <span><b class="command">dos2unix</b></span> before trying
to use them. Similarly, if you copy a configuration file from your
<span class="trademark">Windows</span>™ hard drive to a floppy disk, you must
run <span><b class="command">dos2unix</b></span> against the copy before using it with
Shorewall.</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://www.simtel.net/pub/pd/51438.html" target="_self">Windows
Version of dos2unix</a></p></li><li><p><a href="http://www.megaloman.com/%7Ehany/software/hd2u/" target="_self">Linux
Version of dos2unix</a></p></li></ul></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="id2810224"></a>Conventions</h3></div></div><div></div></div><p>Points at which configuration changes are recommended are flagged
with <img src="images/BD21298_.gif" />.</p><p>Configuration notes that are unique to LEAF/Bering are marked with
<img src="images/leaflogo.gif" />.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810263"></a>PPTP/ADSL</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>If you have an ADSL Modem and you use PPTP to communicate with a
server in that modem, you must make the <a href="PPTP.htm#PPTP_ADSL" target="_self">changes
recommended here</a> in addition to those detailed below. ADSL with
PPTP is most commonly found in Europe, notably in Austria.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2810295"></a>Shorewall Concepts</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The configuration files for Shorewall are contained in the directory
<tt class="filename">/etc/shorewall</tt> -- for simple setups, you will only
need to deal with a few of these as described in this guide. After you
have installed Shorewall, download the three-interface sample, un-tar it (<span><b class="command">tar
<tt class="option">-zxvf</tt> <tt class="filename">three-interfaces.tgz</tt></b></span>)
and and copy the files to <tt class="filename">/etc/shorewall</tt> (the files
will replace files with the same names that were placed in
<tt class="filename">/etc/shorewall</tt> when Shorewall was installed).</p><p>As each file is introduced, I suggest that you look through the
actual file on your system -- each file contains detailed configuration
instructions and default entries.</p><p>Shorewall views the network where it is running as being composed of
a set of zones. In the three-interface sample configuration, the following
zone names are used:</p><div class="informaltable"><table border="1"><colgroup><col /><col /></colgroup><thead valign="middle"><tr><th align="center">Name</th><th align="center">Description</th></tr></thead><tbody><tr><td align="left">net</td><td align="left">The Internet</td></tr><tr><td align="left">loc</td><td align="left">Your Local Network</td></tr><tr><td align="left">dmz</td><td align="left">Demilitarized Zone</td></tr></tbody></table></div><p>Zone names are defined in <tt class="filename">/etc/shorewall/zones</tt>.</p><p>Shorewall also recognizes the firewall system as its own zone - by
default, the firewall itself is known as <tt class="varname">fw</tt>.</p><p>Rules about what traffic to allow and what traffic to deny are
expressed in terms of zones.</p><div class="itemizedlist"><ul type="disc"><li><p>You express your default policy for connections from one zone to
another zone in the <tt class="filename">/etc/shorewall/policy</tt> file.</p></li><li><p>You define exceptions to those default policies in the
<tt class="filename">/etc/shorewall/rules</tt> file.</p></li></ul></div><p>For each connection request entering the firewall, the request is
first checked against the <tt class="filename">/etc/shorewall/rules</tt> file.
If no rule in that file matches the connection request then the first
policy in <tt class="filename">/etc/shorewall/policy</tt> that matches the
request is applied. If that policy is REJECT or DROP the request is first
checked against the rules in <tt class="filename">/etc/shorewall/common</tt> if
that file exists; otherwise the file <tt class="filename">/etc/shorewall/common.def</tt>
is checked</p><p>The <tt class="filename">/etc/shorewall/policy</tt> file included with
the three-interface sample has the following policies:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT info</pre></td></tr></table><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>In the three-interface sample, the line below is included but
commented out. If you want your firewall system to have full access to
servers on the internet, uncomment that line.</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
fw net ACCEPT</pre></td></tr></table></div><p>The above policy will:</p><div class="orderedlist"><ol type="1"><li><p>allow all connection requests from your local network to the
internet</p></li><li><p>drop (ignore) all connection requests from the internet to your
firewall or local network</p></li><li><p>optionally accept all connection requests from the firewall to
the internet (if you uncomment the additional policy)</p></li><li><p>reject all other connection requests.</p></li></ol></div><p><img src="images/BD21298_.gif" /></p><p>At this point, edit your <tt class="filename">/etc/shorewall/policy</tt>
file and make any changes that you wish.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859594"></a>Network Interfaces</h2></div></div><div></div></div><div class="figure"><a id="id2859601"></a><p class="title"><b>Figure 2. DMZ</b></p><div class="mediaobject" align="center"><img src="images/dmz1.png" align="middle" alt="DMZ" /></div></div><p>The firewall has three network interfaces. Where Internet
connectivity is through a cable or DSL “<span class="quote">Modem</span>”, the External
Interface will be the ethernet adapter that is connected to that
“<span class="quote">Modem</span>” (e.g., <tt class="filename">eth0</tt>)
unless you connect via <span class="emphasis"><em>Point-to-Point Protocol</em></span> over
Ethernet (PPPoE) or <span class="emphasis"><em>Point-to-Point Tunneling Protocol</em></span>
(PPTP) in which case the External Interface will be a <tt class="literal">ppp</tt>
interface (e.g., <tt class="filename">ppp0</tt>). If you
connect via a regular modem, your External Interface will also be
<tt class="filename">ppp0</tt>. If you connect using ISDN,
you external interface will be <tt class="filename">ippp0</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external interface is <tt class="filename">ppp0</tt>
or <tt class="filename">ippp0</tt> then you will want to set
<tt class="varname">CLAMPMSS=yes</tt> in <tt class="filename">/etc/shorewall/shorewall.conf</tt>.</p><p>Your Local Interface will be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
or <tt class="filename">eth2</tt>) and will be connected to
a hub or switch. Your local computers will be connected to the same switch
(note: If you have only a single local system, you can connect the
firewall directly to the computer using a cross-over cable).</p><p>Your DMZ Interface will also be an ethernet adapter (<tt class="filename">eth0</tt>, <tt class="filename">eth1</tt>
or <tt class="filename">eth2</tt>) and will be connected to
a hub or switch. Your DMZ computers will be connected to the same switch
(note: If you have only a single DMZ system, you can connect the firewall
directly to the computer using a cross-over cable).</p><div class="caution" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Caution</h3><p>Do not connect the internal and external interface to the same hub
or switch except for testing 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
<tt class="filename">/etc/shorewall/interfaces</tt> for all interfaces
connected to the common hub/switch. Using such a setup with a production
firewall is strongly recommended against.</p></div><p><img src="images/BD21298_.gif" /></p><p>The Shorewall three-interface sample configuration assumes that the
external interface is <tt class="filename">eth0</tt>, the
local interface is <tt class="filename">eth1</tt> and the
DMZ interface is <tt class="filename">eth2</tt>. If your
configuration is different, you will have to modify the sample
<tt class="filename">/etc/shorewall/interfaces</tt> file accordingly. While you
are there, you may wish to review the list of options that are specified
for the interfaces. Some hints:</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
or <tt class="filename">ippp0</tt>, you can replace the
“<span class="quote">detect</span>” in the second column with “<span class="quote">-</span>”
(without the quotes).</p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>If your external interface is <tt class="filename">ppp0</tt>
or <tt class="filename">ippp0</tt> or if you have a static
IP address, you can remove “<span class="quote">dhcp</span>” from the option list.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2859977"></a>IP Addresses</h2></div></div><div></div></div><p>Before going further, we should say a few words about Internet
Protocol (IP) addresses. Normally, your ISP will assign you a single
Public IP address. This address may be assigned via the Dynamic Host
Configuration Protocol (DHCP) or as part of establishing your connection
when you dial in (standard modem) or establish your PPP connection. In
rare cases, your ISP may assign you a static IP address; that means that
you configure your firewall's external interface to use that address
permanently. Regardless of how the address is assigned, it will be shared
by all of your systems when you access the Internet. You will have to
assign your own addresses for your internal network (the local and DMZ
Interfaces on your firewall plus your other computers). RFC 1918 reserves
several Private IP address ranges for this purpose:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255</pre></td></tr></table><p><img src="images/BD21298_.gif" /></p><p>Before starting Shorewall, you should look at the IP address of your
external interface and if it is one of the above ranges, you should remove
the <tt class="varname">norfc1918</tt> option from the external interface's
entry in <tt class="filename">/etc/shorewall/interfaces</tt>.</p><p>You will want to assign your local addresses from one sub-network or
subnet and your DMZ addresses from another subnet. For our purposes, we
can consider a subnet to consists of a range of addresses <tt class="systemitem">x.y.z.0</tt> - <tt class="systemitem">x.y.z.255</tt>.
Such a subnet will have a Subnet Mask of <tt class="systemitem">255.255.255.0</tt>.
The address <tt class="systemitem">x.y.z.0</tt> is reserved
as the Subnet Address and <tt class="systemitem">x.y.z.255</tt>
is reserved as the Subnet Broadcast Address. In Shorewall, a subnet is
described using Classless InterDomain Routing (CIDR) notation with
consists of the subnet address followed by <tt class="varname">/24</tt>. The
<tt class="varname">24</tt> refers to the number of consecutive “<span class="quote">1</span>”
bits from the left of the subnet mask.</p><div class="table"><a id="id2809952"></a><p class="title"><b>Table 1. Example sub-network</b></p><table summary="Example sub-network" border="1"><colgroup><col align="left" /><col /></colgroup><tbody><tr><td align="left">Range:</td><td><tt class="systemitem">10.10.10.0</tt> -
<tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">Subnet Address:</td><td><tt class="systemitem">10.10.10.0</tt></td></tr><tr><td align="left">Broadcast Address:</td><td><tt class="systemitem">10.10.10.255</tt></td></tr><tr><td align="left">CIDR Notation:</td><td><tt class="systemitem">10.10.10.0/24</tt></td></tr></tbody></table></div><p>It is conventional to assign the internal interface either the first
usable address in the subnet (<tt class="systemitem">10.10.10.1</tt>
in the above example) or the last usable address (<tt class="systemitem">10.10.10.254</tt>).</p><p>One of the purposes of subnetting is to allow all computers in the
subnet to understand which other computers can be communicated with
directly. To communicate with systems outside of the subnetwork, systems
send packets through a gateway (router).</p><p><img src="images/BD21298_.gif" /></p><p>Your local computers (Local Computers 1 &amp; 2) should be
configured with their default gateway set to the IP address of the
firewall's internal interface and your DMZ computers (DMZ Computers 1
&amp; 2) should be configured with their default gateway set to the IP
address of the firewall's DMZ interface.</p><p>The foregoing short discussion barely scratches the surface
regarding subnetting and routing. If you are interested in learning more
about IP addressing and routing, I highly recommend “<span class="quote">IP
Fundamentals: What Everyone Needs to Know about Addressing &amp; Routing</span>”,
Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.</p><p>The remainder of this quide will assume that you have configured
your network as shown here:</p><div class="figure"><a id="id2810143"></a><p class="title"><b>Figure 3. DMZ</b></p><div class="mediaobject"><img src="images/dmz2.png" alt="DMZ" /><div class="caption"><p>The default gateway for the DMZ computers would be <tt class="systemitem">10.10.11.254</tt> and the default gateway
for the Local computers would be <tt class="systemitem">10.10.10.254</tt>.</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>Your ISP might assign your external interface an RFC 1918
address. If that address is in the <tt class="systemitem">10.10.10.0/24</tt>
subnet then you will need to select a DIFFERENT RFC 1918 subnet
for your local network and if it is in the <tt class="systemitem">10.10.11.0/24</tt> subnet then you will
need to select a different RFC 1918 subnet for your DMZ.</p></div></div></div></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806632"></a>IP Masquerading (SNAT)</h2></div></div><div></div></div><p>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. When one of your local
systems (let's assume local computer 1) sends a connection request to
an internet host, the firewall must perform Network Address Translation
(NAT). The firewall rewrites the source address in the packet to be the
address of the firewall's external interface; in other words, the
firewall makes it look as if the firewall itself is initiating the
connection. This is necessary so that the destination host will be able to
route return packets back to the firewall (remember that packets whose
destination address is reserved by RFC 1918 can't be routed accross
the internet). When the firewall receives a return packet, it rewrites the
destination address back to 10.10.10.1 and forwards the packet on to local
computer 1.</p><p>On Linux systems, the above process is often referred to as IP
Masquerading and you will also see the term Source Network Address
Translation (SNAT) used. Shorewall follows the convention used with
Netfilter: </p><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>Masquerade</em></span>
describes the case where you let your firewall system automatically detect
the external interface address.</p></li><li><p><span class="emphasis"><em>SNAT</em></span>
refers to the case when you explicitly specify the source address that you
want outbound packets from your local network to use.</p></li></ul></div><p>
In Shorewall, both Masquerading and SNAT are configured with entries in
the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
file.</p><p><img src="images/BD21298_.gif" /></p><p>If your external firewall interface is <tt class="filename">eth0</tt>,
your local interface <tt class="filename">eth1</tt> and your
DMZ interface is <tt class="filename">eth2</tt> then you do
not need to modify the file provided with the sample. Otherwise, edit
<tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
and change it to match your configuration.</p><p>If, despite all advice to the contrary, you are using this guide and
want to use one-to-one NAT or Proxy ARP for your DMZ, remove the entry for
eth2 from <tt class="filename">/etc/shorewall/masq</tt>.</p><p><img src="images/BD21298_.gif" /></p><p>If your external IP is static, you can enter it in the third column
in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">masq</tt>
entry if you like although your firewall will work fine if you leave that
column empty. Entering your static IP in column 3 makes processing
outgoing packets a little more efficient.</p><p><img src="images/BD21298_.gif" /></p><p>If you are using the Debian package, please check your
<tt class="filename">shorewall.conf</tt> file to ensure that the following are
set correctly; if they are not, change them appropriately:
</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="varname">NAT_ENABLED=Yes</tt>
(Shorewall versions earlier than 1.4.6)</p></li><li><p><tt class="varname">IP_FORWARDING=On</tt></p></li></ul></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2806881"></a>Port Forwarding (DNAT)</h2></div></div><div></div></div><p>One of your goals will be to run one or more servers on your DMZ
computers. Because these computers have RFC-1918 addresses, it is not
possible for clients on the internet to connect directly to them. It is
rather necessary for those clients to address their connection requests to
your firewall who rewrites the destination address to the address of your
server and forwards the packet to that server. When your server responds,
the firewall automatically performs SNAT to rewrite the source address in
the response.</p><p>The above process is called <span class="emphasis"><em>Port Forwarding</em></span> or
<span class="emphasis"><em>Destination Network Address Translation</em></span> (DNAT). You
configure port forwarding using DNAT rules in the <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt>
file.</p><p>The general form of a simple port forwarding rule in <tt class="filename">/etc/shorewall/</tt><tt class="filename">rules</tt> is:
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net dmz:<span class="emphasis"><em>&lt;server local ip address&gt;</em></span>[:<span class="emphasis"><em>&lt;server port&gt;</em></span>] <span class="emphasis"><em>&lt;protocol&gt;</em></span> <span class="emphasis"><em>&lt;port&gt;</em></span></pre></td></tr></table><p>
If you don't specify the <span class="emphasis"><em><tt class="varname">&lt;server port&gt;</tt></em></span>,
it is assumed to be the same as <span class="emphasis"><em><tt class="varname">&lt;port&gt;</tt></em></span>.</p><div class="example"><a id="id2807001"></a><p class="title"><b>Example 1. You run a Web Server on DMZ Computer 2 and you want to forward
incoming TCP port 80 to that system</b></p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net dmz:10.10.11.2 tcp 80
ACCEPT loc dmz:10.10.11.2 tcp 80</pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
1 forwards port 80 from the Internet.</p></li><li><p>Entry
2 allows connections from the local network.</p></li></ul></div><p>
Several important points to keep in mind:</p><div class="itemizedlist"><ul type="disc"><li><p>When
you are connecting to your server from your local systems, you must use
the server's internal IP address (<tt class="systemitem">10.10.11.2</tt>).</p></li><li><p>Many
ISPs block incoming connection requests to port 80. If you have problems
connecting to your web server, try the following rule and try connecting
to port 5000 (e.g., connect to <tt class="literal">http://w.x.y.z:5000 where
w.x.y.z</tt> is your external IP).</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE
# PORT(S)
DNAT net dmz:10.10.11.2:80 tcp 80 5000</pre></td></tr></table></li><li><p>If
you want to be able to access your server from the local network using
your external address, then if you have a static external IP you can
replace the loc-&gt;dmz rule above with:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT loc dmz:10.10.11.2 tcp 80 - <span class="emphasis"><em>&lt;external ip&gt;</em></span></pre></td></tr></table><p>If
you have a dynamic ip then you must ensure that your external interface
is up before starting Shorewall and you must take steps as follows
(assume that your external interface is <tt class="filename">eth0</tt>):</p><div class="orderedlist"><ol type="1"><li><p>Include
the following in /etc/shorewall/params:</p><p><span><b class="command">ETH0_IP=$(find_interface_address
eth0)</b></span></p></li><li><p>Make your
<tt class="literal">loc-&gt;dmz</tt> rule: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP</pre></td></tr></table></li></ol></div></li><li><p>If
you want to access your server from the DMZ using your external IP
address, see <a href="FAQ.htm#faq2a" target="_self">FAQ 2a</a>.</p></li></ul></div></div><p><img src="images/BD21298_.gif" /></p><p>At this point, add the DNAT and ACCEPT rules for your servers.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865302"></a>Domain Name Server (DNS)</h2></div></div><div></div></div><p>Normally, when you connect to your ISP, as part of getting an IP
address your firewall's <span class="emphasis"><em>Domain Name Service</em></span> (DNS)
resolver will be automatically configured (e.g., the <tt class="filename">/etc/resolv.conf</tt>
file will be written). Alternatively, your ISP may have given you the IP
address of a pair of DNS name servers for you to manually configure as
your primary and secondary name servers. It is your responsibility to
configure the resolver in your internal systems. You can take one of two
approaches: </p><div class="itemizedlist"><ul type="disc"><li><p>You can configure your internal
systems to use your ISP's name servers. If you ISP gave you the
addresses of their servers or if those addresses are available on their
web site, you can configure your internal systems to use those addresses.
If that information isn't available, look in <tt class="filename">/etc/resolv.conf</tt>
on your firewall system -- the name servers are given in “<span class="quote">nameserver</span>”
records in that file.</p></li><li><p><img src="images/BD21298_.gif" /></p><p>You can
configure a <span class="emphasis"><em>Caching Name Server</em></span> on your firewall or
in your DMZ. <span class="trademark">Red Hat</span>™ has an RPM for a caching name
server (which also requires the '<span><b class="command">bind</b></span>' RPM) and
for Bering users, there is <tt class="filename">dnscache.lrp</tt>. If you take
this approach, you configure your internal systems to use the caching name
server as their primary (and only) name server. You use the internal IP
address of the firewall (<tt class="systemitem">10.10.10.254</tt>
in the example above) for the name server address if you choose to run the
name server on your firewall. To allow your local systems to talk to your
caching name server, you must open port 53 (both UDP and TCP) from the
local network to the server; you do that by adding the rules in
<tt class="filename">/etc/shorewall/rules</tt>.</p></li></ul></div><p>
If you run the name server on the firewall:
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowDNS loc fw
AllowDNS dmz fw </pre></td></tr></table><p> Run name server on DMZ
computer 1: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowDNS loc dmz:10.10.11.1
AllowDNS fw dmz:10.10.11.1 </pre></td></tr></table><p>In the rules shown above, “<span class="quote">AllowDNS</span>” is an example of a
<span class="emphasis"><em>defined action</em></span>. Shorewall includes a number of
defined actions and <a href="User_defined_Actions.html" target="_self">you can add
your own</a>. To see the list of actions included with your version of
Shorewall, look in the file <tt class="filename">/etc/shorewall/actions.std</tt>.
Those actions that accept connection requests have names that begin with
“<span class="quote">Allow</span>”.</p><p>You don't have to use defined actions when coding a rule in
<tt class="filename">/etc/shorewall/rules</tt>; the generated Netfilter ruleset
is slightly more efficient if you code your rules directly rather than
using defined actions. The first example above (name server on the
firewall) could also have been coded as follows:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc fw tcp 53
ACCEPT loc fw udp 53
ACCEPT dmz fw tcp 53
ACCEPT dmz fw udp 53 </pre></td></tr></table><p>In cases where Shorewall doesn't include a defined action to
meet your needs, you can either define the action yourself or you can
simply code the appropriate rules directly.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865536"></a>Other Connections</h2></div></div><div></div></div><p>The three-interface sample includes the following rule:
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowDNS fw net </pre></td></tr></table><p>That rule allow DNS access from
your firewall and may be removed if you commented out the line in
<tt class="filename">/etc/shorewall/policy</tt> allowing all connections from
the firewall to the internet.</p><p>The sample also includes: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowSSH loc fw
AllowSSH loc dmz </pre></td></tr></table><p>Those rules allow you to run
an SSH server on your firewall and in each of your DMZ systems and to
connect to those servers from your local systems.</p><p>If you wish to enable other connections between your systems, the
general format for using a defined action is:
</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
&lt;<span class="emphasis"><em>action</em></span>&gt; <span class="emphasis"><em>&lt;source zone&gt; &lt;destination zone&gt;</em></span></pre></td></tr></table><p>The general format when not using a defined action is:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT <span class="emphasis"><em>&lt;source zone&gt; &lt;destination zone&gt; &lt;protocol&gt; &lt;port&gt; </em></span></pre></td></tr></table><div class="example"><a id="id2865625"></a><p class="title"><b>Example 2. You want to run a publicly-available DNS server on your firewall
system</b></p><p>Using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowDNS net fw</pre></td></tr></table><p>Not using defined actions:</p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net fw tcp 53
ACCEPT net fw udp 53 </pre></td></tr></table><p>Those rules would of course be in addition to the rules listed
above under &quot;If you run the name server on your firewall&quot;.</p></div><p>If you don't know what port and protocol a particular
application uses, <a href="ports.htm" target="_self">look here</a>.</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>I don't recommend enabling telnet to/from the internet because
it uses clear text (even for login!). If you want shell access to your
firewall from the internet, use SSH: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
AllowSSH net fw</pre></td></tr></table></div><p><img src="images/leaflogo.gif" /> Bering
users will want to add the following two rules to be compatible with
Jacques's Shorewall configuration: </p><table border="0" bgcolor="#E0E0E0"><tr><td><pre class="programlisting">#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc fw udp 53
ACCEPT net fw tcp 80 </pre></td></tr></table><div class="itemizedlist"><ul type="disc"><li><p>Entry
1 allows the DNS Cache to be used.</p></li><li><p>Entry
2 allows the “<span class="quote">weblet</span>” to work.</p></li></ul></div><p><img src="images/BD21298_.gif" /></p><p>Now modify <tt class="filename">/etc/shorewall/rules</tt> to add or
remove other connections as required.</p></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865767"></a>Starting and Stopping Your Firewall</h2></div></div><div></div></div><p><img src="images/BD21298_.gif" /></p><p>The <a href="Install.htm" target="_self">installation procedure</a>
configures your system to start Shorewall at system boot but beginning
with Shorewall version 1.3.9 startup is disabled so that your system
won't try to start Shorewall before configuration is complete. Once
you have completed configuration of your firewall, you can enable
Shorewall startup by removing the file <tt class="filename">/etc/shorewall/startup_disabled</tt>.
</p><div class="important" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Important</h3><p>Users of the <tt class="filename">.deb</tt> package must edit
<tt class="filename">/etc/default/shorewall</tt> and set <tt class="varname">startup=1</tt>.</p></div><p>
The firewall is started using the <span><b class="command">shorewall start</b></span>
command and stopped using <span><b class="command">shorewall stop</b></span>. When the
firewall is stopped, routing is enabled on those hosts that have an entry
in <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
A running firewall may be restarted using the <span><b class="command">shorewall restart</b></span>
command. If you want to totally remove any trace of Shorewall from your
Netfilter configuration, use <span><b class="command">shorewall clear</b></span>.</p><p><img src="images/BD21298_.gif" /></p><p>The three-interface sample assumes that you want to enable routing
to/from <tt class="filename">eth1</tt> (your local network)
and <tt class="filename">eth2</tt> (DMZ) when Shorewall is
stopped. If these two interfaces don't connect to your local network
and DMZ or if you want to enable a different set of hosts, modify
<tt class="filename">/etc/shorewall/routestopped</tt> accordingly.
</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p>If you are connected to your firewall from the internet, do
not issue a <span><b class="command">shorewall stop</b></span> command unless you have
added an entry for the IP address that you are connected from to <a href="Documentation.htm#Routestopped" target="_self"><tt class="filename">/etc/shorewall/routestopped</tt></a>.
Also, I don't recommend using <span><b class="command">shorewall restart</b></span>; it
is better to create an <a href="configuration_file_basics.htm#Levels" target="_self">alternate
configuration</a> and test it using the <a href="starting_and_stopping_shorewall.htm" target="_self"><span><b class="command">shorewall try</b></span>
command</a>.</p></div></div><div class="section" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2865997"></a>Additional Recommended Reading</h2></div></div><div></div></div><p>I highly recommend that you review the <a href="configuration_file_basics.htm" target="_self">Common Configuration File Features</a>
page -- it contains helpful tips about Shorewall features than make
administering your firewall easier.</p></div></div></body></html>

10
Shorewall-docs2/three-interface.xml
View File

@ -357,6 +357,16 @@ fw net ACCEPT</programlisting>
or <filename class="devicefile">ippp0</filename> or if you have a static
IP address, you can remove <quote>dhcp</quote> from the option list.</para>
</tip>
<tip>
<para>If you specify <emphasis>norfc1918</emphasis> for your external
interface, you will want to check the <ulink url="errata.htm">Shorewall
Errata</ulink> periodically for updates to the <filename>/usr/share/shorewall/rfc1918
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
file as I do</ulink>.</para>
</tip>
</section>
<section>

49
Shorewall-docs2/troubleshoot.xml
View File

@ -13,7 +13,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2004-01-06</pubdate>
<pubdate>2004-02-02</pubdate>
<copyright>
<year>2001-2004</year>
@ -119,6 +119,50 @@ iptables: No chain/target/match by that name
</example>
</section>
<section>
<title>Some Things to Keep in Mind</title>
<itemizedlist>
<listitem>
<para><emphasis role="bold">You cannot test your firewall from the
inside</emphasis>. Just because you send requests to your firewall
external IP address does not mean that the request will be associated
with the external interface or the <quote>net</quote> zone. Any
traffic that you generate from the local network will be associated
with your local interface and will be treated as loc-&#62;fw traffic.</para>
</listitem>
<listitem>
<para><emphasis role="bold">IP addresses are properties of systems,
not of interfaces</emphasis>. It is a mistake to believe that your
firewall is able to forward packets just because you can ping the IP
address of all of the firewall&#39;s interfaces from the local
network. The only conclusion you can draw from such pinging success is
that the link between the local system and the firewall works and that
you probably have the local system&#39;s default gateway set
correctly.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Reply packets do NOT automatically follow
the reverse path of the one taken by the original request</emphasis>.
All packets are routed according to the routing table of the host at
each step of the way. This issue commonly comes up when people install
a Shorewall firewall parallel to an existing gateway and try to use
DNAT through Shorewall without changing the default gateway of the
system receiving the forwarded requests. Requests come in through the
Shorewall firewall where the destination IP address gets rewritten but
replies go out unmodified through the old gateway.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Shorewall itself has no notion of inside
or outside</emphasis>. These concepts are embodied in how Shorewall is
configured. </para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Your Network Environment</title>
@ -355,7 +399,8 @@ DROP net fw icmp echo-request</programlist
<appendix>
<title>Revision History</title>
<para><revhistory><revision><revnumber>1.6</revnumber><date>2005-01-06</date><authorinitials>TE</authorinitials><revremark>Add
<para><revhistory><revision><revnumber>1.7</revnumber><date>2005-02-02</date><authorinitials>TE</authorinitials><revremark>Add
hint about testing from inside the firewall.</revremark></revision><revision><revnumber>1.6</revnumber><date>2005-01-06</date><authorinitials>TE</authorinitials><revremark>Add
pointer to Site and Mailing List Archives Searches.</revremark></revision><revision><revnumber>1.5</revnumber><date>2004-01-01</date><authorinitials>TE</authorinitials><revremark>Added
information about eliminating ping-generated log messages.</revremark></revision><revision><revnumber>1.4</revnumber><date>2003-12-22</date><authorinitials>TE</authorinitials><revremark>Initial
Docbook Conversion</revremark></revision></revhistory></para>

46
Shorewall-docs2/two-interface.xml
View File

@ -12,7 +12,7 @@
<surname>Eastep</surname>
</author>
<pubdate>2003-02-08</pubdate>
<pubdate>2003-03-16</pubdate>
<copyright>
<year>2002</year>
@ -83,14 +83,15 @@
<varname>loc</varname>). We therefore recommend that once you have set up
this sharing that you uninstall the <trademark>Mandrake</trademark>
Shorewall RPM and install the one from the <ulink url="download.htm">download</ulink>
page then follow the instructions in this Guide.</para></tip>
<caution><para>If you edit your configuration files on a
<trademark>Windows</trademark> system, you must save them as
<trademark>Unix</trademark> files if your editor supports that option or
you must run them through <command>dos2unix</command> before trying to use
them. Similarly, if you copy a configuration file from your
<trademark>Windows</trademark> hard drive to a floppy disk, you must run
<command>dos2unix</command> against the copy before using it with
page then follow the instructions in this Guide.</para></tip><note><para><emphasis
role="bold">The above Shorewall Issue is corrected in Mandrake 10.0 and
later.</emphasis></para></note> <caution><para>If you edit your
configuration files on a <trademark>Windows</trademark> system, you must
save them as <trademark>Unix</trademark> files if your editor supports
that option or you must run them through <command>dos2unix</command>
before trying to use them. Similarly, if you copy a configuration file
from your <trademark>Windows</trademark> hard drive to a floppy disk, you
must run <command>dos2unix</command> against the copy before using it with
Shorewall. <itemizedlist><listitem><para><ulink
url="http://www.simtel.net/pub/pd/51438.html"><trademark>Windows</trademark>
Version of <command>dos2unix</command></ulink></para></listitem><listitem><para><ulink
@ -262,15 +263,24 @@ fw net ACCEPT</programlisting> The above policy will:
your configuration is different, you will have to modify the sample
<filename class="directory">/etc/shorewall/</filename><filename>interfaces</filename>
file accordingly. While you are there, you may wish to review the list of
options that are specified for the interfaces. Some hints: <itemizedlist
spacing="compact"><listitem><para>If your external interface is <filename
class="devicefile">ppp0</filename> or <filename class="devicefile">ippp0</filename>,
you can replace the <varname>detect</varname> in the second column with a
<quote>-</quote> (minus the quotes).</para></listitem><listitem><para>If
options that are specified for the interfaces. Some hints: <tip><para>If
your external interface is <filename class="devicefile">ppp0</filename> or
<filename class="devicefile">ippp0</filename> or if you have a static
<filename class="devicefile">ippp0</filename>, you can replace the
<varname>detect</varname> in the second column with a <quote>-</quote>
(minus the quotes).</para></tip><tip><para>If your external interface is
<filename class="devicefile">ppp0</filename> or <filename
class="devicefile">ippp0</filename> or if you have a static
<acronym>IP</acronym> address, you can remove <varname>dhcp</varname> from
the option list.</para></listitem></itemizedlist></para>
the option list.</para></tip><tip><para>If your internal interface is a
bridge create using the <command>brctl</command> utility then you must add
the <varname>routeback</varname> option to the option list.</para></tip><tip><para>If
you specify <emphasis>norfc1918</emphasis> for your external interface,
you will want to check the <ulink url="errata.htm">Shorewall Errata</ulink>
periodically for updates to the <filename>/usr/share/shorewall/rfc1918
file</filename>. Alternatively, you can copy <filename>/usr/share/shorewall/rfc1918</filename>
to <filename>/etc/shorewall/rfc1918</filename> then <ulink
url="myfiles.htm#RFC1918">strip down your <filename>/etc/shorewall/rfc1918</filename>
file as I do</ulink>.</para></tip></para>
</section>
<section>
@ -659,7 +669,7 @@ ACCEPT loc fw tcp 80 #Allow Weblet to work</progra
traffic may flow freely between the local wired network and the wireless
network.</para>
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /> </para>
<para><inlinegraphic fileref="images/BD21298_.gif" format="GIF" /></para>
<para>There are only two changes that need to be made to the Shorewall
configuration:</para>
@ -701,6 +711,6 @@ eth0 wlan0</programlisting>
either a WINS server or a PDC. I personally use Samba configured as a WINS
server running on my firewall. Running a WINS server on your firewall
requires the rules listed in the <ulink url="samba.htm">Shorewall/Samba
documentation</ulink>. </para>
documentation</ulink>.</para>
</section>
</article>