diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm
deleted file mode 100644
index b7afdf2b4..000000000
--- a/Shorewall-docs/troubleshoot.htm
+++ /dev/null
@@ -1,199 +0,0 @@
-
-
-
-
- Shorewall Troubleshooting
-
-
-
-
-Shorewall
-Troubleshooting 
-"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
-
-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.
-Check the FAQs
-Check the FAQs for solutions to
-common problems.
-If the firewall fails to start
-If you receive an error message when starting or restarting the
-firewall and you can't determine the cause, then do the following:
-
- - Make a note of the error message that you see.
-
- - shorewall debug start 2> /tmp/trace
- - 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.
- - If you still can't determine what's wrong then see the support page.
-
-Here's an example. During startup, a user sees the following:
-
- Adding Common Rules
iptables: No chain/target/match by that name
Terminated
-
-A search through the trace for "No chain/target/match by that name"
-turned up the following:
-
- + 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
-
-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 kernel.htm)
-Your network environment
-Many times when people have problems with Shorewall, the problem is
-actually an ill-conceived network setup. Here are several popular
-snafus:
-
- - Port Forwarding where client and server are in the same subnet.
-See FAQ 2.
- - 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.
- - 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 arp_filter
-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.
-
-If you are having 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.
-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.
-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 FAQ 17.
-While you are troubleshooting, it is a good idea to
-clear two variables in /etc/shorewall/shorewall.conf:
-LOGRATE=""
-LOGBURST=""
-This way, you will see all of the log messages being
-generated (be sure to restart shorewall after clearing these variables).
-Example:
-
-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
-
-Let's look at the important parts of this message:
-
- - all2all:REJECT - This packet was REJECTed out of the
-all2all chain -- the packet was rejected under the "all"->"all"
-REJECT policy (see FAQ 17).
- - IN=eth2 - the packet entered the firewall via eth2
- - OUT=eth1 - if accepted, the packet would be sent on eth1
- - SRC=192.168.2.2 - the packet was sent by 192.168.2.2
- - DST=192.168.1.3 - the packet is destined for 192.168.1.3
- - PROTO=UDP - UDP Protocol
- - DPT=53 - DNS
-
-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:
-ACCEPT dmz
-loc udp 53
-
-See FAQ 17 for additional
-information about how to interpret the chain name appearing in a
-Shorewall log message.
-
-'Ping' Problems?
-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 described here.
-Other Gotchas
-
- - Seeing rejected/dropped packets logged out of the INPUT or
-FORWARD chains? This means that:
-
- - 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
- /etc/shorewall/hosts file
-are you?); or
- - the source and destination hosts are both connected to the
-same interface and you haven't specified the 'routeback' option on that
-interface.
-
-
- - 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:
-
- ACCEPT <source
-zone> <destination zone>
-icmp echo-request
-
-The ramifications of this can be subtle. For example, if you have the
-following in /etc/shorewall/nat:
-
- 10.1.1.2 eth0
-130.252.100.18
-
-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.
- - If you specify "routefilter" for an interface, that interface
-must be up prior to starting the firewall.
- - 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 in both 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.
- - Do you have your kernel properly configured? Click
-here to see my kernel configuration.
- - 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
-ftp://ftp.inr.ac.ru/ip-routing .
- - Problems with NAT? Be sure that you let
-Shorewall add all external addresses to be use with NAT unless you
-have set ADD_IP_ALIASES =No
-in /etc/shorewall/shorewall.conf.
-
-Still Having Problems?
-See the support page.
-
-
-
-
-Last updated 11/1/2003 - Tom Eastep
-Copyright
-© 2001, 2002 Thomas M. Eastep.
-
-
-
-
diff --git a/Shorewall-docs/troubleshoot.xml b/Shorewall-docs/troubleshoot.xml
new file mode 100644
index 000000000..d90562fb5
--- /dev/null
+++ b/Shorewall-docs/troubleshoot.xml
@@ -0,0 +1,335 @@
+
+
+
+
+
+ Shorewall Troubleshooting Guide
+
+
+ Thomas
+
+ M.
+
+ Eastep
+
+
+ 2003/12/22
+
+
+ 2003
+
+ Thomas M. Eastep
+
+
+
+ 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
+ GNU Free Documentation License
.
+
+
+
+ ![]()
+
+ "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
+
+
+ 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
+ 30 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.
+
+
+
+
+ "shorewall start" and "shorewall restart" Errors
+
+ If you receive an error message when starting or restarting the
+ firewall and you can't determine the cause, then do the following:
+
+
+
+
+ Make a note of the error message that you see.
+
+
+
+ shorewall debug start 2> /tmp/trace
+
+
+
+ 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.
+
+
+
+ If you still can't determine what's wrong then see the
+ support page.
+
+
+
+
+ Startup Error
+
+ During startup, a user sees the following:
+
+ Adding Common Rules
+ iptables: No chain/target/match by that name
+ Terminated
+
+ A search through the trace for "No chain/target/match by that
+ name" turned up the following:
+
+ + 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
+
+
+ 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
+ kernel.htm)
+
+
+
+
+ Your Network Environment
+
+ Many times when people have problems with Shorewall, the problem is
+ actually an ill-conceived network setup. Here are several popular snafus:
+
+
+
+
+ Port Forwarding where client and server are in the same subnet.
+ See FAQ 2.
+
+
+
+ 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.
+
+
+
+ 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 arp_filter 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.
+
+
+
+
+
+ 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.
+
+ 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.
+
+ 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 FAQ
+ 17.
+
+ While you are troubleshooting, it is a good idea to clear two
+ variables in /etc/shorewall/shorewall.conf:
+
+ LOGRATE=""
+ LOGBURST=""This way, you will see all of the log
+ messages being generated (be sure to restart shorewall after clearing
+ these variables).
+
+
+ Log Message
+
+ 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
+
+ Let's look at the important parts of this message:
+
+
+
+ all2all:REJECT - This packet was REJECTed out of the all2all
+ chain -- the packet was rejected under the
+ "all"->"all" REJECT policy (see FAQ 17).
+
+
+
+ IN=eth2 - the packet entered the firewall via eth2
+
+
+
+ OUT=eth1 - if accepted, the packet would be sent on eth1
+
+
+
+ SRC=192.168.2.2 - the packet was sent by 192.168.2.2
+
+
+
+ DST=192.168.1.3 - the packet is destined for 192.168.1.3
+
+
+
+ PROTO=UDP - UDP Protocol
+
+
+
+ DPT=53 - DNS
+
+
+
+ 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:
+
+ ACCEPT dmz loc udp 53
+
+
+
+
+ Ping Problems
+
+ 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 described
+ here.
+
+
+
+ Other Gotchas
+
+
+
+ Seeing rejected/dropped packets logged out of the INPUT or
+ FORWARD chains? This means that:
+
+
+
+ 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 /etc/shorewall/hosts
+ file are you?); or
+
+
+
+ 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 routeback option for the
+ interface in /etc/shorewall/interfaces.
+
+
+
+
+
+ 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:
+
+ ACCEPT <source zone> <destination zone> icmp echo-request
+
+ The ramifications of this can be subtle. For example, if you
+ have the following in /etc/shorewall/nat:
+
+ 10.1.1.2 eth0 130.252.100.18
+
+ 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.
+
+
+
+ If you specify "routefilter" for an interface, that
+ interface must be up prior to starting the firewall.
+
+
+
+ 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 in both
+ 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.
+
+
+
+ Do you have your kernel properly configured? Click here to see my kernel configuration.
+
+
+
+
+ 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 ftp://ftp.inr.ac.ru/ip-routing
+ .
+
+
+
+ Problems with NAT? Be sure that you let Shorewall add all
+ external addresses to be use with NAT unless you have set ADD_IP_ALIASES =No
+ in /etc/shorewall/shorewall.conf.
+
+
+
+
+
+ Still Having Problems?
+
+ See the Shorewall Support Page.
+
+
\ No newline at end of file