forked from extern/shorewall_code
dfe1ffbd37
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1061 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
363 lines
15 KiB
XML
363 lines
15 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>2004-01-06</pubdate>
|
|
|
|
<copyright>
|
|
<year>2001-2004</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>
|
|
|
|
<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'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://lists.shorewall.net/htdig/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> /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>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 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 <filename><ulink
|
|
url="Documentation.htm#Interfaces">/etc/shorewall/interfaces</ulink></filename>
|
|
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 <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>-><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)
|
|
ACCEPT   <emphasis><source zone></emphasis>   <emphasis><destination zone></emphasis>    icmp    echo-request</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    eth0    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>Similarly, since Shorewall gives no special treatment to
|
|
<quote>ping</quote>packets, these packets are subject to logging
|
|
specifications in policies. This allows people pinging your firewall
|
|
to create large number of messages in your log. These messages can be
|
|
eliminated by the following rule:<programlisting>#ACTION SOURCE DEST PROTO DEST
|
|
# PORT(S)
|
|
DROP net fw icmp echo-request</programlisting></para>
|
|
</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="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 <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>1.6</revnumber><date>2005-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> |