extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-28 10:33:21 +01:00
Code Issues Packages Projects Releases Wiki Activity
0f72f92c48
shorewall_code/Shorewall-docs/Documentation.htm
teastep a30b326a4b Shorewall-1.4.7 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@756 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-10-06 22:38:40 +00:00

2853 lines
107 KiB
HTML
Raw Blame History

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall 1.4 Documentation</title>
<base target="_self">
<meta name="Microsoft Theme" content="none, default">
<meta name="Microsoft Border" content="none, default">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4"
bgcolor="#3366ff" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall 1.4 Reference</font></h1>
</td>
</tr>
</tbody>
</table>
<h2 align="center">This documentation is intended primarily for
reference. Step-by-step instructions for configuring Shorewall in
common setups may be found in the <a
href="shorewall_quickstart_guide.htm">QuickStart Guides</a>.</h2>
<h2>Components</h2>
<p>Shorewall consists of the following components: </p>
<ul>
<li><b><a href="#Variables">params</a></b> -- a parameter file
installed in /etc/shorewall that can be used to establish the values of
shell variables for use in other files.</li>
<li><b> <a href="#Conf">shorewall.conf</a></b> -- a parameter file
installed in /etc/shorewall that is used to set
several firewall parameters.</li>
<li><b> <a href="#Zones">zones</a></b> - a parameter file installed
in /etc/shorewall that defines a network partitioning into "zones"</li>
<li><b> <a href="#Policy">policy</a></b> -- a parameter file
installed in /etc/shorewall/ that establishes overall firewall policy.</li>
<li><b> <a href="#Rules">rules</a> </b> -- 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.</li>
<li><b><a href="#Blacklist">blacklist</a> -- </b>a parameter file
installed in /etc/shorewall and used to list blacklisted IP/subnet/MAC
addresses.</li>
<li><b><a href="#ECN">ecn</a></b> -- a parameter file installed in
/etc/shorewall and used to selectively disable Explicit Congestion
Notification (ECN - RFC 3168).<br>
</li>
<li><b> functions</b> -- 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.</li>
<li><b> <a href="#modules">modules</a></b> -- 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.</li>
<li><a href="#TOS"><b> tos</b> </a>-- 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.<br>
</li>
<li><b><a href="#Scripts">common.def</a></b> -- a parameter file
installed in in /etc/shorewall that defines firewall-wide rules that
are applied before a DROP or REJECT policy is applied.</li>
<li><b> <a href="#Interfaces">interfaces</a> </b> -- a parameter
file installed in /etc/shorewall/ and used to describe the interfaces
on the firewall system.</li>
<li><a href="#Hosts"><b> hosts</b> </a>-- a parameter file installed
in /etc/shorewall/ and used to describe individual hosts or subnetworks
in zones.</li>
<li><b><a href="#Maclist">maclist</a> </b>-- a parameter file
installed in /etc/shorewall and used to verify the MAC address (and
possibly also the IP address(es)) of devices.<br>
</li>
<li><b> <a href="#Masq">masq</a></b> - This file also describes IP
masquerading under Shorewall and is installed in /etc/shorewall.</li>
<li><b><a href="shorewall_firewall_structure.htm">firewall</a></b> --
a shell program that reads the configuration files in /etc/shorewall
and configures your firewall. This file is installed in your init.d
directory (/etc/rc.d/init.d ) where it is renamed <i>shorewall.</i>
/etc/shorewall/firewall (/var/lib/shorewall/firewall in versions
1.3.2-1.3.8 and /usr/lib/shorewall/firewall in 1.3.9 and later) is a
symbolic link to this program.</li>
<li><b> <a href="#NAT">nat</a></b> -- a parameter file in
/etc/shorewall used to define <a href="#NAT"> static NAT</a> .</li>
<li><b> <a href="#ProxyArp">proxyarp</a></b> -- a parameter file in
/etc/shorewall used to define <a href="#ProxyArp"> Proxy Arp</a> .</li>
<li><b><a href="#rfc1918">rfc1918</a></b> -- a parameter file in
/etc/shorewall used to define the treatment of packets under the <a
href="#Interfaces">norfc1918 interface option</a>.</li>
<li><b><a href="#Routestopped">routestopped</a></b> -- a parameter
file in /etc/shorewall used to define those hosts that can access the
firewall when Shorewall is stopped.</li>
<li><a href="traffic_shaping.htm#tcrules"><b>tcrules</b> </a>-- a
parameter file in /etc/shorewall used to define rules for classifying
packets for <a href="traffic_shaping.htm">Traffic Shaping/Control</a>.</li>
<li><b> <a href="#Tunnels">tunnels</a></b> -- a parameter file in
/etc/shorewall used to define IPSec tunnels.</li>
<li><b> <a href="#Starting">shorewall</a> </b> -- 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).</li>
<li><a href="Accounting.html"><span style="font-weight: bold;">accounting</span></a>
-- a parameter file in /etc/shorewall used to define traffic accounting
rules. This file was added in version 1.4.7.<br>
</li>
<li><b> version</b> -- 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.</li>
</ul>
<h2><a name="Variables"></a> /etc/shorewall/params</h2>
<p>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.</p>
<p>It is suggested that variable names begin with an upper case letter<font
size="1"> </font>to distinguish them from variables used internally
within the Shorewall programs</p>
<p>Example:</p>
<pre><font face="Courier"> NET_IF=eth0<br> NET_BCAST=130.252.100.255<br> NET_OPTIONS=blacklist,norfc1918</font></pre>
<p>Example (/etc/shorewall/interfaces record):</p>
<pre> <font face="Courier">net $NET_IF $NET_BCAST $NET_OPTIONS</font></pre>
<p>The result will be the same as if the record had been written</p>
<pre> <font face="Courier">net eth0 130.252.100.255 blacklist,norfc1918</font></pre>
<p>Variables may be used anywhere in the other configuration files.</p>
<h2><b><a name="Zones"></a> </b>/etc/shorewall/zones</h2>
<p>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:</p>
<ul>
<li><b> ZONE</b> - 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 "all" may not be
used as a zone name nor may the zone name assigned to the firewall
itself via the FW variable in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b> DISPLAY</b> - The name of the zone as displayed during
Shorewall startup.</li>
<li><b> COMMENTS</b> - Any comments that you want to make about the
zone. Shorewall ignores these comments.</li>
</ul>
<p>The /etc/shorewall/zones file released with Shorewall is as follows:</p>
<table border="1" style="border-collapse: collapse;" cellpadding="2">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> DISPLAY</b></td>
<td><b> COMMENTS</b></td>
</tr>
<tr>
<td>net</td>
<td>Net</td>
<td>Internet</td>
</tr>
<tr>
<td>loc</td>
<td>Local</td>
<td>Local networks</td>
</tr>
<tr>
<td>dmz</td>
<td>DMZ</td>
<td>Demilitarized zone</td>
</tr>
</tbody>
</table>
<p>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.</p>
<p><b><font size="5" color="#ff0000"> Warning 1: </font><font
color="#ff0000"> If you rename or delete a zone, you should perform
"shorewall stop; shorewall start" to install the change rather than
"shorewall restart".</font></b></p>
<p><b><font size="5" color="#ff0000">Warning 2: </font><font
color="#ff0000">The order of entries in the /etc/shorewall/zones file
is significant <a href="#Nested">in some cases</a>.</font></b></p>
<h2><font color="#660066"><a name="Interfaces"></a> </font>/etc/shorewall/interfaces</h2>
<p>This file is used to tell the firewall which of your firewall's
network interfaces are connected to which zone. There will be one entry
in /etc/shorewall/interfaces for each of your interfaces. Columns in an
entry are:</p>
<ul>
<li><b> ZONE</b> - A zone defined in the <a href="#Zones">/etc/shorewall/zones</a>
file or "-". If you specify "-", you must use the <a href="#Hosts">
/etc/shorewall/hosts</a> file to define the zones accessed via this
interface.</li>
<li><b> INTERFACE</b> - the name of the interface (examples: eth0,
ppp0, ipsec+). Each interface can be listed on only one record in this
file. <font color="#ff0000"><b>D</b><b>O NOT INCLUDE THE LOOPBACK
INTERFACE (lo) IN THIS FILE!!!</b></font></li>
<li><b> BROADCAST</b> - 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 "-" in this column. If you supply the special value
"detect" in this column, the
firewall will automatically determine the broadcast address. In order
to use "detect":
<ul>
<li>the interface must be up before you start your firewall</li>
<li>the interface must only be attached to a single sub-network
(i.e., there must have a single broadcast address). </li>
</ul>
</li>
<li><b> OPTIONS</b> - a comma-separated list of options. Possible
options include:<br>
<br>
<span style="font-weight: bold;">arp_filter </span>(Added in
version 1.4.7) - This option causes
/proc/sys/net/ipv4/conf/&lt;interface&gt;/arp_filter to be set with the
result that this interface will only answer ARP 'who-has' 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.<br>
<br>
<b>newnotsyn </b>(Added in version 1.4.6) - This option overrides <a
href="#Conf">NEWNOTSYN=No</a> for packets arriving on this interface.
In other words, packets coming in on this interface are processed as if
NEWNOTSYN=Yes had been specified in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.<br>
<b><br>
routeback </b>(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 "-".<br>
<p> <b>tcpflags </b>(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 "silent" port scans.
Packets failing these checks are logged according to the
TCP_FLAGS_LOG_LEVEL option in<a href="#Conf">
/etc/shorewall/shorewall.conf</a> and are disposed of
according to the TCP_FLAGS_DISPOSITION option.<br>
<b><br>
blacklist</b> - This option causes incoming packets on this interface
to be checked against the <a href="#Blacklist">blacklist</a>.<b><br>
<br>
dhcp</b> - 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 <b>norfc1918 </b>option (see below).</p>
<p> <b>norfc1918</b> - Packets arriving on this interface and that
have a source address that is reserved in RFC 1918 or in other RFCs
will be dropped after being optionally logged. If <a href="#Conf">packet
mangling is enabled in /etc/shorewall/shorewall.conf</a> , then packets
arriving on this interface that have a destination address that is
reserved by one of these RFCs will also be logged and dropped.<br>
<br>
Addresses blocked by the standard <a href="#rfc1918"> <b>rfc1918 </b>file</a>
include those addresses reserved by RFC1918 plus other ranges reserved
by the IANA or by other RFCs.</p>
<p> Beware that as IPv4 addresses become in increasingly short
supply, ISPs are beginning to use RFC 1918 addresses within their own
infrastructure. Also, many cable and DSL "modems" have an RFC 1918
address that can be used through a web browser for management and
monitoring functions. If you want to specify <b>norfc1918</b> on your
external interface but need to allow access to certain addresses from
the above list, see <a href="FAQ.htm#faq14">FAQ 14.</a></p>
<p> <b> routefilter</b> - Invoke the Kernel's route filtering
(anti-spoofing) facility on this interface. The kernel will reject any
packets incoming on this interface that have a source address that
would be routed
outbound through another interface on the firewall. <font
color="#ff0000">Warning: </font>If you specify
this option for an interface then the interface must be up
prior to starting the firewall.</p>
<p> <b>dropunclean</b> - Packets from this interface that are
selected by the 'unclean' match target in iptables will be <a
href="#LogUnclean">optionally logged</a> and then dropped. <font
color="#ff0000"><b>Warning: 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.<br>
<br>
Update 12/17/2001: </b></font>The unclean match patch from 2.4.17-rc1
is <a href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean.patch">available
for download</a>. I am currently running this patch applied to kernel
2.4.16.</p>
<p><font color="#ff0000"><b>Update 12/20/2001: </b></font>I've
seen a number of tcp connection requests with OPT (020405B4<u>0000080A</u>...)
being dropped in the <i>badpkt</i> 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'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, <a
href="ftp://ftp.shorewall.net/pub/shorewall/misc/unclean1.patch">here's
a kernel patch</a> against 2.4.17-rc2.</p>
<p><b>logunclean </b>- This option works like <b>dropunclean</b>
with the exception that packets selected by the 'unclean' match target
in iptables are logged <i>but not dropped</i>. The level at which the
packets are logged is determined by the setting of <a
href="#LogUnclean">LOGUNCLEAN</a> and if LOGUNCLEAN has not been set,
"info" is assumed.</p>
<p><b>proxyarp </b>(Added in version 1.3.5) - This option causes
Shorewall to set /proc/sys/net/ipv4/conf/<i>&lt;interface&gt;</i>/proxy_arp
and is used when implementing Proxy ARP Sub-netting as described at <a
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>. Do <u> not</u>
set this option if you are implementing Proxy ARP through entries in <a
href="#ProxyArp"> /etc/shorewall/proxyarp</a>.<br>
<br>
<b>maclist</b> (Added in version 1.3.10) - If this option is
specified, all connection requests from this interface are subject to <a
href="MAC_Validation.html">MAC Verification</a>. May
only be specified for ethernet interfaces.</p>
</li>
</ul>
<p>My recommendations concerning options:<br>
</p>
<ul>
<li>External Interface -- <b>tcpflags,blacklist,norfc1918,routefilter</b></li>
<li>Wireless Interface -- <b>maclist,routefilter,tcpflags</b><br>
</li>
<li>Don't use <b>dropunclean</b> -- It's broken in my opinion</li>
<li>Use <b>logunclean</b> only when you are trying to debug a problem</li>
<li>Use <b>dhcp </b>and <b>proxyarp</b> when needed.<br>
</li>
</ul>
<p> </p>
<p>Example 1: You have a conventional firewall setup in which eth0
connects to a Cable or DSL modem and eth1 connects to your local
network and eth0 gets its IP address via DHCP. You want to check all
packets entering from the
internet against the <a href="#Blacklist">black list</a>. Your
/etc/shorewall/interfaces file would be as follows:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918,blacklist</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 2: You have a standalone dialup GNU/Linux System. Your
/etc/shorewall/interfaces file would be:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>ppp0</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 3: You have local interface eth1 with two IP addresses -
192.168.1.1/24 and 192.168.12.1/24</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>192.168.1.255,192.168.12.255</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><font color="#660066"><a name="Hosts"></a> </font>/etc/shorewall/hosts
Configuration</h2>
<p>For most applications, specifying zones entirely in terms of network
interfaces is sufficient. There may be times though where you need to
define
a zone to be a more general collection of hosts. This is the purpose of
the /etc/shorewall/hosts file.</p>
<p><b><font color="#ff0000">WARNING: </font>The only times that you
need entries
in /etc/shorewall/hosts are:<br>
</b></p>
<ol>
<li><b>You have more than one zone connecting
through a single interface; or</b></li>
<li><b>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.</b><br>
</li>
</ol>
<b>IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS
THEN DON'T TOUCH THIS FILE!!</b>
<p>Columns in this file are:</p>
<ul>
<li><b> ZONE </b> - A zone defined in the <a href="#Zones">/etc/shorewall/zones</a>
file.</li>
<li><b> HOST(S)</b> - The name of a network interface followed by a
colon (":") followed by a comma-separated list either:</li>
</ul>
<blockquote>
<ol>
<li>An IP address (example - eth1:192.168.1.3)</li>
<li>A subnet in CIDR notation<i> </i>(example -
eth2:192.168.2.0/24)</li>
</ol>
<p>The interface name much match an entry in
/etc/shorewall/interfaces.<br>
</p>
<p><font color="#ff0000"><b>Warning: </b></font><b>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.</b><br>
</p>
</blockquote>
<ul>
<li><b> OPTIONS</b> - A comma-separated list of option</li>
</ul>
<blockquote>
<p><b>routeback </b>(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.<b><br>
<br>
maclist - </b>Added in version 1.3.10. If specified, connection
requests from the hosts specified in this entry are subject to <a
href="MAC_Validation.html">MAC Verification</a>. This option is only
valid for ethernet interfaces.<br>
</p>
</blockquote>
<p>If you don't define any hosts for a zone, the hosts in the zone
default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the
interfaces to the zone.</p>
<p><b><font size="4" color="#ff0000">Note: </font></b> You probably
DON'T want to specify any hosts for your internet zone since the hosts
that you specify will be the only ones that you will be able to access
without adding additional rules.</p>
<p>Example 1:</p>
<p>Your local interface is eth1 and you have two groups of local hosts
that you want to make into separate zones:</p>
<ul>
<li>192.168.1.0/25 </li>
<li>192.168.1.128/</li>
</ul>
<p>Your /etc/shorewall/interfaces file might look like:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>-</td>
<td>eth1</td>
<td>192.168.1.127,192.168.1.255<br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> The '-' in the ZONE column for eth1 tells Shorewall that eth1
interfaces to multiple zones.</p>
<p> Your /etc/shorewall/hosts file might look like:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc1</td>
<td>eth1:192.168.1.0/25</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc2</td>
<td>eth1:192.168.1.128/25</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>Example 2:</p>
<p>Your local interface is eth1 and you have two groups of local hosts
that you want to consider as one zone and you want Shorewall to route
between them:</p>
<ul>
<li>192.168.1.0/25 </li>
<li>192.168.1.128/25</li>
</ul>
<p> Your /etc/shorewall/interfaces file might look like:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>loc<br>
</td>
<td>eth1</td>
<td>192.168.1.127,192.168.1.255<br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Your /etc/shorewall/hosts file might look like:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc</td>
<td>eth1:192.168.1.0/25</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc</td>
<td>eth1:192.168.1.128/25</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
If you are running Shorewall 1.4.6 or later, your hosts file may look
like:<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>loc</td>
<td>eth1:192.168.1.0/25,192.168.1.128/25</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<h4><font color="#660066"><a name="Nested"></a> Nested and Overlapping
Zones</font></h4>
<p> 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.</p>
<p> Hosts that belong to more than one zone may be managed by the rules
of all of those zones. This is done through use of the special <a
href="#CONTINUE">CONTINUE policy</a> described below.</p>
<h2><font color="#660066"><a name="Policy"></a> </font>/etc/shorewall/policy
Configuration.</h2>
<p>This file is used to describe the firewall policy regarding
establishment of connections. Connection establishment is described in
terms of <i>clients</i> who initiate connections and <i> servers </i>who
receive those connection requests. Policies defined in
/etc/shorewall/policy describe which zones are allowed to establish
connections with other zones.</p>
<p>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.</p>
<p>Four policies are defined:</p>
<ul>
<li><b> ACCEPT</b> - The connection is allowed.</li>
<li><b> DROP</b> - The connection request is ignored.</li>
<li><b> REJECT</b> - The connection request is rejected with an RST
(TCP) or an ICMP destination-unreachable packet being returned to the
client.</li>
<li><b> CONTINUE </b> - 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.</li>
<li><b>NONE</b> - (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 <b>LOG LEVEL </b>and <b>BURST:LIMIT
</b>columns must be left blank.<br>
</li>
</ul>
<p> For each policy specified in /etc/shorewall/policy, you can
indicate that you want a message sent to your system log each time that
the policy is applied.</p>
<p> Entries in /etc/shorewall/policy have four columns as follows:</p>
<ol>
<li> <b> SOURCE</b> - The name of a client zone (a zone defined in
the <a href="#Zones"> /etc/shorewall/zones file</a> , the <a
href="#Conf">name of the firewall zone</a> or "all").</li>
<li> <b> DEST</b> - The name of a destination zone (a zone defined
in the <a href="#Zones"> /etc/shorewall/zones file</a> , the <a
href="#Conf">name of the firewall zone</a> or "all"). Shorewall
automatically allows all traffic from the firewall to itself so the <a
href="#Conf">name of the firewall zone</a> cannot appear in both the
SOURCE and DEST columns.</li>
<li> <b> POLICY</b> - The default policy for connection requests
from the SOURCE zone to the DESTINATION zone.</li>
<li> <b> LOG LEVEL</b> - Optional. If left empty, no log message is
generated when the policy is applied. Otherwise, this column should
contain an integer or name indicating a <a
href="shorewall_logging.html">syslog level</a>.</li>
<li> <b>LIMIT:BURST </b>- Optional. If left empty, TCP connection
requests from the <b>SOURCE</b> zone to the <b>DEST</b> 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
(":") followed by the maximum burst size that will be tolerated.
Example: <b> 10/sec:40</b> specifies that the maximum rate of TCP
connection requests allowed will be
10 per second and a burst of 40 connections will be tolerated.
Connection requests in excess of these limits will be dropped. See the <a
href="#Rules">rules file documentation</a> for an explaination of how
rate limiting works.<br>
</li>
</ol>
<p> In the SOURCE and DEST columns, you can enter "all" to indicate all
zones. </p>
<p> The policy file installed by default is as follows:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> POLICY</b></td>
<td><b> LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td> <br>
</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> This table may be interpreted as follows:</p>
<ul>
<li>All connection requests from the local network to hosts on the
internet are accepted.</li>
<li>All connection requests originating from the internet are ignored
and logged at level KERNEL.INFO.</li>
<li>All other connection requests are rejected and logged.</li>
</ul>
<p><b><font size="4" color="#ff0000">WARNING:</font></b></p>
<p><font color="#ff0000"><b> The firewall script processes</b> <b> the
/etc/shorewall/policy file from top to bottom and <u>uses the first
applicable policy that it finds.</u> 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.</b></font></p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>POLICY</b></td>
<td><b>LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td>loc</td>
<td>all</td>
<td>ACCEPT</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td> <br>
</td>
</tr>
<tr>
<td>loc</td>
<td>loc</td>
<td>REJECT</td>
<td>info</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h4><a name="IntraZone"></a>IntraZone Traffic</h4>
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 "all" 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.<br>
<p>Any time that you have multiple interfaces associated with a single
zone, you should ask yourself if you really want traffic routed between
those interfaces. Cases where you might not want that behavior are:<br>
</p>
<ol>
<li>Multiple 'net' interfaces to different ISPs. You don't want to
route traffic from one ISP to the other through your firewall.</li>
<li>Multiple VPN clients. You don't necessarily want them to all be
able to communicate between themselves using your gateway/router.<br>
</li>
</ol>
<h4><font color="#660066"><a name="CONTINUE"></a> The CONTINUE policy</font></h4>
<p> Where zones are <a href="#Nested">nested or overlapping</a> , the
CONTINUE policy allows hosts that are within multiple zones to be
managed under the rules of all of these zones. Let's look at an example:</p>
<p> /etc/shorewall/zones:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> DISPLAY</b></td>
<td><b> COMMENTS</b></td>
</tr>
<tr>
<td>sam</td>
<td>Sam</td>
<td>Sam's system at home</td>
</tr>
<tr>
<td>net</td>
<td>Internet</td>
<td>The Internet</td>
</tr>
<tr>
<td>loc</td>
<td>Loc</td>
<td>Local Network</td>
</tr>
</tbody>
</table>
</blockquote>
<p> /etc/shorewall/interfaces:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>-</td>
<td>eth0</td>
<td>detect</td>
<td>dhcp,norfc1918</td>
</tr>
<tr>
<td>loc</td>
<td>eth1</td>
<td>detect</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> /etc/shorewall/hosts:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0:0.0.0.0/0</td>
<td> <br>
</td>
</tr>
<tr>
<td>sam</td>
<td>eth0:206.191.149.197</td>
<td><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Note that Sam's home system is a member of both the <b>sam</b>
zone and the <b>net</b> zone and <a href="#Nested"> as described above</a>
, that means that <b>sam</b> must be listed before <b>net</b> in
/etc/shorewall/zones.</p>
<p> /etc/shorewall/policy:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> SOURCE</b></td>
<td><b> DEST</b></td>
<td><b> POLICY</b></td>
<td><b> LOG LEVEL</b></td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<td> <br>
</td>
</tr>
<tr>
<td>sam</td>
<td>all</td>
<td>CONTINUE</td>
<td> <br>
</td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
</tr>
</tbody>
</table>
</blockquote>
<p> The second entry above says that when Sam is the client, connection
requests should first be process under rules where the source zone is <b>sam</b>
and if there is no match then the connection request should be treated
under rules where the source zone is <b>net</b>. It is important that
this policy be listed BEFORE the next policy (<b>net</b> to <b>all</b>).</p>
<p> Partial /etc/shorewall/rules:</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>loc:192.168.1.5</td>
<td>tcp</td>
<td>www</td>
<td>-</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Given these two rules, Sam can connect to the firewall's internet
interface with ssh and the connection request will be forwarded to
192.168.1.3. Like all hosts in the <b>net</b>
zone, Sam can connect to the firewall's internet interface on TCP port
80 and the connection request will be forwarded to 192.168.1.5. The
order of the rules is not significant.</p>
<p> <a name="Exclude"></a>Sometimes it is necessary to suppress port
forwarding for a sub-zone. For example, suppose that all hosts can SSH
to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. When Sam
connects to the firewall's external IP, he should be connected to the
firewall itself. Because of the way that Netfilter is constructed, this
requires two rules as follows:</p>
<blockquote>
<p> </p>
<font face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table style="border-collapse: collapse;" cellpadding="2" border="1">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>fw</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>net!sam</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>The first rule allows Sam SSH access to the firewall. The second
rule says that any clients from the net zone with the exception of
those in the 'sam' zone should have their connection port forwarded to
192.168.1.3. If you need to exclude more than one zone in this way, you
can list the zones separated by commas (e.g., net!sam,joe,fred). This
technique also may be used when the ACTION is REDIRECT.</p>
<h2><font color="#660066"><a name="Rules"></a> </font>/etc/shorewall/rules</h2>
<p>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. <br>
</p>
<p>Shorewall automatically enables firewall-&gt;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.<br>
</p>
<p>Entries in the file have the following columns:</p>
<ul>
<li><b>ACTION</b>
<ul>
<li>ACCEPT, DROP, REJECT, CONTINUE. These have the same meaning
here as in the policy file above.</li>
<li>DNAT -- Causes the connection request to be forwarded to the
system specified in the DEST column (port forwarding). "DNAT" stands
for "<u>D</u>estination <u>N</u>etwork <u>A</u>ddress <u>T</u>ranslation"</li>
<li>DNAT- -- The above ACTION (DNAT) generates two iptables
rules: 1) and header-rewriting rule in the Netfilter 'nat' table and;
2) an ACCEPT rule in the Netfilter 'filter' table. DNAT- works like
DNAT but only generates the header-rewriting rule.<br>
</li>
<li>REDIRECT -- Causes the connection request to be redirected to
a port on the local (firewall) system.</li>
<li>REDIRECT- -- The above ACTION (REDIRECT) generates two
iptables rules: 1) and header-rewriting rule in the
Netfilter 'nat' table and; 2) an ACCEPT rule in the Netfilter
'filter' table. REDIRECT- works like REDIRECT but only generates the
header-rewriting rule.<br>
</li>
<li>LOG - Log the packet -- requires
a syslog level (see below).</li>
</ul>
<p>Beginning with Shorewall version 1.4.7, you may rate-limit the
rule by optionally following ACCEPT, DNAT[-], REDIRECT[-] or LOG with<br>
&nbsp;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt; &lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] &gt;<br>
<br>
where<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt; is the number of connections per <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;interval&gt; ("sec" or "min") and &lt;burst&gt; is the largest
burst permitted. If no burst value is given, a value of 5 is assumed.<br>
<br>
There may be no whitespace embedded in the
specification.&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; <br>
<br>
Let's take an example:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp; <br>
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.<br>
<br>
<span style="font-weight: bold;">Warning: </span>When rate
limiting is specified on a rule with "all" 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.<br>
<br>
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.<br>
<br>
The ACTION (and rate limit) may optionally be followed by ":" and a <a
href="shorewall_logging.html">syslog level</a> (example: REJECT:info
or ACCEPT&lt;2/sec:4&gt;: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.<br>
<br>
The use of DNAT or REDIRECT requires that you have <a
href="#NatEnabled">NAT enabled</a>.<br>
</p>
</li>
<li> <br>
</li>
<li><b>SOURCE</b> - 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
"all". If the ACTION is DNAT or REDIRECT, sub-zones may be excluded
from the rule by following the initial zone name with "!' and a
comma-separated list of those sub-zones
to be excluded. There is an <a href="#Exclude">example</a> above.<br>
<br>
If the source is not 'all' then the source may be further restricted by
adding a colon (":") followed by a comma-separated list of qualifiers.
Qualifiers are may include:
<ul>
<li>An interface name - 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 (":") and an IP address or subnet (examples:
loc:eth4:192.168.4.22, net:eth0:192.0.2.0/24).</li>
<li>An IP
address - 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.</li>
<li>A MAC
Address in <a href="configuration_file_basics.htm#MAC">Shorewall format</a>.</li>
<li>A subnet - refers to a connection request from any host in
the specified subnet (example net:155.186.235.0/24).<br>
<br>
</li>
</ul>
</li>
<li><b>DEST</b> - 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:
<ul>
<li>An IP
address followed by a colon and the port <u>number</u> that the server
is listening on (service names from /etc/services are not allowed -
example loc:192.168.1.3:80). <br>
</li>
<li>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.</li>
</ul>
Restrictions:<br>
<ul>
<li>MAC addresses may not be specified.</li>
<li>In DNAT rules, only IP addresses may be given -- DNS names
are not permitted.</li>
<li>You may not specify both an IP address and an interface name
in the DEST column.</li>
</ul>
Unlike in the SOURCE column, a range of IP addresses may be specified
in the DEST column as <i>&lt;first address&gt;-&lt;last address&gt;. </i>When
the ACTION is DNAT or DNAT-, connections will be assigned to the
addresses in the range in a round-robin fashion (load-balancing). <b>This
feature is available with DNAT rules only with Shorewall 1.4.6 and
later versions; it is available with DNAT- rules in all versions that
support DNAT-.</b><br>
<br>
</li>
<li><b> PROTO</b> - Protocol. Must be a protocol name from
/etc/protocols, a number or "all". Specifies the protocol of the
connection request.<br>
<br>
</li>
<li><b> DEST PORT(S)</b> - Port or port range (&lt;low
port&gt;:&lt;high port&gt;) being connected to. May only be specified
if the protocol is tcp, udp or icmp. For icmp, this column's contents
are interpreted as an icmp type. If you don't want to specify DEST
PORT(S) but need to include information in one of the columns to the
right, enter "-" 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.<br>
<br>
</li>
<li><b> SOURCE</b> <b>PORTS(S) </b>- May be used to restrict the
rule to a particular client port or port range (a
port range is specified as &lt;low port number&gt;:&lt;high port
number&gt;). If you don't want to restrict client ports
but want to specify something in the next column, enter "-"
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.<br>
<br>
</li>
<li><b>ORIGINAL DEST</b> - This column may only be non-empty if the
ACTION is DNAT or REDIRECT.<br>
<br>
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.<br>
<br>
The IP address(es) may be optionally followed by ":" 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 "Source NAT" or
SNAT.<br>
<br>
If this list begins with "!" then the rule will only apply if the
original destination address matches none of the addresses listed.<br>
<br>
<b><font color="#ff6633">Note: </font> 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. <br>
<br>
</b>Example: DNAT loc<u>:192.168.1.0/24</u> loc:192.168.1.3 tcp www
- 206.124.146.179:192.168.1.3<b><br>
<br>
</b>If SNAT is not used (no ":" 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.<br>
<br>
</li>
<li><span style="font-weight: bold;">RATE LIMIT </span>- 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<br>
&nbsp;<br>
&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;rate&gt;/&lt;interval&gt;[:&lt;burst&gt;] <br>
<br>
where<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;rate&gt; is the number of connections per <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;interval&gt; ("sec" or "min") and &lt;burst&gt; is the largest
burst permitted. If no burst value is given, a value of 5 is assumed.<br>
<br>
There may be no whitespace embedded in the
specification.&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp; <br>
<br>
Let's take an example:<br>
<br>
&nbsp;&nbsp;&nbsp; &nbsp;ACCEPT&lt;2/sec:4&gt;&nbsp;&nbsp;&nbsp;
net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp; tcp&nbsp;&nbsp;&nbsp; 80<br>
&nbsp;&nbsp; <br>
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.<br>
<br>
<span style="font-weight: bold;">Warning: </span>When rate
limiting is specified on a rule with "all" 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.<br>
<br>
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.<br>
<br>
If you want to specify any following columns but no rate limit, place
"-" in this column.<br>
<br>
</li>
<li><span style="font-weight: bold;">USER SET </span>- Beginning
with Shorewall release 1.4.7, output rules from the firewall itself may
be restricted to a particular set of users and/or user groups. See the <a
href="UserSets.html">User Set Documentation </a>for details.<br>
</li>
</ul>
<p><b> <font face="Century Gothic, Arial, Helvetica"> <a
name="PortForward"></a> </font>Example 1. </b> You wish to forward
all ssh connection requests from the internet to local system
192.168.1.3.&nbsp; You wish to limit the number of connections to
4/minute with a burst of 8 (Shorewall 1.4.7 and later only): </p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET<br>
</span></td>
</tr>
<tr>
<td>DNAT&lt;4/min:8&gt;</td>
<td>net</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 2. </b> 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 <a href="#GettingStarted"> (notice
the "!")</a> originally destined to 206.124.146.177 are redirected to
local port 3128.</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET<br>
</span></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td> -<br>
</td>
<td>!206.124.146.177</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>Example 3. </b> 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.</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td>-</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc</td>
<td>dmz:155.186.235.222</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 4. </b> 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. Note
that since the server is in the 192.168.2.0/24 subnetwork, we can
assume that access to the server from that subnet will not involve the
firewall (<a href="FAQ.htm#faq2">but see FAQ 2</a>). Note that 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 <u>all ftp connections</u> originating
in the local subnet 192.168.1.0/24 would be sent to 192.168.2.2 <u>
regardless of the site that the user was trying to connect to</u>. That
is clearly not what you want <img border="0" src="images/SY00079.gif"
width="20" height="20" align="top"> .</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font><font
face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>dmz:192.168.2.2</td>
<td>tcp</td>
<td>ftp</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>loc:192.168.1.0/24</td>
<td>dmz:192.168.2.2</td>
<td>tcp</td>
<td>ftp</td>
<td>-</td>
<td>155.186.235.151</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p>If you are running wu-ftpd, you should restrict the range of passive
in your /etc/ftpaccess file. I only need a few simultaneous FTP
sessions so I use port range 65500-65535. In /etc/ftpaccess, this entry
is appropriate:</p>
<blockquote>
<p> passive ports 0.0.0.0/0 65500 65534</p>
</blockquote>
<p>If you are running pure-ftpd, you would include "-p 65500:65534" on
the pure-ftpd runline.</p>
<p>The important point here is to ensure that the port range used for
FTP passive connections is unique and will not overlap with any usage
on the firewall system.</p>
<p><b>Example 5. </b>You wish to allow unlimited DMZ access to the
host with MAC address 02:00:08:E3:FA:55.</p>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>loc:~02-00-08-E3-FA-55</td>
<td>dmz</td>
<td>all</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<b>Example 6.</b> You wish to allow access to the SMTP server in your
DMZ from all zones.<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td style="vertical-align: top;"><b>ORIGINAL<br>
DEST<br>
</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">all<br>
</td>
<td valign="top">dmz<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
<br>
Note: When 'all' 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.<br>
</blockquote>
<b>Example 7. </b>Your firewall's external interface has several IP
addresses but you only want to accept SSH connections on address
206.124.146.176.<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td style="vertical-align: top;"><b>ORIGINAL<br>
DEST<br>
</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">fw:206.124.146.176<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">22<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<b>Example 8 (For advanced users running Shorewall version 1.3.13 or
later). </b>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. <br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td style="vertical-align: top;"><b>ORIGINAL<br>
DEST<br>
</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td valign="top">DNAT-<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">192.0.2.178<br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td valign="top">DNAT-<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top">0<br>
</td>
<td valign="top">192.0.2.179<br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">dmz:192.0.2.177<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">25<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
Using "DNAT-" rather than "DNAT" avoids two extra copies of the third
rule from being generated.<br>
<br>
<b>Example 9 (Shorewall version 1.4.6 or later). </b>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.<br>
<br>
<blockquote>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>ACTION</b><br>
</td>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DEST<br>
</b></td>
<td valign="top"><b>PROTO<br>
</b></td>
<td valign="top"><b>DEST<br>
PORT(S)<br>
</b></td>
<td valign="top"><b>SOURCE<br>
PORT(S)<br>
</b></td>
<td style="vertical-align: top;"><b>ORIGINAL<br>
DEST<br>
</b></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">RATE<br>
LIMIT<br>
</span></td>
<td style="vertical-align: top;"><span
style="font-weight: bold;">USER<br>
SET</span></td>
</tr>
<tr>
<td valign="top">DNAT<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">loc:192.168.1.101-192.168.1.109<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><a href="ports.htm">Look here for information on other services.</a>
</p>
<h2><a name="Common"> </a>/etc/shorewall/common</h2>
<p>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.</p>
<p>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 'run_iptables'. That way, if
iptables encounters an error, the firewall will be safely stopped.</p>
<h2><a name="Masq"></a> /etc/shorewall/masq</h2>
<p>The /etc/shorewall/masq file is used to define classical IP
Masquerading and Source Network Address Translation (SNAT). There is
one entry in the file for each subnet that you want to masquerade. In
order to make use of this feature, you must have <a href="#NatEnabled">NAT
enabled</a> .</p>
<p> Columns are:</p>
<ul>
<li><b> INTERFACE</b> - The interface that will masquerade the
subnet; this is normally your internet interface. This interface name
can be optionally qualified by adding ":" 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 <a href="#Conf">/etc/shorewall/shorewall.conf</a>,
you can cause Shorewall to create an alias <i>label </i>of the form <i>interfacename:digit
</i>(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. <b>THAT IS THE ONLY THING THAT THIS LABEL IS GOOD FOR
AND IT MAY NOT APPEAR ANYWHERE ELSE IN YOUR SHOREWALL CONFIGURATION.</b></li>
<li><b> SUBNET</b> - 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 'ip'
utility. <b><font color="#ff0000">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.</font></b><br>
<br>
The subnet may be optionally followed by "!' and a comma-separated list
of addresses and/or subnets that are to be excluded from masquerading.</li>
<li><b>ADDRESS</b> - The source address to be used for outgoing
packets. This column is optional and if left blank, the current primary
IP address of the interface in the first column is used. If you have a
static IP on that interface, listing it here makes processing of output
packets a little less expensive for the firewall. If you specify an
address in this column, it must be an IP address configured on the
INTERFACE or you must have
ADD_SNAT_ALIASES enabled in <a href="#Conf">/etc/shorewall/shorewall.conf.</a>
Beginning with Shorewall version 1.4.6, you may include a range of IP
addresses in this column to indicate that Netfilter should use the
addresses in the range in round-robin fashion. Beginning with Shorewall
version 1.4.7, you may include a list of ranges and/or addresses in
this column; again, Netfilter will use all listed ranges/addresses in
rounde-robin fashion.</li>
</ul>
<p><b>Example 1: </b> 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: </p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.9.0/24</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 2:</b> 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.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>ipsec0:10.1.0.0/16</td>
<td>192.168.9.0/24</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b> Example 3:</b> You have a DSL line connected on eth0 and a local
network (192.168.10.0/24) connected to eth1. You want all local-&gt;net
connections to use source address 206.124.146.176.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.10.0/24</td>
<td>206.124.146.176</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>Example 4: </b> Same as example 3 except that you wish to
exclude 192.168.10.44 and 192.168.10.45
from the SNAT rule.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.10.0/24!192.168.10.44,192.168.10.45</td>
<td>206.124.146.176</td>
</tr>
</tbody>
</table>
</blockquote>
<b>Example 5 (Shorewall version &gt;= 1.3.14): </b>You have a second
IP address (206.124.146.177) assigned to you and wish to use it for
SNAT of the subnet 192.168.12.0/24. You want to give that address the
name eth0:0. You must have ADD_SNAT_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>.<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0:0</td>
<td>192.168.12.0/24</td>
<td>206.124.146.177</td>
</tr>
</tbody>
</table>
</blockquote>
<span style="font-weight: bold;">Example 6 (Shorewall version &gt;=
1.4.7): </span>You want to use both 206.124.146.177 and
206.124.146.179 for SNAT of the subnet 192.168.12.0/24. Each address
will be used on alternate outbound connections.<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> INTERFACE</b></td>
<td><b> SUBNET</b></td>
<td><b>ADDRESS</b></td>
</tr>
<tr>
<td>eth0</td>
<td>192.168.12.0/24</td>
<td>206.124.146.177,206.124.146.179</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><font color="#660066"><b><a name="ProxyArp"></a> </b></font>/etc/shorewall/proxyarp</h2>
<p>If you want to use proxy ARP on an entire sub-network, I suggest
that you look at <a
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>. 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/<i>&lt;interface&gt;</i>/proxy_arp)
by including the <b> proxyarp</b> option in the interface's record in <a
href="#Interfaces"> /etc/shorewall/interfaces</a>. When using Proxy
ARP sub-netting, you do <u>NOT</u> include any entries in
/etc/shorewall/proxyarp. </p>
<p>The /etc/shorewall/proxyarp file is used to define <a
href="ProxyARP.htm">Proxy ARP</a>. The file is typically used for
enabling Proxy ARP on a
small set of systems
since you need
one entry in this file for each system using proxy ARP. Columns are:</p>
<ul>
<li><b> ADDRESS</b> - address of the system.</li>
<li><b> INTERFACE</b> - the interface that connects to the system. If
the interface is obvious from the subnetting, you
may enter "-" in this column.</li>
<li><b> EXTERNAL</b> - the external interface that you want to honor
ARP requests for the ADDRESS specified in the first column.</li>
<li><b>HAVEROUTE</b> - If you already have a route through INTERFACE
to ADDRESS, this column should contain "Yes" or "yes". If you want
Shorewall to add the route, the column should contain "No" or "no".</li>
</ul>
<p><font color="#cc6666"><b>Note: 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.</b></font></p>
<p><font color="#cc6666"><b>ISPs typically have ARP configured with
long TTL (hours!) so if your ISPs router has a stale cache entry (as
seen using "tcpdump -nei &lt;external interface&gt; host &lt;IP
addr&gt;"), 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. </b></font></p>
<p><b>Example: </b> You have public IP addresses 155.182.235.0/28. You
configure your firewall as follows:</p>
<ul>
<li>eth0 - 155.186.235.1 (internet connection)</li>
<li>eth1 - 192.168.9.0/24 (masqueraded local systems)</li>
<li>eth2 - 192.168.10.1 (interface to your DMZ)</li>
</ul>
<p> In your DMZ, you want to install a Web/FTP server with public
address 155.186.235.4. On the Web server, you subnet just like the
firewall's eth0 and you configure 155.186.235.1 as the default gateway.
In your /etc/shorewall/proxyarp file, you will have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b> ADDRESS</b></td>
<td><b> INTERFACE</b></td>
<td><b> EXTERNAL</b></td>
<td><b>HAVEROUTE</b></td>
</tr>
<tr>
<td>155.186.235.4</td>
<td>eth2</td>
<td>eth0</td>
<td>No</td>
</tr>
</tbody>
</table>
</blockquote>
<p> Note: 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 Proxy ARP Subnet Mini HOWTO (<a
href="http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/">http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/</a>)
for details. In this case you will want to place "Yes" in the HAVEROUTE
column.</p>
<p><font color="#ff6633"><b>Warning: </b></font>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't had the time to debug this
problem so I can't say if it is a bug in the Kernel or in FreeS/Wan. </p>
<p>You <b>might</b> be able to work around this problem using the
following (I haven't tried it):</p>
<p>In /etc/shorewall/init, include:</p>
<p> qt service ipsec stop</p>
<p>In /etc/shorewall/start, include:</p>
<p> qt service ipsec start</p>
<h2><font color="#660066"><b><a name="NAT"></a> </b></font>/etc/shorewall/nat</h2>
<p>The /etc/shorewall/nat file is used to define static NAT. There is
one entry in the file for each static NAT relationship that you wish to
define. In order to make use of this feature, you must have <a
href="#NatEnabled">NAT enabled</a> .</p>
<p> <font color="#ff0000"> <b>IMPORTANT: If all you want to do is
forward ports to servers behind your firewall, you do NOT want to use
static NAT. Port forwarding can be accomplished with simple entries in
the <a href="#Rules"> rules file</a>. Also, in most cases <a
href="#ProxyArp"> Proxy ARP</a> provides a superior solution to static
NAT because the internal systems are accessed using the same IP address
internally and externally.</b></font></p>
<p>Columns in an entry are:</p>
<ul>
<li><b> EXTERNAL</b> - External IP address - <u>This should NOT be
the primary IP address of the interface named in the next column.</u></li>
<li><b> INTERFACE</b> - Interface that you want the EXTERNAL IP
address to appear on. Beginning with Shorewall version 1.3.14, if you
have set ADD_IP_ALIASES=Yes in <a href="#Conf">/etc/shorewall/shorewall.conf</a>,
&nbsp;you can specify an alias label of the form <i>interfacename:digit
</i>(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. <b>THAT IS THE ONLY THING
THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE
ELSE IN YOUR SHOREWALL CONFIGURATION.</b>&nbsp;</li>
<li><b> INTERNAL </b> - Internal IP address.</li>
<li><b>ALL INTERFACES</b> - 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.</li>
<li><b>LOCAL</b> - If Yes or yes and the ALL INTERFACES column
contains Yes or yes, NAT will be effective from the firewall system. <b>Note:
</b>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 <b>CONFIG_IP_NF_NAT_LOCAL</b> in your kernel.</li>
</ul>
<p><b><a href="NAT.htm"> Look here for additional information and an
example.</a> </b></p>
<h2><font color="#660066"><a name="Tunnels"></a> </font>/etc/shorewall/tunnels</h2>
<p> The /etc/shorewall/tunnels file allows you to define IPSec, GRE,
IPIP, <a href="http://openvpn.sourceforge.net/">OpenVPN</a>, PPTP and
6to4.tunnels with end-points on your firewall. To use ipsec, you must
install version 1.9, 1.91 or the current <a
href="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</a> development
snapshot.
</p>
<p> Note: For kernels 2.4.4 and above, you will need to use version
1.91 or a development snapshot as patching with version 1.9 results in
kernel compilation errors.</p>
<p><b><a href="IPSEC.htm"> Instructions for setting up IPSEC tunnels
may be found here,</a></b> <b><a href="IPIP.htm">instructions for IPIP
and GRE tunnels are here</a></b>, <b><a href="OPENVPN.html">instructions
for OpenVPN tunnels are here</a></b>, <b><a href="PPTP.htm">instructions
for PPTP tunnels are here</a>, <a href="6to4.htm">instructions for
6to4 tunnels are here</a> and <a href="GenericTunnels.html">instructions
for integrating Shorewall with other types of tunnels are here</a>.<br>
</b></p>
<h2><a name="Conf"></a>/etc/shorewall/shorewall.conf</h2>
<p> This file is used to set the following firewall parameters:</p>
<ul>
<li><b>ADMINISABSENTMINDED </b>- Added at version 1.4.7<br>
The value of this variable affects Shorewall's <a
href="starting_and_stopping_shorewall.htm">stopped state</a>. When
ADMINISABSENTMINDES=No,
only traffic to/from those addresses listed in
/etc/shorewall/routestopped
is accepted when Shorewall is stopped.When ADMINISABSENTMINDED=Yes, in
addition
to traffic to/from addresses in /etc/shorewall/routestopped,
&nbsp;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.<br>
</li>
<li><b>SHOREWALL_SHELL </b>- Added at version 1.4.6<br>
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.<br>
</li>
<li><b>LOGFORMAT - </b>Added at version 1.4.4.<br>
The value of this variable generate the --log-prefix setting for
Shorewall logging rules. It contains a 'printf' formatting template
which accepts three arguments (the chain name, logging rule number
(optional) and the disposition). To use LOGFORMAT with fireparse (<a
href="http://www.fireparse.com">http://www.fireparse.com</a>), set it
as:<br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LOGFORMAT="fp=%s:%d a=%s "<br>
&nbsp;<br>
If the LOGFORMAT value contains the substring '%d' 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="") then "Shorewall:%s:%s:" is
assumed.<br>
<br>
<b>CAUTION: </b>/sbin/shorewall uses the leading part of the
LOGFORMAT string (up to but not including the first '%')
to find log messages in the 'show log', 'status' and 'hits' commands.
This part should not be omitted (the LOGFORMAT should not begin with
"%") and the leading part should be sufficiently unique for
/sbin/shorewall to identify Shorewall messages.<br>
</li>
<li><b>CLEAR_TC</b> - Added at version 1.3.13<br>
If this option is set to 'No' then Shorewall won't clear the current
traffic control rules during [re]start. This setting is intended for
use by people that prefer to configure traffic shaping when the network
interfaces come up rather than when the firewall is started. If that is
what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not
supply an /etc/shorewall/tcstart file. That way, your traffic shaping
rules can still use the 'fwmark' classifier based on packet marking
defined in /etc/shorewall/tcrules. If not specified, CLEAR_TC=Yes is
assumed.<br>
</li>
<li><b>MARK_IN_FORWARD_CHAIN </b>- Added at version 1.3.12<br>
If your kernel has a FORWARD chain in the mangle table, you may set
MARK_IN_FORWARD_CHAIN=Yes to cause the marking specified in the <a
href="traffic_shaping.htm#tcrules">tcrules file</a> to occur in that
chain rather than in the PREROUTING chain. This permits you to mark
inbound traffic based on its destination address when SNAT or
Masquerading are in use. To determine if your kernel has a FORWARD
chain in the mangle table, use the "/sbin/shorewall show mangle"
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="") then
MARK_IN_FORWARD_CHAIN=No is assumed.<br>
</li>
<li><b>RFC1918_LOG_LEVEL
- </b>Added at version 1.3.12<br>
This parameter determines
the level at which packets logged under the <a
href="Documentation.htm#rfc1918">'norfc1918' mechanism </a> are
logged. The value must be a valid <a href="shorewall_logging.html">syslog
level</a> and if no level is given, then info is assumed. Prior to
Shorewall version 1.3.12, these packets are always logged at the info
level.</li>
<li><b>TCP_FLAGS_DISPOSITION - </b>Added in Version 1.3.11<br>
Determines the disposition
of TCP packets that fail the checks enabled by the <a
href="#Interfaces%5C">tcpflags</a> interface option and
must have a value of ACCEPT (accept the packet), REJECT (send
an RST response) or DROP (ignore the packet). If not set
or if set to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then
TCP_FLAGS_DISPOSITION=DROP is assumed.</li>
<li><b>TCP_FLAGS_LOG_LEVEL - </b>Added in Version 1.3.11<br>
Determines the <a href="shorewall_logging.html">syslog level</a> for
logging packets that fail the checks enabled by the <a
href="#Interfaces">tcpflags</a> interface option.The value must be a
valid syslogd log level. If you don't want to log these packets, set to
the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").<br>
</li>
<li><b>MACLIST_DISPOSITION </b>- Added in Version 1.3.10<br>
Determines the disposition of connections requests that fail <a
href="MAC_Validation.html">MAC Verification</a> and must have the
value ACCEPT (accept the connection request anyway), REJECT (reject the
connection request) or DROP (ignore the connection request). If not set
or if set to the empty value (e.g., MACLIST_DISPOSITION="") then
MACLIST_DISPOSITION=REJECT is assumed.</li>
<li><b>MACLIST_LOG_LEVEL </b>- Added in Version 1.3.10<br>
Determines the <a href="shorewall_logging.html">syslog level</a> for
logging connection requests that fail <a href="MAC_Validation.html">MAC
Verification</a>. The value must be a valid syslogd log level. If you
don't want to log these connection requests, set to the empty value
(e.g., MACLIST_LOG_LEVEL="").<br>
</li>
<li><b>NEWNOTSYN </b>- Added in Version 1.3.8<br>
When set to "Yes" or "yes", 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 "No", Shorewall will silently drop
such packets. If not set or set to the empty value (e.g.,
"NEWNOTSYN="), NEWNOTSYN=No is assumed.<br>
<br>
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.<br>
</li>
<li><b>LOGNEWNOTSYN</b> - Added in Version 1.3.6<br>
Beginning with version 1.3.6, Shorewall drops non-SYN TCP packets that
are not part of an existing connection. If you would like to log these
packets, set LOGNEWNOTSYN to the <a href="shorewall_logging.html">syslog
level</a> at which you want the packets logged. Example:
LOGNEWNOTSYN=ULOG|<br>
<br>
<b>Note: </b>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.</li>
<li><b>DETECT_DNAT_ADDRS</b> - Added in Version 1.3.4<br>
If set to "Yes" or "yes", 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 "No" or "no", Shorewall will
not detect this address and any destination IP address will
match the DNAT rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes"
is assumed.<br>
</li>
<li><b>MULTIPORT</b> - (Removed in version 1.4.6 -- the value of this
parameter is now automatically detected by Shorewall)<br>
If set to "Yes" or "yes", 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:<br>
<ul>
<li>No port range(s) specified</li>
<li>Specifies 15 or fewer ports</li>
</ul>
<p>Rules not meeting those criteria will continue to generate an
individual rule for each listed port or port range. </p>
</li>
<li><b>NAT_BEFORE_RULES</b><br>
If set to "No" or "no", port forwarding rules can override the contents
of the <a href="#NAT">/etc/shorewall/nat</a> file. If set to "Yes" or
"yes", port forwarding rules cannot override static NAT. If not set or
set to an empty value,
"Yes" is assumed.</li>
<li><b>FW<br>
</b>This parameter specifies the name of the firewall zone. If not
set or if set to an empty string, the value "fw" is assumed.</li>
<li><b>SUBSYSLOCK</b><br>
This parameter should be set to the name of a file that the firewall
should create if it starts successfully and remove when it stops.
Creating and removing this file allows Shorewall to work with your
distribution's initscripts. For RedHat, this should be set to
/var/lock/subsys/shorewall. For Debian, the value is
/var/state/shorewall and in LEAF it is /var/run/shorwall. Example:
SUBSYSLOCK=/var/lock/subsys/shorewall.</li>
<li><b> STATEDIR</b><br>
This parameter specifies the name of a directory where Shorewall stores
state information. If the directory doesn't exist when Shorewall
starts, it will create the directory. Example: STATEDIR=/tmp/shorewall.<br>
<br>
<b>NOTE:</b> 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. </li>
<li><b>MODULESDIR</b><br>
This parameter specifies the directory where your kernel netfilter
modules may be found. If you leave the variable empty, Shorewall will
supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.</li>
<li><b> LOGRATE </b> and <b> LOGBURST</b><br>
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.<br>
<br>
Example:<br>
LOGRATE=10/minute<br>
LOGBURST=5<br>
</li>
<li><b>LOGFILE</b><br>
This parameter tells the /sbin/shorewall program where to look for
Shorewall messages when processing the "show log", "monitor", "status"
and "hits" commands. If not assigned or if assigned an empty value,
/var/log/messages is assumed.</li>
<li><b>NAT_ENABLED</b> (Removed in Shorewall 1.4.6 -- the value of
this parameter is now automatically detected by Shorewall)<br>
This parameter determines whether Shorewall supports NAT operations.
NAT operations include:<br>
<br>
Static NAT<br>
Port Forwarding<br>
Port Redirection<br>
Masquerading<br>
<br>
If the parameter has no value or has a value of "Yes" or "yes" then NAT
is enabled. If the parameter has a value of "no" or "No" then NAT is
disabled.<br>
</li>
<li><b> MANGLE_ENABLED</b> (Removed in Shorewall 1.4.6 -- the value
of this parameter is now automatically detected by Shorewall)<br>
This parameter determines if packet mangling is enabled. If the
parameter has no value or has a value of "Yes" or "yes" than packet
mangling is enabled. If the parameter has a value of "no" or "No" then
packet mangling is disabled. If packet mangling is disabled, the
/etc/shorewall/tos file is ignored.<br>
</li>
<li><b> IP_FORWARDING</b><br>
This parameter determines whether Shorewall enables or disables IPV4
Packet Forwarding (/proc/sys/net/ipv4/ip_forward). Possible values are:<br>
<br>
On or on - packet forwarding will be enabled.<br>
Off or off - packet forwarding will be disabled.<br>
Keep or keep - Shorewall will neither enable nor disable packet
forwarding.<br>
<br>
If this variable is not set or is given an empty value (IP_FORWARD="")
then IP_FORWARD=On is assumed.<br>
</li>
<li><b>ADD_IP_ALIASES</b><br>
This parameter determines whether Shorewall automatically adds the <i>external
</i>address(es) in <a href="#NAT">/etc/shorewall/nat</a> . If the
variable is set to "Yes" or "yes" then Shorewall automatically adds
these aliases. If it is set to "No" or "no", you must add these aliases
yourself using your distribution's network configuration tools. <b>RESTRICTION:
</b>Shorewall versions before 1.4.6 can only add addresses to the
first subnetwork configured on an interface.<br>
<br>
If this variable is not set or is given an empty value
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.</li>
<li><b>ADD_SNAT_ALIASES</b><br>
This parameter determines whether Shorewall automatically adds the SNAT
<i> ADDRESS </i>in <a href="#Masq">/etc/shorewall/masq</a>. If
the variable is set to "Yes" or "yes" then Shorewall automatically adds
these addresses. If it is set
to "No" or "no", you must add these addresses yourself using your
distribution's network configuration tools. <b>RESTRICTION: </b>Shorewall
versions before 1.4.6 can only
add addresses to the first subnetwork configured on an interface.<br>
<br>
If this variable is not set or is given an empty value
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.<br>
</li>
<li><b>LOGUNCLEAN</b><br>
This parameter determines the logging level of mangled/invalid packets
controlled by the '<a href="#Unclean">dropunclean and logunclean</a>'
interface options. If LOGUNCLEAN is empty (LOGUNCLEAN=) then packets
selected by 'dropclean' are dropped silently ('logunclean' packets are
logged under the 'info' log level). Otherwise, these packets are logged
at the specified level (Example: LOGUNCLEAN=debug).</li>
<li><b>BLACKLIST_DISPOSITION</b><br>
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.</li>
<li><b>BLACKLIST_LOGLEVEL</b><br>
This paremter determines if packets from blacklisted hosts are logged
and it determines the syslog level that they are to be logged at. Its
value is a <a href="shorewall_logging.html">syslog level</a> (Example:
BLACKLIST_LOGLEVEL=debug). If you do
not assign a value or if you assign an empty value then packets from
blacklisted hosts are not logged.</li>
<li><b>CLAMPMSS</b><br>
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 "Yes"
or "yes", the feature is enabled. If left blank or set to "No" or "no",
the feature is not enabled. Note: This option requires
CONFIG_IP_NF_TARGET_TCPMSS <a href="kernel.htm">in your kernel</a>.</li>
<li><b>ROUTE_FILTER</b><br>
If this parameter is given the value "Yes" or "yes" then route
filtering (anti-spoofing) is enabled on all network interfaces. The
default value is "no".</li>
</ul>
<h2><a name="modules"></a> /etc/shorewall/modules Configuration</h2>
<p>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 <a
href="#Conf">/etc/shorewall/shorewall.conf</a> above).</p>
<p>The file that is released with Shorewall calls the Shorewall
function "loadmodule" for the set of modules that I load.</p>
<p>The <i>loadmodule</i> function is called as follows:</p>
<blockquote>
<p>loadmodule <i>&lt;modulename&gt; </i>[ <i> &lt;module
parameters&gt; </i>]</p>
</blockquote>
<p>where</p>
<blockquote>
<p><i>&lt;modulename&gt; </i></p>
<blockquote>
<p>is the name of the modules without the trailing ".o" (example
ip_conntrack).</p>
</blockquote>
<p><i> &lt;module parameters&gt;</i></p>
<blockquote>
<p> Optional parameters to the insmod utility.</p>
</blockquote>
</blockquote>
<p> The function determines if the module named by <i>&lt;modulename&gt;
</i> is already loaded and if not then the function determines if the
".o" file corresponding to the module exists in the <i>moduledirectory</i>;
if so, then the following command is executed:</p>
<blockquote>
<p> insmod <i>moduledirectory</i>/<i>&lt;modulename&gt;</i>.o <i>&lt;module
parameters&gt;</i></p>
</blockquote>
<p> If the file doesn't exist, the function determines of the ".o.gz"
file corresponding to the module exists in the <i>moduledirectory</i>.
If
it does, the function assumes that the running configuration supports
compressed modules and execute the following command:</p>
<blockquote>
<p> insmod <i>moduledirectory/&lt;modulename&gt;.</i>o.gz &lt;<i>module
parameters&gt;</i></p>
</blockquote>
<h2><a name="TOS"></a> /etc/shorewall/tos Configuration</h2>
<p> 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 <a href="#MangleEnabled">mangle
support enabled</a> .</p>
<p> Entries in the file have the following columns:</p>
<ul>
<li><b> SOURCE</b> -- The source zone. May be qualified by following
the zone name with a colon (":") and either an IP address, an IP
subnet, a MAC address <a href="configuration_file_basics.htm#MAC">in </a><a
href="configuration_file_basics.htm#MAC">Shorewall Format</a> or the
name of an interface. This column may also contain the <a href="#FW">name
of the firewall</a> zone to indicate packets originating on the
firewall itself or "all" to indicate any source.</li>
<li><b> DEST</b> -- The destination zone. May be qualified by
following the zone name with a colon (":") 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 "all" to
indicate any destination.</li>
<li><b> PROTOCOL</b> -- The name of a protocol in /etc/protocols or
the protocol's number.</li>
<li><b> SOURCE PORT(S)</b> -- The source port or a port range. For
all ports, place a hyphen ("-") in this column.</li>
<li><b> DEST PORT(S)</b> -- The destination port or a port range. To
indicate all ports, place a hyphen ("-") in this column.</li>
<li><b> TOS</b> -- The type of service. Must be one of the following:</li>
</ul>
<blockquote>
<blockquote>
<p> Minimize-Delay (16)<br>
Maximize-Throughput (8)<br>
Maximize-Reliability (4)<br>
Minimize-Cost (2)<br>
Normal-Service (0)</p>
</blockquote>
</blockquote>
<p> The /etc/shorewall/tos file that is included with Shorewall
contains the following entries.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTOCOL</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>DEST PORT(S)</b></td>
<td><b>TOS</b></td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ssh</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ftp</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ftp</td>
<td>-</td>
<td>16</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>-</td>
<td>ftp-data</td>
<td>8</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>tcp</td>
<td>ftp-data</td>
<td>-</td>
<td>8</td>
</tr>
</tbody>
</table>
</blockquote>
<p><b>WARNING: </b>Users have reported that odd routing problems
result from adding the ESP and AH protocols to the /etc/shorewall/tos
file. </p>
<h2><a name="Blacklist"></a>/etc/shorewall/blacklist</h2>
<p>Each line in /etc/shorewall/blacklist contains an IP address, a MAC
address in <a href="configuration_file_basics.htm#MAC">Shorewall Format</a>
or subnet address. Example:</p>
<pre> 130.252.100.69<br> 206.124.146.0/24</pre>
<p>Packets <u><b>from</b></u> hosts listed in the blacklist file will
be disposed of according to the value assigned to the <a href="#Conf">BLACKLIST_DISPOSITION</a>
and <a href="#Conf">BLACKLIST_LOGLEVEL </a>variables in
/etc/shorewall/shorewall.conf. Only packets arriving on interfaces that
have the '<a href="#Interfaces">blacklist</a>' option in
/etc/shorewall/interfaces are checked against the blacklist. The black
list is designed to prevent listed hosts/subnets from accessing
services on <u><b>your</b></u> network.<br>
</p>
<p>Beginning with Shorewall 1.3.8, the blacklist file has three columns:<br>
</p>
<ul>
<li><b>ADDRESS/SUBNET - </b>As described above.</li>
<li><b>PROTOCOL</b> - Optional. If specified, only packets specifying
this protocol will be blocked.</li>
<li><b>PORTS - </b>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 "iptables -h icmp").<br>
</li>
</ul>
<p>Shorewall also has a <a href="blacklisting_support.htm">dynamic
blacklist capability.</a></p>
<p><font color="#cc6666"><b>IMPORTANT: The Shorewall blacklist file is <u>NOT</u>
designed to police your users' web browsing -- to do that, I suggest
that you install and configure Squid (<a
href="http://www.squid-cache.org">http://www.squid-cache.org</a>) with
SquidGuard (<a href="http://www.squidguard.org/">http://www.squidguard.org/</a>).
</b></font></p>
<h2><a name="rfc1918"></a>/etc/shorewall/rfc1918 (Added in Version
1.3.1)</h2>
<p>This file lists the subnets affected by the <a href="#Interfaces"><i>norfc1918</i>
interface option</a>. Columns in the file are:</p>
<ul>
<li><b>SUBNET</b> - The subnet using VLSM notation (e.g.,
192.168.0.0/16).</li>
<li><b>TARGET<i> </i></b>- What to do with packets to/from the
SUBNET:
<ul>
<li><b>RETURN</b> - Process the packet normally thru the rules
and policies.</li>
<li><b>DROP</b> - Silently drop the packet.</li>
<li><b>logdrop</b> - Log then drop the packet -- see the <a
href="#Conf">RFC1918_LOG_LEVEL</a> parameter above.</li>
</ul>
</li>
</ul>
<h2><a name="Routestopped"></a>/etc/shorewall/routestopped (Added in
Version 1.3.4)</h2>
<p>This file defines the hosts that are accessible from the firewall
when the firewall is stopped. Columns in the file are:</p>
<ul>
<li><b>INTERFACE </b>- The firewall interface through which the
host(s) comminicate with the firewall.</li>
<li><b>HOST(S) </b>- (Optional) - A comma-separated list of
IP/Subnet addresses. If not supplied or supplied as "-" then 0.0.0.0/0
is assumed.</li>
</ul>
<p>Example: 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.</p>
<blockquote>
<table border="2" style="border-collapse: collapse;" id="AutoNumber1"
cellpadding="2">
<tbody>
<tr>
<td><u><b>INTERFACE</b></u></td>
<td><u><b>HOST(S)</b></u></td>
</tr>
<tr>
<td>eth2</td>
<td>192.168.1.0/24</td>
</tr>
<tr>
<td>eth1</td>
<td>-</td>
</tr>
</tbody>
</table>
</blockquote>
<h2><a name="Maclist"></a>/etc/shorewall/maclist (Added in Version
1.3.10)</h2>
This file is described in the <a href="MAC_Validation.html">MAC
Validation Documentation</a>.<br>
<h2><a name="ECN"></a>/etc/shorewall/ecn (Added in Version 1.4.0)</h2>
This file is described in the <a href="ECN.html">ECN Control
Documentation</a>.<br>
<p><font size="-1"> Updated 8/21/2003 - <a href="support.htm">Tom
Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> <20> <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink