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

More Shorewall 1.4.0 changes

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@455 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-19 23:21:55 +00:00
parent d08a68991a
commit 84ed075e10
24 changed files with 12304 additions and 12687 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6093
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

2127
Shorewall-docs/FAQ.htm
View File

File diff suppressed because it is too large Load Diff

153
Shorewall-docs/MAC_Validation.html
View File

@ -2,110 +2,109 @@
<html>
<head>
<title>MAC Verification</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">MAC Verification</font><br>
</h1>
<br>
</td>
</tr>
</tbody>
</h1>
<br>
</td>
</tr>
</tbody>
</table>
<br>
Beginning with Shorewall version 1.3.10, all traffic from an interface
or from a subnet on an interface can be verified to originate from a defined
set of MAC addresses. Furthermore, each MAC address may be optionally
associated with one or more IP addresses. <br>
<br>
<b>You must have the iproute package (ip utility) installed to use MAC
Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
<br>
Beginning with Shorewall version 1.3.10, all traffic from an interface
or from a subnet on an interface can be verified to originate from a defined
set of MAC addresses. Furthermore, each MAC address may be optionally associated
with one or more IP addresses. <br>
<br>
<b>You must have the iproute package (ip utility) installed to use MAC
Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- module name ipt_mac.o).</b><br>
<br>
There are four components to this facility.<br>
<br>
There are four components to this facility.<br>
<ol>
<li>The <b>maclist</b> interface option in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. When
this option is specified, all traffic arriving on the interface is subjet
to MAC verification.</li>
<li>The <b>maclist </b>option in <a
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>. When this option
is specified for a subnet, all traffic from that subnet is subject to MAC
<li>The <b>maclist</b> interface option in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>. When this
option is specified, all traffic arriving on the interface is subjet to MAC
verification.</li>
<li>The /etc/shorewall/maclist file. This file is used to associate
MAC addresses with interfaces and to optionally associate IP addresses with
MAC addresses.</li>
<li>The <b>MACLIST_DISPOSITION </b>and <b>MACLIST_LOG_LEVEL </b>variables
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and
determines the disposition of connection requests that fail MAC verification.
The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
requests that fail verification are to be logged. If set the the empty value
<li>The <b>maclist </b>option in <a
href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>. When this option
is specified for a subnet, all traffic from that subnet is subject to MAC
verification.</li>
<li>The /etc/shorewall/maclist file. This file is used to associate
MAC addresses with interfaces and to optionally associate IP addresses
with MAC addresses.</li>
<li>The <b>MACLIST_DISPOSITION </b>and <b>MACLIST_LOG_LEVEL </b>variables
in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a>
The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT and
determines the disposition of connection requests that fail MAC verification.
The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
requests that fail verification are to be logged. If set the the empty value
(e.g., MACLIST_LOG_LEVEL="") then failing connection requests are not logged.<br>
</li>
</li>
</ol>
The columns in /etc/shorewall/maclist are:<br>
The columns in /etc/shorewall/maclist are:<br>
<ul>
<li>INTERFACE - The name of an ethernet interface on the Shorewall
<li>INTERFACE - The name of an ethernet interface on the Shorewall
system.</li>
<li>MAC - The MAC address of a device on the ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in this
<li>MAC - The MAC address of a device on the ethernet segment connected
by INTERFACE. It is not necessary to use the Shorewall MAC format in this
column although you may use that format if you so choose.</li>
<li>IP Address - An optional comma-separated list of IP addresses
for the device whose MAC is listed in the MAC column.</li>
<li>IP Address - An optional comma-separated list of IP addresses
for the device whose MAC is listed in the MAC column.</li>
</ul>
<h3>Example 1: Here are my files:</h3>
<b>/etc/shorewall/shorewall.conf:<br>
</b>
<b>/etc/shorewall/shorewall.conf:<br>
</b>
<pre> MACLIST_DISPOSITION=REJECT<br> MACLIST_LOG_LEVEL=info<br></pre>
<b>/etc/shorewall/interfaces:</b><br>
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,filterping,maclist<br> dmz eth1 192.168.2.255 filterping<br> net eth3 206.124.146.255 filterping,blacklist<br> - texas 192.168.9.255 filterping<br> loc ppp+ - filterping<br></pre>
<b>/etc/shorewall/maclist:</b><br>
<b>/etc/shorewall/interfaces:</b><br>
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,maclist<br> dmz eth1 192.168.2.255<br> net eth3 206.124.146.255 blacklist<br> - texas 192.168.9.255<br> loc ppp+<br></pre>
<b>/etc/shorewall/maclist:</b><br>
<pre> #INTERFACE MAC IP ADDRESSES (Optional)<br> eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie<br> eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry<br> eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa<br> eth2 00:A0:CC:DB:31:C4 192.168.1.128/26 #PPTP Clients to server on Ursa<br> eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)<br> eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap<br></pre>
As shown above, I use MAC Verification on <a href="myfiles.htm">my
local zone</a>.<br>
As shown above, I use MAC Verification on my local zone.<br>
<h3>Example 2: Router in Local Zone</h3>
Suppose now that I add a second ethernet segment to my local zone and
gateway that segment via a router with MAC address 00:06:43:45:C6:15 and
IP address 192.168.1.253. Hosts in the second segment have IP addresses
in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
Suppose now that I add a second ethernet segment to my local zone
and gateway that segment via a router with MAC address 00:06:43:45:C6:15
and IP address 192.168.1.253. Hosts in the second segment have IP addresses
in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
file:<br>
<pre> eth2 00:06:43:45:C6:15 192.168.1.253,192.168.2.0/24<br></pre>
This entry accomodates traffic from the router itself (192.168.1.253)
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
by the router so that traffic's MAC address will be that of the router
(00:06:43:45:C6:15) and not that of the host sending the traffic.
<p><font size="2"> Updated 1/7/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
This entry accomodates traffic from the router itself (192.168.1.253)
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.
<p><font size="2"> Updated 2/18/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
</p>
<br>
</body>
</html>

3131
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

788
Shorewall-docs/Shorewall_Squid_Usage.html
View File

@ -2,368 +2,332 @@
<html>
<head>
<title>Shorewall Squid Usage</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table cellpadding="0" cellspacing="0" border="0" width="100%"
bgcolor="#400169">
<tbody>
<tr>
<td valign="middle" width="33%" bgcolor="#400169"><a
<tbody>
<tr>
<td valign="middle" width="33%" bgcolor="#400169"><a
href="http://www.squid-cache.org/"><img src="images/squidnow.gif"
alt="" width="88" height="31" hspace="4">
</a><br>
</td>
<td valign="middle" height="90" align="center" width="34%"><font
</a><br>
</td>
<td valign="middle" height="90" align="center" width="34%"><font
color="#ffffff"><b><big><big><big><big>Using Shorewall with Squid</big></big></big></big></b></font><br>
</td>
<td valign="middle" height="90" width="33%" align="right"><a
</td>
<td valign="middle" height="90" width="33%" align="right"><a
href="http://www.squid-cache.org/"><img src="images/cache_now.gif"
alt="" width="100" height="31" hspace="4">
</a><br>
</td>
</tr>
</tbody>
</a><br>
</td>
</tr>
</tbody>
</table>
<br>
This page covers Shorewall configuration to use with <a
href="http://www.squid-cache.org/">Squid </a>running as a <u><b>Transparent
Proxy</b></u>.&nbsp;<br>
<a href="#DMZ"></a><br>
<img border="0" src="images/j0213519.gif" width="60" height="60"
<br>
This page covers Shorewall configuration to use with <a
href="http://www.squid-cache.org/">Squid </a>running as a <u><b>Transparent
Proxy</b></u>.&nbsp;<br>
<a href="#DMZ"></a><br>
<img border="0" src="images/j0213519.gif" width="60" height="60"
alt="Caution" align="middle">
&nbsp;&nbsp;&nbsp; Please observe the following general requirements:<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>In all cases, Squid should be configured to run
as a transparent proxy as described at <a
&nbsp;&nbsp;&nbsp; Please observe the following general requirements:<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>In all cases, Squid should be configured to run
as a transparent proxy as described at <a
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
<b><br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files /etc/shorewall/start
and /etc/shorewall/init -- if you don't have those files, siimply create
them.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or in
the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
file entries. That is because the packets being routed to the Squid server
still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iproute2 (<i>ip </i>utility) installed
on your firewall.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iptables installed on your Squid
server.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have NAT and MANGLE enabled in your /etc/shorewall/conf
file<br>
<br>
&nbsp;&nbsp;&nbsp; <b><font color="#009900">&nbsp;&nbsp;&nbsp; NAT_ENABLED=Yes<br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
<br>
Three different configurations are covered:<br>
<b><br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files /etc/shorewall/start
and /etc/shorewall/init -- if you don't have those files, siimply create
them.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or in
the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
file entries. That is because the packets being routed to the Squid server
still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iproute2 (<i>ip </i>utility) installed
on your firewall.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iptables installed on your Squid
server.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have NAT and MANGLE enabled in your
/etc/shorewall/conf file<br>
<br>
&nbsp;&nbsp;&nbsp; <b><font color="#009900">&nbsp;&nbsp;&nbsp; NAT_ENABLED=Yes<br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
<br>
Three different configurations are covered:<br>
<ol>
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on the
Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in the
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on
the Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in the
local network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the DMZ</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the DMZ</a></li>
</ol>
<h2><a name="Firewall"></a>Squid Running on the Firewall</h2>
You want to redirect all local www connection requests EXCEPT
those to your own
http server (206.124.146.177)
to a Squid transparent
proxy running on the firewall and listening on port 3128. Squid
You want to redirect all local www connection requests EXCEPT
those to your own
http server (206.124.146.177)
to a Squid transparent
proxy running on the firewall and listening on port 3128. Squid
will of course require access to remote web servers.<br>
<br>
In /etc/shorewall/rules:<br>
<br>
<br>
In /etc/shorewall/rules:<br>
<br>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td> -<br>
</td>
<td>!206.124.146.177</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<h2><a name="Local"></a>Squid Running in the local network</h2>
You want to redirect all local www connection requests to a Squid
transparent proxy
running in your local zone at 192.168.1.3 and listening on port 3128.
Your local interface is eth1. There may also be a web server running on
192.168.1.3. It is assumed that web access is already enabled from the local
zone to the internet.<br>
<p><font color="#ff0000"><b>WARNING: </b></font>This setup may conflict with
other aspects of your gateway including but not limited to traffic shaping
and route redirection. For that reason, <b>I don't recommend it</b>.<br>
</p>
<ul>
<li>On your firewall system, issue the following command<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</font></b><br></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/init, put:<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.168.1.3 dev eth1 table www.out<br> ip route flush cache<br> echo 0 &gt; /proc/sys/net/ipv4/conf/eth1/send_redirects<br>fi<br></font></b></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/rules:<br>
<br>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>ACCEPT<br>
</td>
<td>loc</td>
<td>loc<br>
</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>Alternativfely, you can have the following policy:<br>
<br>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DESTINATION<br>
</b></td>
<td valign="top"><b>POLICY<br>
</b></td>
<td valign="top"><b>LOG LEVEL<br>
</b></td>
<td valign="top"><b>BURST PARAMETERS<br>
</b></td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">loc<br>
</td>
<td valign="top">ACCEPT<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>In /etc/shorewall/start add:<br>
</li>
</ul>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc</td>
<td>3128</td>
<td>tcp</td>
<td>www</td>
<td> -<br>
</td>
<td>!206.124.146.177</td>
</tr>
<tr>
<td>ACCEPT</td>
<td>fw</td>
<td>net</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td> <br>
</td>
</tr>
</tbody>
</table>
<br>
<pre><font color="#009900"><b>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</b></font><br></pre>
</blockquote>
<h2><a name="Local"></a>Squid Running in the local network</h2>
You want to redirect all local www connection requests to a Squid
transparent proxy
running in your local zone at 192.168.1.3 and listening on port 3128.
Your local interface is eth1. There may also be a web server running on 192.168.1.3.
It is assumed that web access is already enabled from the local zone to the
internet.<br>
<p><font color="#ff0000"><b>WARNING: </b></font>This setup may conflict with
other aspects of your gateway including but not limited to traffic shaping
and route redirection. For that reason, <b>I don't recommend it</b>.<br>
</p>
<ul>
<li>On your firewall system, issue the following command<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</font></b><br></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/init, put:<br>
</li>
</ul>
<blockquote>
<pre><b><font color="#009900">if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.168.1.3 dev eth1 table www.out<br> ip route flush cache<br> echo 0 &gt; /proc/sys/net/ipv4/conf/eth1/send_redirects<br>fi<br></font></b></pre>
</blockquote>
<ul>
<li>In /etc/shorewall/rules:<br>
<br>
<table border="1" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>ACCEPT<br>
</td>
<td>loc</td>
<td>loc<br>
</td>
<td>tcp</td>
<td>www</td>
<td> <br>
</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>Alternativfely, you can have the following policy:<br>
<br>
<table cellpadding="2" cellspacing="0" border="1">
<tbody>
<tr>
<td valign="top"><b>SOURCE<br>
</b></td>
<td valign="top"><b>DESTINATION<br>
</b></td>
<td valign="top"><b>POLICY<br>
</b></td>
<td valign="top"><b>LOG LEVEL<br>
</b></td>
<td valign="top"><b>BURST PARAMETERS<br>
</b></td>
</tr>
<tr>
<td valign="top">loc<br>
</td>
<td valign="top">loc<br>
</td>
<td valign="top">ACCEPT<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</li>
<li>In /etc/shorewall/start add:<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202</b></font><br></pre>
</blockquote>
<ul>
<li>On 192.168.1.3, arrange for the following command to be executed
<li>On 192.168.1.3, arrange for the following command to be executed
after networking has come up<br>
<pre><b><font color="#009900">iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128</font></b><br></pre>
</li>
</li>
</ul>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<blockquote> </blockquote>
<pre><font color="#009900"><b>iptables-save &gt; /etc/sysconfig/iptables</b></font><font
color="#009900"><b><br>chkconfig --level 35 iptables start<br></b></font></pre>
</blockquote>
</blockquote>
<blockquote> </blockquote>
<h2><a name="DMZ"></a>Squid Running in the DMZ (This is what I do)</h2>
You have a single Linux system in your DMZ with IP address 192.0.2.177.
You want to run both a web server and Squid on that system. Your DMZ interface
You have a single Linux system in your DMZ with IP address 192.0.2.177.
You want to run both a web server and Squid on that system. Your DMZ interface
is eth1 and your local interface is eth2.<br>
<ul>
<li>On your firewall system, issue the following command<br>
</li>
<li>On your firewall system, issue the following command<br>
</li>
</ul>
<blockquote>
<blockquote>
<pre><font color="#009900"><b>echo 202 www.out &gt;&gt; /etc/iproute2/rt_tables</b></font><br></pre>
</blockquote>
</blockquote>
<ul>
<li>In /etc/shorewall/init, put:<br>
</li>
<li>In /etc/shorewall/init, put:<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.0.2.177 dev eth1 table www.out<br> ip route flush cache<br>fi</b></font><br></pre>
</blockquote>
<ul>
<li>&nbsp;Do<b> one </b>of the following:<br>
<br>
A) In /etc/shorewall/start add<br>
</li>
</ul>
<blockquote>
<pre><font color="#009900"><b>if [ -z "`ip rule list | grep www.out`" ] ; then<br> ip rule add fwmark 202 table www.out<br> ip route add default via 192.0.2.177 dev eth1 table www.out<br> ip route flush cache<br>fi</b></font><br></pre>
</blockquote>
<ul>
<li>&nbsp;Do<b> one </b>of the following:<br>
<br>
A) In /etc/shorewall/start add<br>
</li>
</ul>
<blockquote>
<blockquote>
<pre><b><font color="#009900"> iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</font></b><br></pre>
</blockquote>
<blockquote>B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
</blockquote>
<blockquote>B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
and add the following entry in /etc/shorewall/tcrules:<br>
</blockquote>
<blockquote>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
<tbody>
<tr>
<td valign="top">MARK<br>
</td>
<td valign="top">SOURCE<br>
</td>
<td valign="top">DESTINATION<br>
</td>
<td valign="top">PROTOCOL<br>
</td>
<td valign="top">PORT<br>
</td>
<td valign="top">CLIENT PORT<br>
</td>
</tr>
<tr>
<td valign="top">202<br>
</td>
<td valign="top">eth2<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top">-<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:<br>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
@ -383,7 +347,7 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
</td>
</tr>
<tr>
<td valign="top">202:P<br>
<td valign="top">202<br>
</td>
<td valign="top">eth2<br>
</td>
@ -400,90 +364,130 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
</tbody>
</table>
</blockquote>
<br>
</blockquote>
C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/tcrules:<br>
</blockquote>
<blockquote>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
<tbody>
<tr>
<td valign="top">MARK<br>
</td>
<td valign="top">SOURCE<br>
</td>
<td valign="top">DESTINATION<br>
</td>
<td valign="top">PROTOCOL<br>
</td>
<td valign="top">PORT<br>
</td>
<td valign="top">CLIENT PORT<br>
</td>
</tr>
<tr>
<td valign="top">202:P<br>
</td>
<td valign="top">eth2<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top">-<br>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
</blockquote>
<ul>
<li>In /etc/shorewall/rules, you will need:</li>
</ul>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
<tbody>
<tr>
<td valign="top">ACTION<br>
</td>
<td valign="top">SOURCE<br>
</td>
<td valign="top">DEST<br>
</td>
<td valign="top">PROTO<br>
</td>
<td valign="top">DEST<br>
PORT(S)<br>
</td>
<td valign="top">CLIENT<br>
PORT(2)<br>
</td>
<td valign="top">ORIGINAL<br>
DEST<br>
</td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">dmz<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<ul>
<li>On 192.0.2.177 (your Web/Squid server), arrange for the following
command to be executed after networking has come up<br>
<pre><font color="#009900"><b>iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></font><br></pre>
</li>
<li>In /etc/shorewall/rules, you will need:</li>
</ul>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<table cellpadding="2" border="1" cellspacing="0">
<tbody>
<tr>
<td valign="top">ACTION<br>
</td>
<td valign="top">SOURCE<br>
</td>
<td valign="top">DEST<br>
</td>
<td valign="top">PROTO<br>
</td>
<td valign="top">DEST<br>
PORT(S)<br>
</td>
<td valign="top">CLIENT<br>
PORT(2)<br>
</td>
<td valign="top">ORIGINAL<br>
DEST<br>
</td>
</tr>
<tr>
<td valign="top">ACCEPT<br>
</td>
<td valign="top">dmz<br>
</td>
<td valign="top">net<br>
</td>
<td valign="top">tcp<br>
</td>
<td valign="top">80<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<ul>
<li>On 192.0.2.177 (your Web/Squid server), arrange for the following
command to be executed after networking has come up<br>
<pre><font color="#009900"><b>iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128</b></font><br></pre>
</li>
</ul>
<blockquote> If you are running RedHat on the server, you can simply execute
the following commands after you have typed the iptables command above:<br>
</blockquote>
<blockquote>
<blockquote> </blockquote>
<pre><font color="#009900"><b>iptables-save &gt; /etc/sysconfig/iptables</b></font><font
color="#009900"><b><br>chkconfig --level 35 iptables start<br></b></font></pre>
</blockquote>
</blockquote>
<blockquote> </blockquote>
<p><font size="-1"> Updated 1/23/2003 - <a
href="file:///home/teastep/Shorewall-docs/support.htm">Tom Eastep</a>
</font></p>
<p><font size="-1"> Updated 1/23/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<a
<a
href="copyright.htm"><font size="2">Copyright</font> &copy; <font
size="2">2003 Thomas M. Eastep.</font></a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>

625
Shorewall-docs/configuration_file_basics.htm
View File

