extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-15 02:41:01 +01:00
Code Issues Packages Projects Releases Wiki Activity

Shorewall 1.4.6 Beta2

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@649 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-07-07 14:18:52 +00:00
parent cf62edd5ca
commit 184390708e
17 changed files with 11188 additions and 10565 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1211
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

297
Shorewall-docs/FAQ.htm
View File

@ -39,9 +39,9 @@
</h1>
<p align="left"><b>1. </b><a href="#faq1"> I want to <b>forward</b> UDP <b>
port</b> 7777 to my my personal PC with IP
address 192.168.1.5. I've looked everywhere and
can't find <b>how to do it</b>.</a></p>
port</b> 7777 to my my personal PC with IP address
192.168.1.5. I've looked everywhere and can't
find <b>how to do it</b>.</a></p>
<p align="left"><b>1a. </b><a href="#faq1a">Ok -- I followed those instructions
but it doesn't work.<br>
@ -50,9 +50,9 @@ can't find <b>how to do it</b>.</a></p>
<p align="left"><b>1b. </b><a href="#faq1b">I'm still having problems with
port forwarding</a></p>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to <b>connect
to port 1022</b> on my firewall and have the <b>firewall forward the connection
to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
<p align="left"><b>1c. </b><a href="#faq1c">From the internet, I want to
<b>connect to port 1022</b> on my firewall and have the <b>firewall forward
the connection to port 22 on local system 192.168.1.3</b>. How do I do that?</a><br>
</p>
<h1><b>DNS and PORT FORWARDING/NAT<br>
@ -86,8 +86,8 @@ using their DNS names.</b></a></p>
as 'closed' rather than 'blocked'.</b> Why?</a></p>
<p align="left"><b>4a. </b><a href="#faq4a">I just ran an <b>nmap UDP scan</b>
of my firewall and it showed 100s of ports
as open!!!!<br>
of my firewall and it showed 100s of ports as
open!!!!<br>
</a></p>
<b>4b</b>. <a href="#faq4b">I have a port that I can't close no matter
how I change my rules. </a>
@ -110,14 +110,13 @@ as open!!!!<br>
<p align="left"><b>6b. <a href="#faq6b">DROP messages</a></b><a
href="#faq6b"> on port 10619 are <b>flooding the logs</b> with their connect
requests. Can i exclude these error messages for this port
temporarily from logging in Shorewall?</a><br>
requests. Can i exclude these error messages for this port temporarily
from logging in Shorewall?</a><br>
</p>
<p align="left"><b>6c. </b><a href="#faq6c">All day long I get a steady flow
of these <b>DROP messages from port 53</b> <b>to some high
numbered port</b>. They get dropped, but what the heck are
they?</a><br>
of these <b>DROP messages from port 53</b> <b>to some high numbered
port</b>. They get dropped, but what the heck are they?</a><br>
</p>
<p align="left"><b>6d.</b> <a href="#faq6d">Why is the <b>MAC address</b>
@ -138,8 +137,8 @@ they?</a><br>
<h1>STARTING AND STOPPING<br>
</h1>
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using
'shorewall stop', I can't connect to anything</b>. Why doesn't that command
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using 'shorewall
stop', I can't connect to anything</b>. Why doesn't that command
work?</a></p>
<p align="left"><b>8. </b><a href="#faq8">When I try to <b>start Shorewall
@ -154,8 +153,8 @@ they?</a><br>
<p align="left"><b>9. </b><a href="FAQ.htm#faq9">Why can't Shorewall <b>detect
my interfaces </b>properly at startup?</a></p>
<b>22. </b><a href="#faq22">I
have some <b>iptables commands </b>that I want to <b>run when
Shorewall starts.</b> Which file do I put them in?</a><br>
have some <b>iptables commands </b>that I want to <b>run
when Shorewall starts.</b> Which file do I put them in?</a><br>
<h1>ABOUT SHOREWALL<br>
</h1>
@ -163,8 +162,7 @@ Shorewall starts.</b> Which file do I put them in?</a><br>
<p align="left"><b>10. </b><a href="#faq10">What <b>distributions</b> does
it work with?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Is there a <b>GUI?</b></a></p>
@ -180,9 +178,9 @@ support?</a></p>
<p align="left"><b>14. </b><a href="#faq14">I'm connected via a cable modem
and it has an internel web server that allows
me to configure/monitor it but as expected if I
enable <b> rfc1918 blocking</b> for my eth0 interface,
it also blocks the <b>cable modems web server</b></a>.</p>
me to configure/monitor it but as expected if I enable
<b> rfc1918 blocking</b> for my eth0 interface, it also
blocks the <b>cable modems web server</b></a>.</p>
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC
@ -216,8 +214,7 @@ not permitted</b>". How can I use nmap with Shorewall?"</a><br>
<hr>
<h4 align="left"><a name="faq1"></a>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.</h4>
I've looked everywhere and can't find how to do it.</h4>
<p align="left"><b>Answer: </b>The <a
href="Documentation.htm#PortForward"> first example</a> in the <a
@ -293,9 +290,9 @@ it.</h4>
</blockquote>
<div align="left"> <font face="Courier"> </font>If
you want to forward requests directed to a particular
address ( <i>&lt;external IP&gt;</i> ) on your firewall
to an internal system:</div>
you want to forward requests directed to a particular address
( <i>&lt;external IP&gt;</i> ) on your firewall to an internal
system:</div>
<blockquote>
<table border="1" cellpadding="2" cellspacing="0"
@ -339,8 +336,8 @@ in the PORT column specify the range as <i>low-port</i>:<i>high-port</i
<ul>
<li>You are
trying to test from inside your firewall (no, that won't
work -- see <a href="#faq2">FAQ #2</a>).</li>
trying to test from inside your firewall (no, that
won't work -- see <a href="#faq2">FAQ #2</a>).</li>
<li>You have
a more basic problem with your local system such as
an incorrect default gateway configured (it should be
@ -357,8 +354,8 @@ set to the IP address of your firewall's internal interface).</l
<ul>
<li>As root, type "iptables
-t nat -Z". This clears the NetFilter counters in the
nat table.</li>
-t nat -Z". This clears the NetFilter counters in
the nat table.</li>
<li>Try to connect to
the redirected port from an external host.</li>
<li>As root type "shorewall
@ -370,8 +367,8 @@ the redirected port from an external host.</li>
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 server (the server's
default gateway should be the IP address of the firewall's
or incorrect default gateway setting on the server (the
server's default gateway should be the IP address of the firewall's
interface to the server).</li>
<li>If the packet count
is zero:</li>
@ -382,9 +379,9 @@ request is not reaching your server (possibly it is
being blocked by your ISP); or</li>
<li>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 "ORIG.
DEST." column in your DNAT rule); or</li>
and your rule is only redirecting the primary IP address (You
need to specify the secondary IP address in the "ORIG. DEST."
column in your DNAT rule); or</li>
<li>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
@ -446,9 +443,9 @@ my local network. External clients can browse http://www
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
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 :-)</li>
<li>The accessibility
@ -456,8 +453,8 @@ your server in a DMZ such that it is isolated from your local systems
href="shorewall_setup_guide.htm#DNS">Bind Version 9 "views"</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 static NAT.</li>
internally. That's what I do here at shorewall.net for my
local systems that use static NAT.</li>
</ul>
@ -469,8 +466,8 @@ my local systems that use static NAT.</li>
</p>
<p align="left">If you are running Shorewall 1.4.0 or earlier see <a
href="1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions suitable for
those releases.<br>
href="1.3/FAQ.htm#faq2">the 1.3 FAQ</a> for instructions suitable for those
releases.<br>
</p>
<p align="left">If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, please
@ -618,22 +615,21 @@ those releases.<br>
<h4 align="left"><a name="faq2a"></a>2a. I have a zone "Z" with an RFC1918
subnet and I use static 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>
with each other using their external (non-RFC1918 addresses)
so they can't access each other using their DNS names.</h4>
<p align="left"><b>Answer: </b>This is another problem that is best solved
using Bind Version 9 "views". It allows both
external and internal clients to access a NATed
host using the host's DNS name.</p>
external and internal clients to access a NATed host
using the host's DNS name.</p>
<p align="left">Another good way to approach this problem is to switch from
static 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 align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">a) Set the Z-&gt;Z policy to ACCEPT.<br>
b) Masquerade
@ -744,12 +740,13 @@ a solution for MSN IM but be aware that there are significant security
port 113 rather than dropping them. This is necessary
to prevent outgoing connection problems to services
that use the 'Auth' mechanism for identifying requesting
users. Shorewall also rejects TCP ports 135, 137 and 139
as well as UDP ports 137-139. These are ports that are used
by Windows (Windows <u>can</u> 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>
users. Shorewall also rejects TCP ports 135, 137 and
139 as well as UDP ports 137-139. These are ports that are
used by Windows (Windows <u>can</u> 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 align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web
@ -762,8 +759,8 @@ than dropping them cuts down slightly on the amount of Windows chatter
section about UDP scans. If nmap gets <b>nothing</b>
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.<br>
open, temporarily change your net-&gt;all policy to
REJECT, restart Shorewall and do the nmap UDP scan again.<br>
</p>
<h4><a name="faq4b"></a>4b. I have a port that I can't close no matter how
@ -773,10 +770,10 @@ open, temporarily change your net-&gt;all policy to REJECT,
works!!!<br>
<br>
<b>Answer: </b> 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.<br>
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.<br>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
can't ping through the firewall</h4>
@ -802,11 +799,11 @@ attempt.<br>
<h4 align="left"><a name="faq6"></a>6. Where are the log messages written
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure
to restart syslogd (on a RedHat system, "service syslog
@ -843,13 +840,13 @@ logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
</p>
</blockquote>
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.
me a report each day from my various systems with each
report summarizing the logged activity on the corresponding
system.
<h4 align="left"><b><a name="faq6b"></a>6b. DROP messages</b> on port 10619
are <b>flooding the logs</b> with their connect requests. Can
i exclude these error messages for this port temporarily from
logging in Shorewall?</h4>
i exclude these error messages for this port temporarily from logging
in Shorewall?</h4>
Temporarily add the following rule:<br>
<pre> DROP net fw udp 10619</pre>
@ -862,7 +859,8 @@ logging in Shorewall?</h4>
<b>Answer: </b>There are two possibilities:<br>
<ol>
<li>They are late-arriving replies to DNS queries.</li>
<li>They are late-arriving replies to DNS
queries.</li>
<li>They are corrupted reply packets.</li>
</ol>
@ -876,8 +874,8 @@ an /etc/shorewall/common file like this:<br>
<blockquote>
<pre>#<br># Include the standard common.def file<br>#<br>. /etc/shorewall/common.def<br>#<br># The following rule is non-standard and compensates for tardy<br># DNS replies<br>#<br>run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</pre>
</blockquote>
The above file is also include in all of my sample
configurations available in the <a
The above file is also include in all of my
sample configurations available in the <a
href="shorewall_quickstart_guide.htm">Quick Start Guides</a> and in
the common.def file in Shorewall 1.4.0 and later.<br>
@ -910,9 +908,9 @@ an /etc/shorewall/common file like this:<br>
<p align="left">The 'stop' command is intended to place your firewall into
a safe state whereby only those hosts listed
in /etc/shorewall/routestopped' are activated.
If you want to totally open up your firewall, you must use
the 'shorewall clear' command. </p>
in /etc/shorewall/routestopped' are activated. If
you want to totally open up your firewall, you must use the
'shorewall clear' command. </p>
<h4 align="left"><a name="faq8"></a>8. When I try to start Shorewall on RedHat,
I get messages about insmod failing -- what's wrong?</h4>
@ -956,9 +954,9 @@ the 'shorewall clear' command. </p>
</div>
<div align="left">
<p align="left"><b>Answer: </b>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 eth1</p>
<p align="left"><b>Answer: </b>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 eth1</p>
</div>
<h4 align="left"><a name="faq10"></a>10. What Distributions does it work
@ -990,16 +988,17 @@ the 'shorewall clear' command. </p>
<h4 align="left"> <a name="faq14"></a>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.</h4>
enable rfc1918 blocking for my eth0 interface (the internet
one), it also blocks the cable modems web server.</h4>
<p align="left">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>
address of the modem in/out but still block all other
rfc1918 addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -1077,10 +1076,10 @@ for that address. For example, if you configure the address
</div>
<div align="left">
<h4 align="left"><a name="faq14a"></a>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>
<h4 align="left"><a name="faq14a"></a>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 align="left">
@ -1092,10 +1091,10 @@ lease.</h4>
the net</h4>
<p align="left"><b>Answer: </b>Every time I read "systems can't see out to
the net", I wonder where the poster bought
computers with eyes and what those computers will
"see" when things are working properly. That aside,
the most common causes of this problem are:</p>
the net", I wonder where the poster bought computers
with eyes and what those computers will "see" when
things are working properly. That aside, the most
common causes of this problem are:</p>
<ol>
<li>
@ -1122,12 +1121,12 @@ computers with eyes and what those computers will
all over my console making it unusable!</h4>
<p align="left"><b>Answer: </b>If you are running Shorewall version 1.4.4
or 1.4.4a then check the <a href="errata.htm">errata.</a> Otherwise, see the
'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command
or 1.4.4a then check the <a href="errata.htm">errata.</a> Otherwise, see
the 'dmesg' man page ("man dmesg"). You must add a suitable 'dmesg' command
to your startup scripts or place it in /etc/shorewall/start.
Under RedHat, the max log level that is sent
to the console is specified in /etc/sysconfig/init
in the LOGLEVEL variable.<br>
to the console is specified in /etc/sysconfig/init in
the LOGLEVEL variable.<br>
</p>
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
@ -1137,21 +1136,20 @@ in the LOGLEVEL variable.<br>
the log message) in Shorewall:<br>
<ol>
<li><b>man1918 -
</b>The destination address is listed in /etc/shorewall/rfc1918
with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>man1918
</b>or <b>logdrop - </b>The destination address is
listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b>
- The source address is listed in /etc/shorewall/rfc1918
or <b>logdrop </b>- The source address is listed in /etc/shorewall/rfc1918
with a <b>logdrop </b>target -- see <a
href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>all2&lt;zone&gt;</b>,
<b>&lt;zone&gt;2all</b> or <b>all2all
</b>- You have a<a href="Documentation.htm#Policy"> 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">rule</a> to
that effect.<br>
</b>- You have a<a href="Documentation.htm#Policy"> 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">rule</a> to that effect.<br>
</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt;
</b>- Either you have a<a
@ -1185,8 +1183,9 @@ it is not a syn packet. Options affecting the logging of such
<li><b>INPUT</b>
or <b>FORWARD</b> - The packet has a source IP address
that isn't in any of your defined zones ("shorewall check"
and look at the printed zone definitions) or the chain is FORWARD
and the destination IP isn't in any of your defined zones.</li>
and look at the printed zone definitions) or the chain is
FORWARD and the destination IP isn't in any of your defined
zones.</li>
<li><b>logflags </b>- The
packet is being logged because it failed the checks implemented
by the <b>tcpflags </b><a
@ -1203,18 +1202,18 @@ packet is being logged because it failed the checks implemen
<h4><b><a name="faq19"></a>19. </b>I have added entries to /etc/shorewall/tcrules
but they don't seem to do anything. Why?</h4>
You probably haven't set TC_ENABLED=Yes
in /etc/shorewall/shorewall.conf so the contents of
the tcrules file are simply being ignored.<br>
You probably haven't set
TC_ENABLED=Yes in /etc/shorewall/shorewall.conf so
the contents of the tcrules file are simply being ignored.<br>
<h4><a name="faq20"></a><b>20. </b>I have just set up a server. <b>Do I have
to change Shorewall to allow access to my server from
the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1223,20 +1222,20 @@ you used during your initial setup for information about how to set
<blockquote>
<pre>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<br> 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 <br> [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 ]<br></pre>
</blockquote>
192.0.2.3 is external on my firewall...
172.16.0.0/24 is my internal LAN<br>
192.0.2.3 is external on my
firewall... 172.16.0.0/24 is my internal LAN<br>
<br>
<b>Answer: </b>While most people
associate the Internet Control Message Protocol (ICMP)
with 'ping', ICMP is a key piece of the internet. ICMP
is used to report problems back to the sender of a packet; this
with 'ping', 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.<br>
<br>
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.<br>
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.<br>
<br>
Host 172.16.1.10 behind NAT gateway
206.124.146.179 sent a UDP DNS query to 192.0.2.3 and
@ -1250,41 +1249,42 @@ 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
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.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file
do I put them in?</h4>
I want to <b>run when Shorewall starts.</b> Which file do
I put them in?</h4>
You can place these commands
in one of the <a href="shorewall_extension_scripts.htm">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
"man iptables" and look at the -I (--insert) command.<br>
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 "man iptables" and look at the -I (--insert) command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
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.<br>
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.<br>
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
the ssh port only<b> from specific IP Addresses</b> on the
internet?</h4>
In the SOURCE column of the rule, follow "net"
by a colon and a list of the host/subnet addresses as a comma-separated
list.<br>
In the SOURCE column of the rule, follow
"net" by a colon and a list of the host/subnet addresses as
a comma-separated list.<br>
<pre> net:&lt;ip1&gt;,&lt;ip2&gt;,...<br></pre>
Example:<br>
@ -1306,11 +1306,12 @@ I use nmap with Shorewall?"</h4>
Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to "NEWNOTSYN=Yes"
then restart Shorewall.<br>
<br>
<font size="2">Last updated 6/29/2003 - <a
<font size="2">Last updated 7/5/2003 - <a
href="support.htm">Tom Eastep</a></font>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

24
Shorewall-docs/NAT.htm
View File

@ -48,8 +48,8 @@ I strongly recommend that you read the <a
<p align="left">Static 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.</p>
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.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
@ -93,25 +93,25 @@ the INTERFACE column should undergo NAT. If you leave this column empty,
href="Documentation.htm#Aliases">ADD_IP_ALIASES</a>="no" (or "No") in
/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or if
you set it to "Yes" or "yes" then you must NOT configure your own alias(es).
<b>RESTRICTION: </b>Shorewall 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 can only add addresses
to the first one.</p>
<b>RESTRICTION: </b>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.</p>
<p><a name="LocalPackets"></a>Note 3: The contents of the "LOCAL" 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 "yes" or "Yes" (and the ALL INTERFACES COLUMN also contains
"Yes" or "yes") then such packets are redirected; otherwise, such packets
are not redirected. The LOCAL column was added in version 1.1.8.</p>
for the EXTERNAL address are redirected to the internal ADDRESS. If
this column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN also
contains "Yes" or "yes") then such packets are redirected; otherwise,
such packets are not redirected. The LOCAL column was added in version
1.1.8.</p>
</blockquote>
<blockquote> </blockquote>
<p><font size="2">Last updated 4/11/2003 - </font><font size="2"> <a
<p><font size="2">Last updated 7/6/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<br>
</body>
</html>

1057
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

BIN
Shorewall-docs/images/Netfilter.png
View File

Binary file not shown.

243
Shorewall-docs/seattlefirewall_index.htm
View File

@ -46,6 +46,7 @@
</tr>
</tbody>
</table>
@ -70,9 +71,9 @@
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
@ -80,28 +81,28 @@
<p>This program is free software; you can redistribute it and/or modify
it
under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
it under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
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 details.<br>
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 details.<br>
<br>
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</p>
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</p>
@ -117,20 +118,22 @@ General Public License</a> as published by the Free Software
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not apply
directly to your setup. If you want to use the documentation that you
find here, you will want to consider uninstalling what you have and installing
a setup that matches the documentation on this site. See the <a
href="two-interface.htm">Two-interface QuickStart Guide</a> for details.<br>
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
<h2>Looking for Information?</h2>
The <a href="shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a> is a good place to start as is the Quick Search to your right.
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not
apply directly to your setup. If you want to use the documentation
that you find here, you will want to consider uninstalling what you have
and installing a setup that matches the documentation on this site.
See the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.<br>
<h2>News</h2>
@ -138,39 +141,62 @@ General Public License</a> as published by the Free Software
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<p><b></b></p>
<ol>
</ol>
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b><b> <img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
<blockquote><a href="http://shorewall.net/pub/shorewall/testing">http://shorewall.net/pub/shorewall/testing</a><br>
<a href="ftp://shorewall.net/pub/shorewall/testing"
target="_top">ftp://shorewall.net/pub/shorewall/testing</a><br>
</blockquote>
<p><b>Problems Corrected:</b><br>
</p>
<ol>
<li>A problem seen on RH7.3 systems where Shorewall encountered
start errors when started using the "service" mechanism has been worked around.<br>
<li>A problem seen on RH7.3 systems where Shorewall encountered start
errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Previously, where a list of IP addresses appears in the DEST
column of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
in the nat table (one for each element in the list). Shorewall now correctly
creates a single DNAT rule with multiple "--to-destination" clauses.<br>
<li>Where a list of IP addresses appears in the DEST column of a
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat
table (one for each element in the list). Shorewall now correctly creates
a single DNAT rule with multiple "--to-destination" clauses.<br>
<br>
</li>
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
were mis-handled when they appeared in the DEST column of a rule.<br>
</li>
</ol>
<p><b>Migration Issues:</b><br>
</p>
<ol>
<li>In earlier versions, an undocumented feature allowed entries
in the host file as follows:<br>
<br>
    z    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
    z   eth1:192.168.1.0/24,192.168.2.0/24<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
detected by Shorewall (see below).<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option
may be specified in /etc/shorewall/interfaces and overrides the setting
NEWNOTSYN=No for packets arriving on the associated interface.<br>
<li>A 'newnotsyn' interface option has been added. This option may
be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
@ -182,24 +208,18 @@ NEWNOTSYN=No for packets arriving on the associated interface.<br>
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin)
over a set of servers. Up to 256 servers may be specified in a range of addresses
given as &lt;first address&gt;-&lt;last address&gt;.<br>
<li>DNAT[-] rules may now be used to load balance (round-robin) over
a set of servers. Servers may be specified in a range of addresses given
as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
Note that this capability has previously been available using a combination
of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable
for load-balancing over a large number of servers (&gt; 16) since specifying
a range in the DNAT rule causes one filter table ACCEPT rule to be generated
for each IP address in the range.<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
options have been removed and have been replaced by code that detects whether
these capabilities are present in the current kernel. The output of the start,
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
have been removed and have been replaced by code that detects whether these
capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
@ -221,11 +241,10 @@ and check commands.<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
   Verifying Configuration...<br>
Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is
changed in the following ways:</li>
If this extension is available, the ruleset generated by Shorewall is changed
in the following ways:</li>
<ul>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
@ -237,23 +256,85 @@ in the filter table (rfc1918 chain).</li>
defaulted to) in the DNAT rule.<br>
<br>
</li>
</ul>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.</li>
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.<br>
<br>
</li>
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
<br>
      ipcalc [ &lt;address&gt; &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt;
]<br>
<br>
Examples:<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0/24<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
Warning:<br>
<br>
If your shell only supports 32-bit signed arithmatic (ash or dash), then
the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1
and for /1 networks. Bash should produce correct information for all valid
IP addresses.<br>
<br>
</li>
<li>An 'iprange' command has been added to /sbin/shorewall. <br>
<br>
      iprange &lt;address&gt;-&lt;address&gt;<br>
