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

More Shorewall 1.4.0 changes

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

1075
Shorewall-docs/Documentation.htm
View File

File diff suppressed because it is too large Load Diff

443
Shorewall-docs/FAQ.htm
View File

@ -63,20 +63,20 @@
<p align="left"><b>2.</b> <a href="#faq2">I <b>port forward</b> www requests
to www.mydomain.com (IP 130.151.100.69) to system 192.168.1.5
in my local network. <b>External clients can browse</b> http://www.mydomain.com
but <b>internal clients can't</b>.</a></p>
in my local network. <b>External clients can browse</b>
http://www.mydomain.com but <b>internal clients can't</b>.</a></p>
<p align="left"><b>2a. </b><a href="#faq3">I have a zone "Z" with an RFC1918
subnet and I use <b>static NAT</b> to assign non-RFC1918
addresses to hosts in Z. Hosts in Z cannot communicate with
each other using their external (non-RFC1918 addresses) so they
<b>can't access each other using their DNS names.</b></a></p>
addresses to hosts in Z. Hosts in Z cannot communicate
with each other using their external (non-RFC1918 addresses)
so they <b>can't access each other using their DNS names.</b></a></p>
<p align="left"><b>3. </b><a href="#faq3">I want to use <b>Netmeeting</b>
or <b>MSN Instant Messenger </b>with Shorewall. What do
I do?</a></p>
or <b>MSN Instant Messenger </b>with Shorewall. What
do I do?</a></p>
<p align="left"><b>4. </b><a href="#faq4">I just used an online port scanner
@ -114,14 +114,15 @@ from logging in Shorewall?</a><br>
in Shorewall log messages <b>so long</b>? I thought MAC addresses were only
6 bytes in length.</a><b><br>
</b></p>
<p align="left"><b>7. </b><a href="#faq7">When I stop Shorewall <b>using
'shorewall stop', I can't connect to anything</b>. Why doesn't that command
work?</a></p>
<p align="left"><b>8. </b><a href="#faq8">When I try to <b>start Shorewall
on RedHat</b> I get messages about insmod failing -- what's
wrong?</a></p>
on RedHat</b> I get messages about insmod failing --
what's wrong?</a></p>
<p align="left"><b>9. </b><a href="FAQ.htm#faq9">Why can't Shorewall <b>detect
@ -143,16 +144,16 @@ support?</a></p>
<p align="left"><b>14. </b><a href="#faq14">I'm connected via a cable modem
and it has an internel web server that allows me to configure/monitor
it but as expected if I enable <b> rfc1918 blocking</b> for
my eth0 interface, it also blocks the <b>cable modems web
server</b></a>.</p>
and it has an internel web server that allows me to
configure/monitor it but as expected if I enable <b> rfc1918
blocking</b> for my eth0 interface, it also blocks the <b>cable
modems web server</b></a>.</p>
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address.
If I enable RFC 1918 filtering on my external interface, <b>my
DHCP client cannot renew its lease</b>.</a></p>
If I enable RFC 1918 filtering on my external interface,
<b>my DHCP client cannot renew its lease</b>.</a></p>
<p align="left"><b>15. </b><a href="#faq15"><b>My local systems can't see
@ -163,12 +164,12 @@ server</b></a>.</p>
all over my console</b> making it unusable!<br>
</a></p>
<b>17</b>. <a
href="#faq17">How do I find out <b>why this traffic is</b>
getting <b>logged?</b></a><br>
href="#faq17">How do I find out <b>why this traffic is</b> getting
<b>logged?</b></a><br>
<br>
<b>18.</b> <a href="#faq18">Is there any way
to use <b>aliased ip addresses</b> with Shorewall, and maintain
separate rulesets for different IPs?</a><br>
<b>18.</b> <a href="#faq18">Is there any
way to use <b>aliased ip addresses</b> with Shorewall, and
maintain separate rulesets for different IPs?</a><br>
<br>
<b>19. </b><a href="#faq19">I have added <b>entries
to /etc/shorewall/tcrules</b> but they <b>don't </b>seem to <b>do
@ -188,8 +189,9 @@ I put them in?</a><br>
<b>23. </b><a href="#faq23">Why do you use such <b>ugly fonts</b>
on your <b>web site</b>?</a><br>
<br>
<b>24. </b><a href="#faq24">How can I <b>allow conections</b> to
let's say the ssh port only<b> from specific IP Addresses</b> on the internet?</a><br>
<b>24. </b><a href="#faq24">How can I <b>allow conections</b>
to let's say the ssh port only<b> from specific IP Addresses</b> on the
internet?</a><br>
<br>
<hr>
@ -318,8 +320,8 @@ let's say the ssh port only<b> from specific IP Addresses</b> on the interne
</table>
</blockquote>
Finally, if you need to forward a range of ports, in the PORT column specify
the range as <i>low-port</i>:<i>high-port</i>.<br>
Finally, if you need to forward a range of ports, in the PORT column
specify the range as <i>low-port</i>:<i>high-port</i>.<br>
<h4 align="left"><a name="faq1a"></a>1a. Ok -- I followed those instructions
but it doesn't work</h4>
@ -329,8 +331,8 @@ the range as <i>low-port</i>:<i>high-port</i>.<br>
<ul>
<li>You are trying to test from inside
your firewall (no, that won't work -- see <a
<li>You are trying to test from
inside your firewall (no, that won't work -- see <a
href="#faq2">FAQ #2</a>).</li>
<li>You have a more basic problem
with your local system such as an incorrect default gateway
@ -346,20 +348,20 @@ internal interface).</li>
<b>Answer: </b>To further diagnose this problem:<br>
<ul>
<li>As root, type "iptables -t nat -Z". This
clears the NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port from
an external host.</li>
<li>As root, type "iptables -t nat -Z".
This clears the NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port
from an external host.</li>
<li>As root type "shorewall show nat"</li>
<li>Locate the appropriate DNAT rule. It will
be in a chain called <i>&lt;source zone&gt;</i>_dnat ('net_dnat'
<li>Locate the appropriate DNAT rule. It
will be in a chain called <i>&lt;source zone&gt;</i>_dnat ('net_dnat'
in the above examples).</li>
<li>Is the packet count in the first column
non-zero? If so, the connection request is reaching the firewall
and is being redirected to the server. In this case, the problem
is usually a missing or incorrect default gateway setting on the
server (the server's default gateway should be the IP address of
the firewall's interface to the server).</li>
is usually a missing or incorrect default gateway setting on
the server (the server's default gateway should be the IP address
of the firewall's interface to the server).</li>
<li>If the packet count is zero:</li>
@ -371,9 +373,9 @@ the firewall's interface to the server).</li>
the primary IP address (You need to specify the secondary IP address
in the "ORIG. DEST." column in your DNAT rule); or</li>
<li>your DNAT rule doesn't match the connection
request in some other way. In that case, you may have to use a
packet sniffer such as tcpdump or ethereal to further diagnose the
problem.<br>
request in some other way. In that case, you may have to use
a packet sniffer such as tcpdump or ethereal to further diagnose
the problem.<br>
</li>
@ -382,9 +384,9 @@ the primary IP address (You need to specify the secondary IP address
</ul>
<h4 align="left"><a name="faq2"></a>2. I port forward www requests to www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in my local network.
External clients can browse http://www.mydomain.com but internal
clients can't.</h4>
(IP 130.151.100.69) to system 192.168.1.5 in my local
network. External clients can browse http://www.mydomain.com
but internal clients can't.</h4>
<p align="left"><b>Answer: </b>I have two objections to this setup.</p>
@ -392,37 +394,34 @@ the primary IP address (You need to specify the secondary IP address
<ul>
<li>Having an internet-accessible
server in your local network is like raising foxes in the
corner of your hen house. If the server is compromised, there's
nothing between that server and your other internal systems.
For the cost of another NIC and a cross-over cable, you can put
your server in a DMZ such that it is isolated from your local
systems - assuming that the Server can be located near the Firewall,
of course :-)</li>
<li>The accessibility problem is
best solved using <a href="shorewall_setup_guide.htm#DNS">Bind
Version 9 "views"</a> (or using a separate DNS server for local
clients) such that www.mydomain.com resolves to 130.141.100.69
externally and 192.168.1.5 internally. That's what I do here at
shorewall.net for my local systems that use static NAT.</li>
server in your local network is like raising foxes in
the corner of your hen house. If the server is compromised,
there's nothing between that server and your other internal
systems. For the cost of another NIC and a cross-over cable,
you can put your server in a DMZ such that it is isolated from
your local systems - assuming that the Server can be located
near the Firewall, of course :-)</li>
<li>The accessibility problem
is best solved using <a
href="shorewall_setup_guide.htm#DNS">Bind Version 9 "views"</a>
(or using a separate DNS server for local clients) such that www.mydomain.com
resolves to 130.141.100.69 externally and 192.168.1.5 internally.
That's what I do here at shorewall.net for my local systems that
use static NAT.</li>
</ul>
<p align="left">If you insist on an IP solution to the accessibility problem
rather than a DNS solution, then assuming that your external
interface is eth0 and your internal interface is eth1 and
that eth1 has IP address 192.168.1.254 with subnet 192.168.1.0/24,
do the following:</p>
<p align="left">a) In /etc/shorewall/interfaces, specify "multi" as an option
for eth1 (No longer required as of Shorewall version 1.3.9).</p>
rather than a DNS solution, then assuming that your
external interface is eth0 and your internal interface
is eth1 and that eth1 has IP address 192.168.1.254 with subnet
192.168.1.0/24, in /etc/shorewall/rules, add:</p>
<div align="left">
<p align="left">b) In /etc/shorewall/rules, add:</p>
</div>
@ -463,8 +462,8 @@ externally and 192.168.1.5 internally. That's what I do here at
<div align="left">
<p align="left">That rule only works of course if you have a static external
IP address. If you have a dynamic IP address and are running
Shorewall 1.3.4 or later then include this in /etc/shorewall/params:</p>
IP address. If you have a dynamic IP address and are
running Shorewall 1.3.4 or later then include this in /etc/shorewall/params:</p>
</div>
@ -515,22 +514,22 @@ externally and 192.168.1.5 internally. That's what I do here at
<div align="left">
<p align="left">Using this technique, you will want to configure your DHCP/PPPoE
client to automatically restart Shorewall each time that
you get a new IP address.</p>
client to automatically restart Shorewall each time
that you get a new IP address.</p>
</div>
<h4 align="left"><a name="faq2a"></a>2a. I have a zone "Z" with an RFC1918
subnet and I use static NAT to assign non-RFC1918 addresses
to hosts in Z. Hosts in Z cannot communicate with each other
using their external (non-RFC1918 addresses) so they can't access
each other using their DNS names.</h4>
using their external (non-RFC1918 addresses) so they can't
access each other using their DNS names.</h4>
<p align="left"><b>Answer: </b>This is another problem that is best solved
using Bind Version 9 "views". It allows both external and
internal clients to access a NATed host using the host's DNS
name.</p>
using Bind Version 9 "views". It allows both external
and internal clients to access a NATed host using the host's
DNS name.</p>
<p align="left">Another good way to approach this problem is to switch from
@ -539,14 +538,12 @@ non-RFC1918 addresses and can be accessed externally and
internally using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
(If you are running a Shorewall version earlier than 1.3.9).<br>
b) Set the Z-&gt;Z policy to ACCEPT.<br>
c) Masquerade Z to itself.<br>
<p align="left">a) Set the Z-&gt;Z policy to ACCEPT.<br>
b) Masquerade Z to itself.<br>
<br>
Example:</p>
@ -574,7 +571,8 @@ traffic through your firewall then:</p>
<td>dmz</td>
<td>eth2</td>
<td>192.168.2.255</td>
<td>multi</td>
<td><br>
</td>
</tr>
@ -653,11 +651,11 @@ traffic through your firewall then:</p>
<p align="left"><b>Answer: </b>There is an <a
href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection
tracking/NAT module</a> that may help with Netmeeting. Look
<a href="http://linux-igd.sourceforge.net">here</a> for a solution for
MSN IM but be aware that there are significant security risks involved with
this solution. Also check the Netfilter mailing list archives
at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
tracking/NAT module</a> that may help with Netmeeting.
Look <a href="http://linux-igd.sourceforge.net">here</a> for a solution
for MSN IM but be aware that there are significant security risks involved
with this solution. Also check the Netfilter mailing list
archives at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
</p>
@ -667,20 +665,21 @@ this solution. Also check the Netfilter mailing list archives
<p align="left"><b>Answer: </b>The common.def included with version 1.3.x
always rejects connection requests on TCP port 113 rather
than dropping them. This is necessary to prevent outgoing
connection problems to services that use the 'Auth' mechanism
for identifying requesting users. Shorewall also rejects TCP
ports 135, 137 and 139 as well as UDP ports 137-139. These are
ports that are used by Windows (Windows <u>can</u> be configured
to use the DCE cell locator on port 135). Rejecting these connection
requests rather than dropping them cuts down slightly on the amount
of Windows chatter on LAN segments connected to the Firewall. </p>
always rejects connection requests on TCP port 113
rather than dropping them. This is necessary to prevent
outgoing connection problems to services that use the 'Auth'
mechanism for identifying requesting users. Shorewall also
rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139.
These are ports that are used by Windows (Windows <u>can</u>
be configured to use the DCE cell locator on port 135). Rejecting
these connection requests rather than dropping them cuts down
slightly on the amount of Windows chatter on LAN segments connected
to the Firewall. </p>
<p align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web server in
violation of your Service Agreement.</p>
your ISP preventing you from running a web server
in violation of your Service Agreement.</p>
<h4 align="left"><a name="faq4a"></a>4a. I just ran an nmap UDP scan of my
@ -691,8 +690,8 @@ violation of your Service Agreement.</p>
section about UDP scans. If nmap gets <b>nothing</b>
back from your firewall then it reports the port as open.
If you want to see which UDP ports are really open, temporarily
change your net-&gt;all policy to REJECT, restart Shorewall and
do the nmap UDP scan again.</p>
change your net-&gt;all policy to REJECT, restart Shorewall
and do the nmap UDP scan again.</p>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
@ -700,13 +699,14 @@ If you want to see which UDP ports are really open, temporarily
<p align="left"><b>Answer: </b>If you want your firewall to be totally open
for "ping": </p>
for "ping", </p>
<p align="left">a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.<br>
b) Copy /etc/shorewall/icmp.def to
/etc/shorewall/icmpdef<br>
c) Add the following to /etc/shorewall/icmpdef:
<p align="left">a) Create /etc/shorewall/common if it doesn't already exist.
<br>
b) Be sure that the first command
in the file is ". /etc/shorewall/common.def"<br>
c) Add the following to /etc/shorewall/common
</p>
@ -723,20 +723,20 @@ see <a href="ping.html">this page</a>.
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure to restart
syslogd (on a RedHat system, "service syslog restart"). </p>
<p align="left">By default, older versions of Shorewall ratelimited log messages
through <a href="Documentation.htm#Conf">settings</a> in
/etc/shorewall/shorewall.conf -- If you want to log all messages,
set: </p>
through <a href="Documentation.htm#Conf">settings</a>
in /etc/shorewall/shorewall.conf -- If you want to log
all messages, set: </p>
<div align="left">
@ -757,7 +757,8 @@ logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
<p align="left"><a
href="http://www.shorewall.net/pub/shorewall/parsefw/"> http://www.shorewall.net/pub/shorewall/parsefw/</a><br>
<a href="http://www.fireparse.com">http://www.fireparse.com</a><br>
<a
href="http://www.fireparse.com">http://www.fireparse.com</a><br>
<a
href="http://cert.uni-stuttgart.de/projects/fwlogwatch">http://cert.uni-stuttgart.de/projects/fwlogwatch</a><a
href="http://www.logwatch.org"><br>
@ -797,18 +798,21 @@ option (<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
<blockquote>
<pre>#<br># Include the standard common.def file<br>#<br>. /etc/shorewall/common.def<br>#<br># The following rule is non-standard and compensates for tardy<br># DNS replies<br>#<br>run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</pre>
</blockquote>
The above file is also include in all of my sample configurations available
in the <a href="shorewall_quickstart_guide.htm">Quick Start Guides</a>.<br>
The above file is also include in all of my sample configurations
available in the <a href="shorewall_quickstart_guide.htm">Quick Start
Guides</a> and in the common.def file in Shorewall 1.4.0 and later.<br>
<h4 align="left"><a name="faq6d"></a><b>6d.</b> Why is the MAC address in
Shorewall log messages so long? I thought MAC addresses were only 6 bytes
in length. What is labeled as the MAC address in a Shorewall log message
is actually the Ethernet frame header. In contains:<br>
</h4>
<ul>
<li>the destination MAC address (6 bytes)</li>
<li>the source MAC address (6 bytes)</li>
<li>the ethernet frame type (2 bytes)</li>
</ul>
Example:<br>
<br>
@ -818,7 +822,9 @@ is actually the Ethernet frame header. In contains:<br>
<li>Destination MAC address = 00:04:4c:dc:e2:28</li>
<li>Source MAC address = 00:b0:8e:cf:3c:4c</li>
<li>Ethernet Frame Type = 08:00 (IP Version 4)</li>
</ul>
<h4 align="left"><a name="faq7"></a>7. When I stop Shorewall using 'shorewall
stop', I can't connect to anything. Why doesn't that command
work?</h4>
@ -859,6 +865,7 @@ is actually the Ethernet frame header. In contains:<br>
<h4 align="left"> </h4>
<h4 align="left"><a name="faq9"></a>9. Why can't Shorewall detect my interfaces
properly?</h4>
@ -878,9 +885,9 @@ is actually the Ethernet frame header. In contains:<br>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
zone is defined as all hosts connected through eth1</p>
<p align="left"><b>Answer: </b>The above output is perfectly normal. The
Net zone is defined as all hosts that are connected through eth0 and the
local zone is defined as all hosts connected through eth1</p>
</div>
@ -889,7 +896,9 @@ is actually the Ethernet frame header. In contains:<br>
<p align="left">Shorewall works with any GNU/Linux distribution that includes
the <a href="shorewall_prerequisites.htm">proper prerequisites</a>.</p>
the <a href="shorewall_prerequisites.htm">proper
prerequisites</a>.</p>
<h4 align="left">11. What Features does it have?</h4>
@ -897,6 +906,7 @@ is actually the Ethernet frame header. In contains:<br>
<p align="left"><b>Answer: </b>See the <a href="shorewall_features.htm">Shorewall
Feature List</a>.</p>
<h4 align="left"><a name="faq12"></a>12. Is there a GUI?</h4>
@ -904,20 +914,22 @@ is actually the Ethernet frame header. In contains:<br>
1.060 and later versions. See <a href="http://www.webmin.com">http://www.webmin.com</a>
</p>
<h4 align="left"> <a name="faq13"></a>13. Why do you call it "Shorewall"?</h4>
<p align="left"><b>Answer: </b>Shorewall is a concatenation of "<u>Shore</u>line"
(<a href="http://www.cityofshoreline.com">the city
where I live</a>) and "Fire<u>wall</u>". The full name of the
product is actually "Shoreline Firewall" but "Shorewall" is must more
commonly used.</p>
where I live</a>) and "Fire<u>wall</u>". The full name of
the product is actually "Shoreline Firewall" but "Shorewall" is must
more commonly used.</p>
<h4 align="left"> <a name="faq14"></a>14. I'm connected via a cable modem
and it has an internal web server that allows me to configure/monitor
it but as expected if I enable rfc1918 blocking for my eth0
interface (the internet one), it also blocks the cable modems
web server.</h4>
and it has an internal web server that allows me to
configure/monitor it but as expected if I enable rfc1918
blocking for my eth0 interface (the internet one), it also
blocks the cable modems web server.</h4>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
@ -926,8 +938,10 @@ address of the modem in/out but still block all other rfc1918
addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -969,13 +983,16 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<p align="left">Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.<br>
</p>
<p align="left">Note: If you add a second IP address to your external firewall
interface to correspond to the modem address, you must also
make an entry in /etc/shorewall/rfc1918 for that address. For
example, if you configure the address 192.168.100.2 on your firewall,
then you would add two entries to /etc/shorewall/rfc1918: <br>
interface to correspond to the modem address, you must
also make an entry in /etc/shorewall/rfc1918 for that address.
For example, if you configure the address 192.168.100.2 on your
firewall, then you would add two entries to /etc/shorewall/rfc1918:
<br>
</p>
<blockquote>
<table cellpadding="2" border="1" style="border-collapse: collapse;">
@ -1001,6 +1018,7 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
</tbody>
</table>
@ -1009,10 +1027,10 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.</h4>
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable
RFC 1918 filtering on my external interface, my DHCP client cannot renew
its lease.</h4>
</div>
@ -1027,10 +1045,10 @@ lease.</h4>
<p align="left"><b>Answer: </b>Every time I read "systems can't see out to
the net", I wonder where the poster bought computers with
eyes and what those computers will "see" when things are working
properly. That aside, the most common causes of this problem
are:</p>
the net", I wonder where the poster bought computers
with eyes and what those computers will "see" when things
are working properly. That aside, the most common causes of
this problem are:</p>
<ol>
@ -1054,7 +1072,8 @@ lease.</h4>
<p align="left">The DNS settings on the local systems are wrong or the
user is running a DNS server on the firewall and hasn't
enabled UDP and TCP port 53 from the firewall to the internet.</p>
enabled UDP and TCP port 53 from the firewall to the
internet.</p>
</li>
@ -1067,19 +1086,20 @@ lease.</h4>
<p align="left"><b>Answer: </b>"man dmesg" -- add a suitable 'dmesg' command
to your startup scripts or place it in /etc/shorewall/start.
Under RedHat, the max log level that is sent to the console
is specified in /etc/sysconfig/init in the LOGLEVEL variable.<br>
Under RedHat, the max log level that is sent to the
console is specified in /etc/sysconfig/init in the LOGLEVEL
variable.<br>
</p>
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
logged?</h4>
<b>Answer: </b>Logging occurs out of a number
of chains (as indicated in the log message) in Shorewall:<br>
<b>Answer: </b>Logging occurs out of
a number of chains (as indicated in the log message) in Shorewall:<br>
<ol>
<li><b>man1918 - </b>The destination address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>man1918 - </b>The destination
address is listed in /etc/shorewall/rfc1918 with a <b>logdrop
</b>target -- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b> - The source address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
@ -1090,12 +1110,12 @@ lease.</h4>
to ACCEPT this traffic then you need a <a
href="Documentation.htm#Rules">rule</a> to that effect.<br>
</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt; </b>-
Either you have a<a href="Documentation.htm#Policy"> policy</a> for
<b>&lt;zone1&gt; </b>to <b>&lt;zone2&gt;</b> that specifies
a log level and this packet is being logged under that policy
or this packet matches a <a href="Documentation.htm#Rules">rule</a>
that includes a log level.</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt;
</b>- Either you have a<a href="Documentation.htm#Policy">
policy</a> for <b>&lt;zone1&gt; </b>to <b>&lt;zone2&gt;</b>
that specifies a log level and this packet is being logged
under that policy or this packet matches a <a
href="Documentation.htm#Rules">rule</a> that includes a log level.</li>
<li><b>&lt;interface&gt;_mac</b> - The packet
is being logged under the <b>maclist</b> <a
href="Documentation.htm#Interfaces">interface option</a>.<br>
@ -1106,20 +1126,22 @@ is being logged under the <b>maclist</b> <a
<li><b>badpkt </b>- The packet is being
logged under the <b>dropunclean</b> <a
href="Documentation.htm#Interfaces">interface option</a> as specified
in the <b>LOGUNCLEAN </b>setting in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is being
logged because the source IP is blacklisted in the<a
in the <b>LOGUNCLEAN </b>setting in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is
being logged because the source IP is blacklisted in the<a
href="Documentation.htm#Blacklist"> /etc/shorewall/blacklist </a>file.</li>
<li><b>newnotsyn </b>- The packet is being
logged because it is a TCP packet that is not part of any current
connection yet it is not a syn packet. Options affecting the logging
of such packets include <b>NEWNOTSYN </b>and <b>LOGNEWNOTSYN
</b>in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> - The
packet has a source IP address that isn't in any of your defined
zones ("shorewall check" and look at the printed zone definitions)
or the chain is FORWARD and the destination IP isn't in any of your
defined zones.</li>
<li><b>newnotsyn </b>- The packet is
being logged because it is a TCP packet that is not part
of any current connection yet it is not a syn packet. Options
affecting the logging of such packets include <b>NEWNOTSYN
</b>and <b>LOGNEWNOTSYN </b>in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> -
The packet has a source IP address that isn't in any of your
defined zones ("shorewall check" and look at the printed zone
definitions) or the chain is FORWARD and the destination IP isn't
in any of your defined zones.</li>
<li><b>logflags </b>- The packet is being logged
because it failed the checks implemented by the <b>tcpflags </b><a
href="Documentation.htm#Interfaces">interface option</a>.<br>
@ -1130,11 +1152,12 @@ because it failed the checks implemented by the <b>tcpflags </b><a
<h4><a name="faq18"></a>18. Is there any way to use <b>aliased ip addresses</b>
with Shorewall, and maintain separate rulesets for different
IPs?</h4>
<b>Answer: </b>Yes. You simply use the IP address
in your rules (or if you use NAT, use the local IP address in
your rules). <b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated
and will disappear eventually. Neither iproute (ip and tc) nor
iptables supports that notation so neither does Shorewall. <br>
<b>Answer: </b>Yes. You simply use the IP
address in your rules (or if you use NAT, use the local IP address
in your rules). <b>Note:</b> The ":n" notation (e.g., eth0:0)
is deprecated and will disappear eventually. Neither iproute
(ip and tc) nor iptables supports that notation so neither does
Shorewall. <br>
<br>
<b>Example 1:</b><br>
<br>
@ -1168,9 +1191,9 @@ because it failed the checks implemented by the <b>tcpflags </b><a
to change Shorewall to allow access to my server from the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1186,13 +1209,14 @@ you used during your initial setup for information about how to set
<b>Answer: </b>While most people associate the Internet
Control Message Protocol (ICMP) with 'ping', ICMP is a key piece
of the internet. ICMP is used to report problems back to the sender
of a packet; this is what is happening here. Unfortunately, where NAT
is involved (including SNAT, DNAT and Masquerade), there are a lot
of broken implementations. That is what you are seeing with these messages.<br>
of a packet; this is what is happening here. Unfortunately, where
NAT is involved (including SNAT, DNAT and Masquerade), there are
a lot of broken implementations. That is what you are seeing with these
messages.<br>
<br>
Here is my interpretation of what is happening -- to
confirm this analysis, one would have to have packet sniffers placed
a both ends of the connection.<br>
Here is my interpretation of what is happening --
to confirm this analysis, one would have to have packet sniffers
placed a both ends of the connection.<br>
<br>
Host 172.16.1.10 behind NAT gateway 206.124.146.179
sent a UDP DNS query to 192.0.2.3 and your DNS server tried to
@ -1200,58 +1224,61 @@ send a response (the response information is in the brackets -- note
source port 53 which marks this as a DNS reply). When the response was
returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10
and forwarded the packet to 172.16.1.10 who no longer had a connection
on UDP port 2857. This causes a port unreachable (type 3, code 3) to
be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has
no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
appear to be related to anything that was sent. The final result is
that the packet gets logged and dropped in the all2all chain. I have also
seen cases where the source IP in the ICMP itself isn't set back to the
external IP of the remote NAT gateway; that causes your firewall to log
and drop the packet out of the rfc1918 chain because the source IP is
reserved by RFC 1918.<br>
on UDP port 2857. This causes a port unreachable (type 3, code 3)
to be generated back to 192.0.2.3. As this packet is sent back through
206.124.146.179, that box correctly changes the source address in
the packet to 206.124.146.179 but doesn't reset the DST IP in the original
DNS response similarly. When the ICMP reaches your firewall (192.0.2.3),
your firewall has no record of having sent a DNS reply to 172.16.1.10
so this ICMP doesn't appear to be related to anything that was sent.
The final result is that the packet gets logged and dropped in the
all2all chain. I have also seen cases where the source IP in the ICMP
itself isn't set back to the external IP of the remote NAT gateway; that
causes your firewall to log and drop the packet out of the rfc1918 chain
because the source IP is reserved by RFC 1918.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do I put them
in?</h4>
You can place these commands in one of the <a
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>.
Be sure that you look at the contents of the chain(s) that you will be modifying
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>. Be
sure that you look at the contents of the chain(s) that you will be modifying
with your commands to be sure that the commands will do what they
are intended. Many iptables commands published in HOWTOs and other
instructional material use the -A command which adds the rules to the
end of the chain. Most chains that Shorewall constructs end with an
unconditional DROP, ACCEPT or REJECT rule and any rules that you add
after that will be ignored. Check "man iptables" and look at the -I (--insert)
command.<br>
are intended. Many iptables commands published in HOWTOs and other instructional
material use the -A command which adds the rules to the end of the
chain. Most chains that Shorewall constructs end with an unconditional
DROP, ACCEPT or REJECT rule and any rules that you add after that will
be ignored. Check "man iptables" and look at the -I (--insert) command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
The Shorewall web site is almost font neutral (it doesn't explicitly
specify fonts except on a few pages) so the fonts you see are largely
the default fonts configured in your browser. If you don't like them
then reconfigure your browser.<br>
The Shorewall web site is almost font neutral (it doesn't
explicitly specify fonts except on a few pages) so the fonts you see
are largely the default fonts configured in your browser. If you don't
like them then reconfigure your browser.<br>
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
the ssh port only<b> from specific IP Addresses</b> on the internet?</h4>
In the SOURCE column of the rule, follow "net" by a colon and a
list of the host/subnet addresses as a comma-separated list.<br>
In the SOURCE column of the rule, follow "net" by a colon and
a list of the host/subnet addresses as a comma-separated list.<br>
<pre>    net:&lt;ip1&gt;,&lt;ip2&gt;,...<br></pre>
Example:<br>
<pre> ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22<br></pre>
<h4></h4>
<div align="left"> </div>
<font size="2">Last updated 2/6/2003 - <a
<font size="2">Last updated 2/18/2003 - <a
href="support.htm">Tom Eastep</a></font>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<p><a href="copyright.htm"><font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
</body>
</html>

