holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Make iproute required

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@459 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-21 22:22:19 +00:00
parent fe9b56090c
commit bcefe5a0c8
16 changed files with 12371 additions and 12104 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6009
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

408
Shorewall-docs/IPIP.htm
View File

@ -1,196 +1,248 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>GRE/IPIP Tunnels</title>
<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>GRE/IPIP Tunnels</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">
<tr>
<td width="100%">
<h1 align="center"><font color="#FFFFFF">GRE and IPIP Tunnels</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">GRE and IPIP Tunnels</font></h1>
</td>
</tr>
</tbody>
</table>
<h3><font color="#FF6633">Warning: </font>GRE and IPIP Tunnels are insecure when used
over the internet; use them at your own risk</h3>
<p>GRE and IPIP tunneling with Shorewall requires iproute2 and can be used to bridge two masqueraded networks.&nbsp;GRE
tunnels were introduced in shorewall version 1.2.0_Beta2.</p>
<p>The simple scripts described in the <a href="http://ds9a.nl/lartc">Linux Advanced Routing
and Shaping HOWTO</a> work fine with Shorewall. Shorewall also includes a tunnel
script for automating tunnel configuration. If you have installed the RPM, the
tunnel script may be found in the Shorewall documentation directory (usually
/usr/share/doc/shorewall-&lt;version&gt;/).</p>
<h3><font color="#ff6633">Warning: </font>GRE and IPIP Tunnels are insecure
when used over the internet; use them at your own risk</h3>
<p>GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded
networks.</p>
<p>The simple scripts described in the <a href="http://ds9a.nl/lartc">Linux
Advanced Routing and Shaping HOWTO</a> work fine with Shorewall. Shorewall
also includes a tunnel script for automating tunnel configuration. If you
have installed the RPM, the tunnel script may be found in the Shorewall documentation
directory (usually /usr/share/doc/shorewall-&lt;version&gt;/).</p>
<h2>Bridging two Masqueraded Networks</h2>
<p>Suppose that we have the following situation:</p>
<p align="center">
<img border="0" src="images/TwoNets1.png" width="745" height="427"></p>
<p align="left">We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is accomplished
through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy file
and the /etc/shorewall/tunnel script that is included with Shorewall.</p>
<p align="left">The 'tunnel' script is not installed in /etc/shorewall by
default -- If you install using the tarball, the script is included in the
tarball; if you install using the RPM, the file is in your Shorewall
documentation directory (normally /usr/share/doc/shorewall-&lt;version&gt;).</p>
<p align="left">In the /etc/shorewall/tunnel script, set the 'tunnel_type'
<p align="center"> <img border="0" src="images/TwoNets1.png" width="745"
height="427">
</p>
<p align="left">We want systems in the 192.168.1.0/24 subnetwork to be able
to communicate with the systems in the 10.0.0.0/8 network. This is accomplished
through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy
file and the /etc/shorewall/tunnel script that is included with Shorewall.</p>
<p align="left">The 'tunnel' script is not installed in /etc/shorewall by
default -- If you install using the tarball, the script is included in the
tarball; if you install using the RPM, the file is in your Shorewall documentation
directory (normally /usr/share/doc/shorewall-&lt;version&gt;).</p>
<p align="left">In the /etc/shorewall/tunnel script, set the 'tunnel_type'
parameter to the type of tunnel that you want to create.</p>
<p align="left">Example:</p>
<blockquote>
<p align="left">tunnel_type=gre</p>
</blockquote>
<p align="left">On each firewall, you will need to declare a zone to represent
the remote subnet. We'll assume that this zone is called 'vpn' and declare it in
/etc/shorewall/zones on both systems as follows.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet</td>
</tr>
</table>
<blockquote>
<p align="left">tunnel_type=gre</p>
</blockquote>
<p align="left">On system A, the 10.0.0.0/8 will comprise the <b>vpn</b> zone. In
/etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tosysb</td>
<td>10.255.255.255</td>
<td>&nbsp;</td>
</tr>
<p align="left">On each firewall, you will need to declare a zone to represent
the remote subnet. We'll assume that this zone is called 'vpn' and declare
it in /etc/shorewall/zones on both systems as follows.</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>ZONE</strong></td>
<td><strong>DISPLAY</strong></td>
<td><strong>COMMENTS</strong></td>
</tr>
<tr>
<td>vpn</td>
<td>VPN</td>
<td>Remote Subnet</td>
</tr>
</tbody>
</table>
</blockquote>
<p align="left">In /etc/shorewall/tunnels on system A, we need the following:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>ipip</td>
<td>net</td>
<td>134.28.54.2</td>
<td>&nbsp;</td>
</tr>
</table>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IP
encapsulation protocol (4) will be accepted to/from the remote gateway.</p>
<p>In the tunnel script on system A:</p>
<blockquote>
<p>tunnel=tosysb<br>
myrealip=206.161.148.9 (for GRE tunnel only)<br>
myip=192.168.1.1<br>
hisip=10.0.0.1<br>
gateway=134.28.54.2<br>
subnet=10.0.0.0/8</p>
</blockquote>
<p>Similarly, On system B the 192.168.1.0/24 subnet will comprise the <b>vpn</b>
</blockquote>
<p align="left">On system A, the 10.0.0.0/8 will comprise the <b>vpn</b>
zone. In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tosysa</td>
<td>192.168.1.255</td>
<td>&nbsp;</td>
</tr>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tosysb</td>
<td>10.255.255.255</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p align="left">In /etc/shorewall/tunnels on system A, we need the following:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>ipip</td>
<td>net</td>
<td>134.28.54.2</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>This entry in /etc/shorewall/tunnels, opens the firewall so that the IP
encapsulation protocol (4) will be accepted to/from the remote gateway.</p>
<p>In the tunnel script on system A:</p>
<blockquote>
<p>tunnel=tosysb<br>
myrealip=206.161.148.9 (for GRE tunnel only)<br>
myip=192.168.1.1<br>
hisip=10.0.0.1<br>
gateway=134.28.54.2<br>
subnet=10.0.0.0/8</p>
</blockquote>
<p>Similarly, On system B the 192.168.1.0/24 subnet will comprise the <b>vpn</b>
zone. In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>ZONE</b></td>
<td><b>INTERFACE</b></td>
<td><b>BROADCAST</b></td>
<td><b>OPTIONS</b></td>
</tr>
<tr>
<td>vpn</td>
<td>tosysa</td>
<td>192.168.1.255</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>In /etc/shorewall/tunnels on system B, we have:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>ipip</td>
<td>net</td>
<td>206.191.148.9</td>
<td>&nbsp;</td>
</tr>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><b>TYPE</b></td>
<td><b>ZONE</b></td>
<td><b>GATEWAY</b></td>
<td><b>GATEWAY ZONE</b></td>
</tr>
<tr>
<td>ipip</td>
<td>net</td>
<td>206.191.148.9</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
<p>And in the tunnel script on system B:</p>
<blockquote>
<blockquote>
<p>tunnel=tosysa<br>
myrealip=134.28.54.2 (for GRE tunnel only)<br>
myip=10.0.0.1<br>
hisip=192.168.1.1<br>
gateway=206.191.148.9<br>
subnet=192.168.1.0/24</p>
</blockquote>
<p>You can rename the modified tunnel scripts if you like; be sure that they are
secured so that root can execute them. </p>
<p align="Left"> You will need to allow traffic between the &quot;vpn&quot; zone and
the &quot;loc&quot; zone on both systems -- if you simply want to admit all traffic
in both directions, you can use the policy file:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse">
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td>&nbsp;</td>
</tr>
</table>
</blockquote>
<p>On both systems, restart Shorewall and
run the modified tunnel script with the &quot;start&quot; argument on each
system. The systems in the two masqueraded subnetworks can now talk to each
other</p>
<p><font size="2">Updated 8/22/2002 - <a href="support.htm">Tom
Eastep</a> </font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></p>
myrealip=134.28.54.2 (for GRE tunnel only)<br>
myip=10.0.0.1<br>
hisip=192.168.1.1<br>
gateway=206.191.148.9<br>
subnet=192.168.1.0/24</p>
</blockquote>
<p>You can rename the modified tunnel scripts if you like; be sure that they
are secured so that root can execute them. </p>
<p align="left"> You will need to allow traffic between the "vpn" zone and
the "loc" zone on both systems -- if you simply want to admit all
traffic in both directions, you can use the policy file:</p>
<blockquote>
<table border="2" cellpadding="2" style="border-collapse: collapse;">
<tbody>
<tr>
<td><strong>SOURCE</strong></td>
<td><strong>DEST</strong></td>
<td><strong>POLICY</strong></td>
<td><strong>LOG LEVEL</strong></td>
</tr>
<tr>
<td>loc</td>
<td>vpn</td>
<td>ACCEPT</td>
<td> </td>
</tr>
<tr>
<td>vpn</td>
<td>loc</td>
<td>ACCEPT</td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
<p>On both systems, restart Shorewall and run the modified tunnel script
with the "start" argument on each system. The systems in the two masqueraded
subnetworks can now talk to each other</p>
<p><font size="2">Updated 2/22/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, 2003Thomas M. Eastep.</font></a></p>
<br>
</body>
</html>

