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

Initial revision

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1143 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-02-14 18:06:39 +00:00
parent 870366caf7
commit a44e4a46f8
220 changed files with 348543 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
Shorewall-docs2/6to4.xml Normal file
View File

@ -0,0 +1,111 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>6to4 Tunnels</title>
<authorgroup>
<author>
<firstname>Eric</firstname>
<surname>de Thouars</surname>
</author>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-05</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Eric de Thoars and Tom Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<warning>
<para>The 6to4 tunnel feature of Shorewall only facilitates IPv6 over IPv4
tunneling. It does not provide any IPv6 security measures.</para>
</warning>
<para>6to4 tunneling with Shorewall can be used to connect your IPv6 network
to another IPv6 network over an IPv4 infrastructure.</para>
<para>More information on Linux and IPv6 can be found in the <ulink
url="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO</ulink>.
Details on how to setup a 6to4 tunnels are described in the section <ulink
url="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/configuring-ipv6to4-tunnels.html">Setup
of 6to4 tunnels</ulink>.</para>
<section>
<title>Connecting two IPv6 Networks</title>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoIPv6Nets1.png" />
<para>We want systems in the 2002:100:333::/64 subnetwork to be able to
communicate with the systems in the 2002:488:999::/64 network. This is
accomplished through use of the <filename><filename>/etc/shorewall/tunnels</filename></filename>
file and the <quote>ip</quote> utility for network interface and routing
configuration.</para>
<para>Unlike GRE and IPIP tunneling, the <filename>/etc/shorewall/policy</filename>,
<filename>/etc/shorewall/interfaces</filename> and <filename>/etc/shorewall/zones</filename>
files are not used. There is no need to declare a zone to represent the
remote IPv6 network. This remote network is not visible on IPv4 interfaces
and to iptables. All that is visible on the IPv4 level is an IPv4 stream
which contains IPv6 traffic. Separate IPv6 interfaces and ip6tables rules
need to be defined to handle this traffic.</para>
<para>In <filename>/etc/shorewall/tunnels </filename>on system A, we need
the following:</para>
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
6to4 net 134.28.54.2</programlisting>
<para>This entry in <filename>/etc/shorewall/tunnels</filename>, opens the
firewall so that the IPv6 encapsulation protocol (41) will be accepted
to/from the remote gateway.</para>
<para>Use the following commands to setup system A:</para>
<programlisting>&#62;<command>ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2</command>
&#62;<command>ip link set dev tun6to4 up</command>
&#62;<command>ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4</command>
&#62;<command>ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2</command></programlisting>
<para>Similarly, in <filename>/etc/shorewall/tunnels</filename> on system
B we have:</para>
<programlisting>#TYPE ZONE GATEWAY GATEWAY ZONE
6to4 net 206.191.148.9</programlisting>
<para>And use the following commands to setup system B:</para>
<programlisting>&#62;<command>ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9</command>
&#62;<command>ip link set dev tun6to4 up</command>
&#62;<command>ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4</command>
&#62;<command>ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1</command></programlisting>
<para>On both systems, restart Shorewall and issue the configuration
commands as listed above. The systems in both IPv6 subnetworks can now
talk to each other using IPv6.</para>
</section>
</article>

231
Shorewall-docs2/Accounting.xml Normal file
View File

@ -0,0 +1,231 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Shorewall Traffic Accounting</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-05</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>Shorewall Traffic Accounting support was added in Shorewall release
1.4.7.</para>
<para>Shorewall accounting rules are described in the file
/etc/shorewall/accounting. By default, the accounting rules are placed in a
chain called <quote>accounting</quote> and can thus be displayed using
<quote>shorewall show accounting</quote>. All traffic passing into, out of
or through the firewall traverses the accounting chain including traffic
that will later be rejected by interface options such as <quote>tcpflags</quote>
and <quote>maclist</quote>. If your kernel doesn&#39;t support the
connection tracking match extension (Kernel 2.4.21) then some traffic
rejected under <quote>norfc1918</quote> will not traverse the accounting
chain.</para>
<para>The columns in the accounting file are as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">ACTION </emphasis>- What to do when a match
is found. Possible values are:</para>
<itemizedlist>
<listitem>
<para>COUNT- Simply count the match and continue trying to match the
packet with the following accounting rules</para>
</listitem>
<listitem>
<para>DONE- Count the match and don&#39;t attempt to match any
following accounting rules.</para>
</listitem>
<listitem>
<para><emphasis>&#60;chain&#62;</emphasis> - The name of a chain to
jump to. Shorewall will create the chain automatically. If the name
of the chain is followed by <quote>:COUNT</quote> then a COUNT rule
matching this rule will automatically be added to &#60;chain&#62;.
Chain names must start with a letter, must be composed of letters
and digits, and may contain underscores (<quote>_</quote>) and
periods (<quote>.</quote>). Beginning with Shorewall version 1.4.8,
chain names man also contain embedded dashes (<quote>-</quote>) and
are not required to start with a letter.</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><emphasis role="bold">CHAIN</emphasis> - The name of the chain
where the accounting rule is to be added. If empty or <quote>-</quote>
then the <quote>accounting</quote> chain is assumed.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SOURCE</emphasis> - Packet Source. The name
of an interface, an address (host or net) or an interface name followed
by <quote>:</quote> and a host or net address.</para>
</listitem>
<listitem>
<para><emphasis role="bold">DESTINATION</emphasis> - Packet Destination
Format the same as the SOURCE column.</para>
</listitem>
<listitem>
<para><emphasis role="bold">PROTOCOL</emphasis> - A protocol name (from
<filename>/etc/protocols</filename>) or a protocol number.</para>
</listitem>
<listitem>
<para><emphasis role="bold">DEST PORT</emphasis> - Destination Port
number. Service name from <filename>/etc/services</filename> or port
number. May only be specified if the protocol is TCP or UDP (6 or 17).</para>
</listitem>
<listitem>
<para><emphasis role="bold">SOURCE PORT</emphasis>- Source Port number.
Service name from /etc/services or port number. May only be specified if
the protocol is TCP or UDP (6 or 17).</para>
</listitem>
</itemizedlist>
<para>In all columns except ACTION and CHAIN, the values <quote>-</quote>,<quote>any</quote>
and <quote>all</quote> are treated as wild-cards.</para>
<para>The accounting rules are evaluated in the Netfilter <quote>filter</quote>
table. This is the same environment where the <quote>rules</quote> file
rules are evaluated and in this environment, DNAT has already occurred in
inbound packets and SNAT has not yet occurred on outbound ones.</para>
<para>Accounting rules are not stateful -- each rule only handles traffic in
one direction. For example, if eth0 is your internet interface and you have
a web server in your DMZ connected to eth1 then to count HTTP traffic in
both directions requires two rules:</para>
<programlisting> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
DONE - eth0 eth1 tcp 80
DONE - eth1 eth0 tcp - 80</programlisting>
<para>Associating a counter with a chain allows for nice reporting. For
example:</para>
<programlisting> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
web:COUNT - eth0 eth1 tcp 80
web:COUNT - eth1 eth0 tcp - 80
web:COUNT - eth0 eth1 tcp 443
web:COUNT - eth1 eth0 tcp - 443
DONE web</programlisting>
<para>Now <quote>shorewall show web</quote> will give you a breakdown of
your web traffic:</para>
<programlisting> [root@gateway shorewall]# shorewall show web
Shorewall-1.4.6-20030821 Chain web at gateway.shorewall.net - Wed Aug 20 09:48:56 PDT 2003
Counters reset Wed Aug 20 09:48:00 PDT 2003
Chain web (4 references)
pkts bytes target prot opt in out source destination
11 1335 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
18 1962 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
29 3297 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#</programlisting>
<para>Here is a slightly different example:</para>
<programlisting> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
web - eth0 eth1 tcp 80
web - eth1 eth0 tcp - 80
web - eth0 eth1 tcp 443
web - eth1 eth0 tcp - 443
COUNT web eth0 eth1
COUNT web eth1 eth0</programlisting>
<para>Now <quote>shorewall show web</quote> simply gives you a breakdown by
input and output:</para>
<programlisting> [root@gateway shorewall]# shorewall show accounting web
Shorewall-1.4.6-20030821 Chains accounting web at gateway.shorewall.net - Wed Aug 20 10:27:21 PDT 2003
Counters reset Wed Aug 20 10:24:33 PDT 2003
Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 web tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
11506 13M web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0
11506 13M all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0
[root@gateway shorewall]#</programlisting>
<para>Here&#39;s how the same example would be constructed on an HTTP server
(READ THAT FOLKS -- IT SAYS <emphasis role="underline">SERVER</emphasis>. If
you want to account for web browsing, you have to reverse the rules below)
with only one interface (eth0):</para>
<programlisting> #ACTION CHAIN SOURCE DESTINATION PROTOCOL DEST SOURCE
# PORT PORT
web - eth0 - tcp 80
web - - eth0 tcp - 80
web - eth0 - tcp 443
web - - eth0 tcp - 443
COUNT web eth0
COUNT web - eth0</programlisting>
<para>Note that with only one interface, only the SOURCE (for input rules)
or the DESTINATION (for output rules) is specified in each rule.</para>
<para>Here&#39;s the output:</para>
<programlisting> [root@mail shorewall]# shorewall show accounting web Shorewall-1.4.7
Chains accounting web at mail.shorewall.net - Sun Oct 12 10:27:21 PDT 2003
Counters reset Sat Oct 11 08:12:57 PDT 2003
Chain accounting (3 references)
pkts bytes target prot opt in out source destination
8767 727K web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
11506 13M web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:80
0 0 web tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 web tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:443
Chain web (4 references)
pkts bytes target prot opt in out source destination
8767 727K all -- eth0 * 0.0.0.0/0 0.0.0.0/0
11506 13M all -- * eth0 0.0.0.0/0 0.0.0.0/0
[root@mail shorewall]#</programlisting>
</article>

542
Shorewall-docs2/CorpNetwork.xml Normal file
View File

@ -0,0 +1,542 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Corporate Network</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
<author>
<firstname>Graeme</firstname>
<surname>Boyle</surname>
</author>
</authorgroup>
<pubdate>2003-11-13</pubdate>
<copyright>
<year>2003 Thomas M. Eastep and Graeme Boyle</year>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>The Network</title>
<note>
<itemizedlist>
<listitem>
<para>This configuration is used on a corporate network that has a
Linux (RedHat 8.0) server with three interfaces, running Shorewall
1.4.5 release,</para>
</listitem>
<listitem>
<para>Make sure you know what public IP addresses are currently
being used and verify these <emphasis>before</emphasis> starting.</para>
</listitem>
<listitem>
<para>Verify your DNS settings <emphasis>before</emphasis> starting
any Shorewall configuration especially if you have split DNS.</para>
</listitem>
<listitem>
<para>System names and Internet IP addresses have been changed to
protect the innocent.</para>
</listitem>
</itemizedlist>
</note>
<warning>
<para>This configuration uses a combination of One-to-one NAT and Proxy
ARP. This is generally not relevant to a simple configuration with a
single public IP address. If you have just a single public IP address,
most of what you see here won&#39;t apply to your setup so beware of
copying parts of this configuration and expecting them to work for you.
What you copy may or may not work in your configuration.</para>
</warning>
<para>I have a T1 with 64 static IP addresses (192.0.18.65-127/26). The
internet is connected to eth0. The local network is connected via eth1
(10.10.0.0/22) and the DMZ is connected to eth2 (192.168.21.0/24). I have
an IPSec tunnel connecting our offices in Germany to our offices in the
US. I host two Microsoft Exchange servers for two different companies
behind the firewall hence, the two Exchange servers in the diagram below.</para>
<section>
<title>Summary</title>
<itemizedlist>
<listitem>
<para>SNAT for all systems connected to the LAN - Internal addresses
10.10.x.x to external address 192.0.18.127.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>Polaris</emphasis> (Exchange
Server #2). Internal address 10.10.1.8 and external address
192.0.18.70.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>Sims</emphasis> (Inventory
Management server). Internal address 10.10.1.56 and external address
192.0.18.75.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>Project</emphasis> (Project Web
Server). Internal address 10.10.1.55 and external address
192.0.18.84.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>Fortress</emphasis> (Exchange
Server). Internal address 10.10.1.252 and external address
192.0.18.93.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>BBSRV</emphasis> (Blackberry
Server). Internal address 10.10.1.230 and external address
192.0.18.97.</para>
</listitem>
<listitem>
<para>One-to-one NAT for <emphasis>Intweb</emphasis> (Intranet Web
Server). Internal address 10.10.1.60 and external address
192.0.18.115.</para>
</listitem>
</itemizedlist>
<para>The firewall runs on a 2Gb, Dual PIV/2.8GHz, Intel motherboard
with RH8.0.</para>
<para>The Firewall is also a proxy server running Privoxy 3.0.</para>
<para>The single system in the DMZ (address 192.0.18.80) runs sendmail,
imap, pop3, DNS, a Web server (Apache) and an FTP server (vsFTPd 1.1.0).
That server is managed through Proxy ARP.</para>
<para>All administration and publishing is done using ssh/scp. I have X
installed on the firewall and the system in the DMZ. X applications
tunnel through SSH to Hummingbird Exceed running on a PC located in the
LAN. Access to the firewall using SSH is restricted to systems in the
LAN, DMZ or the system Kaos which is on the Internet and managed by me.</para>
<graphic fileref="images/CorpNetwork.gif" />
<para>The Ethernet 0 interface in the Server is configured with IP
address 192.0.18.68, netmask 255.255.255.192. The server&#39;s default
gateway is 192.0.18.65, the Router connected to my network and the ISP.
This is the same default gateway used by the firewall itself. On the
firewall, Shorewall automatically adds a host route to 192.0.18.80
through Ethernet 2 (192.168.21.1) because of the entry in
/etc/shorewall/proxyarp (see below). I modified the start, stop and init
scripts to include the fixes suggested when having an IPSec tunnel.</para>
</section>
<section>
<title>Some Mistakes I Made</title>
<para>Yes, believe it or not, I made some really basic mistakes when
building this firewall. Firstly, I had the new firewall setup in
parallel with the old firewall so that there was no interruption of
service to my users. During my out-bound testing, I set up systems on
the LAN to utilize the firewall which worked fine. When testing my NAT
connections, from the outside, these would fail and I could not
understand why. Eventually, I changed the default route on the internal
system I was trying to access, to point to the new firewall and
<quote>bingo</quote>, everything worked as expected. This oversight
delayed my deployment by a couple of days not to mention level of
frustration it produced.</para>
<para>Another problem that I encountered was in setting up the Proxyarp
system in the DMZ. Initially I forgot to remove the entry for the eth2
from the /etc/shorewall/masq file. Once my file settings were correct, I
started verifying that the ARP caches on the firewall, as well as the
outside system <quote>kaos</quote>, were showing the correct Ethernet
MAC address. However, in testing remote access, I could access the
system in the DMZ only from the firewall and LAN but not from the
Internet. The message I received was <quote>connection denied</quote> on
all protocols. What I did not realize was that a <quote>helpful</quote>
administrator that had turned on an old system and assigned the same
address as the one I was using for Proxyarp without notifying me. How
did I work this out. I shutdown the system in the DMZ, rebooted the
router and flushed the ARP cache on the firewall and kaos. Then, from
kaos, I started pinging that IP address and checked the updated ARP
cache and lo-and-behold a different MAC address showed up. High levels
of frustration etc., etc. The administrator will not be doing that
again! :-)</para>
</section>
<section>
<title>Lessons Learned</title>
<itemizedlist>
<listitem>
<para>Read the documentation.</para>
</listitem>
<listitem>
<para>Draw your network topology before starting.</para>
</listitem>
<listitem>
<para>Understand what services you are going to allow in and out of
the firewall, whether they are TCP or UDP packets and make a note of
these port numbers.</para>
</listitem>
<listitem>
<para>Try to get quiet time to build the firewall - you need to
focus on the job at hand.</para>
</listitem>
<listitem>
<para>When asking for assistance, be honest and include as much
detail as requested. Don&#39;t try and hide IP addresses etc., you
will probably screw up the logs and make receiving assistance
harder.</para>
</listitem>
<listitem>
<para>Read the documentation.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Futures</title>
<para>This is by no means the final configuration. In the near future, I
will be moving more systems from the LAN to the DMZ. I will also be
watching the logs for port scan programs etc. but, this should be
standard security maintenance.</para>
</section>
</section>
<section>
<title>Configuation Files</title>
<para>Here are copies of my files. I have removed most of the internal
documentation for the purpose of this space however, my system still has
the original files with all the comments and I highly recommend you do the
same.</para>
<section>
<title>Shorewall.conf</title>
<programlisting>##############################################################################
# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# L O G G I N G
##############################################################################
LOGFILE=/var/log/messages
LOGFORMAT=<quote>Shorewall:%s:%s:</quote>
LOGRATE=
LOGBURST=
LOGUNCLEAN=info
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=
MACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=debug
RFC1918_LOG_LEVEL=debug
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SUBSYSLOCK=/var/lock/subsys/shorewall
STATEDIR=/var/lib/shorewall
MODULESDIR=
FW=fw
NAT_ENABLED=Yes
MANGLE_ENABLED=Yes
IP_FORWARDING=On
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=Yes
TC_ENABLED=Yes
CLEAR_TC=No
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=No
ROUTE_FILTER=Yes
NAT_BEFORE_RULES=No
MULTIPORT=Yes
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Zones File</title>
<programlisting>#
# Shorewall 1.4 -- Sample Zone File For Two Interfaces
# /etc/shorewall/zones
#
# This file determines your network zones. Columns are:
#
# ZONE Short name of the zone
# DISPLAY Display name of the zone
# COMMENTS Comments about the zone
#
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local Networks
dmz DMZ Demilitarized Zone
vpn1 VPN1 VPN to Germany
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Interfaces File</title>
<programlisting>##############################################################################
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 62.123.106.127 routefilter,norfc1918,blacklist,tcpflags
loc eth1 detect dhcp,routefilter
dmz eth2 detect
vpn1 ipsec0
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
</programlisting>
</section>
<section>
<title>Routestopped File</title>
<programlisting>#INTERFACE HOST(S)
eth1 -
eth2 -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Policy File</title>
<programlisting>###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
loc fw ACCEPT
loc dmz ACCEPT
# If you want open access to the Internet from your Firewall
# remove the comment from the following line.
fw net ACCEPT
fw loc ACCEPT
fw dmz ACCEPT
dmz fw ACCEPT
dmz loc ACCEPT
dmz net ACCEPT
#
# Adding VPN Access
loc vpn1 ACCEPT
dmz vpn1 ACCEPT
fw vpn1 ACCEPT
vpn1 loc ACCEPT
vpn1 dmz ACCEPT
vpn1 fw ACCEPT
#
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Masq File</title>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0 eth1 1192.0.18.126
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>NAT File</title>
<programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
#
# Intranet Web Server
192.0.18.115 eth0:0 10.10.1.60 No No
#
# Project Web Server
192.0.18.84 eth0:1 10.10.1.55 No No
#
# Blackberry Server
192.0.18.97 eth0:2 10.10.1.55 No No
#
# Corporate Mail Server
192.0.18.93 eth0:3 10.10.1.252 No No
#
# Second Corp Mail Server
192.0.18.70 eth0:4 10.10.1.8 No No
#
# Sims Server
192.0.18.75 eth0:5 10.10.1.56 No No
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Proxy ARP File</title>
<programlisting>#ADDRESS INTERFACE EXTERNAL HAVEROUTE
#
# The Corporate email server in the DMZ
192.0.18.80 eth2 eth0 No
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Tunnels File</title>
<programlisting># TYPE ZONE GATEWAY GATEWAY ZONE PORT
ipsec net 134.147.129.82
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Rules File (The shell variables are set in /etc/shorewall/params)</title>
<programlisting>##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Accept DNS connections from the firewall to the network
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
# Accept SSH from internet interface from kaos only
#
ACCEPT net:192.0.18.98 fw tcp 22
#
# Accept connections from the local network for administration
#
ACCEPT loc fw tcp 20:22
ACCEPT loc net tcp 22
ACCEPT loc fw tcp 53
ACCEPT loc fw udp 53
ACCEPT loc net tcp 53
ACCEPT loc net udp 53
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT loc dmz icmp 8
ACCEPT loc net icmp 8
ACCEPT dmz fw icmp 8
ACCEPT dmz loc icmp 8
ACCEPT dmz net icmp 8
DROP net fw icmp 8
DROP net loc icmp 8
DROP net dmz icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw dmz icmp 8
DROP fw net icmp 8
#
# Accept proxy web connections from the inside
#
ACCEPT loc fw tcp 8118
#
# Forward PcAnywhere, Oracle and Web traffic from outside to the Demo systems
# From a specific IP Address on the Internet.
#
# ACCEPT net:207.65.110.10 loc:10.10.3.151 tcp 1521,http
# ACCEPT net:207.65.110.10 loc:10.10.2.32 tcp 5631:5632
#
# Intranet web server
ACCEPT net loc:10.10.1.60 tcp 443
ACCEPT dmz loc:10.10.1.60 tcp 443
#
# Projects web server
ACCEPT net loc:10.10.1.55 tcp 80
ACCEPT dmz loc:10.10.1.55 tcp 80
#
# Blackberry Server
ACCEPT net loc:10.10.1.230 tcp 3101
#
# Corporate Email Server
ACCEPT net loc:10.10.1.252 tcp 25,53,110,143,443
#
# Corporate #2 Email Server
ACCEPT net loc:10.10.1.8 tcp 25,80,110,443
#
# Sims Server
ACCEPT net loc:10.10.1.56 tcp 80,443
ACCEPT net loc:10.10.1.56 tcp 7001:7002
ACCEPT net:63.83.198.0/24 loc:10.10.1.56 tcp 5631:5632
#
# Access to DMZ
ACCEPT loc dmz udp 53,177
ACCEPT loc dmz tcp 80,25,53,22,143,443,993,20,110 -
ACCEPT net dmz udp 53
ACCEPT net dmz tcp 25,53,22,21,123
ACCEPT dmz net tcp 25,53,80,123,443,21,22
ACCEPT dmz net udp 53
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</programlisting>
</section>
<section>
<title>Start File</title>
<programlisting>############################################################################
# Shorewall 1.4 -- /etc/shorewall/start
#
# Add commands below that you want to be executed after shorewall has
# been started or restarted.
#
qt service ipsec start</programlisting>
</section>
<section>
<title>Stop File</title>
<programlisting>############################################################################
# Shorewall 1.4 -- /etc/shorewall/stop
#
# Add commands below that you want to be executed at the beginning of a
# <quote>shorewall stop</quote> command.
#
qt service ipsec stop</programlisting>
</section>
<section>
<title>Init File</title>
<programlisting>############################################################################
# Shorewall 1.4 -- /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a <quote>shorewall start</quote> or <quote>shorewall restart</quote> command.
#
qt service ipsec stop</programlisting>
</section>
</section>
</article>

928
Shorewall-docs2/Documentation.html Normal file
View File

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

2986
Shorewall-docs2/Documentation.xml Normal file
View File

File diff suppressed because it is too large Load Diff

384
Shorewall-docs2/Documentation_Index.xml Normal file
View File

