Centos6 iptables startup vs. restart?

Home » CentOS » Centos6 iptables startup vs. restart?
CentOS 4 Comments

What is different about the initial startup of iptables than ‘service iptables restart’ (and different from C5)? I want to use iptables port redirection to send port 80 to 8080 so a java web service doesn’t have to start as root. On C5 it worked to give the iptables  commmands, then ‘iptables save’, and from then on it would automatically work when iptables started after a reboot. With C6, I have the expected entries in /etc/sysconfig/iptables and they are loaded after ‘service iptables restart’, but the initial startup is doing something else.


4 thoughts on - Centos6 iptables startup vs. restart?

  • There is a bug that has been around for years in iptables. I’m not sure
    if it’s a timing problem or what, but I’ve seen it in fedora, centos,
    and ubuntu where certain rules appear not to work when configured
    inititally. I’ve even dumped out the running iptables list after it was
    restarted and diffed it with the saved one and the rules are all there.
    It may be specific to NAT or possibly related to an interaction between
    NAT and connection tracking. Somewhere I remember seeing this problem
    documentated as a known bug in iptables. There are a few bugs listed
    in: http://bugzilla.netfilter.org/buglist.cgi?quicksearch=nat , though
    I’m not sure if any of them quite describes this problem.


  • Did you make sure that the service is active and that the iptables service
    is actually startet on bootup?

    Try “chkconfig –list iptables” to see if it is active and “chkconfig
    iptables on” to activate it.

  • On Tue, Apr 3, 2012 at 5:54 AM, Dennis Jacobfeuerborn

    Yes, it does start, but the initial rules don’t include the port
    redirection in the nat table.

  • I still think it’s a timing problem. Have you checked to see that the
    proper NAT module is loaded in the kernel at the time when the iptables
    rules are loaded? At least for diagnostic purposes I would try adding a
    delay in the startup. You might even find that adding an lsmod into the
    startup sequence (for diagnostic purposes) there would fix the problem.
    I have not had a chance to look at the scripts that do this in CentOS 6.