156
Shorewall-docs/MAC_Validation.html
View File

@ -2,109 +2,111 @@
<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
- module name ipt_mac.o).</b><br>
<br>
There are four components to this facility.<br>
<br>
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>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>
<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 <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
<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>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>
</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
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
column although you may use that format if you so choose.</li>
<li>IP Address - An optional comma-separated list of IP addresses
<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 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>
</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>
<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>
<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 my local zone.<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
file:<br>
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 2/18/2002 - <a href="support.htm">Tom Eastep</a>
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/21/2002 - <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><br>
</p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy;
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

3851
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,371 +2,331 @@
<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
<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"
<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
&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
<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 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
<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>
<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
<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#Local">Squid running in the
local network</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
will of course require access to remote web servers.<br>
<br>
In /etc/shorewall/rules:<br>
<br>
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>
<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
after networking has come up<br>
<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
is eth1 and your local interface is eth2.<br>
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
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>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">
@ -386,7 +346,7 @@ and add the following entry in /etc/shorewall/tcrules:<br>
</td>
</tr>
<tr>
<td valign="top">202:P<br>
<td valign="top">202<br>
</td>
<td valign="top">eth2<br>
</td>
@ -403,90 +363,130 @@ and add the following entry in /etc/shorewall/tcrules:<br>
</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="support.htm">Tom Eastep</a>
<p><font size="-1"> Updated 2/21/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>
<br>

