diff --git a/docs/troubleshoot.xml b/docs/troubleshoot.xml index 445ee32af..ea4d78437 100644 --- a/docs/troubleshoot.xml +++ b/docs/troubleshoot.xml @@ -32,37 +32,6 @@ -
- First Steps - - Some problems are easily solved by checking one of the resources - described in the following sections. - -
- Check the FAQs. - - Check the FAQs for solutions to over - 50 common problems. -
- -
- Check the Errata - - Check the Shorewall Errata to be - sure that there isn't an update that you are missing for your version of - the firewall. -
- -
- Try Searching the Shorewall Site and Mailing List - Archives - - The Site and Mailing - List Archives search facility can locate documents and posts - about similar problems. -
-
-
<quote>shorewall start</quote> and <quote>shorewall restart</quote> Errors @@ -121,62 +90,6 @@ iptables: No chain/target/match by that name
-
- Some Things to Keep in Mind - - - - You cannot test your firewall from the - inside. 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 net 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. - - - - IP addresses are properties of systems, - not of interfaces. 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. - - - - All IP addresses configured on firewall - interfaces are in the $FW (fw) zone. If 192.168.1.254 is - the IP address of your internal interface then you can write - $FW:192.168.1.254 in a - rule but you may not write loc:192.168.1.254. Similarly, it is - nonsensical to add 192.168.1.254 to the loc zone using an entry in - /etc/shorewall/hosts. - - - - Reply packets do NOT automatically follow - the reverse path of the one taken by the original request. - 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. - - - - Shorewall itself has no notion of inside - or outside. These concepts are embodied in how Shorewall is - configured. - - -
-
Your Network Environment @@ -187,7 +100,7 @@ iptables: No chain/target/match by that name Port Forwarding where client and server are in the same subnet. - See FAQ 2. + See FAQ 2. @@ -228,11 +141,35 @@ iptables: No chain/target/match by that name
Connection Problems - 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. + 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: + + + + /sbin/shorewall clear + + + + 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. + + + + Be sure to /sbin/shorewall start after the + test. + + + + 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. 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 @@ -354,6 +291,62 @@ Ping/DROP net all
+
+ Some Things to Keep in Mind + + + + You cannot test your firewall from the + inside. 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 net 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. + + + + IP addresses are properties of systems, + not of interfaces. 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. + + + + All IP addresses configured on firewall + interfaces are in the $FW (fw) zone. If 192.168.1.254 is + the IP address of your internal interface then you can write + $FW:192.168.1.254 in a + rule but you may not write loc:192.168.1.254. Similarly, it is + nonsensical to add 192.168.1.254 to the loc zone using an entry in + /etc/shorewall/hosts. + + + + Reply packets do NOT automatically follow + the reverse path of the one taken by the original request. + 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. + + + + Shorewall itself has no notion of inside + or outside. These concepts are embodied in how Shorewall is + configured. + + +
+
Other Gotchas @@ -379,6 +372,11 @@ Ping/DROP net all interface in /etc/shorewall/interfaces. + + + You have connected two firewall interfaces (from different + zones) to the same hub or switch. + @@ -396,14 +394,8 @@ Ping/DROP net all directions. So when setting up routing between A and B, be sure to verify that the route from B - back to A is defined. - - - - Some versions of LRP (EigerStein2Beta for example) have a shell - with broken variable expansion. You can get a corrected shell from the - Shorewall - Errata download site. + back to A is defined and + correct. @@ -437,84 +429,4 @@ Ping/DROP net all See the Shorewall Support Page.
- - - Revision History - - - - 2.0 - - 2005-09-11 - - CR - - Updated for Shorewall 3.0 - - - - 1.9 - - 2004-08-25 - - TE - - Advice for the networking-challenged. - - - - 1.8 - - 2004-04-03 - - TE - - Point out that firewall addresses are in the $FW - zone. - - - - 1.7 - - 2004-02-02 - - TE - - Add hint about testing from inside the - firewall. - - - - 1.6 - - 2004-01-06 - - TE - - Add pointer to Site and Mailing List Archives - Searches. - - - - 1.5 - - 2004-01-01 - - TE - - Added information about eliminating ping-generated log - messages. - - - - 1.4 - - 2003-12-22 - - TE - - Initial Docbook Conversion - - - \ No newline at end of file