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

Sync with CVS

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@473 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-02-25 19:26:18 +00:00
parent 15607eeb96
commit 70b9971612
10 changed files with 4726 additions and 4431 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

411
STABLE/documentation/FAQ.htm
View File

@ -70,13 +70,13 @@
<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>
each other using their external (non-RFC1918 addresses) so
they <b>can't access each other using their DNS names.</b></a></p>
<p align="left"><b>3. </b><a href="#faq3">I want to use <b>Netmeeting</b>
or <b>MSN Instant Messenger </b>with Shorewall. What do
I do?</a></p>
or <b>MSN Instant Messenger </b>with Shorewall. What
do I do?</a></p>
<p align="left"><b>4. </b><a href="#faq4">I just used an online port scanner
@ -113,9 +113,10 @@ from logging in Shorewall?</a><br>
<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>
</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
'shorewall stop', I can't connect to anything</b>. Why doesn't that command
work?</a></p>
@ -133,7 +134,7 @@ in Shorewall log messages <b>so long</b>? I thought MAC addresses were only
<p align="left"><b>11. </b><a href="#faq18">What <b>features</b> does it
support?</a></p>
support?</a></p>
<p align="left"><b>12. </b><a href="#faq12">Is there a <b>GUI?</b></a></p>
@ -144,15 +145,15 @@ support?</a></p>
<p align="left"><b>14. </b><a href="#faq14">I'm connected via a cable modem
and it has an internel web server that allows me to configure/monitor
it but as expected if I enable <b> rfc1918 blocking</b> for
my eth0 interface, it also blocks the <b>cable modems web
server</b></a>.</p>
it but as expected if I enable <b> rfc1918 blocking</b>
for my eth0 interface, it also blocks the <b>cable modems
web server</b></a>.</p>
<p align="left"><b>14a. </b><a href="#faq14a">Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address.
If I enable RFC 1918 filtering on my external interface, <b>my
DHCP client cannot renew its lease</b>.</a></p>
If I enable RFC 1918 filtering on my external interface,
<b>my DHCP client cannot renew its lease</b>.</a></p>
<p align="left"><b>15. </b><a href="#faq15"><b>My local systems can't see
@ -163,11 +164,11 @@ server</b></a>.</p>
all over my console</b> making it unusable!<br>
</a></p>
<b>17</b>. <a
href="#faq17">How do I find out <b>why this traffic is</b>
getting <b>logged?</b></a><br>
href="#faq17">How do I find out <b>why this traffic is</b> getting
<b>logged?</b></a><br>
<br>
<b>18.</b> <a href="#faq18">Is there any way
to use <b>aliased ip addresses</b> with Shorewall, and maintain
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
@ -175,22 +176,26 @@ to use <b>aliased ip addresses</b> with Shorewall, and maintain
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
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>
</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>
let's say the ssh port only<b> from specific IP Addresses</b> on the
internet?</a><br>
<br>
<b>25. </b><a href="#faq25">How to I tell <b>which version of Shorewall</b>
I am <b>running</b>?</a><br>
<br>
<hr>
<h4 align="left"><a name="faq1"></a>1. I want to forward UDP port 7777 to
@ -318,7 +323,7 @@ let's say the ssh port only<b> from specific IP Addresses</b> on the interne
</table>
</blockquote>
Finally, if you need to forward a range of ports, in the PORT column specify
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
@ -329,13 +334,13 @@ the range as <i>low-port</i>:<i>high-port</i>.<br>
<ul>
<li>You are trying to test from inside
your firewall (no, that won't work -- see <a
<li>You are trying to test from
inside your firewall (no, that won't work -- see <a
href="#faq2">FAQ #2</a>).</li>
<li>You have a more basic problem
with your local system such as an incorrect default gateway
configured (it should be set to the IP address of your firewall's
internal interface).</li>
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>
@ -348,18 +353,18 @@ internal interface).</li>
<ul>
<li>As root, type "iptables -t nat -Z". This
clears the NetFilter counters in the nat table.</li>
<li>Try to connect to the redirected port from
an external host.</li>
<li>Try to connect to the redirected port
from an external host.</li>
<li>As root type "shorewall show nat"</li>
<li>Locate the appropriate DNAT rule. It will
be in a chain called <i>&lt;source zone&gt;</i>_dnat ('net_dnat'
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>
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>
@ -371,9 +376,9 @@ the firewall's interface to the server).</li>
the primary IP address (You need to specify the secondary IP address
in the "ORIG. DEST." column in your DNAT rule); or</li>
<li>your DNAT rule doesn't match the connection
request in some other way. In that case, you may have to use a
packet sniffer such as tcpdump or ethereal to further diagnose the
problem.<br>
request in some other way. In that case, you may have to use
a packet sniffer such as tcpdump or ethereal to further diagnose
the problem.<br>
</li>
@ -382,9 +387,9 @@ the primary IP address (You need to specify the secondary IP address
</ul>
<h4 align="left"><a name="faq2"></a>2. I port forward www requests to www.mydomain.com
(IP 130.151.100.69) to system 192.168.1.5 in my local network.
External clients can browse http://www.mydomain.com but internal
clients can't.</h4>
(IP 130.151.100.69) to system 192.168.1.5 in my local
network. External clients can browse http://www.mydomain.com
but internal clients can't.</h4>
<p align="left"><b>Answer: </b>I have two objections to this setup.</p>
@ -392,18 +397,18 @@ the primary IP address (You need to specify the secondary IP address
<ul>
<li>Having an internet-accessible
server in your local network is like raising foxes in the
corner of your hen house. If the server is compromised, there's
nothing between that server and your other internal systems.
For the cost of another NIC and a cross-over cable, you can put
your server in a DMZ such that it is isolated from your local
systems - assuming that the Server can be located near the Firewall,
of course :-)</li>
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
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>
@ -412,13 +417,14 @@ externally and 192.168.1.5 internally. That's what I do here at
<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,
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>
for eth1 (No longer required as of Shorewall version
1.3.9).</p>
<div align="left">
@ -463,8 +469,8 @@ externally and 192.168.1.5 internally. That's what I do here at
<div align="left">
<p align="left">That rule only works of course if you have a static external
IP address. If you have a dynamic IP address and are running
Shorewall 1.3.4 or later then include this in /etc/shorewall/params:</p>
IP address. If you have a dynamic IP address and are
running Shorewall 1.3.4 or later then include this in /etc/shorewall/params:</p>
</div>
@ -523,24 +529,24 @@ externally and 192.168.1.5 internally. That's what I do here at
<h4 align="left"><a name="faq2a"></a>2a. I have a zone "Z" with an RFC1918
subnet and I use static NAT to assign non-RFC1918 addresses
to hosts in Z. Hosts in Z cannot communicate with each other
using their external (non-RFC1918 addresses) so they can't access
each other using their DNS names.</h4>
using their external (non-RFC1918 addresses) so they can't
access each other using their DNS names.</h4>
<p align="left"><b>Answer: </b>This is another problem that is best solved
using Bind Version 9 "views". It allows both external and
internal clients to access a NATed host using the host's DNS
name.</p>
using Bind Version 9 "views". It allows both external
and internal clients to access a NATed host using the host's
DNS name.</p>
<p align="left">Another good way to approach this problem is to switch from
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>
non-RFC1918 addresses and can be accessed externally and internally
using the same address. </p>
<p align="left">If you don't like those solutions and prefer routing all Z-&gt;Z
traffic through your firewall then:</p>
<p align="left">If you don't like those solutions and prefer routing all
Z-&gt;Z traffic through your firewall then:</p>
<p align="left">a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
@ -653,10 +659,10 @@ traffic through your firewall then:</p>
<p align="left"><b>Answer: </b>There is an <a
href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection
tracking/NAT module</a> that may help with Netmeeting. Look
<a href="http://linux-igd.sourceforge.net">here</a> for a solution for
MSN IM but be aware that there are significant security risks involved with
this solution. Also check the Netfilter mailing list archives
tracking/NAT module</a> that may help with Netmeeting.
Look <a href="http://linux-igd.sourceforge.net">here</a> for a solution
for MSN IM but be aware that there are significant security risks involved
with this solution. Also check the Netfilter mailing list archives
at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
</p>
@ -667,20 +673,21 @@ this solution. Also check the Netfilter mailing list archives
<p align="left"><b>Answer: </b>The common.def included with version 1.3.x
always rejects connection requests on TCP port 113 rather
than dropping them. This is necessary to prevent outgoing
connection problems to services that use the 'Auth' mechanism
for identifying requesting users. Shorewall also rejects TCP
ports 135, 137 and 139 as well as UDP ports 137-139. These are
ports that are used by Windows (Windows <u>can</u> be configured
to use the DCE cell locator on port 135). Rejecting these connection
requests rather than dropping them cuts down slightly on the amount
of Windows chatter on LAN segments connected to the Firewall. </p>
always rejects connection requests on TCP port 113
rather than dropping them. This is necessary to prevent
outgoing connection problems to services that use the 'Auth'
mechanism for identifying requesting users. Shorewall also
rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139.
These are ports that are used by Windows (Windows <u>can</u>
be configured to use the DCE cell locator on port 135). Rejecting
these connection requests rather than dropping them cuts down
slightly on the amount of Windows chatter on LAN segments connected
to the Firewall. </p>
<p align="left">If you are seeing port 80 being 'closed', that's probably
your ISP preventing you from running a web server in
violation of your Service Agreement.</p>
violation of your Service Agreement.</p>
<h4 align="left"><a name="faq4a"></a>4a. I just ran an nmap UDP scan of my
@ -689,10 +696,10 @@ violation of your Service Agreement.</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
change your net-&gt;all policy to REJECT, restart Shorewall and
do the nmap UDP scan again.</p>
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
@ -717,26 +724,26 @@ If you want to see which UDP ports are really open, temporarily
</p>
</blockquote>
For a complete description of Shorewall 'ping' management,
see <a href="ping.html">this page</a>.
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
syslog") in your <a href="Documentation.htm#Policy">policies</a> and <a
href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
<p align="left"><b>Answer: </b>NetFilter uses the kernel's equivalent of
syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern)
facility (see "man openlog") and you get to choose the log level (again,
see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
and <a href="Documentation.htm#Rules">rules</a>. The destination for messaged
logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
When you have changed /etc/syslog.conf, be sure to restart
syslogd (on a RedHat system, "service syslog restart"). </p>
<p align="left">By default, older versions of Shorewall ratelimited log messages
through <a href="Documentation.htm#Conf">settings</a> in
/etc/shorewall/shorewall.conf -- If you want to log all messages,
set: </p>
through <a href="Documentation.htm#Conf">settings</a>
in /etc/shorewall/shorewall.conf -- If you want to log
all messages, set: </p>
<div align="left">
@ -757,7 +764,8 @@ logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf").
<p align="left"><a
href="http://www.shorewall.net/pub/shorewall/parsefw/"> http://www.shorewall.net/pub/shorewall/parsefw/</a><br>
<a href="http://www.fireparse.com">http://www.fireparse.com</a><br>
<a
href="http://www.fireparse.com">http://www.fireparse.com</a><br>
<a
href="http://cert.uni-stuttgart.de/projects/fwlogwatch">http://cert.uni-stuttgart.de/projects/fwlogwatch</a><a
href="http://www.logwatch.org"><br>
@ -777,8 +785,8 @@ activity on the corresponding system.
<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>
@ -789,7 +797,7 @@ get dropped, but what the heck are they?</h4>
</ol>
You can distinguish the difference by setting the <b>logunclean</b>
option (<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
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>
@ -797,18 +805,21 @@ option (<a href="Documentation.htm#Interfaces">/etc/shorewall/interfaces</a>)
<blockquote>
<pre>#<br># Include the standard common.def file<br>#<br>. /etc/shorewall/common.def<br>#<br># The following rule is non-standard and compensates for tardy<br># DNS replies<br>#<br>run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP</pre>
</blockquote>
The above file is also include in all of my sample configurations available
in the <a href="shorewall_quickstart_guide.htm">Quick Start Guides</a>.<br>
The above file is also include in all of my sample configurations
available in the <a href="shorewall_quickstart_guide.htm">Quick Start
Guides</a>.<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>
in length. What is labeled as the MAC address in a Shorewall log message is
actually the Ethernet frame header. In contains:<br>
</h4>
<ul>
<li>the destination MAC address (6 bytes)</li>
<li>the source MAC address (6 bytes)</li>
<li>the ethernet frame type (2 bytes)</li>
</ul>
Example:<br>
<br>
@ -818,7 +829,9 @@ is actually the Ethernet frame header. In contains:<br>
<li>Destination MAC address = 00:04:4c:dc:e2:28</li>
<li>Source MAC address = 00:b0:8e:cf:3c:4c</li>
<li>Ethernet Frame Type = 08:00 (IP Version 4)</li>
</ul>
<h4 align="left"><a name="faq7"></a>7. When I stop Shorewall using 'shorewall
stop', I can't connect to anything. Why doesn't that command
work?</h4>
@ -878,9 +891,9 @@ is actually the Ethernet frame header. In contains:<br>
<div align="left">
<p align="left"><b>Answer: </b>The above output is perfectly normal. The Net
zone is defined as all hosts that are connected through eth0 and the local
zone is defined as all hosts connected through eth1</p>
<p align="left"><b>Answer: </b>The above output is perfectly normal. The
Net zone is defined as all hosts that are connected through eth0 and the
local zone is defined as all hosts connected through eth1</p>
</div>
@ -889,7 +902,9 @@ is actually the Ethernet frame header. In contains:<br>
<p align="left">Shorewall works with any GNU/Linux distribution that includes
the <a href="shorewall_prerequisites.htm">proper prerequisites</a>.</p>
the <a href="shorewall_prerequisites.htm">proper
prerequisites</a>.</p>
<h4 align="left">11. What Features does it have?</h4>
@ -897,37 +912,42 @@ is actually the Ethernet frame header. In contains:<br>
<p align="left"><b>Answer: </b>See the <a href="shorewall_features.htm">Shorewall
Feature List</a>.</p>
<h4 align="left"><a name="faq12"></a>12. Is there a GUI?</h4>
<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>
1.060 and later versions. See <a href="http://www.webmin.com">http://www.webmin.com</a>
</p>
<h4 align="left"> <a name="faq13"></a>13. Why do you call it "Shorewall"?</h4>
<p align="left"><b>Answer: </b>Shorewall is a concatenation of "<u>Shore</u>line"
(<a href="http://www.cityofshoreline.com">the city
where I live</a>) and "Fire<u>wall</u>". The full name of the
product is actually "Shoreline Firewall" but "Shorewall" is must more
commonly used.</p>
where I live</a>) and "Fire<u>wall</u>". The full name of
the product is actually "Shoreline Firewall" but "Shorewall" is must
more commonly used.</p>
<h4 align="left"> <a name="faq14"></a>14. I'm connected via a cable modem
and it has an internal web server that allows me to configure/monitor
it but as expected if I enable rfc1918 blocking for my eth0
interface (the internet one), it also blocks the cable modems
web server.</h4>
it but as expected if I enable rfc1918 blocking for my
eth0 interface (the internet one), it also blocks the cable
modems web server.</h4>
<p align="left">Is there any way it can add a rule before the rfc1918 blocking
that will let all traffic to and from the 192.168.100.1
address of the modem in/out but still block all other rfc1918
addresses?</p>
address of the modem in/out but still block all other rfc1918
addresses?</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall earlier
than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<p align="left"><b>Answer: </b>If you are running a version of Shorewall
earlier than 1.3.1, create /etc/shorewall/start and in it, place the
following:</p>
<div align="left">
<pre> run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT</pre>
@ -970,10 +990,11 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
</p>
<p align="left">Note: If you add a second IP address to your external firewall
interface to correspond to the modem address, you must also
make an entry in /etc/shorewall/rfc1918 for that address. For
example, if you configure the address 192.168.100.2 on your firewall,
then you would add two entries to /etc/shorewall/rfc1918: <br>
interface to correspond to the modem address, you must
also make an entry in /etc/shorewall/rfc1918 for that address.
For example, if you configure the address 192.168.100.2 on your
firewall, then you would add two entries to /etc/shorewall/rfc1918:
<br>
</p>
<blockquote>
@ -1009,10 +1030,10 @@ than 1.3.1, create /etc/shorewall/start and in it, place the following:</p>
<div align="left">
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public IP
addresses, my ISP's DHCP server has an RFC 1918 address. If I enable RFC
1918 filtering on my external interface, my DHCP client cannot renew its
lease.</h4>
<h4 align="left"><a name="faq14a"></a>14a. Even though it assigns public
IP addresses, my ISP's DHCP server has an RFC 1918 address. If I enable
RFC 1918 filtering on my external interface, my DHCP client cannot renew
its lease.</h4>
</div>
@ -1027,10 +1048,10 @@ lease.</h4>
<p align="left"><b>Answer: </b>Every time I read "systems can't see out to
the net", I wonder where the poster bought computers with
eyes and what those computers will "see" when things are working
properly. That aside, the most common causes of this problem
are:</p>
the net", I wonder where the poster bought computers
with eyes and what those computers will "see" when things
are working properly. That aside, the most common causes of
this problem are:</p>
<ol>
@ -1073,13 +1094,13 @@ lease.</h4>
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
logged?</h4>
<b>Answer: </b>Logging occurs out of a number
of chains (as indicated in the log message) in Shorewall:<br>
<b>Answer: </b>Logging occurs out of a
number of chains (as indicated in the log message) in Shorewall:<br>
<ol>
<li><b>man1918 - </b>The destination address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>man1918 - </b>The destination
address is listed in /etc/shorewall/rfc1918 with a <b>logdrop
</b>target -- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
<li><b>rfc1918</b> - The source address
is listed in /etc/shorewall/rfc1918 with a <b>logdrop </b>target
-- see <a href="Documentation.htm#rfc1918">/etc/shorewall/rfc1918.</a></li>
@ -1091,13 +1112,13 @@ lease.</h4>
href="Documentation.htm#Rules">rule</a> to that effect.<br>
</li>
<li><b>&lt;zone1&gt;2&lt;zone2&gt; </b>-
Either you have a<a href="Documentation.htm#Policy"> policy</a> for
<b>&lt;zone1&gt; </b>to <b>&lt;zone2&gt;</b> that specifies
a log level and this packet is being logged under that policy
or this packet matches a <a href="Documentation.htm#Rules">rule</a>
that includes a log level.</li>
Either you have a<a href="Documentation.htm#Policy"> policy</a>
for <b>&lt;zone1&gt; </b>to <b>&lt;zone2&gt;</b> that
specifies a log level and this packet is being logged under
that policy or this packet matches a <a
href="Documentation.htm#Rules">rule</a> that includes a log level.</li>
<li><b>&lt;interface&gt;_mac</b> - The packet
is being logged under the <b>maclist</b> <a
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
@ -1106,22 +1127,24 @@ is being logged under the <b>maclist</b> <a
<li><b>badpkt </b>- The packet is being
logged under the <b>dropunclean</b> <a
href="Documentation.htm#Interfaces">interface option</a> as specified
in the <b>LOGUNCLEAN </b>setting in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
in the <b>LOGUNCLEAN </b>setting in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
<li><b>blacklst</b> - The packet is being
logged because the source IP is blacklisted in the<a
href="Documentation.htm#Blacklist"> /etc/shorewall/blacklist </a>file.</li>
<li><b>newnotsyn </b>- The packet is being
logged because it is a TCP packet that is not part of any current
connection yet it is not a syn packet. Options affecting the logging
of such packets include <b>NEWNOTSYN </b>and <b>LOGNEWNOTSYN
</b>in <a href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>newnotsyn </b>- The packet is
being logged because it is a TCP packet that is not part of
any current connection yet it is not a syn packet. Options affecting
the logging of such packets include <b>NEWNOTSYN </b>and
<b>LOGNEWNOTSYN </b>in <a
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
<li><b>INPUT</b> or <b>FORWARD</b> - The
packet has a source IP address that isn't in any of your defined
zones ("shorewall check" and look at the printed zone definitions)
or the chain is FORWARD and the destination IP isn't in any of your
defined zones.</li>
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
because it failed the checks implemented by the <b>tcpflags </b><a
href="Documentation.htm#Interfaces">interface option</a>.<br>
</li>
@ -1133,8 +1156,9 @@ because it failed the checks implemented by the <b>tcpflags </b><a
<b>Answer: </b>Yes. You simply use the IP address
in your rules (or if you use NAT, use the local IP address in
your rules). <b>Note:</b> The ":n" notation (e.g., eth0:0) is deprecated
and will disappear eventually. Neither iproute (ip and tc) nor
iptables supports that notation so neither does Shorewall. <br>
and will disappear eventually. Neither iproute (ip and tc)
nor iptables supports that notation so neither does Shorewall.
<br>
<br>
<b>Example 1:</b><br>
<br>
@ -1168,9 +1192,9 @@ because it failed the checks implemented by the <b>tcpflags </b><a
to change Shorewall to allow access to my server from the internet?</b><br>
</h4>
Yes. Consult the <a
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that
you used during your initial setup for information about how to set
up rules for your server.<br>
href="shorewall_quickstart_guide.htm">QuickStart guide</a> that you
used during your initial setup for information about how to set up
rules for your server.<br>
<h4><a name="faq21"></a><b>21. </b>I see these <b>strange log entries </b>occasionally;
what are they?<br>
@ -1186,53 +1210,53 @@ you used during your initial setup for information about how to set
<b>Answer: </b>While most people associate the Internet
Control Message Protocol (ICMP) with 'ping', ICMP is a key piece
of the internet. ICMP is used to report problems back to the sender
of a packet; this is what is happening here. Unfortunately, where NAT
is involved (including SNAT, DNAT and Masquerade), there are a lot
of broken implementations. That is what you are seeing with these messages.<br>
of a packet; this is what is happening here. Unfortunately, where
NAT is involved (including SNAT, DNAT and Masquerade), there are
a lot of broken implementations. That is what you are seeing with these
messages.<br>
<br>
Here is my interpretation of what is happening -- to
confirm this analysis, one would have to have packet sniffers placed
a both ends of the connection.<br>
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,
that box correctly changes the source address in the packet to 206.124.146.179
but doesn't reset the DST IP in the original DNS response similarly.
When the ICMP reaches your firewall (192.0.2.3), your firewall has
no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't
appear to be related to anything that was sent. The final result is
that the packet gets logged and dropped in the all2all chain. I have also
seen cases where the source IP in the ICMP itself isn't set back to the
external IP of the remote NAT gateway; that causes your firewall to log
and drop the packet out of the rfc1918 chain because the source IP is
reserved by RFC 1918.<br>
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 appear to be related to anything that was sent.
The final result is that the packet gets logged and dropped in the
all2all chain. I have also seen cases where the source IP in the ICMP
itself isn't set back to the external IP of the remote NAT gateway; that
causes your firewall to log and drop the packet out of the rfc1918 chain
because the source IP is reserved by RFC 1918.<br>
<h4><a name="faq22"></a><b>22. </b>I have some <b>iptables commands </b>that
I want to <b>run when Shorewall starts.</b> Which file do I put them
in?</h4>
You can place these commands in one of the <a
href="shorewall_extension_scripts.htm">Shorewall Extension Scripts</a>.
Be sure that you look at the contents of the chain(s) that you will be modifying
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>
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>
<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>
@ -1243,15 +1267,24 @@ list of the host/subnet addresses as a comma-separated list.<br>
Example:<br>
<pre> ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22<br></pre>
<h4></h4>
<div align="left"> </div>
<font size="2">Last updated 2/6/2003 - <a
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>
<h4><b><a name="faq25"></a>25. </b>How to I tell <b>which version of Shorewall</b>
I am <b>running</b>?<br>
</h4>
At the shell prompt, type:<br>
<br>
<font color="#009900"><b>    /sbin/shorewall version</b></font><br>
<br>
<font size="2">Last updated 2/22/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>
</body>
</html>

901
STABLE/documentation/News.htm
View File

File diff suppressed because it is too large Load Diff

34
STABLE/documentation/Shorewall_Squid_Usage.html
View File

@ -45,16 +45,17 @@
as a transparent proxy as described at <a
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
<b><br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files /etc/shorewall/start
and /etc/shorewall/init -- if you don't have those files, siimply create
them.<br>
</b><b><img src="images/BD21298_3.gif" alt="" width="13"
height="13">
&nbsp;&nbsp;&nbsp; </b>The following instructions mention the files
/etc/shorewall/start and /etc/shorewall/init -- if you don't have those
files, siimply create them.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or in
the local zone, that zone must be defined ONLY by its interface -- no /etc/shorewall/hosts
file entries. That is because the packets being routed to the Squid server
still have their original destination IP addresses.<br>
</b>&nbsp;&nbsp;&nbsp; When the Squid server is in the DMZ zone or
in the local zone, that zone must be defined ONLY by its interface -- no
/etc/shorewall/hosts file entries. That is because the packets being routed
to the Squid server still have their original destination IP addresses.<br>
<br>
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
</b>&nbsp;&nbsp;&nbsp; You must have iproute2 (<i>ip </i>utility) installed
@ -69,7 +70,8 @@
/etc/shorewall/conf file<br>
<br>
&nbsp;&nbsp;&nbsp; <b><font color="#009900">&nbsp;&nbsp;&nbsp; NAT_ENABLED=Yes<br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
</font></b>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <font
color="#009900"><b>MANGLE_ENABLED=Yes</b></font><br>
<br>
Three different configurations are covered:<br>
@ -77,8 +79,9 @@
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on
the Firewall.</a></li>
<li><a href="Shorewall_Squid_Usage.html#Local">Squid running in the
local network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the DMZ</a></li>
local network</a></li>
<li><a href="Shorewall_Squid_Usage.html#DMZ">Squid running in the
DMZ</a></li>
</ol>
@ -147,7 +150,7 @@ local network</a></li>
<h2><a name="Local"></a>Squid Running in the local network</h2>
You want to redirect all local www connection requests to a Squid
transparent proxy
running in your local zone at 192.168.1.3 and listening on port 3128.
running in your local zone at 192.168.1.3 and listening on port 3128.
Your local interface is eth1. There may also be a web server running on
192.168.1.3. It is assumed that web access is already enabled from the local
zone to the internet.<br>
@ -321,11 +324,11 @@ zone to the internet.<br>
</ul>
<blockquote>
<pre><b><font color="#009900"> iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</font></b><br></pre>
<pre><b><font color="#009900"> iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202</font></b><br></pre>
</blockquote>
<blockquote>B) Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf
and add the following entry in /etc/shorewall/tcrules:<br>
and add the following entry in /etc/shorewall/tcrules:<br>
</blockquote>
<blockquote>
@ -477,7 +480,7 @@ and add the following entry in /etc/shorewall/tcrules:<br>
<blockquote> </blockquote>
<p><font size="-1"> Updated 1/23/2003 - <a href="support.htm">Tom Eastep</a>
<p><font size="-1"> Updated 2/22/2003 - <a href="support.htm">Tom Eastep</a>
</font></p>
@ -490,5 +493,6 @@ and add the following entry in /etc/shorewall/tcrules:<br>
<br>
<br>
<br>
<br>
</body>
</html>

176
STABLE/documentation/errata.htm
View File

@ -50,25 +50,26 @@
<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>
<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>
than 1.3.11, when the instructions say to install a corrected
firewall script in /etc/shorewall/firewall, /usr/lib/shorewall/firewall
or /var/lib/shorewall/firewall, use the 'cp' (or 'scp') utility to
overwrite the existing file. DO NOT REMOVE OR RENAME THE OLD
/etc/shorewall/firewall or /var/lib/shorewall/firewall before
you do that. /etc/shorewall/firewall and /var/lib/shorewall/firewall
are symbolic links that point to the 'shorewall' file used by
your system initialization scripts to start Shorewall during
boot. It is that file that must be overwritten with the corrected
script. Beginning with Shorewall 1.3.11, you may rename the existing file
before copying in the new file.</b></p>
</li>
<li>
@ -93,8 +94,8 @@ overwritten with the corrected script. Beginning with Shorewall
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>
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
@ -114,17 +115,22 @@ iptables</a></b></li>
<ul>
<li>There is an <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.14/rfc1918">updated
rfc1918</a> file that reflects the resent allocation of 222.0.0.0/8 and
223.0.0.0/8.</li>
rfc1918</a> file that reflects the resent allocation of 222.0.0.0/8 and 223.0.0.0/8.</li>
</ul>
<ul>
<li>The documentation for the routestopped file claimed that a comma-separated
list could appear in the second column while the code only supported a single
host or network address.</li>
<li>Log messages produced by 'logunclean' and 'dropunclean' were not rate-limited.</li>
<li>Log messages produced by 'logunclean' and 'dropunclean' were not
rate-limited.</li>
<li>802.11b devices with names of the form <i>wlan</i>&lt;n&gt; don't support
the 'maclist' interface option.<br>
</li>
</ul>
Both problems have been corrected in <a
These three problems have been corrected in <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.14/firewall">this
firewall script</a> which may be installed in /usr/lib/shorewall as described
above.<br>
@ -172,9 +178,9 @@ support, post on the users list and I can provide you with a patched version.<
<h3>Version 1.3.12 LRP</h3>
<ul>
<li>The .lrp was missing the /etc/shorewall/routestopped file --
a new lrp (shorwall-1.3.12a.lrp) has been released which corrects this
problem.<br>
<li>The .lrp was missing the /etc/shorewall/routestopped file
-- a new lrp (shorwall-1.3.12a.lrp) has been released which corrects
this problem.<br>
</li>
</ul>
@ -184,7 +190,8 @@ support, post on the users list and I can provide you with a patched version.<
<ul>
<li><a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/rfc1918">This
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of 82.0.0.0/8.<br>
copy of /etc/shorewall/rfc1918</a> reflects the recent allocation of
82.0.0.0/8.<br>
</li>
</ul>
@ -207,8 +214,9 @@ Shorewall fails to start.<br>
<br>
Install <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.11/firewall">this
corrected script</a> in /usr/lib/shorewall/firewall to correct this problem.
Thanks go to Roger Aich who analyzed this problem and provided a fix.<br>
corrected script</a> in /usr/lib/shorewall/firewall to correct this
problem. Thanks go to Roger Aich who analyzed this problem and provided
a fix.<br>
<br>
This problem is corrected in version 1.3.11a.<br>
</li>
@ -223,11 +231,11 @@ Shorewall fails to start.<br>
<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>
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>
@ -258,8 +266,8 @@ just a symbolic link to the real script.<br>
<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
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>
@ -267,8 +275,8 @@ file /etc/shorewall/functions. <a
</ul>
<h3>Version 1.3.9</h3>
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated firewall
script at <a
<b>TUNNELS Broken in 1.3.9!!! </b>There is an updated
firewall script at <a
href="ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall"
target="_top">ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall</a>
-- copy that file to /usr/lib/shorewall/firewall as described above.<br>
@ -277,9 +285,9 @@ file /etc/shorewall/functions. <a
<ul>
<li> Use of shell variables in the LOG LEVEL or SYNPARMS
columns of the policy file doesn't work.</li>
<li>A DNAT rule with the same original and new IP addresses
but with different port numbers doesn't work (e.g., "DNAT loc dmz:10.1.1.1:24
tcp 25 - 10.1.1.1")<br>
<li>A DNAT rule with the same original and new IP
addresses but with different port numbers doesn't work (e.g., "DNAT
loc dmz:10.1.1.1:24 tcp 25 - 10.1.1.1")<br>
</li>
</ul>
@ -297,7 +305,7 @@ file /etc/shorewall/functions. <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>
problem.</p>
<h3>Version 1.3.7a</h3>
@ -311,7 +319,7 @@ problem.</p>
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>
problem.</p>
<h3>Version &lt;= 1.3.7a</h3>
@ -328,13 +336,13 @@ problem.</p>
<ol>
<li>If the firewall
is running a DHCP server, the client
won't be able to obtain an IP address
is running a DHCP server, the
client won't be able to obtain an IP address
lease from that server.</li>
<li>With this order
of checking, the "dhcp" option cannot
be used as a noise-reduction measure
where there are both dynamic and static
of checking, the "dhcp" option
cannot be used as a noise-reduction
measure where there are both dynamic and static
clients on a LAN segment.</li>
</ol>
@ -373,7 +381,7 @@ described 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>
add an SNAT alias. </p>
</li>
<li>
@ -424,8 +432,8 @@ add an SNAT alias. </p>
possible to  include a single host specification on each line.
This problem is corrected by <a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.5a/firewall">this
modified 1.3.5a firewall script</a>. Install the script in /var/lib/pub/shorewall/firewall
as instructed above.</p>
modified 1.3.5a firewall script</a>. Install the script in
/var/lib/pub/shorewall/firewall as instructed above.</p>
</div>
<div align="left">
@ -444,10 +452,10 @@ add an SNAT alias. </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>
@ -455,25 +463,25 @@ it's a good idea to run that command after you have made configuratio
<p align="left">If you have upgraded from Shorewall 1.2 and after
"Activating rules..." you see the message: "iptables: No chains/target/match
by that name" then you probably have an entry in /etc/shorewall/hosts
that specifies an interface that you didn't include in
/etc/shorewall/interfaces. To correct this problem, you
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>
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>
<li>"NAT_BEFORE_RULES=No" was broken; it
behaved just like "NAT_BEFORE_RULES=Yes".</li>
<li>"NAT_BEFORE_RULES=No" was broken;
it behaved just like "NAT_BEFORE_RULES=Yes".</li>
</ul>
@ -500,8 +508,8 @@ case.</p>
<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>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
@ -512,15 +520,15 @@ case.</p>
<br>
Shorewall will ignore the 'dhcp' on eth1.</li>
<li>Update 17 June 2002 - The bug described
in the prior bullet affects the following options: dhcp,
dropunclean, logunclean, norfc1918, routefilter, multi,
filterping and noping. An additional bug has been found
that affects only the 'routestopped' option.<br>
in the prior bullet affects the following options:
dhcp, dropunclean, logunclean, norfc1918, routefilter,
multi, filterping and noping. An additional bug has been
found that affects only the 'routestopped' option.<br>
<br>
Users who downloaded the corrected script
prior to 1850 GMT today should download and install
the corrected script again to ensure that this second
problem is corrected.</li>
the corrected script again to ensure that this second
problem is corrected.</li>
</ul>
@ -533,12 +541,12 @@ problem is corrected.</li>
<ul>
<li>Folks who downloaded 1.3.0 from the
links on the download page before 23:40 GMT, 29 May
2002 may have downloaded 1.2.13 rather than 1.3.0. The
"shorewall version" command will tell you which version
links on the download page before 23:40 GMT, 29 May
2002 may have downloaded 1.2.13 rather than 1.3.0.
The "shorewall version" command will tell you which version
that you have installed.</li>
<li>The documentation NAT.htm file uses
non-existent wallpaper and bullet graphic files. The
non-existent wallpaper and bullet graphic files. The
<a
href="http://www.shorewall.net/pub/shorewall/errata/1.3.0/NAT.htm">
corrected version is here</a>.</li>
@ -558,8 +566,8 @@ non-existent wallpaper and bullet graphic files. The
<blockquote>
<p align="left">There are a couple of serious bugs in iptables 1.2.3 that
prevent it from working with Shorewall. Regrettably,
RedHat released this buggy iptables in RedHat 7.2. </p>
prevent it from working with Shorewall. Regrettably, RedHat
released this buggy iptables in RedHat 7.2. </p>
<p align="left"> I have built a <a
@ -567,14 +575,14 @@ RedHat released this buggy iptables in RedHat 7.2.
corrected 1.2.3 rpm which you can download here</a>  and I have
also built an <a
href="ftp://ftp.shorewall.net/pub/shorewall/iptables-1.2.4-1.i386.rpm">
iptables-1.2.4 rpm which you can download here</a>. If you are currently
iptables-1.2.4 rpm which you can download here</a>. If you are currently
running RedHat 7.1, you can install either of these RPMs
<b><u>before</u> </b>you upgrade to RedHat 7.2.</p>
<p align="left"><font color="#ff6633"><b>Update 11/9/2001: </b></font>RedHat
has released an iptables-1.2.4 RPM of their own which you can
download from<font color="#ff6633"> <a
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>
@ -618,8 +626,8 @@ download from<font color="#ff6633"> <a
<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
@ -686,18 +694,6 @@ kernel configuraiton option; see <a href="Documentation.htm#NAT">http://www.s
<p><a href="copyright.htm"><font size="2">Copyright</font> © <font
size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</p>
</body>
</html>

71
STABLE/documentation/mailing_list.htm
View File

@ -74,6 +74,10 @@
</table>
<h1>REPORTING A PROBLEM OR ASKING FOR HELP? If you haven't already, please
read the <a href="http://www.shorewall.net/support.htm">Shorewall Support
Guide</a>.<br>
</h1>
<p align="left">If you experience problems with any of these lists, please
let <a href="mailto:teastep@shorewall.net">me</a> know</p>
@ -109,24 +113,24 @@ record in DNS.</li>
"for continuous abuse" because it has been my policy to allow HTML in
list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control spam
and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one list
subscriber wrote to me privately "These e-mail admin's need to get a <i>(explitive
deleted)</i> life instead of trying to rid the planet of HTML based e-mail".
Nevertheless, to allow subscribers to receive list posts as must as possible,
I have now configured the list server at shorewall.net to strip all HTML
from outgoing posts. This means that HTML-only posts will be bounced by
the list server.<br>
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the
list subscribers whose MTAs are bouncing all shorewall.net mail. As
one list subscriber wrote to me privately "These e-mail admin's need to
get a <i>(explitive deleted)</i> life instead of trying to rid the planet
of HTML based e-mail". Nevertheless, to allow subscribers to receive list
posts as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts. This means that HTML-only posts
will be bounced by the list server.<br>
<p align="left"> <b>Note: </b>The list server limits posts to 120kb.<br>
</p>
<h2>Other Mail Delivery Problems</h2>
If you find that you are missing an occasional list post, your e-mail
admin may be blocking mail whose <i>Received:</i> headers contain the
names of certain ISPs. Again, I believe that such policies hurt more than
they help but I'm not prepared to go so far as to start stripping <i>Received:</i>
If you find that you are missing an occasional list post, your
e-mail admin may be blocking mail whose <i>Received:</i> headers contain
the names of certain ISPs. Again, I believe that such policies hurt more
than they help but I'm not prepared to go so far as to start stripping <i>Received:</i>
headers to circumvent those policies.<br>
<h2 align="left">Mailing Lists Archive Search</h2>
@ -165,9 +169,9 @@ they help but I'm not prepared to go so far as to start stripping <i>Received:<
</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>
@ -175,16 +179,16 @@ won't stand the traffic. If I catch you, you will be blacklisted.<br>
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>
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>
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
@ -208,9 +212,9 @@ to this list.</p>
<p align="left">The list archives are at <a
href="http://lists.shorewall.net/pipermail/shorewall-users/index.html">http://lists.shorewall.net/pipermail/shorewall-users</a>.</p>
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted at
<a href="http://sourceforge.net">Sourceforge</a>. The archives from that list
may be found at <a
<p align="left">Note that prior to 1/1/2002, the mailing list was hosted
at <a href="http://sourceforge.net">Sourceforge</a>. The archives from that
list may be found at <a
href="http://www.geocrawler.com/lists/3/Sourceforge/9327/0/">www.geocrawler.com/lists/3/Sourceforge/9327/0/</a>.</p>
<h2 align="left">Shorewall Announce Mailing List</h2>
@ -262,8 +266,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>
@ -274,10 +278,10 @@ may be found at <a
<li>
<p align="left">Down at the bottom of that page is the following text:
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a password
reminder, or change your subscription options enter your subscription
email address:". Enter your email address in the box and
click on the "<b>Unsubscribe</b> or edit options" button.</p>
" To <b>unsubscribe</b> from <i>&lt;list name&gt;</i>, get a
password reminder, or change your subscription options enter
your subscription email address:". Enter your email address
in the box and click on the "<b>Unsubscribe</b> or edit options" button.</p>
</li>
<li>
@ -294,13 +298,14 @@ click on the "<b>Unsubscribe</b> or edit options" button.</p>
<p align="left"><a href="gnu_mailman.htm">Check out these instructions</a></p>
<p align="left"><font size="2">Last updated 2/18/2003 - <a
<p align="left"><font size="2">Last updated 2/24/2003 - <a
href="http://www.shorewall.net/support.htm">Tom Eastep</a></font></p>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font>
© <font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
<p align="left"><a href="copyright.htm"> <font size="2">Copyright</font> ©
<font size="2">2001, 2002, 2003 Thomas M. Eastep.</font></a><br>
</p>
<br>
<br>
<br>
</body>
</html>

197
STABLE/documentation/seattlefirewall_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"
@ -116,9 +117,10 @@
<p>The Shoreline Firewall, more commonly known as "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables) based
firewall that can be used on a dedicated firewall system, a multi-function
<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>
@ -131,28 +133,30 @@ firewall that can be used on a dedicated firewall system, a multi-functio
<p>This program is free software; you can redistribute it and/or modify
it under the terms of
<a href="http://www.gnu.org/licenses/gpl.html">Version 2 of
the GNU General Public License</a> as published by the Free Software
the GNU General Public License</a> as published by the Free Software
Foundation.<br>
<br>
This program is distributed in
the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty
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,
MA 02139, USA</p>
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>
@ -176,31 +180,32 @@ 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<br>
Wolzak have a LEAF (router/firewall/gateway on
a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo<br>
</a></p>
<p><b>Congratulations to Jacques and Eric on the recent release of
Bering 1.0 Final!!! </b><br>
<p><b>Congratulations to Jacques and Eric on the recent release of Bering
1.1!!! </b><br>
</p>
<h2>This is a mirror of the main Shorewall web site at SourceForge
(<a href="http://shorewall.sf.net" target="_top">http://shorewall.sf.net</a>)</h2>
<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>
@ -236,9 +241,75 @@ Bering 1.0 Final!!! </b><br>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b><b><img
<p><b>2/21/2003 - Shorewall 1.4.0 Beta 1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
 </b><b> </b></p>
Shorewall 1.4 represents the
next step in the evolution of Shorewall. The main thrust of the initial
release is simply to remove the cruft that has accumulated in Shorewall
over time. <br>
<br>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in
/etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
OLD_PING_HANDLING=Yes will generate an error at startup as will specification
of the 'noping' or 'filterping' interface options.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces and
/etc/shorewall/hosts files is no longer supported and will generate an error
at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
</li>
</ol>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely reorganized
into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in /usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the common
chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.
</li>
</ol>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b></p>
<p>New features include</p>
@ -248,15 +319,15 @@ Bering 1.0 Final!!! </b><br>
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options in
/etc/shorewall/interfaces will all generate an error.<br>
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options
in /etc/shorewall/interfaces will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead
of just the interface name:<br>
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>
@ -265,27 +336,28 @@ of just the interface name:<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID
(e.g., eth0.0)<br>
(e.g., eth0.0)<br>
<br>
</li>
<li>In /etc/shorewall/tcrules, the MARK value may be optionally followed
by ":" and either 'F' or 'P' to designate that the marking will occur in
the FORWARD or PREROUTING chains respectively. If this additional specification
is omitted, the chain used to mark packets will be determined by the setting
of the MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<li>In /etc/shorewall/tcrules, the MARK value may be optionally
followed by ":" and either 'F' or 'P' to designate that the marking will
occur in the FORWARD or PREROUTING chains respectively. If this additional
specification is omitted, the chain used to mark packets will be determined
by the setting of the MARK_IN_FORWARD_CHAIN option in <a
href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<br>
</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>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>
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>
@ -299,13 +371,14 @@ to construct the masquerading/SNAT rules.<br>
<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>
When upgrading to Shorewall 1.3.14, if you have multiple local
subnets connected to an interface that is specified in the SUBNET column
of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will
need changing. In most cases, you will simply be able to remove redundant
entries. In some cases though, you might want to change from using the
interface name to listing specific subnetworks if the change described
above will cause masquerading to occur on subnetworks that you don't wish
to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
@ -316,8 +389,8 @@ listing specific subnetworks if the change described above will cause masquerad
<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>
   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>
@ -338,9 +411,7 @@ listing specific subnetworks if the change described above will cause masquerad
</ol>
<br>
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0
</b><b><img border="0" src="images/new10.gif" width="28"
height="12" alt="(New)">
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0</b><b>
</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>
@ -376,13 +447,14 @@ listing specific subnetworks if the change described above will cause masquerad
<h2><a name="Donations"></a>Donations</h2>
</td>
<td width="88" bgcolor="#4b017c"
valign="top" align="center"> <a
<td width="88"
bgcolor="#4b017c" valign="top" align="center"> <a
href="http://sourceforge.net">M</a></td>
</tr>
@ -411,7 +483,8 @@ listing specific subnetworks if the change described above will cause masquerad
<tr>
<td width="100%" style="margin-top: 1px;">
<td width="100%"
style="margin-top: 1px;">
@ -437,11 +510,11 @@ listing specific subnetworks if the change described above will cause masquerad
<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>
@ -458,9 +531,13 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/13/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/21/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
<br>
<br>
</body>
</html>

193
STABLE/documentation/sourceforge_index.htm
View File

@ -15,7 +15,8 @@
<base target="_self">
<base
target="_self">
</head>
<body>
@ -30,8 +31,8 @@
<tr>
<td width="100%" height="90">
<td width="100%"
height="90">
@ -60,6 +61,7 @@
<div align="center"><a href="/1.2/index.html" target="_top"><font
color="#ffffff">Shorewall 1.2 Site here</font></a></div>
@ -98,6 +100,7 @@
<h2 align="left">What is it?</h2>
@ -113,9 +116,9 @@
<p>The Shoreline Firewall, more commonly known as  "Shorewall", is
a <a href="http://www.netfilter.org">Netfilter</a> (iptables)
based firewall that can be used on a dedicated firewall system,
a multi-function gateway/router/server or on a standalone GNU/Linux
system.</p>
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>
@ -139,17 +142,17 @@ system.</p>
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>
warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License
for more details.<br>
<br>
You should have received a
copy of the GNU General Public License
along with this program; if not, write to the
Free Software Foundation, Inc., 675 Mass Ave,
Cambridge, MA 02139, USA</p>
You should have received
a copy of the GNU General Public License
along with this program; if not, write to
the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA</p>
@ -181,11 +184,11 @@ for more details.<br>
</a>Jacques Nilo and
Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution called
<i>Bering</i> that features Shorewall-1.3.10
and Kernel-2.4.18. You can find their work at:
<i>Bering</i> that features Shorewall-1.3.14
and Kernel-2.4.20. You can find their work at:
<a href="http://leaf.sourceforge.net/devel/jnilo"> http://leaf.sourceforge.net/devel/jnilo</a></p>
<b>Congratulations to Jacques
and Eric on the recent release of Bering 1.0 Final!!! <br>
and Eric on the recent release of Bering 1.1!!! <br>
</b>
@ -206,27 +209,93 @@ for more details.<br>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b><b><img
<p><b>2/21/2003 - Shorewall 1.4.0 Beta 1 </b><b> </b><b><img
border="0" src="images/new10.gif" width="28" height="12" alt="(New)">
</b></p>
 </b><b> </b></p>
Shorewall 1.4 represents
the next step in the evolution of Shorewall. The main thrust of the initial
release is simply to remove the cruft that has accumulated in Shorewall
over time. <br>
<br>
<b>IMPORTANT: Shorewall 1.4.0 <u>REQUIRES</u></b> <b>the iproute package
('ip' utility).</b><br>
<br>
Function from 1.3 that has been omitted from this version include:<br>
<ol>
<li>The MERGE_HOSTS variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.<br>
<br>
</li>
<li>Interface names of the form &lt;device&gt;:&lt;integer&gt; in
/etc/shorewall/interfaces now generate an error.<br>
<br>
</li>
<li>Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No.
OLD_PING_HANDLING=Yes will generate an error at startup as will specification
of the 'noping' or 'filterping' interface options.<br>
<br>
</li>
<li>The 'routestopped' option in the /etc/shorewall/interfaces and
/etc/shorewall/hosts files is no longer supported and will generate an error
at startup if specified.<br>
<br>
</li>
<li>The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
accepted.<br>
<br>
</li>
<li>The ALLOWRELATED variable in shorewall.conf is no longer supported.
Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.<br>
<br>
</li>
<li>The icmp.def file has been removed.<br>
</li>
</ol>
Changes for 1.4 include:<br>
<ol>
<li>The /etc/shorewall/shorewall.conf file has been completely reorganized
into logical sections.<br>
<br>
</li>
<li>LOG is now a valid action for a rule (/etc/shorewall/rules).<br>
<br>
</li>
<li>The firewall script and version file are now installed in /usr/share/shorewall.<br>
<br>
</li>
<li>Late arriving DNS replies are now silently dropped in the common
chain by default.<br>
<br>
</li>
<li>In addition to behaving like OLD_PING_HANDLING=No, Shorewall
1.4 no longer unconditionally accepts outbound ICMP packets. So if you want
to 'ping' from the firewall, you will need the appropriate rule or policy.
</li>
</ol>
<p><b>2/8/2003 - Shorewall 1.3.14</b><b> </b></p>
<p>New features include</p>
<ol>
<li>An OLD_PING_HANDLING option has been added to shorewall.conf.
When set to Yes, Shorewall ping handling is as it has always been (see
http://www.shorewall.net/ping.html).<br>
http://www.shorewall.net/ping.html).<br>
<br>
When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options in
/etc/shorewall/interfaces will all generate an error.<br>
and policies just like any other connection request. The FORWARDPING=Yes
option in shorewall.conf and the 'noping' and 'filterping' options in
/etc/shorewall/interfaces will all generate an error.<br>
<br>
</li>
<li>It is now possible to direct Shorewall to create a "label"
such as  "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes
and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead of
just the interface name:<br>
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>
@ -235,73 +304,80 @@ just the interface name:<br>
<br>
</li>
<li>Support for VLAN devices with names of the form $DEV.$VID
(e.g., eth0.0)<br>
(e.g., eth0.0)<br>
<br>
</li>
<li>In /etc/shorewall/tcrules, the MARK value may be optionally followed
by ":" and either 'F' or 'P' to designate that the marking will occur in
the FORWARD or PREROUTING chains respectively. If this additional specification
is omitted, the chain used to mark packets will be determined by the setting
of the MARK_IN_FORWARD_CHAIN option in <a href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<li>In /etc/shorewall/tcrules, the MARK value may be optionally
followed by ":" and either 'F' or 'P' to designate that the marking will
occur in the FORWARD or PREROUTING chains respectively. If this additional
specification is omitted, the chain used to mark packets will be determined
by the setting of the MARK_IN_FORWARD_CHAIN option in <a
href="Documentation.htm#Conf">shorewall.conf</a>.<br>
<br>
</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>
<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>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>  [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br></pre>
<pre>  [root@gateway test]# shorewall start<br> ...<br> Masqueraded Subnets and Hosts:<br> To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176<br> To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176<br> Processing /etc/shorewall/tos...</pre>
 <br>
When upgrading to Shorewall 1.3.14, if you have multiple local subnets
connected to an interface that is specified in the SUBNET column of an
/etc/shorewall/masq entry, your /etc/shorewall/masq file will need changing.
In most cases, you will simply be able to remove redundant entries. In
some cases though, you might want to change from using the interface name
to listing specific subnetworks if the change described above will cause
When upgrading to Shorewall 1.3.14, if you have multiple local
subnets connected to an interface that is specified in the SUBNET column
of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will need
changing. In most cases, you will simply be able to remove redundant entries.
In some cases though, you might want to change from using the interface
name to listing specific subnetworks if the change described above will cause
masquerading to occur on subnetworks that you don't wish to masquerade.<br>
 <br>
Example 2 -- Suppose that your current config is as follows:<br>
   <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> eth0                    192.168.10.0/24         206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, the second entry in /etc/shorewall/masq is no longer
required.<br>
   In this case, the second entry in /etc/shorewall/masq is no
longer required.<br>
 <br>
Example 3 -- What if your current configuration is like this?<br>
 <br>
<pre>   [root@gateway test]# cat /etc/shorewall/masq<br> #INTERFACE              SUBNET                  ADDRESS<br> eth0                    eth2                    206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
<pre>   [root@gateway test]# ip route show dev eth2<br> 192.168.1.0/24  scope link<br> 192.168.10.0/24  proto kernel  scope link  src 192.168.10.254<br> [root@gateway test]#</pre>
 <br>
   In this case, you would want to change the entry in  /etc/shorewall/masq
to:<br>
<pre>   #INTERFACE              SUBNET                  ADDRESS<br> eth0                    192.168.1.0/24          206.124.146.176<br> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE</pre>
</li>
</ol>
<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)">
<p><b>2/5/2003 - Shorewall Support included in Webmin 1.06</b><b>0</b><b>
</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>
@ -425,6 +501,7 @@ masquerading to occur on subnetworks that you don't wish to masquerade.<br>
<p align="center"><a href="http://www.starlight.org"> <img
border="4" src="images/newlog.gif" width="57" height="100" align="left"
hspace="10">
@ -441,11 +518,12 @@ masquerading to occur on subnetworks that you don't wish to masquerade.<br>
<p align="center"><font size="4" color="#ffffff">Shorewall is free
but if you try it and find it useful, please consider making a donation
<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>
@ -463,9 +541,12 @@ Children's Foundation.</font></a> Thanks!</font></p>
<p><font size="2">Updated 2/14/2003 - <a href="support.htm">Tom Eastep</a></font>
<p><font size="2">Updated 2/19/2003 - <a href="support.htm">Tom Eastep</a></font>
<br>
</p>
</p>
<br>
<br>
<br>
</body>
</html>

27
STABLE/documentation/spam_filters.htm
View File

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

72
STABLE/documentation/support.htm
View File

@ -23,6 +23,7 @@
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0"
style="border-collapse: collapse;" width="100%" id="AutoNumber1"
bgcolor="#400169" height="90">
@ -43,6 +44,7 @@
</tbody>
</table>
<p> <b><big><big><font color="#ff0000">While I don't answer Shorewall  questions
emailed directly to me, I try to spend some time each day answering questions
on the Shorewall Users Mailing List.</font></big><span
@ -52,7 +54,7 @@
<h1>Before Reporting a Problem</h1>
<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>
than some people on this list appear to do.</i>"<br>
<br>
<div align="center">- Wietse Venema - On the Postfix mailing list<br>
@ -148,9 +150,10 @@ problems: </li>
Can anyone tell you what that strange smell is?<br>
<br>
Now, all of us could do some wonderful guessing as to the
smell and even what's causing it. You would be absolutely amazed at
the range and variety of smells we could come up with. Even more amazing
is that all of the explanations for the smells would be completely plausible."<br>
smell and even what's causing it. You would be absolutely amazed
at the range and variety of smells we could come up with. Even more
amazing is that all of the explanations for the smells would be completely
plausible."<br>
</i><br>
<div align="center"> - <i>Russell Mosemann</i> on the Postfix mailing list<br>
@ -164,8 +167,8 @@ is that all of the explanations for the smells would be completely plausib
<li>Please remember we only know what is posted in your message.
Do not leave out any information that appears to be correct, or was
mentioned in a previous post. There have been countless posts by people
who were sure that some part of their configuration was correct when
it actually contained a small error. We tend to be skeptics where detail
who were sure that some part of their configuration was correct when it
actually contained a small error. We tend to be skeptics where detail
is lacking.<br>
<br>
</li>
@ -180,12 +183,12 @@ or summary.<br>
</li>
<li> Please don't describe
your environment and then ask us to send you custom
configuration files. We're here to answer your questions but
we can't do your job for you.<br>
configuration files. We're here to answer your questions but we
can't do your job for you.<br>
<br>
</li>
<li>When reporting a problem, <strong>ALWAYS</strong> include
this information:</li>
this information:</li>
</ul>
@ -252,16 +255,17 @@ please indicate which one. <br>
<ul>
<li><b>NEVER </b>include the output of "<b><font
color="#009900">iptables -L</font></b>". Instead, <b>if you are having
connection problems of any kind</b>, post the exact output of<br>
color="#009900">iptables -L</font></b>". Instead,<font
color="#ff0000"><u><i><big> <b>if you are having connection problems of
any kind then:</b></big></i></u></font><br>
<br>
<b><font color="#009900">/sbin/shorewall status<br>
1. <b><font color="#009900">/sbin/shorewall/reset</font></b><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>
2. Try the connection that is failing.<br>
<br>
<b><font color="#009900">/sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
3.<b><font color="#009900"> /sbin/shorewall status &gt; /tmp/status.txt</font></b><br>
<br>
4. Post the /tmp/status.txt file as an attachment.<br>
<br>
</li>
<li>As a general matter, please <strong>do not edit the diagnostic
@ -295,8 +299,8 @@ copy of your /etc/shorewall/interfaces file.<br>
<li>Please include any of the Shorewall configuration files
(especially the /etc/shorewall/hosts file if you have modified
that file) that you think are relevant. If you include /etc/shorewall/rules,
please include /etc/shorewall/policy as well (rules are meaningless
unless one also knows the policies). </li>
please include /etc/shorewall/policy as well (rules are meaningless unless
one also knows the policies). </li>
</ul>
@ -310,7 +314,7 @@ unless one also knows the policies). </li>
<ul>
<li> If an error occurs
when you try to "<font color="#009900"><b>shorewall start</b></font>",
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>
@ -336,18 +340,18 @@ when you try to "<font color="#009900"><b>shorewall start</b></font>",
<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>
all HTML traffic. At least one MTA has gone so far as to blacklist
shorewall.net "for continuous abuse" because it has been my policy to
allow HTML in list posts!!<br>
<br>
I think that blocking all HTML is a Draconian way to control
spam and that the ultimate losers here are not the spammers but the list
subscribers whose MTAs are bouncing all shorewall.net mail. As one
list subscriber wrote to me privately "These e-mail admin's need to get
a <i>(expletive deleted)</i> life instead of trying to rid the planet
of HTML based e-mail". Nevertheless, to allow subscribers to receive list
posts as must as possible, I have now configured the list server at shorewall.net
to strip all HTML from outgoing posts.<br>
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>
@ -356,9 +360,9 @@ to strip all HTML from outgoing posts.<br>
style="font-weight: 400;">please post your question or problem
to the <a href="mailto:leaf-user@lists.sourceforge.net">LEAF Users
mailing list</a>.</span></h4>
<b>If you run Shorewall under MandrakeSoft Multi Network Firewall
(MNF) and you have not purchased an MNF license from MandrakeSoft then
you can post non MNF-specific Shorewall questions to the </b><a
<b>If you run Shorewall under MandrakeSoft Multi Network
Firewall (MNF) and you have not purchased an MNF license from MandrakeSoft
then you can post non MNF-specific Shorewall questions to the </b><a
href="mailto:shorewall-users@lists.shorewall.net">Shorewall users mailing
list.</a> <b>Do not expect to get free MNF support on the list.</b><br>
@ -375,7 +379,8 @@ to strip all HTML from outgoing posts.<br>
.</p>
<p align="left"><font size="2">Last Updated 2/9/2003 - Tom Eastep</font></p>
<p align="left"><font size="2">Last Updated 2/22/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>
@ -386,5 +391,6 @@ to strip all HTML from outgoing posts.<br>
<br>
<br>
<br>
<br>
</body>
</html>

17
STABLE/firewall
View File

@ -1577,10 +1577,10 @@ setup_mac_lists() {
#
for interface in $maclist_interfaces; do
case $interface in
eth*)
eth*|wlan*)
;;
*)
fatal_error "Error: MAC verification is only supported on ethernet devices: $interface"
fatal_error "Error: MAC verification is only supported on ethernet and 802.11b devices: $interface"
;;
esac
@ -3084,12 +3084,11 @@ setup_intrazone() # $1 = zone
{
eval hosts=\$${1}_hosts
if [ "$hosts" != "${hosts% *}" ] || \
have_interfaces_in_zone_with_option $1 multi
then
if have_interfaces_in_zone_with_option $1 multi; then
ensurechain ${1}2${1}
fi
}
#
# Add a record to the blacklst chain
#
@ -3521,10 +3520,10 @@ add_common_rules() {
if [ -n "$LOGUNCLEAN" ]; then
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:badpkt:DROP:"
logoptions="-j ULOG $LOGPARMS --ulog-prefix Shorewall:badpkt:DROP:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:badpkt:DROP:"
logoptions="-j LOG $LOGPARMS --log-prefix Shorewall:badpkt:DROP:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi
@ -3553,10 +3552,10 @@ add_common_rules() {
[ -z"$LOGUNCLEAN" ] && LOGUNCLEAN=info
if [ "$LOGUNCLEAN" = ULOG ]; then
logoptions="-j ULOG $LOGPARAMS --ulog-prefix Shorewall:logpkt:LOG:"
logoptions="-j ULOG $LOGPARMS --ulog-prefix Shorewall:logpkt:LOG:"
logoptions="$logoptions --log-ip-options"
else
logoptions="-j LOG $LOGPARAMS --log-prefix Shorewall:logpkt:LOG:"
logoptions="-j LOG $LOGPARMS --log-prefix Shorewall:logpkt:LOG:"
logoptions="$logoptions --log-level $LOGUNCLEAN --log-ip-options"
fi