extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-04 21:41:15 +01:00
Code Issues Packages Projects Releases Wiki Activity
b2729de062
shorewall_code/STABLE/documentation/Documentation.htm
teastep 07d90b6fe4 Shorewall-1.4.6 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@672 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2003-07-21 22:06:18 +00:00

3484 lines
215 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><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>
<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.</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>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <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>
</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>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <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 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>
</tr>
<tr>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
<tr>
<td>DNAT</td>
<td>sam</td>
<td>fw</td>
<td>tcp</td>
<td>ssh</td>
<td>-</td>
<td> <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>
</tr>
<tr>
<td>...</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <br>
</td>
<td> <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>The ACTION may optionally be followed by ":" and a <a
href="shorewall_logging.html">syslog level</a> (example: REJECT:info).
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><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).</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).<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.</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.</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.</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.</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. </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>
</tr>
<tr>
<td>DNAT</td>
<td>net</td>
<td>loc:192.168.1.3</td>
<td>tcp</td>
<td>ssh</td>
<td> <br>
</td>
<td> <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>
</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>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <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>
</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>
</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>
</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>
</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>
</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>
</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>
</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>
</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 valign="top"><b>ORIGINAL<br>
DEST<br>
</b></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>
</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 valign="top"><b>ORIGINAL<br>
DEST<br>
</b></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>
</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 valign="top"><b>ORIGINAL<br>
DEST<br>
</b></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>
</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>
</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>
</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 valign="top"><b>ORIGINAL<br>
DEST<br>
</b></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>
</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></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>
<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>,
<20>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><EFBFBD></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> and <a href="6to4.htm">instructions for 6to4
tunnels</a> are here.</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>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>
<20><br>
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD> LOGFORMAT="fp=%s:%d a=%s "<br>
<20><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>).
</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 6/28/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>
<br>
<br>
<br>
<br>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink