1
0
mirror of https://gitlab.com/shorewall/code.git synced 2024-12-15 19:01:19 +01:00
shorewall_code/docs/troubleshoot.xml
judas_iscariote 4033e6051b renamed to a simpler "docs"
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3521 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
2006-02-23 01:22:17 +00:00

520 lines
19 KiB
XML

<?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">
<article id="usefull_links">
<!--$Id$-->
<articleinfo>
<title>Shorewall Troubleshooting Guide</title>
<author>
<firstname>Tom</firstname>
<surname>Eastep</surname>
</author>
<pubdate>2005-11-22</pubdate>
<copyright>
<year>2001-2005</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="GnuCopyright.htm">GNU Free Documentation
License</ulink></quote>.</para>
</legalnotice>
</articleinfo>
<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
50 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't an update that you are missing for your version of
the firewall.</para>
</section>
<section>
<title>Try Searching the Shorewall Site and Mailing List
Archives</title>
<para>The <ulink url="http://shorewall.net/search.html">Site and Mailing
List Archives search facility</ulink> can locate documents and posts
about similar problems.</para>
</section>
</section>
<section>
<title><quote>shorewall start</quote> and <quote>shorewall restart</quote>
Errors</title>
<para>If you receive an error message when starting or restarting the
firewall and you can'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><command>shorewall debug start 2&gt; /tmp/trace</command></para>
</listitem>
<listitem>
<para>Look at the <filename>/tmp/trace</filename> 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't determine what'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 <quote>No chain/target/match by
that name</quote> turned up the following:</para>
<programlisting>+ echo 'Adding Common Rules'
+ 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 's/!/! /g'
+ 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: <quote><command>iptables -A reject -p
tcp -j REJECT --reject-with tcp-reset</command></quote>. 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>Some Things to Keep in Mind</title>
<itemizedlist>
<listitem>
<para><emphasis role="bold">You cannot test your firewall from the
inside</emphasis>. Just because you send requests to your firewall
external IP address does not mean that the request will be associated
with the external interface or the <quote>net</quote> zone. Any
traffic that you generate from the local network will be associated
with your local interface and will be treated as loc-&gt;fw
traffic.</para>
</listitem>
<listitem>
<para><emphasis role="bold">IP addresses are properties of systems,
not of interfaces</emphasis>. It is a mistake to believe that your
firewall is able to forward packets just because you can ping the IP
address of all of the firewall's interfaces from the local network.
The only conclusion you can draw from such pinging success is that the
link between the local system and the firewall works and that you
probably have the local system's default gateway set correctly.</para>
</listitem>
<listitem>
<para><emphasis role="bold">All IP addresses configured on firewall
interfaces are in the $FW (fw) zone</emphasis>. If 192.168.1.254 is
the IP address of your internal interface then you can write
<quote><emphasis role="bold">$FW:192.168.1.254</emphasis></quote> in a
rule but you may not write <quote><emphasis
role="bold">loc:192.168.1.254</emphasis></quote>. Similarly, it is
nonsensical to add 192.168.1.254 to the <emphasis
role="bold">loc</emphasis> zone using an entry in
<filename>/etc/shorewall/hosts</filename>.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Reply packets do NOT automatically follow
the reverse path of the one taken by the original request</emphasis>.
All packets are routed according to the routing table of the host at
each step of the way. This issue commonly comes up when people install
a Shorewall firewall parallel to an existing gateway and try to use
DNAT through Shorewall without changing the default gateway of the
system receiving the forwarded requests. Requests come in through the
Shorewall firewall where the destination IP address gets rewritten but
replies go out unmodified through the old gateway.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Shorewall itself has no notion of inside
or outside</emphasis>. These concepts are embodied in how Shorewall is
configured.</para>
</listitem>
</itemizedlist>
</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 <quote>net</quote> zone.</para>
</listitem>
<listitem>
<para>Multiple interfaces connected to the same HUB or Switch. Given
the way that the Linux kernel respond to ARP <quote>who-has</quote>
requests, this type of setup <emphasis role="bold">does NOT work the
way that you expect it to</emphasis>. You can test using this kind of
configuration if you specify the <emphasis
role="bold">arp_filter</emphasis> option or the <emphasis
role="bold">arp_ignore</emphasis> option in <filename><ulink
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink></filename>
for all interfaces connected to the common hub/switch. <emphasis
role="bold">Using such a setup with a production firewall is strongly
recommended against</emphasis>.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>New Device Doesn't Work?</title>
<para>If you have just added a new device such as VOIP and it doesn't
work, be sure that you have assigned it an IP address in your local
network and that its default gateway has been set to the IP address of
your internal interface. For many of these devices, the simplest solution
is to run a DHCP server; running it on your firewall is fine — be sure to
set the <emphasis role="bold">dhcp</emphasis> option on your internal
interface in <ulink
url="Documentation.htm#INterfaces">/etc/shorewall/interfaces</ulink>.</para>
</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 <quote>Shorewall</quote> messages that Netfilter
will generate when you try to connect in a way that isn't permitted by
your rule set.</para>
<para>Check your log (<quote><command>/sbin/shorewall show
log</command></quote>). 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 <ulink url="FAQ.htm#faq17">FAQ 17</ulink>.</para>
<para>While you are troubleshooting, it is a good idea to clear two
variables in
<filename><filename>/etc/shorewall/shorewall.conf</filename></filename>:</para>
<para><programlisting>LOGRATE=
LOGBURST=""</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'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
<quote>all</quote>-&gt;<quote>all</quote> 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 <quote>dmz</quote> zone and
192.168.1.3 is in the <quote>loc</quote> zone. I was missing the
rule:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT dmz loc udp 53</programlisting>
</example>
</section>
<section>
<title>Ping Problems</title>
<para>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
<quote>Ping</quote> Management is <ulink url="ping.html">described
here</ulink>. Here are a couple of tips:</para>
<itemizedlist>
<listitem>
<para>Remember that Shorewall doesn't automatically allow ICMP type 8
(<quote>ping</quote>) requests to be sent between zones. If you want
pings to be allowed between zones, you need a rule of the form:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST
# PORT(S)
Ping/ACCEPT <emphasis>&lt;source zone&gt;</emphasis>&nbsp;&nbsp; <emphasis>&lt;destination zone&gt;</emphasis></programlisting>
<para>The ramifications of this can be subtle. For example, if you
have the following in <filename><ulink
url="NAT.htm">/etc/shorewall/nat</ulink></filename>:</para>
<programlisting>#EXTERNAL INTERFACE INTERNAL
10.1.1.2&nbsp;&nbsp;&nbsp; eth0&nbsp;&nbsp;&nbsp; 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>Ping requests are subject to logging under your policies. So
ping floods can cause an equally big flood of log messages. To
eliminate these, as the last rule in your /etc/shorewall/rules file
add:</para>
<programlisting>#ACTION SOURCE DEST PROTO DEST
# PORT(S)
Ping/DROP net all</programlisting>
</listitem>
</itemizedlist>
</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't in any zone
(using an <ulink
url="Documentation.htm#Hosts"><filename>/etc/shorewall/hosts</filename></ulink>
file are you?); or</para>
</listitem>
<listitem>
<para>the source and destination hosts are both connected to the
same interface and you don't have a policy or rule for the source
zone to or from the destination zone or you haven't set the
<emphasis role="bold">routeback</emphasis> option for the
interface in <ulink
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>If you specify <quote>routefilter</quote> 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="bold">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 <quote>ip</quote> program. That program
is generally included in the <quote>iproute</quote> 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 <ulink
url="http://developer.osdl.org/dev/iproute2/download/">http://developer.osdl.org/dev/iproute2/download/</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 <filename>/etc/shorewall/shorewall.conf</filename>.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Still Having Problems?</title>
<para>See the <ulink url="support.htm">Shorewall Support
Page</ulink>.</para>
</section>
<appendix>
<title>Revision History</title>
<para><revhistory>
<revision>
<revnumber>2.0</revnumber>
<date>2005-09-11</date>
<authorinitials>CR</authorinitials>
<revremark>Updated for Shorewall 3.0</revremark>
</revision>
<revision>
<revnumber>1.9</revnumber>
<date>2004-08-25</date>
<authorinitials>TE</authorinitials>
<revremark>Advice for the networking-challenged.</revremark>
</revision>
<revision>
<revnumber>1.8</revnumber>
<date>2004-04-03</date>
<authorinitials>TE</authorinitials>
<revremark>Point out that firewall addresses are in the $FW
zone.</revremark>
</revision>
<revision>
<revnumber>1.7</revnumber>
<date>2004-02-02</date>
<authorinitials>TE</authorinitials>
<revremark>Add hint about testing from inside the
firewall.</revremark>
</revision>
<revision>
<revnumber>1.6</revnumber>
<date>2004-01-06</date>
<authorinitials>TE</authorinitials>
<revremark>Add pointer to Site and Mailing List Archives
Searches.</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>2004-01-01</date>
<authorinitials>TE</authorinitials>
<revremark>Added information about eliminating ping-generated log
messages.</revremark>
</revision>
<revision>
<revnumber>1.4</revnumber>
<date>2003-12-22</date>
<authorinitials>TE</authorinitials>
<revremark>Initial Docbook Conversion</revremark>
</revision>
</revhistory></para>
</appendix>
</article>