33
Shorewall-docs/MAC_Validation.html
View File

@ -28,8 +28,8 @@
<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>
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
@ -39,16 +39,16 @@ Verification and your kernel must include MAC match support (CONFIG_IP_NF_MATCH_
<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>
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 with
MAC addresses.</li>
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
@ -78,17 +78,16 @@ for the device whose MAC is listed in the MAC column.</li>
<pre> MACLIST_DISPOSITION=REJECT<br> MACLIST_LOG_LEVEL=info<br></pre>
<b>/etc/shorewall/interfaces:</b><br>
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,filterping,maclist<br> dmz eth1 192.168.2.255 filterping<br> net eth3 206.124.146.255 filterping,blacklist<br> - texas 192.168.9.255 filterping<br> loc ppp+ - filterping<br></pre>
<pre> #ZONE INTERFACE BROADCAST OPTIONS<br> net eth0 206.124.146.255 norfc1918,dhcp,blacklist<br> loc eth2 192.168.1.255 dhcp,maclist<br> dmz eth1 192.168.2.255<br> net eth3 206.124.146.255 blacklist<br> - texas 192.168.9.255<br> loc ppp+<br></pre>
<b>/etc/shorewall/maclist:</b><br>
<pre> #INTERFACE MAC IP ADDRESSES (Optional)<br> eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie<br> eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry<br> eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa<br> eth2 00:A0:CC:DB:31:C4 192.168.1.128/26 #PPTP Clients to server on Ursa<br> eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)<br> eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap<br></pre>
As shown above, I use MAC Verification on <a href="myfiles.htm">my
local zone</a>.<br>
As shown above, I use MAC Verification on my local zone.<br>
<h3>Example 2: Router in Local Zone</h3>
Suppose now that I add a second ethernet segment to my local zone and
gateway that segment via a router with MAC address 00:06:43:45:C6:15 and
IP address 192.168.1.253. Hosts in the second segment have IP addresses
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>
@ -96,10 +95,9 @@ in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorew
This entry accomodates traffic from the router itself (192.168.1.253)
and from the second LAN segment (192.168.2.0/24). Remember that all traffic
being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
by the router so that traffic's MAC address will be that of the router
(00:06:43:45:C6:15) and not that of the host sending the traffic.
<p><font size="2"> Updated 1/7/2002 - <a href="support.htm">Tom Eastep</a>
by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15)
and not that of the host sending the traffic.
<p><font size="2"> Updated 2/18/2002 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -107,5 +105,6 @@ in the subnet 192.168.2.0/24. I would add the following entry to my /etc/shorew
<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>
</body>
</html>

1427
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

22
Shorewall-docs/Shorewall_Squid_Usage.html
View File

@ -65,8 +65,8 @@ the local zone, that zone must be defined ONLY by its interface -- no /etc/shor
server.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have NAT and MANGLE enabled in your /etc/shorewall/conf
file<br>
</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>
@ -74,8 +74,8 @@ server.<br>
Three different configurations are covered:<br>
<ol>
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on the
Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#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>
@ -148,9 +148,9 @@ local network</a></li>
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>
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
@ -327,6 +327,7 @@ A) In /etc/shorewall/start add<br>
<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">
@ -359,11 +360,13 @@ and add the following entry in /etc/shorewall/tcrules:<br>
<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>
<table cellpadding="2" border="1" cellspacing="0">
@ -402,6 +405,7 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
</blockquote>
<br>
</blockquote>
<ul>
<li>In /etc/shorewall/rules, you will need:</li>
@ -473,8 +477,7 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
<blockquote> </blockquote>
<p><font size="-1"> Updated 1/23/2003 - <a
href="file:///home/teastep/Shorewall-docs/support.htm">Tom Eastep</a>
<p><font size="-1"> Updated 1/23/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -486,5 +489,6 @@ C) Run Shorewall 1.3.14 or later and add the following entry in /etc/shorewall/t
<br>
<br>
<br>
<br>
</body>
</html>

79
Shorewall-docs/configuration_file_basics.htm
View File

