extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-29 11:04:03 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update the Troubleshooting Guide

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@4569 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-09-12 18:32:37 +00:00
parent bca1adfcf6
commit c718894e4c
1 changed files with 93 additions and 181 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

274
docs/troubleshoot.xml
View File

@ -32,37 +32,6 @@
</legalnotice> </legalnotice>
</articleinfo> </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> <section>
<title><quote>shorewall start</quote> and <quote>shorewall restart</quote> <title><quote>shorewall start</quote> and <quote>shorewall restart</quote>
Errors</title> Errors</title>
@ -121,62 +90,6 @@ iptables: No chain/target/match by that name
</example> </example>
</section> </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> <section>
<title>Your Network Environment</title> <title>Your Network Environment</title>
@ -187,7 +100,7 @@ iptables: No chain/target/match by that name
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>Port Forwarding where client and server are in the same subnet. <para>Port Forwarding where client and server are in the same subnet.
See FAQ 2.</para> See <ulink url="FAQ.htm#faq2">FAQ 2</ulink>.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -228,11 +141,35 @@ iptables: No chain/target/match by that name
<section> <section>
<title>Connection Problems</title> <title>Connection Problems</title>
<para>If the appropriate policy for the connection that you are trying to <para>One very important thing to remember is that not all connection
make is ACCEPT, please DO NOT ADD ADDITIONAL ACCEPT RULES TRYING TO MAKE problems are Shorewall configuration problems. If the connection that is
IT WORK. Such additional rules will NEVER make it work, they add clutter giving you problems is to or from the firewall system or if it doesn't
to your rule set and they represent a big security hole in the event that rely on NAT or Proxy ARP then you can often eliminate Shorewall using a
you forget to remove them later.</para> 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 <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 an effort to make something work. That robs you of one of your best
@ -354,6 +291,62 @@ Ping/DROP net all</programlisting>
</itemizedlist> </itemizedlist>
</section> </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> <section>
<title>Other Gotchas</title> <title>Other Gotchas</title>
@ -379,6 +372,11 @@ Ping/DROP net all</programlisting>
interface in <ulink interface in <ulink
url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para> url="Documentation.htm#Interfaces"><filename>/etc/shorewall/interfaces</filename></ulink>.</para>
</listitem> </listitem>
<listitem>
<para>You have connected two firewall interfaces (from different
zones) to the same hub or switch.</para>
</listitem>
</orderedlist> </orderedlist>
</listitem> </listitem>
@ -396,14 +394,8 @@ Ping/DROP net all</programlisting>
directions</emphasis>. So when setting up routing between <emphasis directions</emphasis>. So when setting up routing between <emphasis
role="bold">A</emphasis> and <emphasis role="bold">B</emphasis>, be role="bold">A</emphasis> and <emphasis role="bold">B</emphasis>, be
sure to verify that the route from <emphasis role="bold">B</emphasis> sure to verify that the route from <emphasis role="bold">B</emphasis>
back to <emphasis role="bold">A</emphasis> is defined.</para> back to <emphasis role="bold">A</emphasis> is defined and
</listitem> correct.</para>
<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>
<listitem> <listitem>
@ -437,84 +429,4 @@ Ping/DROP net all</programlisting>
<para>See the <ulink url="support.htm">Shorewall Support <para>See the <ulink url="support.htm">Shorewall Support
Page</ulink>.</para> Page</ulink>.</para>
</section> </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> </article>