Red Hat Bugzilla – Bug 806356
iptables rules fail to keep state
Last modified: 2012-04-03 14:04:45 EDT
Description of problem: In a gateway configuration, iptables rules that properly kept state with the previous 3.2.10 kernel (and all previous kernels for that matter), no longer work. The outgoing connection occurs, but the return ACK SYN is blocked by the firewall.
Version-Release number of selected component (if applicable): 3.3.0-4
How reproducible: Always
Steps to Reproduce:
1. Update to new kernel via yum
Actual results: Packets which used to pass as established outbound connections via automatic state keeping find the replies blocked. It isn't 100%, but it is a high enough percentage (95% or better) that it is not a functional gateway. Once in a great while you can get a web page to load but it is very rare. Same way with DNS lookups from clients on the internal LAN. Everything is fine from the gateway itself.
Expected results: Continued proper operation of existing configurations - even though you are moving to bright shiny new dynamic firewall configurations.
Additional info: I don't know what else to say. This is a fwbuilder (latest version) generated firewall that has worked fine for a long time. If you are just using 3.3.0 in a simple configuration, it seems to work fine. Passing traffic between NICs though somehow is now broken when it comes to state keeping.
The NICs in question are Intel Corporation 82574L gigabit cards running the e1000e driver. The internal net runs MTU of 9216 and the external 1500. Both have txqueuelens of 10000. IPv6 is disabled by default. If there is any other info you need, I can pass it along, but again - this is basic functionality that worked in 3.2.10 (and still works when booted to that kernel).
I don't see this on two other boxes that have other hardware combinations (wireless or a different nic combo). They all have the same sysctl.conf settings so perhaps something with NICs. Of course the other gateways are all inbound connections so MTU switch going the other way.
This seems to have resolved itself before the 3.3.0-8 was distributed on a reboot. My best guess is some race condition in executing rc.local via the systemd mess caused some lockup. I had added a service network restart in that script to try to work around some reboot issues with systemd, and maybe it tried to run that while the original network was trying to come up. With systemd - who knows. Anyway, this doesn't seem to be directly kernel related - maybe systemd - or maybe some other package update before 3.3.0-8.
We'll close this out for now. If you see it again, please reopen with relevant details.