Bug 806356 - iptables rules fail to keep state
Summary: iptables rules fail to keep state
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-23 14:25 UTC by William H. Haller
Modified: 2012-04-03 18:04 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-04-03 18:04:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description William H. Haller 2012-03-23 14:25:35 UTC
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
2. Reboot
3.
  
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).

Comment 1 William H. Haller 2012-03-28 14:09:30 UTC
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.

Comment 2 William H. Haller 2012-04-02 15:09:54 UTC
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.

Comment 3 Josh Boyer 2012-04-03 18:04:45 UTC
We'll close this out for now.  If you see it again, please reopen with relevant details.


Note You need to log in before you can comment on or make changes to this bug.