<br>
This command decomposes a range of IP addressses into a list of network
and host addresses. The command can be useful if you need to construct an
efficient set of rules that accept connections from a range of network addresses.<br>
<br>
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
then the range may not span 128.0.0.0.<br>
<br>
Example:<br>
<br>
      [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9<br>
      192.168.1.4/30<br>
      192.168.1.8/29<br>
      192.168.1.16/28<br>
      192.168.1.32/27<br>
      192.168.1.64/26<br>
      192.168.1.128/25<br>
      192.168.2.0/23<br>
      192.168.4.0/22<br>
      192.168.8.0/22<br>
      192.168.12.0/29<br>
      192.168.12.8/31<br>
      [root@gateway root]#<br>
<br>
</li>
<li>A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.<br>
<br>
Example:<br>
<br>
    foo    eth1:192.168.1.0/24,192.168.2.0/24<br>
</li>
</ol>
<p><b>6/17/2003 - Shorewall-1.4.5</b><b> </b></p>
<p>Problems Corrected:<br>
</p>
<ol>
<li>The command "shorewall debug try &lt;directory&gt;" now correctly
traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones file;
previously, INCLUDE in that file was ignored.</li>
<li>The command "shorewall debug try &lt;directory&gt;" now
correctly traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones
file; previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
@ -265,9 +346,9 @@ column are no longer ignored.<br>
<ol>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then the
rule will take effect only if the original destination address in the connection
request does not match any of the addresses listed.</li>
may now contain a list of addresses. If the list begins with "!' then
the rule will take effect only if the original destination address in
the connection request does not match any of the addresses listed.</li>
</ol>
@ -275,9 +356,9 @@ rule will take effect only if the original destination address in the connectio
</b></p>
<p>The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
have been encountered with this set of software. The Shorewall version
is 1.4.4b plus the accumulated changes for 1.4.5.<br>
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No
problems have been encountered with this set of software. The Shorewall
version is 1.4.4b plus the accumulated changes for 1.4.5.<br>
</p>
<p><b>6/8/2003 - Updated Samples</b><b> </b></p>
@ -322,8 +403,9 @@ is 1.4.4b plus the accumulated changes for 1.4.5.<br>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c" valign="top"
align="center">
<td width="88" bgcolor="#4b017c"
valign="top" align="center">
<form method="post"
@ -351,6 +433,7 @@ is 1.4.4b plus the accumulated changes for 1.4.5.<br>
<p><font color="#ffffff"><b><a
href="http://lists.shorewall.net/htdig/search.html"><font
color="#ffffff">Extended Search</font></a></b></font></p>
@ -382,6 +465,7 @@ is 1.4.4b plus the accumulated changes for 1.4.5.<br>
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10" alt="(Starlight Logo)">
@ -393,8 +477,8 @@ is 1.4.4b plus the accumulated changes for 1.4.5.<br>
<p align="center"><font size="4" color="#ffffff"><br>
<font size="+2"> Shorewall is free but if you try it and
find it useful, please consider making a donation
<font size="+2"> Shorewall is free but if you try it
and find it useful, please consider making a donation
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></font></p>
@ -409,11 +493,8 @@ is 1.4.4b plus the accumulated changes for 1.4.5.<br>
</table>
<p><font size="2">Updated 7/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 7/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

157
Shorewall-docs/shorewall_firewall_structure.htm
View File

@ -36,17 +36,17 @@
<ol>
<li> net -- the (untrusted) internet.</li>
<li> dmz - systems that must be accessible from the internet
and from the local network.  These systems cannot be trusted completely
since their servers may have been compromised through a security exploit.</li>
and from the local network.  These systems cannot be trusted completely since
their servers may have been compromised through a security exploit.</li>
<li> loc - systems in your local network(s). These systems
must be protected from the internet and from the DMZ and in some cases,
from each other.</li>
</ol>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall
zone</a>. For ease of description in this documentation, it is assumed
that the firewall zone is named "fw".</p>
<p><b>Note: </b><a href="#Conf">You can specify the name of the firewall zone</a>.
For ease of description in this documentation, it is assumed that the firewall
zone is named "fw".</p>
<p>It can't be stressed enough that with the exception of the firewall zone,
Shorewall itself attaches no meaning to zone names. Zone names are simply
@ -55,8 +55,8 @@ that the firewall zone is named "fw".</p>
<p>While zones are normally disjoint (no two zones have a host in common),
there are cases where nested or overlapping zone definitions are appropriate.</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the purpose
of this document, we will consider Netfilter to have three tables:</p>
<p>Netfilter has the concept of <i>tables</i> and <i>chains. </i>For the
purpose of this document, we will consider Netfilter to have three tables:</p>
<ol>
<li>Filter table -- this is the main table for packet filtering and can
@ -174,8 +174,9 @@ in the diagram above.<br>
<li>Packets entering the firewall first pass through the <i>mangle </i>table's
PREROUTING chain (you can see the mangle table by typing "shorewall show
mangle"). If the packet entered through an interface that has the <b>norfc1918</b>
option, then the packet is sent down the <b>man1918</b> chain which will
drop the packet if its destination IP address is reserved (as specified
option and if iptables/netfilter doesn't support the connection tracking
match extension, then the packet is sent down the <b>man1918</b> chain which
will drop the packet if its destination IP address is reserved (as specified
in the /etc/shorewall/rfc1918 file). Next the packet passes through the<b>
pretos</b> chain to set its TOS field as specified in the /etc/shorewall/tos
file. Finally, if traffic control/shaping is being used, the packet is sent
@ -184,94 +185,85 @@ or traffic control.<br>
<br>
Next, if the packet isn't part of an established connection, it passes
through the<i> nat</i> table's PREROUTING chain (you can see the nat table
by typing "shorewall show nat"). If you are doing both static nat and
port forwarding, the order in which chains are traversed is dependent on
the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
on then packets will ender a chain called<b> <i>interface_</i>in</b> where
by typing "shorewall show nat"). If you are doing both static nat and port
forwarding, the order in which chains are traversed is dependent on the
setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is on
then packets will ender a chain called<b> <i>interface_</i>in</b> where
<i>interface</i> is the name of the interface on which the packet entered.
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP
addresses from /etc/shorewall/nat that correspond to this interface; if
there is a match, DNAT is applied and the packet header is modified to
the IP in the <i>INTERNAL</i> column of the nat file record. If the destination
address doesn't match any of the rules in the <b><i>interface_</i>in</b>
chain then the packet enters a chain called <b><i>sourcezone</i>_dnat</b>
where <i>sourcezone</i> is the source zone of the packet. There it is compared
for a match against each of the DNAT records in the rules file that specify
<i> sourcezone </i>as the source zone. If a match is found, the destination
IP address (and possibly the destination port) is modified based on the
rule matched. If NAT_BEFORE_RULES is off, then the order of traversal of
the <b><i> interface_</i>in</b> and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
Here it's destination IP is compared to each of the <i>EXTERNAL</i> IP addresses
from /etc/shorewall/nat that correspond to this interface; if there is
a match, DNAT is applied and the packet header is modified to the IP in
the <i>INTERNAL</i> column of the nat file record. If the destination address
doesn't match any of the rules in the <b><i>interface_</i>in</b> chain then
the packet enters a chain called <b><i>sourcezone</i>_dnat</b> where <i>sourcezone</i>
is the source zone of the packet. There it is compared for a match against
each of the DNAT records in the rules file that specify <i> sourcezone
</i>as the source zone. If a match is found, the destination IP address
(and possibly the destination port) is modified based on the rule matched.
If NAT_BEFORE_RULES is off, then the order of traversal of the <b><i> interface_</i>in</b>
and <b><i>sourcezone</i>_dnat</b> is reversed.<br>
<br>
</li>
<li>Depending on whether the packet is destined for the firewall itself
or for another system, it follows either the left or the right path. Traffic
going to the firewall goes through chains called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain. Traffic next passes the the
INPUT chain in the filter table where it is broken out based on the interface
on which the packet arrived; packets from interface <i>interface</i> are routed
to chain <b><i>interface</i>_in</b>. For example, packets arriving through
eth0 are passed to the chain <b>eth0_in.</b></li>
<ol>
<li>The first rule in <b><i>interface</i>_in</b> jumps to the chain
named <b>dynamic</b> which matches the source IP in the packet against all
of the addresses that have been blacklisted using <a
href="blacklisting_support.htm#Dynamic">dynamic blacklisting</a>.</li>
<li>If the the interface has the <b>norfc1918</b> option then the packet
is sent down the <b>rfc1918 </b>which checks the source address against those
listed in /etc/shorewall/rfc1918 and treats the packet according to the first
match in that file (if any).</li>
<li>If the interface has the  <b>dhcp </b>option, UDP packets to ports
67 and 68 are accepted.</li>
<li><br>
going to the firewall goes through chain called INPUT in the mangle table.
Shorewall doesn't add any rules to that chain.<br>
<br>
</li>
<li>Traffic that is to be forwarded to another host goes through the chains
called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf,
all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are
processed in a chain called <br>
<br>
</li>
<ol>
</ol>
<li>Traffic is next sent to an<i> input </i>chain in the mail Netfilter
<li>Traffic is next sent to an<i> interface </i>chain in the main Netfilter
table (called 'filter'). If the traffic is destined for the firewall itself,
the name of the input chain is formed by appending "_in" to the interface
the name of the interface chain is formed by appending "_in" to the interface
name. So traffic on eth0 destined for the firewall will enter a chain called
<i>eth0_in</i>. The input chain for traffic that will be routed to
another system is formed by appending "_fwd" to the interface name. So traffic
from eth1 that is going to be forwarded enters a chain called<i> eth1_fwd</i>.
Interfaces described with the wild-card character ("+") in /etc/shorewall/interfaces,
share input chains. if <i>ppp+ </i>appears in /etc/shorewall/interfaces
then all PPP interfaces (ppp0, ppp1, ...) will share the input chains <i>ppp_in</i>
and <i>ppp_fwd</i>. In other words, "+" is deleted from the name before
forming the input chain names.</li>
<i>eth0_in</i>. The interface chain for traffic that will be routed
to another system is formed by appending "_fwd" to the interface name.
So traffic from eth1 that is going to be forwarded enters a chain called<i>
eth1_fwd</i>. Interfaces described with the wild-card character ("+")
in /etc/shorewall/interfaces, share input chains. if <i>ppp+ </i>appears
in /etc/shorewall/interfaces then all PPP interfaces (ppp0, ppp1, ...) will
share the interface chains <i>ppp_in</i> and <i>ppp_fwd</i>. In other words,
"+" is deleted from the name before forming the input chain names.<br>
<br>
While the use of interfacechains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </li>
</ol>
<p> While the use of input chains may seem wasteful in simple environments,
in complex setups it substantially reduces the number of rules that each
packet must traverse.  </p>
<p> Traffic directed from a zone to the firewall itself is sent through
a chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
<p> Traffic directed from a zone to the firewall itself is sent through a
chain named &lt;<i>zone name&gt;</i>2fw. For example, traffic inbound from
the internet and addressed to the firewall is sent through a chain named
net2fw. Similarly, traffic originating in the firewall and being sent to
a host in a given zone is sent through a chain named fw2<i>&lt;zone name&gt;.
</i>For example, traffic originating in the firewall and destined
for a host in the local network is sent through a chain named <i>fw2loc.</i>
<font face="Century Gothic, Arial, Helvetica">  </font></p>
net2fw. Similarly, traffic originating in the firewall and being sent
to a host in a given zone is sent through a chain named fw2<i>&lt;zone
name&gt;. </i>For example, traffic originating in the firewall and
destined for a host in the local network is sent through a chain named
<i>fw2loc.</i> <font face="Century Gothic, Arial, Helvetica">  </font></p>
<p> Traffic being forwarded between two zones (or from one interface to
a zone to another interface to that zone) is sent through a chain named <i>
<p> Traffic being forwarded between two zones (or from one interface to a
zone to another interface to that zone) is sent through a chain named <i>
&lt;source zone&gt;</i>2<i> &lt;destination zone&gt;</i>. So for example,
traffic originating in a local system and destined for a remote web server
is sent through chain <i>loc2net. </i>This chain is referred to as
the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
is sent through chain <i>loc2net. </i>This chain is referred to
as the <i>canonical</i> chain from &lt;source zone&gt; to &lt;destination
zone&gt;. Any destination NAT will have occurred <u>before</u> the packet
traverses one of these chains so rules in /etc/shorewall/rules should be
expressed in terms of the destination system's real IP address as opposed
traverses one of these chains so rules in /etc/shorewall/rules should
be expressed in terms of the destination system's real IP address as opposed
to its apparent external address. Similarly, source NAT will occur <u>after</u>
the packet has traversed the appropriate forwarding chain so the rules
again will be expressed using the source system's real IP address.</p>
<p> For each record in the /etc/shorewall/policy file, a chain is created.
Policies in that file are expressed in terms of a source zone and destination
zone where these zones may be a zone defined in /etc/shorewall/zones,
"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
zone where these zones may be a zone defined in /etc/shorewall/zones, "fw"
or "all". Policies specifying the pseudo-zone "all" matches all defined
zones and "fw". These chains are referred to as <i>Policy Chains.</i> Notice
that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
may also be the policy chain for the pair or the policy chain may be a
@ -289,15 +281,15 @@ immediately to the policy chain.</li>
</ol>
<p> The canonical chain from zone za to zone zb will be created only if
there are exception rules defined in /etc/shorewall/rules for packets going
from za to zb.</p>
<p> The canonical chain from zone za to zone zb will be created only if there
are exception rules defined in /etc/shorewall/rules for packets going from
za to zb.</p>
<p> Shorewall is built on top of the Netfilter kernel facility. Netfilter
implements connection tracking function that allow what is often referred
to as "statefull inspection" of packets. This statefull property allows
firewall rules to be defined in terms of "connections" rather than in
terms of "packets". With Shorewall, you:</p>
firewall rules to be defined in terms of "connections" rather than
in terms of "packets". With Shorewall, you:</p>
<ol>
<li> Identify the client's zone.</li>
@ -311,10 +303,10 @@ server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed between zone
A and the firewall and are also allowed between the firewall and zone
B <font color="#ff6633"><b><u> DOES NOT mean that these connections
are allowed between zone A and zone B</u></b></font>. It rather means
that you can have a proxy running on the firewall that accepts a connection
A and the firewall and are also allowed between the firewall and zone B
<font color="#ff6633"><b><u> DOES NOT mean that these connections are
allowed between zone A and zone B</u></b></font>. It rather means that
you can have a proxy running on the firewall that accepts a connection
from zone A and then establishes its own separate connection from the firewall
to zone B.</p>
@ -330,5 +322,6 @@ from zone A and then establishes its own separate connection from the firewall
<br>
<br>
<br>
<br>
</body>
</html>

47
Shorewall-docs/shorewall_quickstart_guide.htm
View File

@ -25,15 +25,15 @@
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
Version 4.0</font></h1>
</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="center">With thanks to Richard who reminded me once again that we
must all first walk before we can run.<br>
<p align="center">With thanks to Richard who reminded me once again that
we must all first walk before we can run.<br>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
@ -113,8 +113,8 @@ the single-address guides above.</b></p>
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a
href="configuration_file_basics.htm#Configs">Shorewall Configurations
(making a test configuration)</a></li>
href="configuration_file_basics.htm#Configs">Shorewall Configurations (making
a test configuration)</a></li>
<li><a
href="configuration_file_basics.htm#MAC">Using MAC Addresses in Shorewall</a></li>
@ -122,6 +122,7 @@ the single-address guides above.</b></p>
</li>
<li><a href="Documentation.htm">Configuration
File Reference Manual</a>
<ul>
<li> <a
href="Documentation.htm#Variables">params</a></li>
@ -135,7 +136,8 @@ the single-address guides above.</b></p>
href="Documentation.htm#Policy">policy</a></font></li>
<li><font color="#000099"><a
href="Documentation.htm#Rules">rules</a></font></li>
<li><a href="Documentation.htm#Common">common</a></li>
<li><a
href="Documentation.htm#Common">common</a></li>
<li><font color="#000099"><a
href="Documentation.htm#Masq">masq</a></font></li>
<li><font color="#000099"><a
@ -162,8 +164,9 @@ the single-address guides above.</b></p>
</ul>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><a href="ECN.html">ECN Disabling by host
or subnet</a><br>
<li><a href="ECN.html">ECN Disabling by
host or subnet</a></li>
<li><a href="errata.htm">Errata</a><br>
</li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
@ -171,13 +174,21 @@ the single-address guides above.</b></p>
use of files in /etc/shorewall -- /etc/shorewall/start, /etc/shorewall/stopped,
etc.)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="FAQ.htm">FAQs</a><br>
</li>
<li><a href="shorewall_features.htm">Features</a><br>
</li>
<li><a
href="shorewall_firewall_structure.htm">Firewall Structure</a></li>
<li><a href="support.htm">Getting help or answers to questions</a></li>
<li><a href="Install.htm">Installation/Upgrade</a><br>
</li>
<li><font color="#000099"><a
href="kernel.htm">Kernel Configuration</a></font></li>
<li><a href="shorewall_logging.html">Logging</a><br>
</li>
<li><a href="MAC_Validation.html">MAC Verification</a><br>
<li><a href="MAC_Validation.html">MAC Verification</a></li>
<li><a href="http://lists.shorewall.net">Mailing Lists</a><br>
</li>
<li><a href="myfiles.htm">My Shorewall
Configuration (How I personally use Shorewall)</a><br>
@ -193,6 +204,8 @@ the single-address guides above.</b></p>
</ul>
</li>
<li><a href="ProxyARP.htm">Proxy ARP</a></li>
<li><a href="shorewall_prerequisites.htm">Requirements</a><br>
</li>
<li><a href="samba.htm">Samba</a></li>
<li><a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a><br>
</li>
@ -224,6 +237,7 @@ Addresses</a></li>
</li>
<li><a href="shorewall_setup_guide.htm#Options">5.0 Setting
up your Network</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Routed">5.1 Routed</a></li>
@ -267,10 +281,14 @@ Addresses</a></li>
<li><font color="#000099"><a
href="NAT.htm">Static NAT</a></font></li>
<li><a href="Shorewall_Squid_Usage.html">Squid as a Transparent
Proxy with Shorewall</a><br>
</li>
Proxy with Shorewall</a></li>
<li><a href="traffic_shaping.htm">Traffic
Shaping/QOS</a></li>
<li><a href="troubleshoot.htm">Troubleshooting (Things to try if it doesn't
work)</a><br>
</li>
<li><a href="upgrade_issues.htm">Upgrade Issues</a><br>
</li>
<li>VPN
<ul>
@ -294,15 +312,10 @@ Shaping/QOS</a></li>
<p>If you use one of these guides and have a suggestion for improvement <a
href="mailto:webmaster@shorewall.net">please let me know</a>.</p>
<p><font size="2">Last modified 5/18/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last modified 7/6/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

