forked from extern/shorewall_code
9edbc16770
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@2026 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
498 lines
18 KiB
XML
498 lines
18 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-03-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
|
|
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://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> /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->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 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>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>-><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)
|
|
AllowPing <emphasis><source zone></emphasis> <emphasis><destination zone></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 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>
|
|
</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>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> |