Description of problem: /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal changes from 1 to 0 on `service iptables restart`; ignoring settings in /etc/sysctl.conf (other settings seem to be honoured). Version-Release number of selected component (if applicable): iptables-1.3.5-4.el5 How reproducible: Extremely Steps to Reproduce: 1) ensure set to 1 [root@europa ~]# sysctl -a | grep ip_conntrack_tcp_be_liberal net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 2) restart iptables [root@europa ~]# service iptables restart Flushing firewall rules: [ OK ] Setting chains to policy ACCEPT: nat filter [ OK ] Unloading iptables modules: [ OK ] Applying iptables firewall rules: [ OK ] Loading additional iptables modules: ip_conntrack_netbios_n[ OK ] 3) check new value [root@europa ~]# sysctl -a | grep ip_conntrack_tcp_be_liberal net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0 4) work around [root@europa ~]# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1 net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 Actual results: [root@europa ~]# sysctl -a | grep ip_conntrack_tcp_be_liberal net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0 Expected results: Really this should honour what /etc/sysctl.conf contains: root@europa monit.d]# grep liberal /etc/sysctl.conf net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 and thus should produce (at least for me): [root@europa ~]# sysctl -a | grep ip_conntrack_tcp_be_liberal net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 Additional info: From what Red Hat support has told me at other times there appears to be an issue in netfilter with regards to connection tracking which is marking packets as INVALID when the network is under load. the be liberal setting is a work around already... That said, it probably shouldn't go against what /etc/sysctl.conf contains: root@europa monit.d]# grep liberal /etc/sysctl.conf net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 also, /etc/sysconfig/iptables-config contains the IPTABLES_MODULES_UNLOAD="yes" setting, which set to no prevents this from occuring, but given the comments in the file, and the lack of other adverse effects simply working around it for now seems to do the trick.
I confirm this bug, exactly as described. It's quite annoying. Version details follow, this should a fairly up-to-date system: $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga) $ uname -a Linux tss-sysmon-v.sas.its.nyu.edu 2.6.18-128.4.1.el5 #1 SMP Thu Jul 23\ 19:59:17 EDT 2009 i686 i686 i386 GNU/Linux $ rpm -q iptables iptables-1.3.5-5.3.el5_4.1 To more succinctly summarize the workaround described above, adding the following to rc.local will set the correct setting after a reboot: sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1 However, it will still be overwritten when iptables is manually restarted unless you also edit /etc/sysconfig/iptables-config to contain: IPTABLES_MODULES_UNLOAD="no" If you apply both workarounds listed above, your settings should persist, though.
Hello again It appears that the liberal setting is becoming more important again. I'm not sure why that is so, but i'm getting a lot of reports of issues with hosts that have a lot of traffic going through them. I have come up with a work around: modify /etc/modprobe.conf as follows: install ip_conntrack /sbin/modprobe -q --ignore-install ip_conntrack ; /sbin/sysctl -p /etc/sysctl.conf However I'm seeing instances where the setting still gets unset; i have yet to determine how. Cheers Christian
I've logged a support call with red hat and the advise i got back was to use the modification of /etc/modprobe.conf . Since the end of february the problem has not recurred, i'm guessing there was some disconnect between observed configuration and observed behavior. Thus i think this is an non-issue... Cheers Christian
There currently is no mechanism to specify that some sysctl values should be reloaded when iptables is reloaded. This can have severe impact on systems that have reason to use non-default values for net.ipv4.netfilter.ip_conntrack_* sysctls I have proposed a patch for bugID 552522 which provides this functionality, and by doing so (I believe) also addresses the concerns raised in this bug.
*** This bug has been marked as a duplicate of bug 552522 ***