401
Shorewall-docs/shorewall_setup_guide.htm
View File

@ -55,8 +55,8 @@
<h2><a name="Introduction"></a>1.0 Introduction</h2>
<p>This guide is intended for users who are setting up Shorewall in an environment
where a set of public IP addresses must be managed or who want to
know more about Shorewall than is contained in the <a
where a set of public IP addresses must be managed or who want to know
more about Shorewall than is contained in the <a
href="shorewall_quickstart_guide.htm">single-address guides</a>. Because
the range of possible applications is so broad, the Guide will give
you general guidelines and will point you to other resources as necessary.</p>
@ -68,9 +68,9 @@ Shorewall lrp from the shorewall.net site before you proceed.</p>
<p>Shorewall requires that the iproute/iproute2 package be installed (on
RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell if
this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
this package is installed by the presence of an <b>ip</b> program on your
firewall system. As root, you can use the 'which' command to check for
this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
@ -84,10 +84,10 @@ flagged with <img border="0" src="images/BD21298_.gif" width="13"
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows system,
you must save them as Unix files if your editor supports that option
or you must run them through dos2unix before trying to use them with Shorewall.
Similarly, if you copy a configuration file from your Windows hard
drive to a floppy disk, you must run dos2unix against the copy before
using it with Shorewall.</p>
or you must run them through dos2unix before trying to use them with
Shorewall. Similarly, if you copy a configuration file from your Windows
hard drive to a floppy disk, you must run dos2unix against the copy
before using it with Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows
@ -101,8 +101,8 @@ using it with Shorewall.</p>
<h2 align="left"><a name="Concepts"></a>2.0 Shorewall Concepts</h2>
<p>The configuration files for Shorewall are contained in the directory /etc/shorewall
-- for most setups, you will only need to deal with a few of these as described
in this guide. Skeleton files are created during the <a
-- for most setups, you will only need to deal with a few of these as
described in this guide. Skeleton files are created during the <a
href="Install.htm">Shorewall Installation Process</a>.</p>
<p>As each file is introduced, I suggest that you look through the actual
@ -140,8 +140,8 @@ using it with Shorewall.</p>
file.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b> but that may be changed
in the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
the firewall itself is known as <b>fw</b> but that may be changed in
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
file. In this guide, the default name (<b>fw</b>) will be used.</p>
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
@ -170,23 +170,23 @@ one zone to another zone in the<a
href="http://www.cs.princeton.edu/%7Ejns/security/iptables/iptables_conntrack.html">connection
tracking function</a> that allows what is often referred to as <i>stateful
inspection</i> of packets. This stateful property allows firewall
rules to be defined in terms of <i>connections</i> rather than in
terms of packets. With Shorewall, you:</p>
rules to be defined in terms of <i>connections</i> rather than in terms
of packets. With Shorewall, you:</p>
<ol>
<li> Identify the source zone.</li>
<li> Identify the destination zone.</li>
<li> If the POLICY from the client's zone to the server's
zone is what you want for this client/server pair, you need do
nothing further.</li>
<li> If the POLICY from the client's zone to the
server's zone is what you want for this client/server pair, you
need do nothing further.</li>
<li> If the POLICY is not what you want, then you
must add a rule. That rule is expressed in terms of the client's
zone and the server's zone.</li>
</ol>
<p> Just because connections of a particular type are allowed from zone A
to the firewall and are also allowed from the firewall to zone B <font
<p> Just because connections of a particular type are allowed from zone
A to the firewall and are also allowed from the firewall to zone B <font
color="#ff6633"><b><u> DOES NOT mean that these connections are allowed
from zone A to zone B</u></b></font>. It rather means that you can
have a proxy running on the firewall that accepts a connection from
@ -194,8 +194,8 @@ to the firewall and are also allowed from the firewall to zone B <font
to zone B.</p>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in /etc/shorewall/policy
checked against the /etc/shorewall/rules file. If no rule in that file
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common.def.</p>
@ -245,8 +245,8 @@ file matches the connection request then the first policy in /etc/shorewal
to the internet</li>
<li>drop (ignore) all connection requests from the internet
to your firewall or local network and log a message at the <i>info</i>
level (<a href="shorewall_logging.html">here</a> is a description of
log levels).</li>
level (<a href="shorewall_logging.html">here</a> is a description of log
levels).</li>
<li>reject all other connection requests and log a message
at the <i>info</i> level. When a request is rejected, the firewall
will return an RST (if the protocol is TCP) or an ICMP port-unreachable
@ -267,12 +267,13 @@ any changes that you wish.</p>
<p align="left">In this diagram:</p>
<ul>
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A DMZ
is used to isolate your internet-accessible servers from your local
systems so that if one of those servers is compromised, you still have
the firewall between the compromised system and your local systems. </li>
<li>The Local Zone consists of systems Local 1, Local 2 and
Local 3. </li>
<li>The DMZ Zone consists of systems DMZ 1 and DMZ 2. A
DMZ is used to isolate your internet-accessible servers from your
local systems so that if one of those servers is compromised, you still
have the firewall between the compromised system and your local systems.
</li>
<li>The Local Zone consists of systems Local 1, Local 2
and Local 3. </li>
<li>All systems from the ISP outward comprise the Internet
Zone. </li>
@ -299,15 +300,15 @@ to that "Modem" (e.g., <b>eth0</b>)
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then
you will want to set CLAMPMSS=yes in <a
    If your external interface is <b>ppp0</b> or <b>ippp0
</b>then you will want to set CLAMPMSS=yes in <a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
<p align="left">Your <i>Local Interface</i> will be an Ethernet adapter (eth0,
eth1 or eth2) and will be connected to a hub or switch. Your local
computers will be connected to the same switch (note: If you have only
a single local system, you can connect the firewall directly to the
computer using a <i>cross-over </i> cable).</p>
a single local system, you can connect the firewall directly to the computer
using a <i>cross-over </i> cable).</p>
<p align="left">Your <i>DMZ Interface</i> will also be an Ethernet adapter
(eth0, eth1 or eth2) and will be connected to a hub or switch. Your
@ -378,9 +379,9 @@ hub or switch (even for testing). It won't work the way that you expect
height="13">
    Edit the /etc/shorewall/interfaces file and define the
