mirror of
https://gitlab.com/shorewall/code.git
synced 2025-03-05 10:02:19 +01:00
Some documentation updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@463 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
9b98ecbff5
commit
5f9ff7336a
@ -23,6 +23,7 @@
|
||||
|
||||
|
||||
|
||||
|
||||
<meta name="Microsoft Theme" content="none">
|
||||
</head>
|
||||
<body>
|
||||
@ -76,12 +77,12 @@ 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>
|
||||
do I do?</a></p>
|
||||
|
||||
|
||||
<p align="left"><b>4. </b><a href="#faq4">I just used an online port scanner
|
||||
to check my firewall and it shows <b>some ports as 'closed'
|
||||
rather than 'blocked'.</b> Why?</a></p>
|
||||
to check my firewall and it shows <b>some ports as
|
||||
'closed' rather than 'blocked'.</b> Why?</a></p>
|
||||
|
||||
|
||||
<p align="left"><b>4a. </b><a href="#faq4a">I just ran an <b>nmap UDP scan</b>
|
||||
@ -96,6 +97,7 @@ do I do?</a></p>
|
||||
written and how do I <b>change the destination</b>?</a></p>
|
||||
|
||||
|
||||
|
||||
<p align="left"><b>6a. </b><a href="#faq6a">Are there any <b>log parsers</b>
|
||||
that work with Shorewall?</a></p>
|
||||
|
||||
@ -106,7 +108,7 @@ do I do?</a></p>
|
||||
</p>
|
||||
|
||||
<p align="left"><b>6c. </b><a href="#faq6c">All day long I get a steady flow
|
||||
of these <b>DROP messages from port 53</b> <b>to some high numbered port</b>.
|
||||
of these <b>DROP messages from port 53</b> <b>to some high numbered port</b>.
|
||||
They get dropped, but what the heck are they?</a><br>
|
||||
</p>
|
||||
|
||||
@ -151,9 +153,9 @@ 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>
|
||||
IP addresses, my ISP's DHCP server has an RFC 1918
|
||||
address. If I enable RFC 1918 filtering on my external
|
||||
interface, <b>my DHCP client cannot renew its lease</b>.</a></p>
|
||||
|
||||
|
||||
<p align="left"><b>15. </b><a href="#faq15"><b>My local systems can't see
|
||||
@ -168,43 +170,46 @@ modems web server</b></a>.</p>
|
||||
<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
|
||||
way to use <b>aliased ip addresses</b> with Shorewall, and
|
||||
maintain separate rulesets for different IPs?</a><br>
|
||||
<br>
|
||||
<b>19. </b><a href="#faq19">I have added <b>entries
|
||||
to /etc/shorewall/tcrules</b> but they <b>don't </b>seem to <b>do
|
||||
anything</b>. Why?</a><br>
|
||||
<br>
|
||||
<b>20. </b><a href="#faq20">I have just set up
|
||||
a server. <b>Do I have to change Shorewall to allow access to my
|
||||
server from the internet?<br>
|
||||
<b>20. </b><a href="#faq20">I have just set
|
||||
up a server. <b>Do I have to change Shorewall to allow access
|
||||
to my server from the internet?<br>
|
||||
<br>
|
||||
</b></a><b>21. </b><a href="#faq21">I see these <b>strange
|
||||
log entries </b>occasionally; what are they?<br>
|
||||
</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>
|
||||
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>
|
||||
<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>
|
||||
to 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
|
||||
my my personal PC with IP address 192.168.1.5. I've looked
|
||||
everywhere and can't find how to do it.</h4>
|
||||
my my personal PC with IP address 192.168.1.5. I've
|
||||
looked everywhere and can't find how to do it.</h4>
|
||||
|
||||
|
||||
<p align="left"><b>Answer: </b>The <a
|
||||
href="Documentation.htm#PortForward"> first example</a> in the <a
|
||||
href="Documentation.htm#Rules">rules file documentation</a> shows how to
|
||||
do port forwarding under Shorewall. The format of a port-forwarding
|
||||
rule to a local system is as follows:</p>
|
||||
do port forwarding under Shorewall. The format of a
|
||||
port-forwarding rule to a local system is as follows:</p>
|
||||
|
||||
|
||||
<blockquote>
|
||||
@ -224,8 +229,8 @@ internet?</a><br>
|
||||
<tr>
|
||||
<td>DNAT</td>
|
||||
<td>net</td>
|
||||
<td>loc:<i><local IP address></i>[:<i><local
|
||||
port</i>>]</td>
|
||||
<td>loc:<i><local IP
|
||||
address></i>[:<i><local port</i>>]</td>
|
||||
<td><i><protocol></i></td>
|
||||
<td><i><port #></i></td>
|
||||
<td> <br>
|
||||
@ -283,8 +288,8 @@ internet?</a><br>
|
||||
|
||||
|
||||
<div align="left"> <font face="Courier"> </font>If
|
||||
you want to forward requests directed to a particular address ( <i><external
|
||||
IP></i> ) on your firewall to an internal system:</div>
|
||||
you want to forward requests directed to a particular address (
|
||||
<i><external IP></i> ) on your firewall to an internal system:</div>
|
||||
|
||||
|
||||
<blockquote>
|
||||
@ -304,8 +309,8 @@ internet?</a><br>
|
||||
<tr>
|
||||
<td>DNAT</td>
|
||||
<td>net</td>
|
||||
<td>loc:<i><local IP address></i>[:<i><local
|
||||
port</i>>]</td>
|
||||
<td>loc:<i><local IP
|
||||
address></i>[:<i><local port</i>>]</td>
|
||||
<td><i><protocol></i></td>
|
||||
<td><i><port #></i></td>
|
||||
<td>-</td>
|
||||
@ -321,7 +326,7 @@ internet?</a><br>
|
||||
</blockquote>
|
||||
|
||||
Finally, if you need to forward a range of ports, in the PORT column
|
||||
specify the range as <i>low-port</i>:<i>high-port</i>.<br>
|
||||
specify the range as <i>low-port</i>:<i>high-port</i>.<br>
|
||||
|
||||
<h4 align="left"><a name="faq1a"></a>1a. Ok -- I followed those instructions
|
||||
but it doesn't work</h4>
|
||||
@ -336,8 +341,8 @@ specify the range as <i>low-port</i>:<i>high-port</i>.<br>
|
||||
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>
|
||||
configured (it should be set to the IP address of your
|
||||
firewall's internal interface).</li>
|
||||
|
||||
|
||||
</ul>
|
||||
@ -345,22 +350,23 @@ specify the range as <i>low-port</i>:<i>high-port</i>.<br>
|
||||
|
||||
<h4 align="left"><a name="faq1b"></a>1b. I'm still having problems with port
|
||||
forwarding</h4>
|
||||
<b>Answer: </b>To further diagnose this problem:<br>
|
||||
<b>Answer: </b>To further diagnose this
|
||||
problem:<br>
|
||||
|
||||
<ul>
|
||||
<li>As root, type "iptables -t nat -Z".
|
||||
This clears the NetFilter counters in the nat table.</li>
|
||||
This clears the NetFilter counters in the nat table.</li>
|
||||
<li>Try to connect to the redirected port
|
||||
from an external host.</li>
|
||||
<li>As root type "shorewall show nat"</li>
|
||||
<li>Locate the appropriate DNAT rule. It
|
||||
will be in a chain called <i><source zone></i>_dnat ('net_dnat'
|
||||
in the above examples).</li>
|
||||
<li>Locate the appropriate DNAT rule.
|
||||
It will be in a chain called <i><source zone></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
|
||||
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>
|
||||
|
||||
@ -372,10 +378,10 @@ the server (the server's default gateway should be the IP address
|
||||
IP address on your firewall and your rule is only redirecting
|
||||
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>
|
||||
<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>
|
||||
</li>
|
||||
|
||||
|
||||
@ -385,8 +391,8 @@ the server (the server's default gateway should be the IP address
|
||||
|
||||
<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>
|
||||
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>
|
||||
@ -395,19 +401,19 @@ but internal clients can't.</h4>
|
||||
<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
|
||||
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>
|
||||
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
|
||||
is best solved using <a
|
||||
href="shorewall_setup_guide.htm#DNS">Bind Version 9 "views"</a>
|
||||
(or using a separate DNS server for local clients) such that www.mydomain.com
|
||||
resolves to 130.141.100.69 externally and 192.168.1.5 internally.
|
||||
That's what I do here at shorewall.net for my local systems that
|
||||
use static NAT.</li>
|
||||
That's what I do here at shorewall.net for my local systems that
|
||||
use static NAT.</li>
|
||||
|
||||
|
||||
</ul>
|
||||
@ -463,7 +469,8 @@ is eth1 and that eth1 has IP address 192.168.1.254 with subnet
|
||||
<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>
|
||||
running Shorewall 1.3.4 or later then include this in
|
||||
/etc/shorewall/params:</p>
|
||||
</div>
|
||||
|
||||
|
||||
@ -528,14 +535,14 @@ that you get a new IP address.</p>
|
||||
|
||||
<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
|
||||
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>
|
||||
internally using the same address. </p>
|
||||
|
||||
|
||||
<p align="left">If you don't like those solutions and prefer routing all
|
||||
@ -615,6 +622,7 @@ Z->Z traffic through your firewall then:</p>
|
||||
</blockquote>
|
||||
|
||||
|
||||
|
||||
<p align="left">In /etc/shorewall/masq:</p>
|
||||
|
||||
|
||||
@ -655,7 +663,7 @@ Z->Z traffic through your firewall then:</p>
|
||||
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>.
|
||||
archives at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
|
||||
</p>
|
||||
|
||||
|
||||
@ -666,12 +674,12 @@ archives at <a href="http://www.netfilter.org">http://www.netfilter.org</a>.
|
||||
|
||||
<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
|
||||
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>
|
||||
@ -691,7 +699,7 @@ in violation of your Service Agreement.</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->all policy to REJECT, restart Shorewall
|
||||
and do the nmap UDP scan again.</p>
|
||||
and do the nmap UDP scan again.</p>
|
||||
|
||||
|
||||
<h4 align="left"><a name="faq5"></a>5. I've installed Shorewall and now I
|
||||
@ -703,9 +711,9 @@ and do the nmap UDP scan again.</p>
|
||||
|
||||
|
||||
<p align="left">a) Create /etc/shorewall/common if it doesn't already exist.
|
||||
<br>
|
||||
<br>
|
||||
b) Be sure that the first command
|
||||
in the file is ". /etc/shorewall/common.def"<br>
|
||||
in the file is ". /etc/shorewall/common.def"<br>
|
||||
c) Add the following to /etc/shorewall/common
|
||||
</p>
|
||||
|
||||
@ -735,7 +743,7 @@ see "man syslog") in your <a href="Documentation.htm#Policy">policies</a>
|
||||
|
||||
<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
|
||||
in /etc/shorewall/shorewall.conf -- If you want to log
|
||||
all messages, set: </p>
|
||||
|
||||
|
||||
@ -766,22 +774,22 @@ all messages, set: </p>
|
||||
<a href="http://gege.org/iptables">http://gege.org/iptables</a><br>
|
||||
</p>
|
||||
</blockquote>
|
||||
I personnaly use Logwatch. It emails me a report each
|
||||
day from my various systems with each report summarizing the logged
|
||||
activity on the corresponding system.
|
||||
I personnaly use Logwatch. It emails me a report
|
||||
each day from my various systems with each report summarizing the
|
||||
logged activity on the corresponding system.
|
||||
|
||||
<h4 align="left"><b><a name="faq6b"></a>6b. DROP messages</b> on port 10619
|
||||
are <b>flooding the logs</b> with their connect requests. Can i exclude
|
||||
these error messages for this port temporarily from logging in Shorewall?</h4>
|
||||
Temporarily add the following rule:<br>
|
||||
|
||||
<pre> DROP net fw udp 10619</pre>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
<ol>
|
||||
@ -800,12 +808,12 @@ get dropped, but what the heck are they?</h4>
|
||||
</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> and in the common.def file in Shorewall 1.4.0 and later.<br>
|
||||
Guides</a> and in the common.def file in Shorewall 1.4.0 and later.<br>
|
||||
|
||||
<h4 align="left"><a name="faq6d"></a><b>6d.</b> Why is the MAC address in
|
||||
Shorewall log messages so long? I thought MAC addresses were only 6 bytes
|
||||
in length. What is labeled as the MAC address in a Shorewall log message
|
||||
is actually the Ethernet frame header. In contains:<br>
|
||||
is actually the Ethernet frame header. In contains:<br>
|
||||
</h4>
|
||||
|
||||
<ul>
|
||||
@ -826,8 +834,8 @@ is actually the Ethernet frame header. In contains:<br>
|
||||
</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>
|
||||
stop', I can't connect to anything. Why doesn't that
|
||||
command work?</h4>
|
||||
|
||||
|
||||
<p align="left">The 'stop' command is intended to place your firewall into
|
||||
@ -897,7 +905,7 @@ local zone is defined as all hosts connected through eth1</p>
|
||||
|
||||
<p align="left">Shorewall works with any GNU/Linux distribution that includes
|
||||
the <a href="shorewall_prerequisites.htm">proper
|
||||
prerequisites</a>.</p>
|
||||
prerequisites</a>.</p>
|
||||
|
||||
|
||||
<h4 align="left">11. What Features does it have?</h4>
|
||||
@ -920,9 +928,9 @@ prerequisites</a>.</p>
|
||||
|
||||
<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
|
||||
@ -950,7 +958,8 @@ following:</p>
|
||||
|
||||
<div align="left">
|
||||
<p align="left">If you are running version 1.3.1 or later, simply add the
|
||||
following to<a href="Documentation.htm#rfc1918"> /etc/shorewall/rfc1918</a>:</p>
|
||||
following to<a href="Documentation.htm#rfc1918">
|
||||
/etc/shorewall/rfc1918</a>:</p>
|
||||
</div>
|
||||
|
||||
|
||||
@ -986,9 +995,9 @@ following:</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:
|
||||
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>
|
||||
|
||||
@ -1046,9 +1055,9 @@ its 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>
|
||||
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>
|
||||
@ -1071,9 +1080,9 @@ this problem are:</p>
|
||||
|
||||
|
||||
<p align="left">The DNS settings on the local systems are wrong or the
|
||||
user is running a DNS server on the firewall and hasn't
|
||||
enabled UDP and TCP port 53 from the firewall to the
|
||||
internet.</p>
|
||||
user is running a DNS server on the firewall and
|
||||
hasn't enabled UDP and TCP port 53 from the firewall
|
||||
to the internet.</p>
|
||||
</li>
|
||||
|
||||
|
||||
@ -1091,10 +1100,13 @@ console is specified in /etc/sysconfig/init in the LOGLEVEL
|
||||
variable.<br>
|
||||
</p>
|
||||
|
||||
|
||||
<h4><a name="faq17"></a>17. How do I find out why this traffic is getting
|
||||
logged?</h4>
|
||||
<b>Answer: </b>Logging occurs out of
|
||||
a number of chains (as indicated in the log message) in Shorewall:<br>
|
||||
a number of chains (as indicated in the log message) in
|
||||
Shorewall:<br>
|
||||
|
||||
|
||||
<ol>
|
||||
<li><b>man1918 - </b>The destination
|
||||
@ -1106,8 +1118,8 @@ a number of chains (as indicated in the log message) in Shorewal
|
||||
<li><b>all2<zone></b>, <b><zone>2all</b>
|
||||
or <b>all2all </b>- You have a<a
|
||||
href="Documentation.htm#Policy"> policy</a> that specifies a log level
|
||||
and this packet is being logged under that policy. If you intend
|
||||
to ACCEPT this traffic then you need a <a
|
||||
and this packet is being logged under that policy. If you
|
||||
intend to ACCEPT this traffic then you need a <a
|
||||
href="Documentation.htm#Rules">rule</a> to that effect.<br>
|
||||
</li>
|
||||
<li><b><zone1>2<zone2>
|
||||
@ -1120,44 +1132,46 @@ under that policy or this packet matches a <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
|
||||
logged under the <b>logunclean</b> <a
|
||||
<li><b>logpkt</b> - The packet is
|
||||
being logged under the <b>logunclean</b> <a
|
||||
href="Documentation.htm#Interfaces">interface option</a>.</li>
|
||||
<li><b>badpkt </b>- The packet is being
|
||||
logged under the <b>dropunclean</b> <a
|
||||
<li><b>badpkt </b>- The packet is
|
||||
being logged under the <b>dropunclean</b> <a
|
||||
href="Documentation.htm#Interfaces">interface option</a> as specified
|
||||
in the <b>LOGUNCLEAN </b>setting in <a
|
||||
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf</a>.</li>
|
||||
<li><b>blacklst</b> - The packet is
|
||||
being logged because the source IP is blacklisted in the<a
|
||||
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
|
||||
<li><b>blacklst</b> - The packet
|
||||
is being logged because the source IP is blacklisted in
|
||||
the<a href="Documentation.htm#Blacklist"> /etc/shorewall/blacklist
|
||||
</a>file.</li>
|
||||
<li><b>newnotsyn </b>- The packet
|
||||
is being logged because it is a TCP packet that is not part
|
||||
of any current connection yet it is not a syn packet. Options
|
||||
affecting the logging of such packets include <b>NEWNOTSYN
|
||||
</b>and <b>LOGNEWNOTSYN </b>in <a
|
||||
href="Documentation.htm#Conf">/etc/shorewall/shorewall.conf.</a></li>
|
||||
<li><b>INPUT</b> or <b>FORWARD</b> -
|
||||
The packet has a source IP address that isn't in any of your
|
||||
defined zones ("shorewall check" and look at the printed zone
|
||||
definitions) or the chain is FORWARD and the destination IP isn't
|
||||
in any of your defined zones.</li>
|
||||
<li><b>INPUT</b> or <b>FORWARD</b>
|
||||
- The packet has a source IP address that isn't in any of
|
||||
your defined zones ("shorewall check" and look at the printed
|
||||
zone definitions) or the chain is FORWARD and the destination IP
|
||||
isn't in any of your defined zones.</li>
|
||||
<li><b>logflags </b>- The packet is being logged
|
||||
because it failed the checks implemented by the <b>tcpflags </b><a
|
||||
href="Documentation.htm#Interfaces">interface option</a>.<br>
|
||||
because it failed the checks implemented by the <b>tcpflags
|
||||
</b><a href="Documentation.htm#Interfaces">interface option</a>.<br>
|
||||
</li>
|
||||
|
||||
|
||||
</ol>
|
||||
|
||||
<h4><a name="faq18"></a>18. Is there any way to use <b>aliased ip addresses</b>
|
||||
with Shorewall, and maintain separate rulesets for different
|
||||
IPs?</h4>
|
||||
<b>Answer: </b>Yes. You simply use the IP
|
||||
address in your rules (or if you use NAT, use the local IP address
|
||||
in your rules). <b>Note:</b> The ":n" notation (e.g., eth0:0)
|
||||
is deprecated and will disappear eventually. Neither iproute
|
||||
(ip and tc) nor iptables supports that notation so neither does
|
||||
Shorewall. <br>
|
||||
<b>Answer: </b>Yes. You simply use the
|
||||
IP address in your rules (or if you use NAT, use the local
|
||||
IP address in your rules). <b>Note:</b> The ":n" notation (e.g.,
|
||||
eth0:0) is deprecated and will disappear eventually. Neither
|
||||
iproute (ip and tc) nor iptables supports that notation so neither
|
||||
does Shorewall. <br>
|
||||
<br>
|
||||
<b>Example 1:</b><br>
|
||||
<br>
|
||||
@ -1184,8 +1198,9 @@ is deprecated and will disappear eventually. Neither iproute
|
||||
|
||||
<h4><b><a name="faq19"></a>19. </b>I have added entries to /etc/shorewall/tcrules
|
||||
but they don't seem to do anything. Why?</h4>
|
||||
You probably haven't set TC_ENABLED=Yes in /etc/shorewall/shorewall.conf
|
||||
so the contents of the tcrules file are simply being ignored.<br>
|
||||
You probably haven't set TC_ENABLED=Yes in
|
||||
/etc/shorewall/shorewall.conf so the contents of the tcrules
|
||||
file are simply being ignored.<br>
|
||||
|
||||
<h4><a name="faq20"></a><b>20. </b>I have just set up a server. <b>Do I have
|
||||
to change Shorewall to allow access to my server from the internet?</b><br>
|
||||
@ -1206,23 +1221,23 @@ rules for your server.<br>
|
||||
192.0.2.3 is external on my firewall... 172.16.0.0/24
|
||||
is my internal LAN<br>
|
||||
<br>
|
||||
<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>
|
||||
<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>
|
||||
<br>
|
||||
Here is my interpretation of what is happening --
|
||||
to confirm this analysis, one would have to have packet sniffers
|
||||
placed a both ends of the connection.<br>
|
||||
Here is my interpretation of what is happening
|
||||
-- to confirm this analysis, one would have to have packet sniffers
|
||||
placed a both ends of the connection.<br>
|
||||
<br>
|
||||
Host 172.16.1.10 behind NAT gateway 206.124.146.179
|
||||
sent a UDP DNS query to 192.0.2.3 and your DNS server tried to
|
||||
send a response (the response information is in the brackets -- note
|
||||
source port 53 which marks this as a DNS reply). When the response was
|
||||
returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10
|
||||
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
|
||||
@ -1244,35 +1259,41 @@ because the source IP is reserved by RFC 1918.<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>
|
||||
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>
|
||||
explicitly specify fonts except on a few pages) so the fonts you see
|
||||
are largely the default fonts configured in your browser. If you don't
|
||||
like them then reconfigure your browser.<br>
|
||||
|
||||
<h4><a name="faq24"></a>24. How can I <b>allow conections</b> to let's say
|
||||
the ssh port only<b> from specific IP Addresses</b> on the internet?</h4>
|
||||
In the SOURCE column of the rule, follow "net" by a colon and
|
||||
a list of the host/subnet addresses as a comma-separated list.<br>
|
||||
a list of the host/subnet addresses as a comma-separated list.<br>
|
||||
|
||||
<pre> net:<ip1>,<ip2>,...<br></pre>
|
||||
<pre> net:<ip1>,<ip2>,...<br></pre>
|
||||
Example:<br>
|
||||
|
||||
<pre> ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22<br></pre>
|
||||
|
||||
<h4></h4>
|
||||
|
||||
|
||||
<div align="left"> </div>
|
||||
<font size="2">Last updated 2/18/2003 - <a
|
||||
href="support.htm">Tom Eastep</a></font>
|
||||
|
||||
<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>
|
||||
@ -1280,5 +1301,7 @@ a list of the host/subnet addresses as a comma-separated list.<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -41,8 +41,8 @@
|
||||
Please observe the following general requirements:<br>
|
||||
<br>
|
||||
<b><img src="images/BD21298_3.gif" alt="" width="13" height="13">
|
||||
</b>In all cases, Squid should be configured to run
|
||||
as a transparent proxy as described at <a
|
||||
</b>In all cases, Squid should be configured to
|
||||
run as a transparent proxy as described at <a
|
||||
href="http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html">http://www.tldp.org/HOWTO/mini/TransparentProxy-4.html</a>.<br>
|
||||
<b><br>
|
||||
</b><b><img src="images/BD21298_3.gif" alt="" width="13"
|
||||
@ -63,7 +63,7 @@ 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> You must have NAT and MANGLE enabled in your
|
||||
/etc/shorewall/conf file<br>
|
||||
/etc/shorewall/conf file<br>
|
||||
<br>
|
||||
<b><font color="#009900"> NAT_ENABLED=Yes<br>
|
||||
</font></b> <font
|
||||
@ -73,7 +73,7 @@ to the Squid server still have their original destination IP addresses.<br>
|
||||
|
||||
<ol>
|
||||
<li><a href="Shorewall_Squid_Usage.html#Firewall">Squid running on
|
||||
the Firewall.</a></li>
|
||||
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
|
||||
@ -82,9 +82,9 @@ DMZ</a></li>
|
||||
</ol>
|
||||
|
||||
<h2><a name="Firewall"></a>Squid Running on the Firewall</h2>
|
||||
You want to redirect all local www connection requests EXCEPT
|
||||
those to your own
|
||||
http server (206.124.146.177)
|
||||
You want to redirect all local www connection requests
|
||||
EXCEPT those to your
|
||||
own http server (206.124.146.177)
|
||||
to a Squid transparent
|
||||
proxy running on the firewall and listening on port 3128. Squid
|
||||
will of course require access to remote web servers.<br>
|
||||
@ -148,8 +148,8 @@ DMZ</a></li>
|
||||
transparent proxy
|
||||
running in your local zone at 192.168.1.3 and listening on port 3128.
|
||||
Your local interface is eth1. There may also be a web server running on
|
||||
192.168.1.3. It is assumed that web access is already enabled from the local
|
||||
zone to the internet.<br>
|
||||
192.168.1.3. It is assumed that web access is already enabled from the local
|
||||
zone to the internet.<br>
|
||||
|
||||
<p><font color="#ff0000"><b>WARNING: </b></font>This setup may conflict with
|
||||
other aspects of your gateway including but not limited to traffic shaping
|
||||
@ -320,7 +320,7 @@ 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
|
||||
@ -476,7 +476,7 @@ zone to the internet.<br>
|
||||
|
||||
<blockquote> </blockquote>
|
||||
|
||||
<p><font size="-1"> Updated 2/21/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 +490,6 @@ zone to the internet.<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
<br>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@ -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 > /tmp/status.txt</font></b><br>
|
||||
3.<b><font color="#009900"> /sbin/shorewall status > /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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user