@ -40,8 +40,8 @@
<p>Shorewall's configuration files are in the directory /etc/shorewall.</p>
<ul>
<li>/etc/shorewall/shorewall.conf - used to set several
firewall parameters.</li>
<li>/etc/shorewall/shorewall.conf - used to set
several firewall parameters.</li>
<li>/etc/shorewall/params - use this file to set
shell variables that you will expand in other files.</li>
<li>/etc/shorewall/zones - partition the firewall's
@ -53,9 +53,8 @@ high-level policy.</li>
<li>/etc/shorewall/hosts - allows defining zones
in terms of individual hosts and subnetworks.</li>
<li>/etc/shorewall/masq - directs the firewall where
to use many-to-one (dynamic) Network Address Translation
(a.k.a. Masquerading) and Source Network Address Translation
(SNAT).</li>
to use many-to-one (dynamic) Network Address Translation (a.k.a.
Masquerading) and Source Network Address Translation (SNAT).</li>
<li>/etc/shorewall/modules - directs the firewall
to load kernel modules.</li>
<li>/etc/shorewall/rules - defines rules that are
@ -65,20 +64,20 @@ exceptions to the overall policies established in /etc/shorewall/p
ARP.</li>
<li>/etc/shorewall/routestopped (Shorewall 1.3.4
and later) - defines hosts accessible when Shorewall is stopped.</li>
<li>/etc/shorewall/tcrules - defines marking of packets
for later use by traffic control/shaping or policy routing.</li>
<li>/etc/shorewall/tcrules - defines marking of
packets for later use by traffic control/shaping or policy routing.</li>
<li>/etc/shorewall/tos - defines rules for setting
the TOS field in packet headers.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE and
IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE
and IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/blacklist - lists blacklisted
IP/subnet/MAC addresses.</li>
<li>/etc/shorewall/init - commands that you wish to execute at the beginning
of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/init - commands that you wish to execute at the
beginning of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/start - commands that you wish to execute at the
completion of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the beginning
of a "shorewall stop".</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the
beginning of a "shorewall stop".</li>
<li>/etc/shorewall/stopped - commands that you wish to execute at the
completion of a "shorewall stop".<br>
</li>
@ -89,8 +88,8 @@ completion of a "shorewall start" or "shorewall restart"</li>
<p>You may place comments in configuration files by making the first non-whitespace
character a pound sign ("#"). You may also place comments at
the end of any line, again by delimiting the comment from the
rest of the line with a pound sign.</p>
the end of any line, again by delimiting the comment from the rest
of the line with a pound sign.</p>
<p>Examples:</p>
@ -112,9 +111,9 @@ rest of the line with a pound sign.</p>
<p align="left"> </p>
<p align="left"><b>WARNING: I personally recommend strongly <u>against</u>
using DNS names in Shorewall configuration files. If you use DNS
names and you are called out of bed at 2:00AM because Shorewall won't
start as a result of DNS problems then don't say that you were not forewarned.
using DNS names in Shorewall configuration files. If you use DNS names
and you are called out of bed at 2:00AM because Shorewall won't start
as a result of DNS problems then don't say that you were not forewarned.
<br>
</b></p>
@ -127,10 +126,10 @@ start as a result of DNS problems then don't say that you were not forewarn
<br>
DNS names in iptables rules aren't nearly as useful as they
first appear. When a DNS name appears in a rule, the iptables utility
resolves the name to one or more IP addresses and inserts those addresses
into the rule. So changes in the DNS-&gt;IP address relationship that
occur after the firewall has started have absolutely no effect on the
firewall's ruleset. </p>
resolves the name to one or more IP addresses and inserts those
addresses into the rule. So changes in the DNS-&gt;IP address relationship
that occur after the firewall has started have absolutely no effect
on the firewall's ruleset. </p>
<p align="left"> If your firewall rules include DNS names then:</p>
@ -141,8 +140,8 @@ won't start.</li>
won't start.</li>
<li>If your Name Server(s) is(are) down then your firewall
won't start.</li>
<li>If your startup scripts try to start your firewall before
starting your DNS server then your firewall won't start.<br>
<li>If your startup scripts try to start your firewall
before starting your DNS server then your firewall won't start.<br>
</li>
<li>Factors totally outside your control (your ISP's router
is down for example), can prevent your firewall from starting.</li>
@ -188,8 +187,8 @@ configuration files.<br>
<p>Where specifying an IP address, a subnet or an interface, you can
precede the item with "!" to specify the complement of the item. For
example, !192.168.1.4 means "any host but 192.168.1.4". There must be
no white space following the "!".</p>
example, !192.168.1.4 means "any host but 192.168.1.4". There must
be no white space following the "!".</p>
<h2><a name="Lists"></a>Comma-separated Lists</h2>
@ -198,8 +197,8 @@ no white space following the "!".</p>
<ul>
<li>Must not have any embedded white space.<br>
Valid: routestopped,dhcp,norfc1918<br>
Invalid: routestopped,     dhcp,     norfc1818</li>
Valid: routefilter,dhcp,norfc1918<br>
Invalid: routefilter,     dhcp,     norfc1818</li>
<li>If you use line continuation to break a comma-separated
list, the continuation line(s) must begin in column 1 (or
there would be embedded white space)</li>
@ -217,8 +216,8 @@ in any order.</li>
<p>If you need to specify a range of ports, the proper syntax is &lt;<i>low
port number</i>&gt;:&lt;<i>high port number</i>&gt;. For example,
if you want to forward the range of tcp ports 4000 through 4100 to local
host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
if you want to forward the range of tcp ports 4000 through 4100 to
local host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
</p>
<pre> DNAT net loc:192.168.1.3 tcp 4000:4100<br></pre>
@ -238,7 +237,7 @@ the high port number, a value of 65535 is assumed.<br>
<blockquote>
<pre>NET_IF=eth0<br>NET_BCAST=130.252.100.255<br>NET_OPTIONS=noping,norfc1918</pre>
<pre>NET_IF=eth0<br>NET_BCAST=130.252.100.255<br>NET_OPTIONS=routefilter,norfc1918</pre>
</blockquote>
<p><br>
@ -258,18 +257,19 @@ the high port number, a value of 65535 is assumed.<br>
<blockquote>
<pre>net eth0 130.252.100.255 noping,norfc1918</pre>
<pre>net eth0 130.252.100.255 routefilter,norfc1918</pre>
</blockquote>
</font>
<p>Variables may be used anywhere in the other configuration
files.</p>
<h2><a name="MAC"></a>Using MAC Addresses</h2>
<p>Media Access Control (MAC) addresses can be used to specify packet
source in several of the configuration files. To use this feature,
your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
source in several of the configuration files. To use this
feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC)
included.</p>
<p>MAC addresses are 48 bits wide and each Ethernet Controller has a
@ -306,12 +306,12 @@ MAC address in the example above would be written "~02-00-08-E3-FA-55
<h2><a name="Levels"></a>Shorewall Configurations</h2>
<p> Shorewall allows you to have configuration directories other than /etc/shorewall.
The <a href="starting_and_stopping_shorewall.htm">shorewall start and
restart</a> commands allow you to specify an alternate configuration
The <a href="starting_and_stopping_shorewall.htm">shorewall start
and restart</a> commands allow you to specify an alternate configuration
directory and Shorewall will use the files in the alternate directory
rather than the corresponding files in /etc/shorewall. The alternate directory
need not contain a complete configuration; those files not in the alternate
directory will be read from /etc/shorewall.</p>
rather than the corresponding files in /etc/shorewall. The alternate
directory need not contain a complete configuration; those files not
in the alternate directory will be read from /etc/shorewall.</p>
<p> This facility permits you to easily create a test or temporary configuration
by:</p>
@ -342,5 +342,6 @@ MAC address in the example above would be written "~02-00-08-E3-FA-55
<br>
<br>
<br>
<br>
</body>
</html>

457
Shorewall-docs/errata.htm
View File

@ -5,7 +5,8 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall 1.3 Errata</title>
<title>Shorewall 1.4 Errata</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
@ -15,6 +16,8 @@
<meta name="Microsoft Theme" content="none">
<meta name="author" content="Tom Eastep">
</head>
<body>
@ -54,18 +57,9 @@ untar the archive, replace the 'firewall' script in the untarred director
</li>
<li>
<p align="left"> <b>If you are running a Shorewall version earlier
than 1.3.11, when the instructions say to install a corrected firewall
script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to
overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD
/etc/shorewall/firewall or /var/lib/shorewall/firewall before
you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall
are symbolic links that point to the 'shorewall' file used by
your system initialization scripts to start Shorewall during
boot. It is that file that must be overwritten with the corrected
script. Beginning with Shorewall 1.3.11, you may rename the existing file
before copying in the new file.</b></p>
<p align="left"> <b>When the instructions say to install a corrected
firewall script in /usr/share/shorewall/firewall, you may
rename the existing file before copying in the new file.</b></p>
</li>
<li>
@ -80,8 +74,10 @@ For example, do NOT install the 1.3.9a firewall script if you are running
<ul>
<li><b><a href="upgrade_issues.htm">Upgrade Issues</a></b></li>
<li> <b><a href="#V1.3">Problems
in Version 1.3</a></b></li>
<li><b><a href="#V1.4">Problems in Version 1.4</a></b><br>
</li>
<li> <b><a
href="errata_3.html">Problems in Version 1.3</a></b></li>
<li> <b><a
href="errata_2.htm">Problems in Version 1.2</a></b></li>
<li> <b><font
@ -96,421 +92,19 @@ RedHat iptables</a></b></li>
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables
version 1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10 and
NAT</a></b><br>
<li><b><a href="#NAT">Problems with RH Kernel 2.4.18-10
and NAT</a></b><br>
</li>
</ul>
<hr>
<h2 align="left"><a name="V1.3"></a>Problems in Version 1.3</h2>
<h2 align="left"><a name="V1.4"></a>Problems in Version 1.4</h2>
<h3>Version 1.3.13</h3>
<ul>
<li>The 'shorewall add' command produces an error message referring
to 'find_interfaces_by_maclist'.</li>
<li>The 'shorewall delete' command can leave behind undeleted rules.</li>
<li>The 'shorewall add' command can fail with "iptables: Index of insertion
too big".<br>
</li>
</ul>
All three problems are corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.13/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.<br>
<ul>
<li>VLAN interface names of the form "eth<i>n</i>.<i>m</i>" (e.g., eth0.1)
are not supported in this version or in 1.3.12. If you need such support,
post on the users list and I can provide you with a patched version.<br>
</li>
</ul>
<h3>Version 1.3.12</h3>
<ul>
<li>If RFC_1918_LOG_LEVEL is set to anything but ULOG, the effect is
the same as if RFC_1918_LOG_LEVEL=info had been specified. The problem
is corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.12/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.</li>
<li>VLAN interface names of the form "eth<i>n</i>.<i>m</i>" (e.g., eth0.1)
are not supported in this version or in 1.3.13. If you need such support,
post on the users list and I can provide you with a patched version.<br>
</li>
</ul>
<h3>Version 1.3.12 LRP</h3>
<ul>
<li>The .lrp was missing the /etc/shorewall/routestopped file -- a
new lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.<br>
</li>
</ul>
<h3>Version 1.3.11a</h3>
<ul>
<li><a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/rfc1918">This
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of 82.0.0.0/8.<br>
</li>
</ul>
<h3>Version 1.3.11</h3>
<ul>
<li>When installing/upgrading using the .rpm, you may receive
the following warnings:<br>
<br>
     user teastep does not exist - using root<br>
     group teastep does not exist - using root<br>
<br>
These warnings are harmless and may be ignored. Users downloading
the .rpm from shorewall.net or mirrors should no longer see these warnings
as the .rpm you will get from there has been corrected.</li>
<li>DNAT rules that exclude a source subzone (SOURCE column contains
! followed by a sub-zone list) result in an error message and Shorewall
fails to start.<br>
<br>
Install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/firewall">this
corrected script</a> in /usr/lib/shorewall/firewall to correct this problem.
Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
<br>
This problem is corrected in version 1.3.11a.<br>
</li>
</ul>
<h3>Version 1.3.10</h3>
<ul>
<li>If you experience problems connecting to a PPTP server running
on your firewall and you have a 'pptpserver' entry in /etc/shorewall/tunnels,
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.10/firewall">this
version of the firewall script</a> may help. Please report any cases
where installing this script in /usr/lib/shorewall/firewall solved your
connection problems. Beginning with version 1.3.10, it is safe to save
the old version of /usr/lib/shorewall/firewall before copying in the
new one since /usr/lib/shorewall/firewall is the real script now and
not just a symbolic link to the real script.<br>
</li>
</ul>
<h3>Version 1.3.9a</h3>
<ul>
<li> If entries are used in /etc/shorewall/hosts and MERGE_HOSTS=No
then the following message appears during "shorewall [re]start":</li>
</ul>
<pre> recalculate_interfacess: command not found<br></pre>
<blockquote> The updated firewall script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
corrects this problem.Copy the script to /usr/lib/shorewall/firewall
as described above.<br>
</blockquote>
<blockquote> Alternatively, edit /usr/lob/shorewall/firewall and change the
single occurence (line 483 in version 1.3.9a) of 'recalculate_interefacess'
to 'recalculate_interface'. <br>
</blockquote>
<ul>
<li>The installer (install.sh) issues a misleading message
"Common functions installed in /var/lib/shorewall/functions" whereas
the file is installed in /usr/lib/shorewall/functions. The installer
also performs incorrectly when updating old configurations that had the
file /etc/shorewall/functions. <a
href="ftp://ftp.shorewall.net/pub/shorewall/errata/1.3.9/install.sh">Here
is an updated version that corrects these problems.<br>
</a></li>
</ul>
<h3>Version 1.3.9</h3>
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated firewall
script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
-- copy that file to /usr/lib/shorewall/firewall as described above.<br>
<br>
Version 1.3.8
<ul>
<li> Use of shell variables in the LOG LEVEL or SYNPARMS
columns of the policy file doesn't work.</li>
<li>A DNAT rule with the same original and new IP addresses
but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24
tcp 25 - 10.1.1.1")<br>
</li>
</ul>
Installing <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.8/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects these
problems.
<h3>Version 1.3.7b</h3>
<p>DNAT rules where the source zone is 'fw' ($FW)
result in an error message. Installing
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects this
problem.</p>
<h3>Version 1.3.7a</h3>
<p>"shorewall refresh" is not creating the proper
rule for FORWARDPING=Yes. Consequently, after
"shorewall refresh", the firewall will not forward
icmp echo-request (ping) packets. Installing
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
this corrected firewall script</a> in /var/lib/shorewall/firewall
as described above corrects this
problem.</p>
<h3>Version &lt;= 1.3.7a</h3>
<p>If "norfc1918" and "dhcp" are both specified as
options on a given interface then RFC 1918
checking is occurring before DHCP checking. This
means that if a DHCP client broadcasts using an
RFC 1918 source address, then the firewall will
reject the broadcast (usually logging it). This
has two problems:</p>
<ol>
<li>If the firewall is
running a DHCP server, the client
won't be able to obtain an IP address
lease from that server.</li>
<li>With this order of
checking, the "dhcp" option cannot
be used as a noise-reduction measure
where there are both dynamic and static
clients on a LAN segment.</li>
</ol>
<p> <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.7/firewall">
This version of the 1.3.7a firewall script </a>
corrects the problem. It must be installed
in /var/lib/shorewall as described
above.</p>
<h3>Version 1.3.7</h3>
<p>Version 1.3.7 dead on arrival -- please use
version 1.3.7a and check your version against
these md5sums -- if there's a difference, please
download again.</p>
<pre> d2fffb7fb99bcc6cb047ea34db1df10 shorewall-1.3.7a.tgz<br> 6a7fd284c8685b2b471a2f47b469fb94 shorewall-1.3.7a-1.noarch.rpm<br> 3decd14296effcff16853106771f7035 shorwall-1.3.7a.lrp</pre>
<p>In other words, type "md5sum &lt;<i>whatever package you downloaded</i>&gt;
and compare the result with what you see above.</p>
<p>I'm embarrassed to report that 1.2.7 was also DOA -- maybe I'll skip the
.7 version in each sequence from now on.</p>
<h3 align="left">Version 1.3.6</h3>
<ul>
<li>
<p align="left">If ADD_SNAT_ALIASES=Yes is specified in /etc/shorewall/shorewall.conf,
an error occurs when the firewall script attempts to
add an SNAT alias. </p>
</li>
<li>
<p align="left">The <b>logunclean </b>and <b>dropunclean</b> options
cause errors during startup when Shorewall is run with iptables
1.2.7. </p>
</li>
</ul>
<p align="left">These problems are fixed in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.6/firewall">
this correct firewall script</a> which must be installed in
/var/lib/shorewall/ as described above. These problems are also
corrected in version 1.3.7.</p>
<h3 align="left">Two-interface Samples 1.3.6 (file two-interfaces.tgz)</h3>
<p align="left">A line was inadvertently deleted from the "interfaces
file" -- this line should be added back in if the version that you
downloaded is missing it:</p>
<p align="left">net    eth0    detect    routefilter,dhcp,norfc1918</p>
<p align="left">If you downloaded two-interfaces-a.tgz then the above
line should already be in the file.</p>
<h3 align="left">Version 1.3.5-1.3.5b</h3>
<p align="left">The new 'proxyarp' interface option doesn't work :-(
This is fixed in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5/firewall">
this corrected firewall script</a> which must be installed in
/var/lib/shorewall/ as described above.</p>
<h3 align="left">Versions 1.3.4-1.3.5a</h3>
<p align="left">Prior to version 1.3.4, host file entries such as the
following were allowed:</p>
<div align="left">
<pre> adm eth0:1.2.4.5,eth0:5.6.7.8</pre>
</div>
<div align="left">
<p align="left">That capability was lost in version 1.3.4 so that it is only
possible to  include a single host specification on each line.
This problem is corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5a/firewall">this
modified 1.3.5a firewall script</a>. Install the script in /var/lib/pub/shorewall/firewall
as instructed above.</p>
</div>
<div align="left">
<p align="left">This problem is corrected in version 1.3.5b.</p>
</div>
<h3 align="left">Version 1.3.5</h3>
<p align="left">REDIRECT rules are broken in this version. Install
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5/firewall">
this corrected firewall script</a> in /var/lib/pub/shorewall/firewall
as instructed above. This problem is corrected in version
1.3.5a.</p>
<h3 align="left">Version 1.3.n, n &lt; 4</h3>
<p align="left">The "shorewall start" and "shorewall restart" commands
to not verify that the zones named in the /etc/shorewall/policy
file have been previously defined in the /etc/shorewall/zones
file. The "shorewall check" command does perform this verification
so it's a good idea to run that command after you have made configuration
changes.</p>
<h3 align="left">Version 1.3.n, n &lt; 3</h3>
<p align="left">If you have upgraded from Shorewall 1.2 and after
"Activating rules..." you see the message: "iptables: No chains/target/match
by that name" then you probably have an entry in /etc/shorewall/hosts
that specifies an interface that you didn't include in
/etc/shorewall/interfaces. To correct this problem, you
must add an entry to /etc/shorewall/interfaces. Shorewall 1.3.3
and later versions produce a clearer error message in this
case.</p>
<h3 align="left">Version 1.3.2</h3>
<p align="left">Until approximately 2130 GMT on 17 June 2002, the
download sites contained an incorrect version of the .lrp file. That
file can be identified by its size (56284 bytes). The correct
version has a size of 38126 bytes.</p>
<ul>
<li>The code to detect a duplicate interface
entry in /etc/shorewall/interfaces contained a typo that prevented
it from working correctly. </li>
<li>"NAT_BEFORE_RULES=No" was broken; it behaved
just like "NAT_BEFORE_RULES=Yes".</li>
</ul>
<p align="left">Both problems are corrected in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/firewall">
this script</a> which should be installed in <b><u>/var/lib/shorewall</u></b>
as described above.</p>
<ul>
<li>
<p align="left">The IANA have just announced the allocation of subnet
221.0.0.0/8. This <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.2/rfc1918">
updated rfc1918</a> file reflects that allocation.</p>
</li>
</ul>
<h3 align="left">Version 1.3.1</h3>
<ul>
<li>TCP SYN packets may be double counted
when LIMIT:BURST is included in a CONTINUE or ACCEPT policy
(i.e., each packet is sent through the limit chain twice).</li>
<li>An unnecessary jump to the policy chain
is sometimes generated for a CONTINUE policy.</li>
<li>When an option is given for more than
one interface in /etc/shorewall/interfaces then depending
on the option, Shorewall may ignore all but the first
appearence of the option. For example:<br>
<br>
net    eth0    dhcp<br>
loc    eth1    dhcp<br>
<br>
Shorewall will ignore the 'dhcp' on eth1.</li>
<li>Update 17 June 2002 - The bug described
in the prior bullet affects the following options: dhcp,
dropunclean, logunclean, norfc1918, routefilter, multi,
filterping and noping. An additional bug has been found
that affects only the 'routestopped' option.<br>
<br>
Users who downloaded the corrected script
prior to 1850 GMT today should download and install
the corrected script again to ensure that this second
problem is corrected.</li>
</ul>
<p align="left">These problems are corrected in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.1/firewall">
this firewall script</a> which should be installed in /etc/shorewall/firewall
as described above.</p>
<h3 align="left">Version 1.3.0</h3>
<ul>
<li>Folks who downloaded 1.3.0 from the links
on the download page before 23:40 GMT, 29 May 2002 may
have downloaded 1.2.13 rather than 1.3.0. The "shorewall
version" command will tell you which version that you
have installed.</li>
<li>The documentation NAT.htm file uses non-existent
wallpaper and bullet graphic files. The <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.0/NAT.htm">
corrected version is here</a>.</li>
</ul>
<hr>
<h3></h3>
None.
<hr width="100%" size="2">
<h2 align="left"><a name="Upgrade"></a>Upgrade Issues</h2>
<p align="left">The upgrade issues have moved to <a
@ -570,6 +164,7 @@ fine.</p>
and RedHat iptables</h3>
<blockquote>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
@ -613,8 +208,8 @@ installing <a
Shorewall 1.3.7a or later or:</p>
<ul>
<li>set MULTIPORT=No in
/etc/shorewall/shorewall.conf; or </li>
<li>set MULTIPORT=No
in /etc/shorewall/shorewall.conf; or </li>
<li>if you are running
Shorewall 1.3.6 you may install
<a
@ -635,8 +230,8 @@ Shorewall 1.3.6 you may install
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
The solution is to put "no" in the LOCAL column. Kernel support
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled it.
The 2.4.19 kernel contains corrected support under a new kernel configuraiton
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled
it. The 2.4.19 kernel contains corrected support under a new kernel configuraiton
option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
<p><font size="2"> Last updated 2/8/2003 -
@ -646,13 +241,5 @@ Shorewall 1.3.6 you may install
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

