ip_conntrack loopback blues

Today I was doing some testing with siege on a remote box. I was connected via ssh, and siege was running against the webserver over the loopback interface.

I started having problems with siege reporting too many file descriptors open. I checked, and lsof said I was well within acceptable limits.

I did some poking around, and discovered that iptables was overflowing the connection tracking table, and was dropping packets.

kernel: ip_conntrack: table full, dropping packet.

Unsure what was exactly happening, I looked at /proc/sys/net/ipv4/netfilter/ip_conntrack_count and /proc/sys/net/ipv4/netfilter/ip_conntrack_max to get the current and max state table size, respectively. Sure enough, I was bonking into the limit. But..why? This box wasn't doing that much..

After some further research, it turns out iptables does connection tracking even over the loopback inteface. Eureka! I could see this happening by doing:

grep "127.0.0.1" /proc/net/ip_conntrack

Sure enough, I ran my siege test, and the conntrack_count rocketed up. Explosions and fire. :(

After a bit of digging, I discovered how to get iptables to ignore tracking state on specified traffic, even when ip_conntrack is being used.

iptables -t raw -A PREROUTING -i lo -j NOTRACK
iptables -t raw -A OUTPUT -o lo -j NOTRACK

The NOTRACK target is only possible in the raw table. There are only two chains in that table, PREROUTING (for packets arriving via a network interface) and OUTPUT (for packets generated for output).

The above addition to my iptables ruleset, fixed my problem. I no longer track state for traffic over the loopback interface, and my state table is no longer overflowing.