@ -1,343 +1,344 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Configuration File Basics</title>
</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%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Configuration Files</font></h1>
</td>
</tr>
</tbody>
</table>
<p><b><font color="#ff0000">Warning: </font>If you copy or edit your
configuration files on a system running Microsoft Windows, you <u>must</u>
run them through <a
href="http://www.megaloman.com/%7Ehany/software/hd2u/"> dos2unix</a>
before you use them with Shorewall.</b></p>
<h2><a name="Files"></a>Files</h2>
<p>Shorewall's configuration files are in the directory /etc/shorewall.</p>
<ul>
<li>/etc/shorewall/shorewall.conf - used to set
several firewall parameters.</li>
<li>/etc/shorewall/params - use this file to set
shell variables that you will expand in other files.</li>
<li>/etc/shorewall/zones - partition the firewall's
view of the world into <i>zones.</i></li>
<li>/etc/shorewall/policy - establishes firewall
high-level policy.</li>
<li>/etc/shorewall/interfaces - describes the interfaces
on the firewall system.</li>
<li>/etc/shorewall/hosts - allows defining zones
in terms of individual hosts and subnetworks.</li>
<li>/etc/shorewall/masq - directs the firewall where
to use many-to-one (dynamic) Network Address Translation (a.k.a.
Masquerading) and Source Network Address Translation (SNAT).</li>
<li>/etc/shorewall/modules - directs the firewall
to load kernel modules.</li>
<li>/etc/shorewall/rules - defines rules that are
exceptions to the overall policies established in /etc/shorewall/policy.</li>
<li>/etc/shorewall/nat - defines static NAT rules.</li>
<li>/etc/shorewall/proxyarp - defines use of Proxy
ARP.</li>
<li>/etc/shorewall/routestopped (Shorewall 1.3.4
and later) - defines hosts accessible when Shorewall is stopped.</li>
<li>/etc/shorewall/tcrules - defines marking of
packets for later use by traffic control/shaping or policy routing.</li>
<li>/etc/shorewall/tos - defines rules for setting
the TOS field in packet headers.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE
and IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/blacklist - lists blacklisted
IP/subnet/MAC addresses.</li>
<li>/etc/shorewall/init - commands that you wish to execute at the
beginning of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/start - commands that you wish to execute at the
completion of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the
beginning of a "shorewall stop".</li>
<li>/etc/shorewall/stopped - commands that you wish to execute at the
completion of a "shorewall stop".<br>
</li>
</ul>
<h2><a name="Comments"></a>Comments</h2>
<p>You may place comments in configuration files by making the first non-whitespace
character a pound sign ("#"). You may also place comments at
the end of any line, again by delimiting the comment from the rest
of the line with a pound sign.</p>
<p>Examples:</p>
<pre># This is a comment</pre>
<pre>ACCEPT net fw tcp www #This is an end-of-line comment</pre>
<h2><a name="Continuation"></a>Line Continuation</h2>
<p>You may continue lines in the configuration files using the usual backslash
("\") followed immediately by a new line character.</p>
<p>Example:</p>
<pre>ACCEPT net fw tcp \<br>smtp,www,pop3,imap #Services running on the firewall</pre>
<h2><a name="dnsnames"></a>Using DNS Names</h2>
<p align="left"> </p>
<p align="left"><b>WARNING: I personally recommend strongly <u>against</u>
using DNS names in Shorewall configuration files. If you use DNS names
and you are called out of bed at 2:00AM because Shorewall won't start
as a result of DNS problems then don't say that you were not forewarned.
<br>
</b></p>
<p align="left"><b>    -Tom<br>
</b></p>
<p align="left">Beginning with Shorwall 1.3.9, Host addresses in Shorewall
configuration files may be specified as either IP addresses or DNS
Names.<br>
<br>
DNS names in iptables rules aren't nearly as useful as they
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those
addresses into the rule. So changes in the DNS-&gt;IP address relationship
that occur after the firewall has started have absolutely no effect
on the firewall's ruleset. </p>
<p align="left"> If your firewall rules include DNS names then:</p>
<ul>
<li>If your /etc/resolv.conf is wrong then your firewall
won't start.</li>
<li>If your /etc/nsswitch.conf is wrong then your firewall
won't start.</li>
<li>If your Name Server(s) is(are) down then your firewall
won't start.</li>
<li>If your startup scripts try to start your firewall
before starting your DNS server then your firewall won't start.<br>
</li>
<li>Factors totally outside your control (your ISP's router
is down for example), can prevent your firewall from starting.</li>
<li>You must bring up your network interfaces prior to starting
your firewall.<br>
</li>
</ul>
<p align="left"> Each DNS name much be fully qualified and include a minumum
of two periods (although one may be trailing). This restriction is
imposed by Shorewall to insure backward compatibility with existing
configuration files.<br>
<br>
Examples of valid DNS names:<br>
</p>
<ul>
<li>mail.shorewall.net</li>
<li>shorewall.net. (note the trailing period).</li>
</ul>
Examples of invalid DNS names:<br>
<ul>
<li>mail (not fully qualified)</li>
<li>shorewall.net (only one period)</li>
</ul>
DNS names may not be used as:<br>
<ul>
<li>The server address in a DNAT rule (/etc/shorewall/rules
file)</li>
<li>In the ADDRESS column of an entry in /etc/shorewall/masq.</li>
<li>In the /etc/shorewall/nat file.</li>
</ul>
These restrictions are not imposed by Shorewall simply for
your inconvenience but are rather limitations of iptables.<br>
<h2><a name="Compliment"></a>Complementing an Address or Subnet</h2>
<p>Where specifying an IP address, a subnet or an interface, you can
precede the item with "!" to specify the complement of the item. For
example, !192.168.1.4 means "any host but 192.168.1.4". There must
be no white space following the "!".</p>
<h2><a name="Lists"></a>Comma-separated Lists</h2>
<p>Comma-separated lists are allowed in a number of contexts within the
configuration files. A comma separated list:</p>
<ul>
<li>Must not have any embedded white space.<br>
Valid: routefilter,dhcp,norfc1918<br>
Invalid: routefilter,     dhcp,     norfc1818</li>
<li>If you use line continuation to break a comma-separated
list, the continuation line(s) must begin in column 1 (or
there would be embedded white space)</li>
<li>Entries in a comma-separated list may appear
in any order.</li>
</ul>
<h2><a name="Ports"></a>Port Numbers/Service Names</h2>
<p>Unless otherwise specified, when giving a port number you can use
either an integer or a service name from /etc/services. </p>
<h2><a name="Ranges"></a>Port Ranges</h2>
<p>If you need to specify a range of ports, the proper syntax is &lt;<i>low
port number</i>&gt;:&lt;<i>high port number</i>&gt;. For example,
if you want to forward the range of tcp ports 4000 through 4100 to
local host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
</p>
<pre> DNAT net loc:192.168.1.3 tcp 4000:4100<br></pre>
If you omit the low port number, a value of zero is assumed; if you omit
the high port number, a value of 65535 is assumed.<br>
<h2><a name="Variables"></a>Using Shell Variables</h2>
<p>You may use the /etc/shorewall/params file to set shell variables
that you can then use in some of the other configuration files.</p>
<p>It is suggested that variable names begin with an upper case letter<font
size="1"> </font>to distinguish them from variables used internally
within the Shorewall programs</p>
<p>Example:</p>
<blockquote>
<pre>NET_IF=eth0<br>NET_BCAST=130.252.100.255<br>NET_OPTIONS=routefilter,norfc1918</pre>
</blockquote>
<p><br>
Example (/etc/shorewall/interfaces record):</p>
<font
face="Century Gothic, Arial, Helvetica">
<blockquote>
<pre><font face="Courier">net $NET_IF $NET_BCAST $NET_OPTIONS</font></pre>
</blockquote>
</font>
<p>The result will be the same as if the record had been written</p>
<font
face="Century Gothic, Arial, Helvetica">
<blockquote>
<pre>net eth0 130.252.100.255 routefilter,norfc1918</pre>
</blockquote>
</font>
<h1 align="center"><font color="#ffffff">Configuration Files</font></h1>
</td>
</tr>
</tbody>
</table>
<p><b><font color="#ff0000">Warning: </font>If you copy or edit your
configuration files on a system running Microsoft Windows, you <u>must</u>
run them through <a
href="http://www.megaloman.com/%7Ehany/software/hd2u/"> dos2unix</a>
before you use them with Shorewall.</b></p>
<h2><a name="Files"></a>Files</h2>
<p>Shorewall's configuration files are in the directory /etc/shorewall.</p>
<ul>
<li>/etc/shorewall/shorewall.conf - used to set several
firewall parameters.</li>
<li>/etc/shorewall/params - use this file to set
shell variables that you will expand in other files.</li>
<li>/etc/shorewall/zones - partition the firewall's
view of the world into <i>zones.</i></li>
<li>/etc/shorewall/policy - establishes firewall
high-level policy.</li>
<li>/etc/shorewall/interfaces - describes the interfaces
on the firewall system.</li>
<li>/etc/shorewall/hosts - allows defining zones
in terms of individual hosts and subnetworks.</li>
<li>/etc/shorewall/masq - directs the firewall where
to use many-to-one (dynamic) Network Address Translation
(a.k.a. Masquerading) and Source Network Address Translation
(SNAT).</li>
<li>/etc/shorewall/modules - directs the firewall
to load kernel modules.</li>
<li>/etc/shorewall/rules - defines rules that are
exceptions to the overall policies established in /etc/shorewall/policy.</li>
<li>/etc/shorewall/nat - defines static NAT rules.</li>
<li>/etc/shorewall/proxyarp - defines use of Proxy
ARP.</li>
<li>/etc/shorewall/routestopped (Shorewall 1.3.4
and later) - defines hosts accessible when Shorewall is stopped.</li>
<li>/etc/shorewall/tcrules - defines marking of packets
for later use by traffic control/shaping or policy routing.</li>
<li>/etc/shorewall/tos - defines rules for setting
the TOS field in packet headers.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE and
IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/blacklist - lists blacklisted
IP/subnet/MAC addresses.</li>
<li>/etc/shorewall/init - commands that you wish to execute at the beginning
of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/start - commands that you wish to execute at the
completion of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the beginning
of a "shorewall stop".</li>
<li>/etc/shorewall/stopped - commands that you wish to execute at the
completion of a "shorewall stop".<br>
</li>
</ul>
<h2><a name="Comments"></a>Comments</h2>
<p>You may place comments in configuration files by making the first non-whitespace
character a pound sign ("#"). You may also place comments at
the end of any line, again by delimiting the comment from the
rest of the line with a pound sign.</p>
<p>Examples:</p>
<pre># This is a comment</pre>
<pre>ACCEPT net fw tcp www #This is an end-of-line comment</pre>
<h2><a name="Continuation"></a>Line Continuation</h2>
<p>You may continue lines in the configuration files using the usual backslash
("\") followed immediately by a new line character.</p>
<p>Example:</p>
<pre>ACCEPT net fw tcp \<br>smtp,www,pop3,imap #Services running on the firewall</pre>
<h2><a name="dnsnames"></a>Using DNS Names</h2>
<p align="left"> </p>
<p align="left"><b>WARNING: I personally recommend strongly <u>against</u>
using DNS names in Shorewall configuration files. If you use DNS
names and you are called out of bed at 2:00AM because Shorewall won't
start as a result of DNS problems then don't say that you were not forewarned.
<br>
</b></p>
<p align="left"><b>    -Tom<br>
</b></p>
<p align="left">Beginning with Shorwall 1.3.9, Host addresses in Shorewall
configuration files may be specified as either IP addresses or DNS
Names.<br>
<br>
DNS names in iptables rules aren't nearly as useful as they
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those addresses
into the rule. So changes in the DNS-&gt;IP address relationship that
occur after the firewall has started have absolutely no effect on the
firewall's ruleset. </p>
<p align="left"> If your firewall rules include DNS names then:</p>
<ul>
<li>If your /etc/resolv.conf is wrong then your firewall
won't start.</li>
<li>If your /etc/nsswitch.conf is wrong then your firewall
won't start.</li>
<li>If your Name Server(s) is(are) down then your firewall
won't start.</li>
<li>If your startup scripts try to start your firewall before
starting your DNS server then your firewall won't start.<br>
</li>
<li>Factors totally outside your control (your ISP's router
is down for example), can prevent your firewall from starting.</li>
<li>You must bring up your network interfaces prior to starting
your firewall.<br>
</li>
</ul>
<p align="left"> Each DNS name much be fully qualified and include a minumum
of two periods (although one may be trailing). This restriction is
imposed by Shorewall to insure backward compatibility with existing
configuration files.<br>
<br>
Examples of valid DNS names:<br>
</p>
<ul>
<li>mail.shorewall.net</li>
<li>shorewall.net. (note the trailing period).</li>
</ul>
Examples of invalid DNS names:<br>
<ul>
<li>mail (not fully qualified)</li>
<li>shorewall.net (only one period)</li>
</ul>
DNS names may not be used as:<br>
<ul>
<li>The server address in a DNAT rule (/etc/shorewall/rules
file)</li>
<li>In the ADDRESS column of an entry in /etc/shorewall/masq.</li>
<li>In the /etc/shorewall/nat file.</li>
</ul>
These restrictions are not imposed by Shorewall simply for
your inconvenience but are rather limitations of iptables.<br>
<h2><a name="Compliment"></a>Complementing an Address or Subnet</h2>
<p>Where specifying an IP address, a subnet or an interface, you can
precede the item with "!" to specify the complement of the item. For
example, !192.168.1.4 means "any host but 192.168.1.4". There must be
no white space following the "!".</p>
<h2><a name="Lists"></a>Comma-separated Lists</h2>
<p>Comma-separated lists are allowed in a number of contexts within the
configuration files. A comma separated list:</p>
<ul>
<li>Must not have any embedded white space.<br>
Valid: routestopped,dhcp,norfc1918<br>
Invalid: routestopped,     dhcp,     norfc1818</li>
<li>If you use line continuation to break a comma-separated
list, the continuation line(s) must begin in column 1 (or
there would be embedded white space)</li>
<li>Entries in a comma-separated list may appear
in any order.</li>
</ul>
<h2><a name="Ports"></a>Port Numbers/Service Names</h2>
<p>Unless otherwise specified, when giving a port number you can use
either an integer or a service name from /etc/services. </p>
<h2><a name="Ranges"></a>Port Ranges</h2>
<p>If you need to specify a range of ports, the proper syntax is &lt;<i>low
port number</i>&gt;:&lt;<i>high port number</i>&gt;. For example,
if you want to forward the range of tcp ports 4000 through 4100 to local
host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
</p>
<pre> DNAT net loc:192.168.1.3 tcp 4000:4100<br></pre>
If you omit the low port number, a value of zero is assumed; if you omit
the high port number, a value of 65535 is assumed.<br>
<h2><a name="Variables"></a>Using Shell Variables</h2>
<p>You may use the /etc/shorewall/params file to set shell variables
that you can then use in some of the other configuration files.</p>
<p>It is suggested that variable names begin with an upper case letter<font
size="1"> </font>to distinguish them from variables used internally
within the Shorewall programs</p>
<p>Example:</p>
<blockquote>
<pre>NET_IF=eth0<br>NET_BCAST=130.252.100.255<br>NET_OPTIONS=noping,norfc1918</pre>
</blockquote>
<p><br>
Example (/etc/shorewall/interfaces record):</p>
<font
face="Century Gothic, Arial, Helvetica">
<blockquote>
<pre><font face="Courier">net $NET_IF $NET_BCAST $NET_OPTIONS</font></pre>
</blockquote>
</font>
<p>The result will be the same as if the record had been written</p>
<font
face="Century Gothic, Arial, Helvetica">
<blockquote>
<pre>net eth0 130.252.100.255 noping,norfc1918</pre>
</blockquote>
</font>
<p>Variables may be used anywhere in the other configuration
files.</p>
<p>Variables may be used anywhere in the other configuration
files.</p>
<h2><a name="MAC"></a>Using MAC Addresses</h2>
<p>Media Access Control (MAC) addresses can be used to specify packet
source in several of the configuration files. To use this feature,
your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
included.</p>
<p>MAC addresses are 48 bits wide and each Ethernet Controller has a
unique MAC address.<br>
<br>
In GNU/Linux, MAC addresses are usually written as
<p>Media Access Control (MAC) addresses can be used to specify packet
source in several of the configuration files. To use this
feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
included.</p>
<p>MAC addresses are 48 bits wide and each Ethernet Controller has a
unique MAC address.<br>
<br>
In GNU/Linux, MAC addresses are usually written as
a series of 6 hex numbers separated by colons. Example:<br>
<br>
     [root@gateway root]# ifconfig eth0<br>
     eth0 Link encap:Ethernet HWaddr <b><u>02:00:08:E3:FA:55</u></b><br>
     inet addr:206.124.146.176 Bcast:206.124.146.255
Mask:255.255.255.0<br>
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
     RX packets:2398102 errors:0 dropped:0 overruns:0
frame:0<br>
     TX packets:3044698 errors:0 dropped:0 overruns:0
carrier:0<br>
     collisions:30394 txqueuelen:100<br>
     RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
(1582.8 Mb)<br>
     Interrupt:11 Base address:0x1800<br>
<br>
Because Shorewall uses colons as a separator for address
fields, Shorewall requires MAC addresses to be written in another
way. In Shorewall, MAC addresses begin with a tilde ("~") and
consist of 6 hex numbers separated by hyphens. In Shorewall, the
<br>
     [root@gateway root]# ifconfig eth0<br>
     eth0 Link encap:Ethernet HWaddr <b><u>02:00:08:E3:FA:55</u></b><br>
     inet addr:206.124.146.176 Bcast:206.124.146.255
Mask:255.255.255.0<br>
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1<br>
     RX packets:2398102 errors:0 dropped:0 overruns:0
frame:0<br>
     TX packets:3044698 errors:0 dropped:0 overruns:0
carrier:0<br>
     collisions:30394 txqueuelen:100<br>
     RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
(1582.8 Mb)<br>
     Interrupt:11 Base address:0x1800<br>
<br>
Because Shorewall uses colons as a separator for address
fields, Shorewall requires MAC addresses to be written in another
way. In Shorewall, MAC addresses begin with a tilde ("~") and
consist of 6 hex numbers separated by hyphens. In Shorewall, the
MAC address in the example above would be written "~02-00-08-E3-FA-55".<br>
</p>
<p><b>Note: </b>It is not necessary to use the special Shorewall notation
in the <a href="MAC_Validation.html">/etc/shorewall/maclist</a> file.<br>
</p>
</p>
<p><b>Note: </b>It is not necessary to use the special Shorewall notation
in the <a href="MAC_Validation.html">/etc/shorewall/maclist</a> file.<br>
</p>
<h2><a name="Levels"></a>Shorewall Configurations</h2>
<p> Shorewall allows you to have configuration directories other than /etc/shorewall.
The <a href="starting_and_stopping_shorewall.htm">shorewall start and
restart</a> commands allow you to specify an alternate configuration
directory and Shorewall will use the files in the alternate directory
rather than the corresponding files in /etc/shorewall. The alternate directory
need not contain a complete configuration; those files not in the alternate
directory will be read from /etc/shorewall.</p>
<p> This facility permits you to easily create a test or temporary configuration
by:</p>
<p> Shorewall allows you to have configuration directories other than /etc/shorewall.
The <a href="starting_and_stopping_shorewall.htm">shorewall start
and restart</a> commands allow you to specify an alternate configuration
directory and Shorewall will use the files in the alternate directory
rather than the corresponding files in /etc/shorewall. The alternate
directory need not contain a complete configuration; those files not
in the alternate directory will be read from /etc/shorewall.</p>
<p> This facility permits you to easily create a test or temporary configuration
by:</p>
<ol>
<li> copying the files that need modification from
/etc/shorewall to a separate directory;</li>
<li> modify those files in the separate directory;
and</li>
<li> specifying the separate directory in a shorewall
start or shorewall restart command (e.g., <i><b>shorewall -c /etc/testconfig
restart</b></i> ).</li>
<li> copying the files that need modification from
/etc/shorewall to a separate directory;</li>
<li> modify those files in the separate directory;
and</li>
<li> specifying the separate directory in a shorewall
start or shorewall restart command (e.g., <i><b>shorewall -c /etc/testconfig
restart</b></i> ).</li>
</ol>
<p><font size="2"> Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 2/7/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>
<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>
<br>
<br>

761
Shorewall-docs/errata.htm
View File

@ -2,657 +2,244 @@
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall 1.3 Errata</title>
<title>Shorewall 1.4 Errata</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Errata/Upgrade Issues</font></h1>
</td>
</tr>
</td>
</tr>
</tbody>
</tbody>
</table>
<p align="center"> <b><u>IMPORTANT</u></b></p>
<ol>
<li>
<li>
<p align="left"> <b><u>I</u>f you use a Windows system to download
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
a corrected script, be sure to run the script through <u>
<a href="http://www.megaloman.com/%7Ehany/software/hd2u/"
style="text-decoration: none;"> dos2unix</a></u> after you have moved
it to your Linux system.</b></p>
</li>
<li>
it to your Linux system.</b></p>
</li>
<li>
<p align="left"> <b>If you are installing Shorewall for the
first time and plan to use the .tgz and install.sh script, you can
untar the archive, replace the 'firewall' script in the untarred directory
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
<p align="left"> <b>If you are running a Shorewall version earlier
than 1.3.11, when the instructions say to install a corrected firewall
script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to
overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD
/etc/shorewall/firewall or /var/lib/shorewall/firewall before
you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall
are symbolic links that point to the 'shorewall' file used by
your system initialization scripts to start Shorewall during
boot. It is that file that must be overwritten with the corrected
script. Beginning with Shorewall 1.3.11, you may rename the existing file
before copying in the new file.</b></p>
</li>
<li>
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /usr/share/shorewall/firewall, you may
rename the existing file before copying in the new file.</b></p>
</li>
<li>
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are running
1.3.7c.</font></b><br>
</p>
</li>
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are running
1.3.7c.</font></b><br>
</p>
</li>
</ol>
<ul>
<li><b><a href="upgrade_issues.htm">Upgrade Issues</a></b></li>
<li> <b><a href="#V1.3">Problems
in Version 1.3</a></b></li>
<li> <b><a
<li><b><a href="upgrade_issues.htm">Upgrade Issues</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
href="errata_3.html">Problems in Version 1.3</a></b></li>
<li> <b><a
href="errata_2.htm">Problems in Version 1.2</a></b></li>
<li> <b><font
<li> <b><font
color="#660066"> <a href="errata_1.htm">Problems in Version 1.1</a></font></b></li>
<li> <b><font
<li> <b><font
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a
on RH7.2</a></font></b></li>
<li> <b><a
href="#Debug">Problems with kernels &gt;= 2.4.18 and
RedHat iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10 and
NAT</a></b><br>
</li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
</ul>
<hr>
<h2 align="left"><a name="V1.3"></a>Problems in Version 1.3</h2>
<h3>Version 1.3.13</h3>
<ul>
<li>The 'shorewall add' command produces an error message referring
to 'find_interfaces_by_maclist'.</li>
<li>The 'shorewall delete' command can leave behind undeleted rules.</li>
<li>The 'shorewall add' command can fail with "iptables: Index of insertion
too big".<br>
</li>
</ul>
All three problems are corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.13/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.<br>
<ul>
<li>VLAN interface names of the form "eth<i>n</i>.<i>m</i>" (e.g., eth0.1)
are not supported in this version or in 1.3.12. If you need such support,
post on the users list and I can provide you with a patched version.<br>
</li>
</ul>
<h3>Version 1.3.12</h3>
<ul>
<li>If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is
the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem
is corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.12/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.</li>
<li>VLAN interface names of the form "eth<i>n</i>.<i>m</i>" (e.g., eth0.1)
are not supported in this version or in 1.3.13. If you need such support,
post on the users list and I can provide you with a patched version.<br>
</li>
</ul>
<h3>Version 1.3.12 LRP</h3>
<ul>
<li>The .lrp was missing the /etc/shorewall/routestopped file -- a
new lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.<br>
</li>
</ul>
<h3>Version 1.3.11a</h3>
<ul>
<li><a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/rfc1918">This
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of 82.0.0.0/8.<br>
</li>
</ul>
<h3>Version 1.3.11</h3>
<ul>
<li>When installing/upgrading using the .rpm, you may receive
the following warnings:<br>
<br>
     user teastep does not exist - using root<br>
     group teastep does not exist - using root<br>
<br>
These warnings are harmless and may be ignored. Users downloading
the .rpm from shorewall.net or mirrors should no longer see these warnings
as the .rpm you will get from there has been corrected.</li>
<li>DNAT rules that exclude a source subzone (SOURCE column contains
! followed by a sub-zone list) result in an error message and Shorewall
fails to start.<br>
<br>
Install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/firewall">this
corrected script</a> in /usr/lib/shorewall/firewall to correct this problem.
Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
<br>
This problem is corrected in version 1.3.11a.<br>
</li>
</ul>
<h3>Version 1.3.10</h3>
<ul>
<li>If you experience problems connecting to a PPTP server running
on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels,
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">this
version of the firewall script</a> may help. Please report any cases
where installing this script in /usr/lib/shorewall/firewall solved your
connection problems. Beginning with version 1.3.10, it is safe to save
the old version of /usr/lib/shorewall/firewall before copying in the
new one since /usr/lib/shorewall/firewall is the real script now and
not just a symbolic link to the real script.<br>
</li>
</ul>
<h3>Version 1.3.9a</h3>
<ul>
<li> If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No
then the following message appears during "shorewall [re]start":</li>
</ul>
<pre> recalculate_interfacess: command not found<br></pre>
<blockquote> The updated firewall script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
corrects this problem.Copy the script to /usr/lib/shorewall/firewall
as described above.<br>
</blockquote>
<blockquote> Alternatively, edit /usr/lob/shorewall/firewall and change the
single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess'
to 'recalculate_interface'. <br>
</blockquote>
<ul>
<li>The installer (install.sh) issues a misleading message
"Common functions installed in /var/lib/shorewall/functions" whereas
the file is installed in /usr/lib/shorewall/functions. The installer
also performs incorrectly when updating old configurations that had the
file /etc/shorewall/functions. <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.3.9/install.sh">Here
is an updated version that corrects these problems.<br>
</a></li>
</ul>
<h3>Version 1.3.9</h3>
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated firewall
script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
-- copy that file to /usr/lib/shorewall/firewall as described above.<br>
<br>
Version 1.3.8
<ul>
<li> Use of shell variables in the LOG LEVEL or SYNPARMS
columns of the policy file doesn't work.</li>
<li>A DNAT rule with the same original and new IP addresses
but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24
tcp 25 - 10.1.1.1")<br>
</li>
</ul>
Installing <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.8/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects these
problems.
<h3>Version 1.3.7b</h3>
<p>DNAT rules where the source zone is 'fw' ($FW)
result in an error message. Installing
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects this
problem.</p>
<h3>Version 1.3.7a</h3>
<p>"shorewall refresh" is not creating the proper
rule for FORWARDPING=Yes. Consequently, after
"shorewall refresh", the firewall will not forward
icmp echo-request (ping) packets. Installing
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects this
problem.</p>
<h3>Version &lt;= 1.3.7a</h3>
<p>If "norfc1918" and "dhcp" are both specified as
options on a given interface then RFC 1918
checking is occurring before DHCP checking. This
means that if a DHCP client broadcasts using an
RFC 1918 source address, then the firewall will
reject the broadcast (usually logging it). This
has two problems:</p>
<ol>
<li>If the firewall is
running a DHCP server, the client
won't be able to obtain an IP address
lease from that server.</li>
<li>With this order of
checking, the "dhcp" option cannot
be used as a noise-reduction measure
where there are both dynamic and static
clients on a LAN segment.</li>
</ol>
<p> <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
This version of the 1.3.7a firewall script </a>
corrects the problem. It must be installed
in /var/lib/shorewall as described
above.</p>
<h3>Version 1.3.7</h3>
<p>Version 1.3.7 dead on arrival -- please use
version 1.3.7a and check your version against
these md5sums -- if there's a difference, please
download again.</p>
<pre> d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz<br> 6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm<br> 3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp</pre>
<p>In other words, type "md5sum &lt;<i>whatever package you downloaded</i>&gt;
and compare the result with what you see above.</p>
<p>I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the
.7 version in each sequence from now on.</p>
<h3 align="left">Version 1.3.6</h3>
<ul>
<li>
<p align="left">If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf,
an error occurs when the firewall script attempts to
add an SNAT alias. </p>
</li>
<li>
<p align="left">The <b>logunclean </b>and <b>dropunclean</b> options
cause errors during startup when Shorewall is run with iptables
1.2.7. </p>
</li>
</ul>
<p align="left">These problems are fixed in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
this correct firewall script</a> which must be installed in
/var/lib/shorewall/ as described above. These problems are also
corrected in version 1.3.7.</p>
<h3 align="left">Two-interface Samples 1.3.6 (file two-interfaces.tgz)</h3>
<p align="left">A line was inadvertently deleted from the "interfaces
file" -- this line should be added back in if the version that you
downloaded is missing it:</p>
<p align="left">net    eth0    detect    routefilter,dhcp,norfc1918</p>
<p align="left">If you downloaded two-interfaces-a.tgz then the above
line should already be in the file.</p>
<h3 align="left">Version 1.3.5-1.3.5b</h3>
<p align="left">The new 'proxyarp' interface option doesn't work :-(
This is fixed in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5/firewall">
this corrected firewall script</a> which must be installed in
/var/lib/shorewall/ as described above.</p>
<h3 align="left">Versions 1.3.4-1.3.5a</h3>
<p align="left">Prior to version 1.3.4, host file entries such as the
following were allowed:</p>
<div align="left">
<pre> adm eth0:1.2.4.5,eth0:5.6.7.8</pre>
</div>
<div align="left">
<p align="left">That capability was lost in version 1.3.4 so that it is only
possible to  include a single host specification on each line.
This problem is corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5a/firewall">this
modified 1.3.5a firewall script</a>. Install the script in /var/lib/pub/shorewall/firewall
as instructed above.</p>
</div>
<div align="left">
<p align="left">This problem is corrected in version 1.3.5b.</p>
</div>
<h3 align="left">Version 1.3.5</h3>
<p align="left">REDIRECT rules are broken in this version. Install
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5/firewall">
this corrected firewall script</a> in /var/lib/pub/shorewall/firewall
as instructed above. This problem is corrected in version
1.3.5a.</p>
<h3 align="left">Version 1.3.n, n &lt; 4</h3>
<p align="left">The "shorewall start" and "shorewall restart" commands
to not verify that the zones named in the /etc/shorewall/policy
file have been previously defined in the /etc/shorewall/zones
file. The "shorewall check" command does perform this verification
so it's a good idea to run that command after you have made configuration
changes.</p>
<h3 align="left">Version 1.3.n, n &lt; 3</h3>
<p align="left">If you have upgraded from Shorewall 1.2 and after
"Activating rules..." you see the message: "iptables: No chains/target/match
by that name" then you probably have an entry in /etc/shorewall/hosts
that specifies an interface that you didn't include in
/etc/shorewall/interfaces. To correct this problem, you
must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3
and later versions produce a clearer error message in this
case.</p>
<h3 align="left">Version 1.3.2</h3>
<p align="left">Until approximately 2130 GMT on 17 June 2002, the
download sites contained an incorrect version of the .lrp file. That
file can be identified by its size (56284 bytes). The correct
version has a size of 38126 bytes.</p>
<ul>
<li>The code to detect a duplicate interface
entry in /etc/shorewall/interfaces contained a typo that prevented
it from working correctly. </li>
<li>"NAT_BEFORE_RULES=No" was broken; it behaved
just like "NAT_BEFORE_RULES=Yes".</li>
</ul>
<p align="left">Both problems are corrected in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/firewall">
this script</a> which should be installed in <b><u>/var/lib/shorewall</u></b>
as described above.</p>
<ul>
<li>
<p align="left">The IANA have just announced the allocation of subnet
221.0.0.0/8. This <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/rfc1918">
updated rfc1918</a> file reflects that allocation.</p>
</li>
</ul>
<h3 align="left">Version 1.3.1</h3>
<ul>
<li>TCP SYN packets may be double counted
when LIMIT:BURST is included in a CONTINUE or ACCEPT policy
(i.e., each packet is sent through the limit chain twice).</li>
<li>An unnecessary jump to the policy chain
is sometimes generated for a CONTINUE policy.</li>
<li>When an option is given for more than
one interface in /etc/shorewall/interfaces then depending
on the option, Shorewall may ignore all but the first
appearence of the option. For example:<br>
<br>
net    eth0    dhcp<br>
loc    eth1    dhcp<br>
<br>
Shorewall will ignore the 'dhcp' on eth1.</li>
<li>Update 17 June 2002 - The bug described
in the prior bullet affects the following options: dhcp,
dropunclean, logunclean, norfc1918, routefilter, multi,
filterping and noping. An additional bug has been found
that affects only the 'routestopped' option.<br>
<br>
Users who downloaded the corrected script
prior to 1850 GMT today should download and install
the corrected script again to ensure that this second
problem is corrected.</li>
</ul>
<p align="left">These problems are corrected in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall">
this firewall script</a> which should be installed in /etc/shorewall/firewall
as described above.</p>
<h3 align="left">Version 1.3.0</h3>
<ul>
<li>Folks who downloaded 1.3.0 from the links
on the download page before 23:40 GMT, 29 May 2002 may
have downloaded 1.2.13 rather than 1.3.0. The "shorewall
version" command will tell you which version that you
have installed.</li>
<li>The documentation NAT.htm file uses non-existent
wallpaper and bullet graphic files. The <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.0/NAT.htm">
corrected version is here</a>.</li>
</ul>
<hr>
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
<p align="left">The upgrade issues have moved to <a
href="upgrade_issues.htm">a separate page</a>.</p>
<hr>
<h3 align="left"><a name="iptables"></a><font color="#660066"> Problem with
iptables version 1.2.3</font></h3>
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably, RedHat
released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
corrected 1.2.3 rpm which you can download here</a>  and I have
also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
<h2 align="left"><a name="V1.4"></a>Problems in Version 1.4</h2>
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
</font>I have installed this RPM on my firewall and it works
fine.</p>
<p align="left">If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</a>
which corrects a problem with parsing of the --log-level specification
while this <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</a>
corrects a problem in handling the  TOS target.</p>
<p align="left">To install one of the above patches:</p>
<ul>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
</ul>
</blockquote>
<h3><a name="Debug"></a>Problems with kernels &gt;= 2.4.18
and RedHat iptables</h3>
<blockquote>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
<blockquote>
<pre># shorewall start<br>Processing /etc/shorewall/shorewall.conf ...<br>Processing /etc/shorewall/params ...<br>Starting Shorewall...<br>Loading Modules...<br>Initializing...<br>Determining Zones...<br>Zones: net<br>Validating interfaces file...<br>Validating hosts file...<br>Determining Hosts in Zones...<br>Net Zone: eth0:0.0.0.0/0<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br></pre>
</blockquote>
<p>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. If you are already running a 1.2.5 version
of iptables, you will need to specify the --oldpackage option to
rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
<h3></h3>
None.
<hr width="100%" size="2">
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
<p align="left">The upgrade issues have moved to <a
href="upgrade_issues.htm">a separate page</a>.</p>
<hr>
<h3 align="left"><a name="iptables"></a><font color="#660066"> Problem with
iptables version 1.2.3</font></h3>
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably, RedHat
released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3-3.i386.rpm">
corrected 1.2.3 rpm which you can download here</a>  and I have
also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
</font>I have installed this RPM on my firewall and it works
fine.</p>
<p align="left">If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/loglevel.patch">patch</a>
which corrects a problem with parsing of the --log-level specification
while this <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/iptables-1.2.3/tos.patch">patch</a>
corrects a problem in handling the  TOS target.</p>
<p align="left">To install one of the above patches:</p>
<ul>
<li>cd iptables-1.2.3/extensions</li>
<li>patch -p0 &lt; <i>the-patch-file</i></li>
</ul>
</blockquote>
<h3><a name="Debug"></a>Problems with kernels &gt;= 2.4.18
and RedHat iptables</h3>
<blockquote>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
<blockquote>
<pre># shorewall start<br>Processing /etc/shorewall/shorewall.conf ...<br>Processing /etc/shorewall/params ...<br>Starting Shorewall...<br>Loading Modules...<br>Initializing...<br>Determining Zones...<br>Zones: net<br>Validating interfaces file...<br>Validating hosts file...<br>Determining Hosts in Zones...<br>Net Zone: eth0:0.0.0.0/0<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br></pre>
</blockquote>
<p>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. If you are already running a 1.2.5 version
of iptables, you will need to specify the --oldpackage option to
rpm (e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").</p>
</blockquote>
<h3><a name="SuSE"></a>Problems installing/upgrading
RPM on SuSE</h3>
RPM on SuSE</h3>
<p>If you find that rpm complains about a conflict
with kernel &lt;= 2.2 yet you have a 2.4 kernel
installed, simply use the "--nodeps" option to
rpm.</p>
<p>Installing: rpm -ivh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<p>Upgrading: rpm -Uvh --nodeps <i>&lt;shorewall rpm&gt;</i></p>
<h3><a name="Multiport"></a><b>Problems with
iptables version 1.2.7 and MULTIPORT=Yes</b></h3>
<p>The iptables 1.2.7 release of iptables has made
an incompatible change to the syntax used to
specify multiport match rules; as a consequence,
if you install iptables 1.2.7 you must be running
Shorewall 1.3.7a or later or:</p>
<ul>
<li>set MULTIPORT=No in
/etc/shorewall/shorewall.conf; or </li>
<li>if you are running
Shorewall 1.3.6 you may install
<a
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or </li>
<li>if you are running
Shorewall 1.3.6 you may install
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
this firewall script</a> in /var/lib/shorewall/firewall
as described above.</li>
as described above.</li>
</ul>
<h3><a name="NAT"></a>Problems with RH Kernel 2.4.18-10 and NAT<br>
</h3>
/etc/shorewall/nat entries of the following form will result
in Shorewall being unable to start:<br>
<br>
</h3>
/etc/shorewall/nat entries of the following form will result
in Shorewall being unable to start:<br>
<br>
<pre>#EXTERNAL       INTERFACE       INTERNAL        ALL INTERFACES          LOCAL<br>192.0.2.22    eth0    192.168.9.22   yes     yes<br>#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
Error message is:<br>
Error message is:<br>
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
The solution is to put "no" in the LOCAL column. Kernel support
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled it.
The 2.4.19 kernel contains corrected support under a new kernel configuraiton
The solution is to put "no" in the LOCAL column. Kernel support
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled
it. The 2.4.19 kernel contains corrected support under a new kernel configuraiton
option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 2/8/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<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>
<br>
<br>
<br>
<br>
<br>
<br>
</p>
<br>
</body>
</html>

400
Shorewall-docs/mailing_list.htm
View File

@ -2,152 +2,152 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall Mailing Lists</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table height="90" bgcolor="#400169" id="AutoNumber1" width="100%"
style="border-collapse: collapse;" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
<td width="33%" valign="middle" align="left">
<tbody>
<tr>
<td width="33%" valign="middle" align="left">
<h1 align="center"><a
href="http://www.centralcommand.com/linux_products.html"><img
src="images/Vexira_Antivirus_Logo.gif" alt="Vexira Logo" width="78"
height="79" align="left">
</a></h1>
</a></h1>
<a
<a
href="http://www.gnu.org/software/mailman/mailman.html"> <img
border="0" src="images/logo-sm.jpg" align="left" hspace="5" width="110"
height="35" alt="">
</a>
</a>
<p align="right"><font color="#ffffff"><b>  </b></font> </p>
</td>
<td valign="middle" width="34%" align="center">
</td>
<td valign="middle" width="34%" align="center">
<h1 align="center"><font color="#ffffff">Shorewall Mailing Lists</font></h1>
</td>
<td valign="middle" width="33%"> <a
</td>
<td valign="middle" width="33%"> <a
href="http://www.postfix.org/"> <img
src="images/small-picture.gif" align="right" border="0" width="115"
height="45" alt="(Postfix Logo)">
</a><br>
</a><br>
<div align="left"><a href="http://www.spamassassin.org"><img
src="images/ninjalogo.png" alt="" width="110" height="42" align="right"
border="0">
</a> </div>
<br>
</a> </div>
<br>
<div align="right"><br>
<b><font color="#ffffff"><br>
Powered by Postfix    </font></b><br>
</div>
</td>
</tr>
<b><font color="#ffffff"><br>
Powered by Postfix    </font></b><br>
</div>
</td>
</tr>
</tbody>
</tbody>
</table>
<h2 align="left">Not getting List Mail? -- <a
href="mailing_list_problems.htm">Check Here</a></h2>
<p align="left">If you experience problems with any of these lists, please
let <a href="mailto:teastep@shorewall.net">me</a> know</p>
<p align="left">If you experience problems with any of these lists, please
let <a href="mailto:teastep@shorewall.net">me</a> know</p>
<h2 align="left">Not able to Post Mail to shorewall.net?</h2>
<p align="left">You can report such problems by sending mail to tom dot eastep
<p align="left">You can report such problems by sending mail to tom dot eastep
at hp dot com.</p>
<h2>A Word about SPAM Filters <a href="http://ordb.org"></a><a
href="http://osirusoft.com/"> </a></h2>
<p>Before subscribing please read my <a href="spam_filters.htm">policy
about list traffic that bounces.</a> Also please note that the mail server
<p>Before subscribing please read my <a href="spam_filters.htm">policy
about list traffic that bounces.</a> Also please note that the mail server
at shorewall.net checks incoming mail:<br>
</p>
</p>
<ol>
<li>against <a href="http://spamassassin.org">Spamassassin</a>
<li>against <a href="http://spamassassin.org">Spamassassin</a>
(including <a href="http://razor.sourceforge.net/">Vipul's Razor</a>).<br>
</li>
<li>to ensure that the sender address is fully qualified.</li>
<li>to verify that the sender's domain has an A or MX record
in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command
is a valid fully-qualified DNS name that resolves.</li>
</li>
<li>to ensure that the sender address is fully qualified.</li>
<li>to verify that the sender's domain has an A or MX
record in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command
is a valid fully-qualified DNS name that resolves.</li>
</ol>
<h2>Please post in plain text</h2>
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>(explitive
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. This means that HTML-only posts will be bounced by
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>(explitive
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. This means that HTML-only posts will be bounced by
the list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<h2>Other Mail Delivery Problems</h2>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> headers contain the names
of certain ISPs. Again, I believe that such policies hurt more than they
help but I'm not prepared to go so far as to start stripping <i>Received:</i>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> headers contain the
names of certain ISPs. Again, I believe that such policies hurt more than
they help but I'm not prepared to go so far as to start stripping <i>Received:</i>
headers to circumvent those policies.<br>
<h2 align="left">Mailing Lists Archive Search</h2>
<form method="post" action="http://lists.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<form method="post" action="http://lists.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<select name="method">
<option value="and">All </option>
<option value="or">Any </option>
<option value="boolean">Boolean </option>
</select>
Format:
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -156,149 +156,151 @@ the list server.<br>
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font> <input type="hidden" name="config"
</font> <input type="hidden" name="config"
value="htdig"> <input type="hidden" name="restrict"
value="[http://lists.shorewall.net/pipermail/.*]"> <input type="hidden"
name="exclude" value=""> <br>
Search: <input type="text" size="30" name="words"
Search: <input type="text" size="30" name="words"
value=""> <input type="submit" value="Search"> </p>
</form>
</form>
<h2 align="left"><font color="#ff0000">Please do not try to download the entire
Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left"><font color="#ff0000">Please do not try to download the
entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply
won't stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left">Shorewall CA Certificate</h2>
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
in your browser. If you don't wish to trust my certificates then
you can either use unencrypted access when subscribing to Shorewall
mailing lists or you can use secure access (SSL) and accept the server's
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
in your browser. If you don't wish to trust my certificates then
you can either use unencrypted access when subscribing to Shorewall
mailing lists or you can use secure access (SSL) and accept the server's
certificate when prompted by your browser.<br>
<h2 align="left">Shorewall Users Mailing List</h2>
<p align="left">The Shorewall Users Mailing list provides a way for users
to get answers to questions and to report problems. Information
of general interest to the Shorewall user community is also posted
<p align="left">The Shorewall Users Mailing list provides a way for users
to get answers to questions and to report problems. Information
of general interest to the Shorewall user community is also posted
to this list.</p>
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="http://www.shorewall.net/support.htm">problem reporting
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="http://www.shorewall.net/support.htm">problem reporting
guidelines</a>.</b></p>
<p align="left">To subscribe to the mailing list:<br>
</p>
<ul>
<li><b>Insecure: </b><a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a></li>
<li><b>SSL:</b> <a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-users"
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-users</a></li>
</ul>
<p align="left">To post to the list, post to <a
href="mailto:shorewall-users@lists.shorewall.net">shorewall-users@lists.shorewall.net</a>.</p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
<p align="left">This list is for announcements of general interest to the
Shorewall community. To subscribe:<br>
</p>
<p align="left"></p>
<ul>
<li><b>Insecure:</b> <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-announce">http://lists.shorewall.net/mailman/listinfo/shorewall-announce</a></li>
<li><b>SSL</b>: <a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-announce"
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-announce.</a></li>
</ul>
<p align="left"><br>
The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-announce">http://lists.shorewall.net/pipermail/shorewall-announce</a>.</p>
<h2 align="left">Shorewall Development Mailing List</h2>
<p align="left">The Shorewall Development Mailing list provides a forum for
the exchange of ideas about the future of Shorewall and for coordinating
ongoing Shorewall Development.</p>
<p align="left">To subscribe to the mailing list:<br>
</p>
<ul>
<li><b>Insecure: </b><a
<li><b>Insecure: </b><a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a></li>
<li><b>SSL:</b> <a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-users"
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-users</a></li>
</ul>
<p align="left">To post to the list, post to <a
href="mailto:shorewall-users@lists.shorewall.net">shorewall-users@lists.shorewall.net</a>.</p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
<p align="left">This list is for announcements of general interest to the
Shorewall community. To subscribe:<br>
</p>
<p align="left"></p>
<ul>
<li><b>Insecure:</b> <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-announce">http://lists.shorewall.net/mailman/listinfo/shorewall-announce</a></li>
<li><b>SSL</b>: <a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-announce"
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-announce.</a></li>
</ul>
<p align="left"><br>
The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-announce">http://lists.shorewall.net/pipermail/shorewall-announce</a>.</p>
<h2 align="left">Shorewall Development Mailing List</h2>
<p align="left">The Shorewall Development Mailing list provides a forum for
the exchange of ideas about the future of Shorewall and for coordinating
ongoing Shorewall Development.</p>
<p align="left">To subscribe to the mailing list:<br>
</p>
<ul>
<li><b>Insecure: </b><a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-devel">http://lists.shorewall.net/mailman/listinfo/shorewall-devel</a></li>
<li><b>SSL:</b> <a
<li><b>SSL:</b> <a
href="https://lists.shorewall.net/mailman/listinfo/shorewall-devel"
target="_top">https//lists.shorewall.net/mailman/listinfo/shorewall-devel.</a></li>
</ul>
<p align="left"> To post to the list, post to <a
href="mailto:shorewall-devel@lists.shorewall.net">shorewall-devel@lists.shorewall.net</a>. </p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-devel">http://lists.shorewall.net/pipermail/shorewall-devel</a>.</p>
<h2 align="left"><a name="Unsubscribe"></a>How to Unsubscribe from one of
<h2 align="left"><a name="Unsubscribe"></a>How to Unsubscribe from one of
the Mailing Lists</h2>
<p align="left">There seems to be near-universal confusion about unsubscribing
from Mailman-managed lists although Mailman 2.1 has attempted
to make this less confusing. To unsubscribe:</p>
<p align="left">There seems to be near-universal confusion about unsubscribing
from Mailman-managed lists although Mailman 2.1 has attempted to
make this less confusing. To unsubscribe:</p>
<ul>
<li>
<p align="left">Follow the same link above that you used to subscribe
<li>
<p align="left">Follow the same link above that you used to subscribe
to the list.</p>
</li>
<li>
<p align="left">Down at the bottom of that page is the following text:
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a password
reminder, or change your subscription options enter your subscription
email address:". Enter your email address in the box and click
on the "<b>Unsubscribe</b> or edit options" button.</p>
</li>
<li>
<p align="left">There will now be a box where you can enter your password
and click on "Unsubscribe"; if you have forgotten your password,
there is another button that will cause your password to be emailed
</li>
<li>
<p align="left">Down at the bottom of that page is the following text:
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a password
reminder, or change your subscription options enter your subscription
email address:". Enter your email address in the box and
click on the "<b>Unsubscribe</b> or edit options" button.</p>
</li>
<li>
<p align="left">There will now be a box where you can enter your password
and click on "Unsubscribe"; if you have forgotten your password,
there is another button that will cause your password to be emailed
to you.</p>
</li>
</li>
</ul>
<hr>
<hr>
<h2 align="left">Frustrated by having to Rebuild Mailman to use it with Postfix?</h2>
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
<p align="left"><font size="2">Last updated 2/3/2003 - <a
<p align="left"><font size="2">Last updated 2/18/2003 - <a
href="http://www.shorewall.net/support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<p align="left"><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>

190
Shorewall-docs/myfiles.htm
View File

@ -1,190 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>My Shorewall Configuration</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">About My Network</font></h1>
</td>
</tr>
</tbody>
</table>
<blockquote> </blockquote>
<h1>My Current Network </h1>
<blockquote>
<p><big><font color="#ff0000"><b>Warning: </b></font><b><small>I</small></b></big><big><b><small>
use a combination of Static NAT and Proxy ARP, neither of which are relevant
to a simple configuration with a single public IP address.</small></b></big><big><b><small>
If you have just a single public IP address, most of what you see here won't
apply to your setup so beware of copying parts of this configuration and expecting
them to work for you. What you copy may or may not work in your setup. </small></b></big><br>
</p>
<p> I have DSL service and have 5 static IP addresses (206.124.146.176-180).
My DSL "modem" (<a href="http://www.fujitsu.com">Fujitsu</a> Speedport)
is connected to eth0. I have a local network connected to eth2 (subnet
192.168.1.0/24) and a DMZ connected to eth1 (192.168.2.0/24). </p>
<p> I use:<br>
</p>
<ul>
<li>Static NAT for ursa (my XP System) - Internal address 192.168.1.5
and external address 206.124.146.178.</li>
<li>Proxy ARP for wookie (my Linux System). This system has two
IP addresses: 192.168.1.3/24 and 206.124.146.179/24.</li>
<li>SNAT through the primary gateway address (206.124.146.176)
for  my Wife's system (tarry) and the Wireless Access Point (wap)</li>
</ul>
<p> The firewall runs on a 128MB PII/233 with RH7.2 and Kernel 2.4.20-pre6.</p>
<p> Wookie runs Samba and acts as the a WINS server.  Wookie is in its
own 'whitelist' zone called 'me'.</p>
<p> My laptop (eastept1) is connected to eth3 using a cross-over cable.
It runs its own <a href="http://www.sygate.com"> Sygate</a> firewall
software and is managed by Proxy ARP. It connects to the local network
through the PopTop server running on my firewall. </p>
<p> The single system in the DMZ (address 206.124.146.177) runs postfix,
Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP
server (Pure-ftpd). The system also runs fetchmail to fetch our email
from our old and current ISPs. That server is managed through Proxy ARP.</p>
<p> The firewall system itself runs a DHCP server that serves the local
network.</p>
<p> All administration and publishing is done using ssh/scp.</p>
<p> I run an SNMP server on my firewall to serve <a
href="http://www.ee.ethz.ch/%7Eoetiker/webtools/mrtg/"> MRTG</a> running
in the DMZ.</p>
<p align="center"> <img border="0"
src="images/network.png" width="764" height="846">
</p>
<p> </p>
<p>The ethernet interface in the Server is configured
with IP address 206.124.146.177, netmask
255.255.255.0. The server's default gateway is
206.124.146.254 (Router at my ISP. This is the same
default gateway used by the firewall itself). On the firewall,
Shorewall automatically adds a host route to
206.124.146.177 through eth1 (192.168.2.1) because
of the entry in /etc/shorewall/proxyarp (see
below).</p>
<p>A similar setup is used on eth3 (192.168.3.1) which
interfaces to my laptop (206.124.146.180).<br>
</p>
<p>Ursa (192.168.1.5 AKA 206.124.146.178) runs a PPTP server for Road Warrior
access.<br>
</p>
<p><font color="#ff0000" size="5"></font></p>
</blockquote>
<h3>Shorewall.conf</h3>
<pre> SUBSYSLOCK=/var/lock/subsys/shorewall<br> STATEDIR=/var/state/shorewall<br><br> LOGRATE=<br> LOGBURST=<br><br> ADD_IP_ALIASES="Yes"<br><br> CLAMPMSS=Yes<br><br> MULTIPORT=Yes</pre>
<h3>Zones File:</h3>
<pre><font face="Courier" size="2"> #ZONE DISPLAY COMMENTS<br> net Internet Internet<br> me Eastep My Workstation<br> loc Local Local networks<br> dmz DMZ Demilitarized zone<br> tx Texas Peer Network in Dallas Texas<br> #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE</font></pre>
<h3>Interfaces File: </h3>
<blockquote>
<p> This is set up so that I can start the firewall before bringing up
my Ethernet interfaces. </p>
</blockquote>
<pre><font face="Courier" size="2"> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 routefilter,norfc1918,blacklist,filterping<br> loc eth2 192.168.1.255 dhcp,filterping,maclist<br> dmz eth1 206.124.146.255 filterping<br> net eth3 206.124.146.255 filterping,blacklist<br> - texas - filterping<br> loc ppp+ - filterping<br> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
<h3>Hosts File: </h3>
<pre><font face="Courier" size="2"> #ZONE HOST(S) OPTIONS<br> me eth2:192.168.1.3,eth2:206.124.146.179<br> tx texas:192.168.9.0/24<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE -- DO NOT REMOVE</font></pre>
<h3>Routestopped File:</h3>
<pre><font face="Courier" size="2"> #INTERFACE HOST(S)<br> eth1 206.124.146.177<br> eth2 -<br> eth3 206.124.146.180</font></pre>
<h3>Common File: </h3>
<pre><font size="2" face="Courier"> . /etc/shorewall/common.def<br> run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP<br></font></pre>
<h3>Policy File:</h3>
<pre><font size="2" face="Courier">
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
me all ACCEPT
tx me ACCEPT #Give Texas access to my personal system
all me CONTINUE #<font
color="#ff0000">WARNING: You must be running Shorewall 1.3.1 or later for<br> </font>#<font
color="#ff0000"> this policy to work as expected!!!</font> <br> loc loc ACCEPT<br> loc net ACCEPT<br> $FW loc ACCEPT<br> $FW tx ACCEPT<br> loc tx ACCEPT<br> loc fw REJECT<br> net net ACCEPT<br> net all DROP info 10/sec:40<br> all all REJECT info<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOTE</font></pre>
<h3>Masq File: </h3>
<blockquote>
<p> Although most of our internal systems use static NAT, my wife's system
(192.168.1.4) uses IP Masquerading (actually SNAT) as do visitors with
laptops. Also, I masquerade wookie to the peer subnet in Texas.</p>
</blockquote>
<pre><font size="2" face="Courier"> #INTERFACE SUBNET ADDRESS<br> eth0 192.168.1.0/24 206.124.146.176<br> texas 206.124.146.179 192.168.1.254<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</font></pre>
<h3>NAT File: </h3>
<pre><font size="2" face="Courier"> #EXTERNAL INTERFACE INTERNAL ALL LOCAL<br> 206.124.146.178 eth0 192.168.1.5 No No<br> 206.124.146.179 eth0 192.168.1.3 No No<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</font></pre>
<h3>Proxy ARP File:</h3>
<pre><font face="Courier" size="2"> #ADDRESS INTERFACE EXTERNAL HAVEROU</font><font
face="Courier" size="2">TE<br> 206.124.146.177 eth1 eth0 No<br> 206.124.146.180 eth3 eth0 No<br></font><pre><font
face="Courier" size="2"> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre></pre>
<h3>Tunnels File (Shell variable TEXAS set in /etc/shorewall/params):</h3>
<pre><small> #TYPE          ZONE    GATEWAY</small><small> <br> gre             net     $TEXAS</small><small><br> #LAST LINE -- DO NOT REMOVE<br></small></pre>
<h3>Rules File (The shell variables
are set in /etc/shorewall/params):</h3>
<pre><font face="Courier" size="2"> #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL<br> # PORT(S) PORT(S) PORT(S) DEST<br> #<br> # Local Network to Internet - Reject attempts by Trojans to call home<br> #<br> REJECT:info loc net tcp 6667<br> #<br> # Local Network to Firewall <br> #<br> ACCEPT loc fw tcp ssh<br> ACCEPT loc fw tcp time<br> #<br> # Local Network to DMZ <br> #<br> ACCEPT loc dmz udp domain<br> ACCEPT loc dmz tcp smtp<br> ACCEPT loc dmz tcp domain<br> ACCEPT loc dmz tcp ssh<br> ACCEPT loc dmz tcp auth<br> ACCEPT loc dmz tcp imap<br> ACCEPT loc dmz tcp https<br> ACCEPT loc dmz tcp imaps<br> ACCEPT loc dmz tcp cvspserver<br> ACCEPT loc dmz tcp www<br> ACCEPT loc dmz tcp ftp<br> ACCEPT loc dmz tcp pop3<br> ACCEPT loc dmz icmp echo-request<br> #<br> # Internet to DMZ <br> #<br> ACCEPT net dmz tcp www<br> ACCEPT net dmz tcp smtp<br> ACCEPT net dmz tcp ftp<br> ACCEPT net dmz tcp auth<br> ACCEPT net dmz tcp https<br> ACCEPT net dmz tcp imaps<br> ACCEPT net dmz tcp domain<br> ACCEPT net dmz tcp cvspserver<br> ACCEPT net dmz udp domain<br> ACCEPT net dmz icmp echo-request<br> ACCEPT net:$MIRRORS dmz tcp rsync<br> #<br> # Net to Me (ICQ chat and file transfers) <br> #<br> ACCEPT net me tcp 4000:4100<br> #<br> # Net to Local <br> #<br> ACCEPT net loc tcp auth<br> REJECT net loc tcp www<br> ACCEPT net loc:192.168.1.5 tcp 1723<br> ACCEPT net loc:192.168.1.5 gre<br> #<br> # DMZ to Internet<br> #<br> ACCEPT dmz net icmp echo-request<br> ACCEPT dmz net tcp smtp<br> ACCEPT dmz net tcp auth<br> ACCEPT dmz net tcp domain<br> ACCEPT dmz net tcp www<br> ACCEPT dmz net tcp https<br> ACCEPT dmz net tcp whois<br> ACCEPT dmz net tcp echo<br> ACCEPT dmz net udp domain<br> ACCEPT dmz net:$NTPSERVERS udp ntp<br> ACCEPT dmz net:$POPSERVERS tcp pop3<br> #<br> # The following compensates for a bug, either in some FTP clients or in the<br> # Netfilter connection tracking code that occasionally denies active mode<br> # FTP clients<br> #<br> ACCEPT:info dmz net tcp 1024: 20<br> #<br> # DMZ to Firewall -- snmp<br> #<br> ACCEPT dmz fw tcp snmp<br> ACCEPT dmz fw udp snmp<br> #<br> # DMZ to Local Network <br> #<br> ACCEPT dmz loc tcp smtp<br> ACCEPT dmz loc tcp auth<br> ACCEPT dmz loc icmp echo-request<br> # Internet to Firewall<br> #<br> REJECT net fw tcp www<br> #<br> # Firewall to Internet<br> #<br> ACCEPT fw net:$NTPSERVERS udp ntp<br> ACCEPT fw net udp domain<br> ACCEPT fw net tcp domain<br> ACCEPT fw net tcp www<br> ACCEPT fw net tcp https<br> ACCEPT fw net tcp ssh<br> ACCEPT fw net tcp whois<br> ACCEPT fw net icmp echo-request<br> #<br> # Firewall to DMZ<br> #<br> ACCEPT fw dmz tcp www<br> ACCEPT fw dmz tcp ftp<br> ACCEPT fw dmz tcp ssh<br> ACCEPT fw dmz tcp smtp<br> ACCEPT fw dmz udp domain<br> #<br> # Let Texas Ping<br> #<br> ACCEPT tx fw icmp echo-request<br> ACCEPT tx loc icmp echo-request<br><br> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE</font></pre>
<p><font size="2"> Last updated 1/12/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>
<br>
</body>
</html>

275
Shorewall-docs/ping.html
View File

@ -2,147 +2,184 @@
<html>
<head>
<title>ICMP Echo-request (Ping)</title>
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<meta name="author" content="Tom Eastep">
</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%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">ICMP Echo-request (Ping)</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<br>
Shorewall 'Ping' management has evolved over time with the latest change
coming in Shorewall version 1.3.14. In that version, a new option (<b>OLD_PING_HANDLING</b>)
was added to /etc/shorewall/shorewall.conf. The value of that option determines
the overall handling of ICMP echo requests (pings).<br>
<h2>Shorewall Versions &gt;= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf</h2>
In 1.3.14, Ping handling was put under control of the rules and policies
just like any other connection request. In order to accept ping requests from
zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need
a rule in /etc/shoreall/rules of the form:<br>
<br>
Shorewall 'Ping' management has evolved over time with the latest change
coming in Shorewall version 1.4.0. <br>
<h2>Shorewall Versions &gt;= 1.4.0</h2>
In order to accept ping requests from zone z1 to zone z2 where the policy
for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the
form:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example: <br>
<br>
To permit ping from the local zone to the firewall:<br>
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example: <br>
<br>
To permit ping from the local zone to the firewall:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
If you would like to accept 'ping' by default even when the relevant
policy is DROP or REJECT, create <b>/etc/shorewall/icmpdef </b>if it doesn't
already exist and in that file place the following command:<br>
<blockquote>
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
If you would like to accept 'ping' by default even when the relevant
policy is DROP or REJECT, create <b>/etc/shorewall/icmpdef </b>if it doesn't
already exist and in that file place the following command:<br>
<blockquote>
<pre><b><font color="#009900">run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT<br></font></b></pre>
</blockquote>
With that rule in place, if you want to ignore 'ping' from z1 to z2 then
you need a rule of the form:<br>
</blockquote>
With that rule in place, if you want to ignore 'ping' from z1 to z2 then
you need a rule of the form:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example:<br>
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example:<br>
<br>
To drop ping from the internet, you would need this rule in /etc/shorewall/rules:<br>
<br>
To drop ping from the internet, you would need this rule in /etc/shorewall/rules:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
<blockquote> </blockquote>
<h2>Shorewall Versions &lt; 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf<br>
</h2>
There are several aspects to the old Shorewall Ping management:<br>
<ol>
<li>The <b>noping</b> and <b>filterping </b>interface options in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>The <b>FORWARDPING</b> option in<a href="Documentation.htm#Conf">
/etc/shorewall/shorewall.conf</a>.</li>
<li>Explicit rules in <a href="Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
</ol>
There are two cases to consider:<br>
<ol>
<li>Ping requests addressed to the firewall itself; and</li>
<li>Ping requests being forwarded to another system. Included here are
all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple
routing.</li>
</ol>
These cases will be covered separately.<br>
<h3>Ping Requests Addressed to the Firewall Itself</h3>
For ping requests addressed to the firewall, the sequence is as follows:<br>
<ol>
<li>If neither <b>noping</b> nor <b>filterping </b>are specified for
the interface that receives the ping request then the request will be responded
to with an ICMP echo-reply.</li>
<li>If <b>noping</b> is specified for the interface that receives the
ping request then the request is ignored.</li>
<li>If <b>filterping </b>is specified for the interface then the request
is passed to the rules/policy evaluation.</li>
</ol>
<h3>Ping Requests Forwarded by the Firewall</h3>
These requests are <b>always</b> passed to rules/policy evaluation.<br>
<h3>Rules Evaluation</h3>
Ping requests are ICMP type 8. So the general rule format is:<br>
<br>
&nbsp;&nbsp;&nbsp; <i>Target&nbsp;&nbsp;&nbsp; Source&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp; </i>icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 1. Accept pings from the net to the dmz (pings are responded to
with an ICMP echo-reply):<br>
<br>
&nbsp;&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 2. Drop pings from the net to the firewall<br>
<br>
&nbsp;&nbsp;&nbsp; DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
<h3>Policy Evaluation</h3>
If no applicable rule is found, then the policy for the source to the destination
is applied.<br>
<ol>
<li>If the relevant policy is ACCEPT then the request is responded to
with an ICMP echo-reply.</li>
<li>If <b>FORWARDPING</b> is set to Yes in /etc/shorewall/shorewall.conf
then the request is responded to with an ICMP echo-reply.</li>
<li>Otherwise, the relevant REJECT or DROP policy is used and the request
is either rejected or simply ignored.</li>
</ol>
<p><font size="2">Updated 1/21/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<h2>Shorewall Versions &gt;= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf</h2>
In 1.3.14, Ping handling was put under control of the rules and policies
just like any other connection request. In order to accept ping requests
from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need
a rule in /etc/shoreall/rules of the form:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example: <br>
<br>
To permit ping from the local zone to the firewall:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
If you would like to accept 'ping' by default even when the relevant
policy is DROP or REJECT, create <b>/etc/shorewall/icmpdef </b>if it doesn't
already exist and in that file place the following command:<br>
<blockquote>
<pre><b><font color="#009900">run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT<br></font></b></pre>
</blockquote>
With that rule in place, if you want to ignore 'ping' from z1 to z2 then
you need a rule of the form:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example:<br>
<br>
To drop ping from the internet, you would need this rule in /etc/shorewall/rules:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
<blockquote> </blockquote>
<h2>Shorewall Versions &lt; 1.3.14 or with OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf<br>
</h2>
There are several aspects to the old Shorewall Ping management:<br>
<ol>
<li>The <b>noping</b> and <b>filterping </b>interface options in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>The <b>FORWARDPING</b> option in<a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf</a>.</li>
<li>Explicit rules in <a href="Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
</ol>
There are two cases to consider:<br>
<ol>
<li>Ping requests addressed to the firewall itself; and</li>
<li>Ping requests being forwarded to another system. Included here
are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP
and simple routing.</li>
</ol>
These cases will be covered separately.<br>
<h3>Ping Requests Addressed to the Firewall Itself</h3>
For ping requests addressed to the firewall, the sequence is as follows:<br>
<ol>
<li>If neither <b>noping</b> nor <b>filterping </b>are specified for
the interface that receives the ping request then the request will be responded
to with an ICMP echo-reply.</li>
<li>If <b>noping</b> is specified for the interface that receives the
ping request then the request is ignored.</li>
<li>If <b>filterping </b>is specified for the interface then the request
is passed to the rules/policy evaluation.</li>
</ol>
<h3>Ping Requests Forwarded by the Firewall</h3>
These requests are <b>always</b> passed to rules/policy evaluation.<br>
<h3>Rules Evaluation</h3>
Ping requests are ICMP type 8. So the general rule format is:<br>
<br>
&nbsp;&nbsp;&nbsp; <i>Target&nbsp;&nbsp;&nbsp; Source&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp; </i>icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 1. Accept pings from the net to the dmz (pings are responded
to with an ICMP echo-reply):<br>
<br>
&nbsp;&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 2. Drop pings from the net to the firewall<br>
<br>
&nbsp;&nbsp;&nbsp; DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
<h3>Policy Evaluation</h3>
If no applicable rule is found, then the policy for the source to the
destination is applied.<br>
<ol>
<li>If the relevant policy is ACCEPT then the request is responded
to with an ICMP echo-reply.</li>
<li>If <b>FORWARDPING</b> is set to Yes in /etc/shorewall/shorewall.conf
then the request is responded to with an ICMP echo-reply.</li>
<li>Otherwise, the relevant REJECT or DROP policy is used and the request
is either rejected or simply ignored.</li>
</ol>
<p><font size="2">Updated 2/14/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy; <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></p>
<br>
<br>
<br>
<br>
<br>

388
Shorewall-docs/seattlefirewall_index.htm
View File

@ -6,31 +6,32 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base target="_self">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="100%" height="90">
<td width="100%" height="90">
@ -39,15 +40,16 @@
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font></h1>
</a></i></font><font color="#ffffff">Shorewall
1.4 - <font size="4">"<i>iptables made
easy"</i></font></font></h1>
@ -56,42 +58,44 @@
<div align="center"><a
href="http://shorewall.sf.net/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a><br>
href="http://shorewall.sf.net/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a><br>
</div>
</div>
<br>
<br>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tbody>
<tr>
<tr>
<td width="90%">
<td width="90%">
@ -100,7 +104,8 @@
<h2 align="left">What is it?</h2>
@ -112,7 +117,8 @@
<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
@ -127,28 +133,30 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<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
Foundation.<br>
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>
<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>
<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>
@ -159,7 +167,8 @@ with this program; if not, write to the Free Software
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -171,28 +180,31 @@ with this program; if not, write to the Free Software
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric Wolzak
have a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called <i>Bering</i>
that features Shorewall-1.3.10 and Kernel-2.4.18.
You can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
</a>Jacques Nilo and
Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
</p>
Bering 1.1!!!</b><br>
</p>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
@ -207,7 +219,8 @@ Bering 1.0 Final!!! </b><br>
<h2>News</h2>
@ -219,7 +232,7 @@ Bering 1.0 Final!!! </b><br>
<h2></h2>
@ -228,116 +241,111 @@ Bering 1.0 Final!!! </b><br>
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>New features include</p>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <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</pre>
<pre>  [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></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- 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</pre>
<pre>   [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>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <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</pre>
<pre>   [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>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
<br>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard. See
<a href="http://www.webmin.com">http://www.webmin.com</a>.<b> </b>
<p><b></b></p>
<p><b></b></p>
<p><b>3/14/2003 - Shorewall 1.4.0</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p></p>
Shorewall 1.4 represents the next step in the evolution of Shorewall.
The main thrust of the initial release is simply to remove the cruft that
has accumulated in Shorewall over time. <br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
OLD_PING_HANDLING=Yes will generate an error at startup as will specification
of the 'noping' or 'filterping' interface options.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
<br>
</li>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<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 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.<br>
</li>
</ul>
<ol>
</ol>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in
/usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
</li>
</ol>
<ul>
</ul>
<p><b></b><a href="News.htm">More News</a></p>
@ -349,40 +357,45 @@ on subnetworks that you don't wish to masquerade.<br>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
valign="top" align="center"> <a
</td>
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <a
href="http://sourceforge.net">M</a></td>
</tr>
</tr>
</tbody>
</table>
</center>
</center>
</div>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="100%" style="margin-top: 1px;">
<td width="100%"
style="margin-top: 1px;">
@ -391,12 +404,12 @@ on subnetworks that you don't wish to masquerade.<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">
  </a></p>
  </a></p>
@ -406,30 +419,33 @@ on subnetworks that you don't wish to masquerade.<br>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to <a
to <a
href="http://www.starlight.org"><font color="#ffffff">Starlight
Children's Foundation.</font></a> Thanks!</font></p>
</td>
</td>
</tr>
</tr>
</tbody>
</table>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
<br>
</p>
</body>
</html>

165
Shorewall-docs/shoreline.htm
View File

@ -1,126 +1,125 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>About the Shorewall Author</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Tom Eastep</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p align="center"> <img border="3" src="images/TomNTarry.png"
alt="Tom on the PCT - 1991" width="316" height="392">
</p>
</p>
<p align="center">Tarry &amp; Tom -- August 2002<br>
<br>
</p>
<br>
</p>
<ul>
<li>Born 1945 in <a
<li>Born 1945 in <a
href="http://www.experiencewashington.com">Washington State</a> .</li>
<li>BA Mathematics from <a href="http://www.wsu.edu">Washington
State University</a> 1967</li>
<li>MA Mathematics from <a
<li>BA Mathematics from <a href="http://www.wsu.edu">Washington
State University</a> 1967</li>
<li>MA Mathematics from <a
href="http://www.washington.edu">University of Washington</a> 1969</li>
<li>Burroughs Corporation (now <a
<li>Burroughs Corporation (now <a
href="http://www.unisys.com">Unisys</a> ) 1969 - 1980</li>
<li><a href="http://www.tandem.com">Tandem Computers, Incorporated</a>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980
- present</li>
<li>Married 1969 - no children.</li>
</ul>
<p>I am currently a member of the design team for the next-generation
operating system from the NonStop Enterprise Division of HP. </p>
<p>I became interested in Internet Security when I established a home office
in 1999 and had DSL service installed in our home. I investigated
ipchains and developed the scripts which are now collectively known as
<a href="http://seawall.sourceforge.net"> Seattle Firewall</a>. Expanding
on what I learned from Seattle Firewall, I then designed and wrote
Shorewall. </p>
<p>I telework from our home in <a href="http://www.cityofshoreline.com">Shoreline,
Washington</a> where I live with my wife Tarry. </p>
<p>Our current home network consists of: </p>
<li><a href="http://www.tandem.com">Tandem Computers, Incorporated</a>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980 -
present</li>
<li>Married 1969 - no children.</li>
<ul>
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB &amp; 20GB
IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Serves
as a PPTP server for Road Warrior access. Dual boots <a
href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
NIC - My personal Linux System which runs Samba configured as a
WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run both
<a href="http://www.debian.org">Debian Woody</a> and <a
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC 
- Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd),
DNS server (Bind 9).</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX 
(Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.14  and a DHCP
server.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC -
My wife's personal system.</li>
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard
EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main
work system.</li>
</ul>
<p>For more about our network see <a href="myfiles.htm">my Shorewall Configuration</a>.</p>
<p>I am currently a member of the design team for the next-generation
operating system from the NonStop Enterprise Division of HP. </p>
<p>I became interested in Internet Security when I established a home office
in 1999 and had DSL service installed in our home. I investigated
ipchains and developed the scripts which are now collectively known
as <a href="http://seawall.sourceforge.net"> Seattle Firewall</a>.
Expanding on what I learned from Seattle Firewall, I then designed
and wrote Shorewall. </p>
<p>I telework from our home in <a href="http://www.cityofshoreline.com">Shoreline,
Washington</a> where I live with my wife Tarry. </p>
<p>Our current home network consists of: </p>
<ul>
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB &amp;
20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system.
Serves as a PPTP server for Road Warrior access. Dual boots <a
href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
NIC - My personal Linux System which runs Samba configured as
a WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run
both <a href="http://www.debian.org">Debian Woody</a> and <a
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC 
- Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd),
DNS server (Bind 9).</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3
LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.4.0
Alpha 2  and a DHCP server.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC -
My wife's personal system.</li>
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard
EEPRO100 and EEPRO100 in expansion base and LinkSys WAC11 - My main
work system.</li>
</ul>
<p>All of our other systems are made by <a
href="http://www.compaq.com">Compaq</a> (part of the new <a
href="http://www.hp.com/">HP</a>).. All of our Tulip NICs are <a
href="http://www.netgear.com">Netgear</a> FA310TXs.</p>
<p><a href="http://www.redhat.com"><img border="0"
src="images/poweredby.png" width="88" height="31">
</a><a href="http://www.compaq.com"><img border="0"
</a><a href="http://www.compaq.com"><img border="0"
src="images/poweredbycompaqlog0.gif" hspace="3" width="83" height="25">
</a><a href="http://www.pureftpd.org"><img border="0"
</a><a href="http://www.pureftpd.org"><img border="0"
src="images/pure.jpg" width="88" height="31">
</a><font size="4"><a href="http://www.apache.org"><img
</a><font size="4"><a href="http://www.apache.org"><img
border="0" src="images/apache_pb1.gif" hspace="2" width="170"
height="20">
</a><a href="http://www.mandrakelinux.com"><img
</a><a href="http://www.mandrakelinux.com"><img
src="images/medbutton.png" alt="Powered by Mandrake" width="90"
height="32">
</a><img src="images/shorewall.jpg" alt="Protected by Shorewall"
</a><img src="images/shorewall.jpg" alt="Protected by Shorewall"
width="125" height="40" hspace="4">
</font></p>
<p><font size="2">Last updated 1/24/2003 - </font><font size="2"> <a
</font></p>
<p><font size="2">Last updated 2/18/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </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>
<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>
<br>
<br>
</body>
</html>

139
Shorewall-docs/shorewall_extension_scripts.htm
View File

@ -1,133 +1,126 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Extension Scripts</title>
</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>
<tbody>
<tr>
<td width="100%">
<td width="100%">
<h1 align="center"><font color="#ffffff">Extension Scripts</font></h1>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
<p> Extension scripts are user-provided scripts that are invoked at various
points during firewall start, restart, stop and clear. The scripts are
placed in /etc/shorewall and are processed using the Bourne shell "source"
<p> Extension scripts are user-provided scripts that are invoked at various
points during firewall start, restart, stop and clear. The scripts are
placed in /etc/shorewall and are processed using the Bourne shell "source"
mechanism. The following scripts can be supplied:</p>
<ul>
<li>init -- invoked early in "shorewall start" and "shorewall restart"</li>
<li>start -- invoked after the firewall has been started or restarted.</li>
<li>stop -- invoked as a first step when the firewall is being stopped.</li>
<li>stopped -- invoked after the firewall has been stopped.</li>
<li>clear -- invoked after the firewall has been cleared.</li>
<li>refresh -- invoked while the firewall is being refreshed but before
<li>init -- invoked early in "shorewall start" and "shorewall
restart"</li>
<li>start -- invoked after the firewall has been started or restarted.</li>
<li>stop -- invoked as a first step when the firewall is being stopped.</li>
<li>stopped -- invoked after the firewall has been stopped.</li>
<li>clear -- invoked after the firewall has been cleared.</li>
<li>refresh -- invoked while the firewall is being refreshed but before
the common and/or blacklst chains have been rebuilt.</li>
<li>newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn'
<li>newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn'
chain has been created but before any rules have been added to it.</li>
</ul>
<p><u><b>If your version of Shorewall doesn't have the file that you want
<p><u><b>If your version of Shorewall doesn't have the file that you want
to use from the above list, you can simply create the file yourself.</b></u></p>
<p> You can also supply a script with the same name as any of the filter
chains in the firewall and the script will be invoked after the /etc/shorewall/rules
file has been processed but before the /etc/shorewall/policy file has been
processed.</p>
<p> You can also supply a script with the same name as any of the filter
chains in the firewall and the script will be invoked after the /etc/shorewall/rules
file has been processed but before the /etc/shorewall/policy file has
been processed.</p>
<p>The /etc/shorewall/common file receives special treatment. If this file
is present, the rules that it defines will totally replace the default
rules in the common chain. These default rules are contained in the
file /etc/shorewall/common.def which may be used as a starting point
<p>The /etc/shorewall/common file receives special treatment. If this file
is present, the rules that it defines will totally replace the default
rules in the common chain. These default rules are contained in the
file /etc/shorewall/common.def which may be used as a starting point
for making your own customized file.</p>
<p> Rather than running iptables directly, you should run it using the
function run_iptables. Similarly, rather than running "ip" directly,
you should use run_ip. These functions accept the same arguments as the
underlying command but cause the firewall to be stopped if an error occurs
<p> Rather than running iptables directly, you should run it using the
function run_iptables. Similarly, rather than running "ip" directly,
you should use run_ip. These functions accept the same arguments as the
underlying command but cause the firewall to be stopped if an error occurs
during processing of the command.</p>
<p> If you decide to create /etc/shorewall/common it is a good idea to
use the following technique</p>
<p> If you decide to create /etc/shorewall/common it is a good idea to use
the following technique</p>
<p> /etc/shorewall/common:</p>
<blockquote>
<blockquote>
<pre>. /etc/shorewall/common.def<br>&lt;add your rules here&gt;</pre>
</blockquote>
<p>If you need to supercede a rule in the released common.def file, you can
add the superceding rule before the '.' command. Using this technique allows
you to add new rules while still getting the benefit of the latest common.def
</blockquote>
<p>If you need to supercede a rule in the released common.def file, you can
add the superceding rule before the '.' command. Using this technique allows
you to add new rules while still getting the benefit of the latest common.def
file.</p>
<p>Remember that /etc/shorewall/common defines rules that are only applied
if the applicable policy is DROP or REJECT. These rules are NOT applied
<p>Remember that /etc/shorewall/common defines rules that are only applied
if the applicable policy is DROP or REJECT. These rules are NOT applied
if the policy is ACCEPT or CONTINUE.</p>
<p>If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will
be rejected by the firewall. It is recommended with this setting that you
create the file /etc/shorewall/icmpdef and in it place the following commands:</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT<br></pre>
<p align="left"><font size="2">Last updated 12/22/2002 - <a
<p align="left"><font size="2">Last updated 2/18/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002 Thomas
M. Eastep</font></a></p>
<br>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
</body>
</html>

414
Shorewall-docs/shorewall_quickstart_guide.htm
View File

@ -1,299 +1,299 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall QuickStart Guide</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
Version 3.1</font></h1>
</td>
</tr>
</tbody>
<h1 align="center"><font color="#ffffff">Shorewall QuickStart Guides
(HOWTO's)<br>
Version 3.1</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>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
<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>
<h2>The Guides</h2>
<p>These guides provide step-by-step instructions for configuring Shorewall
in common firewall setups.</p>
<p>These guides provide step-by-step instructions for configuring Shorewall
in common firewall setups.</p>
<p>The following guides are for <b>users who have a single public IP address</b>:</p>
<ul>
<li><a href="standalone.htm">Standalone</a> Linux System
(<a href="standalone_fr.html">Version Française</a>)</li>
<li><a href="two-interface.htm">Two-interface</a> Linux
System acting as a firewall/router for a small local network (<a
<li><a href="standalone.htm">Standalone</a> Linux System
(<a href="standalone_fr.html">Version Française</a>)</li>
<li><a href="two-interface.htm">Two-interface</a> Linux
System acting as a firewall/router for a small local network (<a
href="two-interface_fr.html">Version Française</a>)</li>
<li><a href="three-interface.htm">Three-interface</a>
Linux System acting as a firewall/router for a small local network
and a DMZ. (<a href="three-interface_fr.html">Version Française</a>)</li>
<li><a href="three-interface.htm">Three-interface</a>
Linux System acting as a firewall/router for a small local network
and a DMZ. (<a href="three-interface_fr.html">Version Française</a>)</li>
</ul>
<p>The above guides are designed to get your first firewall up and running
quickly in the three most common Shorewall configurations.</p>
<p>The <a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a> outlines
the steps necessary to set up a firewall where <b>there are multiple
public IP addresses involved or if you want to learn more about Shorewall
than is explained in the single-address guides above.</b></p>
<p>The above guides are designed to get your first firewall up and running
quickly in the three most common Shorewall configurations.</p>
<p>The <a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a> outlines
the steps necessary to set up a firewall where <b>there are multiple
public IP addresses involved or if you want to learn more about
Shorewall than is explained in the single-address guides above.</b></p>
<ul>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0
Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0
<li><a
href="shorewall_setup_guide.htm#Introduction">1.0 Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0
Shorewall Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0
Network Interfaces</a></li>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0
Addressing, Subnets and Routing</a>
<li><a href="shorewall_setup_guide.htm#Addressing">4.0
Addressing, Subnets and Routing</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Addresses">4.1
IP Addresses</a></li>
<li><a
<li><a href="shorewall_setup_guide.htm#Addresses">4.1
IP Addresses</a></li>
<li><a
href="shorewall_setup_guide.htm#Subnets">4.2 Subnets</a></li>
<li><a href="shorewall_setup_guide.htm#Routing">4.3
Routing</a></li>
<li><a href="shorewall_setup_guide.htm#ARP">4.4 Address
Resolution Protocol</a></li>
<li><a href="shorewall_setup_guide.htm#Routing">4.3
Routing</a></li>
<li><a href="shorewall_setup_guide.htm#ARP">4.4 Address
Resolution Protocol</a></li>
</ul>
<ul>
<li><a href="shorewall_setup_guide.htm#RFC1918">4.5
RFC 1918</a></li>
<li><a href="shorewall_setup_guide.htm#RFC1918">4.5
RFC 1918</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Options">5.0 Setting
up your Network</a>
</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
<li><a href="shorewall_setup_guide.htm#Routed">5.1
Routed</a></li>
</ul>
<ul>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2
Non-routed</a>
<li><a href="shorewall_setup_guide.htm#NonRouted">5.2
Non-routed</a>
<ul>
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1
<li><a href="shorewall_setup_guide.htm#SNAT">5.2.1
SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2
DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#ProxyARP">5.2.3
Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4
Static NAT</a></li>
<li><a
href="shorewall_setup_guide.htm#ProxyARP">5.2.3 Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4
Static NAT</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3
Rules</a></li>
<li><a
href="shorewall_setup_guide.htm#OddsAndEnds">5.4 Odds and Ends</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#DNS">6.0 DNS</a></li>
<li><a
href="shorewall_setup_guide.htm#StartingAndStopping">7.0 Starting and
</li>
<li><a href="shorewall_setup_guide.htm#DNS">6.0 DNS</a></li>
<li><a
href="shorewall_setup_guide.htm#StartingAndStopping">7.0 Starting and
Stopping the Firewall</a></li>
</ul>
<h2><a name="Documentation"></a>Documentation Index</h2>
<p>The following documentation covers a variety of topics and <b>supplements
the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
described above</b>. Please review the appropriate guide before trying
to use this documentation directly.</p>
<ul>
<li><a href="blacklisting_support.htm">Blacklisting</a>
<ul>
<li>Static Blacklisting using /etc/shorewall/blacklist</li>
<li>Dynamic Blacklisting using /sbin/shorewall</li>
</ul>
</li>
<li><a href="configuration_file_basics.htm">Common configuration
file features</a>
</ul>
<h2><a name="Documentation"></a>Documentation Index</h2>
<p>The following documentation covers a variety of topics and <b>supplements
the <a href="shorewall_quickstart_guide.htm">QuickStart Guides</a>
described above</b>. Please review the appropriate guide before trying
to use this documentation directly.</p>
<ul>
<li><a href="blacklisting_support.htm">Blacklisting</a>
<ul>
<li><a
href="configuration_file_basics.htm#Comments">Comments in configuration
files</a></li>
<li><a
<li>Static Blacklisting using /etc/shorewall/blacklist</li>
<li>Dynamic Blacklisting using /sbin/shorewall</li>
</ul>
</li>
<li><a href="configuration_file_basics.htm">Common configuration
file features</a>
<ul>
<li><a
href="configuration_file_basics.htm#Comments">Comments in configuration
files</a></li>
<li><a
href="configuration_file_basics.htm#Continuation">Line Continuation</a></li>
<li><a href="configuration_file_basics.htm#Ports">Port
<li><a href="configuration_file_basics.htm#Ports">Port
Numbers/Service Names</a></li>
<li><a href="configuration_file_basics.htm#Ranges">Port
Ranges</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#Ranges">Port Ranges</a></li>
<li><a
href="configuration_file_basics.htm#Variables">Using Shell Variables</a></li>
<li><a
<li><a
href="configuration_file_basics.htm#dnsnames">Using DNS Names</a><br>
</li>
<li><a
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>
<li><a href="configuration_file_basics.htm#MAC">Using
MAC Addresses in Shorewall</a></li>
</li>
<li><a
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>
<li><a href="configuration_file_basics.htm#MAC">Using
MAC Addresses in Shorewall</a></li>
</ul>
</li>
<li><a href="Documentation.htm">Configuration File Reference
Manual</a>
</li>
<li><a href="Documentation.htm">Configuration File Reference
Manual</a>
<ul>
<li> <a href="Documentation.htm#Variables">params</a></li>
<li><font color="#000099"><a
<li> <a href="Documentation.htm#Variables">params</a></li>
<li><font color="#000099"><a
href="Documentation.htm#Zones">zones</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Interfaces">interfaces</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Hosts">hosts</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Policy">policy</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Rules">rules</a></font></li>
<li><a href="Documentation.htm#Common">common</a></li>
<li><font color="#000099"><a
<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
<li><font color="#000099"><a
href="Documentation.htm#ProxyArp">proxyarp</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#NAT">nat</a></font></li>
<li><font color="#000099"><a
<li><font color="#000099"><a
href="Documentation.htm#Tunnels">tunnels</a></font></li>
<li><a href="traffic_shaping.htm#tcrules">tcrules</a></li>
<li><font color="#000099"><a
<li><a href="traffic_shaping.htm#tcrules">tcrules</a></li>
<li><font color="#000099"><a
href="Documentation.htm#Conf">shorewall.conf</a></font></li>
<li><a href="Documentation.htm#modules">modules</a></li>
<li><a href="Documentation.htm#TOS">tos</a> </li>
<li><a href="Documentation.htm#Blacklist">blacklist</a></li>
<li><a href="Documentation.htm#rfc1918">rfc1918</a></li>
<li><a href="Documentation.htm#Routestopped">routestopped</a></li>
<li><a href="Documentation.htm#modules">modules</a></li>
<li><a href="Documentation.htm#TOS">tos</a> </li>
<li><a href="Documentation.htm#Blacklist">blacklist</a></li>
<li><a href="Documentation.htm#rfc1918">rfc1918</a></li>
<li><a href="Documentation.htm#Routestopped">routestopped</a></li>
</ul>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall
Structure</a></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>
<li><a href="myfiles.htm">My Configuration Files</a> (How I personally
use Shorewall)</li>
<li><a href="ping.html">'Ping' Management</a><br>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font> (How
to extend Shorewall without modifying Shorewall code)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall
Structure</a></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="ports.htm">Port Information</a>
<li><a href="MAC_Validation.html">MAC Verification</a><br>
</li>
<li><a href="ping.html">'Ping' Management</a><br>
</li>
<li><a href="ports.htm">Port Information</a>
<ul>
<li>Which applications use which ports</li>
<li>Ports used by Trojans</li>
<li>Which applications use which ports</li>
<li>Ports used by Trojans</li>
</ul>
</li>
<li><a href="ProxyARP.htm">Proxy ARP</a></li>
<li><a href="samba.htm">Samba</a></li>
<li><font color="#000099"><a
</li>
<li><a href="ProxyARP.htm">Proxy ARP</a></li>
<li><a href="samba.htm">Samba</a></li>
<li><font color="#000099"><a
href="starting_and_stopping_shorewall.htm">Starting/stopping the Firewall</a></font></li>
<ul>
<li>Description of all /sbin/shorewall commands</li>
<li>How to safely test a Shorewall configuration change<br>
</li>
<li>Description of all /sbin/shorewall commands</li>
<li>How to safely test a Shorewall configuration change<br>
</li>
</ul>
<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>
<li><a href="traffic_shaping.htm">Traffic Shaping/QOS</a></li>
<li>VPN
<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>
<li><a href="traffic_shaping.htm">Traffic Shaping/QOS</a></li>
<li>VPN
<ul>
<li><a href="IPSEC.htm">IPSEC</a></li>
<li><a href="IPIP.htm">GRE and IPIP</a></li>
<li><a href="OPENVPN.html">OpenVPN</a><br>
</li>
<li><a href="PPTP.htm">PPTP</a></li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from a system
<li><a href="IPSEC.htm">IPSEC</a></li>
<li><a href="IPIP.htm">GRE and IPIP</a></li>
<li><a href="OPENVPN.html">OpenVPN</a><br>
</li>
<li><a href="PPTP.htm">PPTP</a></li>
<li><a href="VPN.htm">IPSEC/PPTP</a> from a system
behind your firewall to a remote network.</li>
</ul>
</li>
<li><a href="whitelisting_under_shorewall.htm">White
</li>
<li><a href="whitelisting_under_shorewall.htm">White
List Creation</a></li>
</ul>
<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 2/4/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
<p><a href="copyright.htm"><font size="2">Copyright 2002, 2003 Thomas M.
Eastep</font></a><br>
</p>
</p>
<br>
<br>
<br>
<br>

4114
Shorewall-docs/shorewall_setup_guide.htm
View File

File diff suppressed because it is too large Load Diff

482
Shorewall-docs/sourceforge_index.htm
View File

@ -6,31 +6,34 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base
target="_self">
<meta name="author" content="Tom Eastep">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
<tbody>
<tbody>
<tr>
<tr>
<td width="100%" height="90">
<td width="100%"
height="90">
@ -40,16 +43,16 @@
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font><a href="http://www.sf.net">
</a></h1>
</a></i></font><font
color="#ffffff">Shorewall 1.4 - <font size="4">"<i>iptables
made easy"</i></font></font><a
href="http://www.sf.net"> </a></h1>
@ -59,34 +62,36 @@
<div align="center"><a href="/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a></div>
</td>
</tr>
<div align="center"><a href="/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a></div>
</td>
</tr>
</tbody>
</tbody>
</table>
<div align="center">
<center>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tbody>
<tr>
<tr>
<td width="90%">
<td width="90%">
@ -96,7 +101,8 @@
<h2 align="left">What is it?</h2>
@ -109,11 +115,12 @@
<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>
<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>
@ -125,29 +132,29 @@
<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
Foundation.<br>
<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
Foundation.<br>
<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>
<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>
@ -159,7 +166,7 @@ Software Foundation, Inc., 675 Mass Ave, Cambridge
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -172,23 +179,25 @@ Software Foundation, Inc., 675 Mass Ave, Cambridge
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric
Wolzak have a LEAF (router/firewall/gateway on
a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.10
and Kernel-2.4.18. You 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.0 Final!!! <br>
</b>
</a>Jacques Nilo
and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>
</b>
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.1!!!</b><br>
<h2>News</h2>
@ -203,100 +212,98 @@ a floppy, CD or compact flash) distribution called
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
<p><b>3/14/2003 - Shorewall 1.4.0</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>New features include</p>
</b></p>
Shorewall 1.4 represents the
next step in the evolution of Shorewall. The main thrust of the initial
release is simply to remove the cruft that has accumulated in Shorewall
over time. <br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <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</pre>
<pre>  [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></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- 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</pre>
<pre>   [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>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <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</pre>
<pre>   [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>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
OLD_PING_HANDLING=Yes will generate an error at startup as will specification
of the 'noping' or 'filterping' interface options.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
<br>
</li>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard.
See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</b>
<p><b></b></p>
<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 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>
<ul>
</ul>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG and CONTINUE are now a valid actions for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in
/usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
<br>
</li>
</ol>
<p></p>
<b> </b>
@ -304,7 +311,8 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<ul>
@ -312,7 +320,8 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</ul>
@ -320,7 +329,8 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<p><a href="News.htm">More News</a></p>
@ -333,28 +343,32 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h2> </h2>
<h1 align="center"><a href="http://www.sf.net"><img align="left"
alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
</a></h1>
</a></h1>
<h4> </h4>
<h2>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </h2>
@ -362,15 +376,78 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h2><a name="Donations"></a>Donations</h2>
</td>
</td>
<td width="88"
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <br>
</td>
</td>
</tr>
</tbody>
</table>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%"
style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
<p align="center"><font size="4" color="#ffffff">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></p>
</td>
</tr>
@ -378,78 +455,17 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</tbody>
</tbody>
</table>
</center>
</div>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
<tbody>
<tr>
<td width="100%"
style="margin-top: 1px;">
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
</a></p>
<p align="center"><font size="4" color="#ffffff">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></p>
</td>
</tr>
</tbody>
</table>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</body>
</html>

79
Shorewall-docs/spam_filters.htm
View File

@ -1,62 +1,69 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>SPAM Filters</title>
</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%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">SPAM Filters</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<h1 align="center"><br>
<a href="http://ordb.org"> <a href="http://www.spamassassin.org"><img
<a href="http://ordb.org"> </a><a href="http://www.spamassassin.org"><img
src="images/ninjalogo.png" alt="(SpamAssassin Logo)" width="100"
height="38">
</a><img border="0" src="images/but3.png" hspace="3" width="88"
</a><img border="0" src="images/but3.png" hspace="3" width="88"
height="31">
</a></h1>
<p>Like all of you, I'm concerned about the increasing volume of Unsolicited
Commercial Email (UCE or SPAM). I am therefore sympathetic with those of
you who are installing SPAM filters on your mail servers. A couple of recent
incidents involving mis-configured filters have prompted me to establish
this page to spell out what I will do when these filters bounce list postings.</p>
<p>When your SPAM filter bounces/rejects list mail, I will:</p>
</h1>
<p>Like all of you, I'm concerned about the increasing volume of Unsolicited
Commercial Email (UCE or SPAM). I am therefore sympathetic with those of
you who are installing SPAM filters on your mail servers. A couple of recent
incidents involving mis-configured filters have prompted me to establish this
page to spell out what I will do when these filters bounce list postings.</p>
<p>When your SPAM filter bounces/rejects list mail <b>and I can identify
who you are</b>, I will:</p>
<ol>
<li>immediately turn off delivery to you from all Shorewall lists to which
you subscribe.</li>
<li><u>try</u> to send you an email from a source other than shorewall.net</li>
<li>immediately turn off delivery to you from all Shorewall lists to
which you subscribe.</li>
<li><u>try</u> to send you an email from a source other than shorewall.net</li>
</ol>
<p>When you have corrected the problem, please let me know and I will re-enable
delivery (or you can reenable delivery yourself).</p>
<p>When you have corrected the problem, please let me know and I will re-enable
delivery (or you can reenable delivery yourself).<br>
</p>
<p>Note that many brain-dead spam filters inform the sender that a post was
rejected as spam but fail to provide any clue about the original addressee!!!
If I don't know who you are, I can't tell you about the problem...<br>
</p>
<p><font size="2">Last Updated 1/29/2003 - Tom Eastep</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
<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></p>
<br>
<br>
<br>
</body>
</html>

455
Shorewall-docs/starting_and_stopping_shorewall.htm
View File

@ -1,13 +1,13 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Starting and Stopping Shorewall</title>
@ -15,315 +15,316 @@
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber1" bgcolor="#400169" height="90">
<tbody>
<tr>
<tbody>
<tr>
<td width="100%">
<td width="100%">
<h1 align="center"><font color="#ffffff">Starting/Stopping and Monitoring
the Firewall</font></h1>
<h1 align="center"><font color="#ffffff">Starting/Stopping and Monitoring
the Firewall</font></h1>
</td>
</td>
</tr>
</tr>
</tbody>
</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>
<p><strong><u> <font color="#000099"> Important Notes:</font></u></strong><br>
</p>
<ol>
<li>Shorewall startup is disabled by default. Once you have configured
your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.
Note: Users of the .deb package must 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>
</ol>
<p>
</p>
<p> You can manually start and stop Shoreline Firewall using the "shorewall"
<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>
<p><strong><u> <font color="#000099"> Important Notes:</font></u></strong><br>
</p>
<ol>
<li>Shorewall startup is disabled by default. Once you have configured
your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.
Note: Users of the .deb package must 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>
</ol>
<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>
<li>shorewall restart - stops the firewall (if it's
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
<li>shorewall start - starts the firewall</li>
<li>shorewall stop - stops the firewall</li>
<li>shorewall restart - stops the firewall (if it's
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 and the black and white lists.</li>
</ul>
If you include the keyword <i>debug</i> as the first argument, then a
If you include the keyword <i>debug</i> as the first argument, then a
shell trace of the command is produced as in:<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>
<p>The <a href="#StateDiagram">Shorewall State Diagram</a> is shown at the
<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
bottom of this page.<br>
</p>
</p>
<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
<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 connections - displays the IP connections currently
being tracked by the firewall.</li>
<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
<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
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 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. <font
size="4" color="#ff6666"><b>The "check" command does not parse and validate
the generated iptables commands so even though the "check" command
completes successfully, the configuration may fail to start. See the
recommended way to make configuration changes described below. </b></font>
</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>
<li>shorewall deny, shorewall reject, shorewall accept and shorewall
save implement <a href="blacklisting_support.htm">dynamic blacklisting</a>.</li>
<li>shorewall logwatch (added in version 1.3.2) - Monitors the
<a href="#Conf">LOGFILE </a>and produces an audible alarm when new
<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. <font
size="4" color="#ff6666"><b>The "check" command does not parse and validate
the generated iptables commands so even though the "check" command
completes successfully, the configuration may fail to start. See the
recommended way to make configuration changes described below. </b></font>
</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>
<li>shorewall deny, shorewall reject, shorewall accept and shorewall
save implement <a href="blacklisting_support.htm">dynamic blacklisting</a>.</li>
<li>shorewall logwatch (added in version 1.3.2) - Monitors the
<a href="#Conf">LOGFILE </a>and produces an audible alarm when new
Shorewall messages are logged.</li>
</ul>
Finally, the "shorewall" program may be used to dynamically alter the
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
<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
<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>
<blockquote>Examples:<br>
<blockquote><font color="#009900"><b>shorewall add ipsec0:192.0.2.24 vpn1</b></font>
-- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1<br>
<font color="#009900"><b> shorewall delete ipsec0:192.0.2.24 vpn1</b></font>
-- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1<br>
</blockquote>
</blockquote>
<blockquote><font color="#009900"><b>shorewall add ipsec0:192.0.2.24 vpn1</b></font>
-- adds the address 192.0.2.24 from interface ipsec0 to the zone vpn1<br>
<font color="#009900"><b> shorewall delete ipsec0:192.0.2.24 vpn1</b></font>
-- deletes the address 192.0.2.24 from interface ipsec0 from zone vpn1<br>
</blockquote>
</blockquote>
<p> The <b>shorewall start</b>, <b>shorewall restart, shorewall check </b> and
<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>
href="configuration_file_basics.htm#Configs"> Shorewall configuration</a>
to use:</p>
<blockquote>
<blockquote>
<p> shorewall [ -c <i>configuration-directory</i> ] {start|restart|check}<br>
shorewall try <i>configuration-directory</i></p>
</blockquote>
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
<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>
<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>mkdir /etc/test</b></font></li>
<li><font color="#009900"><b>cd /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><font color="#009900"><b>shorewall -c . check</b></font></li>
<li>&lt;correct any errors found by check and check again&gt;</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>
<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>
<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>cp * /etc/shorewall</b></font></li>
<li><font color="#009900"><b>cd</b></font></li>
<li><font color="#009900"><b>cd</b></font></li>
<li><font color="#009900"><b>rm -rf /etc/test</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>
<div align="center"><img
src="file:///J:/Shorewall-docs/images/State_Diagram.png"
</p>
<div align="center"><img src="images/State_Diagram.png"
alt="(State Diagram)" width="747" height="714" align="middle">
<br>
</div>
<br>
</div>
<p>  <br>
</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>
<br>
</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>
<br>
<table cellpadding="2" cellspacing="2" border="1">
<tbody>
<tr>
<td valign="top">shorewall start<br>
</td>
<td valign="top">firewall start<br>
</td>
</tr>
<tr>
<td valign="top">shorewall stop<br>
</td>
<td valign="top">firewall stop<br>
</td>
</tr>
<tr>
<td valign="top">shorewall restart<br>
</td>
<td valign="top">firewall restart<br>
</td>
</tr>
<tr>
<td valign="top">shorewall add<br>
</td>
<td valign="top">firewall add<br>
</td>
</tr>
<tr>
<td valign="top">shorewall delete<br>
</td>
<td valign="top">firewall delete<br>
</td>
</tr>
<tr>
<td valign="top">shorewall refresh<br>
</td>
<td valign="top">firewall refresh<br>
</td>
</tr>
<tr>
<td valign="top">shorewall try<br>
</td>
<td valign="top">firewall -c &lt;new configuration&gt; restart<br>
If unsuccessful then firewall start (standard configuration)<br>
If timeout then firewall restart (standard configuration)<br>
</td>
</tr>
</tbody>
<tbody>
<tr>
<td valign="top">shorewall start<br>
</td>
<td valign="top">firewall start<br>
</td>
</tr>
<tr>
<td valign="top">shorewall stop<br>
</td>
<td valign="top">firewall stop<br>
</td>
</tr>
<tr>
<td valign="top">shorewall restart<br>
</td>
<td valign="top">firewall restart<br>
</td>
</tr>
<tr>
<td valign="top">shorewall add<br>
</td>
<td valign="top">firewall add<br>
</td>
</tr>
<tr>
<td valign="top">shorewall delete<br>
</td>
<td valign="top">firewall delete<br>
</td>
</tr>
<tr>
<td valign="top">shorewall refresh<br>
</td>
<td valign="top">firewall refresh<br>
</td>
</tr>
<tr>
<td valign="top">shorewall try<br>
</td>
<td valign="top">firewall -c &lt;new configuration&gt; restart<br>
If unsuccessful then firewall start (standard configuration)<br>
If timeout then firewall restart (standard configuration)<br>
</td>
</tr>
</tbody>
</table>
<br>
<p><font size="2"> Updated 1/29/2003 - <a href="support.htm">Tom Eastep</a>
<br>
<p><font size="2"> Updated 2/10/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></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></p>
<br>
<br>
<br>
<br>
<br>
<br>

569
Shorewall-docs/support.htm
View File

@ -2,128 +2,129 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Support</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Support<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
</td>
</tr>
</font></h1>
</td>
</tr>
</tbody>
</tbody>
</table>
<p> <b><big><big><font color="#ff0000">While I don't answer Shorewall  questions
emailed directly to me, I try to spend some time each day answering questions
on the Shorewall Users Mailing List.</font></big><span
<p> <b><big><big><font color="#ff0000">While I don't answer Shorewall  questions
emailed directly to me, I try to spend some time each day answering questions
on the Shorewall Users Mailing List.</font></big><span
style="font-weight: 400;"></span></big></b></p>
<h2 align="center"><big><font color="#ff0000"><b>-Tom Eastep</b></font></big></h2>
<h1>Before Reporting a Problem</h1>
<i>"Well at least you tried to read the documentation, which is a lot more
<i>"Well at least you tried to read the documentation, which is a lot more
than some people on this list appear to do.</i>"<br>
<br>
<br>
<div align="center">- Wietse Venema - On the Postfix mailing list<br>
</div>
<br>
There are a number of sources for
problem solution information. Please try these before you post.
</div>
<br>
There are a number of sources for
problem solution information. Please try these before you post.
<h3> </h3>
<h3> </h3>
<ul>
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
<li>More than half of the questions posted on the support
list have answers directly accessible from the <a
href="shorewall_quickstart_guide.htm#Documentation">Documentation Index</a><br>
<br>
</li>
<li> The <a href="FAQ.htm">FAQ</a>
<br>
</li>
<li> The <a href="FAQ.htm">FAQ</a>
has solutions to more than 20 common problems. </li>
</ul>
<h3> </h3>
<ul>
<li> The <a
href="troubleshoot.htm">Troubleshooting</a> Information contains
a number of tips to help you solve common problems. </li>
<li> The <a
href="troubleshoot.htm">Troubleshooting</a> Information contains
a number of tips to help you solve common problems. </li>
</ul>
<h3> </h3>
<ul>
<li> The <a
href="errata.htm"> Errata</a> has links to download updated
components. </li>
<li> The <a
href="errata.htm"> Errata</a> has links to download updated
components. </li>
</ul>
<h3> </h3>
<ul>
<li> The Mailing List
Archives search facility can locate posts about similar problems:
</li>
<li> The Mailing List
Archives search facility can locate posts about similar
problems: </li>
</ul>
<h2> </h2>
<h2>Mailing List Archive Search</h2>
<form method="post" action="http://lists.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<form method="post" action="http://lists.shorewall.net/cgi-bin/htsearch">
<p> <font size="-1"> Match:
<select name="method">
<option value="and">All </option>
<option value="or">Any </option>
<option value="boolean">Boolean </option>
</select>
Format:
Format:
<select name="format">
<option value="builtin-long">Long </option>
<option value="builtin-short">Short </option>
</select>
Sort by:
Sort by:
<select name="sort">
<option value="score">Score </option>
<option value="time">Time </option>
@ -132,255 +133,257 @@ Archives search facility can locate posts about similar problem
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font> <input type="hidden"
</font> <input type="hidden"
name="config" value="htdig"> <input type="hidden" name="restrict"
value="[http://lists.shorewall.net/pipermail/.*]"> <input type="hidden"
name="exclude" value=""> <br>
Search: <input type="text" size="30"
Search: <input type="text" size="30"
name="words" value=""> <input type="submit" value="Search"> </p>
</form>
</form>
<h2>Problem Reporting Guidelines </h2>
<i>"Let me see if I can translate your message into a real-world
example. It would be like saying that you have three rooms at home,
and when you walk into one of the rooms, you detect this strange smell.
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed
at the range and variety of smells we could come up with. Even more
amazing is that all of the explanations for the smells would be completely
plausible."<br>
</i><br>
<i>"Let me see if I can translate your message into a real-world
example. It would be like saying that you have three rooms at home,
and when you walk into one of the rooms, you detect this strange smell.
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed at
the range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely plausible."<br>
</i><br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
</div>
<br>
</div>
<br>
<h3> </h3>
<ul>
<li>Please remember we only know what is posted in your message.
Do not leave out any information that appears to be correct, or was mentioned
in a previous post. There have been countless posts by people who were
sure that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're 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>
<br>
</li>
<li> Please don't describe your
environment and then ask us to send you custom configuration
files. We're here to answer your questions but we can't
do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
<li>Please remember we only know what is posted in your message.
Do not leave out any information that appears to be correct, or was
mentioned in a previous post. There have been countless posts by people
who were sure that some part of their configuration was correct when
it actually contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're 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>
<br>
</li>
<li> Please don't describe
your environment and then ask us to send you custom
configuration files. We're here to answer your questions but
we can't do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
this information:</li>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall you are running.<br>
<br>
<b><font color="#009900">shorewall version</font><br>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version you are running<br>
<br>
<font color="#009900"><b>uname -a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<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>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart Guides,
please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the Mandrake
installation of Shorewall, please say so.</b><br>
<br>
</li>
</ul>
</ul>
<ul>
<ul>
<li>the exact version of Shorewall you are running.<br>
<br>
<b><font color="#009900">shorewall version</font><br>
</b> <br>
</li>
</ul>
<ul>
<li>the exact kernel version you are running<br>
<br>
<font color="#009900"><b>uname -a<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<br>
<br>
<font color="#009900"><b>ip addr show<br>
<br>
</b></font></li>
</ul>
<ul>
<li>the complete, exact output of<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>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart Guides, please
indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the Mandrake
installation of Shorewall, please say so.</b><br>
<br>
</li>
</ul>
</ul>
<ul>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, if you are having connection
problems of any kind, post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
</font></b>Since that command generates a lot of output, we
suggest that you redirect the output to a file and attach the file to
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, <b>if you are having
connection problems of any kind</b>, post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
</font></b>Since that command generates a lot of output, we
suggest that you redirect the output to a file and attach the file to
your post<br>
<br>
<b><font color="#009900">/sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
<br>
</li>
<li>As a general matter, please <strong>do not edit the diagnostic
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).<strong></strong></li>
<br>
<b><font color="#009900">/sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
<br>
</li>
<li>As a general matter, please <strong>do not edit the diagnostic
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).<strong></strong></li>
</ul>
<ul>
</ul>
<h3> </h3>
<ul>
</ul>
<h3> </h3>
<ul>
<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>
<br>
</li>
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies). </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>
<br>
</li>
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless
unless one also knows the policies). </li>
</ul>
<h3> </h3>
<ul>
</ul>
<h3> </h3>
<ul>
<li> If an error occurs
when you try to "<font color="#009900"><b>shorewall start</b></font>",
include a trace (See the <a href="troubleshoot.htm">Troubleshooting</a>
section for instructions). </li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>The list server limits posts to 120kb so don't post GIFs of
your network layout, etc. to the Mailing List -- your
post will be rejected.</b></h3>
</li>
</ul>
The author gratefully acknowleges that the above list was heavily
plagiarized from the excellent LEAF document by <i>Ray</i> <em>Olszewski</em>
<h3> </h3>
<ul>
<li> If an error occurs
when you try to "<font color="#009900"><b>shorewall start</b></font>",
include a trace (See the <a href="troubleshoot.htm">Troubleshooting</a>
section for instructions). </li>
</ul>
<h3> </h3>
<ul>
<li>
<h3><b>The list server limits posts to 120kb so don't post GIFs of
your network layout, etc. to the Mailing List -- your
post will be rejected.</b></h3>
</li>
</ul>
The author gratefully acknowleges that the above list was heavily
plagiarized from the excellent LEAF document by <i>Ray</i> <em>Olszewski</em>
found at <a
href="http://leaf-project.org/pub/doc/docmanager/docid_1891.html">http://leaf-project.org/pub/doc/docmanager/docid_1891.html</a>.<br>
<h2>Please post in plain text</h2>
<blockquote> </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>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users
mailing list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi Network Firewall
(MNF) and you have not purchased an MNF license from MandrakeSoft then
you can post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a> <b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a></p>
</blockquote>
<p>To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.</p>
<p align="left"><font size="2">Last Updated 2/4/2003 - Tom Eastep</font></p>
<blockquote> </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>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
<blockquote>
<h4>If you run Shorewall under Bering -- <span
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users
mailing list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi Network Firewall
(MNF) and you have not purchased an MNF license from MandrakeSoft then
you can post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a> <b>Do not expect to get free MNF support on the list.</b><br>
<p>Otherwise, please post your question or problem to the <a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a></p>
</blockquote>
<p>To Subscribe to the mailing list go to <a
href="http://lists.shorewall.net/mailman/listinfo/shorewall-users">http://lists.shorewall.net/mailman/listinfo/shorewall-users</a>
.</p>
<p align="left"><font size="2">Last Updated 2/9/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>
<br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
</body>

587
Shorewall-docs/traffic_shaping.htm
View File

@ -1,324 +1,333 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Traffic Shaping</title>
</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%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Traffic Shaping/Control</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p align="left">Beginning with version 1.2.0, Shorewall has limited support
for traffic shaping/control. In order to use traffic shaping under Shorewall,
it is essential that you get a copy of the <a
href="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping HOWTO</a>,
version 0.3.0 or later. You must also install the iproute (iproute2) package
to provide the "ip" and "tc" utilities.</p>
<p align="left">Beginning with version 1.2.0, Shorewall has limited support
for traffic shaping/control. In order to use traffic shaping under
Shorewall, it is essential that you get a copy of the <a
href="http://ds9a.nl/lartc">Linux Advanced Routing and Shaping HOWTO</a>,
version 0.3.0 or later. You must also install the iproute (iproute2)
package to provide the "ip" and "tc" utilities.</p>
<p align="left">Shorewall traffic shaping support consists of the following:</p>
<ul>
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in Shorewall
1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the setting of
this variable determines whether Shorewall clears the traffic shaping configuration
during Shorewall [re]start and Shorewall stop. <br>
</li>
<li><b>/etc/shorewall/tcrules</b> - A file where you can specify
firewall marking of packets. The firewall mark value may be used to
classify packets for traffic shaping/control.<br>
</li>
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you can
use to define your traffic shaping disciplines and classes. I have
provided a <a href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a>
that does table-driven CBQ shaping but if you read the traffic shaping
sections of the HOWTO mentioned above, you can probably code your
own faster than you can learn how to use my sample. I personally use
<a href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall since
HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
the firewall.<br>
<br>
You can generally use off-the-shelf traffic shaping scripts by simply
copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If you
use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file that
is sourced by Shorewall when it is clearing traffic shaping. This
file is normally not required as Shorewall's method of clearing qdisc
and filter definitions is pretty general.</li>
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in
Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the
setting of this variable determines whether Shorewall clears the traffic
shaping configuration during Shorewall [re]start and Shorewall stop. <br>
</li>
<li><b>/etc/shorewall/tcrules</b> - A file where you can specify
firewall marking of packets. The firewall mark value may be used
to classify packets for traffic shaping/control.<br>
</li>
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you
can use to define your traffic shaping disciplines and classes.
I have provided a <a
href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a> that does
table-driven CBQ shaping but if you read the traffic shaping sections
of the HOWTO mentioned above, you can probably code your own faster
than you can learn how to use my sample. I personally use <a
href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of
2.4.20, HTB is a standard part of the kernel but iproute2 must be patched
in order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
the firewall.<br>
<br>
You can generally use off-the-shelf traffic shaping scripts by simply
copying them to /etc/shorewall/tcstart. I use <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (HTB version)
that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart and
modified it according to the Wonder Shaper README). <b>WARNING: </b>If you
use use Masquerading or SNAT (i.e., you only have one external IP address)
then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
script won't work. Traffic shaping occurs after SNAT has already been applied
so when traffic shaping happens, all outbound traffic will have as a source
address the IP addresss of your firewall's external interface.<br>
</li>
<li><b>/etc/shorewall/tcclear</b> - A user-supplied file that
is sourced by Shorewall when it is clearing traffic shaping. This
file is normally not required as Shorewall's method of clearing
qdisc and filter definitions is pretty general.</li>
</ul>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
Shorewall allows you to start traffic shaping when Shorewall itself starts
or it allows you to bring up traffic shaping when you bring up your interfaces.<br>
<br>
To start traffic shaping when Shorewall starts:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic shaping
rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark packets
using entries in /etc/shorewall/tcrules.</li>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic
shaping rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark
packets using entries in /etc/shorewall/tcrules.</li>
</ol>
To start traffic shaping when you bring up your network interfaces, you will
have to arrange for your traffic shaping configuration script to be run at
that time. How you do that is distribution dependent and will not be covered
here. You then should:<br>
To start traffic shaping when you bring up your network interfaces, you
will have to arrange for your traffic shaping configuration script to be
run at that time. How you do that is distribution dependent and will not
be covered here. You then should:<br>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier, you
can mark packets using entries in /etc/shorewall/tcrules.</li>
<li>Set TC_ENABLED=Yes and CLEAR_TC=No</li>
<li>Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear scripts.</li>
<li value="4">If your tcstart script uses the 'fwmark' classifier, you
can mark packets using entries in /etc/shorewall/tcrules.</li>
</ol>
<h3 align="left">Kernel Configuration</h3>
<p align="left">This screen shot show how I've configured QoS in my Kernel:</p>
<p align="center"><img border="0" src="images/QoS.png" width="590"
height="764">
</p>
</p>
<h3 align="left"><a name="tcrules"></a>/etc/shorewall/tcrules</h3>
<p align="left">The fwmark classifier provides a convenient way to classify
packets for traffic shaping. The /etc/shorewall/tcrules file provides
a means for specifying these marks in a tabular fashion.<br>
</p>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255.<br>
<br>
Example - 5<br>
</li>
<li>SOURCE - The source of the packet. If the packet originates
on the firewall, place "fw" in this column. Otherwise, this is a
comma-separated list of interface names, IP addresses, MAC addresses in
<a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
    eth0<br>
    192.168.2.4,192.168.1.0/24<br>
</li>
<li>DEST -- Destination of the packet. Comma-separated list of
IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list of Port
names (from /etc/services), port numbers or port ranges (e.g., 21:22);
if the protocol is "icmp", this column is interpreted as the
destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client. If
omitted, any source port is acceptable. Specified as a comma-separate
list of port names, port numbers or port ranges.</li>
</ul>
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with 2.
All packets originating on the firewall itself should be marked with 3.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>1</td>
<td>eth1</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>2</td>
<td>eth2</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td valign="top">2<br>
</td>
<td valign="top">eth3<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">all<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td>3</td>
<td>fw</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p align="left">Example 2 - All GRE (protocol 47) packets not originating
on the firewall and destined for 155.186.235.151 should be marked with
12.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>12</td>
<td>0.0.0.0/0</td>
<td>155.186.235.151</td>
<td>47</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p align="left">Example 3 - All SSH packets originating in 192.168.1.0/24
and destined for 155.186.235.151 should be marked with 22.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>22</td>
<td>192.168.1.0/24</td>
<td>155.186.235.151</td>
<td>tcp</td>
<td>22</td>
<td> </td>
</tr>
</tbody>
</table>
<h3>My Setup<br>
</h3>
<p>While I am currently using the HTB version of <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (I just copied
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown in
the Wondershaper README), I have also run with the following set of hand-crafted
rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<blockquote>
<pre>run_tc qdisc add dev eth0 root handle 1: htb default 30<br><br>run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k<br><br>echo "   Added Top Level Class -- rate 384kbit"</pre>
<pre>run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1<br>run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0<br>run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1</pre>
<pre>echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"</pre>
<pre>run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5<br>run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10<br>run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5</pre>
<pre>echo "   Enabled PFIFO on Second Level Classes"</pre>
<pre>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30</pre>
<pre>echo "   Defined fwmark filters"<br></pre>
</blockquote>
<p>My tcrules file that went with this tcstart file is shown in Example 1
above. You can look at my <a href="myfiles.htm">network configuration</a>
to get an idea of why I wanted these particular rules.<br>
<p align="left">The fwmark classifier provides a convenient way to classify
packets for traffic shaping. The /etc/shorewall/tcrules file provides
a means for specifying these marks in a tabular fashion.<br>
</p>
<p align="left">Normally, packet marking occurs in the PREROUTING chain before
any address rewriting takes place. This makes it impossible to mark inbound
packets based on their destination address when SNAT or Masquerading are
being used. Beginning with Shorewall 1.3.12, you can cause packet marking
to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
</p>
<p align="left">Columns in the file are as follows:</p>
<ul>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255. Beginning with
Shorewall version 1.3.14, this value may be optionally followed by ":" and
either 'F' or 'P' to designate that the marking will occur in the FORWARD
or PREROUTING chains respectively. If this additional specification is omitted,
the chain used to mark packets will be determined by the setting of the
MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<br>
Example - 5<br>
</li>
<li>SOURCE - The source of the packet. If the packet originates
on the firewall, place "fw" in this column. Otherwise, this is a
comma-separated list of interface names, IP addresses, MAC addresses
in <a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
    eth0<br>
    192.168.2.4,192.168.1.0/24<br>
</li>
<li>DEST -- Destination of the packet. Comma-separated list
of IP addresses and/or subnets.<br>
</li>
<li>PROTO - Protocol - Must be the name of a protocol from
/etc/protocol, a number or "all"<br>
</li>
<li>PORT(S) - Destination Ports. A comma-separated list of
Port names (from /etc/services), port numbers or port ranges (e.g.,
21:22); if the protocol is "icmp", this column is interpreted as
the destination icmp type(s).<br>
</li>
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client.
If omitted, any source port is acceptable. Specified as a comma-separate
list of port names, port numbers or port ranges.</li>
</ul>
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with
2. All packets originating on the firewall itself should be marked with
3.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>1</td>
<td>eth1</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>2</td>
<td>eth2</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td valign="top">2<br>
</td>
<td valign="top">eth3<br>
</td>
<td valign="top">0.0.0.0/0<br>
</td>
<td valign="top">all<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td>3</td>
<td>fw</td>
<td>0.0.0.0/0</td>
<td>all</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p align="left">Example 2 - All GRE (protocol 47) packets not originating
on the firewall and destined for 155.186.235.151 should be marked with
12.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>12</td>
<td>0.0.0.0/0</td>
<td>155.186.235.151</td>
<td>47</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
<p align="left">Example 3 - All SSH packets originating in 192.168.1.0/24
and destined for 155.186.235.151 should be marked with 22.</p>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>MARK</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>PROTO</b></td>
<td><b>PORT(S)</b></td>
<td><b>CLIENT PORT(S)</b></td>
</tr>
<tr>
<td>22</td>
<td>192.168.1.0/24</td>
<td>155.186.235.151</td>
<td>tcp</td>
<td>22</td>
<td> </td>
</tr>
</tbody>
</table>
<h3>My Setup<br>
</h3>
<p>While I am currently using the HTB version of <a
href="http://lartc.org/wondershaper/">The Wonder Shaper</a> (I just copied
wshaper.htb to <b>/etc/shorewall/tcstart</b> and modified it as shown in
the Wondershaper README), I have also run with the following set of hand-crafted
rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</p>
<blockquote>
<pre>run_tc qdisc add dev eth0 root handle 1: htb default 30<br><br>run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k<br><br>echo "   Added Top Level Class -- rate 384kbit"</pre>
<pre>run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1<br>run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0<br>run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit  ceil 384kbit burst 15k quantum 1500 prio 1</pre>
<pre>echo "   Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"</pre>
<pre>run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5<br>run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10<br>run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5</pre>
<pre>echo "   Enabled PFIFO on Second Level Classes"</pre>
<pre>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20<br>run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30</pre>
<pre>echo "   Defined fwmark filters"<br></pre>
</blockquote>
<p>My tcrules file that went with this tcstart file is shown in Example 1
above.<br>
</p>
<ol>
<li>I wanted to allow up to 140kbits/second for traffic outbound from
my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic
can use all available bandwidth if there is no traffic from the local systems
or from my laptop or firewall).</li>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.<br>
</li>
<li>I wanted to allow up to 140kbits/second for traffic outbound
from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ traffic
can use all available bandwidth if there is no traffic from the local systems
or from my laptop or firewall).</li>
<li>My laptop and local systems could use up to 224kbits/second.</li>
<li>My firewall could use up to 20kbits/second.<br>
</li>
</ol>
<p><font size="2">Last Updated 12/31/2002 - <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 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<p><font size="2">Last Updated 2/18/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>
</body>
</html>

371
Shorewall-docs/troubleshoot.htm
View File

@ -1,237 +1,232 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Troubleshooting</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</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%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Troubleshooting<img
src="images/obrasinf.gif" alt="Beating head on table" width="90"
height="90" align="middle">
</font></h1>
</td>
</tr>
</tbody>
</font></h1>
</td>
</tr>
</tbody>
</table>
<h3 align="left">Check the Errata</h3>
<p align="left">Check the <a href="errata.htm">Shorewall Errata</a> to be
sure that there isn't an update that you are missing for your version
of the firewall.</p>
<p align="left">Check the <a href="errata.htm">Shorewall Errata</a> to be
sure that there isn't an update that you are missing for your version
of the firewall.</p>
<h3 align="left">Check the FAQs</h3>
<p align="left">Check the <a href="FAQ.htm">FAQs</a> for solutions to common
problems.</p>
<p align="left">Check the <a href="FAQ.htm">FAQs</a> for solutions to common
problems.</p>
<h3 align="left">If the firewall fails to start</h3>
If you receive an error message when starting or restarting
the firewall and you can't determine the cause, then do the following:
If you receive an error message when starting or restarting
the firewall and you can't determine the cause, then do the following:
<ul>
<li>Make a note of the error message that you see.<br>
</li>
<li>shorewall debug start 2&gt; /tmp/trace</li>
<li>Look at the /tmp/trace file and see if that helps you
determine what the problem is. Be sure you find the place in the log
where the error message you saw is generated -- in 99.9% of the cases, it
will not be near the end of the log because after startup errors, Shorewall
<li>Make a note of the error message that you see.<br>
</li>
<li>shorewall debug start 2&gt; /tmp/trace</li>
<li>Look at the /tmp/trace file and see if that helps you
determine what the problem is. Be sure you find the place in the log
where the error message you saw is generated -- in 99.9% of the cases, it
will not be near the end of the log because after startup errors, Shorewall
goes through a "shorewall stop" phase which will also be traced.</li>
<li>If you still can't determine what's wrong then see the
<a href="support.htm">support page</a>.</li>
<li>If you still can't determine what's wrong then see the
<a href="support.htm">support page</a>.</li>
</ul>
Here's an example. During startup, a user sees the following:<br>
<blockquote>
<pre>Adding Common Rules<br>iptables: No chain/target/match by that name<br>Terminated<br></pre>
</blockquote>
A search through the trace for "No chain/target/match by that name" turned
up the following: 
<blockquote>
<pre>+ echo 'Adding Common Rules'<br>+ add_common_rules<br>+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ sed 's/!/! /g'<br>+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>iptables: No chain/target/match by that name<br></pre>
</blockquote>
The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with
tcp-reset". In this case, the user had compiled his own kernel and had forgotten
to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
<h3>Your network environment</h3>
<p>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular snafus:
</p>
<ul>
<li>Port Forwarding where client and server are in
the same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe that the system
is in the 'net' zone.</li>
<li>Multiple interfaces connected to the same HUB or Switch.
Given the way that the Linux kernel respond to ARP "who-has" requests,
this type of setup does NOT work the way that you expect it to.</li>
</ul>
<h3 align="left">If you are having connection problems:</h3>
<p align="left">If the appropriate policy for the connection that you are
trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
TO MAKE IT WORK. Such additional rules will NEVER make it work, they
add clutter to your rule set and they represent a big security hole in
the event that you forget to remove them later.</p>
<p align="left">I also recommend against setting all of your policies to
ACCEPT in an effort to make something work. That robs you of one of
your best diagnostic tools - the "Shorewall" messages that Netfilter
will generate when you try to connect in a way that isn't permitted
by your rule set.</p>
<p align="left">Check your log ("/sbin/shorewall show log"). If you don't
see Shorewall messages, then your problem is probably NOT a Shorewall
problem. If you DO see packet messages, it may be an indication that you
are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<p align="left">While you are troubleshooting, it is a good idea to clear
two variables in /etc/shorewall/shorewall.conf:</p>
<p align="left">LOGRATE=""<br>
LOGBURST=""</p>
<p align="left">This way, you will see all of the log messages being
generated (be sure to restart shorewall after clearing these variables).</p>
<p align="left">Example:</p>
<font face="Century Gothic, Arial, Helvetica">
Here's an example. During startup, a user sees the following:<br>
<p align="left"><font face="Courier">Jun 27 15:37:56 gateway kernel:
Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3
LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53
LEN=47</font></p>
</font>
<p align="left">Let's look at the important parts of this message:</p>
<ul>
<li>all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the "all"-&gt;"all" REJECT
policy (see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
<li>IN=eth2 - the packet entered the firewall via eth2</li>
<li>OUT=eth1 - if accepted, the packet would be sent on eth1</li>
<li>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</li>
<li>DST=192.168.1.3 - the packet is destined for 192.168.1.3</li>
<li>PROTO=UDP - UDP Protocol</li>
<li>DPT=53 - DNS</li>
<blockquote>
<pre>Adding Common Rules<br>iptables: No chain/target/match by that name<br>Terminated<br></pre>
</blockquote>
A search through the trace for "No chain/target/match by that name" turned
up the following: 
<blockquote>
<pre>+ echo 'Adding Common Rules'<br>+ add_common_rules<br>+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ sed 's/!/! /g'<br>+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>iptables: No chain/target/match by that name<br></pre>
</blockquote>
The command that failed was: "iptables -A reject -p tcp -j REJECT --reject-with
tcp-reset". In this case, the user had compiled his own kernel and had forgotten
to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
<h3>Your network environment</h3>
<p>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular snafus:
</p>
<ul>
<li>Port Forwarding where client and server are in
the same subnet. See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe that the system
is in the 'net' zone.</li>
<li>Multiple interfaces connected to the same HUB or Switch.
Given the way that the Linux kernel respond to ARP "who-has" requests,
this type of setup does NOT work the way that you expect it to.</li>
</ul>
<p align="left">In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3
is in the "loc" zone. I was missing the rule:</p>
<h3 align="left">If you are having connection problems:</h3>
<p align="left">If the appropriate policy for the connection that you are
trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING
TO MAKE IT WORK. Such additional rules will NEVER make it work, they add
clutter to your rule set and they represent a big security hole in the
event that you forget to remove them later.</p>
<p align="left">I also recommend against setting all of your policies to
ACCEPT in an effort to make something work. That robs you of one of
your best diagnostic tools - the "Shorewall" messages that Netfilter
will generate when you try to connect in a way that isn't permitted
by your rule set.</p>
<p align="left">Check your log ("/sbin/shorewall show log"). If you don't
see Shorewall messages, then your problem is probably NOT a Shorewall
problem. If you DO see packet messages, it may be an indication that you
are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<p align="left">While you are troubleshooting, it is a good idea to clear
two variables in /etc/shorewall/shorewall.conf:</p>
<p align="left">LOGRATE=""<br>
LOGBURST=""</p>
<p align="left">This way, you will see all of the log messages being
generated (be sure to restart shorewall after clearing these variables).</p>
<p align="left">Example:</p>
<font face="Century Gothic, Arial, Helvetica">
<p align="left"><font face="Courier">Jun 27 15:37:56 gateway kernel:
Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3
LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53
LEN=47</font></p>
</font>
<p align="left">Let's look at the important parts of this message:</p>
<ul>
<li>all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the "all"-&gt;"all" REJECT policy
(see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
<li>IN=eth2 - the packet entered the firewall via eth2</li>
<li>OUT=eth1 - if accepted, the packet would be sent on eth1</li>
<li>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</li>
<li>DST=192.168.1.3 - the packet is destined for 192.168.1.3</li>
<li>PROTO=UDP - UDP Protocol</li>
<li>DPT=53 - DNS</li>
</ul>
<p align="left">In this case, 192.168.2.2 was in the "dmz" zone and 192.168.1.3
is in the "loc" zone. I was missing the rule:</p>
<p align="left">ACCEPT    dmz    loc    udp    53<br>
</p>
<p align="left">See <a href="FAQ.htm#faq17">FAQ 17</a> for additional information
</p>
<p align="left">See <a href="FAQ.htm#faq17">FAQ 17</a> for additional information
about how to interpret the chain name appearing in a Shorewall log message.<br>
</p>
</p>
<h3 align="left">'Ping' Problems?</h3>
Either can't ping when you think you should be able to or are able to ping
Either can't ping when you think you should be able to or are able to ping
when you think that you shouldn't be allowed? Shorewall's 'Ping' Management<a
href="ping.html"> is described here</a>.<br>
<h3 align="left">Other Gotchas</h3>
<ul>
<li>Seeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that:
<li>Seeing rejected/dropped packets logged out of the INPUT
or FORWARD chains? This means that:
<ol>
<li>your zone definitions are screwed up and the host that
is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
<li>your zone definitions are screwed up and the host that
is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
file are you?); or</li>
<li>the source and destination hosts are both connected to
the same interface and that interface doesn't have the 'multi'
option specified in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>the source and destination hosts are both connected to
the same interface and you don't have a policy or rule for the
source zone to or from the destination zone.</li>
</ol>
</li>
<li>Remember that Shorewall doesn't automatically allow ICMP
type 8 ("ping") requests to be sent between zones. If you want pings
</li>
<li>Remember that Shorewall doesn't automatically allow ICMP
type 8 ("ping") requests to be sent between zones. If you want pings
to be allowed between zones, you need a rule of the form:<br>
<br>
    ACCEPT    &lt;source zone&gt;    &lt;destination zone&gt;   
<br>
    ACCEPT    &lt;source zone&gt;    &lt;destination zone&gt;   
icmp    echo-request<br>
<br>
The ramifications of this can be subtle. For example, if you
have the following in /etc/shorewall/nat:<br>
<br>
    10.1.1.2    eth0    130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type
8 between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped. This is
true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.</li>
<li>If you specify "routefilter" for an interface, that interface
must be up prior to starting the firewall.</li>
<li>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect
of routing is that in order for two hosts to communicate, the routing
between them must be set up <u>in both directions.</u> So when setting
up routing between <b>A</b> and<b> B</b>, be sure to verify that the
<br>
The ramifications of this can be subtle. For example, if you
have the following in /etc/shorewall/nat:<br>
<br>
    10.1.1.2    eth0    130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type
8 between the zone containing the system you are pinging from and
the zone containing 10.1.1.2, the ping requests will be dropped. </li>
<li>If you specify "routefilter" for an interface, that
interface must be up prior to starting the firewall.</li>
<li>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect of
routing is that in order for two hosts to communicate, the routing
between them must be set up <u>in both directions.</u> So when setting
up routing between <b>A</b> and<b> B</b>, be sure to verify that the
route from <b>B</b> back to <b>A</b> is defined.</li>
<li>Some versions of LRP (EigerStein2Beta for example) have a
shell with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected
shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a
<li>Some versions of LRP (EigerStein2Beta for example) have
a shell with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected
shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a
href="kernel.htm">Click here to see my kernel configuration.</a> </li>
<li>Some features require the "ip" program. That program
is generally included in the "iproute" package which should be included
with your distribution (though many distributions don't install iproute
by default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
<li>Some features require the "ip" program. That program
is generally included in the "iproute" package which should be included
with your distribution (though many distributions don't install iproute
by default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
.</li>
<li>If you have <u>any</u> entry for a zone in /etc/shorewall/hosts
then the zone must be entirely defined in /etc/shorewall/hosts unless
you have specified MERGE_HOSTS=Yes (Shorewall version 1.3.5 and later).
For example, if a zone has two interfaces but only one interface has an
entry in /etc/shorewall/hosts then hosts attached to the other interface
will <u>not</u> be considered part of the zone.</li>
<li>Problems with NAT? Be sure that you let Shorewall add all
external addresses to be use with NAT unless you have set <a
<li>Problems with NAT? Be sure that you let Shorewall
add all external addresses to be use with NAT unless you have set <a
href="Documentation.htm#Aliases"> ADD_IP_ALIASES</a> =No in /etc/shorewall/shorewall.conf.</li>
</ul>
<h3>Still Having Problems?</h3>
<p>See the<a href="support.htm"> support page.<br>
</a></p>
<font face="Century Gothic, Arial, Helvetica">
</a></p>
<font face="Century Gothic, Arial, Helvetica">
<blockquote> </blockquote>
</font>
<p><font size="2">Last updated 1/7/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
</font>
<p><font size="2">Last updated 2/18/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
</body>
</html>

1691
Shorewall-docs/two-interface.htm
View File

File diff suppressed because it is too large Load Diff

447
Shorewall-docs/upgrade_issues.htm
View File

@ -1,233 +1,294 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Upgrade Issues</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta name="Microsoft Theme" content="none">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Upgrade Issues</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<p>For upgrade instructions see the <a
href="Install.htm">Install/Upgrade page</a>.</p>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13" 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>
<h3> </h3>
<h3>Version &gt;= 1.4.0</h3>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options are no
longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf. ICMP
echo-request (ping) packets are treated just like any other connection request
and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in /etc/shorewall/interfaces
now generate a Shorewall error at startup (they always have produced warnings
in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall
1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are
determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts file has
been eliminated; use entries in the routestopped file instead.</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>
<li value="6">Late-arriving DNS replies are not dropped by default; there
is no need for your own /etc/shorewall/common file simply to avoid logging
these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have been
moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include it from
/etc/shorewall/icmpdef, you will need to modify that file.</li>
<li value="8">The 'multi' interface option is no longer supported.  Shorewall
will generate rules for sending packets back out the same interface that they
arrived on in two cases:</li>
</ul>
<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>
<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>
</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>
</ul>
</ul>
You will need to make a change to your configuration if:<br>
<ol>
<li>You have one or more entries in /etc/shorewall/masq with an interface
name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<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>
<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>
<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>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13" 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 the new handling as soon as possible.
See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to version
1.3.10, you will need to use the '--force' option:<br>
<br>
<ul>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
</ul>
<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>
<h3>Version &gt;= 1.3.14</h3>
<img src="images/BD21298_3.gif" alt="" width="13" 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>
<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>
</ul>
You will need to make a change to your configuration if:<br>
<h3>Version &gt;= 1.3.8</h3>
<p>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 &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following rules
in their /etc/shorewall/icmpdef file (creating
this file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to
Shorewall &gt;= 1.3.3</b></h3>
<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>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>
<li>You have one or more entries in /etc/shorewall/masq with an interface
name in the SUBNET (second) column; and</li>
<li>That interface connects to more than one subnetwork.</li>
</ol>
Two examples:<br>
<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>
<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>
<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>
<blockquote>In this case, you would want to change the entry in /etc/shorewall/masq
to:<br>
</blockquote>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<img src="images/BD21298_3.gif" alt="" width="13" 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 the new handling as soon as possible.
See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
<h3>Version 1.3.10</h3>
If you have installed the 1.3.10 Beta 1 RPM and are now upgrading to
version 1.3.10, you will need to use the '--force' option:<br>
<br>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
</blockquote>
<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>
<h3>Version &gt;= 1.3.8</h3>
<p>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 &gt;= 1.3.8. Beginning with version 1.3.8,
you must set NEWNOTSYN=Yes in your
/etc/shorewall/shorewall.conf file.</p>
<h3>Version &gt;= 1.3.7</h3>
<p>Users specifying ALLOWRELATED=No in /etc/shorewall.conf
will need to include the following rules
in their /etc/shorewall/icmpdef file (creating
this file if necessary):</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT</pre>
<p>Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
command from that file since the icmp.def file is now empty.</p>
<h3><b><a name="Bering">Upgrading </a>Bering to
Shorewall &gt;= 1.3.3</b></h3>
<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>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>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need to add
the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<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>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn -j RETURN
# So that the connection tracking table can be rebuilt<br>
                                    # from non-SYN packets
after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common -p tcp --tcp-flags
ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<p>The .lrp that I release isn't set up for a two-interface firewall like
Jacques's. You need to follow the <a href="two-interface.htm">instructions
for setting up a two-interface firewall</a> plus you also need to add
the following two Bering-specific rules to /etc/shorewall/rules:</p>
<blockquote>
<pre># Bering specific rules:<br># allow loc to fw udp/53 for dnscache to work<br># allow loc to fw tcp/80 for weblet to work<br>#<br>ACCEPT loc fw udp 53<br>ACCEPT loc fw tcp 80</pre>
</blockquote>
<h3 align="left">Version 1.3.6 and 1.3.7</h3>
<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>
<ol>
<li>
<p align="left">Create the file /etc/shorewall/newnotsyn and in it add
the following rule<br>
<br>
<font face="Courier">run_iptables -A newnotsyn -j RETURN
# So that the connection tracking table can be rebuilt<br>
                                    # from non-SYN packets
after takeover.<br>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
<font face="Courier">run_iptables -A common -p tcp --tcp-flags
ACK,FIN,RST ACK -j ACCEPT #Accept Acks to rebuild connection<br>
                                                                   
#tracking table. <br>
. /etc/shorewall/common.def</font> </p>
</li>
</ol>
<h3 align="left">Versions &gt;= 1.3.5</h3>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no
longer supported. </p>
<p align="left">Some forms of pre-1.3.0 rules file syntax are no
longer supported. </p>
<p align="left">Example 1:</p>
<div align="left">
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</div>
</div>
<h3 align="left">Version &gt;= 1.3.2</h3>
<p align="left">The functions and versions files together with the
'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 1/25/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>
<p align="left">The functions and versions files together with the
'firewall' symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 2/14/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>
<br>
<br>
<br>
</body>

547
Shorewall-docs/whitelisting_under_shorewall.htm
View File

@ -1,281 +1,326 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Whitelisting under Shorewall</title>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Whitelisting under Shorewall</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="100%" id="AutoNumber1" bgcolor="#400169" height="90">
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">Whitelisting under Shorewall</font></h1>
</td>
</tr>
<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">Whitelisting under Shorewall</font></h1>
</td>
</tr>
</tbody>
</table>
<p align="left">For a brief time, the 1.2 version of Shorewall supported an
/etc/shorewall/whitelist file. This file was intended to contain a list of IP
addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist file was
implemented as a stop-gap measure until the facilities necessary for
implementing white lists using zones was in place. As of Version 1.3 RC1, those
facilities were available.</p>
<p align="left">White lists are most often used to give special privileges to a
set&nbsp; of hosts within an organization. Let us suppose that we have the
following environment:</p>
<p align="left">For a brief time, the 1.2 version of Shorewall supported an
/etc/shorewall/whitelist file. This file was intended to contain a list of
IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist
file was implemented as a stop-gap measure until the facilities necessary
for implementing white lists using zones was in place. As of Version 1.3
RC1, those facilities were available.</p>
<p align="left">White lists are most often used to give special privileges
to a set  of hosts within an organization. Let us suppose that we have the
following environment:</p>
<ul>
<li>A firewall with three interfaces -- one to the internet, one
to a local network and one to a DMZ.</li>
<li>The local network uses SNAT to the internet and is comprised
of the class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918
local network, the technique described here in no way depends on that or on
SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).</li>
<li>The network operations staff have workstations with IP
addresses in the class C network 10.10.10.0/24</li>
<li>We want the network operations staff to have full access to
all other hosts.</li>
<li>We want the network operations staff to bypass the transparent
HTTP proxy running on our firewall.</li>
<li>A firewall with three interfaces -- one to the internet, one to
a local network and one to a DMZ.</li>
<li>The local network uses SNAT to the internet and is comprised of
the class B network 10.10.0.0/16 (Note: While this example uses an RFC 1918
local network, the technique described here in no way depends on that or
on SNAT. It may be used with Proxy ARP, Subnet Routing, Static NAT, etc.).</li>
<li>The network operations staff have workstations with IP addresses
in the class C network 10.10.10.0/24</li>
<li>We want the network operations staff to have full access to all
other hosts.</li>
<li>We want the network operations staff to bypass the transparent
HTTP proxy running on our firewall.</li>
</ul>
<p align="left">The basic approach will be that we will place the operations
staff's class C in its own zone called <b>ops</b>. Here are the appropriate
configuration files:</p>
staff's class C in its own zone called <b>ops</b>. Here are the appropriate
configuration files:</p>
<h2 align="left">Zone File</h2>
<blockquote>
<blockquote>
<table border="2">
<tr>
<td><b>
ZONE</b></td>
<td><b>
DISPLAY</b></td>
<td><b>
COMMENTS</b></td>
</tr>
<tbody>
<tr>
<td>net</td>
<td>Net</td>
<td>Internet</td>
</tr>
<tr>
<td>ops</td>
<td>Operations</td>
<td>Operations Staff's Class C</td>
</tr>
<tr>
<td>loc</td>
<td>Local</td>
<td>Local Class B</td>
</tr>
<tr>
<td>dmz</td>
<td>DMZ</td>
<td>Demilitarized zone</td>
</tr>
</table>
</blockquote>
<p>The <b>ops </b>zone has been added to the standard 3-zone zones file -- since
<b>ops</b> is a sub-zone of <b>loc</b>, we list it <u>BEFORE</u> <b>loc</b>.</p>
<td><b> ZONE</b></td>
<td><b> DISPLAY</b></td>
<td><b> COMMENTS</b></td>
</tr>
<tr>
<td>net</td>
<td>Net</td>
<td>Internet</td>
</tr>
<tr>
<td>ops</td>
<td>Operations</td>
<td>Operations Staff's Class C</td>
</tr>
<tr>
<td>loc</td>
<td>Local</td>
<td>Local Class B</td>
</tr>
<tr>
<td>dmz</td>
<td>DMZ</td>
<td>Demilitarized zone</td>
</tr>
</tbody>
</table>
</blockquote>
<p>The <b>ops </b>zone has been added to the standard 3-zone zones file --
since <b>ops</b> is a sub-zone of <b>loc</b>, we list it <u>BEFORE</u> <b>loc</b>.</p>
<h2>Interfaces File</h2>
<blockquote>
<blockquote>
<table border="2">
<tr>
<td><b>
ZONE</b></td>
<td><b>
INTERFACE</b></td>
<td><b>
BROADCAST</b></td>
<td><b>
OPTIONS</b></td>
</tr>
<tbody>
<tr>
<td>net</td>
<td>eth0</td>
<td>&lt;whatever&gt;</td>
<td>&lt;options&gt;</td>
</tr>
<tr>
<td>dmz</td>
<td>eth1</td>
<td>&lt;whatever&gt;</td>
<td>routestopped</td>
</tr>
<tr>
<td>-</td>
<td>eth2</td>
<td>10.10.255.255</td>
<td>&nbsp;</td>
</tr>
</table>
</blockquote>
<p>Because <b>eth2</b> interfaces to two zones (<b>ops</b> and <b>loc)</b>, we
don't specify a zone for it here.</p>
<td><b> ZONE</b></td>
<td><b> INTERFACE</b></td>
<td><b> BROADCAST</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>net</td>
<td>eth0</td>
<td>&lt;whatever&gt;</td>
<td>&lt;options&gt;</td>
</tr>
<tr>
<td>dmz</td>
<td>eth1</td>
<td>&lt;whatever&gt;</td>
<td><br>
</td>
</tr>
<tr>
<td>-</td>
<td>eth2</td>
<td>10.10.255.255</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>Because <b>eth2</b> interfaces to two zones (<b>ops</b> and <b>loc)</b>,
we don't specify a zone for it here.</p>
<h2>Hosts File</h2>
<blockquote>
<blockquote> <font face="Century Gothic, Arial, Helvetica">
</font>
<table border="2">
<tr>
<td><b>
ZONE</b></td>
<td><b>
HOST(S)</b></td>
<td><b>
OPTIONS</b></td>
</tr>
<tbody>
<tr>
<td>ops</td>
<td>eth2:10.10.10.0/24</td>
<font face="Century Gothic, Arial, Helvetica">
<td>routestopped</td>
</font>
</tr>
<tr>
<td>loc</td>
<td>eth2:0.0.0.0/0</td>
<td>&nbsp;</td>
</tr>
</table>
</blockquote>
<td><b> ZONE</b></td>
<td><b> HOST(S)</b></td>
<td><b> OPTIONS</b></td>
</tr>
<tr>
<td>ops</td>
<td>eth2:10.10.10.0/24</td>
<td><br>
</td>
</tr>
<tr>
<td>loc</td>
<td>eth2:0.0.0.0/0</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>Here we define the <b>ops</b> and <b>loc</b> zones. When Shorewall is
stopped, only the hosts in the <b>ops</b> zone will be allowed to access the
firewall and the DMZ. I use 0.0.0.0/0 to define the <b>loc</b> zone rather than
10.10.0.0/16 so that the limited broadcast address (255.255.255.255) falls into
that zone. If I used 10.10.0.0/16 then I would have to have a separate entry for
that special address.</p>
stopped, only the hosts in the <b>ops</b> zone will be allowed to access the
firewall and the DMZ. I use 0.0.0.0/0 to define the <b>loc</b> zone rather
than 10.10.0.0/16 so that the limited broadcast address (255.255.255.255)
falls into that zone. If I used 10.10.0.0/16 then I would have to have a
separate entry for that special address.</p>
<h2>Policy File</h2>
<blockquote>
<table border="2">
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>
POLICY</b></td>
<td><b>
LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td><font color="#0000FF">ops</font></td>
<td><font color="#0000FF">all</font></td>
<td><font color="#0000FF">ACCEPT</font></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td><font color="#0000FF">all</font></td>
<td><font color="#0000FF">ops</font></td>
<td><font color="#0000FF">CONTINUE</font></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<font face="Century Gothic, Arial, Helvetica">
<td>&nbsp;</td>
<td>&nbsp;</td>
</font>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td>&nbsp;</td>
</tr>
<blockquote> <font face="Century Gothic, Arial, Helvetica">
</font>
</table>
</blockquote>
<p>Two entries for <b>ops</b> have been added to the standard 3-zone policy file.
<font color="#FF0000"><b>WARNING: You must be running Shorewall 1.3.1 or later
for the above to work properly.</b></font></p>
<table border="2">
<tbody>
<tr>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> POLICY</b></td>
<td><b> LOG LEVEL</b></td>
<td><b>LIMIT:BURST</b></td>
</tr>
<tr>
<td><font color="#0000ff">ops</font></td>
<td><font color="#0000ff">all</font></td>
<td><font color="#0000ff">ACCEPT</font></td>
<td> </td>
<td> </td>
</tr>
<tr>
<td><font color="#0000ff">all</font></td>
<td><font color="#0000ff">ops</font></td>
<td><font color="#0000ff">CONTINUE</font></td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>loc</td>
<td>net</td>
<td>ACCEPT</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>net</td>
<td>all</td>
<td>DROP</td>
<td>info</td>
<td> </td>
</tr>
<tr>
<td>all</td>
<td>all</td>
<td>REJECT</td>
<td>info</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>Two entries for <b>ops</b> have been added to the standard 3-zone policy
file.<font color="#ff0000"><b></b></font></p>
<h2>Rules File</h2>
<blockquote> <font face="Century Gothic, Arial, Helvetica"> </font>
<table border="2">
<tbody>
<tr>
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b> PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc!ops</td>
<td>3128</td>
<td>tcp</td>
<td>http</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>...</td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This is the rule that transparently redirects web traffic to the transparent
proxy running on the firewall. The SOURCE column explicitly excludes the
<b>ops</b> zone from the rule.</p>
<h2>Routestopped File</h2>
<blockquote>
<table border="2">
<tr>
<font face="Century Gothic, Arial, Helvetica">
<td><b>ACTION</b></td>
<td><b>SOURCE</b></td>
<td><b>DEST</b></td>
<td><b>
PROTO</b></td>
<td><b>DEST<br>
PORT(S)</b></td>
<td><b>SOURCE<br>
PORT(S)</b></td>
<td><b>ORIGINAL<br>
DEST</b></td>
</font>
</tr>
<tr>
<td>REDIRECT</td>
<td>loc!ops</td>
<td>3128</td>
<td>tcp</td>
<td>http</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>...</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tbody>
<tr>
<td><b>INTERFACE</b><br>
</td>
<td><b> HOST(S)</b></td>
</tr>
<tr>
<td valign="top">eth1<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td>eth2<br>
</td>
<td>10.10.10.0/24</td>
</tr>
</table>
</tbody>
</table>
<br>
</blockquote>
<p>This is the rule that transparently redirects web traffic to the transparent
proxy running on the firewall. The SOURCE column explicitly excludes the <b>ops</b>
zone from the rule.</p>
<p><font size="2">
Updated 5/31/2002 - <a href="support.htm">Tom
Eastep</a>
</font></p>
<p><font size="2"> Updated 2/18/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">2002 Thomas M. Eastep.</font></a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2002, 2003Thomas M. Eastep.</font></a></font></p>
</body>
</html>
<br>
<br>
</body>
</html>