52
Shorewall-docs/mailing_list.htm
View File

@ -17,6 +17,7 @@
<title>Shorewall Mailing Lists</title>
<meta name="Microsoft Theme" content="none">
</head>
<body>
@ -29,6 +30,7 @@
<td width="33%" valign="middle" align="left">
<h1 align="center"><a
href="http://www.centralcommand.com/linux_products.html"><img
src="images/Vexira_Antivirus_Logo.gif" alt="Vexira Logo" width="78"
@ -71,8 +73,6 @@
</tbody>
</table>
<h2 align="left">Not getting List Mail? -- <a
href="mailing_list_problems.htm">Check Here</a></h2>
<p align="left">If you experience problems with any of these lists, please
let <a href="mailto:teastep@shorewall.net">me</a> know</p>
@ -96,8 +96,8 @@
(including <a href="http://razor.sourceforge.net/">Vipul's Razor</a>).<br>
</li>
<li>to ensure that the sender address is fully qualified.</li>
<li>to verify that the sender's domain has an A or MX record
in DNS.</li>
<li>to verify that the sender's domain has an A or MX
record in DNS.</li>
<li>to ensure that the host name in the HELO/EHLO command
is a valid fully-qualified DNS name that resolves.</li>
@ -106,13 +106,13 @@
<h2>Please post in plain text</h2>
A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse" because it has been my policy to allow HTML in list
posts!!<br>
"for continuous abuse" because it has been my policy to allow HTML in
list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control spam
and that the ultimate losers here are not the spammers but the list subscribers
whose MTAs are bouncing all shorewall.net mail. As one list subscriber
wrote to me privately "These e-mail admin's need to get a <i>(explitive
and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one list
subscriber wrote to me privately "These e-mail admin's need to get a <i>(explitive
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
@ -124,9 +124,9 @@ the list server.<br>
<h2>Other Mail Delivery Problems</h2>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> headers contain the names
of certain ISPs. Again, I believe that such policies hurt more than they
help but I'm not prepared to go so far as to start stripping <i>Received:</i>
admin may be blocking mail whose <i>Received:</i> headers contain the
names of certain ISPs. Again, I believe that such policies hurt more than
they help but I'm not prepared to go so far as to start stripping <i>Received:</i>
headers to circumvent those policies.<br>
<h2 align="left">Mailing Lists Archive Search</h2>
@ -164,9 +164,10 @@ the list server.<br>
value=""> <input type="submit" value="Search"> </p>
</form>
<h2 align="left"><font color="#ff0000">Please do not try to download the entire
Archive -- it is 75MB (and growing daily) and my slow DSL line simply won't
stand the traffic. If I catch you, you will be blacklisted.<br>
<h2 align="left"><font color="#ff0000">Please do not try to download the
entire Archive -- it is 75MB (and growing daily) and my slow DSL line simply
won't stand the traffic. If I catch you, you will be blacklisted.<br>
</font></h2>
<h2 align="left">Shorewall CA Certificate</h2>
@ -207,9 +208,9 @@ to this list.</p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
@ -261,8 +262,8 @@ list may be found at <a
the Mailing Lists</h2>
<p align="left">There seems to be near-universal confusion about unsubscribing
from Mailman-managed lists although Mailman 2.1 has attempted
to make this less confusing. To unsubscribe:</p>
from Mailman-managed lists although Mailman 2.1 has attempted to
make this less confusing. To unsubscribe:</p>
<ul>
<li>
@ -275,8 +276,8 @@ to make this less confusing. To unsubscribe:</p>
<p align="left">Down at the bottom of that page is the following text:
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a password
reminder, or change your subscription options enter your subscription
email address:". Enter your email address in the box and click
on the "<b>Unsubscribe</b> or edit options" button.</p>
email address:". Enter your email address in the box and
click on the "<b>Unsubscribe</b> or edit options" button.</p>
</li>
<li>
@ -293,12 +294,13 @@ to make this less confusing. To unsubscribe:</p>
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
<p align="left"><font size="2">Last updated 2/3/2003 - <a
<p align="left"><font size="2">Last updated 2/18/2003 - <a
href="http://www.shorewall.net/support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
</body>
</html>

190
Shorewall-docs/myfiles.htm
View File

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

71
Shorewall-docs/ping.html
View File

@ -24,14 +24,49 @@
</table>
<br>
Shorewall 'Ping' management has evolved over time with the latest change
coming in Shorewall version 1.3.14. In that version, a new option (<b>OLD_PING_HANDLING</b>)
was added to /etc/shorewall/shorewall.conf. The value of that option determines
the overall handling of ICMP echo requests (pings).<br>
coming in Shorewall version 1.4.0. <br>
<h2>Shorewall Versions &gt;= 1.4.0</h2>
In order to accept ping requests from zone z1 to zone z2 where the policy
for z1 to z2 is not ACCEPT, you need a rule in /etc/shoreall/rules of the
form:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example: <br>
<br>
To permit ping from the local zone to the firewall:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; loc&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
If you would like to accept 'ping' by default even when the relevant
policy is DROP or REJECT, create <b>/etc/shorewall/icmpdef </b>if it doesn't
already exist and in that file place the following command:<br>
<blockquote>
<pre><b><font color="#009900">run_iptables -A icmpdef -p icmp --icmp-type 8 -j ACCEPT<br></font></b></pre>
</blockquote>
With that rule in place, if you want to ignore 'ping' from z1 to z2 then
you need a rule of the form:<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
</i>icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
Example:<br>
<br>
To drop ping from the internet, you would need this rule in /etc/shorewall/rules:<br>
<br>
<blockquote>DROP&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; fw&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
</blockquote>
<h2>Shorewall Versions &gt;= 1.3.14 with OLD_PING_HANDLING=No in /etc/shorewall/shorewall.conf</h2>
In 1.3.14, Ping handling was put under control of the rules and policies
just like any other connection request. In order to accept ping requests from
zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need
just like any other connection request. In order to accept ping requests
from zone z1 to zone z2 where the policy for z1 to z2 is not ACCEPT, you need
a rule in /etc/shoreall/rules of the form:<br>
<blockquote>ACCEPT&nbsp;&nbsp;&nbsp; <i>z1&nbsp;&nbsp;&nbsp; z2&nbsp;&nbsp;&nbsp;
@ -74,8 +109,8 @@ icmp&nbsp;&nbsp;&nbsp; 8<br>
<ol>
<li>The <b>noping</b> and <b>filterping </b>interface options in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
<li>The <b>FORWARDPING</b> option in<a href="Documentation.htm#Conf">
/etc/shorewall/shorewall.conf</a>.</li>
<li>The <b>FORWARDPING</b> option in<a
href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf</a>.</li>
<li>Explicit rules in <a href="Documentation.htm#Rules">/etc/shorewall/rules</a>.</li>
</ol>
@ -83,9 +118,9 @@ icmp&nbsp;&nbsp;&nbsp; 8<br>
<ol>
<li>Ping requests addressed to the firewall itself; and</li>
<li>Ping requests being forwarded to another system. Included here are
all cases of packet forwarding including NAT, DNAT rule, Proxy ARP and simple
routing.</li>
<li>Ping requests being forwarded to another system. Included here
are all cases of packet forwarding including NAT, DNAT rule, Proxy ARP
and simple routing.</li>
</ol>
These cases will be covered separately.<br>
@ -113,8 +148,8 @@ ping request then the request is ignored.</li>
&nbsp;&nbsp;&nbsp; <i>Target&nbsp;&nbsp;&nbsp; Source&nbsp;&nbsp;&nbsp;
Destination&nbsp;&nbsp;&nbsp; </i>icmp&nbsp;&nbsp;&nbsp; 8<br>
<br>
Example 1. Accept pings from the net to the dmz (pings are responded to
with an ICMP echo-reply):<br>
Example 1. Accept pings from the net to the dmz (pings are responded
to with an ICMP echo-reply):<br>
<br>
&nbsp;&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; net&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; 8<br>
@ -125,12 +160,12 @@ with an ICMP echo-reply):<br>
icmp&nbsp;&nbsp;&nbsp; 8<br>
<h3>Policy Evaluation</h3>
If no applicable rule is found, then the policy for the source to the destination
is applied.<br>
If no applicable rule is found, then the policy for the source to the
destination is applied.<br>
<ol>
<li>If the relevant policy is ACCEPT then the request is responded to
with an ICMP echo-reply.</li>
<li>If the relevant policy is ACCEPT then the request is responded
to with an ICMP echo-reply.</li>
<li>If <b>FORWARDPING</b> is set to Yes in /etc/shorewall/shorewall.conf
then the request is responded to with an ICMP echo-reply.</li>
<li>Otherwise, the relevant REJECT or DROP policy is used and the request
@ -138,7 +173,7 @@ with an ICMP echo-reply.</li>
</ol>
<p><font size="2">Updated 1/21/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2">Updated 2/14/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> &copy; <font
@ -146,5 +181,7 @@ with an ICMP echo-reply.</li>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

242
Shorewall-docs/seattlefirewall_index.htm
View File