408
Shorewall-docs/seattlefirewall_index.htm
View File

@ -6,7 +6,7 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
@ -15,23 +15,24 @@
<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">
@ -41,15 +42,61 @@
<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.4 - <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>
<div align="center"><a
href="http://shorewall.sf.net/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a><br>
</div>
<br>
</td>
</tr>
</tbody>
</table>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<td width="90%">
@ -60,52 +107,6 @@
<div align="center"><a
href="http://shorewall.sf.net/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a><br>
</div>
<br>
</td>
</tr>
</tbody>
</table>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4">
<tbody>
<tr>
<td width="90%">
<h2 align="left">What is it?</h2>
@ -118,11 +119,11 @@
<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>
@ -134,29 +135,29 @@ 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>
<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>
@ -168,7 +169,7 @@ copy of the GNU General Public License
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -181,20 +182,21 @@ copy of the GNU General Public License
<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.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.1!!!</b><br>
</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.1!!!</b><br>
</p>
@ -204,9 +206,9 @@ Bering 1.1!!!</b><br>
<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>
<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>
@ -220,7 +222,7 @@ Bering 1.1!!!</b><br>
<h2>News</h2>
@ -232,7 +234,8 @@ Bering 1.1!!!</b><br>
<h2></h2>
@ -242,102 +245,108 @@ Bering 1.1!!!</b><br>
<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>
</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
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>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<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>
<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>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
<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
<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>
<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>
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
<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
<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>
<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>
@ -345,7 +354,7 @@ support the 'maclist' option.<br>
<p><b></b><a href="News.htm">More News</a></p>
@ -358,44 +367,44 @@ support the 'maclist' option.<br>
<h2><a name="Donations"></a>Donations</h2>
</td>
</td>
<td width="88"
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <a
href="http://sourceforge.net">M</a></td>
</tr>
</tr>
</tbody>
</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;">
@ -404,12 +413,12 @@ support the 'maclist' option.<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>
@ -420,32 +429,33 @@ support the 'maclist' option.<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
<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>
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
</body>
</html>

84
Shorewall-docs/shorewall_prerequisites.htm
View File

