Hide Forgot
Description of problem: There is a value net.ipv4.netfilter.ip_conntrack_max. But when the system boot up, sysctl is issued from rc.sysinit. At the momemnt, system still has not been configured network. So even though net.ipv4.netfilter.ip_conntrack_max is set into /etc/sysctl.conf, system can not set it. So, iptables always use the default value to the ip_conntrack_max. Version-Release number of selected component (if applicable): iptables-1.2.11-3.1.RHEL4 How reproducible: Always Steps to Reproduce: 1. Configure ip_conntrak. 2. Set net.ipv4.netfilter.ip_conntrack_max = 65528 into /etc/sysctl.conf 3. Reboot the system. Actual results: ip_conntrack_max is ALWAYS set as default value. Expected results: iptable startup script should set custom value in /etc/sysctl.conf when ip_conntrak driver loaded. Additional info: Modify idea (ex.) Issue " sysctl -e -p /etc/sysctl.conf " from /etc/init.d/iptables script, after load ip_conntrack driver.
Assigning this to procps. I'd need an option in sysctl, where I can restrict to a subtree of /sys. Here: /net/ipv4/netfilter for IPv4 and /net/ipv6/netfilter for IPv6. Please ressign to iptables if this is fixed in procps.
Well, the solution is extract from sysctl.conf relevant options and use it for sysctl, for example: gawk '/netfilter/ { gsub(" ", ""); print $0; }' /etc/sysctl.conf | xargs sysctl -w
I'd like to expand on this problem as well. When doing a service restart iptables all of the conntrack values are reset to the defaults even if other values are specified in /etc/sysctl.conf. I noticed this because I needed to reduce some timeouts due to spammers filling up my connection table (5 day timeouts seem excessive), but when I restarted iptables, the default values were restored. So it would be nice as part of the start (or restart) process that applicable values from /etc/sysctl.conf get applied after the various conntrack modules have been loaded. Note I am seeing this using iptables-1.4.0-4.fc9.i386.
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.