Tracking down a problem in the firewall is detailed and painstaking. There are no shortcuts to debugging the rules when something goes wrong. In general, the following tips can make the process a bit easier:
Always execute the rules from a complete test script, like the one I've shown how to build throughout this book. Be sure that the script flushes all existing rules, removes any existing user-defined chains, and resets the default policies first. Otherwise, you can't be sure which rules are in effect or in which order.
Don't execute new rules from the command line. Especially don't execute the default policy rules from the command line. You'll be cut off immediately if you're logged in using X Windows or remotely from another system, including a system on the LAN.
Execute the test script from the console if you can. Working in X Windows at the console might be more convenient, but the danger remains of losing access to X Windows locally. Be prepared for the possibility of needing to switch over to a virtual console to regain control. If you must use a remote machine to test the firewall script, use cron to automatically stop the firewall in case you get locked out. Be sure to remove the cron job before going live with the firewall, though.
Remember that flushing the rule chains does not affect the default policy currently in effect.
With a deny-by-default policy, always enable the loopback interface immediately.
When feasible, work on one service at a time. Add rules one at a time, or as input and output rule pairs if you aren't using the state module. Test as you go. This makes it much easier to isolate problem areas in the rules right away. Liberal use of the echo command within the firewall script can help to narrow down the location or rules that are being problematic within the script.
The first matching rule wins. Order is important. Use the iptables list commands as you go to get a feel for how the rules are ordered. Trace an imaginary packet through the list.
Remember that there are at least two independent chains: INPUT and OUTPUT. If the input rules look right, the problem might be in the OUTPUT chain, or vice versa.
If the script appears to hang, chances are good that a rule is referencing a symbolic hostname rather than an IP address before the DNS rules have been enabled. Any rule using a hostname instead of an address must come after the DNS rules, unless the host has an entry in the /etc/hosts file.
Double-check the iptables syntax. It's easy to mistype the rule's direction, to reverse the source and destination addresses or ports, to switch upper- and lowercase-sensitive options, to use -i rather than -o when referring to an outgoing interface, or to precede an option with the wrong number of hyphens.
The three tables, filter, nat, and mangle, have different built-in chains. filter has INPUT, OUTPUT, and FORWARD. nat has POSTROUTING for SNAT, and PREROUTING and OUTPUT for DNAT. mangle has PREROUTING, INPUT, FORWARD, POSTROUTING, and OUTPUT.
The various built-in chains have differing input and output interface specifications. That is, an INPUT rule takes only an incoming interface. An OUTPUT rule takes only an outgoing interface. A FORWARD rule can take either, both, or no interface specifications. Source SNAT and MASQUERADE take only an outgoing interface. Destination DNAT and REDIRECT take only an incoming interface on the PREROUTING chains and only an outgoing interface on the OUTPUT chain.
The filter table is implied by default. The -t option and table name must be specified to access the nat or mangle tables, as in iptables -t nat.
Most match modules require you to reference the module by name with the -m option before specifying the module's feature syntax, as in -m state --state NEW.
The filter table's INPUT and OUTPUT chains refer only to the packets addressed to the local machine or originating from the local machine. Forwarded packets do not traverse the filter table's INPUT or OUTPUT chains.
iptables error messages can be cryptic. If you're having difficulty identifying the problem rule, execute the script with the -x or -v shell option to list the rules as the script is executedfor example, sh -v ./rc.firewall. The -v option prints the line in the script as it is read by the shell command interpreter. The -x option prints the line in the script as it is executed by the shell. script is often useful to capture the output in a typescript file.
When a service doesn't work, log all dropped packets going in both directions, as well as all relevant accepted packets. Do the log entries in /var/log/messages or /var/log/kern.log show anything being dropped when you try the service? If they do, you can adjust your firewall rules to allow the packets. If not, the problem must be elsewhere.
When packets aren't crossing an interface, remember that the FORWARD chain refers to packets traversing the router. The INPUT and OUTPUT chains refer to local packets. NAT rules are separate from FORWARD rules. A NATed packet requires both FORWARD and NAT rules.
Source NAT is applied during POSTROUTING, after the packet has left the FORWARD or OUTPUT chain. This means that rules on the FORWARD and OUTPUT chains must refer to the packet's original source address rather than the NATed address.
Destination NAT is applied during PREROUTING, before the packet arrives on the FORWARD or INPUT chain. This means that rules on the PREROUTING chain must refer to the original destination address, whereas rules on the FORWARD and INPUT chains must refer to the altered destination address.
If you have Internet access from the firewall machine but not from the LAN, double-check that IP forwarding is enabled by running cat /proc/sys/net/ ipv4/ip_forward. The value 1 should be reported. IP forwarding can be permanently configured by hand in /etc/sysctl.conf or in the firewall script itself. The first configuration method takes effect when the network is restarted. If IP forwarding wasn't enabled, you can enable it immediately by typing the following line as root or by including it in the firewall script and reexecuting the script:
echo "1" > /proc/sys/net/ipv4/ip_forward
If a service works on the LAN but not externally, turn on logging for accepted packets on the internal interface. Use the service very briefly to see which ports, addresses, flags, and so forth are in use in both directions. You won't want to log accepted packets for any length of time, or you'll have hundreds or thousands of log entries in /var/log/messages.
If a service doesn't work at all, temporarily insert input and output rules at the beginning of the firewall script to accept everything in both directions and log all traffic. Is the service available now? If so, check the log entries in /var/log/messages to see which ports are in use.