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

Convert troubleshoot.htm to XML Docbook

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@918 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2003-12-23 19:39:06 +00:00
parent 06d236a5b7
commit 1f9f97ef26
2 changed files with 335 additions and 199 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

199
Shorewall-docs/troubleshoot.htm
View File

@ -1,199 +0,0 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=windows-1252">
<title>Shorewall Troubleshooting</title>
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
</head>
<body>
<h1 align="center" style="background-color: rgb(255, 255, 255);">Shorewall
Troubleshooting <img src="images/obrasinf.gif"
alt="Beating head on table" style="width: 90px; height: 90px;"
align="middle" title=""></h1>
<h3 style="text-align: center;"><span style="font-style: italic;">"If
you think you can you can; if you think you can't you're right.<br>
If you don't believe that you can, why should someone else?" -- Gunnar
Tapper<br>
</span></h3>
<h3 align="left">Check the Errata</h3>
<p align="left">Check the <a href="errata.htm">Shorewall Errata</a> to
be sure that there isn't an update that you are missing for your
version of the firewall.</p>
<h3 align="left">Check the FAQs</h3>
<p align="left">Check the <a href="FAQ.htm">FAQs</a> for solutions to
common problems.</p>
<h3 align="left">If the firewall fails to start</h3>
If you receive an error message when starting or restarting the
firewall and you can't determine the cause, then do the following:
<ul>
<li>Make a note of the error message that you see.<br>
</li>
<li>shorewall debug start 2&gt; /tmp/trace</li>
<li>Look at the /tmp/trace file and see if that helps you determine
what the problem is. Be sure you find the place in the log where the
error message you saw is generated -- If you are using Shorewall 1.4.0
or later, you should find the message near the end of the log.</li>
<li>If you still can't determine what's wrong then see the <a
href="support.htm">support page</a>.</li>
</ul>
Here's an example. During startup, a user sees the following:<br>
<blockquote>
<pre>Adding Common Rules<br>iptables: No chain/target/match by that name<br>Terminated<br></pre>
</blockquote>
A search through the trace for "No chain/target/match by that name"
turned up the following:&nbsp;
<blockquote>
<pre>+ echo 'Adding Common Rules'<br>+ add_common_rules<br>+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset<br>++ sed 's/!/! /g'<br>+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset<br>iptables: No chain/target/match by that name<br></pre>
</blockquote>
The command that failed was: "iptables -A reject -p tcp -j REJECT
--reject-with tcp-reset". In this case, the user had compiled his own
kernel and had
forgotten to include REJECT target support (see <a href="kernel.htm">kernel.htm</a>)
<h3>Your network environment</h3>
<p>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular
snafus: </p>
<ul>
<li>Port Forwarding where client and server are in the same subnet.
See <a href="FAQ.htm">FAQ 2.</a></li>
<li>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe
that the system is in the 'net' zone.</li>
<li>Multiple interfaces connected to the same HUB or Switch. Given
the way that the Linux kernel respond to ARP "who-has" requests, this
type of setup does NOT work the way that you expect it to. If you
are running Shorewall version 1.4.7 or later, you can test using this
kind of configuration if you specify
the <span style="font-weight: bold;">arp_filter</span>
option in /etc/shorewall/interfaces for all interfaces connected to the
common hub/switch. Using such a setup with a production firewall is
strongly recommended against.</li>
</ul>
<h3 align="left">If you are having connection problems:</h3>
<p align="left">If the appropriate policy for the connection that you
are trying to make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES
TRYING TO MAKE IT WORK. Such additional rules will NEVER make it work,
they add clutter to your rule set and they represent a big security
hole
in the event that you forget to remove them later.</p>
<p align="left">I also recommend against setting all of your policies
to ACCEPT in an effort to make something work. That robs you of one of
your best diagnostic tools - the "Shorewall" messages that Netfilter
will generate when you try to connect in a way that isn't permitted by
your rule set.</p>
<p align="left">Check your log ("/sbin/shorewall show log"). If you
don't see Shorewall messages, then your problem is probably NOT a
Shorewall problem. If you DO see packet messages, it may be an
indication that
you are missing one or more rules -- see <a href="FAQ.htm#faq17">FAQ 17</a>.</p>
<p align="left">While you are troubleshooting, it is a good idea to
clear two variables in /etc/shorewall/shorewall.conf:</p>
<p align="left">LOGRATE=""<br>
LOGBURST=""</p>
<p align="left">This way, you will see all of the log messages being
generated (be sure to restart shorewall after clearing these variables).</p>
<p align="left">Example:</p>
<font face="Century Gothic, Arial, Helvetica">
<p align="left"><font face="Courier">Jun 27 15:37:56 gateway kernel:
Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2
DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
SPT=1803 DPT=53 LEN=47</font></p>
</font>
<p align="left">Let's look at the important parts of this message:</p>
<ul>
<li>all2all:REJECT - This packet was REJECTed out of the
all2all chain -- the packet was rejected under the "all"-&gt;"all"
REJECT policy (see <a href="FAQ.htm#faq17">FAQ 17).</a></li>
<li>IN=eth2 - the packet entered the firewall via eth2</li>
<li>OUT=eth1 - if accepted, the packet would be sent on eth1</li>
<li>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</li>
<li>DST=192.168.1.3 - the packet is destined for 192.168.1.3</li>
<li>PROTO=UDP - UDP Protocol</li>
<li>DPT=53 - DNS</li>
</ul>
<p align="left">In this case, 192.168.2.2 was in the "dmz" zone and
192.168.1.3 is in the "loc" zone. I was missing the rule:</p>
<p align="left">ACCEPT&nbsp;&nbsp;&nbsp; dmz&nbsp;&nbsp;&nbsp;
loc&nbsp;&nbsp;&nbsp; udp&nbsp;&nbsp;&nbsp; 53<br>
</p>
<p align="left">See <a href="FAQ.htm#faq17">FAQ 17</a> for additional
information about how to interpret the chain name appearing in a
Shorewall log message.<br>
</p>
<h3 align="left">'Ping' Problems?</h3>
Either can't ping when you think you should be able to or are able to
ping when you think that you shouldn't be allowed? Shorewall's 'Ping'
Management<a href="ping.html"> is described here</a>.<br>
<h3 align="left">Other Gotchas</h3>
<ul>
<li>Seeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that:
<ol>
<li>your zone definitions are screwed up and the host that is
sending the packets or the destination host isn't in any zone (using an
<a href="Documentation.htm#Hosts">/etc/shorewall/hosts</a> file
are you?); or</li>
<li>the source and destination hosts are both connected to the
same interface and you haven't specified the 'routeback' option on that
interface.</li>
</ol>
</li>
<li>Remember that Shorewall doesn't automatically allow ICMP type 8
("ping") requests to be sent between zones. If you want pings to be
allowed between zones, you need a rule of the form:<br>
<br>
&nbsp;&nbsp;&nbsp; ACCEPT&nbsp;&nbsp;&nbsp; &lt;source
zone&gt;&nbsp;&nbsp;&nbsp; &lt;destination zone&gt;&nbsp;&nbsp;&nbsp;
icmp&nbsp;&nbsp;&nbsp; echo-request<br>
<br>
The ramifications of this can be subtle. For example, if you have the
following in /etc/shorewall/nat:<br>
<br>
&nbsp;&nbsp;&nbsp; 10.1.1.2&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp;
130.252.100.18<br>
<br>
and you ping 130.252.100.18, unless you have allowed icmp type 8
between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped.&nbsp;</li>
<li>If you specify "routefilter" for an interface, that interface
must be up prior to starting the firewall.</li>
<li>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to
the IP address of their nearest firewall interface. One often
overlooked aspect of routing is that in order for two hosts to
communicate,
the routing between them must be set up <u>in both directions.</u>
So when setting up routing between <b>A</b> and<b> B</b>, be sure
to verify that the route from <b>B</b> back to <b>A</b> is defined.</li>
<li>Some versions of LRP (EigerStein2Beta for example) have a shell
with broken variable expansion. <a
href="ftp://ftp.shorewall.net/pub/shorewall/ash.gz"> You can get a
corrected shell from the Shorewall Errata download site.</a> </li>
<li>Do you have your kernel properly configured? <a href="kernel.htm">Click
here to see my kernel configuration.</a> </li>
<li>Shorewall requires the "ip" program. That program is generally
included in the "iproute" package which should be included with your
distribution (though many distributions don't install iproute by
default). You may also download the latest source tarball from <a
href="ftp://ftp.inr.ac.ru/ip-routing" target="_blank">
ftp://ftp.inr.ac.ru/ip-routing</a> .</li>
<li>Problems with NAT? Be sure that you let
Shorewall add all external addresses to be use with NAT unless you
have set <a href="Documentation.htm#Aliases"> ADD_IP_ALIASES</a> =No
in /etc/shorewall/shorewall.conf.</li>
</ul>
<h3>Still Having Problems?</h3>
<p>See the<a href="support.htm"> support page.<br>
</a></p>
<font face="Century Gothic, Arial, Helvetica">
<blockquote> </blockquote>
</font>
<p><font size="2">Last updated 11/1/2003 - Tom Eastep</font> </p>
<p><font face="Trebuchet MS"><a href="copyright.htm"><font size="2">Copyright</font>
© <font size="2">2001, 2002 Thomas M. Eastep.</font></a></font><br>
</p>
<br>
</body>
</html>

