extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-28 02:23:20 +01:00
Code Issues Packages Projects Releases Wiki Activity
bf9e1ef4ed
shorewall_code/Shorewall-docs2/Documentation.html
teastep a44e4a46f8 Initial revision 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1143 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2004-02-14 18:06:39 +00:00

929 lines
119 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?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>
Reference in New Issue View Git Blame Copy Permalink