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 for solutions to common problems.
![]() | shorewall debug start 2> /tmp/trace |
![]() | Look at the /tmp/trace file and see if that helps you determine what the problem is. |
![]() | If you still can't determine what's wrong then post the /tmp/trace file to teastep@shorewall.net along with any additional information you believe is relevant. |
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.
Check your log. If you don't see Shorewall packet messages, then your problem is probably NOT a Shorewall problem. If you DO see packet messages, it is an indication that you are missing one or more rules.
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 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 - the packet was rejected under the "all"->"all" REJECT policy |
![]() | 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
![]() | 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. This is true even if you have NOT specified 'noping' for eth0 in /etc/shorewall/interfaces. | ||||
![]() | Many times
when people have problems with Shorewall, the problem is actually an
ill-conceived test setup. Here are a couple of popular snafus:
| ||||
![]() | If you specify "routefilter" for an interface, that interface must be up prior to starting the firewall. | ||||
![]() | 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. | ||||
![]() | Some features require 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 . | ||||
![]() | If you have any entry for a zone in /etc/shorewall/hosts then the zone must be entirely defined in /etc/shorewall/hosts. For example, if a zone has two interfaces but only one interface has an entry in /etc/shorewall/hosts then hosts attached to the other interface will not be considered part of the zone. | ||||
![]() | 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 support page.
Last updated 2/12/2002 - Tom Eastep