335
Shorewall-docs/troubleshoot.xml Normal file
View File

@ -0,0 +1,335 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- $Id$ -->
<article id="usefull_links">
<articleinfo>
<title>Shorewall Troubleshooting Guide</title>
<author>
<firstname>Thomas</firstname>
<othername>M.</othername>
<surname>Eastep</surname>
</author>
<pubdate>2003/12/22</pubdate>
<copyright>
<year>2003</year>
<holder>Thomas M. Eastep</holder>
</copyright>
<legalnotice>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.2 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover, and with no Back-Cover
Texts. A copy of the license is included in the section entitled
<quote><ulink type="" url="Copyright.htm">GNU Free Documentation License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<graphic align="center" fileref="images/obrasinf.gif" />
<para><emphasis role="bold">&#34;If you think you can you can; if you think
you can&#39;t you&#39;re right. If you don&#39;t believe that you can, why
should someone else?&#34; -- Gunnar Tapper</emphasis> </para>
<section>
<title>First Steps</title>
<para>Some problems are easily solved by checking one of the resources
described in the following sections.</para>
<section>
<title>Check the FAQs.</title>
<para>Check the <ulink url="FAQ.htm">FAQs</ulink> for solutions to over
30 common problems.</para>
</section>
<section>
<title>Check the Errata</title>
<para>Check the <ulink url="errata.htm">Shorewall Errata</ulink> to be
sure that there isn&#39;t an update that you are missing for your
version of the firewall.</para>
</section>
</section>
<section>
<title>&#34;shorewall start&#34; and &#34;shorewall restart&#34; Errors</title>
<para>If you receive an error message when starting or restarting the
firewall and you can&#39;t determine the cause, then do the following:
</para>
<itemizedlist>
<listitem>
<para>Make a note of the error message that you see. </para>
</listitem>
<listitem>
<para>shorewall debug start 2&#62; /tmp/trace</para>
</listitem>
<listitem>
<para>Look at the /tmp/trace file and see if that helps you determine
what the problem is. Be sure you find the place in the log where the
error message you saw is generated -- If you are using Shorewall 1.4.0
or later, you should find the message near the end of the log.</para>
</listitem>
<listitem>
<para>If you still can&#39;t determine what&#39;s wrong then see the
<ulink url="support.htm">support page</ulink>.</para>
</listitem>
</itemizedlist>
<example>
<title>Startup Error</title>
<para>During startup, a user sees the following:</para>
<programlisting> Adding Common Rules
iptables: No chain/target/match by that name
Terminated</programlisting>
<para>A search through the trace for &#34;No chain/target/match by that
name&#34; turned up the following:</para>
<programlisting> + echo &#39;Adding Common Rules&#39;
+ add_common_rules
+ run_iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
++ echo -A reject -p tcp -j REJECT --reject-with tcp-reset
++ sed &#39;s/!/! /g&#39;
+ iptables -A reject -p tcp -j REJECT --reject-with tcp-reset
iptables: No chain/target/match by that name
</programlisting>
<para>The command that failed was: &#34;iptables -A reject -p tcp -j
REJECT --reject-with tcp-reset&#34;. In this case, the user had compiled
his own kernel and had forgotten to include REJECT target support (see
<ulink url="kernel.htm">kernel.htm</ulink>) </para>
</example>
</section>
<section>
<title>Your Network Environment</title>
<para>Many times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular snafus:
</para>
<itemizedlist>
<listitem>
<para>Port Forwarding where client and server are in the same subnet.
See FAQ 2.</para>
</listitem>
<listitem>
<para>Changing the IP address of a local system to be in the external
subnet, thinking that Shorewall will suddenly believe that the system
is in the &#39;net&#39; zone.</para>
</listitem>
<listitem>
<para>Multiple interfaces connected to the same HUB or Switch. Given
the way that the Linux kernel respond to ARP &#34;who-has&#34;
requests, this type of setup does NOT work the way that you expect it
to. If you are running Shorewall version 1.4.7 or later, you can test
using this kind of configuration if you specify the <emphasis
role="bold">arp_filter</emphasis> option in <ulink
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>
for all interfaces connected to the common hub/switch. Using such a
setup with a production firewall is strongly recommended against.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Connection Problems</title>
<para>If the appropriate policy for the connection that you are trying to
make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING TO MAKE
IT WORK. Such additional rules will NEVER make it work, they add clutter
to your rule set and they represent a big security hole in the event that
you forget to remove them later.</para>
<para>I also recommend against setting all of your policies to ACCEPT in
an effort to make something work. That robs you of one of your best
diagnostic tools - the &#34;Shorewall&#34; messages that Netfilter will
generate when you try to connect in a way that isn&#39;t permitted by your
rule set.</para>
<para>Check your log (&#34;/sbin/shorewall show log&#34;). If you
don&#39;t see Shorewall messages, then your problem is probably NOT a
Shorewall problem. If you DO see packet messages, it may be an indication
that you are missing one or more rules -- see <ulink url="FAQ.htm#faq17">FAQ
17</ulink>.</para>
<para>While you are troubleshooting, it is a good idea to clear two
variables in /etc/shorewall/shorewall.conf:</para>
<para><programlisting> LOGRATE=&#34;&#34;
LOGBURST=&#34;&#34;</programlisting>This way, you will see all of the log
messages being generated (be sure to restart shorewall after clearing
these variables).</para>
<example>
<title>Log Message</title>
<programlisting>Jun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2 DST=192.168.1.3
LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP SPT=1803 DPT=53 LEN=47</programlisting>
<para>Let&#39;s look at the important parts of this message:</para>
<itemizedlist>
<listitem>
<para>all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the
&#34;all&#34;-&#62;&#34;all&#34; REJECT policy (see <ulink
url="FAQ.htm#faq17">FAQ 17</ulink>).</para>
</listitem>
<listitem>
<para>IN=eth2 - the packet entered the firewall via eth2</para>
</listitem>
<listitem>
<para>OUT=eth1 - if accepted, the packet would be sent on eth1</para>
</listitem>
<listitem>
<para>SRC=192.168.2.2 - the packet was sent by 192.168.2.2</para>
</listitem>
<listitem>
<para>DST=192.168.1.3 - the packet is destined for 192.168.1.3</para>
</listitem>
<listitem>
<para>PROTO=UDP - UDP Protocol</para>
</listitem>
<listitem>
<para>DPT=53 - DNS</para>
</listitem>
</itemizedlist>
<para>In this case, 192.168.2.2 was in the &#34;dmz&#34; zone and
192.168.1.3 is in the &#34;loc&#34; zone. I was missing the rule:</para>
<programlisting>ACCEPT dmz loc udp 53</programlisting>
</example>
</section>
<section>
<title>Ping Problems</title>
<para> Either can&#39;t ping when you think you should be able to or are
able to ping when you think that you shouldn&#39;t be allowed?
Shorewall&#39;s &#39;Ping&#39; Management is <ulink url="ping.html">described
here</ulink>.</para>
</section>
<section>
<title>Other Gotchas</title>
<itemizedlist>
<listitem>
<para>Seeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that: </para>
<orderedlist>
<listitem>
<para>your zone definitions are screwed up and the host that is
sending the packets or the destination host isn&#39;t in any zone
(using an <ulink url="Documentation.htm#Hosts">/etc/shorewall/hosts</ulink>
file are you?); or</para>
</listitem>
<listitem>
<para>the source and destination hosts are both connected to the
same interface and you don&#39;t have a policy or rule for the
source zone to or from the destination zone or you haven&#39;t set
the <emphasis role="bold">routeback</emphasis> option for the
interface in <ulink url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink>.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>Remember that Shorewall doesn&#39;t automatically allow ICMP
type 8 (&#34;ping&#34;) requests to be sent between zones. If you want
pings to be allowed between zones, you need a rule of the form:</para>
<programlisting>&#x00A0;&#x00A0;&#x00A0; ACCEPT&#x00A0;&#x00A0;&#x00A0; <emphasis>&#60;source zone&#62;</emphasis>&#x00A0;&#x00A0;&#x00A0; <emphasis>&#60;destination zone&#62;</emphasis>&#x00A0;&#x00A0;&#x00A0; icmp&#x00A0;&#x00A0;&#x00A0; echo-request</programlisting>
<para> The ramifications of this can be subtle. For example, if you
have the following in <ulink url="NAT.htm">/etc/shorewall/nat</ulink>:</para>
<programlisting>&#x00A0;&#x00A0;&#x00A0; 10.1.1.2&#x00A0;&#x00A0;&#x00A0; eth0&#x00A0;&#x00A0;&#x00A0; 130.252.100.18</programlisting>
<para>and you ping 130.252.100.18, unless you have allowed icmp type 8
between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped.</para>
</listitem>
<listitem>
<para>If you specify &#34;routefilter&#34; for an interface, that
interface must be up prior to starting the firewall.</para>
</listitem>
<listitem>
<para>Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect of
routing is that in order for two hosts to communicate, the routing
between them must be set up <emphasis role="underline">in both
directions</emphasis>. So when setting up routing between <emphasis
role="bold">A</emphasis> and <emphasis role="bold">B</emphasis>, be
sure to verify that the route from <emphasis role="bold">B</emphasis>
back to <emphasis role="bold">A</emphasis> is defined.</para>
</listitem>
<listitem>
<para>Some versions of LRP (EigerStein2Beta for example) have a shell
with broken variable expansion. You can get a corrected shell from the
<ulink url="ftp://ftp.shorewall.net/pub/shorewall/ash.gz">Shorewall
Errata download site</ulink>. </para>
</listitem>
<listitem>
<para>Do you have your kernel properly configured? <ulink
url="kernel.htm">Click here to see my kernel configuration</ulink>.
</para>
</listitem>
<listitem>
<para>Shorewall requires the &#34;ip&#34; program. That program is
generally included in the &#34;iproute&#34; package which should be
included with your distribution (though many distributions don&#39;t
install iproute by default). You may also download the latest source
tarball from <ulink url="ftp://ftp.inr.ac.ru/ip-routing">ftp://ftp.inr.ac.ru/ip-routing</ulink>
.</para>
</listitem>
<listitem>
<para>Problems with NAT? Be sure that you let Shorewall add all
external addresses to be use with NAT unless you have set <ulink
url="Shorewall_and_Aliased_Interfaces.html">ADD_IP_ALIASES</ulink> =No
in /etc/shorewall/shorewall.conf.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Still Having Problems?</title>
<para>See the <ulink url="support.htm">Shorewall Support Page</ulink>.</para>
</section>
</article>