forked from extern/shorewall_code
ae71fc3cc2
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@5246 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
426 lines
17 KiB
XML
426 lines
17 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><?dbtimestamp format="Y/m/d"?></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><quote>shorewall start</quote> and <quote>shorewall restart</quote>
|
|
Errors</title>
|
|
|
|
<para>You receive an error message when starting or restarting the
|
|
firewall and you can't determine the cause. First, if your VERBOSITY
|
|
setting in shorewall.conf is less than 2, then try running with a higher
|
|
verbosity level by using the "-v" option:</para>
|
|
|
|
<blockquote>
|
|
<programlisting><command>shorewall -vv [re]start</command></programlisting>
|
|
</blockquote>
|
|
|
|
<para>That will give you additional progress messages that may make it
|
|
clear which entry in which file is generating the error.</para>
|
|
|
|
<para>If that didn't help, 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 <ulink url="FAQ.htm#faq2">FAQ 2</ulink>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Trying to test net->loc DNAT rules from inside your firewall.
|
|
You must test these rules from <emphasis
|
|
role="bold">outside</emphasis> your firewall.</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>One very important thing to remember is that not all connection
|
|
problems are Shorewall configuration problems. If the connection that is
|
|
giving you problems is to or from the firewall system or if it doesn't
|
|
rely on NAT or Proxy ARP then you can often eliminate Shorewall using a
|
|
simple test:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><command>/sbin/shorewall clear</command></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Try the connection. If it works then the problem is in your
|
|
Shorewall configuration; if the connection still doesn't work then the
|
|
problem is not with Shorewall or the way that it is configured.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Be sure to <command>/sbin/shorewall start</command> after the
|
|
test.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>If you still suspect Shorewall and 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)
|
|
Ping/ACCEPT <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>
|
|
|
|
<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>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>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>
|
|
|
|
<listitem>
|
|
<para>You have connected two firewall interfaces (from different
|
|
zones) to the same hub or switch.</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 and
|
|
correct.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Do you have your kernel properly configured? <ulink
|
|
url="kernel.htm">Click here to see kernel configuration
|
|
information</ulink>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Still Having Problems?</title>
|
|
|
|
<para>See the <ulink url="support.htm">Shorewall Support
|
|
Page</ulink>.</para>
|
|
</section>
|
|
</article> |