extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-15 04:04:10 +01:00
Code Issues Packages Projects Releases Wiki Activity
53a9e87cd9
shorewall_code/Shorewall-docs/Documentation.xml
mhnoyes 3783c77ff2 added Article ID 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@842 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-12-13 07:16:11 +00:00

4514 lines
143 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Documentation">
<articleinfo>
<title>Shorewall 1.4 Reference</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<pubdate>2003-12-08</pubdate>
<abstract>
<para>This documentation is intended primarily for reference.
Step-by-step instructions for configuring Shorewall in common setups may
be found in the <ulink url="shorewall_quickstart_guide.htm">QuickStart
Guides</ulink>.</para>
</abstract>
</articleinfo>
<section>
<title>Components</title>
<para>Shorewall consists of the following components:</para>
<variablelist>
<varlistentry>
<term><link linkend="Variables">params</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall that can be used
to establish the values of shell variables for use in other files.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Conf">shorewall.conf</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall that is used to
set several firewall parameters.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Zones">zones</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall that defines a
network partitioning into &#34;zones&#34;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Policy">policy</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall/ that establishes
overall firewall policy.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Rules">rules</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall and used to
express firewall rules that are exceptions to the high-level
policies established in /etc/shorewall/policy.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Blacklist">blacklist</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall and used to list
blacklisted IP/subnet/MAC addresses.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="ECN">ecn</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall and used to
selectively disable Explicit Congestion Notification (ECN - RFC
3168).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>functions</term>
<listitem>
<para>a set of shell functions used by both the firewall and
shorewall shell programs. Installed in /etc/shorewall prior to
version 1.3.2, in /var/lib/shorewall in version s 1.3.2-1.3.8 and in
/usr/lib/shorewall in later versions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="modules">modules</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall and that
specifies kernel modules and their parameters. Shorewall will
automatically load the modules specified in this file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="TOS">tos</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall that is used to
specify how the Type of Service (TOS) field in packets is to be set.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>common.def</term>
<listitem>
<para>a parameter file installed in in /etc/shorewall that defines
firewall-wide rules that are applied before a DROP or REJECT policy
is applied.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>init.sh</term>
<listitem>
<para>a shell script installed in /etc/init.d to automatically start
Shorewall during boot.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Interfaces">interfaces</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall/ and used to
describe the interfaces on the firewall system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Hosts">hosts</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall/ and used to
describe individual hosts or subnetworks in zones.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Maclist">maclist</link></term>
<listitem>
<para>a parameter file installed in /etc/shorewall and used to
verify the MAC address (and possibly also the IP address(es)) of
devices.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Masq">masq</link></term>
<listitem>
<para>This file also describes IP masquerading under Shorewall and
is installed in /etc/shorewall.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>firewall</term>
<listitem>
<para>a shell program that reads the configuration files in
/etc/shorewall and configures your firewall. This file is installed
in /usr/share/shorewall.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="NAT">nat</link></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define <link
linkend="NAT">one-to-one NAT</link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="ProxyArp">proxyarp</link></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define <link
linkend="ProxyArp">Proxy Arp</link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="rfc1918">rfc1918</link></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define the
treatment of packets under the <link linkend="Interfaces">norfc1918
interface option</link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Routestopped">routestopped</link></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define those hosts
that can access the firewall when Shorewall is stopped.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><ulink url="traffic_shaping.htm#tcrules">tcrules</ulink></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define rules for
classifying packets for <ulink url="traffic_shaping.htm">Traffic
Shaping/Control</ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><link linkend="Tunnels">tunnels</link></term>
<listitem>
<para>a parameter file in /etc/shorewall used to define IPSec
tunnels.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>shorewall</term>
<listitem>
<para>a shell program (requiring a Bourne shell or derivative) used
to control and monitor the firewall. This should be placed in /sbin
or in /usr/sbin (the install.sh script and the rpm install this file
in /sbin).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>accounting</term>
<listitem>
<para>a parameter file in /etc/shorewall used to define traffic
accounting rules. This file was added in version 1.4.7.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>version</term>
<listitem>
<para>a file created in /etc/shorewall/ (/var/lib/shorewall in
version 1.3.2-1.3.8 and /usr/lib/shorewall beginning in version
1.3.9) that describes the version of Shorewall installed on your
system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><ulink url="UserSets.html">users and usersets</ulink></term>
<listitem>
<para>files in /etc/shorewall allowing connections originating on
the firewall to be policed by the user id and/or group id of the
user.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>actions and action.template</term>
<listitem>
<para>files in /etc/shorewall that allow you to define your own
actions for rules in /etc/shorewall/rules.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="Variables" xreflabel="/etc/shorewall/params">
<title>/etc/shorewall/params</title>
<para>You may use the file /etc/shorewall/params file to set shell
variables that you can then use in some of the other configuration files.</para>
<para>It is suggested that variable names begin with an upper case letter
to distinguish them from variables used internally within the Shorewall
programs</para>
<example>
<title>shell variables</title>
<programlisting>NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=blacklist,norfc1918</programlisting>
</example>
<example>
<title>/etc/shorewall/interfaces record</title>
<programlisting>net $NET_IF $NET_BCAST $NET_OPTIONS</programlisting>
</example>
<para>The result will be the same as if the record had been written</para>
<programlisting>net eth0 130.252.100.255 blacklist,norfc1918</programlisting>
<para>Variables may be used anywhere in the other configuration files.</para>
</section>
<section id="Zones" xreflabel="/etc/shorewall/zones">
<title>/etc/shorewall/zones</title>
<para>This file is used to define the network zones. There is one entry in
/etc/shorewall/zones for each zone; Columns in an entry are:</para>
<variablelist>
<varlistentry>
<term>ZONE</term>
<listitem>
<para>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
&#34;all&#34; may not be used as a zone name nor may the zone name
assigned to the firewall itself via the FW variable in <xref
linkend="Conf" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DISPLAY</term>
<listitem>
<para>The name of the zone as displayed during Shorewall startup.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>COMMENTS</term>
<listitem>
<para>Any comments that you want to make about the zone. Shorewall
ignores these comments.</para>
</listitem>
</varlistentry>
</variablelist>
<table>
<title>/etc/shorewall/zones file released with Shorewall</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>Net</entry>
<entry>Internet</entry>
</row>
<row>
<entry>loc</entry>
<entry>Local</entry>
<entry>Local networks</entry>
</row>
<row>
<entry>dmz</entry>
<entry>DMZ</entry>
<entry>Demilitarized zone</entry>
</row>
</tbody>
</tgroup>
</table>
<para>You may add, delete and modify entries in the /etc/shorewall/zones
file as desired so long as you have at least one zone defined.</para>
<warning>
<para>If you rename or delete a zone, you should perform &#34;shorewall
stop; shorewall start&#34; to install the change rather than
&#34;shorewall restart&#34;.</para>
</warning>
<warning>
<para>The order of entries in the /etc/shorewall/zones file is
significant <link linkend="Nested">in some cases</link>.</para>
</warning>
</section>
<section id="Interfaces" xreflabel="/etc/shorewall/interfaces">
<title>/etc/shorewall/interfaces</title>
<para>This file is used to tell the firewall which of your firewall&#39;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:</para>
<variablelist>
<varlistentry>
<term>ZONE</term>
<listitem>
<para>A zone defined in the <xref linkend="Zones" /> file or
&#34;-&#34;. If you specify &#34;-&#34;, you must use the <xref
linkend="Hosts" /> file to define the zones accessed via this
interface.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>the name of the interface (examples: eth0, ppp0, ipsec+). Each
interface can be listed on only one record in this file.</para>
<warning>
<para><emphasis role="bold">DO NOT INCLUDE THE LOOPBACK INTERFACE
(lo) IN THIS FILE!!!</emphasis></para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term>BROADCAST</term>
<listitem>
<para>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
&#34;-&#34; in this column. If you supply the special value
&#34;detect&#34; in this column, the firewall will automatically
determine the broadcast address. In order to use &#34;detect&#34;:</para>
<itemizedlist>
<listitem>
<para>the interface must be up before you start your firewall</para>
</listitem>
<listitem>
<para>the interface must only be attached to a single
sub-network (i.e., there must have a single broadcast address).</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>OPTIONS</term>
<listitem>
<para>a comma-separated list of options. Possible options include:</para>
<variablelist>
<varlistentry>
<term>arp_filter</term>
<listitem>
<para>(Added in version 1.4.7) - This option causes
/proc/sys/net/ipv4/conf/&#60;interface&#62;/arp_filter to be
set with the result that this interface will only answer ARP
&#39;who-has&#39; 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>newnotsyn</term>
<listitem>
<para>(Added in version 1.4.6) - This option overrides <link
linkend="Conf">NEWNOTSYN=No</link> 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 <xref linkend="Conf" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>routeback</term>
<listitem>
<para>(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 &#34;-&#34;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>tcpflags</term>
<listitem>
<para>(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 &#34;silent&#34; port scans. Packets
failing these checks are logged according to the
TCP_FLAGS_LOG_LEVEL option in <xref linkend="Conf" /> and are
disposed of according to the TCP_FLAGS_DISPOSITION option.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>blacklist</term>
<listitem>
<para>This option causes incoming packets on this interface to
be checked against the <link linkend="Blacklist">blacklist</link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>dhcp</term>
<listitem>
<para>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 <emphasis role="bold">norfc1918</emphasis> option
(see below).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>norfc1918</term>
<listitem>
<para>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 <link
linkend="Conf">packet mangling is enabled in
/etc/shorewall/shorewall.conf</link> , 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.</para>
<para>Addresses blocked by the standard <link
linkend="rfc1918">rfc1918 file</link> include those addresses
reserved by RFC1918 plus other ranges reserved by the IANA or
by other RFCs.</para>
<para>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
&#34;modems&#34; have an RFC 1918 address that can be used
through a web browser for management and monitoring functions.
If you want to specify <emphasis role="bold">norfc1918</emphasis>
on your external interface but need to allow access to certain
addresses from the above list, see <ulink url="FAQ.htm#faq14">FAQ
14</ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>routefilter</term>
<listitem>
<para>Invoke the Kernel&#39;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.</para>
<warning>
<para>If you specify this option for an interface then the
interface must be up prior to starting the firewall.</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term>dropunclean</term>
<listitem>
<para>Packets from this interface that are selected by the
&#39;unclean&#39; match target in iptables will be optionally
logged and then dropped.</para>
<warning>
<para>This feature requires that UNCLEAN match support be
configured in your kernel, either in the kernel itself or as
a module. UNCLEAN support is broken in some versions of the
kernel but appears to work ok in 2.4.17-rc1.</para>
<para><emphasis role="bold">Update 12/17/2001:</emphasis>
The unclean match patch from 2.4.17-rc1 is <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean.patch">available
for download</ulink>. I am currently running this patch
applied to kernel 2.4.16.</para>
<para><emphasis role="bold">Update 12/20/2001:</emphasis>
I&#39;ve seen a number of tcp connection requests with OPT
(020405B4<emphasis role="bold">0000080A</emphasis>...) being
dropped in the <emphasis>badpkt</emphasis> chain. This
appears to be a bug in the remote TCP stack whereby it is
8-byte aligning a timestamp (TCP option 8) but rather than
padding with 0x01 it is padding with 0x00. It&#39;s a tough
call whether to deny people access to your servers because
of this rather minor bug in their networking software. If
you wish to disable the check that causes these connections
to be dropped, <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">here&#39;s
a kernel patch</ulink> against 2.4.17-rc2.</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term>logunclean</term>
<listitem>
<para>This option works like <emphasis role="bold">dropunclean</emphasis>
with the exception that packets selected by the
&#39;unclean&#39; match target in iptables are logged
<emphasis>but not dropped</emphasis>. The level at which the
packets are logged is determined by the setting of LOGUNCLEAN
and if LOGUNCLEAN has not been set, &#34;info&#34; is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>proxyarp</term>
<listitem>
<para>(Added in version 1.3.5) - This option causes Shorewall
to set /proc/sys/net/ipv4/conf/&#60;<emphasis>interface</emphasis>&#62;/proxy_arp
and is used when implementing Proxy ARP Sub-netting as
described at <ulink
url="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</ulink>.
Do <emphasis role="bold">not</emphasis> set this option if you
are implementing Proxy ARP through entries in <xref
linkend="ProxyArp" />.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>maclist</term>
<listitem>
<para>(Added in version 1.3.10) - If this option is specified,
all connection requests from this interface are subject to
<ulink url="MAC_Validation.html">MAC Verification</ulink>. May
only be specified for ethernet interfaces.</para>
</listitem>
</varlistentry>
</variablelist>
<para>My recommendations concerning options:</para>
<itemizedlist>
<listitem>
<para>External Interface -- <emphasis role="bold">tcpflags,blacklist,norfc1918,routefilter</emphasis></para>
</listitem>
<listitem>
<para>Wireless Interface -- <emphasis role="bold">maclist,routefilter,tcpflags</emphasis></para>
</listitem>
<listitem>
<para>Don&#39;t use <emphasis role="bold">dropunclean</emphasis>
-- It&#39;s broken in my opinion</para>
</listitem>
<listitem>
<para>Use <emphasis role="bold">logunclean</emphasis> only when
you are trying to debug a problem</para>
</listitem>
<listitem>
<para>Use <emphasis role="bold">dhcp</emphasis> and <emphasis
role="bold">proxyarp</emphasis> when needed.</para>
</listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
<example>
<title>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 <link linkend="Blacklist">black list</link>.
Your /etc/shorewall/interfaces file would be as follows:</title>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>eth0</entry>
<entry>detect</entry>
<entry>dhcp,norfc1918,blacklist</entry>
</row>
<row>
<entry>loc</entry>
<entry>eth1</entry>
<entry>detect</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>You have a standalone dialup GNU/Linux System. Your
/etc/shorewall/interfaces file would be:</title>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>ppp0</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</title>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>eth1</entry>
<entry>192.168.1.255,192.168.12.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
</section>
<section id="Hosts" xreflabel="/etc/shorewall/hosts">
<title>/etc/shorewall/hosts Configuration</title>
<para>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 /etc/shorewall/hosts file.</para>
<warning>
<para>The only times that you need entries in /etc/shorewall/hosts are:</para>
<orderedlist>
<listitem>
<para>You have more than one zone connecting through a single
interface; or</para>
</listitem>
<listitem>
<para>You have a zone that has multiple subnetworks that connect
through a single interface and you want the Shorewall box to route
traffic between those subnetworks.</para>
</listitem>
</orderedlist>
<para><emphasis role="bold">IF YOU DON&#39;T HAVE EITHER OF THOSE
SITUATIONS THEN DON&#39;T TOUCH THIS FILE!!</emphasis></para>
</warning>
<para>Columns in this file are:</para>
<variablelist>
<varlistentry>
<term>ZONE</term>
<listitem>
<para>A zone defined in the <xref linkend="Zones" /> file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>HOST(S)</term>
<listitem>
<para>The name of a network interface followed by a colon
(&#34;:&#34;) followed by a comma-separated list either:</para>
<orderedlist>
<listitem>
<para>An IP address (example - eth1:192.168.1.3)</para>
</listitem>
<listitem>
<para>A subnet in CIDR notation (example - eth2:192.168.2.0/24)</para>
</listitem>
</orderedlist>
<para>The interface name much match an entry in
/etc/shorewall/interfaces.</para>
<warning>
<para>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 /etc/shorewall/hosts.</para>
</warning>
</listitem>
</varlistentry>
<varlistentry>
<term>OPTIONS</term>
<listitem>
<para>A comma-separated list of option</para>
<variablelist>
<varlistentry>
<term>routeback</term>
<listitem>
<para>(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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>maclist</term>
<listitem>
<para>Added in version 1.3.10. If specified, connection
requests from the hosts specified in this entry are subject to
<ulink url="MAC_Validation.html">MAC Verification</ulink>.
This option is only valid for ethernet interfaces.</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
</variablelist>
<para>If you don&#39;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.</para>
<note>
<para>You probably DON&#39;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.</para>
</note>
<example>
<title>Your local interface is eth1 and you have two groups of local
hosts that you want to make into separate zones:</title>
<programlisting>192.168.1.0/25
192.168.1.128/</programlisting>
<para>Your /etc/shorewall/interfaces file might look like:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>eth0</entry>
<entry>detect</entry>
<entry>dhcp,norfc1918</entry>
</row>
<row>
<entry>-</entry>
<entry>eth1</entry>
<entry>192.168.1.127,192.168.1.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>The &#39;-&#39; in the ZONE column for eth1 tells Shorewall that
eth1 interfaces to multiple zones.</para>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">HOST(S)</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc1</entry>
<entry>eth1:192.168.1.0/25</entry>
<entry></entry>
</row>
<row>
<entry>loc2</entry>
<entry>eth1:192.168.1.128/25</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</title>
<programlisting>192.168.1.0/25
192.168.1.128/25</programlisting>
<para>Your /etc/shorewall/interfaces file might look like:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>eth0</entry>
<entry>detect</entry>
<entry>dhcp,norfc1918</entry>
</row>
<row>
<entry>loc</entry>
<entry>eth1</entry>
<entry>192.168.1.127,192.168.1.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Your /etc/shorewall/hosts file might look like:</para>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">HOST(S)</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>eth1:192.168.1.0/25</entry>
<entry></entry>
</row>
<row>
<entry>loc</entry>
<entry>eth1:192.168.1.128/25</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>If you are running Shorewall 1.4.6 or later, your hosts file may
look like:</para>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">HOST(S)</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>eth1:192.168.1.0/25,192.168.1.128/25</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<section id="Nested">
<title>Nested and Overlapping Zones</title>
<para>The /etc/shorewall/interfaces and /etc/shorewall/hosts 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 /etc/shorewall/zones 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
/etc/shorewall/zones.</para>
<para>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
<link linkend="CONTINUE">CONTINUE policy</link> described below.</para>
</section>
</section>
<section id="Policy" xreflabel="/etc/shorewall/policy">
<title>/etc/shorewall/policy Configuration</title>
<para>This file is used to describe the firewall policy regarding
establishment of connections. Connection establishment is described in
terms of <emphasis>clients</emphasis> who initiate connections and
<emphasis>servers</emphasis> who receive those connection requests.
Policies defined in /etc/shorewall/policy describe which zones are allowed
to establish connections with other zones.</para>
<para>Policies established in /etc/shorewall/policy can be viewed as
default policies. If no rule in /etc/shorewall/rules applies to a
particular connection request then the policy from /etc/shorewall/policy
is applied.</para>
<para>Four policies are defined:</para>
<variablelist>
<varlistentry>
<term>ACCEPT</term>
<listitem>
<para>The connection is allowed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DROP</term>
<listitem>
<para>The connection request is ignored.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REJECT</term>
<listitem>
<para>The connection request is rejected with an RST (TCP) or an
ICMP destination-unreachable packet being returned to the client.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CONTINUE</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NONE</term>
<listitem>
<para>(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 <emphasis role="bold">LOG
LEVEL</emphasis> and <emphasis role="bold">BURST:LIMIT</emphasis>
columns must be left blank.</para>
</listitem>
</varlistentry>
</variablelist>
<para>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.</para>
<para>Entries in /etc/shorewall/policy have four columns as follows:</para>
<variablelist>
<varlistentry>
<term>SOURCE</term>
<listitem>
<para>The name of a client zone (a zone defined in the <xref
linkend="Zones" /> file , the <link linkend="Conf">name of the
firewall zone</link> or &#34;all&#34;).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DEST</term>
<listitem>
<para>The name of a destination zone (a zone defined in the <xref
linkend="Zones" /> file , the <link linkend="Conf">name of the
firewall zone</link> or &#34;all&#34;). Shorewall automatically
allows all traffic from the firewall to itself so the <link
linkend="Conf">name of the firewall zone</link> cannot appear in
both the SOURCE and DEST columns.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>POLICY</term>
<listitem>
<para>The default policy for connection requests from the SOURCE
zone to the DESTINATION zone.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOG LEVEL</term>
<listitem>
<para>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 <ulink url="shorewall_logging.html">syslog
level</ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIMIT:BURST - optional</term>
<listitem>
<para>If left empty, TCP connection requests from the <emphasis
role="bold">SOURCE</emphasis> zone to the <emphasis role="bold">DEST</emphasis>
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 (&#34;:&#34;) followed by the maximum burst size
that will be tolerated. Example: <emphasis role="bold">10/sec:40</emphasis>
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 <link linkend="Rules">rules file documentation</link>
for an explaination of how rate limiting works.</para>
</listitem>
</varlistentry>
</variablelist>
<para>In the SOURCE and DEST columns, you can enter &#34;all&#34; to
indicate all zones.</para>
<table>
<title>policy file installed by default</title>
<tgroup cols="5">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
<entry align="center">LIMIT:BURST</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>net</entry>
<entry>ACCEPT</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>net</entry>
<entry>all</entry>
<entry>DROP</entry>
<entry>info</entry>
<entry></entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>REJECT</entry>
<entry>info</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>This table may be interpreted as follows:</para>
<itemizedlist>
<listitem>
<para>All connection requests from the local network to hosts on the
internet are accepted.</para>
</listitem>
<listitem>
<para>All connection requests originating from the internet are
ignored and logged at level KERNEL.INFO.</para>
</listitem>
<listitem>
<para>All other connection requests are rejected and logged.</para>
</listitem>
</itemizedlist>
<warning>
<para>The firewall script processes the /etc/shorewall/policy file from
top to bottom and <emphasis role="bold">uses the first applicable policy
that it finds</emphasis>. 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.</para>
<informaltable>
<tgroup cols="5">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
<entry align="center">LIMIT:BURST</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>all</entry>
<entry>ACCEPT</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>net</entry>
<entry>all</entry>
<entry>DROP</entry>
<entry>info</entry>
<entry></entry>
</row>
<row>
<entry>loc</entry>
<entry>loc</entry>
<entry>REJECT</entry>
<entry>info</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</warning>
<section>
<title>IntraZone Traffic</title>
<para>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 &#34;all&#34; 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.</para>
<para>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:</para>
<orderedlist>
<listitem>
<para>Multiple &#39;net&#39; interfaces to different ISPs. You
don&#39;t want to route traffic from one ISP to the other through
your firewall.</para>
</listitem>
<listitem>
<para>Multiple VPN clients. You don&#39;t necessarily want them to
all be able to communicate between themselves using your
gateway/router.</para>
</listitem>
</orderedlist>
</section>
<section id="CONTINUE">
<title>The CONTINUE policy</title>
<para>Where zones are <link linkend="Nested">nested or overlapping</link>,
the CONTINUE policy allows hosts that are within multiple zones to be
managed under the rules of all of these zones. Let&#39;s look at an
example:</para>
<table>
<title>/etc/shorewall/zones</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>sam</entry>
<entry>Sam</entry>
<entry>Sam&#39;s system at home</entry>
</row>
<row>
<entry>net</entry>
<entry>Internet</entry>
<entry>The Internet</entry>
</row>
<row>
<entry>loc</entry>
<entry>Loc</entry>
<entry>Local Network</entry>
</row>
</tbody>
</tgroup>
</table>
<table>
<title>/etc/shorewall/interfaces</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>-</entry>
<entry>eth0</entry>
<entry>detect</entry>
<entry>dhcp,norfc1918</entry>
</row>
<row>
<entry>loc</entry>
<entry>eth1</entry>
<entry>detect</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<table>
<title>/etc/shorewall/hosts</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">HOST(S)</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>net</entry>
<entry>eth0:0.0.0.0/0</entry>
<entry></entry>
</row>
<row>
<entry>sam</entry>
<entry>eth0:206.191.149.197</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<note>
<para>Sam&#39;s home system is a member of both the <emphasis
role="bold">sam</emphasis> zone and the <emphasis role="bold">net</emphasis>
zone and <link linkend="Nested">as described above</link> , that means
that <emphasis role="bold">sam</emphasis> must be listed before
<emphasis role="bold">net</emphasis> in /etc/shorewall/zones.</para>
</note>
<table>
<title>/etc/shorewall/policy</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>net</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>sam</entry>
<entry>all</entry>
<entry>CONTINUE</entry>
<entry></entry>
</row>
<row>
<entry>net</entry>
<entry>all</entry>
<entry>DROP</entry>
<entry>info</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>REJECT</entry>
<entry>info</entry>
</row>
</tbody>
</tgroup>
</table>
<para>The second entry above says that when Sam is the client,
connection requests should first be process under rules where the source
zone is <emphasis role="bold">sam</emphasis> and if there is no match
then the connection request should be treated under rules where the
source zone is <emphasis role="bold">net</emphasis>. It is important
that this policy be listed BEFORE the next policy (<emphasis role="bold">net</emphasis>
to <emphasis role="bold">all</emphasis>).</para>
<table>
<title>Partial /etc/shorewall/rules</title>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>...</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>sam</entry>
<entry>loc:192.168.1.3</entry>
<entry>tcp</entry>
<entry>ssh</entry>
<entry>-</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>net</entry>
<entry>loc:192.168.1.5</entry>
<entry>tcp</entry>
<entry>www</entry>
<entry>-</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>...</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>Given these two rules, Sam can connect to the firewall&#39;s
internet interface with ssh and the connection request will be forwarded
to 192.168.1.3. Like all hosts in the <emphasis role="bold">net</emphasis>
zone, Sam can connect to the firewall&#39;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.</para>
<para id="Exclude">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&#39;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:</para>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>...</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>sam</entry>
<entry>fw</entry>
<entry>tcp</entry>
<entry>ssh</entry>
<entry>-</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>net!sam</entry>
<entry>loc:192.168.1.3</entry>
<entry>tcp</entry>
<entry>ssh</entry>
<entry>-</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>...</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>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 &#39;sam&#39; 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.</para>
</section>
</section>
<section id="Rules" xreflabel="/etc/shorewall/rules">
<title>/etc/shorewall/rules</title>
<para>The /etc/shorewall/rules file defines exceptions to the policies
established in the /etc/shorewall/policy file. There is one entry in
/etc/shorewall/rules for each of these rules.</para>
<para>Shorewall automatically enables firewall-&#62;firewall traffic over
the loopback interface (lo) -- that traffic cannot be regulated using
rules and any rule that tries to regulate such traffic will generate a
warning and will be ignored.</para>
<para>Entries in the file have the following columns:</para>
<variablelist>
<varlistentry>
<term>ACTION</term>
<listitem>
<variablelist>
<varlistentry>
<term>ACCEPT, DROP, REJECT, CONTINUE</term>
<listitem>
<para>These have the same meaning here as in the policy file
above.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DNAT</term>
<listitem>
<para>Causes the connection request to be forwarded to the
system specified in the DEST column (port forwarding).
&#34;DNAT&#34; stands for &#34;<emphasis role="bold">D</emphasis>estination
<emphasis role="bold">N</emphasis>etwork <emphasis role="bold">A</emphasis>ddress
<emphasis role="bold">T</emphasis>ranslation&#34;</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DNAT-</term>
<listitem>
<para>The above ACTION (DNAT) generates two iptables rules:</para>
<orderedlist>
<listitem>
<para>a header-rewriting rule in the Netfilter
&#39;nat&#39; table</para>
</listitem>
<listitem>
<para>an ACCEPT rule in the Netfilter &#39;filter&#39;
table. DNAT- works like DNAT but only generates the
header-rewriting rule.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>REDIRECT</term>
<listitem>
<para>Causes the connection request to be redirected to a port
on the local (firewall) system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REDIRECT-</term>
<listitem>
<para>The above ACTION (REDIRECT) generates two iptables
rules:</para>
<orderedlist>
<listitem>
<para>a header-rewriting rule in the Netfilter
&#39;nat&#39; table</para>
</listitem>
<listitem>
<para>an ACCEPT rule in the Netfilter &#39;filter&#39;
table. REDIRECT- works like REDIRECT but only generates
the header-rewriting rule.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>
<varlistentry>
<term>LOG</term>
<listitem>
<para>Log the packet -- requires a syslog level (see below).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>QUEUE</term>
<listitem>
<para>Forward the packet to a user-space application. This
facility is provided to allow interfacing to <ulink
url="http://p2pwall.sourceforge.net">ftwall</ulink> for <ulink
url="Shorewall_and_Kazaa.html">Kazaa filtering</ulink>.</para>
<note>
<para>When the protocol specified in the PROTO column is TCP
(&#34;tcp&#34;, &#34;TCP&#34; or &#34;6&#34;), Shorewall
will only pass connection requests (SYN packets) to user
space. This is for compatibility with ftwall.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term><ulink url="User_defined_Actions.html">&#60;user-defined
action&#62;</ulink></term>
<listitem>
<para>(Shorewall 1.4.9 and later)</para>
</listitem>
</varlistentry>
</variablelist>
<para>Beginning with Shorewall version 1.4.7, you may rate-limit the
rule by optionally following ACCEPT, DNAT[-], REDIRECT[-] or LOG
with</para>
<programlisting>&#60; &#60;rate&#62;/&#60;interval&#62;[:&#60;burst&#62;] &#62;</programlisting>
<para>where &#60;rate&#62; is the number of connections per
&#60;interval&#62; (&#34;sec&#34; or &#34;min&#34;) and
&#60;burst&#62; is the largest burst permitted. If no burst value is
given, a value of 5 is assumed.</para>
<para>There may be no whitespace embedded in the specification.</para>
<example>
<title>rate-limit</title>
<programlisting>ACCEPT&#60;2/sec:4&#62; net dmz tcp 80</programlisting>
<para>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.</para>
</example>
<warning>
<para>When rate limiting is specified on a rule with &#34;all&#34;
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.</para>
</warning>
<para>Rate limiting may also be specified in the RATE LIMIT column
below; in that case, it must not be specified as part of the ACTION
column.</para>
<para>The ACTION (and rate limit) may optionally be followed by
&#34;:&#34; and a <ulink url="shorewall_logging.html">syslog level</ulink>
(example: REJECT:info or ACCEPT&#60;2/sec:4&#62;:debugging). 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.</para>
<para>The use of DNAT or REDIRECT requires that you have NAT
enabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SOURCE</term>
<listitem>
<para>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 &#34;all&#34;. If the ACTION is DNAT or
REDIRECT, sub-zones may be excluded from the rule by following the
initial zone name with &#34;!&#39; and a comma-separated list of
those sub-zones to be excluded. There is an <link linkend="Exclude">example</link>
above.</para>
<para>If the source is not &#39;all&#39; then the source may be
further restricted by adding a colon (&#34;:&#34;) followed by a
comma-separated list of qualifiers. Qualifiers are may include:</para>
<variablelist>
<varlistentry>
<term>interface name</term>
<listitem>
<para>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 (&#34;:&#34;) and an IP address or subnet
(examples: loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>IP address</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MAC Address</term>
<listitem>
<para>in <ulink url="configuration_file_basics.htm#MAC">Shorewall
format</ulink>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>subnet</term>
<listitem>
<para>refers to a connection request from any host in the
specified subnet (example net:155.186.235.0/24).</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
<varlistentry>
<term>DEST</term>
<listitem>
<para>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:</para>
<itemizedlist>
<listitem>
<para>An IP address followed by a colon and the port <emphasis
role="bold">number</emphasis> that the server is listening on
(service names from /etc/services are not allowed - example
loc:192.168.1.3:80).</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
</itemizedlist>
<para>Restrictions:</para>
<itemizedlist>
<listitem>
<para>MAC addresses may not be specified.</para>
</listitem>
<listitem>
<para>In DNAT rules, only IP addresses may be given -- DNS names
are not permitted.</para>
</listitem>
<listitem>
<para>You may not specify both an IP address and an interface
name in the DEST column.</para>
</listitem>
</itemizedlist>
<para>Unlike in the SOURCE column, a range of IP addresses may be
specified in the DEST column as &#60;<emphasis>first address</emphasis>&#62;-&#60;<emphasis>last
address</emphasis>&#62;. When the ACTION is DNAT or DNAT-,
connections will be assigned to the addresses in the range in a
round-robin fashion (load-balancing). <emphasis role="bold">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-.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>PROTO</term>
<listitem>
<para>Protocol. Must be a protocol name from /etc/protocols, a
number or &#34;all&#34;. Specifies the protocol of the connection
request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DEST PORT(S)</term>
<listitem>
<para>Port or port range (&#60;low port&#62;:&#60;high port&#62;)
being connected to. May only be specified if the protocol is tcp,
udp or icmp. For icmp, this column&#39;s contents are interpreted as
an icmp type. If you don&#39;t want to specify DEST PORT(S) but need
to include information in one of the columns to the right, enter
&#34;-&#34; 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SOURCE PORTS(S)</term>
<listitem>
<para>May be used to restrict the rule to a particular client port
or port range (a port range is specified as &#60;low port
number&#62;:&#60;high port number&#62;). If you don&#39;t want to
restrict client ports but want to specify something in the next
column, enter &#34;-&#34; 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ORIGINAL DEST</term>
<listitem>
<para>This column may only be non-empty if the ACTION is DNAT or
REDIRECT.</para>
<para>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.</para>
<para>The IP address(es) may be optionally followed by &#34;:&#34;
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 &#34;Source NAT&#34; or SNAT.</para>
<para>If this list begins with &#34;!&#34; then the rule will only
apply if the original destination address matches none of the
addresses listed.</para>
<note>
<para>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.</para>
<example>
<title></title>
<programlisting>DNAT loc:<emphasis role="bold">192.168.1.0/24</emphasis> loc:192.168.1.3 tcp www - 206.124.146.179:192.168.1.3</programlisting>
</example>
</note>
<para>If SNAT is not used (no &#34;:&#34; 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>RATE LIMIT</term>
<listitem>
<para>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</para>
<programlisting>&#60;rate&#62;/&#60;interval&#62;[:&#60;burst&#62;]</programlisting>
<para>where &#60;rate&#62; is the number of connections per
&#60;interval&#62; (&#34;sec&#34; or &#34;min&#34;) and
&#60;burst&#62; is the largest burst permitted. If no burst value is
given, a value of 5 is assumed.</para>
<para>There may be no whitespace embedded in the specification.</para>
<example>
<title>Let&#39;s take</title>
<programlisting>ACCEPT&#60;2/sec:4&#62; net dmz tcp 80</programlisting>
<para>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.</para>
</example>
<warning>
<para>When rate limiting is specified on a rule with &#34;all&#34;
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.</para>
</warning>
<para>Rate limiting may also be specified in the ACTION column
above; in that case, it must not be specified as part of the RATE
LIMIT column.</para>
<para>If you want to specify any following columns but no rate
limit, place &#34;-&#34; in this column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>USER SET</term>
<listitem>
<para>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 User Set Documentation for details.</para>
</listitem>
</varlistentry>
</variablelist>
<example>
<title>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):</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>DNAT&#60;4/min:8&#62;</entry>
<entry>net</entry>
<entry>loc:192.168.1.3</entry>
<entry>tcp</entry>
<entry>ssh</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>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 &#34;!&#34;) originally destined to 206.124.146.177
are redirected to local port 3128.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>REDIRECT</entry>
<entry>loc</entry>
<entry>3128</entry>
<entry>tcp</entry>
<entry>www</entry>
<entry>-</entry>
<entry>!206.124.146.177</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>ACCEPT</entry>
<entry>fw</entry>
<entry>net</entry>
<entry>tcp</entry>
<entry>www</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>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.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>ACCEPT</entry>
<entry>net</entry>
<entry>dmz:155.186.235.222</entry>
<entry>tcp</entry>
<entry>www</entry>
<entry>-</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>ACCEPT</entry>
<entry>loc</entry>
<entry>dmz:155.186.235.222</entry>
<entry>tcp</entry>
<entry>www</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>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.</title>
<para><note><para>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 (<ulink url="FAQ.htm#faq2">but see FAQ 2</ulink>)</para></note><note><para>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.</para></note></para>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>DNAT</entry>
<entry>net</entry>
<entry>dmz:192.168.2.2</entry>
<entry>tcp</entry>
<entry>ftp</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>loc:192.168.1.0/24</entry>
<entry>dmz:192.168.2.2</entry>
<entry>tcp</entry>
<entry>ftp</entry>
<entry>-</entry>
<entry>155.186.235.151</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>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:</para>
<programlisting>passive ports 0.0.0.0/0 65500 65534</programlisting>
<para>If you are running pure-ftpd, you would include &#34;-p
65500:65534&#34; on the pure-ftpd runline.</para>
<para>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.</para>
</example>
<example>
<title>You wish to allow unlimited DMZ access to the host with MAC
address 02:00:08:E3:FA:55.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>ACCEPT</entry>
<entry>loc:~02-00-08-E3-FA-55</entry>
<entry>dmz</entry>
<entry>all</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>You wish to allow access to the SMTP server in your DMZ from all
zones.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>ACCEPT</entry>
<entry>all</entry>
<entry>dmz</entry>
<entry>tcp</entry>
<entry>25</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para><note><para>When &#39;all&#39; 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.</para></note></para>
</example>
<example>
<title>Your firewall&#39;s external interface has several IP addresses
but you only want to accept SSH connections on address 206.124.146.176.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>ACCEPT</entry>
<entry>net</entry>
<entry>fw:206.124.146.176</entry>
<entry>tcp</entry>
<entry>22</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>(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.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>DNAT-</entry>
<entry>net</entry>
<entry>dmz:192.0.2.177</entry>
<entry>tcp</entry>
<entry>25</entry>
<entry>0</entry>
<entry>192.0.2.178</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT-</entry>
<entry>net</entry>
<entry>dmz:192.0.2.177</entry>
<entry>tcp</entry>
<entry>25</entry>
<entry>0</entry>
<entry>192.0.2.179</entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>ACCEPT</entry>
<entry>net</entry>
<entry>dmz:192.0.2.177</entry>
<entry>tcp</entry>
<entry>25</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>Using &#34;DNAT-&#34; rather than &#34;DNAT&#34; avoids two extra
copies of the third rule from being generated.</para>
</example>
<example>
<title>(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.</title>
<informaltable>
<tgroup cols="9">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTO</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DEST</entry>
<entry align="center">RATE LIMIT</entry>
<entry align="center">USER SET</entry>
</row>
</thead>
<tbody>
<row>
<entry>DNAT</entry>
<entry>net</entry>
<entry>loc:192.168.1.101-192.168.1.109</entry>
<entry>tcp</entry>
<entry>80</entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<para><ulink url="ports.htm">Look here for information on other services.</ulink></para>
</section>
<section>
<title>/etc/shorewall/common</title>
<para>Shorewall allows definition of rules that apply between all zones.
By default, these rules are defined in the file /etc/shorewall/common.def
but may be modified to suit individual requirements. Rather than modify
/etc/shorewall/common.def, you should copy that file to
/etc/shorewall/common and modify that file.</para>
<para>The /etc/shorewall/common file is expected to contain iptables
commands; rather than running iptables directly, you should run it
indirectly using the Shorewall function &#39;run_iptables&#39;. That way,
if iptables encounters an error, the firewall will be safely stopped.</para>
</section>
<section id="Masq" xreflabel="/etc/shorewall/masq">
<title>/etc/shorewall/masq</title>
<para>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.</para>
<para>Columns are:</para>
<variablelist>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>The interface that will masquerade the subnet; this is
normally your internet interface. This interface name can be
optionally qualified by adding &#34;:&#34; 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.3.14, if you have set ADD_SNAT_ALIASES=Yes in <xref linkend="Conf" />,
you can cause Shorewall to create an alias <emphasis>label</emphasis>
of the form <emphasis>interfacename:digit</emphasis> (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. <emphasis role="bold">THAT IS THE ONLY THING THAT
THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR
SHOREWALL CONFIGURATION.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>SUBNET</term>
<listitem>
<para>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
&#39;ip&#39; utility.</para>
<caution>
<para>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.</para>
</caution>
<para>The subnet may be optionally followed by &#34;!&#39; and a
comma-separated list of addresses and/or subnets that are to be
excluded from masquerading.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ADDRESS</term>
<listitem>
<para>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 <xref
linkend="Conf" />. 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.</para>
</listitem>
</varlistentry>
</variablelist>
<example>
<title>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:</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth0</entry>
<entry>192.168.9.0/24</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>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.</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec0:10.1.0.0/16</entry>
<entry>192.168.9.0/24</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>You have a DSL line connected on eth0 and a local network
(192.168.10.0/24) connected to eth1. You want all local-&#62;net
connections to use source address 206.124.146.176.</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth0</entry>
<entry>192.168.10.0/24</entry>
<entry>206.124.146.176</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title>Same as example 3 except that you wish to exclude 192.168.10.44
and 192.168.10.45 from the SNAT rule.</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth0</entry>
<entry>192.168.10.0/24!192.168.10.44,192.168.10.45</entry>
<entry>206.124.146.176</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title><emphasis role="bold">(Shorewall version &#62;= 1.3.14):</emphasis>
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 <xref
linkend="Conf" />.</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth0:0</entry>
<entry>192.168.12.0/24</entry>
<entry>206.124.146.177</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
<example>
<title><emphasis role="bold">(Shorewall version &#62;= 1.4.7):</emphasis>
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.</title>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">SUBNET</entry>
<entry align="center">ADDRESS</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth0</entry>
<entry>192.168.12.0/24</entry>
<entry>206.124.146.177,206.124.146.179</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
</section>
<section id="ProxyArp" xreflabel="/etc/shorewall/proxyarp">
<title>/etc/shorewall/proxyarp</title>
<para>If you want to use proxy ARP on an entire sub-network, I suggest
that you look at the <ulink
url="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">Proxy ARP Subnet
Mini HOWTO</ulink>. If you decide to use the technique described in that
HOWTO, you can set the proxy_arp flag for an interface
(/proc/sys/net/ipv4/conf/&#60;<emphasis>interface</emphasis>&#62;/proxy_arp)
by including the <emphasis role="bold">proxyarp</emphasis> option in the
interface&#39;s record in <xref linkend="Interfaces" />. When using Proxy
ARP sub-netting, you do <emphasis role="bold">NOT</emphasis> include any
entries in /etc/shorewall/proxyarp.</para>
<para>The /etc/shorewall/proxyarp file is used to define <ulink
url="ProxyARP.htm">Proxy ARP</ulink>. 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:</para>
<variablelist>
<varlistentry>
<term>ADDRESS</term>
<listitem>
<para>address of the system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>the interface that connects to the system. If the interface is
obvious from the subnetting, you may enter &#34;-&#34; in this
column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>EXTERNAL</term>
<listitem>
<para>the external interface that you want to honor ARP requests for
the ADDRESS specified in the first column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>HAVEROUTE</term>
<listitem>
<para>If you already have a route through INTERFACE to ADDRESS, this
column should contain &#34;Yes&#34; or &#34;yes&#34;. If you want
Shorewall to add the route, the column should contain &#34;No&#34;
or &#34;no&#34;.</para>
</listitem>
</varlistentry>
</variablelist>
<note>
<para>After you have made a change to the /etc/shorewall/proxyarp file,
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.</para>
<para>ISPs typically have ARP configured with long TTL (hours!) so if
your ISPs router has a stale cache entry (as seen using &#34;tcpdump
-nei &#60;external interface&#62; host &#60;IP addr&#62;&#34;), 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.</para>
</note>
<example>
<title>You have public IP addresses 155.182.235.0/28. You configure your
firewall as follows:</title>
<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)</programlisting>
<para>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&#39;s eth0 and you configure 155.186.235.1 as the default
gateway. In your /etc/shorewall/proxyarp file, you will have:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ADDRESS</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">EXTERNAL</entry>
<entry align="center">HAVEROUTE</entry>
</row>
</thead>
<tbody>
<row>
<entry>155.186.235.4</entry>
<entry>eth2</entry>
<entry>eth0</entry>
<entry>No</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para><tip><para>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 <ulink url="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">Proxy
ARP Subnet Mini HOWTO</ulink> for details. In this case you will want to
place &#34;Yes&#34; in the HAVEROUTE column.</para></tip></para>
</example>
<warning>
<para>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
/etc/shorewall/proxyarp. I haven&#39;t had the time to debug this
problem so I can&#39;t say if it is a bug in the Kernel or in FreeS/Wan.</para>
<para>You <emphasis role="bold">might</emphasis> be able to work around
this problem using the following (I haven&#39;t tried it):</para>
<para>In /etc/shorewall/init, include:</para>
<programlisting>qt service ipsec stop</programlisting>
<para>In /etc/shorewall/start, include:</para>
<programlisting>qt service ipsec start</programlisting>
</warning>
</section>
<section id="NAT" xreflabel="/etc/shorewall/nat">
<title>/etc/shorewall/nat</title>
<para>The /etc/shorewall/nat 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.</para>
<important>
<para>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 <link linkend="Rules">rules file</link>.
Also, in most cases <link linkend="ProxyArp">Proxy ARP</link> provides a
superior solution to one-to-one NAT because the internal systems are
accessed using the same IP address internally and externally.</para>
</important>
<para>Columns in an entry are:</para>
<variablelist>
<varlistentry>
<term>EXTERNAL</term>
<listitem>
<para>External IP address</para>
<caution>
<para>This should NOT be the primary IP address of the interface
named in the next column.</para>
</caution>
</listitem>
</varlistentry>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>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 <xref linkend="Conf" />, you can specify an
alias label of the form <emphasis>interfacename:digit</emphasis>
(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. <emphasis role="bold">THAT IS THE ONLY THING
THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN
YOUR SHOREWALL CONFIGURATION.</emphasis></para>
</listitem>
</varlistentry>
<varlistentry>
<term>INTERNAL</term>
<listitem>
<para>Internal IP address.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ALL INTERFACES</term>
<listitem>
<para>If Yes or yes (or left empty), NAT will be effective from all
hosts. If No or no then NAT will be effective only through the
interface named in the INTERFACE column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOCAL</term>
<listitem>
<para>If Yes or yes and the ALL INTERFACES column contains Yes or
yes, NAT will be effective from the firewall system.</para>
<note>
<para>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 <emphasis
role="bold">CONFIG_IP_NF_NAT_LOCAL</emphasis> in your kernel.</para>
</note>
</listitem>
</varlistentry>
</variablelist>
<para><ulink url="NAT.htm">Look here for additional information and an
example.</ulink></para>
</section>
<section id="Tunnels" xreflabel="/etc/shorewall/tunnels">
<title>/etc/shorewall/tunnels</title>
<para>The /etc/shorewall/tunnels file allows you to define IPSec, GRE,
IPIP, <ulink url="http://openvpn.sourceforge.net/">OpenVPN</ulink>, PPTP
and 6to4.tunnels with end-points on your firewall. To use ipsec, you must
install version 1.9, 1.91 or the current <ulink
url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink> development
snapshot.</para>
<note>
<para>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.</para>
</note>
<para>Instructions for setting up <ulink url="IPSEC.htm">IPSEC tunnels</ulink>
may be found here, instructions for <ulink url="IPIP.htm">IPIP and GRE
tunnels</ulink> are here, instructions for <ulink url="OPENVPN.html">OpenVPN
tunnels</ulink> are here, instructions for <ulink url="PPTP.htm">PPTP
tunnels</ulink> are here, instructions for <ulink url="6to4.htm">6to4
tunnels</ulink> are here, and instructions for <ulink
url="GenericTunnels.html">integrating Shorewall with other types of
tunnels</ulink> are here.</para>
</section>
<section id="Conf" xreflabel="/etc/shorewall/shorewall.conf">
<title>/etc/shorewall/shorewall.conf</title>
<para>This file is used to set the following firewall parameters:</para>
<variablelist>
<varlistentry>
<term>ADMINISABSENTMINDED</term>
<listitem>
<para>(Added at version 1.4.7) - The value of this variable affects
Shorewall&#39;s <ulink url="starting_and_stopping_shorewall.htm">stopped
state</ulink>. 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SHOREWALL_SHELL</term>
<listitem>
<para>(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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGFORMAT</term>
<listitem>
<para>(Added at version 1.4.4) - The value of this variable generate
the --log-prefix setting for Shorewall logging rules. It contains a
&#39;printf&#39; formatting template which accepts three arguments
(the chain name, logging rule number (optional) and the
disposition). To use LOGFORMAT with <ulink
url="http://www.fireparse.com">fireparse</ulink>, set it as:</para>
<programlisting>LOGFORMAT=&#34;fp=%s:%d a=%s &#34;</programlisting>
<para>If the LOGFORMAT value contains the substring &#39;%d&#39;
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=&#34;&#34;) then &#34;Shorewall:%s:%s:&#34; is assumed.</para>
<caution>
<para>/sbin/shorewall uses the leading part of the LOGFORMAT
string (up to but not including the first &#39;%&#39;) to find log
messages in the &#39;show log&#39;, &#39;status&#39; and
&#39;hits&#39; commands. This part should not be omitted (the
LOGFORMAT should not begin with &#34;%&#34;) and the leading part
should be sufficiently unique for /sbin/shorewall to identify
Shorewall messages.</para>
</caution>
</listitem>
</varlistentry>
<varlistentry>
<term>CLEAR_TC</term>
<listitem>
<para>(Added at version 1.3.13) - If this option is set to
&#39;No&#39; then Shorewall won&#39;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 /etc/shorewall/tcstart file. That way, your traffic
shaping rules can still use the &#39;fwmark&#39; classifier based on
packet marking defined in /etc/shorewall/tcrules. If not specified,
CLEAR_TC=Yes is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MARK_IN_FORWARD_CHAIN</term>
<listitem>
<para>(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 <ulink
url="traffic_shaping.htm#tcrules">tcrules file</ulink> 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 &#34;/sbin/shorewall show
mangle&#34; 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=&#34;&#34;) then MARK_IN_FORWARD_CHAIN=No is
assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>RFC1918_LOG_LEVEL</term>
<listitem>
<para>(Added at version 1.3.12) - This parameter determines the
level at which packets logged under the <link linkend="rfc1918">&#39;norfc1918&#39;
mechanism</link> are logged. The value must be a valid <ulink
url="shorewall_logging.html">syslog level</ulink> 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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>TCP_FLAGS_DISPOSITION</term>
<listitem>
<para>(Added in Version 1.3.11) - Determines the disposition of TCP
packets that fail the checks enabled by the <link
linkend="Interfaces">tcpflags</link> 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=&#34;&#34;) then
TCP_FLAGS_DISPOSITION=DROP is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>TCP_FLAGS_LOG_LEVEL</term>
<listitem>
<para>(Added in Version 1.3.11) - Determines the <ulink
url="shorewall_logging.html">syslog level</ulink> for logging
packets that fail the checks enabled by the <link
linkend="Interfaces">tcpflags</link> interface option.The value must
be a valid syslogd log level. If you don&#39;t want to log these
packets, set to the empty value (e.g.,
TCP_FLAGS_LOG_LEVEL=&#34;&#34;).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MACLIST_DISPOSITION</term>
<listitem>
<para>(Added in Version 1.3.10) - Determines the disposition of
connections requests that fail <ulink url="MAC_Validation.html">MAC
Verification</ulink> 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=&#34;&#34;) then
MACLIST_DISPOSITION=REJECT is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MACLIST_LOG_LEVEL</term>
<listitem>
<para>(Added in Version 1.3.10) - Determines the <ulink
url="shorewall_logging.html">syslog level</ulink> for logging
connection requests that fail <ulink url="MAC_Validation.html">MAC
Verification</ulink>. The value must be a valid syslogd log level.
If you don&#39;t want to log these connection requests, set to the
empty value (e.g., MACLIST_LOG_LEVEL=&#34;&#34;).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NEWNOTSYN</term>
<listitem>
<para>(Added in Version 1.3.8) - When set to &#34;Yes&#34; or
&#34;yes&#34;, 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 &#34;No&#34;, Shorewall will silently
drop such packets. If not set or set to the empty value (e.g.,
&#34;NEWNOTSYN=&#34;), NEWNOTSYN=No is assumed.</para>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGNEWNOTSYN</term>
<listitem>
<para>(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 <ulink url="shorewall_logging.html">syslog level</ulink> at
which you want the packets logged. Example: LOGNEWNOTSYN=ULOG|</para>
<note>
<para>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.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>DETECT_DNAT_ADDRS</term>
<listitem>
<para>(Added in Version 1.3.4) - If set to &#34;Yes&#34; or
&#34;yes&#34;, 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 &#34;No&#34;
or &#34;no&#34;, Shorewall will not detect this address and any
destination IP address will match the DNAT rule. If not specified or
empty, &#34;DETECT_DNAT_ADDRS=Yes&#34; is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MULTIPORT</term>
<listitem>
<note>
<para>Removed in version 1.4.6 -- the value of this parameter is
now automatically detected by Shorewall</para>
</note>
<para>If set to &#34;Yes&#34; or &#34;yes&#34;, Shorewall will use
the Netfilter multiport facility. In order to use this facility,
your kernel must have multiport support
(CONFIG_IP_NF_MATCH_MULTIPORT). When this support is used, Shorewall
will generate a single rule from each record in the
/etc/shorewall/rules file that meets these criteria:</para>
<itemizedlist>
<listitem>
<para>No port range(s) specified</para>
</listitem>
<listitem>
<para>Specifies 15 or fewer ports</para>
</listitem>
</itemizedlist>
<para>Rules not meeting those criteria will continue to generate an
individual rule for each listed port or port range.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NAT_BEFORE_RULES</term>
<listitem>
<para>If set to &#34;No&#34; or &#34;no&#34;, port forwarding rules
can override the contents of the <xref linkend="NAT" /> file. If set
to &#34;Yes&#34; or &#34;yes&#34;, port forwarding rules cannot
override one-to-one NAT. If not set or set to an empty value,
&#34;Yes&#34; is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>FW</term>
<listitem>
<para>This parameter specifies the name of the firewall zone. If not
set or if set to an empty string, the value &#34;fw&#34; is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SUBSYSLOCK</term>
<listitem>
<para>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&#39;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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>STATEDIR</term>
<listitem>
<para>This parameter specifies the name of a directory where
Shorewall stores state information. If the directory doesn&#39;t
exist when Shorewall starts, it will create the directory. Example:
STATEDIR=/tmp/shorewall.</para>
<note>
<para>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.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>MODULESDIR</term>
<listitem>
<para>This parameter specifies the directory where your kernel
netfilter modules may be found. If you leave the variable empty,
Shorewall will supply the value &#34;/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGRATE and LOGBURST</term>
<listitem>
<para>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.</para>
<example>
<title></title>
<programlisting>LOGRATE=10/minute
LOGBURST=5</programlisting>
</example>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGFILE</term>
<listitem>
<para>This parameter tells the /sbin/shorewall program where to look
for Shorewall messages when processing the &#34;show log&#34;,
&#34;monitor&#34;, &#34;status&#34; and &#34;hits&#34; commands. If
not assigned or if assigned an empty value, /var/log/messages is
assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>NAT_ENABLED</term>
<listitem>
<note>
<para>Removed in Shorewall 1.4.6 -- the value of this parameter is
now automatically detected by Shorewall</para>
</note>
<para>This parameter determines whether Shorewall supports NAT
operations. NAT operations include:</para>
<simplelist>
<member>One-to-one NAT</member>
<member>Port Forwarding</member>
<member>Port Redirection</member>
<member>Masquerading</member>
</simplelist>
<para>If the parameter has no value or has a value of &#34;Yes&#34;
or &#34;yes&#34; then NAT is enabled. If the parameter has a value
of &#34;no&#34; or &#34;No&#34; then NAT is disabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MANGLE_ENABLED</term>
<listitem>
<note>
<para>Removed in Shorewall 1.4.6 -- the value of this parameter is
now automatically detected by Shorewall</para>
</note>
<para>This parameter determines if packet mangling is enabled. If
the parameter has no value or has a value of &#34;Yes&#34; or
&#34;yes&#34; than packet mangling is enabled. If the parameter has
a value of &#34;no&#34; or &#34;No&#34; then packet mangling is
disabled. If packet mangling is disabled, the /etc/shorewall/tos
file is ignored.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>IP_FORWARDING</term>
<listitem>
<para>This parameter determines whether Shorewall enables or
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
Possible values are:</para>
<variablelist>
<varlistentry>
<term>On or on</term>
<listitem>
<para>packet forwarding will be enabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Off or off</term>
<listitem>
<para>packet forwarding will be disabled.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Keep or keep</term>
<listitem>
<para>Shorewall will neither enable nor disable packet
forwarding.</para>
</listitem>
</varlistentry>
</variablelist>
<para>If this variable is not set or is given an empty value
(IP_FORWARD=&#34;&#34;) then IP_FORWARD=On is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ADD_IP_ALIASES</term>
<listitem>
<para>This parameter determines whether Shorewall automatically adds
the <emphasis>external</emphasis> address(es) in <xref linkend="NAT" />.
If the variable is set to &#34;Yes&#34; or &#34;yes&#34; then
Shorewall automatically adds these aliases. If it is set to
&#34;No&#34; or &#34;no&#34;, you must add these aliases yourself
using your distribution&#39;s network configuration tools.</para>
<important>
<para>Shorewall versions before 1.4.6 can only add addresses to
the first subnetwork configured on an interface.</para>
</important>
<para>If this variable is not set or is given an empty value
(ADD_IP_ALIASES=&#34;&#34;) then ADD_IP_ALIASES=Yes is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ADD_SNAT_ALIASES</term>
<listitem>
<para>This parameter determines whether Shorewall automatically adds
the SNAT <emphasis>ADDRESS</emphasis> in <xref linkend="Masq" />. If
the variable is set to &#34;Yes&#34; or &#34;yes&#34; then Shorewall
automatically adds these addresses. If it is set to &#34;No&#34; or
&#34;no&#34;, you must add these addresses yourself using your
distribution&#39;s network configuration tools.</para>
<important>
<para>Shorewall versions before 1.4.6 can only add addresses to
the first subnetwork configured on an interface.</para>
</important>
<para>If this variable is not set or is given an empty value
(ADD_SNAT_ALIASES=&#34;&#34;) then ADD_SNAT_ALIASES=No is assumed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LOGUNCLEAN</term>
<listitem>
<para>This parameter determines the logging level of mangled/invalid
packets controlled by the &#39;dropunclean and logunclean&#39;
interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets
selected by &#39;dropclean&#39; are dropped silently
(&#39;logunclean&#39; packets are logged under the &#39;info&#39;
log level). Otherwise, these packets are logged at the specified
level (Example: LOGUNCLEAN=debug).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>BLACKLIST_DISPOSITION</term>
<listitem>
<para>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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>BLACKLIST_LOGLEVEL</term>
<listitem>
<para>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 <ulink url="shorewall_logging.html">syslog level</ulink>
(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.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CLAMPMSS</term>
<listitem>
<para>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 &#34;Yes&#34; or &#34;yes&#34;, the
feature is enabled. If left blank or set to &#34;No&#34; or
&#34;no&#34;, the feature is not enabled.</para>
<note>
<para>This option requires CONFIG_IP_NF_TARGET_TCPMSS <ulink
url="kernel.htm">in your kernel</ulink>.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>ROUTE_FILTER</term>
<listitem>
<para>If this parameter is given the value &#34;Yes&#34; or
&#34;yes&#34; then route filtering (anti-spoofing) is enabled on all
network interfaces. The default value is &#34;no&#34;.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="modules" xreflabel="/etc/shorewall/modules">
<title>/etc/shorewall/modules Configuration</title>
<para>The file /etc/shorewall/modules 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 <xref
linkend="Conf" /> above).</para>
<para>The file that is released with Shorewall calls the Shorewall
function &#34;loadmodule&#34; for the set of modules that I load.</para>
<para>The <emphasis>loadmodule</emphasis> function is called as follows:</para>
<programlisting>loadmodule &#60;<emphasis>modulename</emphasis>&#62; [ &#60;<emphasis>module parameters</emphasis>&#62; ]</programlisting>
<para>where</para>
<variablelist>
<varlistentry>
<term>&#60;<emphasis>modulename</emphasis>&#62;</term>
<listitem>
<para>is the name of the modules without the trailing &#34;.o&#34;
(example ip_conntrack).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&#60;<emphasis>module parameters</emphasis>&#62;</term>
<listitem>
<para>Optional parameters to the insmod utility.</para>
</listitem>
</varlistentry>
</variablelist>
<para>The function determines if the module named by &#60;<emphasis>modulename</emphasis>&#62;
is already loaded and if not then the function determines if the
&#34;.o&#34; file corresponding to the module exists in the
<emphasis>moduledirectory</emphasis>; if so, then the following command is
executed:</para>
<programlisting>insmod <emphasis>moduledirectory</emphasis>/&#60;<emphasis>modulename</emphasis>&#62;.o &#60;<emphasis>module parameters</emphasis>&#62;</programlisting>
<para>If the file doesn&#39;t exist, the function determines of the
&#34;.o.gz&#34; file corresponding to the module exists in the
<emphasis>moduledirectory</emphasis>. If it does, the function assumes
that the running configuration supports compressed modules and execute the
following command:</para>
<programlisting>insmod <emphasis>moduledirectory</emphasis>/&#60;<emphasis>modulename</emphasis>&#62;.o.gz &#60;<emphasis>module parameters</emphasis>&#62;</programlisting>
</section>
<section id="TOS" xreflabel="/etc/shorewall/tos">
<title>/etc/shorewall/tos Configuration</title>
<para>The /etc/shorewall/tos 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.</para>
<para>Entries in the file have the following columns:</para>
<variablelist>
<varlistentry>
<term>SOURCE</term>
<listitem>
<para>The source zone. May be qualified by following the zone name
with a colon (&#34;:&#34;) and either an IP address, an IP subnet, a
MAC address <ulink url="configuration_file_basics.htm#MAC">in
Shorewall Format</ulink> 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 &#34;all&#34; to indicate any
source.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DEST</term>
<listitem>
<para>The destination zone. May be qualified by following the zone
name with a colon (&#34;:&#34;) 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
&#34;all&#34; to indicate any destination.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PROTOCOL</term>
<listitem>
<para>The name of a protocol in /etc/protocols or the protocol&#39;s
number.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>SOURCE PORT(S)</term>
<listitem>
<para>The source port or a port range. For all ports, place a hyphen
(&#34;-&#34;) in this column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DEST PORT(S)</term>
<listitem>
<para>The destination port or a port range. To indicate all ports,
place a hyphen (&#34;-&#34;) in this column.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>TOS</term>
<listitem>
<para>The type of service. Must be one of the following:</para>
<simplelist>
<member>Minimize-Delay (16)</member>
<member>Maximize-Throughput (8)</member>
<member>Maximize-Reliability (4)</member>
<member>Minimize-Cost (2)</member>
<member>Normal-Service (0)</member>
</simplelist>
</listitem>
</varlistentry>
</variablelist>
<table>
<title>/etc/shorewall/tos file that is included with Shorewall</title>
<tgroup cols="6">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">PROTOCOL</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">DEST PORT(S)</entry>
<entry align="center">TOS</entry>
</row>
</thead>
<tbody>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>-</entry>
<entry>ssh</entry>
<entry>16</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>ssh</entry>
<entry>-</entry>
<entry>16</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>-</entry>
<entry>ftp</entry>
<entry>16</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>ftp</entry>
<entry>-</entry>
<entry>16</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>-</entry>
<entry>ftp-data</entry>
<entry>8</entry>
</row>
<row>
<entry>all</entry>
<entry>all</entry>
<entry>tcp</entry>
<entry>ftp-data</entry>
<entry>-</entry>
<entry>8</entry>
</row>
</tbody>
</tgroup>
</table>
<warning>
<para>Users have reported that odd routing problems result from adding
the ESP and AH protocols to the /etc/shorewall/tos file.</para>
</warning>
</section>
<section id="Blacklist" xreflabel="/etc/shorewall/blacklist">
<title>/etc/shorewall/blacklist</title>
<para>Each line in /etc/shorewall/blacklist contains an IP address, a MAC
address in Shorewall Format or subnet address.</para>
<example>
<title></title>
<programlisting>130.252.100.69
206.124.146.0/24</programlisting>
</example>
<para>Packets <emphasis role="bold">from</emphasis> hosts listed in the
blacklist file will be disposed of according to the value assigned to the
<link linkend="Conf">BLACKLIST_DISPOSITION</link> and <link linkend="Conf">BLACKLIST_LOGLEVEL</link>
variables in /etc/shorewall/shorewall.conf. Only packets arriving on
interfaces that have the &#39;<link linkend="Interfaces">blacklist</link>&#39;
option in /etc/shorewall/interfaces are checked against the blacklist. The
black list is designed to prevent listed hosts/subnets from accessing
services on <emphasis role="bold">your</emphasis> network.</para>
<para>Beginning with Shorewall 1.3.8, the blacklist file has three
columns:</para>
<variablelist>
<varlistentry>
<term>ADDRESS/SUBNET</term>
<listitem>
<para>As described above.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PROTOCOL</term>
<listitem>
<para>Optional. If specified, only packets specifying this protocol
will be blocked.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>PORTS</term>
<listitem>
<para>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 &#34;iptables -h icmp&#34;).</para>
</listitem>
</varlistentry>
</variablelist>
<para>Shorewall also has a <ulink url="blacklisting_support.htm">dynamic
blacklist capability</ulink>.</para>
<important>
<para>The Shorewall blacklist file is <emphasis role="bold">NOT</emphasis>
designed to police your users&#39; web browsing -- to do that, I suggest
that you install and configure <ulink url="http://www.squid-cache.org">Squid</ulink>
with <ulink url="http://www.squidguard.org/">SquidGuard</ulink>.</para>
</important>
</section>
<section id="rfc1918" xreflabel="/etc/shorewall/rfc1918">
<title>/etc/shorewall/rfc1918 (Added in Version 1.3.1)</title>
<para>This file lists the subnets affected by the <link
linkend="Interfaces">norfc1918 interface option</link>. Columns in the
file are:</para>
<variablelist>
<varlistentry>
<term>SUBNET</term>
<listitem>
<para>The subnet using VLSM notation (e.g., 192.168.0.0/16).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>TARGET</term>
<listitem>
<para>What to do with packets to/from the SUBNET:</para>
<variablelist>
<varlistentry>
<term>RETURN</term>
<listitem>
<para>Process the packet normally thru the rules and policies.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DROP</term>
<listitem>
<para>Silently drop the packet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>logdrop</term>
<listitem>
<para>Log then drop the packet -- see the <link linkend="Conf">RFC1918_LOG_LEVEL</link>
parameter above.</para>
</listitem>
</varlistentry>
</variablelist>
</listitem>
</varlistentry>
</variablelist>
</section>
<section id="Routestopped" xreflabel="/etc/shorewall/routestopped">
<title>/etc/shorewall/routestopped (Added in Version 1.3.4)</title>
<para>This file defines the hosts that are accessible from the firewall
when the firewall is stopped. Columns in the file are:</para>
<variablelist>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>The firewall interface through which the host(s) comminicate
with the firewall.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>HOST(S) - (Optional)</term>
<listitem>
<para>A comma-separated list of IP/Subnet addresses. If not supplied
or supplied as &#34;-&#34; then 0.0.0.0/0 is assumed.</para>
</listitem>
</varlistentry>
</variablelist>
<example>
<title>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.</title>
<informaltable>
<tgroup cols="2">
<thead>
<row>
<entry align="center">INTERFACE</entry>
<entry align="center">HOST(S)</entry>
</row>
</thead>
<tbody>
<row>
<entry>eth2</entry>
<entry>192.168.1.0/24</entry>
</row>
<row>
<entry>eth1</entry>
<entry>-</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</example>
</section>
<section id="Maclist" xreflabel="/etc/shorewall/maclist">
<title>/etc/shorewall/maclist (Added in Version 1.3.10)</title>
<para>This file is described in the <ulink url="MAC_Validation.html">MAC
Validation Documentation</ulink>.</para>
</section>
<section id="ECN" xreflabel="/etc/shorewall/ecn">
<title>/etc/shorewall/ecn (Added in Version 1.4.0)</title>
<para>This file is described in the <ulink url="ECN.html">ECN Control
Documentation</ulink>.</para>
</section>
</article>
Reference in New Issue View Git Blame Copy Permalink