@ -9,13 +9,14 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<meta name="author" content="Tom Eastep">
</head>
<body>
@ -40,14 +41,16 @@
<h1 align="center"> <font size="4"><i> <a
href="http://www.cityofshoreline.com"> <img vspace="4" hspace="4"
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font></h1>
1.4 - <font size="4">"<i>iptables made
easy"</i></font></font></h1>
@ -58,8 +61,8 @@
<div align="center"><a
href="http://shorewall.sf.net/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a><br>
href="http://shorewall.sf.net/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a><br>
</div>
@ -73,6 +76,7 @@
</tbody>
</table>
@ -101,6 +105,7 @@
<h2 align="left">What is it?</h2>
@ -113,6 +118,7 @@
<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
@ -128,27 +134,30 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<p>This program is free software; you can redistribute it and/or modify
it under the terms of
<a href="http://www.gnu.org/licenses/gpl.html">Version 2 of
the GNU General Public License</a> as published by the Free Software
it under the terms
of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in the
hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.<br>
This program is distributed
in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy of
the GNU General Public License along
with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA
02139, USA</p>
You should have received a
copy of the GNU General Public License
along with this program; if not, write to the
Free Software Foundation, Inc., 675 Mass Ave,
Cambridge, MA 02139, USA</p>
@ -172,27 +181,30 @@ with this program; if not, write to the Free Software
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric Wolzak
have a LEAF (router/firewall/gateway on a floppy,
CD or compact flash) distribution called <i>Bering</i>
that features Shorewall-1.3.10 and Kernel-2.4.18.
You can find their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a>Jacques Nilo and
Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
Bering 1.1!!!</b><br>
</p>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
@ -208,6 +220,7 @@ Bering 1.0 Final!!! </b><br>
<h2>News</h2>
@ -229,108 +242,102 @@ Bering 1.0 Final!!! </b><br>
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
<p><b>3/14/2003 - Shorewall 1.4.0</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>New features include</p>
<p></p>
Shorewall 1.4 represents the next step in the evolution of Shorewall.
The main thrust of the initial release is simply to remove the cruft that
has accumulated in Shorewall over time. <br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
<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>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>Support for OpenVPN Tunnels.<br>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<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>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>  [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
<br>
</li>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.<br>
</li>
</ul>
<ol>
</ol>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in
/usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
</li>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard. See
<a href="http://www.webmin.com">http://www.webmin.com</a>.<b> </b>
</ol>
<p><b></b></p>
<p><b></b></p>
<ul>
</ul>
@ -338,6 +345,7 @@ on subnetworks that you don't wish to masquerade.<br>
<p><b></b><a href="News.htm">More News</a></p>
@ -350,12 +358,14 @@ on subnetworks that you don't wish to masquerade.<br>
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
valign="top" align="center"> <a
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <a
href="http://sourceforge.net">M</a></td>
</tr>
@ -364,6 +374,7 @@ on subnetworks that you don't wish to masquerade.<br>
</tbody>
</table>
@ -374,6 +385,7 @@ on subnetworks that you don't wish to masquerade.<br>
<table border="0" cellpadding="5" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber2"
bgcolor="#4b017c">
@ -382,7 +394,8 @@ on subnetworks that you don't wish to masquerade.<br>
<tr>
<td width="100%" style="margin-top: 1px;">
<td width="100%"
style="margin-top: 1px;">
@ -407,6 +420,7 @@ on subnetworks that you don't wish to masquerade.<br>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
to <a
@ -421,13 +435,15 @@ Children's Foundation.</font></a> Thanks!</font></p>
</tbody>
</table>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>

37
Shorewall-docs/shoreline.htm
View File

@ -47,8 +47,8 @@
<li>Burroughs Corporation (now <a
href="http://www.unisys.com">Unisys</a> ) 1969 - 1980</li>
<li><a href="http://www.tandem.com">Tandem Computers, Incorporated</a>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980
- present</li>
(now part of the <a href="http://www.hp.com">The New HP</a>) 1980 -
present</li>
<li>Married 1969 - no children.</li>
</ul>
@ -58,10 +58,10 @@
<p>I became interested in Internet Security when I established a home office
in 1999 and had DSL service installed in our home. I investigated
ipchains and developed the scripts which are now collectively known as
<a href="http://seawall.sourceforge.net"> Seattle Firewall</a>. Expanding
on what I learned from Seattle Firewall, I then designed and wrote
Shorewall. </p>
ipchains and developed the scripts which are now collectively known
as <a href="http://seawall.sourceforge.net"> Seattle Firewall</a>.
Expanding on what I learned from Seattle Firewall, I then designed
and wrote Shorewall. </p>
<p>I telework from our home in <a href="http://www.cityofshoreline.com">Shoreline,
Washington</a> where I live with my wife Tarry. </p>
@ -69,22 +69,22 @@
<p>Our current home network consists of: </p>
<ul>
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB &amp; 20GB
IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system. Serves
as a PPTP server for Road Warrior access. Dual boots <a
<li>1.2Gz Athlon, Windows XP Pro, 320MB RAM, 40GB &amp;
20GB IDE HDs and LNE100TX (Tulip) NIC - My personal Windows system.
Serves as a PPTP server for Road Warrior access. Dual boots <a
href="http://www.mandrakelinux.com">Mandrake</a> 9.0.</li>
<li>Celeron 1.4Gz, RH8.0, 384MB RAM, 60GB HD, LNE100TX(Tulip)
NIC - My personal Linux System which runs Samba configured as a
WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run both
<a href="http://www.debian.org">Debian Woody</a> and <a
NIC - My personal Linux System which runs Samba configured as
a WINS server. This system also has <a
href="http://www.vmware.com/">VMware</a> installed and can run
both <a href="http://www.debian.org">Debian Woody</a> and <a
href="http://www.suse.com">SuSE 8.1</a> in virtual machines.</li>
<li>K6-2/350, RH8.0, 384MB RAM, 8GB IDE HD, EEPRO100 NIC 
- Email (Postfix, Courier-IMAP and Mailman), HTTP (Apache), FTP (Pure_ftpd),
DNS server (Bind 9).</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3 LNE100TX 
(Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.3.14  and a DHCP
server.</li>
<li>PII/233, RH8.0, 256MB MB RAM, 2GB SCSI HD - 3
LNE100TX  (Tulip) and 1 TLAN NICs  - Firewall running Shorewall 1.4.0
Alpha 2  and a DHCP server.</li>
<li>Duron 750, Win ME, 192MB RAM, 20GB HD, RTL8139 NIC -
My wife's personal system.</li>
<li>PII/400 Laptop, WinXP SP1, 224MB RAM, 12GB HD, onboard
@ -93,8 +93,6 @@ My wife's personal system.</li>
</ul>
<p>For more about our network see <a href="myfiles.htm">my Shorewall Configuration</a>.</p>
<p>All of our other systems are made by <a
href="http://www.compaq.com">Compaq</a> (part of the new <a
href="http://www.hp.com/">HP</a>).. All of our Tulip NICs are <a
@ -116,11 +114,12 @@ My wife's personal system.</li>
width="125" height="40" hspace="4">
</font></p>
<p><font size="2">Last updated 1/24/2003 - </font><font size="2"> <a
<p><font size="2">Last updated 2/18/2003 - </font><font size="2"> <a
href="support.htm">Tom Eastep</a></font> </p>
<font face="Trebuchet MS"><a href="copyright.htm"><font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas
M. Eastep.</font></a></font><br>
<br>
<br>
</body>
</html>

29
Shorewall-docs/shorewall_extension_scripts.htm
View File

@ -41,7 +41,8 @@ placed in /etc/shorewall and are processed using the Bourne shell "source"
mechanism. The following scripts can be supplied:</p>
<ul>
<li>init -- invoked early in "shorewall start" and "shorewall restart"</li>
<li>init -- invoked early in "shorewall start" and "shorewall
restart"</li>
<li>start -- invoked after the firewall has been started or restarted.</li>
<li>stop -- invoked as a first step when the firewall is being stopped.</li>
<li>stopped -- invoked after the firewall has been stopped.</li>
@ -58,10 +59,11 @@ chain has been created but before any rules have been added to it.</li>
<p><u><b>If your version of Shorewall doesn't have the file that you want
to use from the above list, you can simply create the file yourself.</b></u></p>
<p> You can also supply a script with the same name as any of the filter
chains in the firewall and the script will be invoked after the /etc/shorewall/rules
file has been processed but before the /etc/shorewall/policy file has been
processed.</p>
file has been processed but before the /etc/shorewall/policy file has
been processed.</p>
@ -84,8 +86,8 @@ for making your own customized file.</p>
<p> If you decide to create /etc/shorewall/common it is a good idea to
use the following technique</p>
<p> If you decide to create /etc/shorewall/common it is a good idea to use
the following technique</p>
@ -113,21 +115,12 @@ if the policy is ACCEPT or CONTINUE.</p>
<p>If you set ALLOWRELATED=No in shorewall.conf, then most ICMP packets will
be rejected by the firewall. It is recommended with this setting that you
create the file /etc/shorewall/icmpdef and in it place the following commands:</p>
<pre> run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT<br> run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT<br></pre>
<p align="left"><font size="2">Last updated 12/22/2002 - <a
<p align="left"><font size="2">Last updated 2/18/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002 Thomas
M. Eastep</font></a></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
</body>
</html>

38
Shorewall-docs/shorewall_quickstart_guide.htm
View File

@ -34,8 +34,8 @@
</tbody>
</table>
<p align="center">With thanks to Richard who reminded me once again that we
must all first walk before we can run.<br>
<p align="center">With thanks to Richard who reminded me once again that
we must all first walk before we can run.<br>
The French Translations are courtesy of Patrice Vetsel<br>
</p>
@ -63,12 +63,12 @@ and a DMZ. (<a href="three-interface_fr.html">Version Fran
<p>The <a href="shorewall_setup_guide.htm">Shorewall Setup Guide</a> outlines
the steps necessary to set up a firewall where <b>there are multiple
public IP addresses involved or if you want to learn more about Shorewall
than is explained in the single-address guides above.</b></p>
public IP addresses involved or if you want to learn more about
Shorewall than is explained in the single-address guides above.</b></p>
<ul>
<li><a href="shorewall_setup_guide.htm#Introduction">1.0
Introduction</a></li>
<li><a
href="shorewall_setup_guide.htm#Introduction">1.0 Introduction</a></li>
<li><a href="shorewall_setup_guide.htm#Concepts">2.0
Shorewall Concepts</a></li>
<li><a href="shorewall_setup_guide.htm#Interfaces">3.0
@ -97,8 +97,8 @@ RFC 1918</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Options">5.0 Setting
up your Network</a>
<li><a href="shorewall_setup_guide.htm#Options">5.0
Setting up your Network</a>
<ul>
<li><a href="shorewall_setup_guide.htm#Routed">5.1
@ -118,8 +118,8 @@ Routed</a></li>
SNAT</a></li>
<li><a href="shorewall_setup_guide.htm#DNAT">5.2.2
DNAT</a></li>
<li><a href="shorewall_setup_guide.htm#ProxyARP">5.2.3
Proxy ARP</a></li>
<li><a
href="shorewall_setup_guide.htm#ProxyARP">5.2.3 Proxy ARP</a></li>
<li><a href="shorewall_setup_guide.htm#NAT">5.2.4
Static NAT</a></li>
@ -127,7 +127,8 @@ Static NAT</a></li>
</ul>
</li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3 Rules</a></li>
<li><a href="shorewall_setup_guide.htm#Rules">5.3
Rules</a></li>
<li><a
href="shorewall_setup_guide.htm#OddsAndEnds">5.4 Odds and Ends</a></li>
@ -170,8 +171,8 @@ files</a></li>
href="configuration_file_basics.htm#Continuation">Line Continuation</a></li>
<li><a href="configuration_file_basics.htm#Ports">Port
Numbers/Service Names</a></li>
<li><a href="configuration_file_basics.htm#Ranges">Port
Ranges</a></li>
<li><a
href="configuration_file_basics.htm#Ranges">Port Ranges</a></li>
<li><a
href="configuration_file_basics.htm#Variables">Using Shell Variables</a></li>
<li><a
@ -181,8 +182,8 @@ files</a></li>
href="configuration_file_basics.htm#Compliment">Complementing an IP address
or Subnet</a></li>
<li><a
href="configuration_file_basics.htm#Configs">Shorewall Configurations
(making a test configuration)</a></li>
href="configuration_file_basics.htm#Configs">Shorewall Configurations (making
a test configuration)</a></li>
<li><a href="configuration_file_basics.htm#MAC">Using
MAC Addresses in Shorewall</a></li>
@ -227,8 +228,8 @@ files</a></li>
</li>
<li><a href="dhcp.htm">DHCP</a></li>
<li><font color="#000099"><a
href="shorewall_extension_scripts.htm">Extension Scripts</a></font>
(How to extend Shorewall without modifying Shorewall code)</li>
href="shorewall_extension_scripts.htm">Extension Scripts</a></font> (How
to extend Shorewall without modifying Shorewall code)</li>
<li><a href="fallback.htm">Fallback/Uninstall</a></li>
<li><a href="shorewall_firewall_structure.htm">Firewall
Structure</a></li>
@ -238,8 +239,6 @@ Configuration</a></font></li>
</li>
<li><a href="MAC_Validation.html">MAC Verification</a><br>
</li>
<li><a href="myfiles.htm">My Configuration Files</a> (How I personally
use Shorewall)</li>
<li><a href="ping.html">'Ping' Management</a><br>
</li>
<li><a href="ports.htm">Port Information</a>
@ -298,5 +297,6 @@ List Creation</a></li>
<br>
<br>
<br>
<br>
</body>
</html>

228
Shorewall-docs/shorewall_setup_guide.htm
View File

@ -80,11 +80,12 @@ for this program:</p>
.</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 with Shorewall. Similarly,
if you copy a configuration file from your Windows hard drive to a floppy
disk, you must run dos2unix against the copy before using it with Shorewall.</p>
    If you edit your configuration files on a Windows system, you
must save them as Unix files if your editor supports that option or you
must run them through dos2unix before trying to use them with Shorewall.
Similarly, if you copy a configuration file from your Windows hard drive
to a floppy disk, you must run dos2unix against the copy before using
it with Shorewall.</p>
<ul>
<li><a href="http://www.simtel.net/pub/pd/51438.html">Windows Version
@ -106,8 +107,8 @@ in this guide. Skeleton files are created during the <a
and some contain default entries.</p>
<p>Shorewall views the network where it is running as being composed of a
set of <i>zones.</i> In the default installation, the following zone names
are used:</p>
set of <i>zones.</i> In the default installation, the following zone
names are used:</p>
<table border="0" style="border-collapse: collapse;" cellpadding="3"
cellspacing="0" id="AutoNumber2">
@ -136,9 +137,9 @@ in this guide. Skeleton files are created during the <a
file.</p>
<p>Shorewall also recognizes the firewall system as its own zone - by default,
the firewall itself is known as <b>fw</b> but that may be changed in the
<a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a> file.
In this guide, the default name (<b>fw</b>) will be used.</p>
the firewall itself is known as <b>fw</b> but that may be changed in
the <a href="Documentation.htm#Configs">/etc/shorewall/shorewall.conf</a>
file. In this guide, the default name (<b>fw</b>) will be used.</p>
<p>With the exception of <b>fw</b>, Shorewall attaches absolutely no meaning
to zone names. Zones are entirely what YOU make of them. That means that
@ -171,8 +172,8 @@ to another zone in the<a href="Documentation.htm#Policy"> /etc/shorewall/pol
<ol>
<li> Identify the source zone.</li>
<li> Identify the destination zone.</li>
<li> If the POLICY from the client's zone to the server's zone
is what you want for this client/server pair, you need do nothing
<li> If the POLICY from the client's zone to the server's
zone is what you want for this client/server pair, you need do nothing
further.</li>
<li> If the POLICY is not what you want, then you must add
a rule. That rule is expressed in terms of the client's zone and
@ -183,10 +184,10 @@ the server's zone.</li>
<p> Just because connections of a particular type are allowed from zone
A to the firewall and are also allowed from the firewall to zone B <font
color="#ff6633"><b><u> DOES NOT mean that these connections are allowed
from zone A to zone B</u></b></font>. It rather means that you can have
a proxy running on the firewall that accepts a connection from zone A
and then establishes its own separate connection from the firewall to
zone B.</p>
from zone A to zone B</u></b></font>. It rather means that you can
have a proxy running on the firewall that accepts a connection from
zone A and then establishes its own separate connection from the firewall
to zone B.</p>
<p>For each connection request entering the firewall, the request is first
checked against the /etc/shorewall/rules file. If no rule in that file
@ -236,14 +237,15 @@ the request is first checked against the rules in /etc/shorewall/common.def.</
<p>The above policy will:</p>
<ol>
<li>allow all connection requests from your local network to the internet</li>
<li>allow all connection requests from your local network to the
internet</li>
<li>drop (ignore) all connection requests from the internet to your
firewall or local network and log a message at the <i>info</i> level
(<a href="shorewall_logging.html">here</a> is a description of log levels).</li>
<li>reject all other connection requests and log a message at the
<i>info</i> level. When a request is rejected, the firewall will
return an RST (if the protocol is TCP) or an ICMP port-unreachable packet
for other protocols.</li>
return an RST (if the protocol is TCP) or an ICMP port-unreachable
packet for other protocols.</li>
</ol>
@ -254,8 +256,8 @@ for other protocols.</li>
<h2 align="left"><a name="Interfaces"></a>3.0 Network Interfaces</h2>
<p align="left">For the remainder of this guide, we'll refer to the following
diagram. While it may not look like your own network, it can be used to
illustrate the important aspects of Shorewall configuration.</p>
diagram. While it may not look like your own network, it can be used
to illustrate the important aspects of Shorewall configuration.</p>
<p align="left">In this diagram:</p>
@ -266,7 +268,8 @@ that if one of those servers is compromised, you still have the firewall
between the compromised system and your local systems. </li>
<li>The Local Zone consists of systems Local 1, Local 2 and Local
3. </li>
<li>All systems from the ISP outward comprise the Internet Zone. </li>
<li>All systems from the ISP outward comprise the Internet Zone.
</li>
</ul>
@ -281,8 +284,8 @@ interface. This is done in the <a href="Documentation.htm#Interfaces">/etc/sh
<p align="left">The firewall illustrated above has three network interfaces.
Where Internet connectivity is through a cable or DSL "Modem", the <i>External
Interface</i> will be the Ethernet adapter that is connected to that "Modem"
(e.g., <b>eth0</b>)  <u>unless</u> you connect via <i><u>P</u>oint-to-<u>P</u>oint
Interface</i> will be the Ethernet adapter that is connected to that
"Modem" (e.g., <b>eth0</b>)  <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 ppp interface (e.g., <b>ppp0</b>). If you connect
@ -291,8 +294,9 @@ If you connect using ISDN, you external interface will be <b>ippp0.</b></p>
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then you
will want to set CLAMPMSS=yes in <a href="Documentation.htm#Conf"> /etc/shorewall/shorewall.conf.</a></p>
    If your external interface is <b>ppp0</b> or <b>ippp0 </b>then
you will want to set CLAMPMSS=yes in <a href="Documentation.htm#Conf">
/etc/shorewall/shorewall.conf.</a></p>
<p align="left">Your <i>Local Interface</i> will be an Ethernet adapter (eth0,
eth1 or eth2) and will be connected to a hub or switch. Your local computers
@ -308,10 +312,10 @@ a single DMZ system, you can connect the firewall directly to the computer
<p align="left"><u><b> <img border="0" src="images/j0213519.gif"
width="60" height="60">
</b></u>Do not connect more than one interface to the same hub or switch
(even for testing). It won't work the way that you expect it to and you
will end up confused and believing that Linux networking doesn't work at
all.</p>
</b></u>Do not connect more than one interface to the same hub or
switch (even for testing). It won't work the way that you expect it to
and you will end up confused and believing that Linux networking doesn't
work at all.</p>
<p align="left">For the remainder of this Guide, we will assume that:</p>
@ -367,11 +371,11 @@ all.</p>
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/interfaces file and define the network interfaces
on your firewall and associate each interface with a zone. If you have
a zone that is interfaced through more than one interface, simply include
one entry for each interface and repeat the zone name as many times as
necessary.</p>
    Edit the /etc/shorewall/interfaces file and define the network
interfaces on your firewall and associate each interface with a zone. If
you have a zone that is interfaced through more than one interface, simply
include one entry for each interface and repeat the zone name as many times
as necessary.</p>
<p align="left">Example:</p>
@ -495,11 +499,11 @@ value "w", the next byte has value "x", etc. If we take the address 192.0.2.14
<p align="left">The class of a network was uniquely determined by the value
of the high order byte of its address so you could look at an IP address
and immediately determine the associated <i>netmask</i>. The netmask is
a number that when logically ANDed with an address isolates the <i>network
and immediately determine the associated <i>netmask</i>. The netmask
is a number that when logically ANDed with an address isolates the <i>network
number</i>; the remainder of the address is the <i>host number</i>. For
example, in the Class C address 192.0.2.14, the network number is hex C00002
and the host number is hex 0E.</p>
example, in the Class C address 192.0.2.14, the network number is hex
C00002 and the host number is hex 0E.</p>
<p align="left">As the internet grew, it became clear that such a gross partitioning
of the 32-bit address space was going to be very limiting (early on, large
@ -533,9 +537,9 @@ to as
</ol>
<p align="left">As you can see by this definition, in each subnet of size
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that can
be assigned to hosts). The first and last address in the subnet are
used for the subnet address and subnet broadcast address respectively.
<b>n</b> there are (<b>n</b> - 2) usable addresses (addresses that
can be assigned to hosts). The first and last address in the subnet
are used for the subnet address and subnet broadcast address respectively.
Consequently, small subnetworks are more wasteful of IP addresses than
are large ones. </p>
@ -744,8 +748,8 @@ As we will see below, this property of subnet masks is very useful in
routing.</p>
<p align="left">For a subnetwork whose address is <b>a.b.c.d</b> and whose
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork as
"<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
Variable Length Subnet Mask is <b>/v</b>, we denote the subnetwork
as "<b>a.b.c.d/v</b>" using <i>CIDR</i> <i>Notation</i>.  </p>
<p align="left">Example:</p>
@ -825,7 +829,7 @@ to VLSM <b>/v</b>.</p>
<h3 align="left"><a name="Routing"></a>4.3 Routing</h3>
<p align="left">One of the purposes of subnetting is that it forms the basis
for routing. Here's the routing table on <a href="myfiles.htm">my firewall</a>:</p>
for routing. Here's the routing table on my firewall:</p>
<div align="left">
<blockquote>
@ -836,12 +840,13 @@ to VLSM <b>/v</b>.</p>
<p align="left">The device <i>texas</i> is a GRE tunnel to a peer site in
the Dallas, Texas area.<br>
<br>
The first three routes are <i>host routes</i> since they indicate how
to get to a single host. In the 'netstat' output this can be seen by the
"Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the Flags column.
The remainder are 'net' routes since they tell the kernel how to route
packets to a subnetwork. The last route is the <i>default route</i> and
the gateway mentioned in that route is called the <i>default gateway</i>.</p>
The first three routes are <i>host routes</i> since they indicate
how to get to a single host. In the 'netstat' output this can be seen
by the "Genmask" (Subnet Mask) of 255.255.255.255 and the "H" in the
Flags column. The remainder are 'net' routes since they tell the kernel
how to route packets to a subnetwork. The last route is the <i>default
route</i> and the gateway mentioned in that route is called the <i>default
gateway</i>.</p>
<p align="left">When the kernel is trying to send a packet to IP address
<b>A</b>, it starts at the top of the routing table and:</p>
@ -898,13 +903,13 @@ eth2.</p>
</div>
<p align="left">One more thing needs to be emphasized -- all outgoing packet
are sent using the routing table and reply packets are not a special case.
There seems to be a common mis-conception whereby people think that request
packets are like salmon and contain a genetic code that is magically transferred
to reply packets so that the replies follow the reverse route taken by
the request. That isn't the case; the replies may take a totally different
route back to the client than was taken by the requests -- they are totally
independent.</p>
are sent using the routing table and reply packets are not a special
case. There seems to be a common mis-conception whereby people think
that request packets are like salmon and contain a genetic code that
is magically transferred to reply packets so that the replies follow
the reverse route taken by the request. That isn't the case; the replies
may take a totally different route back to the client than was taken by
the requests -- they are totally independent.</p>
<h3 align="left"><a name="ARP"></a>4.4 Address Resolution Protocol</h3>
@ -948,8 +953,8 @@ with IP address 192.168.1.19 is 0:6:25:aa:8a:f0.</p>
<p align="left">In order to avoid having to exchange ARP information each
time that an IP packet is to be sent, systems maintain an <i>ARP cache</i>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your system
(including your Windows system) using the 'arp' command:</p>
of IP&lt;-&gt;MAC correspondences. You can see the ARP cache on your
system (including your Windows system) using the 'arp' command:</p>
<blockquote>
<div align="left">
@ -971,9 +976,9 @@ records the information we saw using tcpdump above.</p>
who delegates allocations on a geographic basis to <i>Regional Internet
Registries</i> (RIRs). For example, allocation for the Americas and for
sub-Sahara Africa is delegated to the <i><a href="http://www.arin.net">American
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn delegate
to national registries. Most of us don't deal with these registrars but
rather get our IP addresses from our ISP.</p>
Registry for Internet Numbers</a> </i>(ARIN). These RIRs may in turn
delegate to national registries. Most of us don't deal with these registrars
but rather get our IP addresses from our ISP.</p>
<p align="left">It's a fact of life that most of us can't afford as many
Public IP addresses as we have devices to assign them to so we end up making
@ -987,9 +992,9 @@ ranges for this purpose:</p>
<div align="left">
<p align="left">The addresses reserved by RFC 1918 are sometimes referred
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. This is understandable
given that anyone can select any of these addresses for their private
use.</p>
forward packets which have an RFC-1918 destination address. This is
understandable given that anyone can select any of these addresses
for their private use.</p>
</div>
<div align="left">
@ -1164,8 +1169,8 @@ IP addresses to set up our networks as shown in the preceding example
<div align="left">
<p align="left">Clearly, that set of addresses doesn't comprise a subnetwork
and there aren't enough addresses for all of the network interfaces.
There are four different techniques that can be used to work around this
problem.</p>
There are four different techniques that can be used to work around
this problem.</p>
</div>
<div align="left">
@ -1201,11 +1206,12 @@ these will be discussed in the sections that follow.</p>
<div align="left">
<p align="left">With SNAT, an internal LAN segment is configured using RFC
1918 addresses. When a host <b>A </b>on this internal segment initiates
a connection to host <b>B</b> on the internet, the firewall/router rewrites
the IP header in the request to use one of your public IP addresses
as the source address. When <b>B</b> responds and the response is received
by the firewall, the firewall changes the destination address back to
the RFC 1918 address of <b>A</b> and forwards the response back to <b>A.</b></p>
a connection to host <b>B</b> on the internet, the firewall/router
rewrites the IP header in the request to use one of your public IP
addresses as the source address. When <b>B</b> responds and the response
is received by the firewall, the firewall changes the destination address
back to the RFC 1918 address of <b>A</b> and forwards the response back
to <b>A.</b></p>
</div>
<div align="left">
@ -1282,9 +1288,10 @@ selected connections from the internet.</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
     Suppose that your daughter wants to run a web server on her system
"Local 3". You could allow connections to the internet to her server
by adding the following entry in <a href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
     Suppose that your daughter wants to run a web server on her
system "Local 3". You could allow connections to the internet to her
server by adding the following entry in <a
href="Documentation.htm#Rules">/etc/shorewall/rules</a>:</p>
</div>
<div align="left">
@ -1381,8 +1388,8 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<div align="left"> <img border="0" src="images/BD21298_2.gif"
width="13" height="13">
    The Shorewall configuration of Proxy ARP is done using the <a
href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
    The Shorewall configuration of Proxy ARP is done using the
<a href="Documentation.htm#ProxyArp">/etc/shorewall/proxyarp</a> file.</div>
<div align="left">
<blockquote>
@ -1417,9 +1424,10 @@ will respond (with the MAC if the firewall interface to <b>H</b>). </p>
<p align="left">Because the HAVE ROUTE column contains No, Shorewall will
add host routes thru eth2 to 192.0.2.177 and 192.0.2.178.<br>
</p>
<p align="left">The ethernet interfaces on DMZ 1 and DMZ 2 should be configured
to have the IP addresses shown but should have the same default gateway as
the firewall itself -- namely 192.0.2.254.<br>
to have the IP addresses shown but should have the same default gateway
as the firewall itself -- namely 192.0.2.254.<br>
</p>
</div>
@ -1440,27 +1448,27 @@ There are a couple of things that you can try:<br>
<li>(Courtesy of Bradey Honsinger) A reading of Stevens' <i>TCP/IP Illustrated,
Vol 1</i> reveals that a <br>
<br>
"gratuitous" ARP packet should cause the ISP's router to refresh their ARP
cache (section 4.7). A gratuitous ARP is simply a host requesting the MAC
address for its own IP; in addition to ensuring that the IP address isn't
"gratuitous" ARP packet should cause the ISP's router to refresh their
ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
MAC address for its own IP; in addition to ensuring that the IP address isn't
a duplicate,...<br>
<br>
"if the host sending the gratuitous ARP has just changed its hardware address...,
this packet causes any other host...that has an entry in its cache for the
old hardware address to update its ARP cache entry accordingly."<br>
"if the host sending the gratuitous ARP has just changed its hardware
address..., this packet causes any other host...that has an entry in its
cache for the old hardware address to update its ARP cache entry accordingly."<br>
<br>
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP (or
static NAT for that matter). Happily enough, recent versions of Redhat's iputils
package include "arping", whose "-U" flag does just that:<br>
static NAT for that matter). Happily enough, recent versions of Redhat's
iputils package include "arping", whose "-U" flag does just that:<br>
<br>
    <font color="#009900"><b>arping -U -I &lt;net if&gt; &lt;newly proxied
IP&gt;</b></font><br>
    <font color="#009900"><b>arping -U -I eth0 66.58.99.83 # for example</b></font><br>
<br>
Stevens goes on to mention that not all systems respond correctly to gratuitous
ARPs, but googling for "arping -U" seems to support the idea that it works
most of the time.<br>
Stevens goes on to mention that not all systems respond correctly to
gratuitous ARPs, but googling for "arping -U" seems to support the idea
that it works most of the time.<br>
<br>
</li>
<li>You can call your ISP and ask them to purge the stale ARP cache
@ -1498,8 +1506,8 @@ will assume is 130.252.100.254):</p>
different from the destination MAC address in the echo reply!! In this
case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
was the MAC address of DMZ 1. In other words, the gateway's ARP cache
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with the
firewall's eth0.</p>
still associates 192.0.2.177 with the NIC in DMZ 1 rather than with
the firewall's eth0.</p>
</div>
<div align="left">
@ -1509,9 +1517,10 @@ will assume is 130.252.100.254):</p>
<div align="left">
<p align="left">With static NAT, you assign local systems RFC 1918 addresses
then establish a one-to-one mapping between those addresses and public
IP addresses. For outgoing connections SNAT occurs and on incoming connections
DNAT occurs. Let's go back to our earlier example involving your daughter's
web server running on system Local 3.</p>
IP addresses. For outgoing connections SNAT (Source Network Address
Translation) occurs and on incoming connections DNAT (Destination Network
Address Translation) occurs. Let's go back to our earlier example involving
your daughter's web server running on system Local 3.</p>
</div>
<div align="left">
@ -1522,8 +1531,8 @@ will assume is 130.252.100.254):</p>
<div align="left">
<p align="left">Recall that in this setup, the local network is using SNAT
and is sharing the firewall external IP (192.0.2.176) for outbound connections.
This is done with the following entry in /etc/shorewall/masq:</p>
and is sharing the firewall external IP (192.0.2.176) for outbound
connections. This is done with the following entry in /etc/shorewall/masq:</p>
</div>
<div align="left">
@ -1550,8 +1559,8 @@ will assume is 130.252.100.254):</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Suppose now that you have decided to give your daughter her own
IP address (192.0.2.179) for both inbound and outbound connections.
    Suppose now that you have decided to give your daughter her
