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

Shorewall 1.3.14 Release

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@438 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-08 20:46:02 +00:00
parent dfc7974ea0
commit 10b51d1991
12 changed files with 4860 additions and 5259 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

333
Shorewall-docs/FAQ.htm
View File

@ -3,16 +3,20 @@
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Shorewall FAQ</title>
@ -23,6 +27,7 @@
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber4"
bgcolor="#400169" height="90">
@ -38,17 +43,21 @@
</tr>
</tbody>
</table>
<p align="left"><b>1. </b><a href="#faq1"> I want to <b>forward</b> UDP <b>
port</b> 7777 to my my personal PC with IP address 192.168.1.5.
I've looked everywhere and can't find <b>how to do it</b>.</a></p>
<p align="left"><b>1a. </b><a href="#faq1a">Ok -- I followed those instructions
but it doesn't work.<br>
</a></p>
<p align="left"><b>1b. </b><a href="#faq1b">I'm still having problems with
port forwarding</a></p>
@ -57,26 +66,32 @@
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>
<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>
<p align="left"><b>4. </b><a href="#faq4">I just used an online port scanner
to check my firewall and it shows <b>some ports as 'closed'
rather than 'blocked'.</b> Why?</a></p>
<p align="left"><b>4a. </b><a href="#faq4a">I just ran an <b>nmap UDP scan</b>
of my firewall and it showed 100s of ports as open!!!!</a></p>
<p align="left"><b>5. </b><a href="#faq5">I've installed Shorewall and now
I <b> can't ping</b> through the firewall</a></p>
<p align="left"><b>6. </b><a href="#faq6">Where are the <b>log messages</b>
written and how do I <b>change the destination</b>?</a></p>
@ -95,14 +110,20 @@ from logging in Shorewall?</a><br>
They get dropped, but what the heck are they?</a><br>
</p>
<p align="left"><b>6d.</b> <a href="#faq6d">Why is the <b>MAC address</b>
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>
<p align="left"><b>9. </b><a href="FAQ.htm#faq9">Why can't Shorewall <b>detect
my interfaces </b>properly?</a></p>
@ -110,68 +131,80 @@ from logging in Shorewall?</a><br>
<p align="left"><b>10. </b><a href="#faq10">What <b>distributions</b> does
it work with?</a></p>
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Why isn't there a <b>GUI</b></a></p>
<p align="left"><b>12. </b><a href="#faq12">Is there a <b>GUI?</b></a></p>
<p align="left"><b>13. </b><a href="#faq13">Why do you call it <b>"Shorewall"?</b></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>
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>
<p align="left"><b>15. </b><a href="#faq15"><b>My local systems can't see
out to the net</b></a></p>
<p align="left"><b>16. </b><a href="#faq16">Shorewall is writing <b>log messages
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>
<b>17</b>. <a
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
<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
anything</b>. Why?</a><br>
<br>
<b>20. </b><a href="#faq20">I have just set up a
server. <b>Do I have to change Shorewall to allow access to my server
from the internet?<br>
<b>20. </b><a href="#faq20">I have just set up
a server. <b>Do I have to change Shorewall to allow access to my
server from the internet?<br>
<br>
</b></a><b>21. </b><a href="#faq21">I see these <b>strange log
entries </b>occasionally; what are they?<br>
</b></a><b>21. </b><a href="#faq21">I see these <b>strange
log entries </b>occasionally; what are they?<br>
</a><br>
<b>22. </b><a href="#faq22">I have some <b>iptables commands
</b>that I want to <b>run when Shorewall starts.</b> Which file do I
put them in?</a><br>
</b>that I want to <b>run when Shorewall starts.</b> Which file do
I put them in?</a><br>
<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>
<h4 align="left"><a name="faq1"></a>1. I want to forward UDP port 7777 to
my my personal PC with IP address 192.168.1.5. I've looked
everywhere and can't find how to do it.</h4>
<p align="left"><b>Answer: </b>The <a
href="Documentation.htm#PortForward"> first example</a> in the <a
href="Documentation.htm#Rules">rules file documentation</a> shows how to
do port forwarding under Shorewall. The format of a port-forwarding
rule to a local system is as follows:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -201,14 +234,17 @@ put them in?</a><br>
</tbody>
</table>
</blockquote>
<p align="left">So to forward UDP port 7777 to internal system 192.168.1.5,
the rule is:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -237,15 +273,18 @@ put them in?</a><br>
</tbody>
</table>
</blockquote>
<div align="left"> <font face="Courier"> </font>If
you want to forward requests directed to a particular address ( <i>&lt;external
IP&gt;</i> ) on your firewall to an internal system:</div>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -273,29 +312,35 @@ put them in?</a><br>
</tbody>
</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>
<p align="left"><b>Answer: </b>That is usually the result of one of two things:</p>
<ul>
<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 configured
(it should be set to the IP address of your firewall's internal
interface).</li>
<li>You have a more basic problem
with your local system such as an incorrect default gateway
configured (it should be set to the IP address of your firewall's
internal interface).</li>
</ul>
<h4 align="left"><a name="faq1b"></a>1b. I'm still having problems with port
forwarding</h4>
<b>Answer: </b>To further diagnose this problem:<br>
@ -309,12 +354,12 @@ clears the NetFilter counters in the nat table.</li>
<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>
<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>
<li>If the packet count is zero:</li>
@ -341,39 +386,46 @@ problem.<br>
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>
<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
<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>
<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>
<div align="left">
<p align="left">b) In /etc/shorewall/rules, add:</p>
</div>
<div align="left">
<blockquote>
@ -401,6 +453,7 @@ for my local systems that use static NAT.</li>
</tbody>
</table>
@ -414,14 +467,17 @@ for my local systems that use static NAT.</li>
Shorewall 1.3.4 or later then include this in /etc/shorewall/params:</p>
</div>
<div align="left">
<pre> ETH0_IP=`find_interface_address eth0`</pre>
</div>
<div align="left">
<p align="left">and make your DNAT rule:</p>
</div>
<div align="left">
<blockquote>
@ -449,37 +505,44 @@ for my local systems that use static NAT.</li>
</tbody>
</table>
</blockquote>
</div>
<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>
</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>
<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>
<p align="left">Another good way to approach this problem is to switch from
static NAT to Proxy ARP. That way, the hosts in Z have
non-RFC1918 addresses and can be accessed externally and
internally using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">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>
@ -487,12 +550,15 @@ traffic through your firewall then:</p>
<br>
Example:</p>
<p align="left">Zone: dmz<br>
Interface: eth2<br>
Subnet: 192.168.2.0/24</p>
<p align="left">In /etc/shorewall/interfaces:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -513,13 +579,16 @@ traffic through your firewall then:</p>
</tbody>
</table>
</blockquote>
<p align="left">In /etc/shorewall/policy:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -541,6 +610,7 @@ traffic through your firewall then:</p>
</tbody>
</table>
@ -549,6 +619,7 @@ traffic through your firewall then:</p>
<p align="left">In /etc/shorewall/masq:</p>
<blockquote>
<table border="1" cellpadding="2" style="border-collapse: collapse;"
@ -569,19 +640,22 @@ traffic through your firewall then:</p>
</tbody>
</table>
</blockquote>
<h4 align="left"><a name="faq3"></a>3. I want to use Netmeeting or MSN Instant
Messenger with Shorewall. What do I do?</h4>
<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
<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>
@ -605,8 +679,8 @@ 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
@ -614,35 +688,41 @@ of Windows chatter on LAN segments connected to the Firewall. </p>
<p align="left"><b>Answer: </b>Take a deep breath and read the nmap man page
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
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>
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
can't ping through the firewall</h4>
<p align="left"><b>Answer: </b>If you want your firewall to be totally open
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>
b) Copy /etc/shorewall/icmp.def to
/etc/shorewall/icmpdef<br>
c) Add the following to /etc/shorewall/icmpdef:
</p>
<blockquote>
<p align="left">run_iptables -A icmpdef -p ICMP --icmp-type echo-request
-j ACCEPT<br>
</p>
</blockquote>
For a complete description of Shorewall 'ping' management, see
<a href="ping.html">this page</a>.
For a complete description of Shorewall 'ping' management,
see <a href="ping.html">this page</a>.
<h4 align="left"><a name="faq6"></a>6. Where are the log messages written
and how do I change the destination?</h4>
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of syslog
(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility
(see "man openlog") and you get to choose the log level (again, see "man
@ -652,22 +732,27 @@ 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>
<div align="left">
<pre align="left"> LOGLIMIT=""<br> LOGBURST=""<br><br>Beginning with Shorewall version 1.3.12, you can <a
href="shorewall_logging.html">set up Shorewall to log all of its messages to a separate file</a>.<br></pre>
</div>
<h4 align="left"><a name="faq6a"></a>6a. Are there any log parsers that work
with Shorewall?</h4>
<p align="left"><b>Answer: </b>Here are several links that may be helpful:
</p>
<blockquote>
<p align="left"><a
@ -680,9 +765,9 @@ set: </p>
<a href="http://gege.org/iptables">http://gege.org/iptables</a><br>
</p>
</blockquote>
I personnaly use Logwatch. It emails me a report each day
from my various systems with each report summarizing the logged activity
on the corresponding system.
I personnaly use Logwatch. It emails me a report each
day from my various systems with each report summarizing the logged
activity on the corresponding system.
<h4 align="left"><b><a name="faq6b"></a>6b. DROP messages</b> on port 10619
are <b>flooding the logs</b> with their connect requests. Can i exclude
@ -692,8 +777,8 @@ these error messages for this port temporarily from logging in Shorewall?</h4>
<pre> DROP    net    fw    udp    10619</pre>
<h4 align="left"><a name="faq6c"></a>6c. All day long I get a steady flow
of these DROP messages from port 53 to some high numbered port.  They get
dropped, but what the heck are they?</h4>
of these DROP messages from port 53 to some high numbered port.  They
get dropped, but what the heck are they?</h4>
<pre>Jan  8 15:50:48 norcomix kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:40:c7:2e:09:c0:00:01:64:4a:70:00:08:00<br> SRC=208.138.130.16 DST=24.237.22.45 LEN=53 TOS=0x00 PREC=0x00<br> TTL=251 ID=8288 DF PROTO=UDP SPT=53 DPT=40275 LEN=33 </pre>
<b>Answer: </b>There are two possibilities:<br>
@ -703,8 +788,8 @@ these error messages for this port temporarily from logging in Shorewall?</h4>
<li>They are corrupted reply packets.</li>
</ol>
You can distinguish the difference by setting the <b>logunclean</b> option
(<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
You can distinguish the difference by setting the <b>logunclean</b>
option (<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
on your external interface (eth0 in the above example). If they get logged
twice, they are corrupted. I solve this problem by using an /etc/shorewall/common
file like this:<br>
@ -715,36 +800,63 @@ twice, they are corrupted. I solve this problem by using an /etc/shorewall/comm
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>
<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>
MAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00<br>
<ul>
<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>
<p align="left">The 'stop' command is intended to place your firewall into
a safe state whereby only those hosts listed in /etc/shorewall/routestopped'
are activated. If you want to totally open up your firewall,
you must use the 'shorewall clear' command. </p>
<h4 align="left"><a name="faq8"></a>8. When I try to start Shorewall on RedHat,
I get messages about insmod failing -- what's wrong?</h4>
<p align="left"><b>Answer: </b>The output you will see looks something like
this:</p>
<pre> /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy<br> Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters<br> /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod<br> /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed<br> /lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed<br> iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)<br> Perhaps iptables or your kernel needs to be upgraded.</pre>
<p align="left">This is usually cured by the following sequence of commands:
</p>
<div align="left">
<pre align="left"> service ipchains stop<br> chkconfig --delete ipchains<br> rmmod ipchains</pre>
</div>
<div align="left">
<p align="left">Also, be sure to check the <a href="errata.htm">errata</a>
for problems concerning the version of iptables (v1.2.3)
shipped with RH7.2.</p>
</div>
<h4 align="left"> </h4>
<h4 align="left"><a name="faq9"></a>9. Why can't Shorewall detect my interfaces
@ -754,14 +866,17 @@ twice, they are corrupted. I solve this problem by using an /etc/shorewall/comm
<p align="left">I just installed Shorewall and when I issue the start command,
I see the following:</p>
<div align="left">
<pre> Processing /etc/shorewall/shorewall.conf ...<br> Processing /etc/shorewall/params ...<br> Starting Shorewall...<br> Loading Modules...<br> Initializing...<br> Determining Zones...<br> Zones: net loc<br> Validating interfaces file...<br> Validating hosts file...<br> Determining Hosts in Zones...<br><b> Net Zone: eth0:0.0.0.0/0<br> Local Zone: eth1:0.0.0.0/0<br></b> Deleting user chains...<br> Creating input Chains...<br> ...</pre>
</div>
<div align="left">
<p align="left">Why can't Shorewall detect my interfaces properly?</p>
</div>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
@ -782,23 +897,21 @@ twice, they are corrupted. I solve this problem by using an /etc/shorewall/comm
<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. Why isn't there a GUI?</h4>
<h4 align="left"><a name="faq12"></a>12. Is there a GUI?</h4>
<p align="left"><b>Answer: </b>Every time I've started to work on one, I find
myself doing other things. I guess I just don't care enough if Shorewall
has a GUI to invest the effort to create one myself. There are several
Shorewall GUI projects underway however and I will publish links to
them when the authors feel that they are ready. </p>
<p align="left"><b>Answer: </b>Yes. Shorewall support is included in Webmin
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>
(<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>
<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
@ -808,8 +921,9 @@ them when the authors feel that they are ready. </p>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1 address
of the modem in/out but still block all other rfc1918 addresses?</p>
that will let all traffic to and from the 192.168.100.1
address of the modem in/out but still block all other rfc1918
addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
@ -819,11 +933,13 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
</div>
<div align="left">
<p align="left">If you are running version 1.3.1 or later, simply add the
following to<a href="Documentation.htm#rfc1918"> /etc/shorewall/rfc1918</a>:</p>
</div>
<div align="left">
<blockquote>
@ -841,12 +957,14 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
</tbody>
</table>
</blockquote>
</div>
<div align="left">
<p align="left">Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.<br>
</p>
@ -889,6 +1007,7 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
</blockquote>
</div>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
@ -896,43 +1015,52 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
lease.</h4>
</div>
<div align="left">
<p align="left">The solution is the same as FAQ 14 above. Simply substitute
the IP address of your ISPs DHCP server.</p>
</div>
<h4 align="left"><a name="faq15"></a>15. My local systems can't see out to
the net</h4>
<p align="left"><b>Answer: </b>Every time I read "systems can't see out to
the net", I wonder where the poster bought computers with
eyes and what those computers will "see" when things are working
properly. That aside, the most common causes of this problem
are:</p>
<ol>
<li>
<p align="left">The default gateway on each local system isn't set to
the IP address of the local firewall interface.</p>
</li>
<li>
<p align="left">The entry for the local network in the /etc/shorewall/masq
file is wrong or missing.</p>
</li>
<li>
<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>
</li>
</ol>
<h4 align="left"><a name="faq16"></a>16. Shorewall is writing log messages
all over my console making it unusable!</h4>
@ -968,8 +1096,8 @@ Either you have a<a href="Documentation.htm#Policy"> policy</a> for
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
<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>
</li>
<li><b>logpkt</b> - The packet is being
@ -992,8 +1120,8 @@ 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
<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>
</li>
@ -1049,6 +1177,7 @@ you used during your initial setup for information about how to set
</h4>
<blockquote>
<pre>Nov 25 18:58:52 linux kernel: Shorewall:net2all:DROP:IN=eth1 OUT= MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00<br> SRC=206.124.146.179 DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP TYPE=3 CODE=3 <br> [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]<br></pre>
</blockquote>
192.0.2.3 is external on my firewall... 172.16.0.0/24
@ -1058,31 +1187,31 @@ is my internal LAN<br>
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>
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 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,
Host 172.16.1.10 behind NAT gateway 206.124.146.179
sent a UDP DNS query to 192.0.2.3 and your DNS server tried to
send a response (the response information is in the brackets -- note
source port 53 which marks this as a DNS reply). When the response was
returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10
and forwarded the packet to 172.16.1.10 who no longer had a connection
on UDP port 2857. This causes a port unreachable (type 3, code 3) to
be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has no
record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
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>
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
@ -1090,43 +1219,39 @@ by RFC 1918.<br>
You can place these commands in one of the <a
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>.
Be sure that you look at the contents of the chain(s) that you will be modifying
with your commands to be sure that the commands will do what they are
intended. Many iptables commands published in HOWTOs and other instructional
material use the -A command which adds the rules to the end of the chain.
Most chains that Shorewall constructs end with an unconditional DROP,
ACCEPT or REJECT rule and any rules that you add after that will be ignored.
Check "man iptables" and look at the -I (--insert) command.<br>
with your commands to be sure that the commands will do what they
are intended. Many iptables commands published in HOWTOs and other
instructional material use the -A command which adds the rules to the
end of the chain. Most chains that Shorewall constructs end with an
unconditional DROP, ACCEPT or REJECT rule and any rules that you add
after that will be ignored. Check "man iptables" and look at the -I (--insert)
command.<br>
<h4><a name="faq23"></a><b>23. </b>Why do you use such ugly fonts on your
web site?</h4>
The Shorewall web site is almost font neutral (it doesn't explicitly
specify fonts except on a few pages) so the fonts you see are largely
the default fonts configured in your browser. If you don't like them then
reconfigure your browser.<br>
the 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/3/2003 - <a
<font size="2">Last updated 2/6/2003 - <a
href="support.htm">Tom Eastep</a></font>
<p><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

642
Shorewall-docs/News.htm
View File

File diff suppressed because it is too large Load Diff

22
Shorewall-docs/blacklisting_support.htm
View File

@ -31,7 +31,8 @@
<h2>Static Blacklisting</h2>
<p>Shorewall static blacklisting support has the following configuration parameters:</p>
<p>Shorewall static blacklisting support has the following configuration
parameters:</p>
<ul>
<li>You specify whether you want packets from blacklisted hosts dropped
@ -41,8 +42,8 @@ or rejected using the <a href="Documentation.htm#BLDisposition">BLACKLIST_DI
and at what syslog level using the <a
href="Documentation.htm#BLLoglevel">BLACKLIST_LOGLEVEL</a> setting in
/etc/shorewall/shorewall.conf</li>
<li>You list the IP addresses/subnets that you wish to blacklist in <a
href="Documentation.htm#Blacklist">/etc/shorewall/blacklist.</a> Beginning
<li>You list the IP addresses/subnets that you wish to blacklist in
<a href="Documentation.htm#Blacklist">/etc/shorewall/blacklist.</a> Beginning
with Shorewall version 1.3.8, you may also specify PROTOCOL and Port numbers/Service
names in the blacklist file.<br>
</li>
@ -63,8 +64,8 @@ against the blacklist using the "<a
<ul>
<li>drop <i>&lt;ip address list&gt; </i>- causes packets from the listed
IP addresses to be silently dropped by the firewall.</li>
<li>reject <i>&lt;ip address list&gt; </i>- causes packets from the listed
IP addresses to be rejected by the firewall.</li>
<li>reject <i>&lt;ip address list&gt; </i>- causes packets from the
listed IP addresses to be rejected by the firewall.</li>
<li>allow <i>&lt;ip address list&gt; </i>- re-enables receipt of packets
from hosts previously blacklisted by a <i>deny</i> or <i>reject</i> command.</li>
<li>save - save the dynamic blacklisting configuration so that it will
@ -72,23 +73,26 @@ be automatically restored the next time that the firewall is restarted.</li>
<li>show dynamic - displays the dynamic blacklisting configuration.</li>
</ul>
Dynamic blacklisting is <u>not</u> dependent on the "blacklist" option in
/etc/shorewall/interfaces.<br>
<p>Example 1:</p>
<pre> shorewall drop 192.0.2.124 192.0.2.125</pre>
<pre> <b><font color="#009900">shorewall drop 192.0.2.124 192.0.2.125</font></b></pre>
<p>    Drops packets from hosts 192.0.2.124 and 192.0.2.125</p>
<p>Example 2:</p>
<pre> shorewall allow 192.0.2.125</pre>
<pre> <b><font color="#009900">shorewall allow 192.0.2.125</font></b></pre>
<p>    Reenables access from 192.0.2.125.</p>
<p><font size="2">Last updated 10/7/2002 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2002 Thomas M. Eastep.</font></a></font></p>
© <font size="2">2002, 2003 Thomas M. Eastep.</font></a></font></p>
<br>
<br>
<br>
</body>

79
Shorewall-docs/configuration_file_basics.htm
View File

@ -21,6 +21,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Configuration Files</font></h1>
</td>
</tr>
@ -41,19 +42,20 @@
<ul>
<li>/etc/shorewall/shorewall.conf - used to set several
firewall parameters.</li>
<li>/etc/shorewall/params - use this file to set shell
variables that you will expand in other files.</li>
<li>/etc/shorewall/params - use this file to set
shell variables that you will expand in other files.</li>
<li>/etc/shorewall/zones - partition the firewall's
view of the world into <i>zones.</i></li>
<li>/etc/shorewall/policy - establishes firewall high-level
policy.</li>
<li>/etc/shorewall/policy - establishes firewall
high-level policy.</li>
<li>/etc/shorewall/interfaces - describes the interfaces
on the firewall system.</li>
<li>/etc/shorewall/hosts - allows defining zones in
terms of individual hosts and subnetworks.</li>
<li>/etc/shorewall/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
@ -61,20 +63,20 @@ exceptions to the overall policies established in /etc/shorewall/p
<li>/etc/shorewall/nat - defines static NAT rules.</li>
<li>/etc/shorewall/proxyarp - defines use of Proxy
ARP.</li>
<li>/etc/shorewall/routestopped (Shorewall 1.3.4 and
later) - defines hosts accessible when Shorewall is stopped.</li>
<li>/etc/shorewall/routestopped (Shorewall 1.3.4
and later) - defines hosts accessible when Shorewall is stopped.</li>
<li>/etc/shorewall/tcrules - defines marking of packets
for later use by traffic control/shaping or policy routing.</li>
<li>/etc/shorewall/tos - defines rules for setting
the TOS field in packet headers.</li>
<li>/etc/shorewall/tunnels - defines IPSEC, GRE and
IPIP tunnels with end-points on the firewall system.</li>
<li>/etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC
addresses.</li>
<li>/etc/shorewall/blacklist - lists blacklisted
IP/subnet/MAC addresses.</li>
<li>/etc/shorewall/init - commands that you wish to execute at the beginning
of a "shorewall start" or "shorewall restart".</li>
<li>/etc/shorewall/start - commands that you wish to execute at the completion
of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/start - commands that you wish to execute at the
completion of a "shorewall start" or "shorewall restart"</li>
<li>/etc/shorewall/stop - commands that you wish to execute at the beginning
of a "shorewall stop".</li>
<li>/etc/shorewall/stopped - commands that you wish to execute at the
@ -87,8 +89,8 @@ completion of a "shorewall stop".<br>
<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>
@ -110,9 +112,9 @@ 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>
@ -186,8 +188,8 @@ your inconvenience but are rather limitations of iptables.<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>
@ -201,8 +203,8 @@ be no white space following the "!".</p>
<li>If you use line continuation to break a comma-separated
list, the continuation line(s) must begin in column 1 (or
there would be embedded white space)</li>
<li>Entries in a comma-separated list may appear in
any order.</li>
<li>Entries in a comma-separated list may appear
in any order.</li>
</ul>
@ -215,11 +217,13 @@ there would be embedded white space)</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>
If you omit the low port number, a value of zero is assumed; if you omit
the high port number, a value of 65535 is assumed.<br>
<h2><a name="Variables"></a>Using Shell Variables</h2>
@ -271,8 +275,8 @@ local host 192.168.1.3, the entry in /etc/shorewall/rules is:<br>
<p>MAC addresses are 48 bits wide and each Ethernet Controller has a
unique MAC address.<br>
<br>
In GNU/Linux, MAC addresses are usually written as a
series of 6 hex numbers separated by colons. Example:<br>
In GNU/Linux, MAC addresses are usually written as
a series of 6 hex numbers separated by colons. Example:<br>
<br>
     [root@gateway root]# ifconfig eth0<br>
     eth0 Link encap:Ethernet HWaddr <b><u>02:00:08:E3:FA:55</u></b><br>
@ -290,9 +294,9 @@ series of 6 hex numbers separated by colons. Example:<br>
<br>
Because Shorewall uses colons as a separator for address
fields, Shorewall requires MAC addresses to be written in another
way. In Shorewall, MAC addresses begin with a tilde ("~") and consist
of 6 hex numbers separated by hyphens. In Shorewall, the MAC address
in the example above would be written "~02-00-08-E3-FA-55".<br>
way. In Shorewall, MAC addresses begin with a tilde ("~") and
consist of 6 hex numbers separated by hyphens. In Shorewall, the
MAC address in the example above would be written "~02-00-08-E3-FA-55".<br>
</p>
<p><b>Note: </b>It is not necessary to use the special Shorewall notation
@ -302,12 +306,12 @@ series of 6 hex numbers separated by colons. Example:<br>
<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>
@ -326,16 +330,17 @@ in the alternate directory will be read from /etc/shorewall.</p>
<p><font size="2"> Updated 12/29/2002 - <a href="support.htm">Tom Eastep</a>
<p><font size="2"> Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

47
Shorewall-docs/download.htm
View File

@ -21,6 +21,7 @@
<tr>
<td width="100%">
<h1 align="center"><font color="#ffffff">Shorewall Download</font></h1>
</td>
</tr>
@ -34,26 +35,25 @@
for the configuration that most closely matches your own.<br>
</b></p>
<p>The entire set of Shorewall documentation is available in PDF format
at:</p>
<p>The entire set of Shorewall documentation is available in PDF format at:</p>
<p>    <a href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
    <a href="rsync://slovakia.shorewall.net/shorewall/pdf/">rsync://slovakia.shorewall.net/shorewall/pdf/</a>
</p>
<p>The documentation in HTML format is included in the .rpm and in the
.tgz packages below.</p>
<p>The documentation in HTML format is included in the .rpm and in the .tgz
packages below.</p>
<p> Once you've done that, download <u> one</u> of the modules:</p>
<ul>
<li>If you run a <b>RedHat</b>, <b>SuSE, Mandrake</b>, <b>
Linux PPC</b> or <b> TurboLinux</b> distribution with
a 2.4 kernel, you can use the RPM version (note: the
RPM should also work with other distributions that store
init scripts in /etc/init.d and that include chkconfig or
insserv). If you find that it works in other cases, let <a
<li>If you run a <b>RedHat</b>, <b>SuSE, Mandrake</b>,
<b> Linux PPC</b> or <b> TurboLinux</b> distribution
with a 2.4 kernel, you can use the RPM version (note: the
RPM should also work with other distributions that
store init scripts in /etc/init.d and that include chkconfig
or insserv). If you find that it works in other cases, let <a
href="mailto:teastep@shorewall.net"> me</a> know so that
I can mention them here. See the <a href="Install.htm">Installation
Instructions</a> if you have problems installing the RPM.</li>
@ -61,8 +61,8 @@ Instructions</a> if you have problems installing the RPM.</li>
might also want to download the .tgz so you will have a copy of
the documentation).</li>
<li>If you run <a href="http://www.debian.org"><b>Debian</b></a>
and would like a .deb package, Shorewall is included in both the
<a href="http://packages.debian.org/testing/net/shorewall.html">Debian
and would like a .deb package, Shorewall is included in both
the <a href="http://packages.debian.org/testing/net/shorewall.html">Debian
Testing Branch</a> and the <a
href="http://packages.debian.org/unstable/net/shorewall.html">Debian
Unstable Branch</a>.</li>
@ -98,9 +98,9 @@ THE RPM AND ISSUE A "shorewall start" COMMAND. SOME CONFIGURATION
IS REQUIRED BEFORE THE FIREWALL WILL START. Once you have completed configuration
of your firewall, you can enable startup by removing the file /etc/shorewall/startup_disabled.</b></font></p>
<p><b>Download Latest Version</b> (<b>1.3.13</b>): <b>Remember that updates
to the mirrors occur 1-12 hours after an update to the Washington State
site.</b></p>
<p><b>Download Latest Version</b> (<b>1.3.14</b>): <b>Remember that updates
to the mirrors occur 1-12 hours after an update to the Washington
State site.</b></p>
<blockquote>
<table border="2" cellspacing="3" cellpadding="3"
@ -239,11 +239,9 @@ site.</b></p>
<td><a
href="http://france.shorewall.net/pub/LATEST.rpm">Download .rpm</a><br>
<a
href="http://france.shorewall.net/pub/LATEST.tgz">Download
.tgz</a> <br>
href="http://france.shorewall.net/pub/LATEST.tgz">Download .tgz</a> <br>
<a
href="http://france.shorewall.net/pub/LATEST.lrp">Download
.lrp</a><br>
href="http://france.shorewall.net/pub/LATEST.lrp">Download .lrp</a><br>
<a
href="http://france.shorewall.net/pub/LATEST.md5sums">Download
.md5sums</a></td>
@ -374,14 +372,14 @@ site.</b></p>
<blockquote>
<p align="left">The <a target="_top"
href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository at
cvs.shorewall.net</a> contains the latest snapshots of the each Shorewall
component. There's no guarantee that what you find there will work
at all.<br>
href="http://cvs.shorewall.net/Shorewall_CVS_Access.html">CVS repository
at cvs.shorewall.net</a> contains the latest snapshots of the each
Shorewall component. There's no guarantee that what you find there
will work at all.<br>
</p>
</blockquote>
<p align="left"><font size="2">Last Updated 1/13/2003 - <a
<p align="left"><font size="2">Last Updated 2/7/2003 - <a
href="support.htm">Tom Eastep</a></font></p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
@ -389,5 +387,6 @@ at all.<br>
</p>
<br>
<br>
<br>
</body>
</html>

154
Shorewall-docs/errata.htm
View File

@ -30,6 +30,7 @@
</td>
</tr>
</tbody>
</table>
@ -46,9 +47,9 @@
</li>
<li>
<p align="left"> <b>If you are installing Shorewall for the first
time and plan to use the .tgz and install.sh script, you can untar
the archive, replace the 'firewall' script in the untarred directory
<p align="left"> <b>If you are installing Shorewall for the
first time and plan to use the .tgz and install.sh script, you can
untar the archive, replace the 'firewall' script in the untarred directory
with the one you downloaded below, and then run install.sh.</b></p>
</li>
<li>
@ -56,19 +57,21 @@ the archive, replace the 'firewall' script in the untarred directory
<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>
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to
overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD
/etc/shorewall/firewall or /var/lib/shorewall/firewall before
you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall
are symbolic links that point to the 'shorewall' file used by
your system initialization scripts to start Shorewall during
boot. It is that file that must be overwritten with the corrected
script. Beginning with Shorewall 1.3.11, you may rename the existing file
before copying in the new file.</b></p>
</li>
<li>
<p align="left"><b><font color="#ff0000">DO NOT INSTALL CORRECTED COMPONENTS
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW. For
example, do NOT install the 1.3.9a firewall script if you are running
ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER BELOW.
For example, do NOT install the 1.3.9a firewall script if you are running
1.3.7c.</font></b><br>
</p>
</li>
@ -86,12 +89,13 @@ overwritten with the corrected script. Beginning with Shorewall
<li> <b><font
color="#660066"><a href="#iptables"> Problem with iptables version 1.2.3
on RH7.2</a></font></b></li>
<li> <b><a href="#Debug">Problems
with kernels &gt;= 2.4.18 and RedHat iptables</a></b></li>
<li> <b><a
href="#Debug">Problems with kernels &gt;= 2.4.18 and
RedHat iptables</a></b></li>
<li><b><a href="#SuSE">Problems installing/upgrading
RPM on SuSE</a></b></li>
<li><b><a href="#Multiport">Problems with iptables version
1.2.7 and MULTIPORT=Yes</a></b></li>
<li><b><a href="#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>
@ -105,29 +109,33 @@ RPM on SuSE</a></b></li>
<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.<br>
<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>
Both problems are corrected by <a
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
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>
@ -160,8 +168,8 @@ new lrp (shorwall-1.3.12a.lrp) has been released which corrects this problem.<
<h3>Version 1.3.11</h3>
<ul>
<li>When installing/upgrading using the .rpm, you may receive the
following warnings:<br>
<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>
@ -190,11 +198,12 @@ as the .rpm you will get from there has been corrected.</li>
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>
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>
@ -222,11 +231,11 @@ as the .rpm you will get from there has been corrected.</li>
</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
<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>
@ -253,8 +262,8 @@ as the .rpm you will get from there has been corrected.</li>
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.
as described above corrects these
problems.
<h3>Version 1.3.7b</h3>
<p>DNAT rules where the source zone is 'fw' ($FW)
@ -262,7 +271,8 @@ as the .rpm you will get from there has been corrected.</li>
<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>
as described above corrects this
problem.</p>
<h3>Version 1.3.7a</h3>
@ -273,7 +283,8 @@ as the .rpm you will get from there has been corrected.</li>
<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>
as described above corrects this
problem.</p>
<h3>Version &lt;= 1.3.7a</h3>
@ -328,8 +339,8 @@ above.</p>
<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>
an error occurs when the firewall script attempts to
add an SNAT alias. </p>
</li>
<li>
@ -399,10 +410,10 @@ above.</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
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>
@ -412,20 +423,21 @@ it's a good idea to run that command after you have made configuratio
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>
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>
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>
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>
@ -451,15 +463,15 @@ prevented it from working correctly. </li>
<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>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>
<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>
@ -471,9 +483,10 @@ in the prior bullet affects the following options: dhcp,
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>
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>
@ -525,8 +538,8 @@ also built an <a
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can download
from<font color="#ff6633"> <a
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
href="http://www.redhat.com/support/errata/RHSA-2001-144.html">http://www.redhat.com/support/errata/RHSA-2001-144.html</a>.
</font>I have installed this RPM on my firewall and it works
fine.</p>
@ -560,15 +573,17 @@ fine.</p>
<p>Users who use RedHat iptables RPMs and who upgrade to kernel 2.4.18/19
may experience the following:</p>
<blockquote>
<pre># shorewall start<br>Processing /etc/shorewall/shorewall.conf ...<br>Processing /etc/shorewall/params ...<br>Starting Shorewall...<br>Loading Modules...<br>Initializing...<br>Determining Zones...<br>Zones: net<br>Validating interfaces file...<br>Validating hosts file...<br>Determining Hosts in Zones...<br>Net Zone: eth0:0.0.0.0/0<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br>iptables: libiptc/libip4tc.c:380: do_check: Assertion<br>`h-&gt;info.valid_hooks == (1 &lt;&lt; 0 | 1 &lt;&lt; 3)' failed.<br>Aborted (core dumped)<br></pre>
</blockquote>
<p>The RedHat iptables RPM is compiled with debugging enabled but the
user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by installing
<a
the Netfilter 'mangle' table. You can correct the problem by
installing <a
href="http://www.shorewall.net/pub/shorewall/iptables-1.2.5-1.i386.rpm">
this iptables RPM</a>. If you are already running a 1.2.5 version
of iptables, you will need to specify the --oldpackage option to
@ -620,11 +635,11 @@ in Shorewall being unable to start:<br>
<pre>Setting up NAT...<br>iptables: Invalid argument<br>Terminated<br><br></pre>
The solution is to put "no" in the LOCAL column. Kernel support
for LOCAL=yes has never worked properly and 2.4.18-10 has disabled
it. The 2.4.19 kernel contains corrected support under a new kernel
configuraiton option; see <a href="Documentation.htm#NAT">http://www.shorewall.net/Documentation.htm#NAT</a><br>
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 1/25/2003 -
<p><font size="2"> Last updated 2/8/2003 -
<a href="support.htm">Tom Eastep</a></font> </p>
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
@ -638,5 +653,6 @@ configuraiton option; see <a href="Documentation.htm#NAT">http://www.shorewal
<br>
<br>
<br>
<br>
</body>
</html>

52
Shorewall-docs/mailing_list.htm
View File

@ -41,6 +41,7 @@
border="0" src="images/logo-sm.jpg" align="left" hspace="5" width="110"
height="35" alt="">
</a>
<p align="right"><font color="#ffffff"><b>  </b></font> </p>
</td>
<td valign="middle" width="34%" align="center">
@ -105,8 +106,8 @@
<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
@ -115,17 +116,17 @@ list posts!!<br>
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
from outgoing posts. This means that HTML-only posts will be bounced by the
list server.<br>
from outgoing posts. This means that HTML-only posts will be bounced by
the list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<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>
@ -163,26 +164,26 @@ they help but I'm not prepared to go so far as to start stripping <i>Received:<
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>
If you want to trust X.509 certificates issued by Shoreline
Firewall (such as the one used on my web site), you may <a
href="Shorewall_CA_html.html">download and install my CA certificate</a>
in your browser. If you don't wish to trust my certificates then you
can either use unencrypted access when subscribing to Shorewall mailing
lists or you can use secure access (SSL) and accept the server's certificate
when prompted by your browser.<br>
in your browser. If you don't wish to trust my certificates then
you can either use unencrypted access when subscribing to Shorewall
mailing lists or you can use secure access (SSL) and accept the server's
certificate when prompted by your browser.<br>
<h2 align="left">Shorewall Users Mailing List</h2>
<p align="left">The Shorewall Users Mailing list provides a way for users
to get answers to questions and to report problems. Information of
general interest to the Shorewall user community is also posted to
this list.</p>
to get answers to questions and to report problems. Information
of general interest to the Shorewall user community is also posted
to this list.</p>
<p align="left"><b>Before posting a problem report to this list, please see
the <a href="http://www.shorewall.net/support.htm">problem reporting
@ -206,9 +207,9 @@ guidelines</a>.</b></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>
@ -260,8 +261,8 @@ 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>
@ -293,10 +294,11 @@ may be found at <a
<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
href="support.htm">Tom Eastep</a></font></p>
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>
</body>
</html>

37
Shorewall-docs/ports.htm
View File

@ -52,11 +52,11 @@ firewall to accommodate.</p>
<p>DNS</p>
<blockquote>
<p>UDP Port 53. If you are configuring a DNS client, you will probably
want to open TCP Port 53 as well.<br>
If you are configuring a server, only open TCP Port 53 if you will return
long replies to queries or if you need to enable ZONE transfers. In the
latter case, be sure that your server is properly configured.</p>
<p>UDP Port 53. If you are configuring a DNS client, you will probably want
to open TCP Port 53 as well.<br>
If you are configuring a server, only open TCP Port 53 if you will
return long replies to queries or if you need to enable ZONE transfers. In
the latter case, be sure that your server is properly configured.</p>
</blockquote>
<p>ICQ   </p>
@ -144,8 +144,8 @@ have:<br>
<p>Note that you MUST include port 21 in the <i>ports</i> list or you may
have problems accessing regular FTP servers.</p>
<p>If there is a possibility that these modules might be loaded before
Shorewall starts, then you should include the port list in /etc/modules.conf:<br>
<p>If there is a possibility that these modules might be loaded before Shorewall
starts, then you should include the port list in /etc/modules.conf:<br>
</p>
<blockquote>
@ -172,23 +172,32 @@ Shorewall starts, then you should include the port list in /etc/modules.conf:<br
<p>UDP ports 33434 through 33434+<i>&lt;max number of hops&gt;</i>-1</p>
</blockquote>
<p>NFS</p>
<p>NFS<br>
</p>
<blockquote>
<p>I personally use the following rules for opening access from zone z1
to a server with IP address a.b.c.d in zone z2:<br>
</p>
<pre>ACCEPT z1 z2:a.b.c.d udp 111<br>ACCEPT z1 z2:a.b.c.d udp 2049<br>ACCEPT z1 z2:a.b.c.d udp 32700:<br></pre>
</blockquote>
<blockquote>
<p>There's some good information at  <a
<p>Note that my rules only cover NFS using UDP (the normal case). There
is lots of additional information at  <a
href="http://nfs.sourceforge.net/nfs-howto/security.html"> http://nfs.sourceforge.net/nfs-howto/security.html</a></p>
</blockquote>
<p>Didn't find what you are looking for -- have you looked in your own
/etc/services file? </p>
<p>Didn't find what you are looking for -- have you looked in your own /etc/services
file? </p>
<p>Still looking? Try <a
href="http://www.networkice.com/advice/Exploits/Ports"> http://www.networkice.com/advice/Exploits/Ports</a></p>
<p><font size="2">Last updated 11/10/2002 - </font><font size="2"> <a
<p><font size="2">Last updated 2/7/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 Thomas M. Eastep.</font></a><br>
<a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<br>
<br>
<br>
</body>

485
Shorewall-docs/seattlefirewall_index.htm
View File

@ -6,6 +6,7 @@
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shoreline Firewall (Shorewall) 1.3</title>
@ -13,13 +14,14 @@
<base
target="_self">
<base target="_self">
</head>
<body>
<table border="0" cellpadding="0" cellspacing="4"
style="border-collapse: collapse;" width="100%" id="AutoNumber3"
bgcolor="#4b017c">
@ -77,6 +79,7 @@ made easy"</i></font></font></h1>
<div align="center">
<center>
@ -109,9 +112,10 @@ made easy"</i></font></font></h1>
<p>The Shoreline Firewall, more commonly known as "Shorewall", is a
<a href="http://www.netfilter.org">Netfilter</a> (iptables) based firewall
that can be used on a dedicated firewall system, a multi-function
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
gateway/router/server or on a standalone GNU/Linux system.</p>
@ -123,10 +127,12 @@ made easy"</i></font></font></h1>
<p>This program is free software; you can redistribute it and/or modify
it under the terms of <a
href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU General
Public License</a> as published by the Free Software Foundation.<br>
it under the terms of
<a href="http://www.gnu.org/licenses/gpl.html">Version 2 of
the GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
@ -139,10 +145,11 @@ Public License</a> as published by the Free Software Foundation.<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>
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>
@ -169,8 +176,8 @@ the GNU General Public License along with
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>
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>
@ -179,15 +186,15 @@ the GNU General Public License along with
<p><b>Congratulations to Jacques and Eric on the recent release of Bering
1.0 Final!!! </b><br>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </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>
<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>
@ -212,6 +219,7 @@ the GNU General Public License along with
<h2></h2>
@ -220,45 +228,17 @@ the GNU General Public License along with
<p><b>2/4/2003 - Shorewall 1.3.14-RC1</b><b> </b><b><img
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.</p>
<p> The release candidate may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta"
target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2 </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 1 content plus restores VLAN device names of the
form $dev.$vid (e.g., eth0.1)</p>
<p> The beta may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
 </b><br>
</p>
<p>The Beta includes the following changes:<br>
</p>
<p>New features include</p>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see http://www.shorewall.net/ping.html).<br>
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
@ -266,25 +246,32 @@ the GNU General Public License along with
will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead of
just the interface name:<br>
<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>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
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
   a) The subnets associated with other addresses on the interface.<br>
   b) Subnets accessed through local routers.<br>
 <br>