@ -1,68 +1,68 @@
<!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>Shorewall Prerequisites</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">Shorewall Requirements</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<br>
Shorewall Requires:<br>
<br>
Shorewall Requires:<br>
<ul>
<li>A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6.
<a href="kernel.htm"> Check here for kernel configuration
information.</a> If you are looking for a firewall for use with 2.2
kernels, <a href="http://seawall.sf.net"> see the Seattle Firewall
site</a> .</li>
<li>iptables 1.2 or later but beware version 1.2.3 -- see the <a
href="errata.htm">Errata</a>. <font color="#ff0000"><b>WARNING: </b></font>The
buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
<li>A kernel that supports netfilter. I've tested with 2.4.2 - 2.4.20-pre6.
<a href="kernel.htm"> Check here for kernel configuration information.</a>
If you are looking for a firewall for use with 2.2 kernels, <a
href="http://seawall.sf.net"> see the Seattle Firewall site</a>
.</li>
<li>iptables 1.2 or later but beware version 1.2.3 -- see the <a
href="errata.htm">Errata</a>. <font color="#ff0000"><b>WARNING: </b></font>The
buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
is available <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat</a>
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">from RedHat</a>
and in the <a href="errata.htm">Shorewall Errata</a>. </li>
<li>Some features require iproute ("ip" utility). The iproute package
is included with most distributions but may not be installed by default.
The official download site is <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> <font
face="Century Gothic, Arial, Helvetica">f</font>tp://ftp.inr.ac.ru/ip-routing</a>.
</li>
<li>A Bourne shell or derivative such as bash or ash. This shell must
have correct support for variable expansion formats ${<i>variable</i>%<i>pattern</i>
}, ${<i>variable</i>%%<i>pattern</i>}, ${<i>variable</i>#<i>pattern</i>
} and ${<i>variable</i>##<i>pattern</i>}.</li>
<li>The firewall monitoring display is greatly improved if you have
<li>Iproute ("ip" utility). The iproute package is included with
most distributions but may not be installed by default. The official
download site is <a href="ftp://ftp.inr.ac.ru/ip-routing"
target="_blank"> <font face="Century Gothic, Arial, Helvetica">f</font>tp://ftp.inr.ac.ru/ip-routing</a>.
</li>
<li>A Bourne shell or derivative such as bash or ash. This shell must
have correct support for variable expansion formats ${<i>variable</i>%<i>pattern</i>
}, ${<i>variable</i>%%<i>pattern</i>}, ${<i>variable</i>#<i>pattern</i>
} and ${<i>variable</i>##<i>pattern</i>}.</li>
<li>The firewall monitoring display is greatly improved if you have
awk (gawk) installed.</li>
</ul>
<p align="left"><font size="2">Last updated 11/10/2002 - <a
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font></p>
<br>
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
<br>
</body>

4327
Shorewall-docs/shorewall_setup_guide.htm
View File

File diff suppressed because it is too large Load Diff

359
Shorewall-docs/sourceforge_index.htm
View File

@ -6,7 +6,7 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.4</title>
@ -15,25 +15,25 @@
<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">
@ -43,15 +43,15 @@
<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.4 - <font size="4">"<i>iptables
made easy"</i></font></font><a
</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>
@ -63,35 +63,35 @@
<div align="center"><a href="/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a></div>
</td>
</tr>
</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%">
@ -102,7 +102,7 @@
<h2 align="left">What is it?</h2>
@ -115,11 +115,11 @@
<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
<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>
@ -132,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
<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>
@ -166,7 +166,7 @@ A PARTICULAR PURPOSE. See the GNU General Public License
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -180,24 +180,25 @@ A PARTICULAR PURPOSE. See the GNU General Public License
<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.14 and Kernel-2.4.20. You can find
their work at: <a
</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>
</b>
<b>Congratulations to Jacques and Eric
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.1!!!</b><br>
<h2>News</h2>
@ -213,97 +214,102 @@ on the recent release of Bering 1.1!!!</b><br>
<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>
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>
</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>
Function from 1.3 that has been omitted from this version include:<br>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<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.
<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
<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 '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>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
<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
<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>
<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>
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
<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
<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>
<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>
<b> </b>
@ -312,7 +318,7 @@ support the 'maclist' option.<br>
<ul>
@ -321,16 +327,16 @@ support the 'maclist' option.<br>
</ul>
</ul>
<p><a href="News.htm">More News</a></p>
@ -344,31 +350,31 @@ support the 'maclist' option.<br>
<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>
@ -376,44 +382,44 @@ support the 'maclist' option.<br>
<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>
</tr>
</tbody>
</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;">
@ -423,12 +429,12 @@ support the 'maclist' option.<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>
@ -440,32 +446,33 @@ support the 'maclist' option.<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
<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>
href="http://www.starlight.org"><font color="#ffffff">Starlight Children's
Foundation.</font></a> Thanks!</font></p>
</td>
</td>
</tr>
</tr>
</tbody>
</tbody>
</table>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
</body>
</html>

690
Shorewall-docs/standalone.htm
View File

@ -1,425 +1,425 @@
<!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>Standalone Firewall</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" bordercolor="#111111" width="100%"
id="AutoNumber6" bgcolor="#400169" height="90">
<tbody>
<tr>
<td width="100%">
<tbody>
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Standalone Firewall</font></h1>
</td>
</tr>
</tbody>
</td>
</tr>
</tbody>
</table>
<h2 align="center">Version 2.0.1</h2>
<p align="left">Setting up Shorewall on a standalone Linux system is very
easy if you understand the basics and follow the documentation.</p>
<p>This guide doesn't attempt to acquaint you with all of the features of
Shorewall. It rather focuses on what is required to configure Shorewall
in one of its most common configurations:</p>
<p align="left">Setting up Shorewall on a standalone Linux system is very
easy if you understand the basics and follow the documentation.</p>
<p>This guide doesn't attempt to acquaint you with all of the features of
Shorewall. It rather focuses on what is required to configure Shorewall
in one of its most common configurations:</p>
<ul>
<li>Linux system</li>
<li>Single external IP address</li>
<li>Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...</li>
<li>Linux system</li>
<li>Single external IP address</li>
<li>Connection through Cable Modem, DSL, ISDN, Frame Relay, dial-up...</li>
</ul>
<p>This guide assumes that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
if this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
<p>Shorewall requires that you have the iproute/iproute2 package installed
(on RedHat, the package is called <i>iproute</i>)<i>. </i>You can tell
if this package is installed by the presence of an <b>ip</b> program on
your firewall system. As root, you can use the 'which' command to check
for this program:</p>
<pre> [root@gateway root]# which ip<br> /sbin/ip<br> [root@gateway root]#</pre>
<p>I recommend that you read through the guide first to familiarize yourself
with what's involved then go back through it again making your configuration
changes.  Points at which configuration changes are recommended are flagged
with <img border="0" src="images/BD21298_.gif" width="13" height="13">
.</p>
<p>I recommend that you read through the guide first to familiarize yourself
with what's involved then go back through it again making your configuration
changes.  Points at which configuration changes are recommended are flagged
with <img border="0" src="images/BD21298_.gif" width="13" height="13">
.</p>
<p><img border="0" src="images/j0213519.gif" width="60" height="60">
    If you edit your configuration files on a Windows system, you must
save them as Unix files if your editor supports that option or you must
run them through dos2unix before trying to use them. Similarly, if you
copy a configuration file from your Windows hard drive to a floppy disk,
you must run dos2unix against the copy before using it with Shorewall.</p>
    If you edit your configuration files on a Windows system, you
must save them as Unix files if your editor supports that option or you
must run them through dos2unix before trying to use them. Similarly, if
you copy a configuration file from your Windows hard drive to a floppy
disk, you must run dos2unix against the copy before using it with Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
of dos2unix</a></li>
<li><a href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux
Version of dos2unix</a></li>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
of dos2unix</a></li>
<li><a href="http://www.megaloman.com/%7Ehany/software/hd2u/">Linux
Version of dos2unix</a></li>
</ul>
<h2 align="left">Shorewall Concepts</h2>
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13"
alt="">
    The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for simple setups, you only need to deal with a few of
these as described in this guide. After you have <a
    The configuration files for Shorewall are contained in the directory
/etc/shorewall -- for simple setups, you only need to deal with a few
of these as described in this guide. After you have <a
href="Install.htm">installed Shorewall</a>, <b>download the <a
href="/pub/shorewall/LATEST.samples/one-interface.tgz">one-interface sample</a>,
un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall
(they will replace files with the same names that were placed in /etc/shorewall
href="/pub/shorewall/LATEST.samples/one-interface.tgz">one-interface sample</a>,
un-tar it (tar -zxvf one-interface.tgz) and and copy the files to /etc/shorewall
(they will replace files with the same names that were placed in /etc/shorewall
during Shorewall installation)</b>.</p>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the one-interface sample configuration, only one
zone is defined:</p>
<p>As each file is introduced, I suggest that you look through the actual
file on your system -- each file contains detailed configuration instructions
and default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the one-interface sample configuration, only
one zone is defined:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
<tbody>
<tbody>
<tr>
<td><u><b>Name</b></u></td>
<td><u><b>Description</b></u></td>
</tr>
<tr>
<td><u><b>Name</b></u></td>
<td><u><b>Description</b></u></td>
</tr>
<tr>
<td><b>net</b></td>
<td><b>The Internet</b></td>
</tr>
</tbody>
<td><b>net</b></td>
<td><b>The Internet</b></td>
</tr>
</tbody>
</table>
<p>Shorewall zones are defined in <a href="Documentation.htm#Zones"> /etc/shorewall/zones</a>.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b>.</p>
<p>Rules about what traffic to allow and what traffic to deny are expressed
in terms of zones.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b>.</p>
<p>Rules about what traffic to allow and what traffic to deny are expressed
in terms of zones.</p>
<ul>
<li>You express your default policy for connections from one zone
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
<li>You express your default policy for connections from one zone
to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/policy
</a>file.</li>
<li>You define exceptions to those default policies in the <a
<li>You define exceptions to those default policies in the <a
href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
</ul>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common (the
samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the one-interface sample has
the following policies:</p>
<blockquote>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
matches the connection request then the first policy in /etc/shorewall/policy
that matches the request is applied. If that policy is REJECT or DROP 
the request is first checked against the rules in /etc/shorewall/common
(the samples provide that file for you).</p>
<p>The /etc/shorewall/policy file included with the one-interface sample
has the following policies:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber3">
<tbody>
<tbody>
<tr>
<td><u><b>SOURCE ZONE</b></u></td>
<td><u><b>DESTINATION ZONE</b></u></td>
<td><u><b>POLICY</b></u></td>
<td><u><b>LOG LEVEL</b></u></td>
<td><u><b>LIMIT:BURST</b></u></td>
</tr>
<tr>
<td><u><b>SOURCE ZONE</b></u></td>
<td><u><b>DESTINATION ZONE</b></u></td>
<td><u><b>POLICY</b></u></td>
<td><u><b>LOG LEVEL</b></u></td>
<td><u><b>LIMIT:BURST</b></u></td>
</tr>
<tr>
<td>fw</td>
<td>net</td>
<td>ACCEPT</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>net</td>
<td>all<br>
</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>
<td>fw</td>
<td>net</td>
<td>ACCEPT</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>net</td>
<td>all<br>
</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>
</blockquote>
<p>The above policy will:</p>
<ol>
<li>allow all connection requests from the firewall to the internet</li>
<li>drop (ignore) all connection requests from the internet to your
firewall</li>
<li>reject all other connection requests (Shorewall requires this
catchall policy).</li>
<li>allow all connection requests from the firewall to the internet</li>
<li>drop (ignore) all connection requests from the internet to your
firewall</li>
<li>reject all other connection requests (Shorewall requires this
catchall policy).</li>
</ol>
<p>At this point, edit your /etc/shorewall/policy and make any changes that
you wish.</p>
<p>At this point, edit your /etc/shorewall/policy and make any changes that
you wish.</p>
<h2 align="left">External Interface</h2>
<p align="left">The firewall has a single network interface. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter (<b>eth0</b>) that is connected to that "Modem" 
<u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint <u>P</u>rotocol
over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint <u>T</u>unneling
<u>P</u>rotocol </i>(PPTP) in which case the External Interface will be
a <b>ppp0</b>. If you connect via a regular modem, your External Interface
will also be <b>ppp0</b>. If you connect using ISDN, your external interface
will be<b> ippp0.</b></p>
<p align="left">The firewall has a single network interface. Where Internet
connectivity is through a cable or DSL "Modem", the <i>External Interface</i>
will be the ethernet adapter (<b>eth0</b>) that is connected to that
"Modem"  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
<u>P</u>rotocol over <u>E</u>thernet</i> (PPPoE) or <i><u>P</u>oint-to-<u>P</u>oint
<u>T</u>unneling <u>P</u>rotocol </i>(PPTP) in which case the External
Interface will be a <b>ppp0</b>. If you connect via a regular modem, your
External Interface will also be <b>ppp0</b>. If you connect using ISDN,
your external interface will be<b> ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_3.gif" width="13"
height="13">
    The Shorewall one-interface sample configuration assumes that the
external interface is <b>eth0</b>. If your configuration is different,
you will have to modify the sample /etc/shorewall/interfaces file accordingly.
While you are there, you may wish to review the list of options that are
specified for the interface. Some hints:</p>
    The Shorewall one-interface sample configuration assumes that
the external interface is <b>eth0</b>. If your configuration is different,
you will have to modify the sample /etc/shorewall/interfaces file accordingly.
While you are there, you may wish to review the list of options that
are specified for the interface. Some hints:</p>
<ul>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>,
you can replace the "detect" in the second column with "-". </p>
</li>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the option
list. </p>
</li>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>,
you can replace the "detect" in the second column with "-". </p>
</li>
<li>
<p align="left">If your external interface is <b>ppp0</b> or <b>ippp0</b>
or if you have a static IP address, you can remove "dhcp" from the
option list. </p>
</li>
</ul>
<div align="left">
<div align="left">
<h2 align="left">IP Addresses</h2>
</div>
<div align="left">
<p align="left">RFC 1918 reserves several <i>Private </i>IP address ranges
for use in private networks:</p>
<div align="left">
</div>
<div align="left">
<p align="left">RFC 1918 reserves several <i>Private </i>IP address ranges
for use in private networks:</p>
<div align="left">
<pre> 10.0.0.0 - 10.255.255.255<br> 172.16.0.0 - 172.31.255.255<br> 192.168.0.0 - 192.168.255.255</pre>
</div>
<p align="left">These addresses are sometimes referred to as <i>non-routable</i>
because the Internet backbone routers will not forward a packet whose
destination address is reserved by RFC 1918. In some cases though, ISPs
are assigning these addresses then using <i>Network Address Translation
</i>to rewrite packet headers when forwarding to/from the internet.</p>
</div>
<p align="left">These addresses are sometimes referred to as <i>non-routable</i>
because the Internet backbone routers will not forward a packet whose
destination address is reserved by RFC 1918. In some cases though, ISPs
are assigning these addresses then using <i>Network Address Translation
</i>to rewrite packet headers when forwarding to/from the internet.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" align="left"
width="13" height="13">
     Before starting Shorewall, you should look at the IP address
of your external interface and if it is one of the above ranges, you should
remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.</p>
</div>
<div align="left">
<h2 align="left">Enabling other Connections</h2>
     Before starting Shorewall, you should look at the IP address
of your external interface and if it is one of the above ranges, you
should remove the 'norfc1918' option from the entry in /etc/shorewall/interfaces.</p>
</div>
<div align="left">
<p align="left">If you wish to enable connections from the internet to your
firewall, the general format is:</p>
</div>
<div align="left">
<blockquote>
<div align="left">
<h2 align="left">Enabling other Connections</h2>
</div>
<div align="left">
<p align="left">If you wish to enable connections from the internet to your
firewall, the general format is:</p>
</div>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber4">
<tbody>
<tr>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tbody>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td><i>&lt;protocol&gt;</i></td>
<td><i>&lt;port&gt;</i></td>
<td> </td>
<td> </td>
</tr>
</tbody>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td><i>&lt;protocol&gt;</i></td>
<td><i>&lt;port&gt;</i></td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
</div>
<div align="left">
<p align="left">Example - You want to run a Web Server and a POP3 Server
on your firewall system:</p>
</div>
<div align="left">
<p align="left">Example - You want to run a Web Server and a POP3 Server on
your firewall system:</p>
</div>
<div align="left">
<blockquote>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber5">
<tbody>
<tr>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tbody>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>80</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>110</td>
<td> </td>
<td> </td>
</tr>
</tbody>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>80</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>110</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</blockquote>
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular
application uses, see <a href="ports.htm">here</a>.</p>
</div>
<div align="left">
<p align="left">If you don't know what port and protocol a particular application
uses, see <a href="ports.htm">here</a>.</p>
</div>
<div align="left">
<p align="left"><b>Important: </b>I don't recommend enabling telnet to/from
the internet because it uses clear text (even for login!). If you want
shell access to your firewall from the internet, use SSH:</p>
</div>
<div align="left">
<blockquote>
<div align="left">
<p align="left"><b>Important: </b>I don't recommend enabling telnet to/from
the internet because it uses clear text (even for login!). If you want
shell access to your firewall from the internet, use SSH:</p>
</div>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
id="AutoNumber4">
<tbody>
<tr>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tbody>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>22</td>
<td> </td>
<td> </td>
</tr>
</tbody>
<td><u><b>ACTION</b></u></td>
<td><u><b>SOURCE</b></u></td>
<td><u><b>DESTINATION</b></u></td>
<td><u><b>PROTOCOL</b></u></td>
<td><u><b>PORT</b></u></td>
<td><u><b>SOURCE PORT</b></u></td>
<td><u><b>ORIGINAL ADDRESS</b></u></td>
</tr>
<tr>
<td>ACCEPT</td>
<td>net</td>
<td>fw</td>
<td>tcp</td>
<td>22</td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
</blockquote>
</div>
<div align="left">
</blockquote>
</div>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_3.gif" width="13"
height="13">
    At this point, edit /etc/shorewall/rules to add other connections
as desired.</p>
</div>
<div align="left">
<h2 align="left">Starting and Stopping Your Firewall</h2>
    At this point, edit /etc/shorewall/rules to add other connections
as desired.</p>
</div>
<div align="left">
<div align="left">
<h2 align="left">Starting and Stopping Your Firewall</h2>
</div>
<div align="left">
<p align="left"> <img border="0" src="images/BD21298_2.gif"
width="13" height="13" alt="Arrow">
    The <a href="Install.htm">installation procedure </a> configures
your system to start Shorewall at system boot but beginning with Shorewall
version 1.3.9 startup is disabled so that your system won't try to start
Shorewall before configuration is complete. Once you have completed configuration
of your firewall, you can enable Shorewall startup by removing the file
/etc/shorewall/startup_disabled.<br>
</p>
<p align="left"><font color="#ff0000"><b>IMPORTANT</b>: Users of the .deb
package must edit /etc/default/shorewall and set 'startup=1'.</font><br>
</p>
</div>
    The <a href="Install.htm">installation procedure </a> configures
your system to start Shorewall at system boot but beginning with Shorewall
version 1.3.9 startup is disabled so that your system won't try to start
Shorewall before configuration is complete. Once you have completed configuration
of your firewall, you can enable Shorewall startup by removing the file /etc/shorewall/startup_disabled.<br>
</p>
<div align="left">
<p align="left">The firewall is started using the "shorewall start" command
and stopped using "shorewall stop". When the firewall is stopped, routing
is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart" command.
If you want to totally remove any trace of Shorewall from your Netfilter
configuration, use "shorewall clear".</p>
</div>
<div align="left">
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
the internet, do not issue a "shorewall stop" command unless you have
added an entry for the IP address that you are connected from to <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate configuration</a></i>
and test it using the <a href="starting_and_stopping_shorewall.htm">"shorewall
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/26/2003 - <a
<p align="left"><font color="#ff0000"><b>IMPORTANT</b>: Users of the .deb
package must edit /etc/default/shorewall and set 'startup=1'.</font><br>
</p>
</div>
<div align="left">
<p align="left">The firewall is started using the "shorewall start" command
and stopped using "shorewall stop". When the firewall is stopped, routing
is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart" command.
If you want to totally remove any trace of Shorewall from your Netfilter
configuration, use "shorewall clear".</p>
</div>
<div align="left">
<p align="left"><b>WARNING: </b>If you are connected to your firewall from
the internet, do not issue a "shorewall stop" command unless you have
added an entry for the IP address that you are connected from to <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
Also, I don't recommend using "shorewall restart"; it is better to create
an <i><a href="configuration_file_basics.htm#Configs">alternate configuration</a></i>
and test it using the <a
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 2/21/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>

2209
Shorewall-docs/three-interface.htm
View File

File diff suppressed because it is too large Load Diff

2027
Shorewall-docs/three-interface_fr.html
View File

File diff suppressed because it is too large Load Diff

538
Shorewall-docs/traffic_shaping.htm
View File

@ -1,333 +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">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.</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.
<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.
<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
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
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
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
</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
<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
<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">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
<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
<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>
</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
<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>
<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><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>
<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
<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>
<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><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>
<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
<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>
<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><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>
<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>
</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>
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 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>
<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>
<br>
<br>
</body>
</html>

373
Shorewall-docs/troubleshoot.htm
View File

@ -1,232 +1,233 @@
<!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
<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
<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
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>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>
</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>)
</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
about how to interpret the chain name appearing in a Shorewall log message.<br>
</p>
<h3 align="left">'Ping' Problems?</h3>
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>
<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>Seeing rejected/dropped packets logged out of the INPUT
or FORWARD chains? This means that:
<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">
<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
about how to interpret the chain name appearing in a Shorewall log message.<br>
</p>
<h3 align="left">'Ping' Problems?</h3>
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:
<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>
file are you?); or</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
<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 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
to be allowed between zones, you need a rule of the form:<br>
<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
</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;   
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. </li>
<li>If you specify "routefilter" for an interface, that
<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
<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
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>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
<li>Shorewall requires 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>Problems with NAT? Be sure that you let Shorewall
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
.</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
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 2/18/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
</font>
<p><font size="2">Last updated 2/21/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>
</p>
<br>
<br>
</body>
</html>

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

File diff suppressed because it is too large Load Diff

514
Shorewall-docs/upgrade_issues.htm
View File

@ -1,291 +1,301 @@
<!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> </h3>
<h3>Version &gt;= 1.4.0</h3>
If you are upgrading from a version &lt; 1.4.0, then:<br>
<b>IMPORTANT: Shorewall &gt;=1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
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
<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
<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
<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>
<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>
<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>
<ul>
<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>
<ul>
</ul>
<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>
<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>
<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>
<blockquote>
<pre>rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm </pre>
<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>
<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>
<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>
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>
<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>
<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>
<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">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</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 2/14/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<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><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">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">Example 1:</p>
<div align="left">
<pre> ACCEPT net loc:192.168.1.12:22 tcp 11111 - all</pre>
</div>
<p align="left">Must be replaced with:</p>
<div align="left">
<pre> DNAT net loc:192.168.1.12:22 tcp 11111</pre>
</div>
<div align="left">
<p align="left">Example 2:</p>
</div>
<div align="left">
<pre> ACCEPT loc fw::3128 tcp 80 - all</pre>
</div>
<div align="left">
<p align="left">Must be replaced with:</p>
</div>
<div align="left">
<pre> REDIRECT loc 3128 tcp 80</pre>
</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 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>