puppetlabs-firewall icon indicating copy to clipboard operation
puppetlabs-firewall copied to clipboard

"iptables" parser error (random was meant to be a boolean but received value: true-fully) when running Puppet on RHEL 8.6 Nodes

Open gmcgrillan opened this issue 2 years ago • 8 comments

Describe the Bug

When running Puppet on an RHEL 8.6 node, the run fails with the following error:

Error: Could not prefetch firewall provider 'iptables': Parser error: random was meant to be a boolean but received value: true-fully.
Error: Failed to apply catalog: Parser error: random was meant to be a boolean but received value: true-fully.

This results in no resources being applied. Running servers on other RHEL 8 versions (8.5 for example) and have experienced no issues.

Expected Behavior

Should be able to parse the IPTABLES rules as per Rhel 8.5 (see above)

Steps to Reproduce

Steps to reproduce the behavior: Will provide more details shortly.

Environment

  • Version latest 3.5.0
  • Platform Rhel 8.6

gmcgrillan avatar Jun 14 '22 14:06 gmcgrillan

Some more information from the customer:

Please find below some code snippets from our firewall resource:

# == Class: profile::base::ossettings::firewall::firewall
#
class profile::base::ossettings::firewall::firewall {
  stage { 'fw_pre':  before  => Stage['main']; }
  stage { 'fw_post': require => Stage['main']; }

  class { 'profile::base::ossettings::firewall::pre':
    stage => 'fw_pre',
  }

  class { 'profile::base::ossettings::firewall::post':
    stage => 'fw_post',
  }

  # The firewall purge is destructive for docker hosts; use for all other systems
  if $facts['docker_binary_exist'] == false {

    resources { 'firewall':
      purge => true
    }

  }

}
 
# == Class: profile::base::ossettings::firewall::pre

#

class profile::base::ossettings::firewall::pre {

  # Default firewall rules

  firewall { '000 accept all icmp':

    proto  => 'icmp',

    action => 'accept',

  }

  firewall { '001 accept all to lo interface':

    proto   => 'all',

    iniface => 'lo',

    action  => 'accept',

  }

  firewall { '002 accept related established rules':

    proto  => 'all',

    state  => ['RELATED', 'ESTABLISHED'],

    action => 'accept',

  }

  # Allow SSH

  firewall { '100 allow ssh access':

    dport  => '22',

    proto  => tcp,

    action => accept,

  }

  # Allow HTTP and HTTPS

  firewall { '100 allow http and https access':

    dport  => [80, 443, 8080],

    proto  => tcp,

    action => accept,

  }

  #Allow Samba

  firewall { '101 allow samba':

    source      => '0.0.0.0/0',

    dport       => '445',

    destination => $::ipaddress,

    proto       => tcp,

    action      => 'accept',

  }

  # Avoid removing Docker rules

  if $facts['docker_binary_exist'] == true {

    firewallchain { 'FORWARD:filter:IPv4':

      purge  => true,

      ignore => [ 'DOCKER', 'docker', ' br-' ],

    }

    firewallchain { 'DOCKER:filter:IPv4':

      purge  => false,

    }

    firewallchain { 'DOCKER-ISOLATION-STAGE-1:filter:IPv4':

      purge  => false,

    }

    firewallchain { 'DOCKER-ISOLATION-STAGE-2:filter:IPv4':

      purge  => false,

    }

    firewallchain { 'DOCKER-USER:filter:IPv4':

      purge  => false,

    }

    firewallchain { 'OUTPUT:nat:IPv4':

      purge  => true,

      ignore => [ 'DOCKER' ],

    }

    firewallchain { 'DOCKER:nat:IPv4':

      purge  => false,

    }

    firewallchain { 'POSTROUTING:nat:IPv4':

      purge  => true,

      ignore => [ 'DOCKER', ' br-', '169.254.' ],

    }

    firewallchain { 'PREROUTING:nat:IPv4':

      purge  => true,

      ignore => [ 'DOCKER' ],

    }

    # Avoid removing RTPENGINE rules  

    if $facts['servertype'] == 'INSERT_SERVER_NAME HERE'    *****THIS HAS BEEN REPLACED*******

    {

      #ignore RTPENGINE rules when input rules are cleaned out

      firewallchain { 'INPUT:filter:IPv4':

        ensure => present,

        purge  => true,

        ignore => [ 'RTPENGINE' ],

      }

    }

    else

    {

      #ensure input rules are cleaned out

      firewallchain { 'INPUT:filter:IPv4':

        ensure => present,

        purge  => true,

      }

    }

  }

}

# == Class: profile::base::ossettings::firewall::post

#

class profile::base::ossettings::firewall::post {

  firewall { '999 drop all other requests':

    action => 'drop',

  }

}

There are other minor firewall resources used in other modules, however, I believe these are only to add further rules. The bulk of the firewall configuration is done in the above snippets.

gmcgrillan avatar Jun 15 '22 11:06 gmcgrillan

@gmcgrillan It look's like random is being retrieved strange, but I'm having some trouble replicating. Could you ask them to check the machine causing the problems and do a iptables -L? They can censor all the port and ip numbers. I just want to see if any of the rules have random/random-fully set and if so, how exactly they are returning.

david22swan avatar Jun 24 '22 09:06 david22swan

will ask now! Apologies didn't see this

gmcgrillan avatar Jun 29 '22 14:06 gmcgrillan

Folks - I have the iptables but there are some customer-facing fqdn's I'd like to either sanitise or pass to you @david22swan independently.

Give me a shout on slack @david22swan

gmcgrillan avatar Jun 29 '22 15:06 gmcgrillan

@gmcgrillan Could you get back to the customer and this time ask them to run iptables-save and send the results back. It should give a bit more information and hopefully show what the issue is.

david22swan avatar Jul 05 '22 09:07 david22swan

@david22swan - I've sent you that directly on slack! G...

gmcgrillan avatar Jul 05 '22 11:07 gmcgrillan

Think I've got an idea what the issue is. Look's like --random-fully is being retrieved and then misidentified as --random. So that when true is appended after it to keep Puppet happy it's instead turning --random-fully into --random true-fully.

Not sure why this is popping up on RHEL 8.6 specifically..... both variables are tested so this doesn't happen and run green on RHEL 8 + 9

david22swan avatar Jul 05 '22 11:07 david22swan

@gmcgrillan Hey, have gotten a potential fix for this issue if you could ask the customer to pull it down and try it out: https://github.com/puppetlabs/puppetlabs-firewall/pull/1058

david22swan avatar Jul 13 '22 10:07 david22swan

The customer responded in a new support ticket, the fix works as expected! Can we expect this to get merged and released once the tests have been fixed?

pgrant87 avatar Sep 22 '22 16:09 pgrant87

Being used for internal tracking: https://tickets.puppetlabs.com/browse/CONT-23

pmcmaw avatar Sep 28 '22 08:09 pmcmaw

Fix merged, release should go out sometime today

david22swan avatar Oct 03 '22 10:10 david22swan

Release has gone out

david22swan avatar Oct 05 '22 12:10 david22swan