forked from extern/shorewall_code
Convert troubleshoot.htm to XML Docbook
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@918 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
06d236a5b7
commit
1f9f97ef26
@ -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> /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:
|
|
||||||
<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"->"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 dmz
|
|
||||||
loc udp 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>
|
|
||||||
ACCEPT <source
|
|
||||||
zone> <destination zone>
|
|
||||||
icmp echo-request<br>
|
|
||||||
<br>
|
|
||||||
The ramifications of this can be subtle. For example, if you have the
|
|
||||||
following in /etc/shorewall/nat:<br>
|
|
||||||
<br>
|
|
||||||
10.1.1.2 eth0
|
|
||||||
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. </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
335
Shorewall-docs/troubleshoot.xml
Normal 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">"If you think you can you can; if you think
|
||||||
|
you can't you're right. If you don't believe that you can, why
|
||||||
|
should someone else?" -- 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't an update that you are missing for your
|
||||||
|
version of the firewall.</para>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
|
||||||
|
<section>
|
||||||
|
<title>"shorewall start" and "shorewall restart" 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>shorewall debug start 2> /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'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 "No chain/target/match by that
|
||||||
|
name" 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: "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
|
||||||
|
<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 'net' zone.</para>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>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 <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 "Shorewall" 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 ("/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 <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=""
|
||||||
|
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
|
||||||
|
"all"->"all" 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 "dmz" zone and
|
||||||
|
192.168.1.3 is in the "loc" zone. I was missing the rule:</para>
|
||||||
|
|
||||||
|
<programlisting>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 'Ping' 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'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'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">/etc/shorewall/interfaces</ulink>.</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
<listitem>
|
||||||
|
<para>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:</para>
|
||||||
|
|
||||||
|
<programlisting>    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 <ulink url="NAT.htm">/etc/shorewall/nat</ulink>:</para>
|
||||||
|
|
||||||
|
<programlisting>    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>If you specify "routefilter" 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 "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 <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>
|
||||||
Loading…
Reference in New Issue
Block a user