own IP address (192.0.2.179) for both inbound and outbound connections.
You would do that by adding an entry in <a
href="Documentation.htm#NAT">/etc/shorewall/nat</a>.</p>
</div>
@ -1589,10 +1598,10 @@ You would do that by adding an entry in <a
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Once the relationship between 192.0.2.179 and 192.168.201.4 is
established by the nat file entry above, it is no longer appropriate
to use a DNAT rule for you daughter's web server -- you would rather just
use an ACCEPT rule:</p>
    Once the relationship between 192.0.2.179 and 192.168.201.4
is established by the nat file entry above, it is no longer appropriate
to use a DNAT rule for you daughter's web server -- you would rather
just use an ACCEPT rule:</p>
</div>
<div align="left">
@ -1635,8 +1644,8 @@ use an ACCEPT rule:</p>
access any servers on the internet and the DMZ can't access any other
host (including the firewall). With the exception of <a
href="#DNAT">DNAT rules</a> which cause address translation and allow
the translated connection request to pass through the firewall, the way
to allow connection requests through your firewall is to use ACCEPT
the translated connection request to pass through the firewall, the
way to allow connection requests through your firewall is to use ACCEPT
rules.</p>
</div>
@ -2482,7 +2491,8 @@ and its interface to the dmz as dmz.foobar.net. Let's have the DNS server
<p align="left"><img border="0" src="images/BD21298_2.gif" width="13"
height="13">
    Edit the /etc/shorewall/routestopped file and configure those
systems that you want to be able to access the firewall when it is stopped.</p>
systems that you want to be able to access the firewall when it is
stopped.</p>
</div>
<div align="left">
@ -2496,7 +2506,7 @@ systems that you want to be able to access the firewall when it is stopped.
try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/13/2003 - <a
<p align="left"><font size="2">Last updated 2/18/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
@ -2506,5 +2516,7 @@ Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

250
Shorewall-docs/sourceforge_index.htm
View File

@ -9,13 +9,15 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
<title>Shoreline Firewall (Shorewall) 1.4</title>
<base target="_self">
<base
target="_self">
<meta name="author" content="Tom Eastep">
</head>
<body>
@ -30,7 +32,8 @@
<tr>
<td width="100%" height="90">
<td width="100%"
height="90">
@ -46,10 +49,10 @@
alt="Shorwall Logo" height="70" width="85" align="left"
src="images/washington.jpg" border="0">
</a></i></font><font color="#ffffff">Shorewall
1.3 - <font size="4">"<i>iptables
made easy"</i></font></font><a href="http://www.sf.net">
</a></h1>
</a></i></font><font
color="#ffffff">Shorewall 1.4 - <font size="4">"<i>iptables
made easy"</i></font></font><a
href="http://www.sf.net"> </a></h1>
@ -60,8 +63,10 @@
<div align="center"><a href="/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a></div>
<div align="center"><a href="/1.3/index.html" target="_top"><font
color="#ffffff">Shorewall 1.3 Site here</font></a></div>
</td>
</tr>
@ -97,6 +102,7 @@
<h2 align="left">What is it?</h2>
@ -111,9 +117,10 @@
<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>
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>
@ -127,27 +134,27 @@
<p>This program is free software; you can redistribute it and/or modify
it under the terms of
<a href="http://www.gnu.org/licenses/gpl.html">Version 2 of
the GNU General Public License</a> as published by the Free Software
it under the terms
of <a href="http://www.gnu.org/licenses/gpl.html">Version
2 of the GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed
in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License
WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR
A PARTICULAR PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a copy
of the GNU General Public License
along with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge,
MA 02139, USA</p>
You should have received
a copy of the GNU General Public License
along with this program; if not, write to
the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
@ -173,22 +180,24 @@ Software Foundation, Inc., 675 Mass Ave, Cambridge
<p> <a href="http://leaf.sourceforge.net" target="_top"><img
border="0" src="images/leaflogo.gif" width="49" height="36">
</a>Jacques Nilo and Eric
Wolzak have a LEAF (router/firewall/gateway on
a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.10
and Kernel-2.4.18. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.0 Final!!! <br>
</a>Jacques Nilo
and Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution
called <i>Bering</i> that features
Shorewall-1.3.14 and Kernel-2.4.20. You can find
their work at: <a
href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>
</b>
<b>Congratulations to Jacques and Eric
on the recent release of Bering 1.1!!!</b><br>
<h2>News</h2>
@ -204,99 +213,98 @@ a floppy, CD or compact flash) distribution called
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
<p><b>3/14/2003 - Shorewall 1.4.0</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>New features include</p>
Shorewall 1.4 represents the
next step in the evolution of Shorewall. The main thrust of the initial
release is simply to remove the cruft that has accumulated in Shorewall
over time. <br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules and
policies just like any other connection request. The FORWARDPING=Yes option
in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/interfaces
will all generate an error.<br>
<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>It is now possible to direct Shorewall to create a "label" such
as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
 <br>
   a) In the INTERFACE column of /etc/shorewall/masq<br>
   b) In the INTERFACE column of /etc/shorewall/nat<br>
 </li>
<li>Support for OpenVPN Tunnels.<br>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt;
in /etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<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>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in the
SUBNET column, shorewall will use the firewall's routing table to construct
the masquerading/SNAT rules.<br>
 <br>
