Netfilter / Iptables Mini-FAQ

This isn't anywhere near a real FAQ; give it time.

Q: When I do a 'iptables -L', why does it take so long to display the info?
A: If you don't use the '-n' switch, Iptables will reverse resolve the IP addresses (can take quite some time). '--numeric' or '-n' will display numeric output of addresses and ports (e.g. 'iptables -L --line -nv').

Q: I'm using the ip_nat_ftp and ip_conntrack_ftp modules, but since my FTP server isn't running on standard ports, how do I fix this?
A: Load the modules with the option 'ports=#'. For example, for an FTP server listening on port 2121, use 'modprobe ip_nat_ftp ports=2121'. If you have to specify more than one port, use a comma to separate the values (no space).

Q: How do I enter these options if I compiled the modules into the kernel statically?
A: Don't compile it into your kernel statically.

Q: Does Netfilter/Iptables support NetMeeting (H.323)?
A: No. Not until someone write a connection tracking module to support it. In the mean time, check out http://openh323proxy.sourceforge.net/ to proxy H.323 connections through Netfilter.

Q: I'm trying to apply the FTP security patch from http://netfilter.samba.org/security-fix/ftp-security2.patch; why won't it apply cleanly?
A: This is only for kernels v2.4.3 and before. The problem has been fixed in subsequent kernels. It's recommended that you run a more recent kernel.

Q: What is the patch-o-matic and how do I use it?
A: Rusty's patch-o-matic helps you to patch your kernel with enhanced or experimental features. See http://www.knowplace.org/netfilter/ipt_compile.html for more details.

Q: Netfilter keeps displaying logging information on the console, how do I get this to stop?
A: There are a couple of reasons why this might be happening. First, check your /etc/syslog.conf to make sure it doesn't contain a line like 'kern.* /dev/console'. If that doesn't work, try starting your klogd with the switch '-c 3'.

Q: I keep seeing ACK FIN log entries such as:
kernel: IN=eth0 OUT= MAC=#:#:#:#:#:#:#:#:#:#:#:#:08:00 SRC=#.#.#.# DST=#.#.#.# LEN=40 TOS=0x00 PREC=0x00 TTL=43 ID=37639 DF PROTO=TCP SPT=# DPT=# WINDOW=4288 RES=0x00 ACK FIN URGP=0
Is something wrong?
A: Well, yes and no. This is a known 'bug' in which Netfilter appears to be dropping the conntrack entry for a specific connection too early. However, it isn't exactly clear if it's Netfilter that has this wrong, or the server/client is doing this wrong. If you want to help, please send packet dumps (tcpdump) along with the error log to the netfilter mailing list (DO NOT just send the error logs). Either way, this is harmless beyond filling up your logs.

Q: I'm using the UNCLEAN match; why does it seem to drop valid packets? Why did it seem to suddenly break when I upgraded to > 2.4.6 kernels?
A: It's not called experimental for no reason. See http://lists.samba.org/pipermail/netfilter/2001-August/014748.html. The UNCLEAN match was always broken, but because it was never actually called, it didn't seem to break anything.

Q: How do I list the NAT/masqueraded connections ('ipchains -L -M')?
A: Use 'cat /proc/net/ip_conntrack'.

Q: When I display connection tracking info by 'cat /proc/net/ip_conntrack', why does it hangs for a while before displaying it all.
A: The /proc filesystem was probably accessed at the same time as a read-write lock attempt elsewhere in ip_conntrack. It's a probably transient problem and not likely to happen often.