network interfaces on your firewall and associate each interface with
a zone. If you have a zone that is interfaced through more than one
interface, simply include one entry for each interface and repeat the
zone name as many times as necessary.</p>
a zone. If you have a zone that is interfaced through more than one interface,
simply include one entry for each interface and repeat the zone name
as many times as necessary.</p>
<p align="left">Example:</p>
@ -457,18 +458,18 @@ zone name as many times as necessary.</p>
<p align="left">Normally, your ISP will assign you a set of <i> Public</i>
IP addresses. You will configure your firewall's external interface
to use one of those addresses permanently and you will then have to
decide how you are going to use the rest of your addresses. Before we
tackle that question though, some background is in order.</p>
to use one of those addresses permanently and you will then have to decide
how you are going to use the rest of your addresses. Before we tackle
that question though, some background is in order.</p>
<p align="left">If you are thoroughly familiar with IP addressing and routing,
you may <a href="#Options">go to the next section</a>.</p>
<p align="left">The following discussion barely scratches the surface of addressing
and routing. If you are interested in learning more about this subject,
I highly recommend <i>"IP Fundamentals: What Everyone Needs to Know about
Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall, 1999, ISBN
0-13-975483-0.</p>
<p align="left">The following discussion barely scratches the surface of
addressing and routing. If you are interested in learning more about this
subject, I highly recommend <i>"IP Fundamentals: What Everyone Needs to
Know about Addressing &amp; Routing",</i> Thomas A. Maufer, Prentice-Hall,
1999, ISBN 0-13-975483-0.</p>
<h3 align="left"><a name="Addresses"></a>4.1 IP Addresses</h3>
@ -491,8 +492,8 @@ has value "w", the next byte has value "x", etc. If we take the address
<p align="left">You will still hear the terms "Class A network", "Class B
network" and "Class C network". In the early days of IP, networks
only came in three sizes (there were also Class D networks but they
were used differently):</p>
only came in three sizes (there were also Class D networks but they were
used differently):</p>
<blockquote>
<p align="left">Class A - netmask 255.0.0.0, size = 2 ** 24</p>
@ -507,8 +508,8 @@ were used differently):</p>
and immediately determine the associated <i>netmask</i>. The netmask
is a number that when logically ANDed with an address isolates the <i>network
number</i>; the remainder of the address is the <i>host number</i>.
For example, in the Class C address 192.0.2.14, the network number is
hex C00002 and the host number is hex 0E.</p>
For example, in the Class C address 192.0.2.14, the network number
is hex C00002 and the host number is hex 0E.</p>
<p align="left">As the internet grew, it became clear that such a gross partitioning
of the 32-bit address space was going to be very limiting (early on, large
@ -638,9 +639,9 @@ the following table:</p>
</blockquote>
<p align="left">You will notice that the above table also contains a column
for (32 - log2 <b>n</b>). That number is the <i>Variable Length
Subnet Mask</i> for a network of size <b>n</b>. From the above table,
we can derive the following one which is a little easier to use.</p>
for (32 - log2 <b>n</b>). That number is the <i>Variable Length Subnet
Mask</i> for a network of size <b>n</b>. From the above table, we
can derive the following one which is a little easier to use.</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -732,13 +733,13 @@ we can derive the following one which is a little easier to use.</p>
</blockquote>
<p align="left">Notice that the VLSM is written with a slash ("/") -- you
will often hear a subnet of size 64 referred to as a "slash 26"
subnet and one of size 8 referred to as a "slash 29".</p>
will often hear a subnet of size 64 referred to as a "slash 26" subnet
and one of size 8 referred to as a "slash 29".</p>
<p align="left">The subnet's mask (also referred to as its <i>netmask) </i>is
simply a 32-bit number with the first "VLSM" bits set to one and
the remaining bits set to zero. For example, for a subnet of size
64, the subnet mask has 26 leading one bits:</p>
the remaining bits set to zero. For example, for a subnet of size 64,
the subnet mask has 26 leading one bits:</p>
<blockquote>
<p align="left">11111111111111111111111111000000 = FFFFFFC0 = FF.FF.FF.C0
@ -821,15 +822,29 @@ useful in routing.</p>
and the set of all possible IP addresses is written <b>0.0.0.0/0</b>.</p>
<p align="left">Later in this guide, you will see the notation <b>a.b.c.d/v</b>
used to describe the ip configuration of a network interface (the
'ip' utility also uses this syntax). This simply means that the interface
used to describe the ip configuration of a network interface (the 'ip'
utility also uses this syntax). This simply means that the interface
is configured with ip address <b>a.b.c.d</b> and with the netmask that
corresponds to VLSM <b>/v</b>.</p>
<p align="left">Example: 192.0.2.65/29</p>
<p align="left">    The interface is configured with IP address 192.0.2.65
and netmask 255.255.255.248.</p>
and netmask 255.255.255.248.<br>
</p>
<p align="left">Beginning with Shorewall 1.4.6, /sbin/shorewall supports
an <b>ipcalc</b> command that automatically calculates information about
a [sub]network.<br>
</p>
<p align="left">Example 1:<br>
</p>
<blockquote>
<pre><b><font color="#009900">ipcalc 10.10.10.0/25<br></font></b> CIDR=10.10.10.0/25<br> NETMASK=255.255.255.128<br> NETWORK=10.10.10.0<br> BROADCAST=10.10.10.127<br></pre>
</blockquote>
Example 2
<blockquote>
<pre><b><font color="#009900">ipcalc 10.10.10.0 255.255.255.128</font></b><br> CIDR=10.10.10.0/25<br> NETMASK=255.255.255.128<br> NETWORK=10.10.10.0<br> BROADCAST=10.10.10.127<br></pre>
</blockquote>
<h3 align="left"><a name="Routing"></a>4.3 Routing</h3>
@ -853,13 +868,13 @@ useful in routing.</p>
route</i> and the gateway mentioned in that route is called the <i>default
gateway</i>.</p>
<p align="left">When the kernel is trying to send a packet to IP address <b>A</b>,
it starts at the top of the routing table and:</p>
<p align="left">When the kernel is trying to send a packet to IP address
<b>A</b>, it starts at the top of the routing table and:</p>
<ul>
<li>
<p align="left"><b>A</b> is logically ANDed with the 'Genmask' value in
the table entry.</p>
<p align="left"><b>A</b> is logically ANDed with the 'Genmask' value
in the table entry.</p>
</li>
<li>
<p align="left">The result is compared with the 'Destination' value in
@ -888,10 +903,10 @@ the table entry.</p>
</ul>
<p align="left">Since the default route matches any IP address (<b>A</b> land
0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing table
entries are sent to the <i>default gateway</i> which is usually a router
at your ISP.</p>
<p align="left">Since the default route matches any IP address (<b>A</b>
land 0.0.0.0 = 0.0.0.0), packets that don't match any of the other routing
table entries are sent to the <i>default gateway</i> which is usually a
router at your ISP.</p>
<p align="left">Lets take an example. Suppose that we want to route a packet
to 192.168.1.5. That address clearly doesn't match any of the host
@ -903,17 +918,18 @@ routes in the table but if we logically and that address with 255.255.255.
<pre>192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2</pre>
</blockquote>
<p>So to route a packet to 192.168.1.5, the packet is sent directly over eth2.</p>
<p>So to route a packet to 192.168.1.5, the packet is sent directly over
eth2.</p>
</div>
<p align="left">One more thing needs to be emphasized -- all outgoing packet
are sent using the routing table and reply packets are not a special
case. There seems to be a common mis-conception whereby people think
that request packets are like salmon and contain a genetic code that
is magically transferred to reply packets so that the replies follow the
reverse route taken by the request. That isn't the case; the replies may
take a totally different route back to the client than was taken by the
requests -- they are totally independent.</p>
is magically transferred to reply packets so that the replies follow
the reverse route taken by the request. That isn't the case; the replies
may take a totally different route back to the client than was taken by
the requests -- they are totally independent.</p>
<h3 align="left"><a name="ARP"></a>4.4 Address Resolution Protocol (ARP)</h3>
@ -930,9 +946,9 @@ obtain the MAC of an Ethernet device using the 'ip' utility:</p>
</blockquote>
<div align="left">
<p align="left">As you can see from the above output, the MAC is 6 bytes (48
bits) wide. A card's MAC is usually also printed on a label attached to
the card itself. </p>
<p align="left">As you can see from the above output, the MAC is 6 bytes
(48 bits) wide. A card's MAC is usually also printed on a label attached
to the card itself. </p>
</div>
<div align="left">
@ -968,10 +984,10 @@ the card itself. </p>
<p align="left">The leading question marks are a result of my having specified
the 'n' option (Windows 'arp' doesn't allow that option) which causes
the 'arp' program to forego IP-&gt;DNS name translation. Had I not
given that option, the question marks would have been replaced with
the FQDN corresponding to each IP address. Notice that the last entry
in the table records the information we saw using tcpdump above.</p>
the 'arp' program to forego IP-&gt;DNS name translation. Had I not given
that option, the question marks would have been replaced with the FQDN
corresponding to each IP address. Notice that the last entry in the
table records the information we saw using tcpdump above.</p>
<h3 align="left"><a name="RFC1918"></a>4.5 RFC 1918</h3>
@ -985,10 +1001,10 @@ for sub-Sahara Africa is delegated to the <i><a
Most of us don't deal with these registrars but rather get our IP addresses
from our ISP.</p>
<p align="left">It's a fact of life that most of us can't afford as many Public
IP addresses as we have devices to assign them to so we end up making use
of <i> Private </i>IP addresses. RFC 1918 reserves several IP address ranges
for this purpose:</p>
<p align="left">It's a fact of life that most of us can't afford as many
Public IP addresses as we have devices to assign them to so we end up making
use of <i> Private </i>IP addresses. RFC 1918 reserves several IP address
ranges for this purpose:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
@ -996,10 +1012,10 @@ for this purpose:</p>
<div align="left">
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers
don't forward packets which have an RFC-1918 destination address.
This is understandable given that anyone can select any of these
addresses for their private use.</p>
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. This
is understandable given that anyone can select any of these addresses
for their private use.</p>
</div>
<div align="left">
@ -1010,8 +1026,8 @@ addresses for their private use.</p>
<div align="left">
<ul>
<li>
<p align="left">As the IPv4 address space becomes depleted, more and more
organizations (including ISPs) are beginning to use RFC 1918 addresses
<p align="left">As the IPv4 address space becomes depleted, more and
more organizations (including ISPs) are beginning to use RFC 1918 addresses
in their infrastructure. </p>
</li>
<li>
@ -1025,8 +1041,8 @@ addresses for their private use.</p>
<div align="left">
<p align="left">So it's a good idea to check with your ISP to see if they
are using (or are planning to use) private addresses before you
decide the addresses that you are going to use.</p>
are using (or are planning to use) private addresses before you decide
the addresses that you are going to use.</p>
</div>
<div align="left">
@ -1086,12 +1102,12 @@ IP address of your firewall/router's external interface. </p>
<div align="left">
<p align="left">Let's assume that your ISP has assigned you the subnet 192.0.2.64/28
routed through 192.0.2.65. That means that you have IP addresses 192.0.2.64
- 192.0.2.79 and that your firewall's external IP address is 192.0.2.65.
Your ISP has also told you that you should use a netmask of 255.255.255.0
(so your /28 is part of a larger /24). With this many IP addresses,
you are able to subnet your /28 into two /29's and set up your network
as shown in the following diagram.</p>
routed through 192.0.2.65. That means that you have IP addresses
192.0.2.64 - 192.0.2.79 and that your firewall's external IP address
is 192.0.2.65. Your ISP has also told you that you should use a netmask
of 255.255.255.0 (so your /28 is part of a larger /24). With this
many IP addresses, you are able to subnet your /28 into two /29's
and set up your network as shown in the following diagram.</p>
</div>
<div align="left">
@ -1101,10 +1117,10 @@ IP address of your firewall/router's external interface. </p>
</div>
<div align="left">
<p align="left">Here, the DMZ comprises the subnet 192.0.2.64/29 and the Local
network is 192.0.2.72/29. The default gateway for hosts in the DMZ would
be configured to 192.0.2.66 and the default gateway for hosts in the local
network would be 192.0.2.73.</p>
<p align="left">Here, the DMZ comprises the subnet 192.0.2.64/29 and the
Local network is 192.0.2.72/29. The default gateway for hosts in the DMZ
would be configured to 192.0.2.66 and the default gateway for hosts in
the local network would be 192.0.2.73.</p>
</div>
<div align="left">
@ -1133,18 +1149,18 @@ The routing table on DMZ 1 will look like this:</p>
<div align="left">
<p align="left">This means that DMZ 1 will send an ARP "who-has 192.0.2.65"
request and no device on the DMZ Ethernet segment has that IP address.
Oddly enough, the firewall will respond to the request with the
MAC address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet
Oddly enough, the firewall will respond to the request with the MAC
address of its <u>DMZ Interface!!</u> DMZ 1 can then send Ethernet
frames addressed to that MAC address and the frames will be received
(correctly) by the firewall/router.</p>
</div>
<div align="left">
<p align="left">It is this rather unexpected ARP behavior on the part of the
Linux Kernel that prompts the warning earlier in this guide regarding the
connecting of multiple firewall/router interfaces to the same hub or switch.
When an ARP request for one of the firewall/router's IP addresses is sent
by another system connected to the hub/switch, all of the firewall's
<p align="left">It is this rather unexpected ARP behavior on the part of
the Linux Kernel that prompts the warning earlier in this guide regarding
the connecting of multiple firewall/router interfaces to the same hub
or switch. When an ARP request for one of the firewall/router's IP addresses
is sent by another system connected to the hub/switch, all of the firewall's
interfaces that connect to the hub/switch can respond! It is then
a race as to which "here-is" response reaches the sender first.</p>
</div>
@ -1154,16 +1170,16 @@ by another system connected to the hub/switch, all of the firewall's
</div>
<div align="left">
<p align="left">If you have the above situation but it is non-routed, you
can configure your network exactly as described above with one additional
<p align="left">If you have the above situation but it is non-routed,
you can configure your network exactly as described above with one additional
twist; simply specify the "proxyarp" option on all three firewall
interfaces in the /etc/shorewall/interfaces file.</p>
</div>
<div align="left">
<p align="left">Most of us don't have the luxury of having enough public IP
addresses to set up our networks as shown in the preceding example (even
if the setup is routed). </p>
<p align="left">Most of us don't have the luxury of having enough public
IP addresses to set up our networks as shown in the preceding example
(even if the setup is routed). </p>
</div>
<div align="left">
@ -1201,8 +1217,8 @@ if the setup is routed). </p>
</div>
<div align="left">
<p align="left">Often a combination of these techniques is used. Each of these
will be discussed in the sections that follow.</p>
<p align="left">Often a combination of these techniques is used. Each of
these will be discussed in the sections that follow.</p>
</div>
<div align="left">
@ -1215,9 +1231,9 @@ if the setup is routed). </p>
a connection to host <b>B</b> on the internet, the firewall/router
rewrites the IP header in the request to use one of your public IP
addresses as the source address. When <b>B</b> responds and the response
is received by the firewall, the firewall changes the destination address
back to the RFC 1918 address of <b>A</b> and forwards the response back
to <b>A.</b></p>
is received by the firewall, the firewall changes the destination
address back to the RFC 1918 address of <b>A</b> and forwards the response
back to <b>A.</b></p>
</div>
<div align="left">
@ -1276,10 +1292,10 @@ if the setup is routed). </p>
<p align="left">This example used the normal technique of assigning the same
public IP address for the firewall external interface and for SNAT.
If you wanted to use a different IP address, you would either have
to use your distributions network configuration tools to add that IP
address to the external interface or you could set ADD_SNAT_ALIASES=Yes
in /etc/shorewall/shorewall.conf and Shorewall will add the address for
you.</p>
to use your distributions network configuration tools to add that
IP address to the external interface or you could set ADD_SNAT_ALIASES=Yes
in /etc/shorewall/shorewall.conf and Shorewall will add the address
for you.</p>
</div>
<div align="left">
@ -1342,9 +1358,9 @@ on her system "Local 3". You could allow connections to the internet
</div>
<div align="left">
<p align="left">This example used the firewall's external IP address for DNAT.
You can use another of your public IP addresses but Shorewall will not
add that address to the firewall's external interface for you.</p>
<p align="left">This example used the firewall's external IP address for
DNAT. You can use another of your public IP addresses but Shorewall will
not add that address to the firewall's external interface for you.</p>
</div>
<div align="left">
@ -1358,8 +1374,8 @@ add that address to the firewall's external interface for you.</p>
<div align="left">
<ul>
<li>
<p align="left">A host <b>H </b>behind your firewall is assigned one of
your public IP addresses (<b>A)</b> and is assigned the same netmask
<p align="left">A host <b>H </b>behind your firewall is assigned one
of your public IP addresses (<b>A)</b> and is assigned the same netmask
<b>(M) </b>as the firewall's external interface. </p>
</li>
<li>
@ -1367,9 +1383,9 @@ your public IP addresses (<b>A)</b> and is assigned the same netmask
</p>
</li>
<li>
<p align="left">When <b>H</b> issues an ARP "who has" request for an address
in the subnetwork defined by <b>A</b> and <b>M</b>, the firewall will
respond (with the MAC if the firewall interface to <b>H</b>). </p>
<p align="left">When <b>H</b> issues an ARP "who has" request for an
address in the subnetwork defined by <b>A</b> and <b>M</b>, the firewall
will respond (with the MAC if the firewall interface to <b>H</b>). </p>
</li>
</ul>
@ -1457,9 +1473,9 @@ file.</div>
<div align="left">
<p align="left">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:<br>
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:<br>
</p>
<ol>
@ -1471,21 +1487,20 @@ the internet. There are a couple of things that you can try:<br>
the MAC address for its own IP; in addition to ensuring that the IP address
isn't a duplicate,...<br>
<br>
"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."<br>
"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."<br>
<br>
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 static NAT for that matter). Happily enough, recent versions
of Redhat's iputils package include "arping", whose "-U" flag does just
that:<br>
ARP (or static NAT for that matter). Happily enough, recent versions of
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly
proxied IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for
example</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 #
for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly
to gratuitous ARPs, but googling for "arping -U" seems to support the
@ -1497,9 +1512,9 @@ ARP cache entry but many either can't or won't purge individual entries.
</ol>
You can determine if your ISP'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 192.0.2.177. On the firewall,
run tcpdump as follows:</div>
using ping and tcpdump. Suppose that we suspect that the gateway router
has a stale ARP cache entry for 192.0.2.177. On the firewall, run
tcpdump as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
@ -1526,10 +1541,10 @@ run tcpdump as follows:</div>
<div align="left">
<p align="left">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's eth0 NIC while
0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the
gateway's ARP cache still associates 192.0.2.177 with the NIC in
DMZ 1 rather than with the firewall's eth0.</p>
this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC
while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words,
the gateway's ARP cache still associates 192.0.2.177 with the NIC
in DMZ 1 rather than with the firewall's eth0.</p>
</div>
<div align="left">
@ -1538,9 +1553,9 @@ DMZ 1 rather than with the firewall's eth0.</p>
<div align="left">
<p align="left">With static NAT, you assign local systems RFC 1918 addresses
then establish a one-to-one mapping between those addresses and
public IP addresses. For outgoing connections SNAT (Source Network
Address Translation) occurs and on incoming connections DNAT (Destination
then establish a one-to-one mapping between those addresses and public
IP addresses. For outgoing connections SNAT (Source Network Address
Translation) occurs and on incoming connections DNAT (Destination
Network Address Translation) occurs. Let's go back to our earlier example
involving your daughter's web server running on system Local 3.</p>
</div>
@ -1666,29 +1681,28 @@ the internet. There are a couple of things that you can try:<br>
</p>
<ol>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP
Illustrated, Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP'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't a duplicate,...<br>
<br>
"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."<br>
"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."<br>
<br>
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 static NAT for that matter). Happily enough, recent versions
of Redhat's iputils package include "arping", whose "-U" flag does just
that:<br>
ARP (or static NAT for that matter). Happily enough, recent versions of
Redhat's iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly
proxied IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for
example</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 #
for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly
to gratuitous ARPs, but googling for "arping -U" seems to support the
@ -1700,9 +1714,9 @@ that:<br>
</ol>
You can determine if your ISP'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 209.0.2.179. On the firewall,
run tcpdump as follows:</div>
using ping and tcpdump. Suppose that we suspect that the gateway router
has a stale ARP cache entry for 209.0.2.179. On the firewall, run
tcpdump as follows:</div>
<div align="left">
<pre> <font color="#009900"><b>tcpdump -nei eth0 icmp</b></font></pre>
@ -1729,10 +1743,10 @@ we will assume is 192.0.2.254):</p>
<div align="left">
<p align="left">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's eth0 NIC while
0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words, the
gateway's ARP cache still associates 192.0.2.179 with the NIC in
the local zone rather than with the firewall's eth0.</p>
this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC
while 0:c0:a8:50:b2:57 was the MAC address of DMZ 1. In other words,
the gateway's ARP cache still associates 192.0.2.179 with the NIC
in the local zone rather than with the firewall's eth0.</p>
</div>
<h3 align="left"><a name="Rules"></a>5.3 Rules</h3>
@ -1746,8 +1760,8 @@ the local zone rather than with the firewall's eth0.</p>
any other host (including the firewall). With the exception of <a
href="#DNAT">DNAT rules</a> which cause address translation and allow
the translated connection request to pass through the firewall, the
way to allow connection requests through your firewall is to use
ACCEPT rules.</p>
way to allow connection requests through your firewall is to use ACCEPT
rules.</p>
</div>
<div align="left">
@ -1902,8 +1916,8 @@ ACCEPT rules.</p>
</div>
<div align="left">
<p align="left">If you run a public DNS server on 192.0.2.177, you would need
to add the following rules:</p>
<p align="left">If you run a public DNS server on 192.0.2.177, you would
need to add the following rules:</p>
</div>
<div align="left">
@ -1991,9 +2005,8 @@ ACCEPT rules.</p>
<div align="left">
<p align="left">You probably want some way to communicate with your firewall
and DMZ systems from the local network -- I recommend SSH which
through its scp utility can also do publishing and software update
distribution.</p>
and DMZ systems from the local network -- I recommend SSH which through
its scp utility can also do publishing and software update distribution.</p>
</div>
<div align="left">
@ -2036,10 +2049,10 @@ distribution.</p>
</div>
<div align="left">
<p align="left">The above discussion reflects my personal preference for using
Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems. I
prefer to use NAT only in cases where a system that is part of an RFC 1918
subnet needs to have it's own public IP. </p>
<p align="left">The above discussion reflects my personal preference for
using Proxy ARP for my servers in my DMZ and SNAT/NAT for my local systems.
I prefer to use NAT only in cases where a system that is part of an RFC
1918 subnet needs to have it's own public IP. </p>
</div>
<div align="left">
@ -2054,13 +2067,14 @@ Shorewall can do.</p>
</div>
<div align="left">
<p align="left">In case you haven't been keeping score, here's the final set
of configuration files for our sample network. Only those that were modified
from the original installation are shown.</p>
<p align="left">In case you haven't been keeping score, here's the final
set of configuration files for our sample network. Only those that were
modified from the original installation are shown.</p>
</div>
<div align="left">
<p align="left">/etc/shorewall/interfaces (The "options" will be very site-specific).</p>
<p align="left">/etc/shorewall/interfaces (The "options" will be very
site-specific).</p>
</div>
<div align="left">
@ -2440,10 +2454,10 @@ bring up Shorewall before you bring up your network interfaces.</p>
</div>
<div align="left">
<p align="left">Given the collection of RFC 1918 and public addresses in this
setup, it only makes sense to have separate internal and external DNS
servers. You can combine the two into a single BIND 9 server using <i>Views.
</i> If you are not interested in Bind 9 views, you can <a
<p align="left">Given the collection of RFC 1918 and public addresses in
this setup, it only makes sense to have separate internal and external
DNS servers. You can combine the two into a single BIND 9 server using
<i>Views. </i> If you are not interested in Bind 9 views, you can <a
href="#StartingAndStopping">go to the next section</a>.</p>
</div>
@ -2583,9 +2597,9 @@ servers. You can combine the two into a single BIND 9 server using <i>Views.
and stopped using "shorewall stop". When the firewall is stopped,
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
running firewall may be restarted using the "shorewall restart" command.
If you want to totally remove any trace of Shorewall from your Netfilter
configuration, use "shorewall clear".</p>
</div>
<div align="left">
@ -2607,11 +2621,12 @@ to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 6/27/2003 - <a
<p align="left"><font size="2">Last updated 7/6/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Easte</font></a><br>
</p>
<br>
</body>
</html>