Example 1 -- This is how it works in 1.3.14.<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>  [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an /etc/shorewall/masq
entry, your /etc/shorewall/masq file will need changing. In most cases,
you will simply be able to remove redundant entries. In some cases though,
you might want to change from using the interface name to listing specific
subnetworks if the change described above will cause masquerading to occur
on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<li>The 'routestopped' option in the /etc/shorewall/interfaces
and /etc/shorewall/hosts files is no longer supported and will generate an
error at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no
longer accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
<br>
</li>
<li value="8">The 'multi' interface option is no longer supported.
 Shorewall will generate rules for sending packets back out the same interface
that they arrived on in two cases:</li>
</ol>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard.
See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</b>
<p><b></b></p>
<ul>
<li>There is an <u>explicit</u> policy for the source zone to or
from the destination zone. An explicit policy names both zones and does not
use the 'all' reserved word.</li>
<li>There are one or more rules for traffic for the source zone to
or from the destination zone including rules that use the 'all' reserved
word. Exception: if the source zone and destination zone are the same then
the rule must be explicit - it must name the zone in both the SOURCE and
DESTINATION columns.</li>
</ul>
<ul>
</ul>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely
reorganized into logical sections.<br>
<br>
</li>
<li>LOG and CONTINUE are now a valid actions for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in
/usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the
common chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.<br>
<br>
</li>
<li>802.11b devices with names of the form wlan<i>&lt;n&gt;</i> now
support the 'maclist' option.<br>
<br>
</li>
</ol>
<p></p>
<b> </b>
@ -313,6 +321,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
</ul>
@ -321,6 +330,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<p><a href="News.htm">More News</a></p>
@ -334,12 +344,14 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h2> </h2>
<h1 align="center"><a href="http://www.sf.net"><img align="left"
alt="SourceForge Logo"
src="http://sourceforge.net/sflogo.php?group_id=22587&amp;type=3">
@ -349,12 +361,14 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<h4> </h4>
<h2>This site is hosted by the generous folks at <a
href="http://www.sf.net">SourceForge.net</a> </h2>
@ -409,6 +423,7 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
@ -425,11 +440,12 @@ See <a href="http://www.webmin.com">http://www.webmin.com</a> <b>
<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>
@ -447,7 +463,7 @@ Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>

23
Shorewall-docs/spam_filters.htm
View File

@ -28,35 +28,42 @@
</table>
<h1 align="center"><br>
<a href="http://ordb.org"> <a href="http://www.spamassassin.org"><img
<a href="http://ordb.org"> </a><a href="http://www.spamassassin.org"><img
src="images/ninjalogo.png" alt="(SpamAssassin Logo)" width="100"
height="38">
</a><img border="0" src="images/but3.png" hspace="3" width="88"
height="31">
</a></h1>
</h1>
<p>Like all of you, I'm concerned about the increasing volume of Unsolicited
Commercial Email (UCE or SPAM). I am therefore sympathetic with those of
you who are installing SPAM filters on your mail servers. A couple of recent
incidents involving mis-configured filters have prompted me to establish
this page to spell out what I will do when these filters bounce list postings.</p>
incidents involving mis-configured filters have prompted me to establish this
page to spell out what I will do when these filters bounce list postings.</p>
<p>When your SPAM filter bounces/rejects list mail, I will:</p>
<p>When your SPAM filter bounces/rejects list mail <b>and I can identify
who you are</b>, I will:</p>
<ol>
<li>immediately turn off delivery to you from all Shorewall lists to which
you subscribe.</li>
<li>immediately turn off delivery to you from all Shorewall lists to
which you subscribe.</li>
<li><u>try</u> to send you an email from a source other than shorewall.net</li>
</ol>
<p>When you have corrected the problem, please let me know and I will re-enable
delivery (or you can reenable delivery yourself).</p>
delivery (or you can reenable delivery yourself).<br>
</p>
<p>Note that many brain-dead spam filters inform the sender that a post was
rejected as spam but fail to provide any clue about the original addressee!!!
If I don't know who you are, I can't tell you about the problem...<br>
</p>
<p><font size="2">Last Updated 1/29/2003 - Tom Eastep</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
</body>
</html>

29
Shorewall-docs/starting_and_stopping_shorewall.htm
View File

@ -62,8 +62,8 @@ graphical run-level editor.</p>
<ol>
<li>Shorewall startup is disabled by default. Once you have configured
your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.
Note: Users of the .deb package must edit /etc/default/shorewall and set
'startup=1'.<br>
Note: Users of the .deb package must edit /etc/default/shorewall and
set 'startup=1'.<br>
</li>
<li>If you use dialup, you may want to start the firewall in
your /etc/ppp/ip-up.local script. I recommend just placing "shorewall
@ -102,8 +102,8 @@ shell trace of the command is produced as in:<br>
<p>The above command would trace the 'start' command and place the trace information
in the file /tmp/trace<br>
<p>The above command would trace the 'start' command and place the trace
information in the file /tmp/trace<br>
</p>
<p>The <a href="#StateDiagram">Shorewall State Diagram</a> is shown at the
@ -123,8 +123,8 @@ in the file /tmp/trace<br>
<li>shorewall show tos - produce a verbose report about the mangle
table (iptables -t mangle -L -n -v)</li>
<li>shorewall show log - display the last 20 packet log entries.</li>
<li>shorewall show connections - displays the IP connections currently
being tracked by the firewall.</li>
<li>shorewall show connections - displays the IP connections
currently being tracked by the firewall.</li>
<li>shorewall
show
tc - displays information
@ -223,8 +223,8 @@ zone.</li>
<p> If the configuration starts but doesn't work, just "shorewall restart"
to restore the old configuration. If the new configuration fails to start,
the "try" command will automatically start the old one for you.</p>
to restore the old configuration. If the new configuration fails to
start, the "try" command will automatically start the old one for you.</p>
@ -249,8 +249,8 @@ zone.</li>
<p><a name="StateDiagram"></a>The Shorewall State Diargram is depicted below.<br>
</p>
<div align="center"><img
src="file:///J:/Shorewall-docs/images/State_Diagram.png"
<div align="center"><img src="images/State_Diagram.png"
alt="(State Diagram)" width="747" height="714" align="middle">
<br>
</div>
@ -258,9 +258,9 @@ zone.</li>
<p>  <br>
</p>
You will note that the commands that result in state transitions use
the word "firewall" rather than "shorewall". That is because the actual
transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall
on Debian); /sbin/shorewall runs 'firewall" according to the following table:<br>
the word "firewall" rather than "shorewall". That is because the actual transitions
are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall on
Debian); /sbin/shorewall runs 'firewall" according to the following table:<br>
<br>
<table cellpadding="2" cellspacing="2" border="1">
@ -314,7 +314,7 @@ on Debian); /sbin/shorewall runs 'firewall" according to the following table:<b
</table>
<br>
<p><font size="2"> Updated 1/29/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 2/10/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -331,5 +331,6 @@ on Debian); /sbin/shorewall runs 'firewall" according to the following table:<b
<br>
<br>
<br>
<br>
</body>
</html>

81
Shorewall-docs/support.htm
View File

