Tom 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

Some problems are easily solved by checking one of the resources described in the following sections.

Check the FAQs for solutions to over 30 common problems.

Check the Shorewall Errata to be sure that there isn't an update that you are missing for your version of the firewall.

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. 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)

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 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). 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

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.

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.

See the Shorewall Support Page.