Beginning with Shorewall 1.3.14, if you enter an interface name in
the SUBNET column, shorewall will use the firewall's routing table to
construct the masquerading/SNAT rules.<br>
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>
@ -293,371 +280,53 @@ construct the masquerading/SNAT rules.<br>
<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... <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>
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]#<br></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]#<br></pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
The beta may be downloaded from:<br>
<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b><b>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
</b></p>
Webmin version 1.060 now has Shorewall support included as standard. See
<a href="http://www.webmin.com">http://www.webmin.com</a>.<b> </b>
<p><b></b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
documenation. the PDF may be downloaded from</p>
    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
<p><b>1/17/2003 - shorewall.net has MOVED</b><b></b></p>
<p>Thanks to the generosity of Alex Martin and <a
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and
ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A
big thanks to Alex for making this happen.<br>
</p>
<p><b>1/13/2003 - Shorewall 1.3.13</b><br>
</p>
<p>Just includes a few things that I had on the burner:<br>
</p>
<ol>
<li>A new 'DNAT-' action has been added for entries in the
/etc/shorewall/rules file. DNAT- is intended for advanced users who wish
to minimize the number of rules that connection requests must traverse.<br>
<br>
A Shorewall DNAT rule actually generates two iptables rules: a
header rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
table. A DNAT- rule only generates the first of these rules. This is handy
when you have several DNAT rules that would generate the same ACCEPT rule.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
<br>
   These three rules ended up generating _three_ copies of<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of
