I am trying to use a puppet master 3.1.1 to manage iptables on various servers. My local puppet agent is 2.7.19, the server OS is CentOS 5.4.


class base::iptables (
    $identity_environment = $::identity_environment

  if ($identity_environment == "production")
    $start_iptables = "true"
    $run_iptables = "running"

  elsif ($identity_environment == "development")
    $start_iptables = "false"
    $run_iptables = "stopped"

  if ($run_iptables != "stopped")
    file { "/etc/sysconfig/iptables":
      ensure => file,
      owner  => root,
      group  => root,
      mode   => 644,
      source => "puppet://path_to_my_conf",
      require => File["/etc/resolv.conf"],

    service { "iptables":
      subscribe => File["/etc/sysconfig/iptables"],
      enable => "$start_iptables",
      ensure => "$run_iptables",
      status => "[[ `iptables -L -n | egrep -v '(Chain|target)' | grep '^[A-Za-z]' | wc -l` != 0 ]]",

    service { "iptables":
      enable =>"$start_iptables",
      ensure =>"$run_iptables",

When I run puppet on a development server:

puppet agent --verbose --no-daemonize --onetime --debug | grep iptable

the following occurs:

debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig iptables' debug: Serviceiptables: Executing '/sbin/service iptables stop' debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig iptables' notice: /Stage[main]/Base::Iptables/Service[iptables]/ensure: ensure changed 'running' to 'stopped' debug: /Stage[main]/Base::Iptables/Service[iptables]: The container Class[Base::Iptables] will propagate my refresh event debug: Serviceip6tables: Executing '/sbin/service ip6tables status' debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig ip6tables' debug: Class[Base::Iptables]: The container Stage[main] will propagate my refresh event

Checking manually with service iptables status shows that the service is indeed running, is puppet stopping the service then somehow starting it due to that 'refresh'?

I attempted to alter my manifest according to this similar question but to no avail,

service { "iptables":
    ensure => "stopped",
    hasstatus => "true",
    status => "true"

results in the same thing - puppet checking, then stopping iptables, but yet the service is turned back on.

I do not know if this could be related to this documented race condition bug that has been fixed in a newer puppet version, I do not have the option of updating or implementing a proper method such as puppetlab's firewall module at this time.

UPDATE [20140724]

After some great feedback here I did some debugging/logging from the /etc/init.d/iptables script. Come to find out When puppet was running, no calls to start the service were being made, however the OS still reported iptables as running even if puppet stopped it.

My inclination was to look at the iptables module itself. Sure enough if I removed the iptables module and then ran puppet again, the module would be re-loaded.

UPDATE [20140729]

My solution is listed below as an answer. I will open a new question for continuing to troubleshoot CentOS 6 with this.

  • It might be interesting to see an excerpt of all resource_statuses related to iptables from your last_run_report.yaml.
    – Zoredache
    Jul 23, 2014 at 17:08
  • Can you provide the relevant sections without the grep? You're losing relevant output since the lines don't contain 'iptable'. Jul 23, 2014 at 17:13
  • @Zoredache - pastebin.com/eeRJdKgg Looks like the service was stopped? I see nothing about it being started again, interesting I should be looking at these more often.
    – Shanedroid
    Jul 23, 2014 at 17:51
  • @ShaneMadden pastebin.com/ErhcH6dh
    – Shanedroid
    Jul 23, 2014 at 17:57
  • 1
    @Shanedroid Looks like; and it got an exit code of 0. Try running service iptables stop as root yourself - see what exit code you get (echo $?) and see what service iptables status shows then. Jul 23, 2014 at 17:59

1 Answer 1


I wanted to leave this here as an answer to my question because it worked for me. If you are running CentOS 5.4 this will work and effectively will ensure that the iptables module is unloaded from the kernel. I will ask a new question specifically relating to my continued work with CentOS 6 and puppet.

exec { "chkconfig_iptables":
          onlyif => "/sbin/chkconfig --level 3 iptables",
          command => "/sbin/chkconfig --level 3 iptables off",
          before => exec["kill_iptables"]
exec { "kill_iptables":
          onlyif => "/sbin/lsmod | grep ip_tables",
          command => "/sbin/service iptables stop;/sbin/modprobe -f -r ip_tables"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.