I've had a bad run with security issues. Reading the Linux NAT code I discover that it's not really meant to be a firewall. For example, unparsable packets are usually handled with NF_ACCEPT, which leaves a lot of room for nastiness. This choice makes sense from a NAT point of view -- many packets don't need NATing and so if you can't parse the packet, then just change the network-layer headers, punt it through and see how it goes. But from a firewalling NAT point of view, it's not so hot.
There's also a severe problem with port allocation. Linux NAT tries to use the same ports on the Outside of the NAT as on the Inside of the NAT. Handy for fault tracing. But consider a malicious Inside user who uses port 80. Assuming there is no one currently holding port 80, then the NAT will use port 80.
So we have a race condition on system start. Who will get port 80 first: our malicious Insider with the phishing web site, or our server. Well the networking starts before Apache, so the odds are stacked in favour of our insider.
Cisco need not look smug at this point. A little testing shows a problem in that camp too.
Thinking about it more, systems are plagued with race conditions on start. The sensible thing to do would be to configure a "client mode" firewall, bring up the system, then re-configure the firewall into a "server mode" stance. This carries the implication that host firewalls do have substantial benefits, something not appreciated by "corporate firewall appliance" vendors.
I don't understand much beyond networking, but I also wonder what joys are being unleashed by the current trend of operating systems allowing users to log in before the system initialisation completes. That race condition used to be avoided by setting /etc/nologin at system start and removing it once the system was running sucessfully.
I also don't understand the conntrack code. Each conntrack module seems to allocate a 64KB packet parsing buffer. That's going to lead to more packet copying than is healthy. But also, consider the "network applicance" case. Those vendors are going to install every conntrack module they can -- so that user's applications just work through their ADSL gateways. But most users won't use all of the protocols, so some of those allocations will never be touched. Even if the parsing buffer is retained, then lazy allocation of the buffer is called for.