@ -0,0 +1,384 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Shorewall Documentation</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-04</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<edition>2.0.0-Beta1</edition>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<caution>
<para>Are you running Shorewall on <ulink
url="http://www.mandrakesoft.com"><trademark>Mandrake</trademark> Linux</ulink>
with a two-interface setup?</para>
<para>If so, this documentation will not apply directly to your
environment. If you want to use the documentation that you find here, you
will want to consider uninstalling what you have and installing a
configuration that matches this documentation. See the <ulink
url="two-interface.htm">Two-interface QuickStart Guide</ulink> for
details.</para>
</caution>
<itemizedlist>
<listitem>
<para><ulink url="Introduction.html">Introduction to Shorewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_quickstart_guide.htm">QuickStart Guides
(HOWTOS)</ulink></para>
</listitem>
</itemizedlist>
<para>The remainder of the Documentation supplements the QuickStart Guides.
Please review the appropriate guide before trying to use this documentation
directly.</para>
<itemizedlist>
<listitem>
<para><ulink url="Accounting.html">Accounting</ulink></para>
</listitem>
<listitem>
<para><ulink url="Shorewall_and_Aliased_Interfaces.html">Aliased
(virtual) Interfaces (e.g., eth0:0)</ulink></para>
</listitem>
<listitem>
<para><ulink url="traffic_shaping.htm">Bandwidth Control</ulink></para>
</listitem>
<listitem>
<para><ulink url="blacklisting_support.htm">Blacklisting</ulink></para>
<itemizedlist>
<listitem>
<para>Static Blacklisting using /etc/shorewall/blacklist</para>
</listitem>
<listitem>
<para>Dynamic Blacklisting using /sbin/shorewall</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><ulink url="starting_and_stopping_shorewall.htm">Commands</ulink>
(Description of all /sbin/shorewall commands)</para>
</listitem>
<listitem>
<para><ulink url="configuration_file_basics.htm">Common configuration
file features&#x00A0;</ulink><itemizedlist><listitem><para><ulink
url="configuration_file_basics.htm#Comments">Comments in configuration
files</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Continuation">Line Continuation</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#INCLUDE">INCLUDE Directive</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Ports">Port Numbers/Service Names</ulink>configuration_file_basics.htm#Ports</para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Ranges">Port Ranges</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Variables">Using Shell Variables</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#dnsnames">Using DNS Names</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Compliment">Complementing an IP
address or Subnet</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#Levels">Shorewall Configurations
(making a test configuration)</ulink></para></listitem><listitem><para><ulink
url="configuration_file_basics.htm#MAC">Using MAC Addresses in Shorewall</ulink></para></listitem></itemizedlist></para>
</listitem>
<listitem>
<para><ulink url="Documentation.htm">Configuration File Reference Manual
</ulink><itemizedlist><listitem><para><ulink
url="Documentation.htm#Variables">params</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Zones">zones</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Interfaces">interfaces</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Hosts">hosts</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Policy">policy</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Rules">rules</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Common">common</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Masq">masq</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#ProxyArp">proxyarp</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#NAT">nat</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Tunnels">tunnels</ulink></para></listitem><listitem><para><ulink
url="traffic_shaping.htm#tcrules">tcrules</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Conf">shorewall.conf</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#modules">modules</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#TOS">tos</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Blacklist">blacklist</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#rfc1918">rfc1918</ulink></para></listitem><listitem><para><ulink
url="Documentation.htm#Routestopped">routestopped</ulink></para></listitem><listitem><para><ulink
url="Accounting.html">accounting</ulink></para></listitem><listitem><para><ulink
url="UserSets.html">usersets and users</ulink></para></listitem><listitem><para><ulink
url="MAC_Validation.html">maclist</ulink></para></listitem><listitem><para><ulink
url="User_defined_Actions.html">actions and action.template</ulink></para></listitem></itemizedlist></para>
</listitem>
<listitem>
<para><ulink url="CorpNetwork.htm">Corporate Network Example</ulink>
(Contributed by a Graeme Boyle)</para>
</listitem>
<listitem>
<para><ulink url="dhcp.htm">DHCP</ulink></para>
</listitem>
<listitem>
<para><ulink url="ECN.html">ECN Disabling by host or subnet</ulink></para>
</listitem>
<listitem>
<para><ulink url="errata.htm">Errata</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_extension_scripts.htm">Extension Scripts</ulink>
(How to extend Shorewall without modifying Shorewall code through the
use of files in /etc/shorewall -- /etc/shorewall/start,
/etc/shorewall/stopped, etc.)</para>
</listitem>
<listitem>
<para><ulink url="fallback.htm">Fallback/Uninstall</ulink></para>
</listitem>
<listitem>
<para><ulink url="FAQ.htm">FAQs</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_features.htm">Features</ulink></para>
</listitem>
<listitem>
<para><ulink url="Multiple_Zones.html">Forwarding Traffic on the Same
Interface</ulink></para>
</listitem>
<listitem>
<para><ulink url="FTP.html">FTP and Shorewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="support.htm">Getting help or answers to questions</ulink></para>
</listitem>
<listitem>
<para><ulink url="Install.htm">Installation/Upgrade</ulink></para>
</listitem>
<listitem>
<para><ulink url="IPSEC.htm">IPSEC</ulink></para>
</listitem>
<listitem>
<para><ulink url="Shorewall_and_Kazaa.html">Kazaa Filtering</ulink></para>
</listitem>
<listitem>
<para><ulink url="kernel.htm">Kernel Configuration</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_logging.html">Logging</ulink></para>
</listitem>
<listitem>
<para><ulink url="MAC_Validation.html">MAC Verification</ulink></para>
</listitem>
<listitem>
<para><ulink url="Multiple_Zones.html">Multiple Zones Through One
Interface</ulink></para>
</listitem>
<listitem>
<para><ulink url="myfiles.htm">My Shorewall Configuration</ulink> (How I
personally use Shorewall)</para>
</listitem>
<listitem>
<para><ulink url="NetfilterOverview.html">Netfilter Overview</ulink></para>
</listitem>
<listitem>
<para><ulink url="NAT.htm">One-to-one NAT</ulink> (Formerly referred to
as Static NAT)</para>
</listitem>
<listitem>
<para><ulink url="OPENVPN.html">OpenVPN</ulink></para>
</listitem>
<listitem>
<para><ulink url="starting_and_stopping_shorewall.htm">Operating
Shorewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="ping.html">&#39;Ping&#39; Management</ulink></para>
</listitem>
<listitem>
<para><ulink url="ports.htm">Port Information</ulink></para>
<itemizedlist>
<listitem>
<para>Which applications use which ports</para>
</listitem>
<listitem>
<para>Ports used by Trojans</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><ulink url="PPTP.htm">PPTP</ulink></para>
</listitem>
<listitem>
<para><ulink url="ProxyARP.htm">Proxy ARP</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_prerequisites.htm">Requirements</ulink></para>
</listitem>
<listitem>
<para><ulink url="Multiple_Zones.html">Routing on One Interface</ulink></para>
</listitem>
<listitem>
<para><ulink url="samba.htm">Samba</ulink></para>
</listitem>
<listitem>
<para><ulink url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink><itemizedlist><listitem><para><ulink
url="shorewall_setup_guide.htm#Introduction">Introduction</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Concepts">Shorewall Concepts</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Interfaces">Network Interfaces</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Addressing">Addressing, Subnets and
Routing</ulink></para><itemizedlist><listitem><para><ulink
url="shorewall_setup_guide.htm#Addresses">IP Addresses</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Subnets">Subnets</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Routing">Routing</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#ARP">Address Resolution Protocol (ARP)</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#RFC1918">RFC 1918</ulink></para></listitem></itemizedlist></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Options">Setting up your Network</ulink></para><itemizedlist><listitem><para><ulink
url="shorewall_setup_guide.htm#Routed">Routed</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#NonRouted">Non-routed</ulink></para><itemizedlist><listitem><para><ulink
url="shorewall_setup_guide.htm#SNAT">SNAT</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#DNAT">DNAT</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#ProxyARP">Proxy ARP</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#NAT">One-to-one NAT</ulink></para></listitem></itemizedlist></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#Rules">Rules</ulink></para></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#OddsAndEnds">Odds and Ends</ulink></para></listitem></itemizedlist></listitem><listitem><para><ulink
url="shorewall_setup_guide.htm#DNS">DNS</ulink></para></listitem><listitem><para><ulink
url="starting_and_stopping_shorewall.htm">Starting and Stopping the
Firewall</ulink></para></listitem></itemizedlist></para>
</listitem>
<listitem>
<para><ulink url="starting_and_stopping_shorewall.htm">Starting/stopping
the Firewall</ulink><itemizedlist><listitem><para>Description of all
/sbin/shorewall commands</para></listitem><listitem><para>How to safely
test a Shorewall configuration change</para></listitem></itemizedlist></para>
</listitem>
<listitem>
<para><ulink url="Shorewall_Squid_Usage.html">Squid with Shorewall</ulink></para>
</listitem>
<listitem>
<para><ulink url="Accounting.html">Traffic Accounting</ulink></para>
</listitem>
<listitem>
<para><ulink url="traffic_shaping.htm">Traffic Shaping/QOS</ulink></para>
</listitem>
<listitem>
<para><ulink url="troubleshoot.htm">Troubleshooting</ulink> (Things to
try if it doesn&#39;t work)</para>
</listitem>
<listitem>
<para><ulink url="User_defined_Actions.html">User-defined Actions</ulink></para>
</listitem>
<listitem>
<para><ulink url="UserSets.html">UID/GID Based Rules</ulink></para>
</listitem>
<listitem>
<para><ulink url="upgrade_issues.htm">Upgrade Issues</ulink></para>
</listitem>
<listitem>
<para>VPN</para>
<itemizedlist>
<listitem>
<para><ulink url="IPSEC.htm">IPSEC</ulink></para>
</listitem>
<listitem>
<para><ulink url="IPIP.htm">GRE and IPIP</ulink></para>
</listitem>
<listitem>
<para><ulink url="OPENVPN.html">OpenVPN</ulink></para>
</listitem>
<listitem>
<para><ulink url="PPTP.htm">PPTP</ulink></para>
</listitem>
<listitem>
<para><ulink url="6to4.htm">6to4</ulink></para>
</listitem>
<listitem>
<para><ulink url="VPN.htm">IPSEC/PPTP passthrough from a system
behind your firewall to a remote network</ulink></para>
</listitem>
<listitem>
<para><ulink url="GenericTunnels.html">Other VPN types</ulink></para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para><ulink url="whitelisting_under_shorewall.htm">White List Creation</ulink></para>
</listitem>
</itemizedlist>
</article>

92
Shorewall-docs2/ECN.xml Normal file
View File

@ -0,0 +1,92 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="ECN">
<!--$Id$-->
<articleinfo>
<title>ECN</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-03-28</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Explicit Congestion Notification (ECN)</title>
<para>Explicit Congestion Notification (ECN) is described in RFC 3168 and
is a proposed internet standard. Unfortunately, not all sites support ECN
and when a TCP connection offering ECN is sent to sites that don&#39;t
support it, the result is often that the connection request is ignored.</para>
<para>To allow ECN to be used, Shorewall allows you to enable ECN on your
Linux systems then disable it in your firewall when the destination
matches a list that you create (the /etc/shorewall/ecn file).</para>
<para>You enable ECN by</para>
<programlisting>echo 1 &#62; /proc/sys/net/ipv4/tcp_ecn</programlisting>
<para>You must arrange for that command to be executed at system boot.
Most distributions have a method for doing that -- on RedHat, you make an
entry in /etc/sysctl.conf.</para>
<programlisting>net.ipv4.tcp_ecn = 1</programlisting>
<para>Entries in /etc/shorewall/ecn have two columns as follows:</para>
<variablelist>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>The name of an interface on your system</para>
</listitem>
</varlistentry>
<varlistentry>
<term>HOST(S)</term>
<listitem>
<para>An address (host or subnet) of a system or group of systems
accessed through the interface in the first column. You may include
a comma-separated list of such addresses in this column.</para>
</listitem>
</varlistentry>
</variablelist>
<example>
<title>Your external interface is eth0 and you want to disable ECN for
tcp connections to 192.0.2.0/24:</title>
<para><table><title>/etc/shorewall/ecn</title><tgroup cols="2"><thead><row><entry
align="center">INTERFACE</entry><entry align="center">HOST(S)</entry></row></thead><tbody><row><entry>eth0</entry><entry>192.0.2.0/24</entry></row></tbody></tgroup></table></para>
</example>
</section>
</article>

640
Shorewall-docs2/FAQ.html Normal file
View File

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

1622
Shorewall-docs2/FAQ.xml Normal file
View File

File diff suppressed because it is too large Load Diff

349
Shorewall-docs2/FTP.xml Normal file
View File

@ -0,0 +1,349 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="FTP">
<!--$Id$-->
<articleinfo>
<title>Shorewall and FTP</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-12-01</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<important>
<para>If you are running Mandrake 9.1 or 9.2 and are having problems with
FTP, you have three choices:</para>
<orderedlist>
<listitem>
<para>Edit /usr/share/shorewall/firewall and replace this line:</para>
<programlisting>for suffix in o gz ko ; do</programlisting>
<para>with</para>
<programlisting>for suffix in o gz ko o.gz ; do</programlisting>
<para>and at a root shell prompt:</para>
<programlisting><command>shorewall restart</command></programlisting>
</listitem>
<listitem>
<para>Install the Mandrake <quote>cooker</quote> version of Shorewall.</para>
</listitem>
<listitem>
<para>Upgrade to Shorewall 1.4.7 or later.</para>
</listitem>
</orderedlist>
</important>
<section>
<title>FTP Protocol</title>
<para>FTP transfers involve two TCP connections. The first <emphasis
role="bold">control</emphasis> connection goes from the FTP client to port
21 on the FTP server. This connection is used for logon and to send
commands and responses between the endpoints. Data transfers (including
the output of <quote>ls</quote> and <quote>dir</quote> commands) requires
a second data connection. The <emphasis role="bold">data</emphasis>
connection is dependent on the <emphasis role="bold">mode</emphasis> that
the client is operating in:</para>
<variablelist>
<varlistentry>
<term>Passive Mode</term>
<listitem>
<para>(often the default for web browsers) -- The client issues a
PASV command. Upon receipt of this command, the server listens on a
dynamically-allocated port then sends a PASV reply to the client.
The PASV reply gives the IP address and port number that the server
is listening on. The client then opens a second connection to that
IP address and port number.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Active Mode</term>
<listitem>
<para>(often the default for line-mode clients) -- The client
listens on a dynamically-allocated port then sends a PORT command to
the server. The PORT command gives the IP address and port number
that the client is listening on. The server then opens a connection
to that IP address and port number; the <emphasis role="bold">source
port</emphasis> for this connection is 20 (ftp-data in
/etc/services).</para>
</listitem>
</varlistentry>
</variablelist>
<para>You can see these commands in action using your linux ftp
command-line client in debugging mode. Note that my ftp client defaults to
passive mode and that I can toggle between passive and active mode by
issuing a <quote>passive</quote> command:</para>
<programlisting>[teastep@wookie Shorewall]$ <emphasis role="bold">ftp ftp1.shorewall.net</emphasis>
Connected to lists.shorewall.net.
220-=(&#60;*&#62;)=-.:. (( Welcome to PureFTPd 1.0.12 )) .:.-=(&#60;*&#62;)=-
220-You are user number 1 of 50 allowed.
220-Local time is now 10:21 and the load is 0.14. Server port: 21.
220 You will be disconnected after 15 minutes of inactivity.
500 Security extensions not implemented
500 Security extensions not implemented
KERBEROS_V4 rejected as an authentication type
Name (ftp1.shorewall.net:teastep): ftp
331-Welcome to ftp.shorewall.net
331-
331 Any password will work
Password:
230 Any password will work
Remote system type is UNIX.
Using binary mode to transfer files.
ftp&#62; <emphasis role="bold">debug</emphasis>
Debugging on (debug=1).
ftp&#62; <emphasis role="bold">ls</emphasis>
---&#62; <emphasis>PASV</emphasis>
<emphasis>227 Entering Passive Mode (192,168,1,193,195,210)</emphasis>
---&#62; LIST
150 Accepted data connection
drwxr-xr-x 5 0 0 4096 Nov 9 2002 archives
drwxr-xr-x 2 0 0 4096 Feb 12 2002 etc
drwxr-sr-x 6 0 50 4096 Feb 19 15:24 pub
226-Options: -l
226 3 matches total
ftp&#62; <emphasis role="bold">passive</emphasis>
Passive mode off.
ftp&#62; <emphasis role="bold">ls</emphasis>
<emphasis>---&#62; PORT 192,168,1,3,142,58</emphasis>
200 PORT command successful
---&#62; LIST
150 Connecting to port 36410
drwxr-xr-x 5 0 0 4096 Nov 9 2002 archives
drwxr-xr-x 2 0 0 4096 Feb 12 2002 etc
drwxr-sr-x 6 0 50 4096 Feb 19 15:24 pub
226-Options: -l
226 3 matches total
ftp&#62;</programlisting>
<para>Things to notice:</para>
<orderedlist>
<listitem>
<para>The commands that I issued are <emphasis role="bold">strongly
emphasized</emphasis>.</para>
</listitem>
<listitem>
<para>Commands sent by the client to the server are preceded by
---&#62;</para>
</listitem>
<listitem>
<para>Command responses from the server over the control connection
are numbered.</para>
</listitem>
<listitem>
<para>FTP uses a comma as a separator between the bytes of the IP
address; and</para>
</listitem>
<listitem>
<para>When sending a port number, FTP sends the MSB then the LSB and
separates the two bytes by a comma. As shown in the PORT command, port
142,58 translates to 142*256+58 = 36410.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Linux FTP connection-tracking</title>
<para>Given the normal loc-&#62;net policy of ACCEPT, passive mode access
from local clients to remote servers will always work but active mode
requires the firewall to dynamically open a <quote>hole</quote> for the
server&#39;s connection back to the client. Similarly, if you are running
an FTP server in your local zone then active mode should always work but
passive mode requires the firewall to dynamically open a <quote>hole</quote>
for the client&#39;s second connection to the server. This is the role of
FTP connection-tracking support in the Linux kernel.</para>
<para>Where any form of NAT (SNAT, DNAT, Masquerading) on your firewall is
involved, the PORT commands and PASV responses may also need to be
modified by the firewall. This is the job of the FTP nat support kernel
function.</para>
<para>Including FTP connection-tracking and NAT support normally means
that the modules <quote>ip_conntrack_ftp</quote> and <quote>ip_nat_ftp</quote>
need to be loaded. Shorewall automatically loads these <quote>helper</quote>
modules from /lib/modules/&#60;<emphasis>kernel-version</emphasis>&#62;/kernel/net/ipv4/netfilter/
and you can determine if they are loaded using the <quote>lsmod</quote>
command. The &#60;<emphasis>kernel-version</emphasis>&#62; may be obtained
by typing</para>
<programlisting><command>uname -r</command></programlisting>
<example>
<title></title>
<programlisting>[root@lists etc]# lsmod
Module Size Used by Not tainted
autofs 12148 0 (autoclean) (unused)
ipt_TOS 1560 12 (autoclean)
ipt_LOG 4120 5 (autoclean)
ipt_REDIRECT 1304 1 (autoclean)
ipt_REJECT 3736 4 (autoclean)
ipt_state 1048 13 (autoclean)
ip_nat_irc 3152 0 (unused)
<emphasis role="bold">ip_nat_ftp 3888 0 (unused)</emphasis>
ip_conntrack_irc 3984 1
<emphasis role="bold">ip_conntrack_ftp 5008 1</emphasis>
ipt_multiport 1144 2 (autoclean)
ipt_conntrack 1592 0 (autoclean)
iptable_filter 2316 1 (autoclean)
iptable_mangle 2680 1 (autoclean)
iptable_nat 20568 3 (autoclean) [ipt_REDIRECT ip_nat_irc ip_nat_ftp]
ip_conntrack 26088 5 (autoclean) [ipt_REDIRECT ipt_state ip_nat_irc
ip_nat_ftp ip_conntrack_irc ip_conntrack_ftp
ipt_conntrack iptable_nat]
ip_tables 14488 12 [ipt_TOS ipt_LOG ipt_REDIRECT ipt_REJECT ipt_state
ipt_multiport ipt_conntrack iptable_filter
iptable_mangle iptable_nat]
tulip 42464 0 (unused)
e100 50596 1
keybdev 2752 0 (unused)
mousedev 5236 0 (unused)
hid 20868 0 (unused)
input 5632 0 [keybdev mousedev hid]
usb-uhci 24684 0 (unused)
usbcore 73280 1 [hid usb-uhci]
ext3 64704 2
jbd 47860 2 [ext3]
[root@lists etc]#</programlisting>
</example>
<para>If you want Shorewall to load these modules from an alternate
directory, you need to set the MODULESDIR variable in
/etc/shorewall/shorewall.conf to point to that directory.</para>
<para>If your FTP helper modules are compressed and have the names
<emphasis>ip_nat_ftp.o.gz and ip_conntrack_ftp.o.gz</emphasis> then you
will need Shorewall 1.4.7 or later if you want Shorewall to load them for
you.</para>
<para>Server configuration is covered in the <ulink type=""
url="Documentation.htm#Rules">/etc/shorewall/rules documentation</ulink>,</para>
<para>For a client, you must open outbound TCP port 21.</para>
<para>The above discussion about commands and responses makes it clear
that the FTP connection-tracking and NAT helpers must scan the traffic on
the control connection looking for PASV and PORT commands as well as PASV
responses. If you run an FTP server on a nonstandard port or you need to
access such a server, you must therefore let the helpers know by
specifying the port in /etc/shorewall/modules entries for the helpers. For
example, if you run an FTP server that listens on port 49 or you need to
access a server on the internet that listens on that port then you would
have:</para>
<example>
<title>if you run an FTP server that listens on port 49 or you need to
access a server on the internet that listens on that port then you would
have:</title>
<programlisting>loadmodule ip_conntrack_ftp ports=21,49
loadmodule ip_nat_ftp ports=21,49</programlisting>
<para><note><para>you MUST include port 21 in the ports list or you may
have problems accessing regular FTP servers.</para></note></para>
<para>If there is a possibility that these modules might be loaded
before Shorewall starts, then you should include the port list in
/etc/modules.conf:</para>
<programlisting>options ip_conntrack_ftp ports=21,49
options ip_nat_ftp ports=21,49</programlisting>
<para><important><para>Once you have made these changes to
/etc/shorewall/modules and/or /etc/modules.conf, you must either:</para><orderedlist><listitem><para>Unload
the modules and restart shorewall:</para><programlisting><command>rmmod ip_nat_ftp; rmmod ip_conntrack_ftp; shorewall restart</command></programlisting></listitem><listitem><para>Reboot</para></listitem></orderedlist></important></para>
</example>
<para>One problem that I see occasionally involves active mode and the FTP
server in my DMZ. I see the active data connection to <emphasis
role="bold">certain client IP addresses</emphasis> being continuously
rejected by my firewall. It is my conjecture that there is some broken
client out there that is sending a PORT command that is being either
missed or mis-interpreted by the FTP connection tracking helper yet it is
being accepted by my FTP server. My solution is to add the following rule:</para>
<informaltable>
<tgroup cols="7">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DESTINATION</entry>
<entry align="center">PROTOCOL</entry>
<entry align="center">PORT(S)</entry>
<entry align="center">SOURCE PORT(S)</entry>
<entry align="center">ORIGINAL DESTINATION</entry>
</row>
</thead>
<tbody>
<row>
<entry>ACCEPT:info</entry>
<entry>dmz</entry>
<entry>net</entry>
<entry>tcp</entry>
<entry>-</entry>
<entry>20</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>The above rule accepts and logs all active mode connections from my
DMZ to the net.</para>
</section>
</article>

292
Shorewall-docs2/GenericTunnels.xml Normal file
View File

@ -0,0 +1,292 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="GenericTunnels">
<!--$Id$-->
<articleinfo>
<title>Generic Tunnels</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-08-09</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>Shorewall includes built-in support for a wide range of VPN solutions.
If you have need for a tunnel type that does not have explicit support, you
can generally describe the tunneling software using <quote>generic tunnels</quote>.</para>
<section>
<title>Bridging two Masqueraded Networks</title>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is
accomplished through use of the /etc/shorewall/tunnels file, the
/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
included with Shorewall.</para>
<para>Suppose that you have tunneling software that uses two different
protocols:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>TCP port 1071</para>
</listitem>
<listitem>
<para>GRE (Protocol 47)</para>
</listitem>
<listitem>
<para>The tunnel interface on system A is <quote>tun0</quote> and the
tunnel interface on system B is also <quote>tun0</quote>.</para>
</listitem>
</orderedlist>
<para>On each firewall, you will need to declare a zone to represent the
remote subnet. We&#39;ll assume that this zone is called <quote>vpn</quote>
and declare it in /etc/shorewall/zones on both systems as follows.</para>
<informaltable>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>VPN</entry>
<entry>Remote Subnet</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>On system A, the 10.0.0.0/8 will comprise the <emphasis role="bold">vpn</emphasis>
zone. In /etc/shorewall/interfaces:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tun0</entry>
<entry>10.255.255.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>In /etc/shorewall/tunnels on system A, we need the following:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>generic:tcp:1071</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
<row>
<entry>generic:47</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>These entries in /etc/shorewall/tunnels, opens the firewall so that
TCP port 1071 and the Generalized Routing Encapsulation Protocol (47) will
be accepted to/from the remote gateway.</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tun0</entry>
<entry>192.168.1.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>In /etc/shorewall/tunnels on system B, we have:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>generic:tcp:1071</entry>
<entry>net</entry>
<entry>206.191.148.9</entry>
<entry></entry>
</row>
<row>
<entry>generic:47</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>You will need to allow traffic between the <quote>vpn</quote> zone
and the <quote>loc</quote> zone on both systems -- if you simply want to
admit all traffic in both directions, you can use the policy file:</para>
<informaltable>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>vpn</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>On both systems, restart Shorewall and start your VPN software on
each system. The systems in the two masqueraded subnetworks can now talk
to each other</para>
</section>
</article>

434
Shorewall-docs2/GnuCopyright.xml Normal file
View File

@ -0,0 +1,434 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<appendix id="gfdl">
<title>GNU Free Documentation License</title>
<subtitle>Version 1.2, November 2002</subtitle>
<blockquote id="fsf-copyright">
<para>Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.</para>
</blockquote>
<section id="gfdl-0"><title>PREAMBLE</title>
<para>The purpose of this License is to make a manual, textbook, or
other functional and useful document "free" in the sense of freedom: to
assure everyone the effective freedom to copy and redistribute it, with
or without modifying it, either commercially or noncommercially.
Secondarily, this License preserves for the author and publisher a way
to get credit for their work, while not being considered responsible for
modifications made by others.</para>
<para>This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft license
designed for free software.</para>
<para>We have designed this License in order to use it for manuals for
free software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals; it
can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.</para>
</section>
<section id="gfdl-1"><title>APPLICABILITY AND DEFINITIONS</title>
<para id="gfdl-doc">This License applies to any manual or other work, in
any medium, that contains a notice placed by the copyright holder saying
it can be distributed under the terms of this License. Such a notice
grants a world-wide, royalty-free license, unlimited in duration, to use
that work under the conditions stated herein. The "Document", below,
refers to any such manual or work. Any member of the public is a
licensee, and is addressed as "you". You accept the license if you
copy, modify or distribute the work in a way requiring permission under
copyright law.</para>
<para id="gfdl-mod-ver">A "Modified Version" of the Document means any
work containing the Document or a portion of it, either copied verbatim,
or with modifications and/or translated into another language.</para>
<para id="gfdl-secnd-sect">A "Secondary Section" is a named appendix or
a front-matter section of the Document that deals exclusively with the
relationship of the publishers or authors of the Document to the
Document's overall subject (or to related matters) and contains nothing
that could fall directly within that overall subject. (Thus, if the
Document is in part a textbook of mathematics, a Secondary Section may
not explain any mathematics.) The relationship could be a matter of
historical connection with the subject or with related matters, or of
legal, commercial, philosophical, ethical or political position
regarding them.</para>
<para id="gfdl-inv-sect">The "Invariant Sections" are certain Secondary
Sections whose titles are designated, as being those of Invariant
Sections, in the notice that says that the Document is released under
this License. If a section does not fit the above definition of
Secondary then it is not allowed to be designated as Invariant. The
Document may contain zero Invariant Sections. If the Document does not
identify any Invariant Sections then there are none.</para>
<para id="gfdl-cov-text">The "Cover Texts" are certain short passages of
text that are listed, as Front-Cover Texts or Back-Cover Texts, in the
notice that says that the Document is released under this License. A
Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at
most 25 words.</para>
<para id="gfdl-transparent">A "Transparent" copy of the Document means a
machine-readable copy, represented in a format whose specification is
available to the general public, that is suitable for revising the
document straightforwardly with generic text editors or (for images
composed of pixels) generic paint programs or (for drawings) some widely
available drawing editor, and that is suitable for input to text
formatters or for automatic translation to a variety of formats suitable
for input to text formatters. A copy made in an otherwise Transparent
file format whose markup, or absence of markup, has been arranged to
thwart or discourage subsequent modification by readers is not
Transparent. An image format is not Transparent if used for any
substantial amount of text. A copy that is not "Transparent" is called
"Opaque".</para>
<para>Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML or
XML using a publicly available DTD, and standard-conforming simple HTML,
PostScript or PDF designed for human modification. Examples of
transparent image formats include PNG, XCF and JPG. Opaque formats
include proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the machine-generated
HTML, PostScript or PDF produced by some word processors for output
purposes only.</para>
<para id="gfdl-title-page">The "Title Page" means, for a printed book,
the title page itself, plus such following pages as are needed to hold,
legibly, the material this License requires to appear in the title page.
For works in formats which do not have any title page as such, "Title
Page" means the text near the most prominent appearance of the work's
title, preceding the beginning of the body of the text.</para>
<para id="gfdl-entitled">A section "Entitled XYZ" means a named subunit
of the Document whose title either is precisely XYZ or contains XYZ in
parentheses following text that translates XYZ in another language.
(Here XYZ stands for a specific section name mentioned below, such as
"Acknowledgements", "Dedications", "Endorsements", or "History".) To
"Preserve the Title" of such a section when you modify the Document
means that it remains a section "Entitled XYZ" according to this
definition.</para>
<para>The Document may include Warranty Disclaimers next to the notice
which states that this License applies to the Document. These Warranty
Disclaimers are considered to be included by reference in this License,
but only as regards disclaiming warranties: any other implication that
these Warranty Disclaimers may have is void and has no effect on the
meaning of this License.</para>
</section>
<section id="gfdl-2"><title>VERBATIM COPYING</title>
<para>You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies to
the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further copying
of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
</para>
<para>You may also lend copies, under the same conditions stated above,
and you may publicly display copies.</para>
</section>
<section id="gfdl-3"><title>COPYING IN QUANTITY</title>
<para>If you publish printed copies (or copies in media that commonly
have printed covers) of the Document, numbering more than 100, and the
Document's license notice requires Cover Texts, you must enclose the
copies in covers that carry, clearly and legibly, all these Cover Texts:
Front-Cover Texts on the front cover, and Back-Cover Texts on the back
cover. Both covers must also clearly and legibly identify you as the
publisher of these copies. The front cover must present the full title
with all words of the title equally prominent and visible. You may add
other material on the covers in addition. Copying with changes limited
to the covers, as long as they preserve the title of the Document and
satisfy these conditions, can be treated as verbatim copying in other
respects.</para>
<para>If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.</para>
<para>If you publish or distribute Opaque copies of the Document
numbering more than 100, you must either include a machine-readable
Transparent copy along with each Opaque copy, or state in or with each
Opaque copy a computer-network location from which the general
network-using public has access to download using public-standard
network protocols a complete Transparent copy of the Document, free of
added material. If you use the latter option, you must take reasonably
prudent steps, when you begin distribution of Opaque copies in quantity,
to ensure that this Transparent copy will remain thus accessible at the
stated location until at least one year after the last time you
distribute an Opaque copy (directly or through your agents or retailers)
of that edition to the public.</para>
<para>It is requested, but not required, that you contact the authors of
the Document well before redistributing any large number of copies, to
give them a chance to provide you with an updated version of the
Document.</para>
</section>
<section id="gfdl-4"><title>MODIFICATIONS</title>
<para>You may copy and distribute a Modified Version of the Document
under the conditions of sections 2 and 3 above, provided that you
release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing
distribution and modification of the Modified Version to whoever
possesses a copy of it. In addition, you must do these things in the
Modified Version:</para>
<orderedlist id="gfdl-modif-cond" numeration="upperalpha">
<listitem><simpara>Use in the Title Page (and on the covers, if any) a
title distinct from that of the Document, and from those of previous
versions (which should, if there were any, be listed in the History
section of the Document). You may use the same title as a previous
version if the original publisher of that version gives permission.
</simpara></listitem>
<listitem><simpara>List on the Title Page, as authors, one or more
persons or entities responsible for authorship of the modifications in
the Modified Version, together with at least five of the principal
authors of the Document (all of its principal authors, if it has fewer
than five), unless they release you from this requirement.
</simpara></listitem>
<listitem><simpara>State on the Title page the name of the publisher of
the Modified Version, as the publisher.</simpara></listitem>
<listitem><simpara>Preserve all the copyright notices of the Document.
</simpara></listitem>
<listitem><simpara>Add an appropriate copyright notice for your
modifications adjacent to the other copyright notices.
</simpara></listitem>
<listitem><simpara>Include, immediately after the copyright notices, a
license notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in the
<link linkend="gfdl-addendum">Addendum</link> below.
</simpara></listitem>
<listitem><simpara>Preserve in that license notice the full lists of
Invariant Sections and required Cover Texts given in the Document's
license notice.</simpara></listitem>
<listitem><simpara>Include an unaltered copy of this License.
</simpara></listitem>
<listitem><simpara>Preserve the section Entitled "History", Preserve its
Title, and add to it an item stating at least the title, year, new
authors, and publisher of the Modified Version as given on the Title
Page. If there is no section Entitled "History" in the Document,
create one stating the title, year, authors, and publisher of the
Document as given on its Title Page, then add an item describing the
Modified Version as stated in the previous sentence.
</simpara></listitem>
<listitem><simpara>Preserve the network location, if any, given in the
Document for public access to a Transparent copy of the Document, and
likewise the network locations given in the Document for previous
versions it was based on. These may be placed in the "History"
section. You may omit a network location for a work that was
published at least four years before the Document itself, or if the
original publisher of the version it refers to gives permission.
</simpara></listitem>
<listitem><simpara>For any section Entitled "Acknowledgements" or
"Dedications", Preserve the Title of the section, and preserve in the
section all the substance and tone of each of the contributor
acknowledgements and/or dedications given therein.
</simpara></listitem>
<listitem><simpara>Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers or the
equivalent are not considered part of the section titles.
</simpara></listitem>
<listitem><simpara>Delete any section Entitled "Endorsements".
Such a section may not be included in the Modified Version.
</simpara></listitem>
<listitem><simpara>Do not retitle any existing section to be Entitled
"Endorsements" or to conflict in title with any Invariant Section.
</simpara></listitem>
<listitem><simpara>Preserve any Warranty Disclaimers.
</simpara></listitem>
</orderedlist>
<para>If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.</para>
<para>You may add a section Entitled "Endorsements", provided it
contains nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.</para>
<para>You may add a passage of up to five words as a Front-Cover Text,
and a passage of up to 25 words as a Back-Cover Text, to the end of the
list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through
arrangements made by) any one entity. If the Document already includes
a cover text for the same cover, previously added by you or by
arrangement made by the same entity you are acting on behalf of, you may
not add another; but you may replace the old one, on explicit permission
from the previous publisher that added the old one.</para>
<para>The author(s) and publisher(s) of the Document do not by this
License give permission to use their names for publicity for or to
assert or imply endorsement of any Modified Version.</para>
</section>
<section id="gfdl-5"><title>COMBINING DOCUMENTS</title>
<para>You may combine the Document with other documents released under
this License, under the terms defined in <link linkend="gfdl-4">section
4</link> above for modified versions, provided that you include in the
combination all of the Invariant Sections of all of the original
documents, unmodified, and list them all as Invariant Sections of your
combined work in its license notice, and that you preserve all their
Warranty Disclaimers.</para>
<para>The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by adding
at the end of it, in parentheses, the name of the original author or
publisher of that section if known, or else a unique number. Make the
same adjustment to the section titles in the list of Invariant Sections
in the license notice of the combined work.</para>
<para>In the combination, you must combine any sections Entitled
"History" in the various original documents, forming one section
Entitled "History"; likewise combine any sections Entitled
"Acknowledgements", and any sections Entitled "Dedications". You must
delete all sections Entitled "Endorsements".</para>
</section>
<section id="gfdl-6"><title>COLLECTIONS OF DOCUMENTS</title>
<para>You may make a collection consisting of the Document and other
documents released under this License, and replace the individual copies
of this License in the various documents with a single copy that is
included in the collection, provided that you follow the rules of this
License for verbatim copying of each of the documents in all other
respects.</para>
<para>You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert a
copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that
document.</para>
</section>
<section id="gfdl-7"><title>AGGREGATION WITH INDEPENDENT WORKS</title>
<para>A compilation of the Document or its derivatives with other
separate and independent documents or works, in or on a volume of a
storage or distribution medium, is called an "aggregate" if the
copyright resulting from the compilation is not used to limit the legal
rights of the compilation's users beyond what the individual works
permit. When the Document is included in an aggregate, this License does
not apply to the other works in the aggregate which are not themselves
derivative works of the Document.</para>
<para>If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one half of
the entire aggregate, the Document's Cover Texts may be placed on covers
that bracket the Document within the aggregate, or the electronic
equivalent of covers if the Document is in electronic form. Otherwise
they must appear on printed covers that bracket the whole
aggregate.</para>
</section>
<section id="gfdl-8"><title>TRANSLATION</title>
<para>Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License, and all the license notices in the
Document, and any Warranty Disclaimers, provided that you also include
the original English version of this License and the original versions
of those notices and disclaimers. In case of a disagreement between the
translation and the original version of this License or a notice or
disclaimer, the original version will prevail.</para>
<para>If a section in the Document is Entitled "Acknowledgements",
"Dedications", or "History", the requirement (section 4) to Preserve its
Title (section 1) will typically require changing the actual
title.</para>
</section>
<section id="gfdl-9"><title>TERMINATION</title>
<para>You may not copy, modify, sublicense, or distribute the Document
except as expressly provided for under this License. Any other attempt
to copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this License
will not have their licenses terminated so long as such parties remain
in full compliance.</para>
</section>
<section id="gfdl-10"><title>FUTURE REVISIONS OF THIS LICENSE</title>
<para>The Free Software Foundation may publish new, revised versions of
the GNU Free Documentation License from time to time. Such new versions
will be similar in spirit to the present version, but may differ in
detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.</para>
<para>Each version of the License is given a distinguishing version
number. If the Document specifies that a particular numbered version of
this License "or any later version" applies to it, you have the option
of following the terms and conditions either of that specified version
or of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.</para>
</section>
<section id="gfdl-addendum"><title>ADDENDUM: How to use this License for
your documents</title>
<para>To use this License in a document you have written, include a copy
of the License in the document and put the following copyright and
license notices just after the title page:</para>
<blockquote id="copyright-sample"><para>
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
</para></blockquote>
<para>If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:</para>
<blockquote id="inv-cover-sample"><para>
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
</para></blockquote>
<para>If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.</para>
<para>If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit
their use in free software.</para>
</section>
</appendix>

324
Shorewall-docs2/IPIP.xml Normal file
View File

@ -0,0 +1,324 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="IPIP">
<!--$Id$-->
<articleinfo>
<title>GRE and IPIP Tunnels</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-02-22</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<warning>
<para>GRE and IPIP Tunnels are insecure when used over the internet; use
them at your own risk</para>
</warning>
<para>GRE and IPIP tunneling with Shorewall can be used to bridge two
masqueraded networks.</para>
<para>The simple scripts described in the <citetitle><ulink
url="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping HOWTO</ulink></citetitle>
work fine with Shorewall. Shorewall also includes a tunnel script for
automating tunnel configuration. If you have installed the RPM, the tunnel
script may be found in the Shorewall documentation directory (usually
/usr/share/doc/shorewall-&#60;version&#62;/).</para>
<section>
<title>Bridging two Masqueraded Networks</title>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is
accomplished through use of the /etc/shorewall/tunnels file, the
/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
included with Shorewall.</para>
<para>The <quote>tunnel</quote> script is not installed in /etc/shorewall
by default -- If you install using the tarball, the script is included in
the tarball; if you install using the RPM, the file is in your Shorewall
documentation directory (normally
/usr/share/doc/shorewall-&#60;version&#62;).</para>
<para>In the /etc/shorewall/tunnel script, set the <quote>tunnel_type</quote>
parameter to the type of tunnel that you want to create.</para>
<example>
<title>/etc/shorewall/tunnel</title>
<programlisting>tunnel_type=gre</programlisting>
</example>
<para>On each firewall, you will need to declare a zone to represent the
remote subnet. We&#39;ll assume that this zone is called <quote>vpn</quote>
and declare it in /etc/shorewall/zones on both systems as follows.</para>
<table>
<title>/etc/shorewall/zones system A &#38; B</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>VPN</entry>
<entry>Remote Subnet</entry>
</row>
</tbody>
</tgroup>
</table>
<para>On system A, the 10.0.0.0/8 will comprise the <emphasis role="bold">vpn</emphasis>
zone. In /etc/shorewall/interfaces:</para>
<table>
<title>/etc/shorewall/interfaces system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tosysb</entry>
<entry>10.255.255.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on system A, we need the following:</para>
<table>
<title>/etc/shorewall/tunnels system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipip</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>This entry in /etc/shorewall/tunnels, opens the firewall so that the
IP encapsulation protocol (4) will be accepted to/from the remote gateway.</para>
<para>In the tunnel script on system A:</para>
<example>
<title>tunnel script on system A</title>
<programlisting>tunnel=tosysb
myrealip=206.161.148.9 (for GRE tunnel only)
myip=192.168.1.1
hisip=10.0.0.1
gateway=134.28.54.2
subnet=10.0.0.0/8
</programlisting>
</example>
<para>Similarly, On system B the 192.168.1.0/24 subnet will comprise the
<emphasis role="bold">vpn</emphasis> zone. In /etc/shorewall/interfaces:</para>
<table>
<title>/etc/shorewall/interfaces system B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tosysa</entry>
<entry>192.168.1.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on system B, we have:</para>
<table>
<title>/etc/shorewall/tunnels system B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipip</entry>
<entry>net</entry>
<entry>206.191.148.9</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>And in the tunnel script on system B:</para>
<example>
<title>tunnel script on system B</title>
<programlisting>tunnel=tosysa
myrealip=134.28.54.2 (for GRE tunnel only)
myip=10.0.0.1
hisip=192.168.1.1
gateway=206.191.148.9
subnet=192.168.1.0/24</programlisting>
</example>
<para>You can rename the modified tunnel scripts if you like; be sure that
they are secured so that root can execute them.</para>
<para>You will need to allow traffic between the <quote>vpn</quote> zone
and the <quote>loc</quote> zone on both systems -- if you simply want to
admit all traffic in both directions, you can use the policy file:</para>
<table>
<title>/etc/shorewall/policy system A &#38; B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>vpn</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>On both systems, restart Shorewall and run the modified tunnel
script with the <quote>start</quote> argument on each system. The systems
in the two masqueraded subnetworks can now talk to each other</para>
</section>
</article>

847
Shorewall-docs2/IPSEC.xml Normal file
View File

@ -0,0 +1,847 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="IPSEC">
<!--$Id$-->
<articleinfo>
<title>IPSEC Tunnels</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-22</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<warning>
<para>This documentation does not cover configuring IPSEC under the 2.6
Linux Kernel. David Hollis has provided i<ulink
url="http://lists.shorewall.net/pipermail/shorewall-users/2003-December/010417.html">nformation
about how to set up a simple tunnel under 2.6</ulink>. One important point
that is not made explicit in David&#39;s post is that the <emphasis
role="bold">vpn</emphasis> zone must be defined before the <emphasis
role="bold">net</emphasis> zone in <filename>/etc/shorewall/zones</filename>.</para>
</warning>
<section>
<title>Configuring FreeS/Wan</title>
<para>There is an excellent guide to configuring IPSEC tunnels at <ulink
url="http://www.geocities.com/jixen66/">http://www.geocities.com/jixen66/</ulink>.
I highly recommend that you consult that site for information about
configuring FreeS/Wan.</para>
<warning>
<para>Do not use Proxy ARP and FreeS/Wan on the same system unless you
are prepared to suffer the consequences. If you start or restart
Shorewall with an IPSEC tunnel active, the proxied IP addresses are
mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to
the interface that you specify in the INTERFACE column of
/etc/shorewall/proxyarp. I haven&#39;t had the time to debug this
problem so I can&#39;t say if it is a bug in the Kernel or in FreeS/Wan.</para>
<para>You <emphasis role="bold">might</emphasis> be able to work around
this problem using the following (I haven&#39;t tried it):</para>
<para>In /etc/shorewall/init, include:</para>
<programlisting>qt service ipsec stop</programlisting>
<para>In /etc/shorewall/start, include:</para>
<programlisting>qt service ipsec start</programlisting>
</warning>
<important>
<para>The documentation below assumes that you have disabled
opportunistic encryption feature in FreeS/Wan 2.0 using the following
additional entries in ipsec.conf:</para>
<programlisting>conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore</programlisting>
<para>For further information see <ulink
url="http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html">http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html</ulink>.</para>
</important>
</section>
<section>
<title>IPSec Gateway on the Firewall System</title>
<para>Suppose that we have the following sutuation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 sub-network to be able to
communicate with systems in the 10.0.0.0/8 network.</para>
<para>To make this work, we need to do two things:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>Open the firewall so that the IPSEC tunnel can be established
(allow the ESP and AH protocols and UDP Port 500).</para>
</listitem>
<listitem>
<para>Allow traffic through the tunnel.</para>
</listitem>
</orderedlist>
<para>Opening the firewall for the IPSEC tunnel is accomplished by adding
an entry to the /etc/shorewall/tunnels file.</para>
<para>In /etc/shorewall/tunnels on system A, we need the following</para>
<table>
<title>/etc/shorewall/tunnels system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on system B, we would have:</para>
<table>
<title>/etc/shorewall/tunnels system B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>206.161.148.9</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<note>
<para>If either of the endpoints is behind a NAT gateway then the
tunnels file entry on the <emphasis role="bold">other</emphasis>
endpoint should specify a tunnel type of ipsecnat rather than ipsec and
the GATEWAY address should specify the external address of the NAT
gateway.</para>
</note>
<example>
<title>VPN</title>
<para>You need to define a zone for the remote subnet or include it in
your local zone. In this example, we&#39;ll assume that you have created
a zone called <quote>vpn</quote> to represent the remote subnet.</para>
<para><table><title>/etc/shorewall/zones local</title><tgroup cols="3"><thead><row><entry
align="center">ZONE</entry><entry align="center">DISPLAY</entry><entry
align="center">COMMENTS</entry></row></thead><tbody><row><entry>vpn</entry><entry>VPN</entry><entry>Remote
Subnet</entry></row></tbody></tgroup></table></para>
<para>At both systems, ipsec0 would be included in
/etc/shorewall/interfaces as a <quote>vpn</quote> interface:</para>
<para><table><title>/etc/shorewall/interfaces system local &#38; remote</title><tgroup
cols="4"><thead><row><entry align="center">ZONE</entry><entry
align="center">INTERFACE</entry><entry align="center">BROADCAST</entry><entry
align="center">OPTIONS</entry></row></thead><tbody><row><entry>vpn</entry><entry>ipsec0</entry><entry></entry><entry></entry></row></tbody></tgroup></table></para>
<para>You will need to allow traffic between the <quote>vpn</quote> zone
and the <quote>loc</quote> zone -- if you simply want to admit all
traffic in both directions, you can use the policy file:</para>
<para><table><title>/etc/shorewall/policy local &#38; remote</title><tgroup
cols="4"><thead><row><entry align="center">SOURCE</entry><entry
align="center">DEST</entry><entry align="center">POLICY</entry><entry
align="center">LOG LEVEL</entry></row></thead><tbody><row><entry>loc</entry><entry>vpn</entry><entry>ACCEPT</entry><entry></entry></row><row><entry>vpn</entry><entry>loc</entry><entry>ACCEPT</entry><entry></entry></row></tbody></tgroup></table></para>
<para>Once you have these entries in place, restart Shorewall (type
shorewall restart); you are now ready to configure the tunnel in <ulink
url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink>.</para>
</example>
</section>
<section>
<title>VPN Hub</title>
<para>Shorewall can be used in a VPN Hub environment where multiple remote
networks are connected to a gateway running Shorewall. This environment is
shown in this diatram.</para>
<graphic fileref="images/ThreeNets.png" />
<para>We want systems in the 192.168.1.0/24 sub-network to be able to
communicate with systems in the 10.0.0.0/16 and 10.1.0.0/16 networks and
we want the 10.0.0.0/16 and 10.1.0.0/16 networks to be able to
communicate.</para>
<para>To make this work, we need to do several things:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>Open the firewall so that two IPSEC tunnels can be established
(allow the ESP and AH protocols and UDP Port 500).</para>
</listitem>
<listitem>
<para>Allow traffic through the tunnels two/from the local zone
(192.168.1.0/24).</para>
</listitem>
<listitem>
<para>Deny traffic through the tunnels between the two remote
networks.</para>
</listitem>
</orderedlist>
<para>Opening the firewall for the IPSEC tunnels is accomplished by adding
two entries to the /etc/shorewall/tunnels file.</para>
<para>In /etc/shorewall/tunnels on system A, we need the following</para>
<table>
<title>/etc/shorewall/tunnels system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>130.152.100.14</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on systems B and C, we would have:</para>
<table>
<title>/etc/shorewall/tunnels system B &#38; C</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>206.161.148.9</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<note>
<para>If either of the endpoints is behind a NAT gateway then the
tunnels file entry on the <emphasis role="bold">other</emphasis>
endpoint should specify a tunnel type of <emphasis>ipsecnat</emphasis>
rather than ipsec and the GATEWAY address should specify the external
address of the NAT gateway.</para>
</note>
<para>On each system, we will create a zone to represent the remote
networks. On System A:</para>
<table>
<title>/etc/shorewall/zones system A</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn1</entry>
<entry>VPN1</entry>
<entry>Remote Subnet on system B</entry>
</row>
<row>
<entry>vpn2</entry>
<entry>VPN2</entry>
<entry>Remote Subnet on system C</entry>
</row>
</tbody>
</tgroup>
</table>
<para>On systems B and C:</para>
<table>
<title>/etc/shorewall/zones system B &#38; C</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>VPN</entry>
<entry>Remote Subnet on system A</entry>
</row>
</tbody>
</tgroup>
</table>
<para>At system A, ipsec0 represents two zones so we have the following in
/etc/shorewall/interfaces:</para>
<table>
<title>/etc/shorewall/interfaces system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>-</entry>
<entry>ipsec0</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>The /etc/shorewall/hosts file on system A defines the two VPN zones:</para>
<table>
<title>/etc/shorewall/hosts system A</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">HOSTS</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn1</entry>
<entry>ipsec0:10.0.0.0/16</entry>
<entry></entry>
</row>
<row>
<entry>vpn2</entry>
<entry>ipsec0:10.1.0.0/16</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>At systems B and C, ipsec0 represents a single zone so we have the
following in /etc/shorewall/interfaces:</para>
<table>
<title>/etc/shorewall/interfaces system B &#38; C</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>ipsec0</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>On systems A, you will need to allow traffic between the
<quote>vpn1</quote> zone and the <quote>loc</quote> zone as well as
between <quote>vpn2</quote> and the <quote>loc</quote> zone -- if you
simply want to admit all traffic in both directions, you can use the
following policy file entries on all three gateways:</para>
<table>
<title>/etc/shorewall/policy system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>vpn1</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn1</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>loc</entry>
<entry>vpn2</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn2</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>On systems B and C, you will need to allow traffic between the
<quote>vpn</quote> zone and the <quote>loc</quote> zone -- if you simply
want to admit all traffic in both directions, you can use the following
policy file entries on all three gateways:</para>
<table>
<title>/etc/shorewall/policy system B &#38; C</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>vpn</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>Once you have the Shorewall entries added, restart Shorewall on each
gateway (type shorewall restart); you are now ready to configure the
tunnels in <ulink url="http://www.xs4all.nl/%7Efreeswan/">FreeS/WAN</ulink>.</para>
<note>
<para>to allow traffic between the networks attached to systems B and C,
it is necessary to simply add two additional entries to the
/etc/shorewall/policy file on system A.</para>
<table>
<title>/etc/shorewall/policy system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn1</entry>
<entry>vpn2</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn2</entry>
<entry>vpn1</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
</note>
<note>
<para>If you find traffic being rejected/dropped in the OUTPUT chain,
place the names of the remote VPN zones as a comma-separated list in the
GATEWAY ZONE column of the /etc/shorewall/tunnels file entry.</para>
</note>
</section>
<section>
<title>Mobile System (Road Warrior)</title>
<para>Suppose that you have a laptop system (B) that you take with you
when you travel and you want to be able to establish a secure connection
back to your local network.</para>
<graphic fileref="images/Mobile.png" />
<example>
<title>Road Warrior VPN</title>
<para>You need to define a zone for the laptop or include it in your
local zone. In this example, we&#39;ll assume that you have created a
zone called <quote>vpn</quote> to represent the remote host.</para>
<para><table><title>/etc/shorewall/zones local</title><tgroup cols="3"><thead><row><entry
align="center">ZONE</entry><entry align="center">DISPLAY</entry><entry
align="center">COMMENTS</entry></row></thead><tbody><row><entry>vpn</entry><entry>VPN</entry><entry>Remote
Subnet</entry></row></tbody></tgroup></table></para>
<para>In this instance, the mobile system (B) has IP address 134.28.54.2
but that cannot be determined in advance. In the /etc/shorewall/tunnels
file on system A, the following entry should be made:</para>
<para><table><title>/etc/shorewall/tunnels system A</title><tgroup
cols="4"><thead><row><entry align="center">TYPE</entry><entry
align="center">ZONE</entry><entry align="center">GATEWAY</entry><entry
align="center">GATEWAY ZONE</entry></row></thead><tbody><row><entry>ipsec</entry><entry>net</entry><entry>0.0.0.0/0</entry><entry>vpn</entry></row></tbody></tgroup></table></para>
<para><note><para>the GATEWAY ZONE column contains the name of the zone
corresponding to peer subnetworks. This indicates that the gateway
system itself comprises the peer subnetwork; in other words, the remote
gateway is a standalone system.</para></note></para>
<para>You will need to configure /etc/shorewall/interfaces and establish
your <quote>through the tunnel</quote> policy as shown under the first
example above.</para>
</example>
</section>
<section>
<title>Dynamic RoadWarrior Zones</title>
<para>Beginning with Shorewall release 1.3.10, you can define multiple VPN
zones and add and delete remote endpoints dynamically using
/sbin/shorewall. In /etc/shorewall/zones:</para>
<table>
<title>/etc/shorewall/zones</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn1</entry>
<entry>VPN-1</entry>
<entry>First VPN Zone</entry>
</row>
<row>
<entry>vpn2</entry>
<entry>VPN-2</entry>
<entry>Second VPN Zone</entry>
</row>
<row>
<entry>vpn3</entry>
<entry>VPN-3</entry>
<entry>Third VPN Zone</entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels:</para>
<table>
<title>/etc/shorewall/tunnels</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>ipsec</entry>
<entry>net</entry>
<entry>0.0.0.0/0</entry>
<entry>vpn1,vpn2,vpn3</entry>
</row>
</tbody>
</tgroup>
</table>
<para>When Shorewall is started, the zones vpn[1-3] will all be empty and
Shorewall will issue warnings to that effect. These warnings may be safely
ignored. FreeS/Wan may now be configured to have three different Road
Warrior connections with the choice of connection being based on X-509
certificates or some other means. Each of these connectioins will utilize
a different updown script that adds the remote station to the appropriate
zone when the connection comes up and that deletes the remote station when
the connection comes down. For example, when 134.28.54.2 connects for the
vpn2 zone the <quote>up</quote> part of the script will issue the command:</para>
<programlisting>/sbin/shorewall add ipsec0:134.28.54.2 vpn2</programlisting>
<para>and the <quote>down</quote> part will:</para>
<programlisting>/sbin/shorewall delete ipsec0:134.28.54.2 vpn2</programlisting>
<section>
<title>Limitations of Dynamic Zones</title>
<para>If you include a dynamic zone in the exclude list of a DNAT rule,
the dynamically-added hosts are not excluded from the rule.</para>
<example>
<title>dyn=dynamic zone</title>
<para><informaltable><tgroup cols="7"><thead><row><entry
align="center">ACTION</entry><entry align="center">SOURCE</entry><entry
align="center">DESTINATION</entry><entry align="center">PROTOCOL</entry><entry
align="center">PORT(S)</entry><entry align="center">CLIENT PORT(S)</entry><entry
align="center">ORIGINAL DESTINATION</entry></row></thead><tbody><row><entry>DNAT</entry><entry>z!dyn</entry><entry>loc:192.168.1.3</entry><entry>tcp</entry><entry>80</entry><entry></entry><entry></entry></row></tbody></tgroup></informaltable></para>
<para>Dynamic changes to the zone <emphasis role="bold">dyn</emphasis>
will have no effect on the above rule.</para>
</example>
</section>
</section>
</article>

371
Shorewall-docs2/Install.xml Normal file
View File

@ -0,0 +1,371 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Install">
<!--$Id$-->
<articleinfo>
<title>Shorewall Installation and Upgrade</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-04-08</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<important>
<para>Before upgrading, be sure to review the <ulink
url="upgrade_issues.htm">Upgrade Issues</ulink>.</para>
</important>
<important>
<para>Before attempting installation, I strongly urge you to read and
print a copy of the <ulink url="shorewall_quickstart_guide.htm">Shorewall
QuickStart</ulink> Guide for the configuration that most closely matches
your own.</para>
</important>
<section id="Install_RPM">
<title>Install using RPM</title>
<para>To install Shorewall using the RPM:</para>
<warning>
<para>If you have RedHat 7.2 and are running iptables version 1.2.3 (at
a shell prompt, type <quote>/sbin/iptables --version</quote>), you must
upgrade to version 1.2.4 either from the <ulink
url="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat
update site</ulink> or from the <ulink url="errata.htm">Shorewall Errata
page</ulink> before attempting to start Shorewall.</para>
</warning>
<orderedlist>
<listitem>
<para>Install the RPM</para>
<programlisting>rpm -ivh &#60;shorewall rpm&#62;</programlisting>
<note>
<para>Some SuSE users have encountered a problem whereby rpm reports
a conflict with kernel &#60;= 2.2 even though a 2.4 kernel is
installed. If this happens, simply use the --nodeps option to rpm.</para>
<programlisting>rpm -ivh --nodeps &#60;shorewall rpm&#62;</programlisting>
</note>
<note>
<para>Beginning with Shorewall 1.4.0, Shorewall is dependent on the
iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the installation of Shorewall to fail with
the diagnostic:</para>
<programlisting>error: failed dependencies:iproute is needed by shorewall-1.4.x-1</programlisting>
<para>This may be worked around by using the --nodeps option of rpm.</para>
<programlisting>rpm -ivh --nodeps &#60;shorewall rpm&#62;</programlisting>
</note>
</listitem>
<listitem>
<para>Edit the <link linkend="Config_Files">configuration files</link>
to match your configuration.</para>
<warning>
<para>YOU CAN <emphasis role="bold">NOT</emphasis> SIMPLY INSTALL
THE RPM AND ISSUE A <quote>shorewall start</quote> COMMAND. SOME
CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START. IF YOU
ISSUE A <quote>start</quote> COMMAND AND THE FIREWALL FAILS TO
START, YOUR SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF
THIS HAPPENS, ISSUE A <quote>shorewall clear</quote> COMMAND TO
RESTORE NETWORK CONNECTIVITY.</para>
</warning>
</listitem>
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
</listitem>
</orderedlist>
</section>
<section id="Install_Tarball">
<title>Install using tarball</title>
<para>To install Shorewall using the tarball and install script:</para>
<orderedlist>
<listitem>
<para>unpack the tarball (tar -zxf shorewall-x.y.z.tgz).</para>
</listitem>
<listitem>
<para>cd to the shorewall directory (the version is encoded in the
directory name as in <quote>shorewall-1.1.10</quote>).</para>
</listitem>
<listitem>
<para>If you are using <ulink
url="http://www.caldera.com/openstore/openlinux/">Caldera</ulink>,
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
url="http://www.corel.com">Corel</ulink>, <ulink
url="http://www.slackware.com/">Slackware</ulink> or <ulink
url="http://www.debian.org">Debian</ulink> then type</para>
<programlisting>./install.sh</programlisting>
<orderedlist numeration="loweralpha">
<listitem>
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
then type</para>
<programlisting>./install.sh /etc/init.d</programlisting>
</listitem>
<listitem>
<para>If your distribution has directory /etc/rc.d/init.d or
/etc/init.d then type</para>
<programlisting>./install.sh</programlisting>
</listitem>
<listitem>
<para>For other distributions, determine where your distribution
installs init scripts and type</para>
<programlisting>./install.sh &#60;init script directory&#62;</programlisting>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>Edit the <link linkend="Config_Files">configuration files</link>
to match your configuration.</para>
</listitem>
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
</listitem>
<listitem>
<para>If the install script was unable to configure Shorewall to be
started automatically at boot, see <ulink
url="starting_and_stopping_shorewall.htm">these instructions</ulink>.</para>
</listitem>
</orderedlist>
</section>
<section id="LRP">
<title>Install the .lrp</title>
<para>To install my version of Shorewall on a fresh Bering disk, simply
replace the <quote>shorwall.lrp</quote> file on the image with the file
that you downloaded. See the <ulink url="two-interface.htm">two-interface
QuickStart Guide</ulink> for information about further steps required.</para>
</section>
<section id="Upgrade_RPM">
<title>Upgrade using RPM</title>
<para>If you already have the Shorewall RPM installed and are upgrading to
a new version:</para>
<important>
<para>If you are upgrading from a 1.2 version of Shorewall to a 1.4
version or and you have entries in the /etc/shorewall/hosts file then
please check your /etc/shorewall/interfaces file to be sure that it
contains an entry for each interface mentioned in the hosts file. Also,
there are certain 1.2 rule forms that are no longer supported under 1.4
(you must use the new 1.4 syntax). See <ulink url="errata.htm#Upgrade">the
upgrade issues</ulink> for details.</para>
</important>
<orderedlist>
<listitem>
<para>Upgrade the RPM</para>
<programlisting>rpm -Uvh &#60;shorewall rpm file&#62;</programlisting>
<note>
<para>If you are installing version 1.2.0 and have one of the 1.2.0
Beta RPMs installed, you must use the <quote>--oldpackage</quote>
option to rpm.</para>
<informalexample>
<programlisting>rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm</programlisting>
</informalexample>
</note>
<note>
<para>Some SuSE users have encountered a problem whereby rpm reports
a conflict with kernel &#60;= 2.2 even though a 2.4 kernel is
installed. If this happens, simply use the --nodeps option to rpm.</para>
<programlisting>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</programlisting>
</note>
<note>
<para>Beginning with Shorewall 1.4.0, Shorewall is dependent on the
iproute package. Unfortunately, some distributions call this package
iproute2 which will cause the upgrade of Shorewall to fail with the
diagnostic:</para>
<programlisting>error: failed dependencies:iproute is needed by shorewall-1.4.0-1</programlisting>
<para>This may be worked around by using the --nodeps option of rpm.</para>
<programlisting>rpm -Uvh --nodeps &#60;shorewall rpm&#62;</programlisting>
</note>
</listitem>
<listitem>
<para>See if there are any incompatibilities between your
configuration and the new Shorewall version and correct as necessary.</para>
<programlisting>shorewall check</programlisting>
</listitem>
<listitem>
<para>Restart the firewall.</para>
<programlisting>shorewall restart</programlisting>
</listitem>
</orderedlist>
</section>
<section id="Upgrade_Tarball">
<title>Upgrade using tarball</title>
<para>If you already have Shorewall installed and are upgrading to a new
version using the tarball:</para>
<important>
<para>If you are upgrading from a 1.2 version of Shorewall to a 1.4
version and you have entries in the /etc/shorewall/hosts file then
please check your /etc/shorewall/interfaces file to be sure that it
contains an entry for each interface mentioned in the hosts file. Also,
there are certain 1.2 rule forms that are no longer supported under 1.4
(you must use the new 1.4 syntax). See <ulink url="errata.htm#Upgrade">the
upgrade issues</ulink> for details.</para>
</important>
<orderedlist>
<listitem>
<para>unpack the tarball.</para>
<programlisting>tar -zxf shorewall-x.y.z.tgz</programlisting>
</listitem>
<listitem>
<para>cd to the shorewall directory (the version is encoded in the
directory name as in <quote>shorewall-3.0.1</quote>).</para>
</listitem>
<listitem>
<para>If you are using <ulink
url="http://www.caldera.com/openstore/openlinux/">Caldera</ulink>,
<ulink url="http://www.redhat.com">RedHat</ulink>, <ulink
url="http://www.linux-mandrake.com">Mandrake</ulink>, <ulink
url="http://www.corel.com">Corel</ulink>, <ulink
url="http://www.slackware.com/">Slackware</ulink> or <ulink
url="http://www.debian.org">Debian</ulink> then type</para>
<programlisting>./install.sh</programlisting>
<orderedlist numeration="loweralpha">
<listitem>
<para>If you are using <ulink url="http://www.suse.com">SuSe</ulink>
then type</para>
<programlisting>./install.sh /etc/init.d</programlisting>
</listitem>
<listitem>
<para>If your distribution has directory /etc/rc.d/init.d or
/etc/init.d then type</para>
<programlisting>./install.sh</programlisting>
</listitem>
<listitem>
<para>For other distributions, determine where your distribution
installs init scripts and type</para>
<programlisting>./install.sh &#60;init script directory&#62;</programlisting>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>See if there are any incompatibilities between your
configuration and the new Shorewall version and correct as necessary.</para>
<programlisting>shorewall check</programlisting>
</listitem>
<listitem>
<para>Start the firewall by typing</para>
<programlisting>shorewall start</programlisting>
</listitem>
<listitem>
<para>If the install script was unable to configure Shorewall to be
started automatically at boot, see <ulink
url="starting_and_stopping_shorewall.htm">these instructions</ulink>.</para>
</listitem>
</orderedlist>
</section>
<section id="LRP_Upgrade">
<title>Upgrade the .lrp</title>
<para>If you already have a running Bering installation and wish to
upgrade to a later version of Shorewall:</para>
<remark>UNDER CONSTRUCTION...</remark>
</section>
<section id="Config_Files">
<title>Configuring Shorewall</title>
<para>You will need to edit some or all of the configuration files to
match your setup. In most cases, the <ulink
url="shorewall_quickstart_guide.htm">Shorewall QuickStart Guides</ulink>
contain all of the information you need.</para>
</section>
<section>
<title>Uninstall/Fallback</title>
<para>See <quote><ulink url="fallback.htm">Fallback and Uninstall</ulink></quote>.</para>
</section>
</article>

202
Shorewall-docs2/Introduction.xml Normal file
View File

@ -0,0 +1,202 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="usefull_links">
<!--$Id$-->
<articleinfo>
<title>Introduction</title>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
<pubdate>2004-02-03</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink type="" url="Copyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Introduction</title>
<para>The information in this document applies only to 2.0.x releases of
Shorewall.</para>
<section>
<title>Glossary</title>
<itemizedlist>
<listitem>
<para><ulink url="http://www.netfilter.org">Netfilter</ulink> - the
packet filter facility built into the 2.4 and later Linux kernels.</para>
</listitem>
<listitem>
<para>ipchains - the packet filter facility built into the 2.2 Linux
kernels. Also the name of the utility program used to configure and
control that facility. Netfilter can be used in ipchains
compatibility mode.</para>
</listitem>
<listitem>
<para>iptables - the utility program used to configure and control
Netfilter. The term <quote>iptables</quote> is often used to refer
to the combination of iptables+Netfilter (with Netfilter not in
ipchains compatibility mode).</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>What is Shorewall?</title>
<para>The Shoreline Firewall, more commonly known as <quote>Shorewall</quote>,
is high-level tool for configuring Netfilter. You describe your
firewall/gateway requirements using entries in a set of configuration
files. Shorewall reads those configuration files and with the help of
the iptables utility, Shorewall configures Netfilter to match your
requirements. Shorewall can be used on a dedicated firewall system, a
multi-function gateway/router/server or on a standalone GNU/Linux
system. Shorewall does not use Netfilter&#39;s ipchains compatibility
mode and can thus take advantage of Netfilter&#39;s connection state
tracking capabilities.</para>
<para>Shorewall is not a daemon. Once Shorewall has configured
Netfilter, it&#39;s job is complete although the <ulink
url="starting_and_stopping_shorewall.htm">/sbin/shorewall program can be
used at any time to monitor the Netfilter firewall</ulink>.</para>
</section>
<section>
<title>Getting Started with Shorewall</title>
<para>New to Shorewall? Start by selecting the <ulink
url="shorewall_quickstart_guide.htm">QuickStart Guide</ulink> that most
closely match your environment and follow the step by step instructions.</para>
</section>
<section>
<title>Looking for Information?</title>
<para>The <ulink url="Documentation_Index.html">Documentation Index</ulink>
is a good place to start.</para>
</section>
</section>
<section>
<title>Shorewall Concepts</title>
<para>The configuration files for Shorewall are contained in the directory
<filename class="directory">/etc/shorewall</filename> -- for simple
setups, you will only need to deal with a few of them.</para>
<para>Shorewall views the network where it is running as being composed of
a set of zones. In the <ulink url="three-interface.htm">three-interface
sample configuration</ulink> for example, the following zone names are
used: <informaltable frame="all" pgwide="0"><tgroup align="left" cols="2"><thead
valign="middle"><row valign="middle"><entry align="left">Name</entry><entry
align="left">Description</entry></row></thead><tbody valign="middle"><row
valign="middle"><entry align="left"><varname>net</varname></entry><entry
align="left">The Internet</entry></row><row valign="middle"><entry
align="left"><varname>loc</varname></entry><entry align="left">Your Local
Network</entry></row><row valign="middle"><entry align="left"><varname>dmz</varname></entry><entry
align="left">Demilitarized Zone</entry></row></tbody></tgroup></informaltable>Zones
are defined in the <ulink url="Documentation.htm#Zones"><filename
class="directory">/etc/shorewall/</filename><filename>zones</filename></ulink>
file.</para>
<para>Shorewall also recognizes the firewall system as its own zone - by
default, the firewall itself is known as <emphasis role="bold"><varname>fw</varname></emphasis>.</para>
<para>Rules about what traffic to allow and what traffic to deny are
expressed in terms of zones. <itemizedlist spacing="compact"><listitem><para>You
express your default policy for connections from one zone to another zone
in the <ulink url="Documentation.htm#Policy"><filename class="directory">/etc/shorewall/</filename><filename>policy</filename></ulink>
file. The choices for policy are:</para><itemizedlist><listitem><para>ACCEPT
- Accept the connection.</para></listitem><listitem><para>DROP - Ignore
the connection request.</para></listitem><listitem><para>REJECT - Return
an appropriate error to the connection request.</para></listitem></itemizedlist><para>Connection
request logging may be specified as part of a policy and it is
conventional to log DROP and REJECT policies.</para></listitem><listitem><para>You
define exceptions to those default policies in the <ulink
url="Documentation.htm#Rules"><filename class="directory">/etc/shorewall/</filename><filename>rules</filename></ulink>
file.</para></listitem></itemizedlist>For each connection request entering
the firewall, the request is first checked against the <filename
class="directory">/etc/shorewall/</filename><filename>rules</filename>
file. If no rule in that file matches the connection request then the
first policy in <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
that matches the request is applied. If there is a common action defined
for the policy in /etc/shorewall/actions then that action is invoked
before the policy is enforces. In the standard Shorewall distribution, the
DROP policy has a common action called <emphasis role="bold">Drop</emphasis>
and the REJECT policy has a common action called <emphasis role="bold">Reject</emphasis>.
Common actions are used primarily to discard </para>
<para>The <filename class="directory">/etc/shorewall/</filename><filename>policy</filename>
file included with the three-interface sample has the following policies:
<programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT info</programlisting>In the three-interface
sample, the line below is included but commented out. If you want your
firewall system to have full access to servers on the internet, uncomment
that line. <programlisting>#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
fw net ACCEPT</programlisting> The above policy will:
<itemizedlist><listitem><para>Allow all connection requests from your
local network to the internet</para></listitem><listitem><para>Drop
(ignore) all connection requests from the internet to your firewall or
local network; these ignored connection requests will be logged using the
<emphasis>info</emphasis> syslog priority (log level).</para></listitem><listitem><para>Optionally
accept all connection requests from the firewall to the internet (if you
uncomment the additional policy)</para></listitem><listitem><para>reject
all other connection requests; these rejected connection requests will be
logged using the <emphasis>info</emphasis> syslog priority (log level).</para></listitem></itemizedlist></para>
<para>The simplest way to define a zone is to associate the zone with a
network interface using the <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
file. In the three-interface sample, the three zones are defined using
that file as follows:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect dhcp,routefilter,norfc1918
loc eth1 detect
dmz eth2 detect</programlisting>
<para>The above file defines the net zone as all hosts interfacing to the
firewall through eth0, the loc zone as all hosts interfacing through eth1
and the dmz as all hosts interfacing through eth2.</para>
</section>
<section>
<title>License</title>
<para>This program is free software; you can redistribute it and/or modify
it under the terms of <ulink url="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</ulink> as published by the Free
Software Foundation.</para>
<para>This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more detail.</para>
<para>You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation,
Inc., 675 Mass Ave, Cambridge, MA 02139, USA</para>
</section>
</article>

184
Shorewall-docs2/MAC_Validation.xml Normal file
View File

@ -0,0 +1,184 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="MAC_Validation">
<!--$Id$-->
<articleinfo>
<title>MAC Verification</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-06</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>All traffic from an interface or from a subnet on an interface can be
verified to originate from a defined set of MAC addresses. Furthermore, each
MAC address may be optionally associated with one or more IP addresses.</para>
<important>
<para><emphasis role="bold">MAC addresses are only visible within a
ethernet segment so all MAC addresses used in verification must belong to
devices physically connected to one of the LANs to which your firewall is
connected.</emphasis></para>
</important>
<important>
<para><emphasis role="bold">Your kernel must include MAC match support
(CONFIG_IP_NF_MATCH_MAC - module name ipt_mac.o).</emphasis></para>
</important>
<section>
<title>Components</title>
<para>There are four components to this facility.</para>
<orderedlist>
<listitem>
<para>The <emphasis role="bold">maclist</emphasis> interface option in
<ulink url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.
When this option is specified, all traffic arriving on the interface
is subjet to MAC verification.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">maclist</emphasis> option in <ulink
url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink>. When this
option is specified for a subnet, all traffic from that subnet is
subject to MAC verification.</para>
</listitem>
<listitem>
<para>The /etc/shorewall/maclist file. This file is used to associate
MAC addresses with interfaces and to optionally associate IP addresses
with MAC addresses.</para>
</listitem>
<listitem>
<para>The <emphasis role="bold">MACLIST_DISPOSITION</emphasis> and
<emphasis role="bold">MACLIST_LOG_LEVEL</emphasis> variables in <ulink
url="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</ulink>.
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
and determines the disposition of connection requests that fail MAC
verification. The MACLIST_LOG_LEVEL variable gives the syslogd level
at which connection requests that fail verification are to be logged.
If set the the empty value (e.g., MACLIST_LOG_LEVEL=&#34;&#34;) then
failing connection requests are not logged.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>/etc/shorewall/maclist</title>
<para>The columns in /etc/shorewall/maclist are:</para>
<variablelist>
<varlistentry>
<term>INTERFACE</term>
<listitem>
<para>The name of an ethernet interface on the Shorewall system.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>MAC</term>
<listitem>
<para>The MAC address of a device on the ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in
this column although you may use that format if you so choose.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>IP Address</term>
<listitem>
<para>An optional comma-separated list of IP addresses for the
device whose MAC is listed in the MAC column.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section>
<title>Examples</title>
<example>
<title>Here are my files (look <ulink url="myfiles.htm">here</ulink> for
details about my setup)</title>
<para>/etc/shorewall/shorewall.conf:</para>
<programlisting>MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info</programlisting>
<para>/etc/shorewall/interfaces:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
loc eth2 192.168.1.255 dhcp
dmz eth1 192.168.2.255
WiFi eth3 192.168.3.255 dhcp,maclist
- texas 192.168.9.255</programlisting>
<para>/etc/shorewall/maclist:</para>
<programlisting>#INTERFACE MAC IP ADDRESSES (Optional)
eth3 00:A0:CC:A2:0C:A0 192.168.3.7 #Work Laptop
eth3 00:04:5a:fe:85:b9 192.168.3.250 #WAP11
eth3 00:06:25:56:33:3c 192.168.3.225,192.168.3.8 #WET11
eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIPPER</programlisting>
<para>As shown above, I use MAC Verification on my wireless zone.</para>
<para><note><para>While marketed as a wireless bridge, the WET11 behaves
like a wireless router with DHCP relay. When forwarding DHCP traffic, it
uses the MAC address of the host (TIPPER) but for other forwarded
traffic it uses it&#39;s own MAC address. Consequently, I list the IP
addresses of both devices in /etc/shorewall/maclist.</para></note></para>
</example>
<example>
<title>Router in Wireless Zone</title>
<para>Suppose now that I add a second wireless segment to my wireless
zone and gateway that segment via a router with MAC address
00:06:43:45:C6:15 and IP address 192.168.3.253. Hosts in the second
segment have IP addresses in the subnet 192.168.4.0/24. I would add the
following entry to my /etc/shorewall/maclist file:</para>
<programlisting>eth3 00:06:43:45:C6:15 192.168.3.253,192.168.4.0/24</programlisting>
<para>This entry accomodates traffic from the router itself
(192.168.3.253) and from the second wireless segment (192.168.4.0/24).
Remember that all traffic being sent to my firewall from the
192.168.4.0/24 segment will be forwarded by the router so that
traffic&#39;s MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.</para>
</example>
</section>
</article>

330
Shorewall-docs2/Multiple_Zones.xml Normal file
View File

@ -0,0 +1,330 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Multiple_Zones">
<!--$Id$-->
<articleinfo>
<title>Routing on One Interface</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-07</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Introduction</title>
<para>While most configurations can be handled with each of the
firewall&#39;s network interfaces assigned to a single zone, there are
cases where you will want to divide the hosts accessed through an
interface between two or more zones.</para>
<itemizedlist>
<listitem>
<para>The interface has multiple addresses on multiple subnetworks.
This case is covered in the <ulink
url="Shorewall_and_Aliased_Interfaces.html">Aliased Interface
documentation</ulink>.</para>
</listitem>
<listitem>
<para>You are using some form of NAT and want to access a server by
its external IP address from the same LAN segment. This is covered in
<ulink url="FAQ.htm#faq2">FAQs 2 and 2a</ulink>.</para>
</listitem>
<listitem>
<para>There are routers accessible through the interface and you want
to treat the networks accessed through that router as a separate zone.</para>
</listitem>
<listitem>
<para>Some of the hosts accessed through an interface have
significantly different firewalling requirements from the others so
you want to assign them to a different zone.</para>
</listitem>
</itemizedlist>
<para>The key points to keep in mind when setting up multiple zones per
interface are:</para>
<itemizedlist>
<listitem>
<para>Shorewall generates rules for zones in the order that the zone
declarations appear in /etc/shorewall/zones.</para>
</listitem>
<listitem>
<para>The order of entries in /etc/shorewall/hosts is immaterial as
far as the generated ruleset is concerned.</para>
</listitem>
</itemizedlist>
<para><emphasis role="bold">These examples use the local zone but the same
technique works for any zone.</emphasis> Remember that Shorewall
doesn&#39;t have any conceptual knowledge of <quote>Internet</quote>,
<quote>Local</quote>, or <quote>DMZ</quote> so all zones except the
firewall itself ($FW) are the same as far as Shorewall is concerned. Also,
the examples use private (RFC 1918) addresses but public IP addresses can
be used in exactly the same way.</para>
</section>
<section>
<title>Router in the Local Zone</title>
<para>Here is an example of a router in the local zone.</para>
<note>
<para>the <emphasis role="bold">box called <quote>Router</quote> could
be a VPN server</emphasis> or other such device; from the point of view
of this discussion, it makes no difference.</para>
</note>
<graphic fileref="images/MultiZone1.png" />
<section>
<title>Can You Use the Standard Configuration?</title>
<para>In many cases, the <ulink url="two-interface.htm">standard
two-interface Shorewall setup</ulink> will work fine in this
configuration. It will work if:</para>
<itemizedlist>
<listitem>
<para>The firewall requirements to/from the internet are the same
for 192.168.1.0/24 and 192.168.2.0/24.</para>
</listitem>
<listitem>
<para>The hosts in 192.168.1.0/24 know that the route to
192.168.2.0/24 is through the <emphasis role="bold">router</emphasis>.</para>
</listitem>
</itemizedlist>
<para>All you have to do on the firewall is add a route to
192.168.2.0/24 through the <emphasis role="bold">router</emphasis> and
restart Shorewall.</para>
</section>
<section>
<title>Will One Zone be Enough?</title>
<para>If the firewalling requirements for the two local networks is the
same but the hosts in 192.168.1.0/24 don&#39;t know how to route to
192.168.2.0/24 then you need to configure the firewall slightly
differently. This type of configuration is rather stupid from an IP
networking point of view but it is sometimes necessary because you
simply don&#39;t want to have to reconfigure all of the hosts in
192.168.1.0/24 to add a persistent route to 192.168.2.0/24. On the
firewall:</para>
<orderedlist>
<listitem>
<para>Add a route to 192.168.2.0/24 through the <emphasis
role="bold">Router</emphasis>.</para>
</listitem>
<listitem>
<para>Set the <quote>routeback</quote> and <quote>newnotsyn</quote>
options for eth1 (the local firewall interface) in
/etc/shorewall/interfaces.</para>
</listitem>
<listitem>
<para>Restart Shorewall.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>I Need Separate Zones</title>
<para>If you need to make 192.168.2.0/24 into it&#39;s own zone, you can
do it one of two ways; Nested Zones or Parallel Zones.</para>
<section>
<title>Nested Zones</title>
<para>You can define one zone (called it <quote>loc</quote>) as being
all hosts connectied to eth1 and a second zone <quote>loc1</quote>
(192.168.2.0/24) as a sub-zone.</para>
<graphic fileref="images/MultiZone1A.png" />
<para>The advantage of this approach is that the zone <quote>loc1</quote>
can use CONTINUE policies such that if a connection request
doesn&#39;t match a <quote>loc1</quote> rule, it will be matched
against the <quote>loc</quote> rules. For example, if your
loc1-&#62;net policy is CONTINUE then if a connection request from
loc1 to the internet doesn&#39;t match any rules for loc1-&#62;net
then it will be checked against the loc-&#62;net rules.</para>
<para><filename>/etc/shorewall/zones</filename></para>
<programlisting>#ZONE DISPLAY COMMENTS
loc1 Local1 Hosts accessed through internal router
loc Local All hosts accessed via eth1</programlisting>
<note>
<para>the sub-zone (loc1) is defined first!</para>
</note>
<para><filename>/etc/shorewall/interfaces</filename></para>
<programlisting>#ZONE INTERFACE BROADCAST
loc eth1 192.168.1.255</programlisting>
<para><filename>/etc/shorewall/hosts</filename></para>
<programlisting>#ZONE HOSTS
loc1 eth1:192.168.2.0/24</programlisting>
<para>If you don&#39;t need Shorewall to set up infrastructure to
route traffic between <quote>loc</quote> and <quote>loc1</quote>, add
these two policies.</para>
<para>/etc/shorewall/policy</para>
<programlisting>#SOURCE DEST POLICY
loc loc1 NONE
loc1 loc NONE</programlisting>
</section>
<section>
<title>Parallel Zones</title>
<para>You define both zones in the /etc/shorewall/hosts file to create
two disjoint zones.</para>
<graphic fileref="images/MultiZone1B.png" />
<para><filename>/etc/shorewall/zones</filename></para>
<programlisting>#ZONE DISPLAY COMMENTS
loc1 Local1 Hosts accessed Directly from Firewall
loc2 Local2 Hosts accessed via the internal Router</programlisting>
<note>
<para>Here it doesn&#39;t matter which zone is defined first.</para>
</note>
<para><filename>/etc/shorewall/interfaces</filename></para>
<programlisting>#ZONE INTERFACE BROADCAST
- eth1 192.168.1.255</programlisting>
<para><filename>/etc/shorewall/hosts</filename></para>
<programlisting>#ZONE HOSTS
loc1 eth1:192.168.1.0/24
loc2 eth1:192.168.2.0/24</programlisting>
<para>You don&#39;t need Shorewall to set up infrastructure to route
traffic between <quote>loc</quote> and <quote>loc1</quote>, so add
these two policies:</para>
<programlisting>#SOURCE DEST POLICY
loc1 loc2 NONE
loc2 loc1 NONE</programlisting>
</section>
</section>
</section>
<section>
<title>Some Hosts have Special Firewalling Requirements</title>
<para>There are cases where a subset of the addresses associated with an
interface need special handling. Here&#39;s an example.</para>
<graphic fileref="images/MultiZone2.png" />
<para>In this example, addresses 192.168.1.8 - 192.168.1.15
(192.168.1.8/29) are to be treated as their own zone (loc1).</para>
<para><filename>/etc/shorewall/zones</filename></para>
<programlisting>#ZONE DISPLAY COMMENTS
loc1 Local1 192.168.1.8-192.168.1.15
loc Local All hosts accessed via eth1</programlisting>
<note>
<para>the sub-zone (loc1) is defined first!</para>
</note>
<para><filename>/etc/shorewall/interfaces</filename></para>
<programlisting>#ZONE INTERFACE BROADCAST
loc eth1 192.168.1.255</programlisting>
<para><filename>/etc/shorewall/hosts</filename><programlisting>#ZONE HOSTS
loc1 eth1:192.168.1.8/29</programlisting></para>
<para>You probably don&#39;t want Shorewall to set up infrastructure to
route traffic between <quote>loc</quote> and <quote>loc1</quote> so you
should add these two policies.</para>
<para><filename>/etc/shorewall/policy</filename></para>
<programlisting>#SOURCE DEST POLICY
loc loc1 NONE
loc1 loc NONE</programlisting>
</section>
<section id="OneArmed">
<title>One-armed Router</title>
<para>Nested zones may also be used to configure a <quote>one-armed</quote>
router (I don&#39;t call it a <quote>firewall</quote> because it is very
insecure. For example, if you connect to the internet via cable modem,
your next door neighbor has full access to your local systems as does
everyone else connected to the same cable modem head-end controller). Here
eth0 is configured with both a public IP address and an RFC 1918 address
(More on that topic may be found <ulink
url="Shorewall_and_Aliased_Interfaces.html">here</ulink>). Hosts in the
<quote>loc</quote> zone are configured with their default gateway set to
the Shorewall router&#39;s RFC1918 address.<graphic
fileref="images/MultiZone3.png" /></para>
<para><filename>/etc/shorewall/zones</filename></para>
<programlisting>#ZONE DISPLAY COMMENTS
loc Local Local Zone
net Internet The big bad Internet</programlisting>
<note>
<para>the sub-zone (loc) is defined first!</para>
</note>
<para><filename>/etc/shorewall/interfaces</filename></para>
<programlisting>#ZONE INTERFACE BROADCAST
net eth0 detect</programlisting>
<para><filename>/etc/shorewall/hosts</filename></para>
<programlisting>#ZONE HOSTS
loc eth0:192.168.1.0/24</programlisting>
</section>
</article>

111
Shorewall-docs2/NAT.xml Normal file
View File

@ -0,0 +1,111 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="NAT">
<!--$Id$-->
<articleinfo>
<title>One-to-one NAT</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-04</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>One-to-one NAT</title>
<important>
<para><emphasis role="bold">If all you want to do is forward ports to
servers behind your firewall, you do NOT want to use one-to-one NAT.
Port forwarding can be accomplished with simple entries in the <ulink
url="Documentation.htm#Rules">rules file</ulink>.</emphasis></para>
</important>
<para>One-to-one NAT is a way to make systems behind a firewall and
configured with private IP addresses (those reserved for private use in
RFC 1918) appear to have public IP addresses. Before you try to use this
technique, I strongly recommend that you read the <ulink
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>.</para>
<para>The following figure represents a one-to-one NAT environment.</para>
<graphic fileref="images/staticnat.png" />
<para>One-to-one NAT can be used to make the systems with the 10.1.1.*
addresses appear to be on the upper (130.252.100.*) subnet. If we assume
that the interface to the upper subnet is eth0, then the following
/etc/shorewall/NAT file would make the lower left-hand system appear to
have IP address 130.252.100.18 and the right-hand one to have IP address
130.252.100.19.</para>
<para><filename>/etc/shorewall/nat</filename><programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
130.252.100.18 eth0 10.1.1.2 no no
130.252.100.19 eth0 10.1.1.3 no no</programlisting></para>
<para>Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the
above example) is (are) not included in any specification in
/etc/shorewall/masq or /etc/shorewall/proxyarp.</para>
<note>
<para>The <quote>ALL INTERFACES</quote> column is used to specify
whether access to the external IP from all firewall interfaces should
undergo NAT (Yes or yes) or if only access from the interface in the
INTERFACE column should undergo NAT. If you leave this column empty,
<quote>No</quote> is assumed (Shorewall 2.0.0 and later -- prior to
this, <quote>Yes</quote> was assumed). <emphasis role="bold">Specifying
<quote>Yes</quote> in this column will not allow systems on the lower
LAN to access each other using their public IP addresses.</emphasis> For
example, the lower left-hand system (10.1.1.2) cannot connect to
130.252.100.19 and expect to be connected to the lower right-hand
system. <ulink url="FAQ.htm#faq2a">See FAQ 2a</ulink>.</para>
</note>
<note>
<para>Shorewall will automatically add the external address to the
specified interface unless you specify <ulink
url="Documentation.htm#Aliases">ADD_IP_ALIASES</ulink>=<quote>no</quote>
(or <quote>No</quote>) in /etc/shorewall/shorewall.conf; If you do not
set ADD_IP_ALIASES or if you set it to <quote>Yes</quote> or
<quote>yes</quote> then you must NOT configure your own alias(es).</para>
<para><important><para>Shorewall versions earlier than 1.4.6 can only
add external addresses to an interface that is configured with a single
subnetwork -- if your external interface has addresses in more than one
subnetwork, Shorewall 1.4.5 and earlier can only add addresses to the
first one.</para></important></para>
</note>
<note>
<para>The contents of the <quote>LOCAL</quote> column determine whether
packets originating on the firewall itself and destined for the EXTERNAL
address are redirected to the internal ADDRESS. If this column contains
<quote>yes</quote> or <quote>Yes</quote> (and the ALL INTERFACES COLUMN
also contains <quote>Yes</quote> or <quote>yes</quote>) then such
packets are redirected; otherwise, such packets are not redirected. This
feature requires kernel 2.4.19 or later and iptables 1.2.6a or later and
you must have enabled CONFIG_IP_NF_NAT_LOCAL in your kernel.</para>
</note>
</section>
</article>

223
Shorewall-docs2/NetfilterOverview.xml Normal file
View File

@ -0,0 +1,223 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="NetfilterOverview">
<!--$Id$-->
<articleinfo>
<title>Netfilter Overview</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-10-14</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Netfilter Overview</title>
<para>Netfilter consists of three tables: <emphasis role="bold">Filter</emphasis>,
<emphasis role="bold">Nat</emphasis> and <emphasis role="bold">Mangle</emphasis>.
Each table has a number of build-in chains: <emphasis role="bold">PREROUTING</emphasis>,
<emphasis role="bold">INPUT</emphasis>, <emphasis role="bold">FORWARD</emphasis>,
<emphasis role="bold">OUTPUT</emphasis> and <emphasis role="bold">POSTROUTING</emphasis>.</para>
<para>Rules in the various tables are used as follows:</para>
<variablelist>
<varlistentry>
<term>Filter</term>
<listitem>
<para>Packet filtering (rejecting, dropping or accepting packets)</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Nat</term>
<listitem>
<para>Network Address Translation including DNAT, SNAT and
Masquerading</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Mangle</term>
<listitem>
<para>General packet header modification such as setting the TOS
value or marking packets for policy routing and traffic shaping.</para>
</listitem>
</varlistentry>
</variablelist>
<para>The following diagram shows how packets traverse the various builtin
chains within Netfilter. Note that not all table/chain combinations are
used.</para>
<graphic fileref="images/Netfilter.png" />
<para><quote>Local Process</quote> means a process running on the
Shorewall system itself.</para>
<para>In the above diagram are boxes similar to this:</para>
<graphic fileref="images/Legend.png" />
<para>The above box gives the name of the built-in chain (<emphasis
role="bold">INPUT</emphasis>) along with the names of the tables (<emphasis
role="bold">Mangle</emphasis> and <emphasis role="bold">Filter</emphasis>)
that the chain exists in and in the order that the chains are traversed.
The above sample indicates that packets go first through the <emphasis
role="bold">INPUT</emphasis> chain of the <emphasis role="bold">Mangle</emphasis>
table then through the <emphasis role="bold">INPUT</emphasis> chain of the
<emphasis role="bold">Filter</emphasis> table. When a chain is enclosed in
parentheses, Shorewall does not use the named chain (<emphasis role="bold">INPUT</emphasis>)
in that table (<emphasis role="bold">Mangle</emphasis>).</para>
<important>
<para>Keep in mind that chains in the <emphasis role="bold">Nat</emphasis>
table are <emphasis role="bold">only traversed for new connection
requests</emphasis> (including those related to existing connections)
while the chains in the other tables are traversed on every packet.</para>
</important>
<para>The above diagram should help you understand the output of
<quote>shorewall status</quote>.</para>
<para>Here are some excerpts from <quote>shorewall status</quote> on a
server with one interface (eth0):</para>
<programlisting>[root@lists html]# shorewall status
Shorewall-1.4.7 Status at lists.shorewall.net - Mon Oct 13 12:51:13 PDT 2003
Counters reset Sat Oct 11 08:12:57 PDT 2003</programlisting>
<para>The first table shown is the <emphasis role="bold">Filter</emphasis>
table.</para>
<programlisting>Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
785K 93M accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID</programlisting>
<para>The following rule indicates that all traffic destined for the
firewall that comes into the firewall on eth0 is passed to a chain called
<quote>eth0_in</quote>. That chain will be shown further down.</para>
<programlisting> 785K 93M eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:&#39;
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:&#39;
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
922K 618M accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
922K 618M fw2net all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:OUTPUT:REJECT:&#39;
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0</programlisting>
<para>Here is the eth0_in chain:</para>
<programlisting>Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
785K 93M dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
785K 93M net2fw all -- * * 0.0.0.0/0 0.0.0.0/0</programlisting>
<para>The <quote>dynamic</quote> chain above is where dynamic blacklisting
is done.</para>
<para>Next comes the <emphasis role="bold">Nat</emphasis> table:</para>
<programlisting>NAT Table
Chain PREROUTING (policy ACCEPT 182K packets, 12M bytes)
pkts bytes target prot opt in out source destination
20005 1314K net_dnat all -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain net_dnat (1 references)
pkts bytes target prot opt in out source destination
638 32968 REDIRECT tcp -- * * 0.0.0.0/0 !206.124.146.177 tcp dpt:80 redir ports 3128
</programlisting>
<para>And finally, the <emphasis role="bold">Mangle</emphasis> table:</para>
<programlisting>Mangle Table
Chain PREROUTING (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
1464K 275M pretos all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
1601K 800M outtos all -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
Chain outtos (1 references)
pkts bytes target prot opt in out source destination
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 TOS set 0x10
315K 311M TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 TOS set 0x10
683 59143 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 TOS set 0x10
3667 5357K TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 TOS set 0x08
Chain pretos (1 references)
pkts bytes target prot opt in out source destination
271K 15M TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 TOS set 0x10
730 41538 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 TOS set 0x08
2065 111K TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 TOS set 0x08</programlisting>
</section>
</article>

340
Shorewall-docs2/OPENVPN.xml Normal file
View File

@ -0,0 +1,340 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="OPENVPN">
<!--$Id$-->
<articleinfo>
<title>OpenVPN Tunnels</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
<author>
<firstname>Simon</firstname>
<surname>Mater</surname>
</author>
</authorgroup>
<pubdate>2003-02-04</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
<holder>Simon Mater</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>OpenVPN is a robust and highly configurable VPN (Virtual Private
Network) daemon which can be used to securely link two or more private
networks using an encrypted tunnel over the internet. OpenVPN is an Open
Source project and is <ulink
url="http://openvpn.sourceforge.net/license.html">licensed under the GPL</ulink>.
OpenVPN can be downloaded from <ulink url="http://openvpn.sourceforge.net/">http://openvpn.sourceforge.net/</ulink>.</para>
<para>OpenVPN support was added to Shorewall in version 1.3.14.</para>
<section>
<title>Bridging two Masqueraded Networks</title>
<para>Suppose that we have the following situation:</para>
<graphic fileref="images/TwoNets1.png" />
<para>We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is
accomplished through use of the /etc/shorewall/tunnels file and the
/etc/shorewall/policy file and OpenVPN.</para>
<para>While it was possible to use the Shorewall start and stop script to
start and stop OpenVPN, I decided to use the init script of OpenVPN to
start and stop it.</para>
<para>On each firewall, you will need to declare a zone to represent the
remote subnet. We&#39;ll assume that this zone is called <quote>vpn</quote>
and declare it in /etc/shorewall/zones on both systems as follows.</para>
<table>
<title>/etc/shorewall/zones system A &#38; B</title>
<tgroup cols="3">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">DISPLAY</entry>
<entry align="center">COMMENTS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>VPN</entry>
<entry>Remote Subnet</entry>
</row>
</tbody>
</tgroup>
</table>
<para>On system A, the 10.0.0.0/8 will comprise the <emphasis role="bold">vpn</emphasis>
zone. In /etc/shorewall/interfaces:</para>
<table>
<title>etc/shorewall/interfaces system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tun0</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on system A, we need the following:</para>
<table>
<title>/etc/shorewall/tunnels system A</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>openvpn</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>This entry in /etc/shorewall/tunnels opens the firewall so that
OpenVPN traffic on the default port 5000/udp will be accepted to/from the
remote gateway. If you change the port used by OpenVPN to 7777, you can
define /etc/shorewall/tunnels like this:</para>
<table>
<title>/etc/shorewall/tunnels port 7777</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>openvpn:7777</entry>
<entry>net</entry>
<entry>134.28.54.2</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>This is the OpenVPN config on system A:</para>
<programlisting>dev tun
local 206.162.148.9
remote 134.28.54.2
ifconfig 192.168.99.1 192.168.99.2
up ./route-a.up
tls-server
dh dh1024.pem
ca ca.crt
cert my-a.crt
key my-a.key
comp-lzo
verb 5</programlisting>
<para>Similarly, On system B the 192.168.1.0/24 subnet will comprise the
<emphasis role="bold">vpn</emphasis> zone. In /etc/shorewall/interfaces:</para>
<table>
<title>/etc/shorewall/interfaces system B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">ZONE</entry>
<entry align="center">INTERFACE</entry>
<entry align="center">BROADCAST</entry>
<entry align="center">OPTIONS</entry>
</row>
</thead>
<tbody>
<row>
<entry>vpn</entry>
<entry>tun0</entry>
<entry>192.168.1.255</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>In /etc/shorewall/tunnels on system B, we have:</para>
<table>
<title>/etc/shorewall/tunnels system B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">TYPE</entry>
<entry align="center">ZONE</entry>
<entry align="center">GATEWAY</entry>
<entry align="center">GATEWAY ZONE</entry>
</row>
</thead>
<tbody>
<row>
<entry>openvpn</entry>
<entry>net</entry>
<entry>206.191.148.9</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>And in the OpenVPN config on system B:</para>
<programlisting>dev tun
local 134.28.54.2
remote 206.162.148.9
ifconfig 192.168.99.2 192.168.99.1
up ./route-b.up
tls-client
ca ca.crt
cert my-b.crt
key my-b.key
comp-lzo
verb 5</programlisting>
<para>You will need to allow traffic between the <quote>vpn</quote> zone
and the <quote>loc</quote> zone on both systems -- if you simply want to
admit all traffic in both directions, you can use the policy file:</para>
<table>
<title>/etc/shorewall/policy system A &#38; B</title>
<tgroup cols="4">
<thead>
<row>
<entry align="center">SOURCE</entry>
<entry align="center">DEST</entry>
<entry align="center">POLICY</entry>
<entry align="center">LOG LEVEL</entry>
</row>
</thead>
<tbody>
<row>
<entry>loc</entry>
<entry>vpn</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
<row>
<entry>vpn</entry>
<entry>loc</entry>
<entry>ACCEPT</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>On both systems, restart Shorewall and start OpenVPN. The systems in
the two masqueraded subnetworks can now talk to each other.</para>
</section>
</article>

1428
Shorewall-docs2/PPTP.xml Normal file
View File

File diff suppressed because it is too large Load Diff

192
Shorewall-docs2/ProxyARP.xml Normal file
View File

@ -0,0 +1,192 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="ProxyARP">
<!--$Id$-->
<articleinfo>
<title>Proxy ARP</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-14</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>Proxy ARP allows you to insert a firewall in front of a set of servers
without changing their IP addresses and without having to re-subnet. Before
you try to use this technique, I strongly recommend that you read the <ulink
url="shorewall_setup_guide.htm">Shorewall Setup Guide</ulink>.</para>
<section>
<title>Example</title>
<para>The following figure represents a Proxy ARP environment.</para>
<graphic fileref="images/proxyarp.png" />
<para>Proxy ARP can be used to make the systems with addresses
130.252.100.18 and 130.252.100.19 appear to be on the upper
(130.252.100.*) subnet. Assuming that the upper firewall interface is eth0
and the lower interface is eth1, this is accomplished using the following
entries in <filename>/etc/shorewall/proxyarp</filename>:</para>
<programlisting>#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
130.252.100.18 eth1 eth0 no yes
130.252.100.19 eth1 eth0 no yes </programlisting>
<para>Be sure that the internal systems (130.242.100.18 and 130.252.100.19
in the above example) are not included in any specification in
<filename>/etc/shorewall/masq</filename> or <filename>/etc/shorewall/nat</filename>.</para>
<note>
<para>I&#39;ve used an RFC1918 IP address for eth1 - that IP address is
largely irrelevant (see below).</para>
</note>
<para>The lower systems (130.252.100.18 and 130.252.100.19) should have
their subnet mask and default gateway configured exactly the same way that
the Firewall system&#39;s eth0 is configured. In other words, they should
be configured just like they would be if they were parallel to the
firewall rather than behind it.</para>
<warning>
<para>Do not add the Proxy ARP&#39;ed address(es) (130.252.100.18 and
130.252.100.19 in the above example) to the external interface (eth0 in
this example) of the firewall.</para>
</warning>
<para>While the address given to the firewall interface is largely
irrelevant, one approach you can take is to make that address the same as
the address of your external interface!</para>
<graphic align="center" fileref="images/proxyarp1.png" />
<para>It the diagram above, <filename class="devicefile">eth1</filename>
has been given the address 130.252.100.17, the same as
<filename>eth0</filename>. Note though that the VLSM is 32 so there is no
network associated with this address. This is the approach <ulink
url="myfiles.htm">that I take with my DMZ</ulink>.</para>
<warning>
<para>Your distribution&#39;s network configuration GUI may not be
capable of configuring a device in this way. It may complain about the
duplicate address or it may configure the address incorrectly. Here is
what the above configuration should look like when viewed using
<command>ip</command> (the part of the output that is in <emphasis
role="bold">bold text</emphasis> is relevant):</para>
<programlisting>gateway:~# <command>ip addr ls eth1</command>
3: eth1: &#60;BROADCAST,MULTICAST,UP&#62; mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:a0:cc:d1:db:12 brd ff:ff:ff:ff:ff:ff
<emphasis role="bold">inet 130.252.100.17/32 scope global eth1</emphasis>
gateway:~#</programlisting>
<para>Note in particular that there is no broadcast address. <ulink
url="myfiles.htm#Interfaces">Here is how I configure a device in this
way under Debian</ulink>.</para>
</warning>
</section>
<section>
<title>ARP cache</title>
<para>A word of warning is in order here. ISPs typically configure their
routers with a long ARP cache timeout. If you move a system from parallel
to your firewall to behind your firewall with Proxy ARP, it will probably
be HOURS before that system can communicate with the internet. There are a
couple of things that you can try:</para>
<orderedlist>
<listitem>
<para>A reading of <citetitle>TCP/IP Illustrated, Vol 1</citetitle> by
Stevens reveals<footnote><para>Courtesy of Bradey Honsinger</para></footnote>
that a <quote>gratuitous</quote> ARP packet should cause the ISP&#39;s
router to refresh their ARP cache (section 4.7). A gratuitous ARP is
simply a host requesting the MAC address for its own IP; in addition
to ensuring that the IP address isn&#39;t a duplicate...</para>
<blockquote>
<para>if the host sending the gratuitous ARP has just changed its
hardware address..., this packet causes any other host...that has an
entry in its cache for the old hardware address to update its ARP
cache entry accordingly.</para>
</blockquote>
<para>Which is, of course, exactly what you want to do when you switch
a host from being exposed to the Internet to behind Shorewall using
proxy ARP (or one-to-one NAT for that matter). Happily enough, recent
versions of Redhat&#39;s iputils package include <quote>arping</quote>,
whose <quote>-U</quote> flag does just that:</para>
<programlisting>arping -U -I &#60;<emphasis>net if</emphasis>&#62; &#60;<emphasis>newly proxied IP</emphasis>&#62;
arping -U -I eth0 66.58.99.83 # for example</programlisting>
<para>Stevens goes on to mention that not all systems respond
correctly to gratuitous ARPs, but googling for <quote>arping -U</quote>
seems to support the idea that it works most of the time.</para>
<para>To use arping with Proxy ARP in the above example, you would
have to:</para>
<programlisting>shorewall clear
ip addr add 130.252.100.18 dev eth0
ip addr add 130.252.100.19 dev eth0
arping -U -I eth0 130.252.100.18
arping -U -I eth0 130.252.100.19
ip addr del 130.252.100.18 dev eth0
ip addr del 130.252.100.19 dev eth0
shorewall start</programlisting>
</listitem>
<listitem>
<para>You can call your ISP and ask them to purge the stale ARP cache
entry but many either can&#39;t or won&#39;t purge individual entries.</para>
</listitem>
</orderedlist>
<para>You can determine if your ISP&#39;s gateway ARP cache is stale using
ping and tcpdump. Suppose that we suspect that the gateway router has a
stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as
follows:</para>
<programlisting>tcpdump -nei eth0 icmp</programlisting>
<para>Now from 130.252.100.19, ping the ISP&#39;s gateway (which we will
assume is 130.252.100.254):</para>
<programlisting>ping 130.252.100.254</programlisting>
<para>We can now observe the tcpdump output:</para>
<programlisting>13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 &#62; 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 &#62; 130.252.100.177 : icmp: echo reply</programlisting>
<para>Notice that the source MAC address in the echo request is different
from the destination MAC address in the echo reply!! In this case
0:4:e2:20:20:33 was the MAC of the firewall&#39;s eth0 NIC while
0:c0:a8:50:b2:57 was the MAC address of the system on the lower left. In
other words, the gateway&#39;s ARP cache still associates 130.252.100.19
with the NIC in that system rather than with the firewall&#39;s eth0.</para>
</section>
</article>

83
Shorewall-docs2/Shorewall_Doesnt.xml Normal file
View File

@ -0,0 +1,83 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Shorewall_Doesnt">
<!--$Id$-->
<articleinfo>
<title>Some Things that Shorewall Cannot Do</title>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
<pubdate>2003-10-07</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Shorewall Cannot:</title>
<itemizedlist>
<listitem>
<para>Be used to filter traffic through a Layer 2 Bridge</para>
</listitem>
<listitem>
<para>Act as a <quote>Personal Firewall</quote> that allows internet
access by application.</para>
</listitem>
<listitem>
<para>Be used with an Operating System other than Linux (version
&#62;= 2.4.0)</para>
</listitem>
<listitem>
<para>Do content filtering:</para>
<itemizedlist>
<listitem>
<para>HTTP - better to use <ulink url="Shorewall_Squid_Usage.html">Squid</ulink>
for that.</para>
</listitem>
<listitem>
<para>Email -- Install something like <ulink
url="http://www.postfix.org">Postfix</ulink> on your firewall and
integrate it with <ulink url="http://www.spamassassin.org/">SpamAssassin</ulink>
and <ulink url="http://www.ijs.si/software/amavisd/">Amavisd-new</ulink>.</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<section>
<title>In Addition:</title>
<itemizedlist>
<listitem>
<para>Shorewall does not contain any support for Netfilter <ulink
url="http://www.netfilter.org/documentation/pomlist/pom-summary.html">Patch-O-Matic</ulink>
features -- Shorewall only supports features from released kernels.</para>
</listitem>
</itemizedlist>
</section>
</article>

76
Shorewall-docs2/Shorewall_Squid_Usage.html Normal file
View File

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

317
Shorewall-docs2/Shorewall_Squid_Usage.xml Normal file
View File

@ -0,0 +1,317 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Shorewall_Squid_Usage">
<!--$Id$-->
<articleinfo>
<title>Using Shorewall with Squid</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-04</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para></para>
<para>This page covers Shorewall configuration to use with <ulink
url="http://www.squid-cache.org">Squid</ulink> running as a Transparent
Proxy or as a Manual Proxy.</para>
<para>If you are running Shorewall 1.3, please see <ulink
url="1.3/Shorewall_Squid_Usage.html">this documentation</ulink>.</para>
<section>
<title>Squid as a Transparent Proxy</title>
<caution>
<para>Please observe the following general requirements:</para>
<itemizedlist>
<listitem>
<para>In all cases, Squid should be configured to run as a transrent
proxy as described at
http://tldp.org/HOWTO/mini/TransparentProxy.html.</para>
</listitem>
<listitem>
<para>The following instructions mention the files
/etc/shorewall/start and /etc/shorewall/init -- if you don&#39;t
have those files, siimply create them.</para>
</listitem>
<listitem>
<para>When the Squid server is in the DMZ zone or in the local zone,
that zone must be defined ONLY by its interface -- no
/etc/shorewall/hosts file entries. That is because the packets being
routed to the Squid server still have their original destination IP
addresses.</para>
</listitem>
<listitem>
<para>You must have iptables installed on your Squid server.</para>
</listitem>
<listitem>
<para>If you run a Shorewall version earlier than 1.4.6, you must
have NAT and MANGLE enabled in your /etc/shorewall/conf file</para>
<programlisting>NAT_ENABLED=Yes
MANGLE_ENABLED=Yes</programlisting>
</listitem>
</itemizedlist>
</caution>
</section>
<section>
<title>Configurations</title>
<para>Three different configurations are covered:</para>
<simplelist>
<member>Squid (transparent) Running on the Firewall</member>
<member>Squid (transparent) Running in the local Network</member>
<member>Squid (transparent) Running in a DMZ</member>
</simplelist>
<section id="Firewall">
<title>Squid (transparent) Running on the Firewall</title>
<para>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.</para>
<para>In <filename>/etc/shorewall/rules</filename>:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
REDIRECT loc 3228 tcp www - !206.124.146.177
ACCEPT fw net tcp www</programlisting>
<para>There may be a requirement to exclude additional destination hosts
or networks from being redirected. For example, you might also want
requests destined for 130.252.100.0/24 to not be routed to Squid.</para>
<para>If you are running Shorewall version 1.4.5 or later, you may just
add the additional hosts/networks to the ORIGINAL DEST column in your
REDIRECT rule.</para>
<para><filename>/etc/shorewall/rules</filename>:<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
REDIRECT loc 3228 tcp www - !206.124.146.177,130.252.100.0/24</programlisting></para>
<para>If you are running a Shorewall version earlier than 1.4.5, you
must add a manual rule in /etc/shorewall/start:</para>
<programlisting><command>run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN</command></programlisting>
<para>To exclude additional hosts or networks, just add additional
similar rules.</para>
</section>
<section id="Local">
<title>Squid (transparent) Running in the local network</title>
<para>You want to redirect all local www connection requests to a Squid
transparent proxy running in your local zone at 192.168.1.3 and
listening on port 3128. Your local interface is eth1. There may also be
a web server running on 192.168.1.3. It is assumed that web access is
already enabled from the local zone to the internet..</para>
<orderedlist>
<listitem>
<para>* On your firewall system, issue the following command</para>
<programlisting><command>echo 202 www.out &#62;&#62; /etc/iproute2/rt_tables</command></programlisting>
</listitem>
<listitem>
<para>In /etc/shorewall/init, put:</para>
<programlisting><command>if [ -z &#34;`ip rule list | grep www.out`&#34; ] ; then
ip rule add fwmark 202 table www.out
ip route add default via 192.168.1.3 dev eth1 table www.out
ip route flush cache
echo 0 &#62; /proc/sys/net/ipv4/conf/eth1/send_redirects
fi</command></programlisting>
</listitem>
<listitem>
<important>
<para>If you are running Shorewall 1.4.1 or Shorewall 1.4.1a,
please upgrade to Shorewall 1.4.2 or later.</para>
</important>
<para>If you are running Shorewall 1.4.2 or later, then in
<filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect <emphasis role="bold">routeback</emphasis> </programlisting>
</listitem>
<listitem>
<para>In /etc/shorewall/rules:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc loc tcp www</programlisting>
<orderedlist numeration="loweralpha">
<listitem>
<para>Alternativfely, if you are running Shorewall 1.4.0 you can
have the following policy in place of the above rule.</para>
<para><filename>/etc/shorewall/policy</filename></para>
<programlisting>#SOURCE DESTINATION POLICY
loc loc ACCEPT</programlisting>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>In <filename>/etc/shorewall/start</filename> add:</para>
<programlisting><command>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</command></programlisting>
</listitem>
<listitem>
<para>On 192.168.1.3, arrange for the following command to be
executed after networking has come up</para>
<programlisting><command>iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128</command></programlisting>
<para>If you are running RedHat on the server, you can simply
execute the following commands after you have typed the iptables
command above:</para>
<programlisting><command>iptables-save &#62; /etc/sysconfig/iptables
chkconfig --level 35 iptables on</command></programlisting>
</listitem>
</orderedlist>
</section>
<section id="DMZ">
<title>Squid (transparent) Running in the DMZ</title>
<para>You have a single Linux system in your DMZ with IP address
192.0.2.177. You want to run both a web server and Squid on that system.
Your DMZ interface is eth1 and your local interface is eth2.</para>
<orderedlist>
<listitem>
<para>On your firewall system, issue the following command</para>
<programlisting><command>echo 202 www.out &#62;&#62; /etc/iproute2/rt_tables</command></programlisting>
</listitem>
<listitem>
<para>In /etc/shorewall/init, put:</para>
<programlisting><command>if [ -z &#34;`ip rule list | grep www.out`&#34; ] ; then
ip rule add fwmark 202 table www.out
ip route add default via 192.0.2.177 dev eth1 table www.out
ip route flush cache
fi</command></programlisting>
</listitem>
<listitem>
<para>Do <emphasis role="bold">one</emphasis> of the following:</para>
<orderedlist numeration="loweralpha">
<listitem>
<para>In <filename>/etc/shorewall/start</filename> add</para>
<programlisting><command>iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</command></programlisting>
</listitem>
<listitem>
<para>Set MARK_IN_FORWARD_CHAIN=No in <filename>/etc/shorewall/shorewall.conf</filename>
and add the following entry in <filename>/etc/shorewall/tcrules</filename>:</para>
<programlisting>#MARK SOURCE DESTINATION PROTOCOL PORT
202 eth2 0.0.0.0 tcp 80</programlisting>
</listitem>
<listitem>
<para>Run Shorewall 1.3.14 or later and add the following entry
in <filename>/etc/shorewall/tcrules</filename>:</para>
<programlisting>#MARK SOURCE DESTINATION PROTOCOL PORT
202:P eth2 0.0.0.0 tcp 80</programlisting>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>In <filename>/etc/shorewall/rules</filename>, you will need:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc dmz tcp 80
ACCEPT dmz net tcp 80</programlisting>
</listitem>
<listitem>
<para>On 192.0.2.177 (your Web/Squid server), arrange for the
following command to be executed after networking has come up</para>
<programlisting><command>iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</command></programlisting>
<para>If you are running RedHat on the server, you can simply
execute the following commands after you have typed the iptables
command above:</para>
<programlisting><command>iptables-save &#62; /etc/sysconfig/iptables
chkconfig --level 35 iptables on</command></programlisting>
</listitem>
</orderedlist>
</section>
</section>
<section>
<title>Squid as a Manual Proxy</title>
<para>Assume that Squid is running in zone SZ and listening on port SP;
all web sites that are to be accessed through Squid are in the
<quote>net</quote> zone. Then for each zone Z that needs access to the
Squid server.</para>
<para><filename>/etc/shorewall/rules</filename>:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT Z SZ tcp SP
ACCEPT SZ net tcp 80</programlisting>
<example>
<title>Squid on the firewall listening on port 8080 with access from the
<quote>loc</quote> zone:</title>
<para><filename>/etc/shorewall/rules:</filename><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc fw tcp 8080
ACCEPT fw net tcp 80</programlisting></para>
</example>
</section>
</article>

307
Shorewall-docs2/Shorewall_and_Aliased_Interfaces.xml Normal file
View File

@ -0,0 +1,307 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Shorewall_and_Aliased_Interfaces">
<!--$Id$-->
<articleinfo>
<title>Shorewall and Aliased Interfaces</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-04</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Background</title>
<para>The traditional net-tools contain a program called
<emphasis>ifconfig</emphasis> which is used to configure network devices.
ifconfig introduced the concept of <emphasis>aliased</emphasis> or
<emphasis>virtual</emphasis> interfaces. These virtual interfaces have
names of the form <emphasis>interface:integer</emphasis> (e.g., <filename
class="devicefile">eth0:0</filename>) and ifconfig treats them more or
less like real interfaces.</para>
<example>
<title>ifconfig</title>
<programlisting>[root@gateway root]# <command>ifconfig eth0:0</command>
eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55
inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0x2000
[root@gateway root]# </programlisting>
</example>
<para>The ifconfig utility is being gradually phased out in favor of the
ip utility which is part of the <emphasis>iproute</emphasis> package. The
ip utility does not use the concept of aliases or virtual interfaces but
rather treats additional addresses on an interface as objects in their own
right. The ip utility does provide for interaction with ifconfig in that
it allows addresses to be <emphasis>labeled</emphasis> where these labels
take the form of ipconfig virtual interfaces.</para>
<example>
<title>ip</title>
<programlisting>[root@gateway root]# <command>ip addr show dev eth0</command>
2: eth0: &#60;BROADCAST,MULTICAST,UP&#62; mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
[root@gateway root]# </programlisting>
<para><note><para>One <emphasis role="bold">cannot</emphasis> type
<quote><command>ip addr show dev eth0:0</command></quote> because
<quote><filename class="devicefile">eth0:0</filename></quote> is a label
for a particular address rather than a device name.</para><programlisting>[root@gateway root]# <command>ip addr show dev eth0:0</command>
Device &#34;eth0:0&#34; does not exist.
[root@gateway root]#</programlisting></note></para>
</example>
<para>The iptables program doesn&#39;t support virtual interfaces in
either it&#39;s <quote>-i</quote> or <quote>-o</quote> command options; as
a consequence, Shorewall does not allow them to be used in the
/etc/shorewall/interfaces file or anywhere else except as described in the
discussion below.</para>
</section>
<section>
<title>Adding Addresses to Interfaces</title>
<para>Most distributions have a facility for adding additional addresses
to interfaces. If you have already used your distribution&#39;s capability
to add your required addresses, you can skip this section.</para>
<para>Shorewall provides facilities for automatically adding addresses to
interfaces as described in the following section. It is also easy to add
them yourself using the <emphasis role="bold">ip</emphasis> utility. The
above alias was added using:</para>
<programlisting><command>ip addr add 206.124.146.178/24 brd 206.124.146.255 dev eth0 label eth0:0</command></programlisting>
<para>You probably want to arrange to add these addresses when the device
is started rather than placing commands like the above in one of the
Shorewall extension scripts. For example, on RedHat systems, you can place
the commands in /sbin/ifup-local:</para>
<programlisting>#!/bin/sh
case $1 in
eth0)
/sbin/ip addr add 206.124.146.177 dev eth0 label eth0:0
;;
esac</programlisting>
<para>RedHat systems also allow adding such aliases from the network
administration GUI (which only works well if you have a graphical
environment on your firewall).</para>
</section>
<section>
<title>So how do I handle more than one address on an interface?</title>
<para>The answer depends on what you are trying to do with the interfaces.
In the sub-sections that follow, we&#39;ll take a look at common
scenarios.</para>
<section>
<title>Separate Rules</title>
<para>If you need to make a rule for traffic to/from the firewall itself
that only applies to a particular IP address, simply qualify the $FW
zone with the IP address.</para>
<example>
<title>allow SSH from net to eth0:0 above</title>
<para><optional><filename>/etc/shorewall/rules</filename></optional><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net $FW:206.124.146.178 tcp 22</programlisting></para>
</example>
</section>
<section>
<title>DNAT</title>
<para>Suppose that I had set up eth0:0 as above and I wanted to port
forward from that virtual interface to a web server running in my local
zone at 192.168.1.3. That is accomplised by a single rule in the
<filename>/etc/shorewall/rules</filename> file:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT net loc:192.168.1.3 tcp 80 - 206.124.146.178 </programlisting>
</section>
<section>
<title>SNAT</title>
<para>If you wanted to use eth0:0 as the IP address for outbound
connections from your local zone (eth1), then in <filename>/etc/shorewall/masq</filename>:</para>
<programlisting>#INTERFACE SUBNET ADDRESS
eth0 eth1 206.124.146.178</programlisting>
<para>Shorewall can create the alias (additional address) for you if you
set ADD_SNAT_ALIASES=Yes in <filename>/etc/shorewall/shorewall.con</filename>f.
Beginning with Shorewall 1.3.14, Shorewall can actually create the
<quote>label</quote> (virtual interface) so that you can see the created
address using ifconfig. In addition to setting ADD_SNAT_ALIASES=Yes, you
specify the virtual interface name in the INTERFACE column as follows.</para>
<para><filename>/etc/shorewall/masq</filename><programlisting>#INTERFACE SUBNET ADDRESS
eth0:0 eth1 206.124.146.178</programlisting></para>
<para>Shorewall can also set up SNAT to round-robin over a range of IP
addresses. Do do that, you specify a range of IP addresses in the
ADDRESS column. If you specify a label in the INTERFACE column,
Shorewall will use that label for the first address of the range and
will increment the label by one for each subsequent label.</para>
<para><filename>/etc/shorewall/masq</filename><programlisting>#INTERFACE SUBNET ADDRESS
eth0:0 eth1 206.124.146.178-102.124.146.180</programlisting></para>
<para>The above would create three IP addresses:</para>
<programlisting>eth0:0 = 206.124.146.178
eth0:1 = 206.124.146.179
eth0:2 = 206.124.146.180</programlisting>
</section>
<section>
<title>One-to-one NAT</title>
<para>If you wanted to use one-to-one NAT to link <filename
class="devicefile">eth0:0</filename> with local address 192.168.1.3, you
would have the following in <filename>/etc/shorewall/nat</filename>:</para>
<programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0 192.168.1.3 no no</programlisting>
<para>Shorewall can create the alias (additional address) for you if you
set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning with
Shorewall 1.3.14, Shorewall can actually create the <quote>label</quote>
(virtual interface) so that you can see the created address using
ifconfig. In addition to setting ADD_IP_ALIASES=Yes, you specify the
virtual interface name in the INTERFACE column as follows.</para>
<para><filename>/etc/shorewall/nat</filename><programlisting>#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0:0 192.168.1.3 no no</programlisting></para>
<para>In either case, to create rules in <filename>/etc/shorewall/rules</filename>
that pertain only to this NAT pair, you simply qualify the local zone
with the internal IP address.</para>
<example>
<title>You want to allow SSH from the net to 206.124.146.178 a.k.a.
192.168.1.3.</title>
<para><programlisting>#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net loc:192.168.1.3 tcp 22</programlisting></para>
</example>
</section>
<section>
<title>MULTIPLE SUBNETS</title>
<para>Sometimes multiple IP addresses are used because there are
multiple subnetworks configured on a LAN segment. This technique does
not provide for any security between the subnetworks if the users of the
systems have administrative privileges because in that case, the users
can simply manipulate their system&#39;s routing table to bypass your
firewall/router. Nevertheless, there are cases where you simply want to
consider the LAN segment itself as a zone and allow your firewall/router
to route between the two subnetworks.</para>
<example>
<title>Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
eth1:0 is 192.168.20.254. You want to simply route all requests
between the two subnetworks.</title>
<variablelist>
<varlistentry>
<term>If you are running Shorewall 1.4.1 or Later</term>
<listitem>
<para>In <filename>/etc/shorewall/interfaces</filename>:</para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
- eth1 192.168.1.255,192.168.20.255</programlisting>
<para>In /etc<filename>/shorewall/hosts</filename>:</para>
<note>
<para>You do NOT need any entry in /etc/shorewall/policy as
Shorewall 1.4.1 and later releases default to allowing
intra-zone traffic.</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term>If you are running Shorewall 1.4.0 or earlier</term>
<listitem>
<para>See the Shorewall 1.4 documentation.</para>
</listitem>
</varlistentry>
</variablelist>
</example>
<example>
<title>Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
eth1:0 is 192.168.20.254. You want to make these subnetworks into
separate zones and control the access between them (the users of the
systems do not have administrative privileges).</title>
<para>In <filename>/etc/shorewall/zones</filename>:</para>
<programlisting>#ZONE DISPLAY DESCRIPTION
loc Local Local Zone 1
loc2 Local2 Local Zone 2</programlisting>
<para>In <filename>/etc/shorewall/interfaces</filename>:<note
id="multiple_subnets-ex2-n1"><para>If you are running Shorewall 1.3.10
or earlier then you must specify the <emphasis role="bold">multi</emphasis>
option.</para></note></para>
<programlisting>#ZONE INTERFACE BROADCAST OPTIONS
- eth1 192.168.1.255,192.168.20.255 <xref
linkend="multiple_subnets-ex2-n1" /></programlisting>
<para>In <filename>/etc/shorewall/hosts</filename>:</para>
<programlisting>#ZONE HOSTS OPTIONS
loc eth1:192.168.1.0/24
loc2 eth1:192.168.20.0/24</programlisting>
<para>In <filename>/etc/shorewall/rules</filename>, simply specify
ACCEPT rules for the traffic that you want to permit.</para>
</example>
</section>
</section>
</article>

61
Shorewall-docs2/Shorewall_and_Kazaa.xml Normal file
View File

@ -0,0 +1,61 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="Shorewall_and_Kazaa">
<!--$Id$-->
<articleinfo>
<title>Kazaa Filtering</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-04</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>Beginning with Shorewall version 1.4.8, Shorewall can interface to
ftwall. <emphasis role="bold">ftwall</emphasis> is part of the <ulink
url="http://p2pwall.sourceforge.net">p2pwall project</ulink> and is a
user-space filter for applications based on the <quote>Fast Track</quote>
peer to peer protocol. Applications using this protocol include Kazaa,
KazaaLite, iMash and Grokster.</para>
<para>To filter traffic from your <quote>loc</quote> zone with ftwall, you
insert the following rules <emphasis role="bold">near the top</emphasis> of
your /etc/shorewall/rules file (before any ACCEPT rules whose source is the
<quote>loc</quote> zone).</para>
<programlisting> #ACTION SOURCE DEST PROTO
QUEUE loc net tcp
QUEUE loc net udp
QUEUE loc fw udp</programlisting>
<para>Now simply configure ftwall as described in the ftwall documentation
and restart Shorewall.</para>
<tip>
<para>There are ftwall init scripts for use with <trademark>SuSE</trademark>
and <trademark>Debian</trademark> Linux at <ulink
url="http://shorewall.net/pub/shorewall/contrib/ftwall">http://shorewall.net/pub/shorewall/contrib/ftwall</ulink>.</para>
</tip>
</article>

209
Shorewall-docs2/UserSets.xml Normal file
View File

@ -0,0 +1,209 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="UserSets">
<!--$Id$-->
<articleinfo>
<title>Controlling Output Traffic by UID/GID</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2003-09-19</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Overview</title>
<para>This capability was added in Shorewall release 1.4.7.</para>
<para>Netfilter provides the capability to filter packets generated on the
firewall system by User Id and/or Group Id. Shorewall provides two
separate but related ways to use this Netfilter capability:</para>
<itemizedlist>
<listitem>
<para>Shorewall allows you to define collections of users called
<quote><link linkend="UserSet">User Sets</link></quote> and then to
restrict certain rules in /etc/shorewall/rules to a given User Set.</para>
</listitem>
<listitem>
<para>Shorewall also allows you to restrict a given <link
linkend="Rule">rule</link> to a particular user and/or group.</para>
</listitem>
</itemizedlist>
<para>Since only packets created by programs running on the Shorewall box
itself, only rules whose SOURCE is the firewall ($FW) may be restricted
using either of the facilities.</para>
</section>
<section id="UserSet">
<title>User Sets</title>
<para>Given the way that this facility is implemented in Shorewall, it is
not possible to control logging of individual rules using a User Set and
logging is rather specified on the User Set itself.</para>
<para>User Sets are defined in the /etc/shorewall/usersets file. Columns
in that file include:</para>
<variablelist>
<varlistentry>
<term>USERSET</term>
<listitem>
<para>The name of a User Set. Must be a legal shell identifier of no
more than six (6) characters in length.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>REJECT</term>
<listitem>
<para>Log level for connections rejected for this User Set.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ACCEPT</term>
<listitem>
<para>Log level for connections accepted for this User Set.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>DROP</term>
<listitem>
<para>Log level for connections dropped for this User Set.</para>
</listitem>
</varlistentry>
</variablelist>
<para>In the REJECT and ACCEPT columns, if you don&#39;t want to specify a
value in the column but you want to specify a value in a following column,
you may enter <quote>-</quote>.</para>
<para>Users and/or groups are added to User Sets using the
/etc/shorewall/users file. Columns in that file are:</para>
<variablelist>
<varlistentry>
<term>USERSET</term>
<listitem>
<para>The name of a User Set defined in /etc/shorewall/usersets.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>USER</term>
<listitem>
<para>The name of a user defined on the system or a user number.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>GROUP</term>
<listitem>
<para>The name of a group defined on the system or a number.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Only one of the USER and GROUP column needs to be non-empty. If you
wish to specify a GROUP but not a USER, enter <quote>-</quote> in the user
column.</para>
<para>If both USER and GROUP are specified then only programs running
under that USER:GROUP pair will match rules specifying the User Set named
in the USERSET column.</para>
<para>Once a user set has been defined, its name may be placed in the USER
SET column of the /etc/shorewall/rules file.</para>
<important>
<para>When the name of a user set is given in the USER SET column, you
may not include a log level in the ACTION column; logging of such rules
is governed solely by the user set&#39;s definition in the
/etc/shorewall/userset file.</para>
</important>
<example>
<title>You want members of the <quote>admin</quote> group and
<quote>root</quote> to be able to use ssh on the firewall to connect to
local systems. You want to log all connections accepted for these users
using syslog at the <quote>info</quote> level.</title>
<para>/etc/shorewall/usersets</para>
<programlisting>#USERSET REJECT ACCEPT DROP
admins - info</programlisting>
<para>/etc/shorewall/users</para>
<programlisting>#USERSET USER GROUP
admins - admin
admins root</programlisting>
<para>/etc/shorewall/rules</para>
<programlisting>#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 22 - - - admins</programlisting>
</example>
</section>
<section id="Rule">
<title>Restricting a rule to a particular user and/or group</title>
<para>In cases where you may want to restrict a rule to a particular user
and/or group, the USER SET column in the rules file may be specified as:</para>
<programlisting>[ &#60;<emphasis>user name or number</emphasis>&#62; ] : [ &#60;<emphasis>group name or number</emphasis>&#62; ]</programlisting>
<para>When a user and/or group name is given in the USER SET column, it is
OK to specify a log level in the ACTION column.</para>
<example>
<title>You want user <emphasis role="bold">mail</emphasis> to be able to
send email from the firewall to the local net zone</title>
<para>/etc/shorewall/rules (be sure to note the <quote>:</quote> in the
USER SET column entry).</para>
<programlisting>#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 25 - - - mail:</programlisting>
</example>
</section>
</article>

238
Shorewall-docs2/User_defined_Actions.xml Executable file
View File

@ -0,0 +1,238 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>User-defined Actions</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-08</pubdate>
<copyright>
<year>2003-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<para>Prior to Shorewall version 1.4.9, rules in <filename>/etc/shorewall/rules</filename>
were limited to those defined by Netfilter (ACCEPT, DROP, REJECT, etc.).
Beginning with Shorewall version 1.4.9, users may use sequences of these
elementary operations to define more complex actions.</para>
<para>To define a new action:</para>
<orderedlist>
<listitem>
<para>Add a line to <filename><filename>/etc/shorewall/actions</filename></filename>
that names your new action. Action names must be valid shell variable
names as well as valid Netfilter chain names. It is recommended that the
name you select for a new action begins with with a capital letter; that
way, the name won&#39;t conflict with a Shorewall-defined chain name.</para>
<para>Beginning with Shorewall-2.0.0-Beta1, the name of the action may
be optionally followed by a colon (<quote>:</quote>) and ACCEPT, DROP or
REJECT. When this is done, the named action will become the
<emphasis>common action </emphasis>for policies of type ACCEPT, DROP or
REJECT respectively. The common action is applied immediately before the
policy is enforced (before any logging is done under that policy) and is
used mainly to suppress logging of uninteresting traffic which would
otherwise clog your logs. The same policy name can appear in multiple
actions; the last such action for each policy name is the one which
Shorewall will use.</para>
<para>Shorewall includes pre-defined actions for DROP and REJECT -- see
below.</para>
</listitem>
<listitem>
<para>Once you have defined your new action name (ActionName), then copy
/etc/shorewall/action.template to <filename>/etc/shorewall/action.ActionName</filename>
(for example, if your new action name is <quote>Foo</quote> then copy
<filename>/etc/shorewall/action.template</filename> to
<filename>/etc/shorewall/action.Foo</filename>).</para>
</listitem>
<listitem>
<para>Now modify the new file to define the new action.</para>
</listitem>
</orderedlist>
<para>Columns in the action.template file are as follows:</para>
<itemizedlist>
<listitem>
<para>TARGET - Must be ACCEPT, DROP, REJECT, LOG, QUEUE or &#60;<emphasis>action</emphasis>&#62;
where &#60;<emphasis>action</emphasis>&#62; is a previously-defined
action (that is, it must precede the action being defined in this file
in your <filename>/etc/shorewall/actions</filename> file). The TARGET
may optionally be followed by a colon (<quote>:</quote>) and a syslog
log level (e.g, REJECT:info or ACCEPT:debugging). This causes the packet
to be logged at the specified level. You may also specify ULOG (must be
in upper case) as a log level.This will log to the ULOG target for
routing to a separate log through use of ulogd (<ulink
url="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</ulink>).</para>
</listitem>
<listitem>
<para>SOURCE - Source hosts to which the rule applies. A comma-separated
list of subnets and/or hosts. Hosts may be specified by IP or MAC
address; mac addresses must begin with <quote>~</quote> and must use
<quote>-</quote> as a separator.</para>
<para>Alternatively, clients may be specified by interface name. For
example, eth1 specifies a client that communicates with the firewall
system through eth1. This may be optionally followed by another colon (<quote>:</quote>)
and an IP/MAC/subnet address as described above (e.g.,
eth1:192.168.1.5).</para>
</listitem>
<listitem>
<para>DEST - Location of Server. Same as above with the exception that
MAC addresses are not allowed.</para>
<para>Unlike in the SOURCE column, you may specify a range of up to 256
IP addresses using the syntax &#60;<emphasis>first ip</emphasis>&#62;-&#60;<emphasis>last
ip</emphasis>&#62;.</para>
</listitem>
<listitem>
<para>PROTO - Protocol - Must be <quote>tcp</quote>, <quote>udp</quote>,
<quote>icmp</quote>, a number, or <quote>all</quote>.</para>
</listitem>
<listitem>
<para>DEST PORT(S) - Destination Ports. A comma-separated list of Port
names (from <filename>/etc/services</filename>), port numbers or port
ranges; if the protocol is <quote>icmp</quote>, this column is
interpreted as the destination icmp-type(s).</para>
<para>A port range is expressed as &#60;<emphasis>low port</emphasis>&#62;:&#60;<emphasis>high
port</emphasis>&#62;.</para>
<para>This column is ignored if PROTOCOL = all but must be entered if
any of the following ields are supplied. In that case, it is suggested
that this field contain <quote>-</quote>.</para>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the
CLIENT PORT(S) list below:</para>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<listitem>
<para>SOURCE PORT(S) - Port(s) used by the client. If omitted, any
source port is acceptable. Specified as a comma-separated list of port
names, port numbers or port ranges.</para>
<para>If you don&#39;t want to restrict client ports but need to specify
an ADDRESS in the next column, then place &#34;-&#34; in this column.</para>
<para>If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and in the DEST
PORT(S) list above:</para>
<orderedlist>
<listitem>
<para>There are 15 or less ports listed.</para>
</listitem>
<listitem>
<para>No port ranges are included.</para>
</listitem>
</orderedlist>
<para>Otherwise, a separate rule will be generated for each port.</para>
</listitem>
<listitem>
<para>RATE LIMIT - You may rate-limit the rule by placing a value in
this column:</para>
<para><programlisting> &#60;<emphasis>rate</emphasis>&#62;/&#60;<emphasis>interval</emphasis>&#62;[:&#60;<emphasis>burst</emphasis>&#62;]</programlisting>where
&#60;<emphasis>rate</emphasis>&#62; is the number of connections per
&#60;<emphasis>interval</emphasis>&#62; (<quote>sec</quote> or
<quote>min</quote>) and &#60;<emphasis>burst</emphasis>&#62; is the
largest burst permitted. If no &#60;<emphasis>burst</emphasis>&#62; is
given, a value of 5 is assumed. There may be no whitespace embedded in
the specification.</para>
<para><programlisting> Example: 10/sec:20</programlisting></para>
</listitem>
<listitem>
<para>USER/GROUP - For output rules (those with the firewall as their
source), you may control connections based on the effective UID and/or
GID of the process requesting the connection. This column can contain
any of the following:</para>
<simplelist>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;[:]</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;[:]</member>
<member>[!]:&#60;<emphasis>group number</emphasis>&#62;</member>
<member>[!]:&#60;<emphasis>group name</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user number</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
number</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user inumber</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
<member>[!]&#60;<emphasis>user name</emphasis>&#62;:&#60;<emphasis>group
name</emphasis>&#62;</member>
</simplelist>
</listitem>
</itemizedlist>
<para>Example:</para>
<para><filename>/etc/shorewall/actions</filename>:</para>
<para><programlisting> LogAndAccept</programlisting><phrase><filename>/etc/shorewall/action.LogAndAccept</filename></phrase><programlisting> LOG:info
ACCEPT</programlisting></para>
<para>Beginning with Shorewall 2.0.0-Beta1, Shorewall includes a number of
defined actions. These defined actions are listed in <filename>/etc/shorewall/actions.std</filename>.
To ensure that all of these actions are included in the configuration, the
<filename>/etc/shorewall/actions</filename> file released with Shorewall
contains <quote><command>INCLUDE /etc/shorewall/actions.std</command></quote>.</para>
<para>The <filename>/etc/shorewall/actions.std</filename> file includes the
common actions <quote>Drop</quote> for DROP policies and <quote>Reject</quote>
for REJECT policies.</para>
</article>

124
Shorewall-docs2/VPN.xml Normal file
View File

@ -0,0 +1,124 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article id="VPN">
<!--$Id$-->
<articleinfo>
<title>VPN</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2002-12-21</pubdate>
<copyright>
<year>2002</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Virtual Private Networking (VPN)</title>
<para>It is often the case that a system behind the firewall needs to be
able to access a remote network through Virtual Private Networking (VPN).
The two most common means for doing this are IPSEC and PPTP. The basic
setup is shown in the following diagram:</para>
<graphic fileref="images/VPN.png" />
<para>A system with an RFC 1918 address needs to access a remote network
through a remote gateway. For this example, we will assume that the local
system has IP address 192.168.1.12 and that the remote gateway has IP
address 192.0.2.224.</para>
<para>If PPTP is being used, there are no firewall requirements beyond the
default loc-&#62;net ACCEPT policy. There is one restriction however: Only
one local system at a time can be connected to a single remote gateway
unless you patch your kernel from the <quote>Patch-o-matic</quote> patches
available at <ulink url="http://www.netfilter.org">http://www.netfilter.org</ulink>.</para>
<para>If IPSEC is being used then only one system may connect to the
remote gateway and there are firewall configuration requirements as
follows:</para>
<table>
<title>/etc/shorewall/rules</title>
<tgroup cols="7">
<thead>
<row>
<entry align="center">ACTION</entry>
<entry align="center">SOURCE</entry>
<entry align="center">DESTINATION</entry>
<entry align="center">PROTOCOL</entry>
<entry align="center">PORT</entry>
<entry align="center">CLIENT PORT</entry>
<entry align="center">ORIGINAL DEST</entry>
</row>
</thead>
<tbody>
<row>
<entry>DNAT</entry>
<entry>net:192.0.2.224</entry>
<entry>loc:192.168.1.12</entry>
<entry>50</entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>DNAT</entry>
<entry>net:192.0.2.224</entry>
<entry>loc:192.168.1.12</entry>
<entry>udp</entry>
<entry>500</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<para>If you want to be able to give access to all of your local systems
to the remote network, you should consider running a VPN client on your
firewall. As starting points, see <ulink url="Documentation.htm#Tunnels">http://www.shorewall.net/Documentation.htm#Tunnels</ulink>
or <ulink url="PPTP.htm">http://www.shorewall.net/PPTP.htm</ulink>.</para>
</section>
</article>

158
Shorewall-docs2/blacklisting_support.xml Normal file
View File

@ -0,0 +1,158 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Shorewall Blacklisting Support</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-17</pubdate>
<copyright>
<year>2002-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Introduction</title>
<para>Shorewall supports two different forms of blacklisting; static and
dynamic. Beginning with Shorewall version 1.4.8, the BLACKLISTNEWONLY
option in /etc/shorewall/shorewall.conf controls the degree of blacklist
filtering:</para>
<orderedlist>
<listitem>
<para>BLACKLISTNEWONLY=No --&#x00A0; All incoming packets are checked
against the blacklist. New blacklist entries can be used to terminate
existing connections. Versions of Shorewall prior to 1.4.8 behave in
this manner.</para>
</listitem>
<listitem>
<para>BLACKLISTNEWONLY=Yes -- The blacklists are only consulted for
new connection requests. Blacklists may not be used to terminate
existing connections. Only the source address is checked against the
blacklists.</para>
</listitem>
</orderedlist>
<para>Only the source address is checked against the blacklists.</para>
</section>
<section>
<title>Static Blacklisting</title>
<para>Shorewall static blacklisting support has the following
configuration parameters:</para>
<itemizedlist>
<listitem>
<para>You specify whether you want packets from blacklisted hosts
dropped or rejected using the BLACKLIST_DISPOSITION setting in <ulink
url="Documentation.htm#Config"><filename>/etc/shorewall/shorewall.conf</filename>.</ulink></para>
</listitem>
<listitem>
<para>You specify whether you want packets from blacklisted hosts
logged and at what syslog level using the BLACKLIST_LOGLEVEL setting
in <ulink url="Documentation.htm#Config"><filename>/etc/shorewall/shorewall.conf</filename></ulink>.</para>
</listitem>
<listitem>
<para>You list the IP addresses/subnets that you wish to blacklist in
<ulink url="Documentation.htm#Blacklist"><filename>/etc/shorewall/blacklist</filename></ulink>.
Beginning with Shorewall version 1.3.8, you may also specify PROTOCOL
and Port numbers/Service names in the blacklist file.</para>
</listitem>
<listitem>
<para>You specify the interfaces whose incoming packets you want
checked against the blacklist using the <quote>blacklist</quote>
option in <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
</listitem>
<listitem>
<para>The black list is refreshed from <filename>/etc/shorewall/blacklist</filename>
by the <quote><ulink url="starting_and_stopping_shorewall.htm"><command>shorewall
refresh</command></ulink></quote> command.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Dynamic Blacklisting</title>
<para>Dynamic blacklisting support was added in version 1.3.2. Dynamic
blacklisting doesn&#39;t use any configuration parameters but is rather
controlled using /sbin/shorewall commands:</para>
<itemizedlist>
<listitem>
<para>drop <emphasis>&#60;ip address list&#62;</emphasis> - causes
packets from the listed IP addresses to be silently dropped by the
firewall.</para>
</listitem>
<listitem>
<para>reject <emphasis>&#60;ip address list&#62;</emphasis> - causes
packets from the listed IP addresses to be rejected by the firewall.</para>
</listitem>
<listitem>
<para>allow <emphasis>&#60;ip address list&#62;</emphasis> -
re-enables receipt of packets from hosts previously blacklisted by a
<emphasis>drop</emphasis> or <emphasis>reject</emphasis> command.</para>
</listitem>
<listitem>
<para>save - save the dynamic blacklisting configuration so that it
will be automatically restored the next time that the firewall is
restarted.</para>
</listitem>
<listitem>
<para>show dynamic - displays the dynamic blacklisting configuration.</para>
</listitem>
</itemizedlist>
<para>Dynamic blacklisting is not dependent on the <quote>blacklist</quote>
option in <filename>/etc/shorewall/interfaces</filename>.</para>
<example>
<title>Ignore packets from a pair of systems</title>
<programlisting> <command>shorewall drop 192.0.2.124 192.0.2.125</command></programlisting>
<para>Drops packets from hosts 192.0.2.124 and 192.0.2.125</para>
</example>
<example>
<title>Re-enable packetes from a system</title>
<programlisting> <command>shorewall allow 192.0.2.125</command></programlisting>
<para>Re-enables traffic from 192.0.2.125.</para>
</example>
</section>
</article>

451
Shorewall-docs2/configuration_file_basics.xml Normal file
View File

@ -0,0 +1,451 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Configuration Files</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-03</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<caution>
<para>If you copy or edit your configuration files on a system running
Microsoft Windows, you must run them through <ulink
url="http://www.megaloman.com/~hany/software/hd2u/">dos2unix</ulink>
before you use them with Shorewall.</para>
</caution>
<section id="Files">
<title>Files</title>
<para><itemizedlist><listitem><para><filename>/etc/shorewall/shorewall.conf</filename>
- used to set several firewall parameters.</para></listitem><listitem><para><filename>/etc/shorewall/params</filename>
- use this file to set shell variables that you will expand in other
files.</para></listitem><listitem><para><filename>/etc/shorewall/zones</filename>
- partition the firewall&#39;s view of the world into zones.</para></listitem><listitem><para><filename>/etc/shorewall/policy</filename>
- establishes firewall high-level policy.</para></listitem><listitem><para><filename>/etc/shorewall/interfaces</filename>
- describes the interfaces on the firewall system.</para></listitem><listitem><para><filename>/etc/shorewall/hosts</filename>
- allows defining zones in terms of individual hosts and subnetworks.</para></listitem><listitem><para><filename>/etc/shorewall/masq</filename>
- directs the firewall where to use many-to-one (dynamic) Network Address
Translation (a.k.a. Masquerading) and Source Network Address Translation
(SNAT).</para></listitem><listitem><para><filename>/etc/shorewall/modules</filename>
- directs the firewall to load kernel modules.</para></listitem><listitem><para><filename>/etc/shorewall/rules</filename>
- defines rules that are exceptions to the overall policies established in
/etc/shorewall/policy.</para></listitem><listitem><para><filename>/etc/shorewall/nat</filename>
- defines one-to-one NAT rules.</para></listitem><listitem><para><filename>/etc/shorewall/proxyarp</filename>
- defines use of Proxy ARP.</para></listitem><listitem><para><filename>/etc/shorewall/routestopped</filename>
(Shorewall 1.3.4 and later) - defines hosts accessible when Shorewall is
stopped.</para></listitem><listitem><para><filename>/etc/shorewall/tcrules
</filename>- defines marking of packets for later use by traffic
control/shaping or policy routing.</para></listitem><listitem><para><filename>/etc/shorewall/tos</filename>
- defines rules for setting the TOS field in packet headers.</para></listitem><listitem><para><filename>/etc/shorewall/tunnels</filename>
- defines IPSEC, GRE and IPIP tunnels with end-points on the firewall
system.</para></listitem><listitem><para><filename>/etc/shorewall/blacklist</filename>
- lists blacklisted IP/subnet/MAC addresses.</para></listitem><listitem><para><filename>/etc/shorewall/init</filename>
- commands that you wish to execute at the beginning of a <quote>shorewall
start</quote> or <quote>shorewall restart</quote>.</para></listitem><listitem><para><filename>/etc/shorewall/start</filename>
- commands that you wish to execute at the completion of a <quote>shorewall
start</quote> or <quote>shorewall restart</quote></para></listitem><listitem><para><filename>/etc/shorewall/stop
</filename>- commands that you wish to execute at the beginning of a
<quote>shorewall stop</quote>.</para></listitem><listitem><para><filename>/etc/shorewall/stopped</filename>
- commands that you wish to execute at the completion of a <quote>shorewall
stop</quote>.</para></listitem><listitem><para><filename>/etc/shorewall/ecn</filename>
- disable Explicit Congestion Notification (ECN - RFC 3168) to remote
hosts or networks.</para></listitem><listitem><para><filename>/etc/shorewall/accounting</filename>
- define IP traffic accounting rules</para></listitem><listitem><para><filename>/etc/shorewall/actions</filename>
and <filename>/etc/shorewall/action.template</filename> - define your own
actions for rules in /etc/shorewall/rules (shorewall 1.4.9 and later).</para></listitem><listitem><para><filename>/etc/shorewall/actions.std</filename>
- Actions defined by Shorewall. Included using the <link linkend="INCLUDE">INCLUDE
command</link> by <filename>/etc/shorewall/actions</filename>.</para></listitem><listitem><para><filename>/etc/shorewall/actions.*</filename>
- Details of actions defined by Shorewall.</para></listitem></itemizedlist></para>
</section>
<section id="Comments">
<title>Comments</title>
<para>You may place comments in configuration files by making the first
non-whitespace character a pound sign (<quote>#</quote>). You may also
place comments at the end of any line, again by delimiting the comment
from the rest of the line with a pound sign.</para>
<example>
<title>Comments in a Configuration File</title>
<programlisting># This is a comment
ACCEPT net fw tcp www #This is an end-of-line comment</programlisting>
</example>
</section>
<section id="Continuation">
<title>Line Continuation</title>
<para>You may continue lines in the configuration files using the usual
backslash (<quote>\</quote>) followed immediately by a new line character.</para>
<example>
<title>Line Continuation</title>
<programlisting>ACCEPT net fw tcp \
smtp,www,pop3,imap #Services running on the firewall</programlisting>
</example>
</section>
<section id="INCLUDE">
<title>INCLUDE Directive</title>
<para>Beginning with Shorewall version 1.4.2, any file may contain INCLUDE
directives. An INCLUDE directive consists of the word INCLUDE followed by
a file name and causes the contents of the named file to be logically
included into the file containing the INCLUDE. File names given in an
INCLUDE directive are assumed to reside in /etc/shorewall or in an
alternate configuration directory if one has been specified for the
command.</para>
<para>INCLUDE&#39;s may be nested to a level of 3 -- further nested
INCLUDE directives are ignored with a warning message.</para>
<example>
<title>Use of INCLUDE</title>
<programlisting> shorewall/params.mgmt:
&#x00A0;&#x00A0; MGMT_SERVERS=1.1.1.1,2.2.2.2,3.3.3.3
&#x00A0;&#x00A0; TIME_SERVERS=4.4.4.4
&#x00A0;&#x00A0; BACKUP_SERVERS=5.5.5.5
&#x00A0;&#x00A0; ----- end params.mgmt -----
&#x00A0;&#x00A0; shorewall/params:
&#x00A0;&#x00A0; # Shorewall 1.3 /etc/shorewall/params
&#x00A0;&#x00A0; [..]
&#x00A0;&#x00A0; #######################################
&#x00A0;
&#x00A0;&#x00A0; INCLUDE params.mgmt&#x00A0;&#x00A0;&#x00A0;
&#x00A0;
&#x00A0;&#x00A0; # params unique to this host here
&#x00A0;&#x00A0; #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
&#x00A0;&#x00A0; ----- end params -----
&#x00A0;&#x00A0; shorewall/rules.mgmt:
&#x00A0;&#x00A0; ACCEPT net:$MGMT_SERVERS&#x00A0;&#x00A0;&#x00A0;$FW&#x00A0;&#x00A0;&#x00A0; tcp&#x00A0;&#x00A0;&#x00A0; 22
&#x00A0;&#x00A0; ACCEPT $FW&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; net:$TIME_SERVERS&#x00A0;&#x00A0;&#x00A0; udp&#x00A0;&#x00A0;&#x00A0; 123
&#x00A0;&#x00A0; ACCEPT $FW&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; net:$BACKUP_SERVERS&#x00A0; tcp&#x00A0;&#x00A0;&#x00A0; 22
&#x00A0;&#x00A0; ----- end rules.mgmt -----
&#x00A0;&#x00A0; shorewall/rules:
&#x00A0;&#x00A0; # Shorewall version 1.3 - Rules File
&#x00A0;&#x00A0; [..]
&#x00A0;&#x00A0; #######################################
&#x00A0;
&#x00A0;&#x00A0; INCLUDE rules.mgmt&#x00A0;&#x00A0;&#x00A0;&#x00A0;
&#x00A0;
&#x00A0;&#x00A0; # rules unique to this host here
&#x00A0;&#x00A0; #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
&#x00A0;&#x00A0; ----- end rules -----</programlisting>
</example>
</section>
<section id="dnsnames">
<title>Using DNS Names</title>
<caution>
<para>I personally recommend strongly against using DNS names in
Shorewall configuration files. If you use DNS names and you are called
out of bed at 2:00AM because Shorewall won&#39;t start as a result of
DNS problems then don&#39;t say that you were not forewarned.</para>
</caution>
<para>Beginning with Shorewall 1.3.9, Host addresses in Shorewall
configuration files may be specified as either IP addresses or DNS Names.</para>
<para>DNS names in iptables rules aren&#39;t nearly as useful as they
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those addresses
into the rule. So changes in the DNS-&#62;IP address relationship that
occur after the firewall has started have absolutely no effect on the
firewall&#39;s ruleset.</para>
<para>If your firewall rules include DNS names then:</para>
<itemizedlist>
<listitem>
<para>If your <filename>/etc/resolv.conf </filename>is wrong then your
firewall won&#39;t start.</para>
</listitem>
<listitem>
<para>If your <filename>/etc/nsswitch.conf</filename> is wrong then
your firewall won&#39;t start.</para>
</listitem>
<listitem>
<para>If your Name Server(s) is(are) down then your firewall won&#39;t
start.</para>
</listitem>
<listitem>
<para>If your startup scripts try to start your firewall before
starting your DNS server then your firewall won&#39;t start.</para>
</listitem>
<listitem>
<para>Factors totally outside your control (your ISP&#39;s router is
down for example), can prevent your firewall from starting.</para>
</listitem>
<listitem>
<para>You must bring up your network interfaces prior to starting your
firewall.</para>
</listitem>
</itemizedlist>
<para>Each DNS name much be fully qualified and include a minumum of two
periods (although one may be trailing). This restriction is imposed by
Shorewall to insure backward compatibility with existing configuration
files.</para>
<example>
<title>Valid DNS Names</title>
<itemizedlist>
<listitem>
<para>mail.shorewall.net</para>
</listitem>
<listitem>
<para>shorewall.net. (note the trailing period).</para>
</listitem>
</itemizedlist>
</example>
<example>
<title>Invalid DNS Names</title>
<itemizedlist>
<listitem>
<para>mail (not fully qualified)</para>
</listitem>
<listitem>
<para>shorewall.net (only one period)</para>
</listitem>
</itemizedlist>
</example>
<para>DNS names may not be used as:</para>
<itemizedlist>
<listitem>
<para>The server address in a DNAT rule (/etc/shorewall/rules file)</para>
</listitem>
<listitem>
<para>In the ADDRESS column of an entry in /etc/shorewall/masq.</para>
</listitem>
<listitem>
<para>In the <filename>/etc/shorewall/nat</filename> file.</para>
</listitem>
</itemizedlist>
<para>These restrictions are imposed by Netfilter and not by Shorewall.</para>
</section>
<section id="Compliment">
<title>Complementing an Address or Subnet</title>
<para>Where specifying an IP address, a subnet or an interface, you can
precede the item with <quote>!</quote> to specify the complement of the
item. For example, !192.168.1.4 means <quote>any host but 192.168.1.4</quote>.
There must be no white space following the <quote>!</quote>.</para>
</section>
<section id="Lists">
<title>Comma-separated Lists</title>
<para>Comma-separated lists are allowed in a number of contexts within the
configuration files. A comma separated list:</para>
<itemizedlist>
<listitem>
<para>Must not have any embedded white space.<programlisting> Valid: routefilter,dhcp,norfc1918
Invalid: routefilter,&#x00A0;&#x00A0;&#x00A0;&#x00A0; dhcp,&#x00A0;&#x00A0;&#x00A0;&#x00A0; norfc1818</programlisting></para>
</listitem>
<listitem>
<para>If you use line continuation to break a comma-separated list,
the continuation line(s) must begin in column 1 (or there would be
embedded white space)</para>
</listitem>
<listitem>
<para>Entries in a comma-separated list may appear in any order.</para>
</listitem>
</itemizedlist>
</section>
<section id="Ports">
<title>Port Numbers/Service Names</title>
<para>Unless otherwise specified, when giving a port number you can use
either an integer or a service name from /etc/services.</para>
</section>
<section id="Ranges">
<title>Port Ranges</title>
<para>If you need to specify a range of ports, the proper syntax is
&#60;low port number&#62;:&#60;high port number&#62;. For example, if you
want to forward the range of tcp ports 4000 through 4100 to local host
192.168.1.3, the entry in /etc/shorewall/rules is:</para>
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORTS(S)
DNAT net loc:192.168.1.3 tcp 4000:4100</programlisting>
<para>If you omit the low port number, a value of zero is assumed; if you
omit the high port number, a value of 65535 is assumed.</para>
</section>
<section id="Variables">
<title>Using Shell Variables</title>
<para>You may use the /etc/shorewall/params file to set shell variables
that you can then use in some of the other configuration files.</para>
<para>It is suggested that variable names begin with an upper case letter
to distinguish them from variables used internally within the Shorewall
programs</para>
<example>
<title>Using Shell Variables</title>
<programlisting>&#x00A0;&#x00A0;&#x00A0; /etc/shorewall/params
NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
&#x00A0;&#x00A0;&#x00A0; /etc/shorewall/interfaces record:
net $NET_IF $NET_BCAST $NET_OPTIONS
&#x00A0;&#x00A0;&#x00A0; The result will be the same as if the record had been written
net eth0 130.252.100.255 routefilter,norfc1918
</programlisting>
<para>Variables may be used anywhere in the other configuration files.</para>
</example>
</section>
<section id="MAC">
<title>Using MAC Addresses</title>
<para>Media Access Control (MAC) addresses can be used to specify packet
source in several of the configuration files. To use this feature, your
kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
included.</para>
<para>MAC addresses are 48 bits wide and each Ethernet Controller has a
unique MAC address.</para>
<para>In GNU/Linux, MAC addresses are usually written as a series of 6 hex
numbers separated by colons.</para>
<example>
<title>MAC Address of a NIC</title>
<programlisting> &#x00A0;&#x00A0;&#x00A0;&#x00A0; [root@gateway root]# <command>ifconfig eth0</command>
&#x00A0;&#x00A0;&#x00A0;&#x00A0; eth0 Link encap:Ethernet HWaddr <emphasis
role="bold">02:00:08:E3:FA:55</emphasis>
&#x00A0;&#x00A0;&#x00A0;&#x00A0; inet addr:206.124.146.176 Bcast:206.124.146.255 Mask:255.255.255.0
&#x00A0;&#x00A0;&#x00A0;&#x00A0; UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
&#x00A0;&#x00A0;&#x00A0;&#x00A0; RX packets:2398102 errors:0 dropped:0 overruns:0 frame:0
&#x00A0;&#x00A0;&#x00A0;&#x00A0; TX packets:3044698 errors:0 dropped:0 overruns:0 carrier:0
&#x00A0;&#x00A0;&#x00A0;&#x00A0; collisions:30394 txqueuelen:100
&#x00A0;&#x00A0;&#x00A0;&#x00A0; RX bytes:419871805 (400.4 Mb) TX bytes:1659782221 (1582.8 Mb)
&#x00A0;&#x00A0;&#x00A0;&#x00A0; Interrupt:11 Base address:0x1800
</programlisting>
</example>
<para>Because Shorewall uses colons as a separator for address fields,
Shorewall requires MAC addresses to be written in another way. In
Shorewall, MAC addresses begin with a tilde (<quote>~</quote>) and consist
of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in
the example above would be written <quote>~02-00-08-E3-FA-55</quote>.</para>
<note>
<para>It is not necessary to use the special Shorewall notation in the
<filename><ulink url="MAC_Validation.html">/etc/shorewall/maclist</ulink></filename>
file.</para>
</note>
</section>
<section id="Levels">
<title>Shorewall Configurations</title>
<para>Shorewall allows you to have configuration directories other than
<filename class="directory">/etc/shorewall</filename>. The shorewall
check, start and restart commands allow you to specify an alternate
configuration directory and Shorewall will use the files in the alternate
directory rather than the corresponding files in /etc/shorewall. The
alternate directory need not contain a complete configuration; those files
not in the alternate directory will be read from <filename
class="directory">/etc/shorewall</filename>.</para>
<para>This facility permits you to easily create a test or temporary
configuration by</para>
<orderedlist>
<listitem>
<para>copying the files that need modification from /etc/shorewall to
a separate directory;</para>
</listitem>
<listitem>
<para>modify those files in the separate directory; and</para>
</listitem>
<listitem>
<para>specifying the separate directory in a shorewall start or
shorewall restart command (e.g., <command>shorewall -c /etc/testconfig
restart</command> )</para>
</listitem>
</orderedlist>
<para>The <ulink url="starting_and_stopping_shorewall.htm">try command</ulink>
allows you to attempt to restart using an alternate configuration and if
an error occurs to automatically restart the standard configuration.</para>
</section>
</article>

107
Shorewall-docs2/dhcp.xml Executable file
View File

@ -0,0 +1,107 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>DHCP</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-01-10</pubdate>
<copyright>
<year>2001</year>
<year>2002</year>
<year>2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<note>
<para>For most operations, DHCP software interfaces to the Linux IP stack
at a level below Netfilter. Hence, Netfilter (and therefore Shorewall)
cannot be used effectively to police DHCP. The <quote>dhcp</quote>
interface option described in this article allows for Netfilter to stay
out of DHCP&#39;s way for those operations that can be controlled by
Netfilter and prevents unwanted logging of DHCP-related traffic by
Shorewall-generated Netfilter logging rules.</para>
</note>
<section>
<title>If you want to Run a DHCP Server on your firewall</title>
<itemizedlist>
<listitem>
<para>Specify the <quote>dhcp</quote> option on each interface to be
served by your server in the <filename><ulink
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink></filename>
file. This will generate rules that will allow DHCP to and from your
firewall system.</para>
</listitem>
<listitem>
<para>When starting <quote>dhcpd</quote>, you need to list those
interfaces on the run line. On a RedHat system, this is done by
modifying <filename>/etc/sysconfig/dhcpd</filename>.</para>
</listitem>
</itemizedlist>
<para>You can use <ulink url="myfiles.htm#Dhcpd">my dhcpd.conf file</ulink>
as an example. </para>
</section>
<section>
<title>If a Firewall Interface gets its IP Address via DHCP</title>
<itemizedlist>
<listitem>
<para>Specify the <quote>dhcp</quote> option for this interface in the
<ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
file.&#x00A0;This will generate rules that will allow DHCP to and from
your firewall system.</para>
</listitem>
<listitem>
<para>If you know that the dynamic address is always going to be in
the same subnet, you can specify the subnet address in the
interface&#39;s entry in the <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
file.</para>
</listitem>
<listitem>
<para>If you don&#39;t know the subnet address in advance, you should
specify <quote>detect</quote> for the interface&#39;s subnet address
in the <ulink url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>
file and start Shorewall after the interface has started.</para>
</listitem>
<listitem>
<para>In the event that the subnet address might change while
Shorewall is started, you need to arrange for a <quote>shorewall
refresh</quote> command to be executed when a new dynamic IP address
gets assigned to the interface. Check your DHCP client&#39;s
documentation.</para>
</listitem>
</itemizedlist>
</section>
</article>

235
Shorewall-docs2/errata.xml Normal file
View File

@ -0,0 +1,235 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<articleinfo>
<title>Shorewall Errata</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2004-02-03</pubdate>
<copyright>
<year>2001-2004</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<caution>
<itemizedlist>
<listitem>
<para>If you use a Windows system to download a corrected script, be
sure to run the script through <ulink
url="http://www.megaloman.com/~hany/software/hd2u/">dos2unix</ulink>
after you have moved it to your Linux system.</para>
</listitem>
<listitem>
<para>If you are installing Shorewall for the first time and plan to
use the .tgz and install.sh script, you can untar the archive, replace
the <quote>firewall</quote> script in the untarred directory with the
one you downloaded below, and then run install.sh.</para>
</listitem>
<listitem>
<para>When the instructions say to install a corrected firewall script
in /usr/share/shorewall/firewall, you may rename the existing file
before copying in the new file.</para>
</listitem>
<listitem>
<para><emphasis role="bold">DO NOT INSTALL CORRECTED COMPONENTS ON A
RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.</emphasis>
For example, do NOT install the 1.3.9a firewall script if you are
running 1.3.7c.</para>
</listitem>
</itemizedlist>
</caution>
<section>
<title>RFC1918 File</title>
<para><ulink url="http://shorewall.net/pub/shorewall/errata/1.4.8/rfc1918">Here</ulink>
is the most up to date version of the <ulink
url="Documentation.htm#rfc1918">rfc1918 file</ulink>.</para>
</section>
<section>
<title>Problems in Version 2.0</title>
<section>
<title>Shorewall 2.0.0-Beta 1</title>
<itemizedlist>
<listitem>
<para></para>
</listitem>
</itemizedlist>
</section>
</section>
<section>
<title>Upgrade Issues</title>
<para>The upgrade issues have moved to <ulink url="upgrade_issues.htm">a
separate page</ulink>.</para>
</section>
<section>
<title>Problem with iptables version 1.2.3</title>
<para>There are a couple of serious bugs in iptables 1.2.3 that prevent it
from working with Shorewall. Regrettably, RedHat released this buggy
iptables in RedHat 7.2.&#x00A0;</para>
<para>I have built a <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">corrected
1.2.3 rpm which you can download here</ulink>&#x00A0; and I have also
built an <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">iptables-1.2.4
rpm which you can download here</ulink>. If you are currently running
RedHat 7.1, you can install either of these RPMs before you upgrade to
RedHat 7.2.</para>
<para><emphasis role="bold">Update 11/9/2001:</emphasis> RedHat has
released an iptables-1.2.4 RPM of their own which you can download from
<ulink url="http://www.redhat.com/support/errata/RHSA-2001-144.html.">http://www.redhat.com/support/errata/RHSA-2001-144.html</ulink>.I
have installed this RPM on my firewall and it works fine.</para>
<para>If you would like to patch iptables 1.2.3 yourself, the patches are
available for download. This <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</ulink>
which corrects a problem with parsing of the --log-level specification
while this <ulink
url="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</ulink>
corrects a problem in handling the&#x00A0; TOS target.</para>
<para>To install one of the above patches:<programlisting> cd iptables-1.2.3/extensions
patch -p0 &#60; the-patch-file</programlisting></para>
</section>
<section>
<title>Problems with kernels &#62;= 2.4.18 and RedHat iptables</title>
<para>Users who use RedHat iptables RPMs and who upgrade to kernel
2.4.18/19 may experience the following:</para>
<blockquote>
<programlisting># shorewall start
Processing /etc/shorewall/shorewall.conf ...
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h-&#62;info.valid_hooks == (1 &#60;&#60; 0 | 1 &#60;&#60; 3)&#39; failed.
Aborted (core dumped)
iptables: libiptc/libip4tc.c:380: do_check: Assertion
`h-&#62;info.valid_hooks == (1 &#60;&#60; 0 | 1 &#60;&#60; 3)&#39; failed.
Aborted (core dumped)</programlisting>
</blockquote>
<para>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in the
Netfilter <quote>mangle</quote> table. You can correct the problem by
installing <ulink
url="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">this
iptables RPM</ulink>. If you are already running a 1.2.5 version of
iptables, you will need to specify the --oldpackage option to rpm (e.g.,
<quote>iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm</quote>).</para>
</section>
<section>
<title>Problems with iptables version 1.2.7 and MULTIPORT=Yes</title>
<para>The iptables 1.2.7 release of iptables has made an incompatible
change to the syntax used to specify multiport match rules; as a
consequence, if you install iptables 1.2.7 you must be running Shorewall
1.3.7a or later or:</para>
<itemizedlist>
<listitem>
<para>set MULTIPORT=No in /etc/shorewall/shorewall.conf; or</para>
</listitem>
<listitem>
<para>If you are running Shorewall 1.3.6 you may install <ulink
url="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">this
firewall script</ulink> in /usr/lib/shorewall/firewall as described
above.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Problems with RH Kernel 2.4.18-10 and NAT</title>
<para>/etc/shorewall/nat entries of the following form will result in
Shorewall being unable to start:</para>
<programlisting> #EXTERNAL&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; INTERFACE&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; INTERNAL&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; ALL INTERFACES&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0;&#x00A0; LOCAL
192.0.2.22&#x00A0;&#x00A0;&#x00A0; eth0&#x00A0;&#x00A0;&#x00A0; 192.168.9.22&#x00A0;&#x00A0; yes&#x00A0;&#x00A0;&#x00A0;&#x00A0; yes
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</programlisting>
<para>Error message is:</para>
<programlisting> Setting up NAT...
iptables: Invalid argument
Terminated</programlisting>
<para>The solution is to put <quote>no</quote> in the LOCAL column. Kernel
support for LOCAL=yes has never worked properly and 2.4.18-10 has disabled
it. The 2.4.19 kernel contains corrected support under a new kernel
configuraiton option; see <ulink
url="http://www.shorewall.net/Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</ulink>.</para>
</section>
<section>
<title>Problems with RH Kernels after 2.4.20-9 and REJECT (also applies to
2.4.21-RC1)</title>
<para>Beginning with errata kernel 2.4.20-13.9, <quote>REJECT
--reject-with tcp-reset</quote> is broken. The symptom most commonly seen
is that REJECT rules act just like DROP rules when dealing with TCP. A
kernel patch and precompiled modules to fix this problem are available at
<ulink url="ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel">ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel</ulink></para>
<note>
<para>RedHat have corrected this problem in their 2.4.20-27.x kernels.</para>
</note>
</section>
<appendix>
<title>Revision History4</title>
<para><revhistory><revision><revnumber>1.5</revnumber><date>2004-02-03</date><authorinitials>TE</authorinitials><revremark>Update
for Shorewall 2.0.0.</revremark></revision><revision><revnumber>1.4</revnumber><date>2004-01-19</date><authorinitials>TE</authorinitials><revremark>IPV6
address problems. Make RFC1918 file section more prominent.</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-14</date><authorinitials>TE</authorinitials><revremark>Confusing
template file in 1.4.9</revremark></revision><revision><revnumber>1.3</revnumber><date>2004-01-03</date><authorinitials>TE</authorinitials><revremark>Added
note about REJECT RedHat Kernal problem being corrected.</revremark></revision><revision><revnumber>1.2</revnumber><date>2003-12-29</date><authorinitials>TE</authorinitials><revremark>Updated
RFC1918 file</revremark></revision><revision><revnumber>1.1</revnumber><date>2003-12-17</date><authorinitials>TE</authorinitials><revremark>Initial
Conversion to Docbook XML</revremark></revision></revhistory></para>
</appendix>
</article>

93
Shorewall-docs2/fallback.xml Normal file
View File

@ -0,0 +1,93 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<article>
<!--$Id$-->
<articleinfo>
<title>Fallback and Uninstall</title>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
</authorgroup>
<pubdate>2001-03-26</pubdate>
<copyright>
<year>2001</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<section>
<title>Falling Back to the Previous Version of Shorewall using the
Fallback Script</title>
<para>If you install Shorewall and discover that it doesn&#39;t work for
you, you can fall back to your previously installed version. To do that:</para>
<itemizedlist>
<listitem>
<para>cd to the distribution directory for the version of Seattle
Firewall that you are currently running (NOT the version that you want
to fall back to).</para>
</listitem>
<listitem>
<para>Type <quote>./fallback.sh</quote></para>
</listitem>
</itemizedlist>
<caution>
<para>The fallback script will replace /etc/shorewall/policy,
/etc/shorewall/rules, /etc/shorewall/interfaces, /etc/shorewall/nat,
/etc/shorewall/proxyarp and /etc/shorewall/masq with the version of
these files from before the current version was installed. Any changes
to any of these files will be lost.</para>
</caution>
</section>
<section>
<title>Falling Back to the Previous Version of Shorewall using rpm</title>
<para>If your previous version of Shorewall was installed using RPM, you
may fall back to that version by typing <quote>rpm -Uvh --force &#60;old
rpm&#62;</quote> at a root shell prompt (Example: <quote>rpm -Uvh --force
/downloads/shorewall-3.1=0noarch.rpm</quote> would fall back to the 3.1-0
version of Shorewall).</para>
</section>
<section>
<title>Uninstalling Shorewall</title>
<para>If you no longer wish to use Shorewall, you may remove it by:</para>
<itemizedlist>
<listitem>
<para>cd to the distribution directory for the version of Shorewall
that you have installed.</para>
</listitem>
<listitem>
<para>type <quote>./uninstall.sh</quote></para>
</listitem>
</itemizedlist>
<para>If you installed using an rpm, at a root shell prompt type
<quote>rpm -e shorewall</quote>.</para>
</section>
</article>

BIN
Shorewall-docs2/images/BD21298_.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 B

BIN
Shorewall-docs2/images/BD21298_1.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 B

BIN
Shorewall-docs2/images/BD21298_2.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 B

BIN
Shorewall-docs2/images/BD21298_3.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 101 B

BIN
Shorewall-docs2/images/CorpNetwork.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
Shorewall-docs2/images/DMZ4.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
Shorewall-docs2/images/DMZ5.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

BIN
Shorewall-docs2/images/DMZ6.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
Shorewall-docs2/images/Hiking1.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

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

Binary file not shown.

2473
Shorewall-docs2/images/Legend.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/Legend.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

BIN
Shorewall-docs2/images/Logo1.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

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

Binary file not shown.

BIN
Shorewall-docs2/images/Logo2.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

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

Binary file not shown.

BIN
Shorewall-docs2/images/MDKlinux.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
Shorewall-docs2/images/Mobile.png Normal file
View File

Binary file not shown.

6399
Shorewall-docs2/images/Mobile.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/Mobile.vsd Normal file
View File

Binary file not shown.

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

Binary file not shown.

7737
Shorewall-docs2/images/MultiPPTP.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/MultiPPTP.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

15685
Shorewall-docs2/images/MultiZone1.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/MultiZone1.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

15917
Shorewall-docs2/images/MultiZone1A.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/MultiZone1A.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

15917
Shorewall-docs2/images/MultiZone1B.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/MultiZone1B.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

11017
Shorewall-docs2/images/MultiZone2.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/MultiZone2.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

13850
Shorewall-docs2/images/MultiZone3.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

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

Binary file not shown.

8844
Shorewall-docs2/images/Netfilter.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/Netfilter.vsd Executable file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/ORE.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

BIN
Shorewall-docs2/images/P1000048.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 65 KiB

BIN
Shorewall-docs2/images/P1000049.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 82 KiB

BIN
Shorewall-docs2/images/P1000050.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

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

Binary file not shown.

BIN
Shorewall-docs2/images/QoS.png Normal file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/SY00079.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

BIN
Shorewall-docs2/images/Shorewall_Banner.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 KiB

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

Binary file not shown.

9756
Shorewall-docs2/images/State_Diagram.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/State_Diagram.vsd Executable file
View File

Binary file not shown.

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

Binary file not shown.

6495
Shorewall-docs2/images/ThreeNets.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/ThreeNets.vsd Executable file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/Thumbs.db Normal file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/Tom.jpg Executable file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

BIN
Shorewall-docs2/images/TomNTarry.png Normal file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/TwoIPv6Nets1.png Normal file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/TwoNets1.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
Shorewall-docs2/images/TwoNets1.png Normal file
View File

Binary file not shown.

5750
Shorewall-docs2/images/TwoNets1.vdx Executable file
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs2/images/TwoNets1.vsd Normal file
View File

Binary file not shown.

BIN
Shorewall-docs2/images/VPN.png Normal file
View File

Binary file not shown.

Some files were not shown because too many files have changed in this diff Show More