@ -54,6 +54,7 @@
<i>"Well at least you tried to read the documentation, which is a lot more
than some people on this list appear to do.</i>"<br>
<br>
<div align="center">- Wietse Venema - On the Postfix mailing list<br>
</div>
<br>
@ -97,8 +98,8 @@ problem solution information. Please try these before you post.
<ul>
<li> The Mailing List
Archives search facility can locate posts about similar problems:
</li>
Archives search facility can locate posts about similar
problems: </li>
</ul>
@ -147,39 +148,40 @@ Archives search facility can locate posts about similar problem
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed
at the range and variety of smells we could come up with. Even more
amazing is that all of the explanations for the smells would be completely
plausible."<br>
smell and even what's causing it. You would be absolutely amazed at
the range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely plausible."<br>
</i><br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
</div>
<br>
<h3> </h3>
<ul>
<li>Please remember we only know what is posted in your message.
Do not leave out any information that appears to be correct, or was mentioned
in a previous post. There have been countless posts by people who were
sure that some part of their configuration was correct when it actually
contained a small error. We tend to be skeptics where detail is lacking.<br>
Do not leave out any information that appears to be correct, or was
mentioned in a previous post. There have been countless posts by people
who were sure that some part of their configuration was correct when
it actually contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
<li>Please keep in mind that you're asking for <strong>free</strong>
technical support. Any help we offer is an act of generosity, not an obligation.
Try to make it easy for us to help you. Follow good, courteous practices
in writing and formatting your e-mail. Provide details that we need if
you expect good answers. <em>Exact quoting </em> of error messages, log
entries, command output, and other output is better than a paraphrase or
summary.<br>
technical support. Any help we offer is an act of generosity, not an
obligation. Try to make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. <em>Exact quoting </em> of error messages,
log entries, command output, and other output is better than a paraphrase
or summary.<br>
<br>
</li>
<li> Please don't describe your
environment and then ask us to send you custom configuration
files. We're here to answer your questions but we can't
do your job for you.<br>
<li> Please don't describe
your environment and then ask us to send you custom
configuration files. We're here to answer your questions but
we can't do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
@ -235,8 +237,8 @@ this information:</li>
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart Guides, please
indicate which one. <br>
<li>If you installed Shorewall using one of the QuickStart Guides,
please indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the Mandrake
@ -250,8 +252,8 @@ installation of Shorewall, please say so.</b><br>
<ul>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, if you are having connection
problems of any kind, post the exact output of<br>
color="#009900">iptables -L</font></b>". Instead, <b>if you are having
connection problems of any kind</b>, post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
@ -283,18 +285,18 @@ your post<br>
<h3> </h3>
<ul>
<li> Do you see any "Shorewall"
messages ("<b><font color="#009900">/sbin/shorewall show log</font></b>")
when you exercise the function that is giving you problems? If
so, include the message(s) in your post along with a copy of your /etc/shorewall/interfaces
file.<br>
<li> Do you see any
"Shorewall" messages ("<b><font color="#009900">/sbin/shorewall show
log</font></b>") when you exercise the function that is giving
you problems? If so, include the message(s) in your post along with a
copy of your /etc/shorewall/interfaces file.<br>
<br>
</li>
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies). </li>
please include /etc/shorewall/policy as well (rules are meaningless
unless one also knows the policies). </li>
</ul>
@ -339,13 +341,13 @@ when you try to "<font color="#009900"><b>shorewall start</b></font>",
list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the
list subscribers whose MTAs are bouncing all shorewall.net mail. As
one list subscriber wrote to me privately "These e-mail admin's need
to get a <i>(expletive deleted)</i> life instead of trying to rid the
planet of HTML based e-mail". Nevertheless, to allow subscribers to receive
list posts as must as possible, I have now configured the list server
at shorewall.net to strip all HTML from outgoing posts.<br>
spam and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one
list subscriber wrote to me privately "These e-mail admin's need to get
a <i>(expletive deleted)</i> life instead of trying to rid the planet
of HTML based e-mail". Nevertheless, to allow subscribers to receive list
posts as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts.<br>
<h2>Where to Send your Problem Report or to Ask for Help</h2>
@ -373,7 +375,7 @@ at shorewall.net to strip all HTML from outgoing posts.<br>
.</p>
<p align="left"><font size="2">Last Updated 2/4/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 2/9/2003 - Tom Eastep</font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
@ -383,5 +385,6 @@ at shorewall.net to strip all HTML from outgoing posts.<br>
<br>
<br>
<br>
<br>
</body>
</html>

111
Shorewall-docs/traffic_shaping.htm
View File

@ -29,38 +29,39 @@
</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
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>
version 0.3.0 or later. You must also install the iproute (iproute2)
package to provide the "ip" and "tc" utilities.</p>
<p align="left">Shorewall traffic shaping support consists of the following:</p>
<ul>
<li>A new <b>TC_ENABLED</b> parameter in /etc/shorewall.conf.
Traffic Shaping also requires that you enable packet mangling.</li>
<li>A new <b>CLEAR_TC </b>parameter in /etc/shorewall.conf (Added in Shorewall
1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes), the setting of
this variable determines whether Shorewall clears the traffic shaping configuration
during Shorewall [re]start and Shorewall stop. <br>
<li>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>
firewall marking of packets. The firewall mark value may be used
to classify packets for traffic shaping/control.<br>
</li>
<li><b>/etc/shorewall/tcstart </b>- A user-supplied file that
is sourced by Shorewall during "shorewall start" and which you can
use to define your traffic shaping disciplines and classes. I have
provided a <a href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a>
that does table-driven CBQ shaping but if you read the traffic shaping
sections of the HOWTO mentioned above, you can probably code your
own faster than you can learn how to use my sample. I personally use
<a href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall since
HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
HTB is a standard part of the kernel but iproute2 must be patched in
order to use it.<br>
is sourced by Shorewall during "shorewall start" and which you
can use to define your traffic shaping disciplines and classes.
I have provided a <a
href="ftp://ftp.shorewall.net/pub/shorewall/cbq">sample</a> that does
table-driven CBQ shaping but if you read the traffic shaping sections
of the HOWTO mentioned above, you can probably code your own faster
than you can learn how to use my sample. I personally use <a
href="http://luxik.cdi.cz/%7Edevik/qos/htb/">HTB</a> (see below).
HTB support may eventually become an integral part of Shorewall
since HTB is a lot simpler and better-documented than CBQ. As of
2.4.20, HTB is a standard part of the kernel but iproute2 must be patched
in order to use it.<br>
<br>
In tcstart, when you want to run the 'tc' utility, use the
run_tc function supplied by shorewall if you want tc errors to stop
@ -79,32 +80,36 @@ so when traffic shaping happens, all outbound traffic will have as a source
</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>
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>
<ol>
<li>Set TC_ENABLED=Yes and CLEAR_TC=Yes</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic shaping
rules.</li>
<li>Supply an /etc/shorewall/tcstart script to configure your traffic
shaping rules.</li>
<li>Optionally supply an /etc/shorewall/tcclear script to stop traffic
shaping. That is usually unnecessary.</li>
<li>If your tcstart script uses the 'fwmark' classifier, you can mark packets
using entries in /etc/shorewall/tcrules.</li>
<li>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>
</ol>
<h3 align="left">Kernel Configuration</h3>
@ -134,39 +139,45 @@ to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN option in
<ul>
<li>MARK - Specifies the mark value is to be assigned in case
of a match. This is an integer in the range 1-255.<br>
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>
comma-separated list of interface names, IP addresses, MAC addresses
in <a href="Documentation.htm#MAC">Shorewall Format</a> and/or Subnets.<br>
<br>
Examples<br>
    eth0<br>
    192.168.2.4,192.168.1.0/24<br>
</li>
<li>DEST -- Destination of the packet. Comma-separated list of
IP addresses and/or subnets.<br>
<li>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>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
<li>CLIENT PORT(S) - (Optional) Port(s) used by the client.
If omitted, any source port is acceptable. Specified as a comma-separate
list of port names, port numbers or port ranges.</li>
</ul>
<p align="left">Example 1 - All packets arriving on eth1 should be marked
with 1. All packets arriving on eth2 and eth3 should be marked with 2.
All packets originating on the firewall itself should be marked with 3.</p>
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>
@ -298,13 +309,12 @@ rules in my <b>/etc/shorewall/tcstart</b> file:<br>
</blockquote>
<p>My tcrules file that went with this tcstart file is shown in Example 1
above. You can look at my <a href="myfiles.htm">network configuration</a>
to get an idea of why I wanted these particular rules.<br>
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
<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>
@ -313,12 +323,11 @@ can use all available bandwidth if there is no traffic from the local systems
</ol>
<p><font size="2">Last Updated 12/31/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last Updated 2/18/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

49
Shorewall-docs/troubleshoot.htm
View File

@ -93,9 +93,9 @@ this type of setup does NOT work the way that you expect it to.</li>
<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>
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
@ -129,8 +129,8 @@ LEN=47</font></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>
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>
@ -154,11 +154,12 @@ policy (see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
Either can't ping when you think you should be able to or are able to ping
when you think that you shouldn't be allowed? Shorewall's 'Ping' Management<a
href="ping.html"> is described here</a>.<br>
<h3 align="left">Other Gotchas</h3>
<ul>
<li>Seeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that:
<li>Seeing rejected/dropped packets logged out of the INPUT
or FORWARD chains? This means that:
<ol>
<li>your zone definitions are screwed up and the host that
@ -166,8 +167,8 @@ is sending the packets or the destination host isn't in any zone
(using an <a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a>
file are you?); or</li>
<li>the source and destination hosts are both connected to
the same interface and that interface doesn't have the 'multi'
option specified in <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.</li>
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>
@ -184,20 +185,19 @@ have the following in /etc/shorewall/nat:<br>
    10.1.1.2    eth0    130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type
8 between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped. This is
true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces.</li>
<li>If you specify "routefilter" for an interface, that interface
must be up prior to starting the firewall.</li>
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
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
<li>Some versions of LRP (EigerStein2Beta for example) have
a shell with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a corrected
shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a
@ -208,14 +208,8 @@ is generally included in the "iproute" package which should be included
by default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank"> ftp://ftp.inr.ac.ru/ip-routing</a>
.</li>
<li>If you have <u>any</u> entry for a zone in /etc/shorewall/hosts
then the zone must be entirely defined in /etc/shorewall/hosts unless
you have specified MERGE_HOSTS=Yes (Shorewall version 1.3.5 and later).
For example, if a zone has two interfaces but only one interface has an
entry in /etc/shorewall/hosts then hosts attached to the other interface
will <u>not</u> be considered part of the zone.</li>
<li>Problems with NAT? Be sure that you let Shorewall add all
external addresses to be use with NAT unless you have set <a
<li>Problems with NAT? Be sure that you let Shorewall
add all external addresses to be use with NAT unless you have set <a
href="Documentation.htm#Aliases"> ADD_IP_ALIASES</a> =No in /etc/shorewall/shorewall.conf.</li>
</ul>
@ -228,10 +222,11 @@ is generally included in the "iproute" package which should be included
<blockquote> </blockquote>
</font>
<p><font size="2">Last updated 1/7/2003 - Tom Eastep</font> </p>
<p><font size="2">Last updated 2/18/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
</body>
</html>

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

@ -24,6 +24,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Basic Two-Interface Firewall</font></h1>
</td>
</tr>
@ -40,11 +41,11 @@ follow the documentation.</p>
in its most common configuration:</p>
<ul>
<li>Linux system used as a firewall/router for a small local
network.</li>
<li>Linux system used as a firewall/router for a small
local network.</li>
<li>Single public IP address.</li>
<li>Internet connection through cable modem, DSL, ISDN, Frame
Relay, dial-up ...</li>
<li>Internet connection through cable modem, DSL, ISDN,
Frame Relay, dial-up ...</li>
</ul>
@ -57,12 +58,21 @@ follow the documentation.</p>
<p><b>If you are running Shorewall under Mandrake 9.0 or later, you can easily
configure the above setup using the Mandrake "Internet Connection Sharing"
applet. From the Mandrake Control Center, select "Network &amp; Internet"
then "Connection Sharing". You should not need to refer to this guide.</b><br>
then "Connection Sharing".<br>
</b></p>
<p><b>Note however, that the Shorewall configuration produced by Mandrake
Internet Connection Sharing is strange and is apt to confuse you if you use
the rest of this documentation (it has two local zones; "loc" and "masq"
where "loc" is empty; this conflicts with this documentation which assumes
a single local zone "loc"). We therefore recommend that once you have set
up this sharing that you uninstall the Mandrake Shorewall RPM and install
the one from the <a href="download.htm">download page</a> then follow the
instructions in this Guide.</b><br>
</p>
<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 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>
@ -103,8 +113,8 @@ 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/two-interfaces.tgz">two-interface sample</a>,
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to /etc/shorewall
(these files will replace files with the same name).</b></p>
un-tar it (tar -zxvf two-interfaces.tgz) and and copy the files to
/etc/shorewall (these files will replace files with the same name).</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
@ -146,16 +156,16 @@ a few of these as described in this guide. After you have <a
<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 href="Documentation.htm#Rules">/etc/shorewall/rules </a>file.</li>
<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
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 two-interface sample has
@ -234,8 +244,8 @@ the following policies:</p>
to the internet</li>
<li>drop (ignore) all connection requests from the internet
to your firewall or local network</li>
<li>optionally accept all connection requests from the firewall
to the internet (if you uncomment the additional policy)</li>
<li>optionally accept all connection requests from the
firewall to the internet (if you uncomment the additional policy)</li>
<li>reject all other connection requests.</li>
</ol>
@ -285,8 +295,8 @@ that Shorewall doesn't work at all.</p>
that the external interface is <b>eth0</b> and the internal interface
is <b>eth1</b>. If your configuration is different, you will have to
modify the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>
file accordingly. While you are there, you may wish to review the list
of options that are specified for the interfaces. Some hints:</p>
file accordingly. While you are there, you may wish to review the
list of options that are specified for the interfaces. Some hints:</p>
<ul>
<li>
@ -307,13 +317,13 @@ modify the sample <a href="Documentation.htm#Interfaces">/etc/shorewall/inter
<p align="left">Before going further, we should say a few words about Internet
Protocol (IP) <i>addresses</i>. Normally, your ISP will assign you
a single <i> Public</i> IP address. This address may be assigned via the<i>
Dynamic Host Configuration Protocol</i> (DHCP) or as part of establishing
a single <i> Public</i> IP address. This address may be assigned via
the<i> Dynamic Host Configuration Protocol</i> (DHCP) or as part of establishing
your connection when you dial in (standard modem) or establish your PPP
connection. In rare cases, your ISP may assign you a<i> static</i> IP
address; that means that you configure your firewall's external interface
to use that address permanently.<i> </i>However your external address is
assigned, it will be shared by all of your systems when you access the
to use that address permanently.<i> </i>However your external address
is assigned, it will be shared by all of your systems when you access the
Internet. You will have to assign your own addresses in your internal network
(the Internal Interface on your firewall plus your other computers). RFC
1918 reserves several <i>Private </i>IP address ranges for this purpose:</p>
@ -334,14 +344,15 @@ interface's entry in /etc/shorewall/interfaces.</p>
<div align="left">
<p align="left">You will want to assign your addresses from the same <i>
sub-network </i>(<i>subnet)</i>.  For our purposes, we can consider a subnet
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a subnet
will have a <i>Subnet Mask </i>of 255.255.255.0. The address x.y.z.0
is reserved as the <i>Subnet Address</i> and x.y.z.255 is reserved
as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall, a subnet
is described using <a href="shorewall_setup_guide.htm#Subnets"><i>Classless
InterDomain Routing </i>(CIDR) notation</a> with consists of the subnet
address followed by "/24". The "24" refers to the number of consecutive
leading "1" bits from the left of the subnet mask. </p>
to consists of a range of addresses x.y.z.0 - x.y.z.255. Such a
subnet will have a <i>Subnet Mask </i>of 255.255.255.0. The address
x.y.z.0 is reserved as the <i>Subnet Address</i> and x.y.z.255 is
reserved as the <i>Subnet Broadcast</i> <i>Address</i>. In Shorewall,
a subnet is described using <a
href="shorewall_setup_guide.htm#Subnets"><i>Classless InterDomain Routing
</i>(CIDR) notation</a> with consists of the subnet address followed
by "/24". The "24" refers to the number of consecutive leading "1" bits
from the left of the subnet mask. </p>
</div>
<div align="left">
@ -378,8 +389,8 @@ interface's entry in /etc/shorewall/interfaces.</p>
<div align="left">
<p align="left">It is conventional to assign the internal interface either
the first usable address in the subnet (10.10.10.1 in the above example)
or the last usable address (10.10.10.254).</p>
the first usable address in the subnet (10.10.10.1 in the above
example) or the last usable address (10.10.10.254).</p>
</div>
<div align="left">
@ -392,8 +403,8 @@ interface's entry in /etc/shorewall/interfaces.</p>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_1.gif" width="13"
height="13">
    Your local computers (computer 1 and computer 2 in the
above diagram) should be configured with their<i> default gateway</i>
    Your local computers (computer 1 and computer 2 in
the above diagram) should be configured with their<i> default gateway</i>
to be the IP address of the firewall's internal interface.<i>     
</i> </p>
</div>
@ -418,8 +429,8 @@ interface's entry in /etc/shorewall/interfaces.</p>
height="13" alt="">
    <font color="#ff0000"><b>WARNING: </b></font><b>Your ISP might assign
your external interface an RFC 1918 address. If that address is in the 10.10.10.0/24
subnet then you will need to select a DIFFERENT RFC 1918 subnet for your local
network.</b><br>
subnet then you will need to select a DIFFERENT RFC 1918 subnet for your
local network.</b><br>
</p>
<h2 align="left">IP Masquerading (SNAT)</h2>
@ -428,16 +439,17 @@ network.</b><br>
to as <i>non-routable</i> because the Internet backbone routers don't
forward packets which have an RFC-1918 destination address. When one
of your local systems (let's assume computer 1) sends a connection request
to an internet host, the firewall must perform <i>Network Address Translation
</i>(NAT). The firewall rewrites the source address in the packet to
be the address of the firewall's external interface; in other words,
the firewall makes it look as if the firewall itself is initiating the
connection.  This is necessary so that the destination host will be able
to route return packets back to the firewall (remember that packets whose
destination address is reserved by RFC 1918 can't be routed across the
internet so the remote host can't address its response to computer 1).
When the firewall receives a return packet, it rewrites the destination address
back to 10.10.10.1 and forwards the packet on to computer 1. </p>
to an internet host, the firewall must perform <i>Network Address
Translation </i>(NAT). The firewall rewrites the source address in
the packet to be the address of the firewall's external interface; in
other words, the firewall makes it look as if the firewall itself is
initiating the connection.  This is necessary so that the destination
host will be able to route return packets back to the firewall (remember
that packets whose destination address is reserved by RFC 1918 can't
be routed across the internet so the remote host can't address its response
to computer 1). When the firewall receives a return packet, it rewrites
the destination address back to 10.10.10.1 and forwards the packet on to
computer 1. </p>
<p align="left">On Linux systems, the above process is often referred to as<i>
IP Masquerading</i> but you will also see the term <i>Source Network Address
@ -468,9 +480,9 @@ When the firewall receives a return packet, it rewrites the destination address
height="13">
    If your external firewall interface is <b>eth0</b>, you
do not need to modify the file provided with the sample. Otherwise,
edit /etc/shorewall/masq and change the first column to the name of
your external interface and the second column to the name of your internal
interface.</p>
edit /etc/shorewall/masq and change the first column to the name
of your external interface and the second column to the name of your
internal interface.</p>
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
@ -497,12 +509,12 @@ your static IP in column 3 makes processing outgoing packets a little
<h2 align="left">Port Forwarding (DNAT)</h2>
<p align="left">One of your goals may be to run one or more servers on your
local computers. Because these computers have RFC-1918 addresses, it
is not possible for clients on the internet to connect directly to them.
It is rather necessary for those clients to address their connection
local computers. Because these computers have RFC-1918 addresses,
it is not possible for clients on the internet to connect directly to
them. It is rather necessary for those clients to address their connection
requests to the firewall who rewrites the destination address to the
address of your server and forwards the packet to that server. When your
server responds, the firewall automatically performs SNAT to rewrite
address of your server and forwards the packet to that server. When
your server responds, the firewall automatically performs SNAT to rewrite
the source address in the response.</p>
<p align="left">The above process is called<i> Port Forwarding</i> or <i>
@ -575,11 +587,11 @@ port forwarding using DNAT rules in the /etc/shorewall/rules file.</p>
<p>A couple of important points to keep in mind:</p>
<ul>
<li>You must test the above rule from a client outside of
your local network (i.e., don't test from a browser running on computers
1 or 2 or on the firewall). If you want to be able to access your
web server using the IP address of your external interface, see <a
href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
<li>You must test the above rule from a client outside
of your local network (i.e., don't test from a browser running on
computers 1 or 2 or on the firewall). If you want to be able to
access your web server using the IP address of your external interface,
see <a href="FAQ.htm#faq2">Shorewall FAQ #2</a>.</li>
<li>Many ISPs block incoming connection requests to port
80. If you have problems connecting to your web server, try the
following rule and try connecting to port 5000.</li>
@ -615,8 +627,8 @@ following rule and try connecting to port 5000.</li>
</blockquote>
<p> <img border="0" src="images/BD21298_.gif" width="13" height="13">
    At this point, modify /etc/shorewall/rules to add any DNAT
rules that you require.</p>
    At this point, modify /etc/shorewall/rules to add any
DNAT rules that you require.</p>
<h2 align="left">Domain Name Server (DNS)</h2>
@ -625,9 +637,9 @@ following rule and try connecting to port 5000.</li>
will be automatically configured (e.g., the /etc/resolv.conf file will
be written). Alternatively, your ISP may have given you the IP address
of a pair of DNS <i> name servers</i> for you to manually configure as
your primary and secondary name servers. Regardless of how DNS gets configured
on your firewall, it is <u>your</u> responsibility to configure the resolver
in your internal systems. You can take one of two approaches:</p>
your primary and secondary name servers. Regardless of how DNS gets
configured on your firewall, it is <u>your</u> responsibility to configure
the resolver in your internal systems. You can take one of two approaches:</p>
<ul>
<li>
@ -636,8 +648,9 @@ your primary and secondary name servers. Regardless of how DNS gets configu
name servers. If you ISP gave you the addresses of their servers
or if those addresses are available on their web site, you can configure
your internal systems to use those addresses. If that information
isn't available, look in /etc/resolv.conf on your firewall system --
the name servers are given in "nameserver" records in that file. </p>
isn't available, look in /etc/resolv.conf on your firewall system
-- the name servers are given in "nameserver" records in that file.
</p>
</li>
<li>
@ -647,12 +660,12 @@ the name servers are given in "nameserver" records in that file. </p>
firewall.<i> </i>Red Hat has an RPM for a caching name server
(the RPM also requires the 'bind' RPM) and for Bering users, there
is dnscache.lrp. If you take this approach, you configure your internal
systems to use the firewall itself as their primary (and only) name server.
You use the internal IP address of the firewall (10.10.10.254 in the
example above) for the name server address. To allow your local systems
to talk to your caching name server, you must open port 53 (both UDP
and TCP) from the local network to the firewall; you do that by adding
the following rules in /etc/shorewall/rules. </p>
systems to use the firewall itself as their primary (and only) name
server. You use the internal IP address of the firewall (10.10.10.254
in the example above) for the name server address. To allow your
local systems to talk to your caching name server, you must open port
53 (both UDP and TCP) from the local network to the firewall; you
do that by adding the following rules in /etc/shorewall/rules. </p>
</li>
</ul>
@ -917,6 +930,7 @@ uses, look <a href="ports.htm">here</a>.</p>
width="49" height="36">
    Bering users will want to add the following two rules to be compatible
with Jacques's Shorewall configuration.</p>
<div align="left">
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -960,6 +974,7 @@ with Jacques's Shorewall configuration.</p>
</table>
</blockquote>
</div>
<p align="left"><br>
<img border="0" src="images/BD21298_.gif" width="13" height="13">
    Now edit your /etc/shorewall/rules file to add or delete
@ -973,12 +988,12 @@ with Jacques's Shorewall configuration.</p>
<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>
    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>: </font><font
@ -992,18 +1007,18 @@ with Jacques's Shorewall configuration.</p>
and stopped using "shorewall stop". When the firewall is stopped,
routing is enabled on those hosts that have an entry in <a
href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>. A
running firewall may be restarted using the "shorewall restart" command.
If you want to totally remove any trace of Shorewall from your Netfilter
configuration, use "shorewall clear".</p>
running firewall may be restarted using the "shorewall restart"
command. If you want to totally remove any trace of Shorewall from
your Netfilter configuration, use "shorewall clear".</p>
</div>
<div align="left">
<p align="left"><img border="0" src="images/BD21298_.gif" width="13"
height="13">
    The two-interface sample assumes that you want to enable
routing to/from <b>eth1 </b>(the local network) when Shorewall is stopped.
If your local network isn't connected to <b>eth1</b> or if you wish to
enable access to/from other hosts, change /etc/shorewall/routestopped
routing to/from <b>eth1 </b>(the local network) when Shorewall is
stopped. If your local network isn't connected to <b>eth1</b> or if you
wish to enable access to/from other hosts, change /etc/shorewall/routestopped
accordingly.</p>
</div>
@ -1018,24 +1033,12 @@ to <a href="Documentation.htm#Routestopped">/etc/shorewall/routestopped</a>.
href="starting_and_stopping_shorewall.htm">"shorewall try" command</a>.</p>
</div>
<p align="left"><font size="2">Last updated 1/21/2003 - <a
<p align="left"><font size="2">Last updated 2/13/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"><font size="2">Copyright 2002, 2003
Thomas M. Eastep</font></a></p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Thomas M. Eastep</font></a><br>
</p>
<br>
</body>
</html>

107
Shorewall-docs/upgrade_issues.htm
View File

@ -6,6 +6,7 @@
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">
@ -31,6 +32,59 @@
<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>
<ul>
<li>The <b>noping </b>and <b>forwardping</b> interface options are no
longer supported nor is the <b>FORWARDPING </b>option in shorewall.conf. ICMP
echo-request (ping) packets are treated just like any other connection request
and are subject to rules and policies.</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in /etc/shorewall/interfaces
now generate a Shorewall error at startup (they always have produced warnings
in iptables).</li>
<li>The MERGE_HOSTS variable has been removed from shorewall.conf. Shorewall
1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone contents are
determined by BOTH the interfaces and hosts files when there are entries
for the zone in both files.</li>
<li>The <b>routestopped</b> option in the interfaces and hosts file has
been eliminated; use entries in the routestopped file instead.</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted; you must convert to using the new syntax.</li>
<li value="6">The ALLOWRELATED variable in shorewall.conf is no longer
supported. Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.</li>
<li value="6">Late-arriving DNS replies are not dropped by default; there
is no need for your own /etc/shorewall/common file simply to avoid logging
these packets.</li>
<li value="6">The 'firewall', 'functions' and 'version' file have been
moved to /usr/share/shorewall.</li>
<li value="6">The icmp.def file has been removed. If you include it from
/etc/shorewall/icmpdef, you will need to modify that file.</li>
<li value="8">The 'multi' interface option is no longer supported.  Shorewall
will generate rules for sending packets back out the same interface that they
arrived on in two cases:</li>
</ul>
<ul>
<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
@ -39,13 +93,15 @@ 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>
<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>
@ -76,16 +132,17 @@ to:<br>
<pre> #INTERFACE              SUBNET                  ADDRESS <br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<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
    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>
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>
@ -93,8 +150,8 @@ See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
</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
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>
@ -125,15 +182,15 @@ See the <a href="ping.html">'Ping' handling documentation</a> for details.<br>
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>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>
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
@ -170,6 +227,7 @@ and 1.3.7</p>
 </font> </p>
</li>
<li>
<p align="left">Create /etc/shorewall/common (if you don't already
have that file) and include the following:<br>
<br>
@ -222,7 +280,7 @@ and 1.3.7</p>
If you have applications that access these files, those applications
should be modified accordingly.</p>
<p><font size="2"> Last updated 1/25/2003 -
<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>
@ -230,5 +288,8 @@ and 1.3.7</p>
</p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

269
Shorewall-docs/whitelisting_under_shorewall.htm
View File

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