247
Shorewall-docs/sourceforge_index.htm
View File

@ -45,6 +45,7 @@
</tr>
</tbody>
</table>
@ -83,18 +84,18 @@
<p>This program is free software; you can redistribute it and/or modify
it under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the
GNU General Public License</a> as published by the Free Software
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
General Public License</a> as published by the Free Software
Foundation.<br>
<br>
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 details.<br>
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 details.<br>
<br>
@ -114,60 +115,81 @@ Inc., 675 Mass Ave, Cambridge, MA 02139, USA</p>
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not apply
directly to your setup. If you want to use the documentation that
you find here, you will want to consider uninstalling what you have and
installing a setup that matches the documentation on this site. See
the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.<br>
<h2>Getting Started with Shorewall</h2>
New to Shorewall? Start by selecting the <a
href="shorewall_quickstart_guide.htm">QuickStart Guide</a> that most closely
match your environment and follow the step by step instructions.<br>
href="file:///vfat/Shorewall-docs/shorewall_quickstart_guide.htm">QuickStart
Guide</a> that most closely match your environment and follow
the step by step instructions.<br>
<h2>Looking for Information?</h2>
The <a href="shorewall_quickstart_guide.htm#Documentation">Documentation
Index</a> is a good place to start as is the Quick Search to your right.
<h2>Running Shorewall on Mandrake with a two-interface setup?</h2>
If so, the documentation<b> </b>on this site will not
apply directly to your setup. If you want to use the documentation
that you find here, you will want to consider uninstalling what you have
and installing a setup that matches the documentation on this site.
See the <a href="two-interface.htm">Two-interface QuickStart Guide</a>
for details.
<h2></h2>
<h2><b>News</b></h2>
<b> </b>
<p><b>7/4/2003 - Shorewall-1.4.6 Beta 1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
<p><b>7/7/2003 - Shorewall-1.4.6 Beta 2</b><b> <img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
<br>
</b></p>
<blockquote><a href="http://shorewall.net/pub/shorewall/testing">http://shorewall.net/pub/shorewall/testing</a><br>
<a href="ftp://shorewall.net/pub/shorewall/testing" target="_top">ftp://shorewall.net/pub/shorewall/testing</a><br>
</blockquote>
<p><b>Problems Corrected:</b><br>
</p>
<ol>
<li>A problem seen on RH7.3 systems where Shorewall encountered
start errors when started using the "service" mechanism has been worked around.<br>
<li>A problem seen on RH7.3 systems where Shorewall encountered start
errors when started using the "service" mechanism has been worked around.<br>
<br>
</li>
<li>Previously, where a list of IP addresses appears in the DEST
column of a DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules
in the nat table (one for each element in the list). Shorewall now correctly
creates a single DNAT rule with multiple "--to-destination" clauses.<br>
<li>Where a list of IP addresses appears in the DEST column of a
DNAT[-] rule, Shorewall incorrectly created multiple DNAT rules in the nat
table (one for each element in the list). Shorewall now correctly creates
a single DNAT rule with multiple "--to-destination" clauses.<br>
<br>
</li>
<li>Corrected a problem in Beta 1 where DNS names containing a "-"
were mis-handled when they appeared in the DEST column of a rule.<br>
</li>
</ol>
<p><b>Migration Issues:</b><br>
</p>
<ol>
<li>In earlier versions, an undocumented feature allowed entries
in the host file as follows:<br>
<br>
    z    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
    z   eth1:192.168.1.0/24,192.168.2.0/24<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
