Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 493226

Summary: net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 1 gets set to 0 (despite persistent setting in /etc/syctl.conf and runtime configuration) on iptables restart
Product: Red Hat Enterprise Linux 5 Reporter: Christian Unger <chakkerz>
Component: iptablesAssignee: iptables-maint-list <iptables-maint-list>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: low    
Version: 5.3CC: cg2v, martin_foster, mikelococo, twoerner
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-14 16:14:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Christian Unger 2009-04-01 00:29:39 UTC 
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.
Comment 1 Mike Lococo 2009-12-14 23:48:38 UTC 
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.
Comment 2 Christian Unger 2010-02-28 23:18:35 UTC 
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
Comment 3 Christian Unger 2010-04-14 01:11:28 UTC 
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
Comment 4 Martin Foster 2010-08-20 13:12:13 UTC 
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.
Comment 5 Thomas Woerner 2011-11-14 16:14:59 UTC 

*** This bug has been marked as a duplicate of bug 552522 ***