Using a LOG jump with a log_level of 4 causes an unnecessary updating action

[sbrowne-godaddy]

Describe the Bug

When using a log_level of 4/warn, corrective action occurs every puppet execution. From my testing it appears that iptables-save does not save the log level when the default value (4) is in use. As such, the firewall module does not read it in and thus fails its comparison.

Expected Behavior

When using the log_level of 4/warn, I expect no corrective actions to be taken.

Steps to Reproduce

Steps to reproduce the behavior:

1. Define firewall policy similar to:

  firewall { '998 log rejected input (v6)':
    chain      => 'INPUT',
    jump       => 'LOG',
    log_level  => '4',
    limit      => '10/min',
    log_prefix => 'ip6tables: [INPUT] REJECT: ',
    proto      => 'all',
    before     => undef,
    protocol   => 'ip6tables',
  }

2. Apply.
3. Expected output upon subsequent runs:

Notice: /Stage[main]/Profile::Base::Firewall::Post/Firewall[998 log rejected input (v6)]/log_level: current_value , should be '4' (noop) (corrective)

Environment

• Version:
  • module tag v8.0.2
  • puppet 8.6.0
  • RHEL7 iptables v1.4.21
  • RHEL9 iptables v1.8.8 (nf_tables)
• Platform: RHEL7, RHEL9

Additional Context

Removing the log_level clears the issue up, however this is unintuitive. I've not looked at the iptables-save code so I'm not sure what 'other' default values it doesn't save. I'm also unsure whether this default is different between platforms.