removed from /etc/shorewall/shorewall.conf. These capabilities are now automatically
detected by Shorewall (see below).<br>
</li>
</ol>
<p><b>New Features:</b><br>
</p>
<ol>
<li>A 'newnotsyn' interface option has been added. This option
may be specified in /etc/shorewall/interfaces and overrides the setting
NEWNOTSYN=No for packets arriving on the associated interface.<br>
<li>A 'newnotsyn' interface option has been added. This option may
be specified in /etc/shorewall/interfaces and overrides the setting NEWNOTSYN=No
for packets arriving on the associated interface.<br>
<br>
</li>
<li>The means for specifying a range of IP addresses in /etc/shorewall/masq
@ -179,24 +201,18 @@ NEWNOTSYN=No for packets arriving on the associated interface.<br>
first one on an interface.<br>
<br>
</li>
<li>DNAT[-] rules may now be used to load balance (round-robin)
over a set of servers. Up to 256 servers may be specified in a range of addresses
given as &lt;first address&gt;-&lt;last address&gt;.<br>
<li>DNAT[-] rules may now be used to load balance (round-robin) over
a set of servers. Servers may be specified in a range of addresses given
as &lt;first address&gt;-&lt;last address&gt;.<br>
<br>
Example:<br>
<br>
    DNAT net loc:192.168.10.2-192.168.10.5 tcp 80<br>
<br>
Note that this capability has previously been available using a combination
of a DNAT- rule and one or more ACCEPT rules. That technique is still preferable
for load-balancing over a large number of servers (&gt; 16) since specifying
a range in the DNAT rule causes one filter table ACCEPT rule to be generated
for each IP address in the range.<br>
<br>
</li>
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration
options have been removed and have been replaced by code that detects whether
these capabilities are present in the current kernel. The output of the start,
<li>The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT configuration options
have been removed and have been replaced by code that detects whether these
capabilities are present in the current kernel. The output of the start,
restart and check commands have been enhanced to report the outcome:<br>
<br>
Shorewall has detected the following iptables/netfilter capabilities:<br>
@ -218,11 +234,10 @@ and check commands.<br>
   Packet Mangling: Available<br>
   Multi-port Match: Available<br>
   Connection Tracking Match: Available<br>
   Verifying Configuration...<br>
Verifying Configuration...<br>
<br>
If this extension is available, the ruleset generated by Shorewall is
changed in the following ways:</li>
If this extension is available, the ruleset generated by Shorewall is changed
in the following ways:</li>
<ul>
<li>To handle 'norfc1918' filtering, Shorewall will not create
chains in the mangle table but will rather do all 'norfc1918' filtering
@ -234,10 +249,76 @@ in the filter table (rfc1918 chain).</li>
defaulted to) in the DNAT rule.<br>
<br>
</li>
</ul>
<li>The shell used to interpret the firewall script (/usr/share/shorewall/firewall)
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.</li>
may now be specified using the SHOREWALL_SHELL parameter in shorewall.conf.<br>
<br>
</li>
<li>An 'ipcalc' command has been added to /sbin/shorewall.<br>
<br>
      ipcalc [ &lt;address&gt; &lt;netmask&gt; | &lt;address&gt;/&lt;vlsm&gt;
]<br>
<br>
Examples:<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0/24<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
      [root@wookie root]# shorewall ipcalc 192.168.1.0 255.255.255.0<br>
         CIDR=192.168.1.0/24<br>
         NETMASK=255.255.255.0<br>
         NETWORK=192.168.1.0<br>
         BROADCAST=192.168.1.255<br>
      [root@wookie root]#<br>
<br>
Warning:<br>
<br>
If your shell only supports 32-bit signed arithmatic (ash or dash), then
the ipcalc command produces incorrect information for IP addresses 128.0.0.0-1
and for /1 networks. Bash should produce correct information for all valid
IP addresses.<br>
<br>
</li>
<li>An 'iprange' command has been added to /sbin/shorewall. <br>
<br>
      iprange &lt;address&gt;-&lt;address&gt;<br>
<br>
This command decomposes a range of IP addressses into a list of network
and host addresses. The command can be useful if you need to construct an
efficient set of rules that accept connections from a range of network addresses.<br>
<br>
Note: If your shell only supports 32-bit signed arithmetic (ash or dash)
then the range may not span 128.0.0.0.<br>
<br>
Example:<br>
<br>
      [root@gateway root]# shorewall iprange 192.168.1.4-192.168.12.9<br>
      192.168.1.4/30<br>
      192.168.1.8/29<br>
      192.168.1.16/28<br>
      192.168.1.32/27<br>
      192.168.1.64/26<br>
      192.168.1.128/25<br>
      192.168.2.0/23<br>
      192.168.4.0/22<br>
      192.168.8.0/22<br>
      192.168.12.0/29<br>
      192.168.12.8/31<br>
      [root@gateway root]#<br>
<br>
</li>
<li>A list of host/net addresses is now allowed in an entry in /etc/shorewall/hosts.<br>
<br>
Example:<br>
<br>
    foo    eth1:192.168.1.0/24,192.168.2.0/24</li>
</ol>
<b> </b>
<ol>
</ol>
@ -247,10 +328,10 @@ in the filter table (rfc1918 chain).</li>
</p>
<ol>
<li>The command "shorewall debug try &lt;directory&gt;" now correctly
traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones file;
previously, INCLUDE in that file was ignored.</li>
<li>The command "shorewall debug try &lt;directory&gt;" now
correctly traces the attempt.</li>
<li>The INCLUDE directive now works properly in the zones
file; previously, INCLUDE in that file was ignored.</li>
<li>/etc/shorewall/routestopped records with an empty second
column are no longer ignored.<br>
</li>
@ -262,21 +343,22 @@ column are no longer ignored.<br>
<ol>
<li>The ORIGINAL DEST column in a DNAT[-] or REDIRECT[-] rule
may now contain a list of addresses. If the list begins with "!' then the
rule will take effect only if the original destination address in the connection
request does not match any of the addresses listed.</li>
may now contain a list of addresses. If the list begins with "!' then
the rule will take effect only if the original destination address in
the connection request does not match any of the addresses listed.</li>
</ol>
<p><b>6/15/2003 - Shorewall, Kernel 2.4.21 and iptables 1.2.8</b><b>
</b></p>
The firewall at shorewall.net has been upgraded to the 2.4.21 kernel
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No problems
have been encountered with this set of software. The Shorewall version
is 1.4.4b plus the accumulated changes for 1.4.5.
and iptables 1.2.8 (using the "official" RPM from netfilter.org). No
problems have been encountered with this set of software. The Shorewall
version is 1.4.4b plus the accumulated changes for 1.4.5.
<p><b>6/8/2003 - Updated Samples</b><b> </b></p>
<p>Thanks to Francesca Smith, the samples have been updated to Shorewall
version 1.4.4.</p>
@ -296,6 +378,7 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
<p><b></b></p>
<blockquote>
@ -311,6 +394,7 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
<p><a href="file:///Z:/Shorewall-docs/News.htm"></a></p>
<b> </b>
@ -341,11 +425,12 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.2!!!
<b>Congratulations to Jacques
and Eric on the recent release of Bering 1.2!!!
</b><br>
<h1 align="center"><b><a href="http://www.sf.net"><img
align="left" alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
@ -383,20 +468,21 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
<p><strong><br>
<font color="#ffffff"><b>Note: </b></font></strong>
<font color="#ffffff">Search is unavailable Daily 0200-0330
GMT.</font><br>
<font color="#ffffff">Search is unavailable Daily
0200-0330 GMT.</font><br>
 </p>
