debug is ignored by the Shorewall compiler.

debug causes altered behavior of generated scripts. These scripts normally use iptables-restore to install the Netfilter ruleset but with debug, the commands normally passed to iptables-restore in its input file are passed individually to iptables. This is a diagnostic aid which allows identifying the individual command that is causing iptables-restore to fail; it should be used when iptables-restore fails when executing a COMMIT command.

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

Port Forwarding where client and server are in the same subnet. See FAQ 2.

Trying to test net->loc DNAT rules from inside your firewall. You must test these rules from outside your firewall.

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. You can test using this kind of configuration if you specify the arp_filter option or the arp_ignore 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.

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

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:

#ACTION  SOURCE          DEST                  PROTO   DEST
#                                                      PORT(S)
Ping(ACCEPT)<source zone> <destination zone>

The ramifications of this can be subtle. For example, if you have the following in /etc/shorewall/nat:

#EXTERNAL   INTERFACE  INTERNAL
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.

Ping requests are subject to logging under your policies. So ping floods can cause an equally big flood of log messages. To eliminate these, as the last rule in your /etc/shorewall/rules file add:

#ACTION  SOURCE          DEST                  PROTO   DEST
#                                                      PORT(S)
Ping(DROP)net             all

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.

Seeing rejected/dropped packets logged out of the INPUT or FORWARD chains? This means that:

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 and correct.

Do you have your kernel properly configured? Click here to see kernel configuration information.