We recently had a problem to troubleshoot on the wireless network, which was quickly resolved through simply having effective logging from iptables.
In case you didn’t know, iptables has a LOG target which can direct messages to the local syslog service regarding the matched packet. It’s a non-terminating target so you can log and still continue to process the packet in other ways. The LOG target is commonly used just before the DROP target, but in our case we do something slightly different to many of the cookie-cutter iptables scripts out there on the Internet.
First we set the log level using the –log-level option. This allows us to collect the iptables logs using syslog-ng and direct them to a special file, separate from the other Kernel logs. The iptables logs can have quite a large volume, so it’s useful to be able to look at other Kernel logs without the noise, or equally to grep the iptables logs in isolation.
Next we employ the –log-prefix option each time we call upon the LOG target. So there are two points here: first, try to log and drop often throughout your rules, which will reduce the processing overheads for iptables. Second, multiple calls to LOG allows multiple –log-prefix parameters. We use this parameter to describe why we dropped or rejected the packet, using simple tags such as “[BAD-STATE]” which work well with grep.
In this particular case, the dropped packets had protocol 47 – GRE, and we had neglected to load the iptables conntrack helper module for GRE on this firewall. It was simple to find the cause by having good firewall logs in place. Do you have any other tips for firewall logging from iptables?