<p><font color="#ffffff"><strong>Quick Search</strong></font><br>
<font face="Arial" size="-1"> <input
type="text" name="words" size="15"></font><font size="-1"> </font><font
face="Arial" size="-1"> <input type="hidden" name="format"
value="long"> <input type="hidden" name="method" value="and">
<input type="hidden" name="config" value="htdig"> <input
type="submit" value="Search"></font> </p>
<font face="Arial" size="-1">
<input type="text" name="words" size="15"></font><font
size="-1"> </font><font face="Arial" size="-1"> <input
type="hidden" name="format" value="long"> <input
type="hidden" name="method" value="and"> <input type="hidden"
name="config" value="htdig"> <input type="submit"
value="Search"></font> </p>
<font face="Arial"> <input
type="hidden" name="exclude"
value="[http://lists.shorewall.net/pipermail/*]"> </font>
@ -449,8 +535,8 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
<p align="center"><font size="4" color="#ffffff"><br>
<font size="+2">Shorewall is free but if you try it and
find it useful, please consider making a donation
<font size="+2">Shorewall is free but if you try it
and find it useful, please consider making a donation
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></font></p>
@ -465,11 +551,8 @@ is 1.4.4b plus the accumulated changes for 1.4.5.
</table>
<p><font size="2">Updated 7/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 7/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

159
Shorewall-docs/starting_and_stopping_shorewall.htm
View File

@ -14,47 +14,28 @@
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Starting/Stopping and Monitoring
the Firewall</font></h1>
</td>
</tr>
</tbody>
</table>
<p> If you have a permanent internet connection such as DSL or Cable,
I recommend that you start the firewall automatically at boot.
Once you have installed "firewall" in your init.d directory, simply
type "chkconfig --add firewall". This will start the firewall
in run levels 2-5 and stop it in run levels 1 and 6. If you want
to configure your firewall differently from this default, you can
use the "--level" option in chkconfig (see "man chkconfig") or using
your favorite graphical run-level editor.</p>
in run levels 2-5 and stop it in run levels 1 and 6. If you want to
configure your firewall differently from this default, you can use
the "--level" option in chkconfig (see "man chkconfig") or using your
favorite graphical run-level editor.</p>
<p><strong><u> <font color="#000099"> Important Notes:</font></u></strong><br>
</p>
@ -66,21 +47,16 @@ configured your firewall, you can enable startup by removing the file
edit /etc/default/shorewall and set 'startup=1'.<br>
</li>
<li>If you use dialup, you may want to start the firewall
in your /etc/ppp/ip-up.local script. I recommend just placing
"shorewall restart" in that script.</li>
in your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
restart" in that script.</li>
</ol>
<p>
</p>
<p> </p>
<p> You can manually start and stop Shoreline Firewall using the "shorewall"
shell program: </p>
<ul>
<li>shorewall start - starts the firewall</li>
<li>shorewall stop - stops the firewall</li>
@ -88,10 +64,10 @@ edit /etc/default/shorewall and set 'startup=1'.<br>
running) and then starts it again</li>
<li>shorewall reset - reset the packet and byte counters
in the firewall</li>
<li>shorewall clear - remove all rules and chains
installed by Shoreline Firewall</li>
<li>shorewall refresh - refresh the rules involving the broadcast
addresses of firewall interfaces, <a
<li>shorewall clear - remove all rules and chains installed
by Shoreline Firewall</li>
<li>shorewall refresh - refresh the rules involving the
broadcast addresses of firewall interfaces, <a
href="blacklisting_support.htm">the black list</a>, <a
href="traffic_shaping.htm">traffic control rules</a> and <a
href="ECN.html">ECN control rules</a>.</li>
@ -102,11 +78,8 @@ edit /etc/default/shorewall and set 'startup=1'.<br>
<pre> <font color="#009900"><b>shorewall debug start 2&gt; /tmp/trace</b></font><br></pre>
<p>The above command would trace the 'start' command and place the trace
information in the file /tmp/trace<br>
<p>The above command would trace the 'start' command and place the trace information
in the file /tmp/trace<br>
</p>
<p>The <a href="#StateDiagram">Shorewall State Diagram</a> is shown at the
@ -115,36 +88,36 @@ information in the file /tmp/trace<br>
<p>The "shorewall" program may also be used to monitor the firewall.</p>
<ul>
<li>shorewall status - produce a verbose report about the
firewall (iptables -L -n -v)</li>
<li>shorewall show <i>chain</i> - produce a verbose report
about <i>chain </i>(iptables -L <i>chain</i> -n -v)</li>
<li>shorewall show nat - produce a verbose report about the
nat table (iptables -t nat -L -n -v)</li>
<li>shorewall show tos - produce a verbose report about the
mangle table (iptables -t mangle -L -n -v)</li>
<li>shorewall show log - display the last 20 packet log entries.</li>
<li>shorewall show nat - produce a verbose report about
the nat table (iptables -t nat -L -n -v)</li>
<li>shorewall show tos - produce a verbose report about
the mangle table (iptables -t mangle -L -n -v)</li>
<li>shorewall show log - display the last 20 packet log
entries.</li>
<li>shorewall show connections - displays the IP connections
currently being tracked by the firewall.</li>
<li>shorewall
show
<li>shorewall show
tc - displays
information about the traffic control/shaping configuration.</li>
<li>shorewall monitor [ delay ] - Continuously display the
firewall status, last 20 log entries and nat. When the log
entry display changes, an audible alarm is sounded.</li>
<li>shorewall hits - Produces several reports about the Shorewall
packet log messages in the current /var/log/messages file.</li>
<li>shorewall hits - Produces several reports about the
Shorewall packet log messages in the current /var/log/messages
file.</li>
<li>shorewall version - Displays the installed version
number.</li>
<li>shorewall check - Performs a <u>cursory</u> validation of the
zones, interfaces, hosts, rules and policy files.<br>
<br>
<font size="4" color="#ff6666"><b>The "check" command is totally unsuppored
and does not parse and validate the generated iptables commands. Even
though the "check" command completes successfully, the configuration
and does not parse and validate the generated iptables commands.
Even though the "check" command completes successfully, the configuration
may fail to start. Problem reports that complain about errors that the 'check'
command does not detect will not be accepted.<br>
<br>
@ -152,10 +125,10 @@ command does not detect will not be accepted.<br>
<br>
</li>
<li>shorewall try<i> configuration-directory</i> [<i> timeout</i>
] - Restart shorewall using the specified configuration and if an
error occurs or if the<i> timeout </i> option is given and the new
configuration has been up for that many seconds then shorewall is
restarted using the standard configuration.</li>
] - Restart shorewall using the specified configuration and if
an error occurs or if the<i> timeout </i> option is given and the
new configuration has been up for that many seconds then shorewall
is restarted using the standard configuration.</li>
<li>shorewall deny, shorewall reject, shorewall accept and
shorewall save implement <a href="blacklisting_support.htm">dynamic
blacklisting</a>.</li>
@ -164,16 +137,26 @@ restarted using the standard configuration.</li>
new Shorewall messages are logged.</li>
</ul>
Finally, the "shorewall" program may be used to dynamically alter
the contents of a zone.<br>
Beginning with Shorewall 1.4.6, /sbin/shorewall supports a couple of commands
for dealing with IP addresses and IP address ranges:<br>
<ul>
<li>shorewall ipcalc [ <i>address mask </i>| <i>address/vlsm</i> ] - displays
the network address, broadcast address, network in CIDR notation and netmask
corresponding to the input[s].</li>
<li>shorewall iprange <i>address1-address2</i> - Decomposes the specified
range of IP addresses into the equivalent list of network/host addresses.
<br>
</li>
</ul>
Finally, the "shorewall" program may be used to dynamically alter the
contents of a zone.<br>
<ul>
<li>shorewall add <i>interface</i>[:<i>host]</i> <i>zone </i>-
Adds the specified interface (and host if included) to the specified
zone.</li>
<li>shorewall delete <i>interface</i>[:<i>host]</i> <i>zone </i>-
Deletes the specified interface (and host if included) from the specified
zone.</li>
Adds the specified interface (and host if included) to the specified zone.</li>
<li>shorewall delete <i>interface</i>[:<i>host]</i> <i>zone
</i>- Deletes the specified interface (and host if included) from
the specified zone.</li>
</ul>
@ -187,80 +170,50 @@ from zone vpn1<br>
</blockquote>
</blockquote>
<p> The <b>shorewall start</b>, <b>shorewall restart, shorewall check, </b>and
<b>shorewall try </b>commands allow you to specify which <a
href="configuration_file_basics.htm#Configs"> Shorewall configuration</a>
to use:</p>
<blockquote>
<p> shorewall [ -c <i>configuration-directory</i> ] {start|restart|check}<br>
shorewall try <i>configuration-directory</i></p>
</blockquote>
<p> If a <i>configuration-directory</i> is specified, each time that Shorewall
is going to use a file in /etc/shorewall it will first look in the
<i>configuration-directory</i> . If the file is present in the <i>configuration-directory</i>,
that file will be used; otherwise, the file in /etc/shorewall will be
used.</p>
<p> When changing the configuration of a production firewall, I recommend
the following:</p>
<ul>
<li><font color="#009900"><b>mkdir /etc/test</b></font></li>
<li><font color="#009900"><b>cd /etc/test</b></font></li>
<li>&lt;copy any files that you need to change from
/etc/shorewall to . and change them here&gt;</li>
<li>&lt;copy any files that you need to change
from /etc/shorewall to . and change them here&gt;</li>
<li><font color="#009900"><b>shorewall -c . check</b></font></li>
<li>&lt;correct any errors found by check and check again&gt;</li>
<li><font color="#009900"><b>/sbin/shorewall
try .</b></font></li>
<li><font
color="#009900"><b>/sbin/shorewall try .</b></font></li>
</ul>
<p> If the configuration starts but doesn't work, just "shorewall restart"
to restore the old configuration. If the new configuration fails
to start, the "try" command will automatically start the old one for
you.</p>
to restore the old configuration. If the new configuration fails to
start, the "try" command will automatically start the old one for you.</p>
<p> When the new configuration works then just </p>
<ul>
<li><font color="#009900"><b>cp * /etc/shorewall</b></font></li>
<li><font color="#009900"><b>cd</b></font></li>
<li><font color="#009900"><b>rm -rf /etc/test</b></font></li>
</ul>
<p><a name="StateDiagram"></a>The Shorewall State Diargram is depicted below.<br>
</p>
@ -274,7 +227,8 @@ you.</p>
You will note that the commands that result in state transitions
use the word "firewall" rather than "shorewall". That is because the actual
transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall
on Debian); /sbin/shorewall runs 'firewall" according to the following table:<br>
on Debian); /sbin/shorewall runs 'firewall" according to the following
table:<br>
<br>
<table cellpadding="2" cellspacing="2" border="1">
@ -328,14 +282,13 @@ use the word "firewall" rather than "shorewall". That is because the actual
</table>
<br>
<p><font size="2"> Updated 2/27/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 7/6/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

105
Shorewall-docs/support.htm
View File

@ -33,8 +33,8 @@
are a number of sources of Shorewall information. Please try
these before you post.
<ul>
<li>Shorewall versions earlier
that 1.3.0 are no longer supported.<br>
<li>Shorewall versions
earlier that 1.3.0 are no longer supported.<br>
</li>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
@ -42,18 +42,20 @@ these before you post.
Index</a><br>
</li>
<li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a> has
solutions to more than 20 common problems. </li>
The <a href="http://www.shorewall.net/FAQ.htm">FAQ</a>
has solutions to more than 20 common problems.
</li>
<li>
The <a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to
help you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/troubleshoot.htm">Troubleshooting</a>
Information contains a number of tips to help
you solve common problems. </li>
<li> The
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has
links to download updated components. </li>
<li> The
Site and Mailing List Archives search facility can locate
documents and posts about similar problems: </li>
<a href="http://www.shorewall.net/errata.htm"> Errata</a> has links
to download updated components. </li>
<li>
The Site and Mailing List Archives search facility can
locate documents and posts about similar problems:
</li>
</ul>
@ -116,10 +118,10 @@ links to download updated components. </li>
asking for <strong>free</strong> technical support.
Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. <em>Exact quoting </em> of error
messages, log entries, command output, and other output is better than
a paraphrase or summary.<br>
practices in writing and formatting your e-mail. Provide details
that we need if you expect good answers. <em>Exact quoting </em>
of error messages, log entries, command output, and other output is
better than a paraphrase or summary.<br>
<br>
</li>
<li>
@ -129,8 +131,8 @@ a paraphrase or summary.<br>
your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong>
include this information:</li>
<li>When reporting a problem,
<strong>ALWAYS</strong> include this information:</li>
</ul>
@ -148,13 +150,7 @@ your job for you.<br>
</ul>
<ul>
<li>the exact kernel version
you are running<br>
<br>
<font color="#009900"><b>uname
-a<br>
<br>
</b></font></li>
</ul>
@ -175,17 +171,11 @@ addr show<br>
<br>
<font color="#009900"><b>ip
route show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>If your kernel is modularized,
the exact output from<br>
<br>
<font color="#009900"><b>lsmod</b></font><br>
</li>
</ul>
@ -195,13 +185,14 @@ route show<br>
<ul>
<ul>
<li><font color="#ff0000"><u><i><big><b>If you are having
connection problems of any kind then:</b></big></i></u></font><br>
<li><font color="#ff0000"><u><i><big><b>THIS IS IMPORTANT!<br>
<br>
1. <b><font color="#009900">/sbin/shorewall
reset</font></b><br>
</b></big></i></u></font>If your problem is that some type of connection
to/from or through your firewall isn't working then please:<br>
<br>
2. Try the connection that is failing.<br>
1. <b><font color="#009900">/sbin/shorewall reset</font></b><br>
<br>
2. Try making the connection that is failing.<br>
<br>
3.<b><font color="#009900"> /sbin/shorewall
status &gt; /tmp/status.txt</font></b><br>
@ -228,15 +219,15 @@ status &gt; /tmp/status.txt</font></b><br>
information</strong> in an attempt to conceal your IP address,
netmask, nameserver addresses, domain name, etc. These aren't
secrets, and concealing them often misleads us (and 80% of the time,
a hacker could derive them anyway from information contained in
the SMTP headers of your post).<br>
a hacker could derive them anyway from information contained
in the SMTP headers of your post).<br>
<br>
<strong></strong></li>
<li>Do you see any "Shorewall" messages
("<b><font color="#009900">/sbin/shorewall show log</font></b>")
when you exercise the function that is giving you problems?
If so, include the message(s) in your post along with a copy of
your /etc/shorewall/interfaces file.<br>
If so, include the message(s) in your post along with a copy of your
/etc/shorewall/interfaces file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration
@ -268,27 +259,28 @@ etc. to the Mailing List -- your post will be rejected.</b><
<h2>When using the mailing list, please post in plain text</h2>
<blockquote> A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist
shorewall.net "for continuous abuse" because it has been my policy
to allow HTML in list posts!!<br>
<blockquote> A growing number of MTAs serving list subscribers are
rejecting all HTML traffic. At least one MTA has gone so far as to
blacklist shorewall.net "for continuous abuse" because it has been
my policy to allow HTML in list posts!!<br>
<br>
I think that blocking all HTML
is a Draconian way to control spam and that the ultimate
losers here are not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML
based e-mail". Nevertheless, to allow subscribers to receive
list posts as must as possible, I have now configured the list
server at shorewall.net to strip all HTML from outgoing posts.<br>
whose MTAs are bouncing all shorewall.net mail. As one list
subscriber wrote to me privately "These e-mail admin's need
to get a <i>(expletive deleted)</i> life instead of trying to
rid the planet of HTML based e-mail". Nevertheless, to allow
subscribers to receive list posts as must as possible, I have now
configured the list server at shorewall.net to strip all HTML from
outgoing posts.<br>
<br>
<big><font color="#cc0000"><b>If you run your own outgoing mail server
and it doesn't have a valid DNS PTR record, your email won't reach the lists
unless/until the postmaster notices that your posts are being rejected.
To avoid this problem, you should configure your MTA to forward posts to
shorewall.net through an MTA that <u>does</u> have a valid PTR record (such
as the one at your ISP). </b></font></big><br>
unless/until the postmaster notices that your posts are being rejected. To
avoid this problem, you should configure your MTA to forward posts to shorewall.net
through an MTA that <u>does</u> have a valid PTR record (such as the one
at your ISP). </b></font></big><br>
</blockquote>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
@ -320,11 +312,12 @@ as the one at your ISP). </b></font></big><br>
href="http://lists.shorewall.net">http://lists.shorewall.net</a><br>
</p>
<p align="left"><font size="2">Last Updated 6/24/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 7/6/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