the ACCEPT rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
<br>
</li>
<li>The 'shorewall check' command now prints out the applicable
policy between each pair of zones.<br>
<br>
</li>
<li>A new CLEAR_TC option has been added to shorewall.conf.
If this option is set to 'No' then Shorewall won't clear the current
traffic control rules during [re]start. This setting is intended for
use by people that prefer to configure traffic shaping when the network
interfaces come up rather than when the firewall is started. If that
is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not
supply an /etc/shorewall/tcstart file. That way, your traffic shaping
rules can still use the 'fwmark' classifier based on packet marking defined
in /etc/shorewall/tcrules.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows
distribution packagers to easily move the shared directory (default /usr/lib/shorewall).
Users should never have a need to change the value of this shorewall.conf
setting.<br>
</li>
</ol>
<p><b>1/6/2003 -</b><b><big><big><big><big><big><big><big><big> B</big></big></big></big></big><small>U<small>R<small>N<small>O<small>U<small>T</small></small></small></small></small></small></big></big></big></b><b>
</b></p>
<p><b>Until further notice, I will not be involved in either Shorewall
Development or Shorewall Support</b></p>
<p><b>-Tom Eastep</b><br>
</p>
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b>
</b></p>
<p> Features include:<br>
</p>
<ol>
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging
after an error occurs. This places the point of the failure near
the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by
more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been
added which shows the current packet classification filters. The
output from this command is also added as a separate page in "shorewall
monitor"</li>
<li>ULOG (must be all caps) is now accepted as a
valid syslog level and causes the subject packets to be logged using
the ULOG target rather than the LOG target. This allows you to run
ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD
chain in the mangle table ("shorewall show mangle" will show you
the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
won't overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable
to <a href="Documentation.htm#Conf">shorewall.conf</a>. This
variable specifies the syslog level at which packets are logged as
a result of entries in the /etc/shorewall/rfc1918 file. Previously,
these packets were always logged at the 'info' level.<br>
</li>
</ol>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
This version corrects a problem with Blacklist logging.
In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the
firewall would fail to start and "shorewall refresh" would also fail.<br>
<p> You may download the Beta from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is
now available (Beta 1 was made available to a limited audience).
<br>
<br>
Features include:<br>
<br>
<ol>
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off
debugging after an error occurs. This places the point of the failure
near the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded
up by more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command
has been added which shows the current packet classification filters.
The output from this command is also added as a separate page in
"shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted
as a valid syslog level and causes the subject packets to be logged
using the ULOG target rather than the LOG target. This allows you to
run ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a
FORWARD chain in the mangle table ("shorewall show mangle" will
show you the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in shorewall.conf. This allows for marking input packets based on
their destination even when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall
directory with empty 'init', 'start', 'stop' and 'stopped' files.
If you already have a file with one of these names, don't worry
-- the upgrade process won't overwrite your file.</li>
</ol>
You may download the Beta from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" width="150" height="21" border="0">
</a></b></p>
Shorewall is at the center of MandrakeSoft's recently-announced
<a
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">Multi
Network Firewall (MNF)</a> product. Here is the <a
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
release</a>.<br>
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b><b>
</b></p>
<p>Two months and 3 days after I pre-ordered Mandrake 9.0, it was finally
delivered. I have installed 9.0 on one of my systems and I am
now in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/6/2002 -  Debian 1.3.11a Packages Available</b><br>
</p>
<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11
users who don't need rules of this type need not upgrade to 1.3.11.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>11/24/2002 - Shorewall 1.3.11</b><b> </b><b>
</b></p>
<p>In this version:</p>
<p><b></b></p>
<ul>
<li>A 'tcpflags' option has been
added to entries in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP
packet header flags.</li>
<li>It is now allowed to use 'all'
in the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear
by itself (in may not be qualified) and it does not enable intra-zone
traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc'
to 'loc'.</li>
<li>Shorewall's use of the 'echo'
command is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
@ -738,11 +407,11 @@ command is now compatible with bash clones such as ash and dash.</
<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>
@ -758,13 +427,9 @@ Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
<br>
</body>
</html>

10
Shorewall-docs/shorewall_features.htm
View File

@ -46,6 +46,9 @@
</li>
<li> <a href="shorewall_quickstart_guide.htm">QuickStart Guides (HOWTOs)</a>
to help get your first firewall up and running quickly</li>
<li>A <b>GUI</b> is available via Webmin 1.060 and later (<a
href="http://www.webmin.com">http://www.webmin.com</a>)<br>
</li>
<li>Extensive <b> <a
href="shorewall_quickstart_guide.htm#Documentation">documentation</a>
</b> included in the .tgz and .rpm downloads.</li>
@ -97,18 +100,19 @@ on a floppy, CD or compact flash).</li>
</ul>
</li>
<li><a href="MAC_Validation.html">Media Access Control (<b>MAC</b>) Address
<b>Verification</b><br>
<li><a href="MAC_Validation.html">Media Access Control (<b>MAC</b>)
Address <b>Verification</b><br>
</a><br>
</li>
</ul>
<p><font size="2">Last updated 1/31/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p><font size="2">Last updated 2/5/2003 - <a href="support.htm">Tom Eastep</a></font></p>
<p align="left"><font face="Trebuchet MS"><a href="copyright.htm"> <font
size="2">Copyright</font> © <font size="2">2001-2003 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
<br>
</body>
</html>

486
Shorewall-docs/sourceforge_index.htm
View File

@ -40,6 +40,7 @@
<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"
@ -108,6 +109,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
@ -123,6 +125,7 @@
<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
@ -131,19 +134,19 @@ the GNU General Public License</a> as published by the Free Software
<br>
This program is distributed in
the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty
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>
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,
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>
@ -156,6 +159,7 @@ MA 02139, USA</p>
<p><a href="copyright.htm">Copyright 2001, 2002, 2003 Thomas M. Eastep</a></p>
@ -168,21 +172,23 @@ MA 02139, USA</p>
<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>
Wolzak have a LEAF (router/firewall/gateway on
a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.10
and Kernel-2.4.18. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques and
Eric on the recent release of Bering 1.0 Final!!! <br>
</b>
<h2>News</h2>
@ -197,41 +203,12 @@ Eric on the recent release of Bering 1.0 Final!!! <br>
<p><b>2/4/2003 - Shorewall 1.3.14-RC1</b><b> </b><b><img
<p><b>2/8/2003 - Shoreawll 1.3.14</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 2 content plus support for OpenVPN tunnels.<br>
</p>
<p> The release candidate may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top"><br>
ftp://ftp.shorewall.net/pub/shorewall/Beta</a></blockquote>
<p></p>
<p><b>1/28/2003 - Shorewall 1.3.14-Beta2 </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
<p>Includes the Beta 1 content plus restores VLAN device names of the
form $dev.$vid (e.g., eth0.1)</p>
<p> The beta may be downloaded from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/25/2003 - Shorewall 1.3.14-Beta1</b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
 </b><br>
</p>
<p>The Beta includes the following changes:<br>
</p>
<p>New features include</p>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
@ -244,16 +221,23 @@ in shorewall.conf and the 'noping' and 'filterping' options in /etc/shorewall/
will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
<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>When an interface name is entered in the SUBNET column of
the /etc/shorewall/masq file, Shorewall previously masqueraded traffic from
<li>Support for OpenVPN Tunnels.<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID (e.g.,
eth0.0)<br>
<br>
</li>
<li>When an interface name is entered in the SUBNET column of the
/etc/shorewall/masq file, Shorewall previously masqueraded traffic from
only the first subnet defined on that interface. It did not masquerade
traffic from:<br>
 <br>
@ -286,7 +270,8 @@ on subnetworks that you don't wish to masquerade.<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]#<br></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>
@ -295,381 +280,31 @@ on subnetworks that you don't wish to masquerade.<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]# <br></pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
The beta may be downloaded from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a href="ftp://ftp.shorewall.net/pub/shorewall/Beta">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format</b><b> </b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13
documenation. the PDF may be downloaded from</p>
    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a>
<p><b>1/17/2003 - shorewall.net has MOVED</b><b> </b><b>  </b></p>
<p>Thanks to the generosity of Alex Martin and <a
href="http://www.rettc.com">Rett Consulting</a>, www.shorewall.net and ftp.shorewall.net
are now hosted on a system in Bellevue, Washington. A big thanks to Alex
for making this happen.<br>
</p>
<p><b>1/13/2003 - Shorewall 1.3.13</b><b> </b><b><img border="0"
src="images/new10.gif" width="28" height="12" alt="(New)">
</b><br>
</p>
<p>Just includes a few things that I had on the burner:<br>
</p>
<ol>
<li>A new 'DNAT-' action has been added for entries in the
/etc/shorewall/rules file. DNAT- is intended for advanced users who wish
to minimize the number of rules that connection requests must traverse.<br>
<br>
A Shorewall DNAT rule actually generates two iptables rules: a header
rewriting rule in the 'nat' table and an ACCEPT rule in the 'filter'
table. A DNAT- rule only generates the first of these rules. This is
handy when you have several DNAT rules that would generate the same ACCEPT
rule.<br>
<br>
   Here are three rules from my previous rules file:<br>
<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.178<br>
        DNAT   net  dmz:206.124.146.177 tcp smtp - 206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,...<br>
<br>
   These three rules ended up generating _three_ copies of<br>
<br>
         ACCEPT net  dmz:206.124.146.177 tcp smtp<br>
<br>
   By writing the rules this way, I end up with only one copy of
the ACCEPT rule.<br>
<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.178<br>
        DNAT-  net  dmz:206.124.146.177 tcp smtp -  206.124.146.179<br>
        ACCEPT net  dmz:206.124.146.177 tcp www,smtp,ftp,....<br>
<br>
</li>
<li>The 'shorewall check' command now prints out the applicable
policy between each pair of zones.<br>
<br>
</li>
<li>A new CLEAR_TC option has been added to shorewall.conf.
If this option is set to 'No' then Shorewall won't clear the current traffic
control rules during [re]start. This setting is intended for use by people
that prefer to configure traffic shaping when the network interfaces
come up rather than when the firewall is started. If that is what you
want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart
file. That way, your traffic shaping rules can still use the 'fwmark'
classifier based on packet marking defined in /etc/shorewall/tcrules.<br>
<br>
</li>
<li>A new SHARED_DIR variable has been added that allows
distribution packagers to easily move the shared directory (default /usr/lib/shorewall).
Users should never have a need to change the value of this shorewall.conf
setting.</li>
</ol>
<p><b>1/6/2003 - </b><b><big><big><big><big><big><big><big><big>B</big></big></big></big></big><small>U<small>R<small>N<small>O<small>U<small>T</small></small></small></small></small></small></big></big></big></b><b>
<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>
<p><b>Until further notice, I will not be involved in either Shorewall
Development or Shorewall Support</b></p>
<p><b>-Tom Eastep</b><br>
</p>
<p><b>12/30/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/"
target="_self">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>12/27/2002 - Shorewall 1.3.12 Released</b><b>
</b></p>
<p> Features include:<br>
</p>
<ol>
<li>"shorewall refresh" now reloads the traffic shaping
rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off debugging
after an error occurs. This places the point of the failure near
the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up by
more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has been
added which shows the current packet classification filters. The
output from this command is also added as a separate page in "shorewall
monitor"</li>
<li>ULOG (must be all caps) is now accepted as a
valid syslog level and causes the subject packets to be logged using
the ULOG target rather than the LOG target. This allows you to run
ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD
chain in the mangle table ("shorewall show mangle" will show you
the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in <a href="Documentation.htm#Conf">shorewall.conf</a>. This allows for
marking input packets based on their destination even when you are
using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you
already have a file with one of these names, don't worry -- the upgrade
process won't overwrite your file.</li>
<li>I have added a new RFC1918_LOG_LEVEL variable
to <a href="Documentation.htm#Conf">shorewall.conf</a>. This variable
specifies the syslog level at which packets are logged as a result
of entries in the /etc/shorewall/rfc1918 file. Previously, these packets
were always logged at the 'info' level.</li>
</ol>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 3</b><br>
</p>
This version corrects a problem with Blacklist logging.
In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the
firewall would fail to start and "shorewall refresh" would also fail.<br>
<p> You may download the Beta from:<br>
</p>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/20/2002 - Shorewall 1.3.12 Beta 2</b><b>
</b></p>
The first public Beta version of Shorewall 1.3.12 is
now available (Beta 1 was made available only to a limited audience).
<br>
<br>
Features include:<br>
<br>
<ol>
<li>"shorewall refresh" now reloads the traffic
shaping rules (tcrules and tcstart).</li>
<li>"shorewall debug [re]start" now turns off
debugging after an error occurs. This places the point of the failure
near the end of the trace rather than up in the middle of it.</li>
<li>"shorewall [re]start" has been speeded up
by more than 40% with my configuration. Your milage may vary.</li>
<li>A "shorewall show classifiers" command has
been added which shows the current packet classification filters.
The output from this command is also added as a separate page in
"shorewall monitor"</li>
<li>ULOG (must be all caps) is now accepted
as a valid syslog level and causes the subject packets to be logged
using the ULOG target rather than the LOG target. This allows you to
run ulogd (available from <a
href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd</a>)
and log all Shorewall messages <a
href="shorewall_logging.html">to a separate log file</a>.</li>
<li>If you are running a kernel that has a FORWARD
chain in the mangle table ("shorewall show mangle" will show you
the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes
in shorewall.conf. This allows for marking input packets based on
their destination even when you are using Masquerading or SNAT.</li>
<li>I have cluttered up the /etc/shorewall directory
with empty 'init', 'start', 'stop' and 'stopped' files. If you already
have a file with one of these names, don't worry -- the upgrade process
won't overwrite your file.</li>
</ol>
You may download the Beta from:<br>
<blockquote><a href="http://www.shorewall.net/pub/shorewall/Beta">http://www.shorewall.net/pub/shorewall/Beta</a><br>
<a
href="ftp://ftp.shorewall.net/pub/shorewall/Beta" target="_top">ftp://ftp.shorewall.net/pub/shorewall/Beta</a><br>
</blockquote>
<p><b>12/12/2002 - Mandrake Multi Network Firewall <a
href="http://www.mandrakesoft.com"><img src="images/logo2.png"
alt="Powered by Mandrake Linux" width="150" height="23" border="0">
</a></b></p>
Shorewall is at the center of MandrakeSofts's recently-announced
<a
href="http://www.mandrakestore.com/mdkinc/index.php?PAGE=tab_0/menu_0.php&amp;id_art=250&amp;LANG_=en#GOTO_250">Multi
Network Firewall (MNF)</a> product. Here is the <a
href="http://www.mandrakesoft.com/company/press/pr?n=/pr/products/2403">press
release</a>.<br>
<p><b>12/7/2002 - Shorewall Support for Mandrake 9.0</b><b>
</b></p>
<p>Two months and 3 days after I pre-ordered Mandrake 9.0, it was finally
delivered. I have installed 9.0 on one of my systems and I am
now in a position to support Shorewall users who run Mandrake 9.0.</p>
<p><b>12/6/2002 -  Debian 1.3.11a Packages Available</b><b></b><br>
</p>
<p>Apt-get sources listed at <a
href="http://security.dsi.unimi.it/%7Elorenzo/debian.html">http://security.dsi.unimi.it/~lorenzo/debian.html.</a></p>
<p><b>12/3/2002 - Shorewall 1.3.11a</b><b>
</b></p>
<p>This is a bug-fix roll up which includes Roger Aich's fix for DNAT
with excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11
users who don't need rules of this type need not upgrade to 1.3.11.</p>
<p><b>11/25/2002 - Shorewall 1.3.11 Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.11
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</p>
<p><b>11/24/2002 - Shorewall 1.3.11</b><b>
</b></p>
<p>In this version:</p>
<ul>
<li>A 'tcpflags' option has been
added to entries in <a
href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>.
This option causes Shorewall to make a set of sanity check on TCP
packet header flags.</li>
<li>It is now allowed to use 'all'
in the SOURCE or DEST column in a <a
href="Documentation.htm#Rules">rule</a>. When used, 'all' must appear
by itself (in may not be qualified) and it does not enable intra-zone
traffic. For example, the rule <br>
<br>
    ACCEPT loc all tcp 80<br>
<br>
does not enable http traffic from 'loc'
to 'loc'.</li>
<li>Shorewall's use of the 'echo'
command is now compatible with bash clones such as ash and dash.</li>
<li>fw-&gt;fw policies now generate
a startup error. fw-&gt;fw rules generate a warning and are
ignored</li>
</ul>
<p><b>11/14/2002 - Shorewall Documentation in PDF Format</b><b>
</b></p>
<p>Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10
documenation. the PDF may be downloaded from</p>
<p>    <a
href="ftp://slovakia.shorewall.net/mirror/shorewall/pdf/" target="_top">ftp://slovakia.shorewall.net/mirror/shorewall/pdf/</a><br>
    <a
href="http://slovakia.shorewall.net/pub/shorewall/pdf/">http://slovakia.shorewall.net/pub/shorewall/pdf/</a><br>
</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>
@ -686,7 +321,8 @@ command is now compatible with bash clones such as ash and dash.</
<p><b></b><a href="News.htm">More News</a></p>
<p><a href="News.htm">More News</a></p>
@ -726,13 +362,14 @@ command is now compatible with bash clones such as ash and dash.</
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
valign="top" align="center"> <br>
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <br>
</td>
</tr>
@ -761,7 +398,8 @@ command is now compatible with bash clones such as ash and dash.</
<tr>
<td width="100%" style="margin-top: 1px;">
<td width="100%"
style="margin-top: 1px;">
@ -787,11 +425,11 @@ command is now compatible with bash clones such as ash and dash.</
<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>
@ -808,12 +446,10 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/4/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/7/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
<br>
<br>
<br>
</body>
</html>

74
Shorewall-docs/support.htm
View File

@ -32,6 +32,7 @@
<h1 align="center"><font color="#ffffff">Shorewall Support<img
src="images/obrasinf.gif" alt="" width="90" height="90" align="middle">
</font></h1>
@ -50,8 +51,14 @@ on the Shorewall Users Mailing List.</font></big><span
<h2 align="center"><big><font color="#ff0000"><b>-Tom Eastep</b></font></big></h2>
<h1>Before Reporting a Problem</h1>
There are a number of sources for problem
solution information. Please try these before you post.
<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>
There are a number of sources for
problem solution information. Please try these before you post.
<h3> </h3>
@ -89,8 +96,8 @@ list have answers directly accessible from the <a
<h3> </h3>
<ul>
<li> The Mailing List Archives
search facility can locate posts about similar problems:
<li> The Mailing List
Archives search facility can locate posts about similar problems:
</li>
</ul>
@ -125,8 +132,8 @@ list have answers directly accessible from the <a
<option value="revtime">Reverse Time </option>
<option value="revtitle">Reverse Title </option>
</select>
</font> <input type="hidden" name="config"
value="htdig"> <input type="hidden" name="restrict"
</font> <input type="hidden"
name="config" value="htdig"> <input type="hidden" name="restrict"
value="[http://lists.shorewall.net/pipermail/.*]"> <input type="hidden"
name="exclude" value=""> <br>
Search: <input type="text" size="30"
@ -139,10 +146,10 @@ list have answers directly accessible from the <a
and when you walk into one of the rooms, you detect this strange smell.
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the smell
and even what's causing it. You would be absolutely amazed at the
range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed
at the range and variety of smells we could come up with. Even more
amazing is that all of the explanations for the smells would be completely
plausible."<br>
</i><br>
@ -175,8 +182,8 @@ summary.<br>
do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include this
information:</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
this information:</li>
</ul>
@ -225,7 +232,15 @@ summary.<br>
<br>
</li>
<li>the exact wording of any <code
style="color: green; font-weight: bold;">ping</code> failure responses.<br>
style="color: green; font-weight: bold;">ping</code> failure responses<br>
<br>
</li>
<li>If you installed Shorewall using one of the QuickStart Guides, please
indicate which one. <br>
<br>
</li>
<li><b>If you are running Shorewall under Mandrake using the Mandrake
installation of Shorewall, please say so.</b><br>
<br>
</li>
@ -236,12 +251,13 @@ summary.<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 please post the exact output of<br>
problems of any kind, post the exact output of<br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
<br>
</font></b>Since that command generates a lot of output, we suggest
that you redirect the output to a file and attach the file to your post<br>
</font></b>Since that command generates a lot of output, we
suggest that you redirect the output to a file and attach the file to
your post<br>
<br>
<b><font color="#009900">/sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
<br>
@ -291,8 +307,8 @@ so, include the message(s) in your post along with a copy of your /etc/shorewa
<h3> </h3>
<ul>
<li> If an error occurs when
you try to "<font color="#009900"><b>shorewall start</b></font>",
<li> If an error occurs
when you try to "<font color="#009900"><b>shorewall start</b></font>",
include a trace (See the <a href="troubleshoot.htm">Troubleshooting</a>
section for instructions). </li>
@ -319,17 +335,17 @@ found at <a
<blockquote> </blockquote>
A growing number of MTAs serving list subscribers are rejecting
all HTML traffic. At least one MTA has gone so far as to blacklist shorewall.net
"for continuous abuse" because it has been my policy to allow HTML in list
posts!!<br>
"for continuous abuse" because it has been my policy to allow HTML in
list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one list
subscriber wrote to me privately "These e-mail admin's need to get a <i>(expletive
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
from outgoing posts.<br>
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>
@ -357,7 +373,7 @@ list.</a></p>
.</p>
<p align="left"><font size="2">Last Updated 2/3/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 2/4/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>
@ -365,5 +381,7 @@ list.</a></p>
<br>
<br>
<br>
<br>
<br>
</body>
</html>