145
Shorewall-docs/upgrade_issues.htm
View File

@ -56,12 +56,26 @@ are currently running.<br>
<h3> </h3>
<h3>Version &gt;= 1.4.6</h3>
The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed from
shorewall.conf. These capabilities are now automatically detected by Shorewall.<br>
<ul>
<li> The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
from shorewall.conf. These capabilities are now automatically detected by
Shorewall.</li>
<li>An undocumented <i>feature</i> previously allowed entries in the host
file as follows:<br>
<br>
<i>zone</i>    eth1:192.168.1.0/24,eth2:192.168.2.0/24<br>
<br>
This capability was never documented and has been removed in 1.4.6 to allow
entries of the following format:<br>
<br>
<i>zone</i>   eth1:192.168.1.0/24,192.168.2.0/24<br>
</li>
</ul>
<h3>Version &gt;= 1.4.4</h3>
If you are upgrading from 1.4.3 and have set the LOGMARKER variable in
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then you
must set the new LOGFORMAT variable appropriately and remove your setting
<a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>, then
you must set the new LOGFORMAT variable appropriately and remove your setting
of LOGMARKER<br>
<br>
@ -78,8 +92,8 @@ Upgrade to Version 1.4.4a to fix this problem..<br>
<ol>
<li><a href="FAQ.htm#faq2">In FAQ #2</a>.</li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a transparent
proxy in your local zone.</a></li>
<li><a href="Shorewall_Squid_Usage.html">When running Squid as a
transparent proxy in your local zone.</a></li>
</ol>
If you have either of these cases, you will want to review the current
@ -89,14 +103,14 @@ Upgrade to Version 1.4.4a to fix this problem..<br>
<ul>
<li>Beginning with Version 1.4.1, traffic between groups in the
same zone is accepted by default. Previously, traffic from a zone to
itself was treated just like any other traffic; any matching rules were
applied followed by enforcement of the appropriate policy. With 1.4.1
and later versions, unless you have explicit rules for traffic from Z
to Z or you have an explicit Z to Z policy (where "Z" is some zone) then
traffic between the groups in zone Z will be accepted. If you do have one
or more explicit rules for Z to Z or if you have an explicit Z to Z policy
then the behavior is as it was in prior versions.</li>
same zone is accepted by default. Previously, traffic from a zone to itself
was treated just like any other traffic; any matching rules were applied
followed by enforcement of the appropriate policy. With 1.4.1 and later
versions, unless you have explicit rules for traffic from Z to Z or you
have an explicit Z to Z policy (where "Z" is some zone) then traffic between
the groups in zone Z will be accepted. If you do have one or more explicit
rules for Z to Z or if you have an explicit Z to Z policy then the behavior
is as it was in prior versions.</li>
</ul>
@ -109,8 +123,8 @@ then the behavior is as it was in prior versions.</li>
Z-&gt;Z rules then your configuration should not require any change.</li>
<li>If you are currently relying on a implicit policy (one that
has "all" in either the SOURCE or DESTINATION column) to prevent traffic
between two interfaces to a zone Z and you have no rules for Z-&gt;Z then
you should add an explicit DROP or REJECT policy for Z to Z.<br>
between two interfaces to a zone Z and you have no rules for Z-&gt;Z
then you should add an explicit DROP or REJECT policy for Z to Z.<br>
</li>
</ol>
@ -144,11 +158,11 @@ is asymetric routing where only the traffic on one direction flows through
</h3>
<ul>
<li>In Version 1.4.1, Shorewall will never create rules to deal
with traffic from a given group back to itself. The <i>multi</i> interface
option is no longer available so if you want to route traffic between
two subnetworks on the same interface then I recommend that you upgrade
to Version 1.4.2 and use the 'routeback' interface or host option. </li>
<li>In Version 1.4.1, Shorewall will never create rules to
deal with traffic from a given group back to itself. The <i>multi</i>
interface option is no longer available so if you want to route traffic
between two subnetworks on the same interface then I recommend that you
upgrade to Version 1.4.2 and use the 'routeback' interface or host option. </li>
</ul>
@ -185,8 +199,8 @@ there are entries for the zone in both files.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules
is no longer accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf
is no longer supported. Shorewall 1.4 behavior is the same as 1.3 with
ALLOWRELATED=Yes.</li>
is no longer supported. Shorewall 1.4 behavior is the same as 1.3
with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are now dropped
by default; there is no need for your own /etc/shorewall/common file
simply to avoid logging these packets.</li>
@ -220,18 +234,18 @@ file.</li>
<blockquote>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to
or from the destination zone. An explicit policy names both zones and
does not use the 'all' reserved word.</li>
<li>There is an <u>explicit</u> policy for the source zone
to or from the destination zone. An explicit policy names both zones
and does not use the 'all' reserved word.</li>
</ul>
<ul>
<li>There are one or more rules for traffic for the source zone
to or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same
then the rule must be explicit - it must name the zone in both the SOURCE
and DESTINATION columns.</li>
<li>There are one or more rules for traffic for the source
zone to or from the destination zone including rules that use the 'all'
reserved word. Exception: if the source zone and destination zone are
the same then the rule must be explicit - it must name the zone in both
the SOURCE and DESTINATION columns.</li>
</ul>
</blockquote>
@ -241,19 +255,19 @@ file.</li>
height="13">
     Beginning in version 1.3.14, Shorewall treats entries
in <a href="Documentation.htm#Masq">/etc/shorewall/masq </a>differently.
The change involves entries with an <b>interface name</b> in the <b>SUBNET</b>
(second) <b>column</b>:<br>
The change involves entries with an <b>interface name</b> in the
<b>SUBNET</b> (second) <b>column</b>:<br>
<ul>
<li>Prior to 1.3.14, Shorewall would detect the FIRST
subnet on the interface (as shown by "ip addr show <i>interface</i>")
and would masquerade traffic from that subnet. Any other subnets that
routed through eth1 needed their own entry in /etc/shorewall/masq to
be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses the
firewall's routing table to determine ALL subnets routed through the
named interface. Traffic originating in ANY of those subnets is masqueraded
or has SNAT applied.</li>
routed through eth1 needed their own entry in /etc/shorewall/masq
to be masqueraded or to have SNAT applied.</li>
<li>Beginning with Shorewall 1.3.14, Shorewall uses
the firewall's routing table to determine ALL subnets routed through
the named interface. Traffic originating in ANY of those subnets
is masqueraded or has SNAT applied.</li>
</ul>
You will need to make a change to your configuration if:<br>
@ -266,8 +280,8 @@ be masqueraded or to have SNAT applied.</li>
</ol>
Two examples:<br>
<br>
 <b>Example 1</b> -- Suppose that your current config is
as follows:<br>
 <b>Example 1</b> -- Suppose that your current config
is as follows:<br>
   <br>
<pre> [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE<br> [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
@ -275,8 +289,8 @@ be masqueraded or to have SNAT applied.</li>
<blockquote>In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
</blockquote>
<b>Example 2</b>-- What if your current configuration is
like this?<br>
<b>Example 2</b>-- What if your current configuration
is like this?<br>
<pre> [root@gateway test]# cat /etc/shorewall/masq <br> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE <br> [root@gateway test]# ip route show dev eth2 <br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254 <br> [root@gateway test]#</pre>
@ -289,10 +303,10 @@ be masqueraded or to have SNAT applied.</li>
height="13">
    Version 1.3.14 also introduced simplified ICMP echo-request
(ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
is used to specify that the old (pre-1.3.14) ping handling is to be
used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting the
old handling indefinitely so I urge current users to migrate to using
is used to specify that the old (pre-1.3.14) ping handling is to
be used (If the option is not set in your /etc/shorewall/shorewall.conf
then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting
the old handling indefinitely so I urge current users to migrate to using
the new handling as soon as possible. See the <a href="ping.html">'Ping'
handling documentation</a> for details.<br>
@ -307,8 +321,9 @@ handling documentation</a> for details.<br>
<h3>Version &gt;= 1.3.9</h3>
The 'functions' file has moved to /usr/lib/shorewall/functions.
If you have an application that uses functions from that file, your
application will need to be changed to reflect this change of location.<br>
If you have an application that uses functions from that file,
your application will need to be changed to reflect this change of
location.<br>
<h3>Version &gt;= 1.3.8</h3>
@ -336,19 +351,20 @@ handling documentation</a> for details.<br>
<p>To properly upgrade with Shorewall version 1.3.3 and later:</p>
<ol>
<li>Be sure you have
a backup -- you will need to transcribe
any Shorewall configuration changes
that you have made to the new configuration.</li>
<li>Replace the shorwall.lrp
package provided on the Bering
floppy with the later one. If you did
not obtain the later version from Jacques's site, see additional
instructions below.</li>
<li>Be sure you
have a backup -- you will need
to transcribe any Shorewall configuration
changes that you have made to the new
configuration.</li>
<li>Replace the
shorwall.lrp package provided on
the Bering floppy with the later one. If you did
not obtain the later version from Jacques's
site, see additional instructions below.</li>
<li>Edit the /var/lib/lrpkg/root.exclude.list
file and remove the /var/lib/shorewall
entry if present. Then do not forget
to backup root.lrp !</li>
entry if present. Then do not
forget to backup root.lrp !</li>
</ol>
@ -366,8 +382,8 @@ floppy with the later one. If you did
<p align="left">If you have a pair of firewall systems configured for
failover or if you have asymmetric routing, you will need to modify
your firewall setup slightly under Shorewall versions
1.3.6 and 1.3.7</p>
your firewall setup slightly under Shorewall versions 1.3.6
and 1.3.7</p>
<ol>
<li>
@ -436,12 +452,13 @@ Acks to rebuild connection<br>
If you have applications that access these files, those
applications should be modified accordingly.</p>
<p><font size="2"> Last updated 6/29/2003 - <a href="support.htm">Tom
Eastep</a></font> </p>
<p><font size="2"> Last updated 6/29/2003 - <a href="support.htm">Tom Eastep</a></font>
</p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

2
Shorewall/fallback.sh
View File

@ -28,7 +28,7 @@
# shown below. Simply run this script to revert to your prior version of
# Shoreline Firewall.
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{

2
Shorewall/install.sh
View File

@ -54,7 +54,7 @@
# /etc/rc.d/rc.local file is modified to start the firewall.
#
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{

4
Shorewall/shorewall.spec
View File

@ -1,6 +1,6 @@
%define name shorewall
%define version 1.4.6
%define release 0Beta1
%define release 0Beta2
%define prefix /usr
Summary: Shoreline Firewall is an iptables-based firewall for Linux systems.
@ -105,6 +105,8 @@ fi
%doc COPYING INSTALL changelog.txt releasenotes.txt tunnel
%changelog
* Mon Jul 07 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.6-0Beta2
* Fri Jul 04 2003 Tom Eastep <tom@shorewall.net>
- Changed version to 1.4.6-0Beta1
* Tue Jun 17 2003 Tom Eastep <tom@shorewall.net>

2
Shorewall/uninstall.sh
View File

@ -26,7 +26,7 @@
# You may only use this script to uninstall the version
# shown below. Simply run this script to remove Seattle Firewall
VERSION=1.4.6Beta1
VERSION=1.4.6Beta2
usage() # $1 = exit status
{