Rich rule purging isn't idempotent, or isn't saving, or similar

[tskirvin]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.24.0
• Ruby: ruby 2.7.7p221 (2022-11-24 revision 168ec2b1e5) [x86_64-linux]
• Distribution: Alma 9 (but probably true on other releases too)
• Module version: latest from github (5f9836e506383ac6851d7c2ab49f19c198237d4c)

How to reproduce (e.g Puppet code you use)

  $zone = '99_public'

  firewalld_zone { $zone:
    target           => '%%REJECT%%',
    icmp_blocks      => [
      'fragmentation-needed',
      'neighbour-advertisement',
      'neighbour-solicitation',
      'router-advertisement',
      'router-solicitation',
      'tos-network-redirect',
    ],
    masquerade       => false,
    purge_rich_rules => $purge_rich_rules,   # parameterized for testing
    purge_ports      => true,
    purge_services   => true,
  }

...and then later manifests use firewalld_rich_rule(), e.g.:

      firewalld_rich_rule { 'ssh_fnal_4':
        zone     => $zone,
        action   => 'accept',
        source   => { 'ipset' => 'fnal_4' },
        port     => { 'port' => $port, protocol => 'tcp' },
        priority => 111
      }

What are you seeing

When I turn on rich rule purging, every run I get the same general thing: all existing rules are purged (except for echo-request ping rules), then puppet re-implements the rules. See the logs below. This is only the case if purge_rich_rules is true for the puppet zone.

What behaviour did you expect instead

I'd expect that puppet would recognize its previous rules and not purge them. (This is critical! We can't go deleting firewall holes every time puppet runs, this will interfere with our work.)

Output log

Notice: /Stage[main]/P_firewall::Firewalld::Zone::Public/Firewalld_zone[99_public]/purge_rich_rules: purge_rich_rules changed 'purgable' to 'true' (corrective)
Notice: /Stage[main]/P_firewall::Ssh::Lockdown/Firewalld_rich_rule[ssh_lockdown_4]/ensure: created (corrective)
Info: /Stage[main]/P_firewall::Ssh::Lockdown/Firewalld_rich_rule[ssh_lockdown_4]: Scheduling refresh of Class[Firewalld::Reload]
Notice: /Stage[main]/P_firewall::Ssh::Lockdown/Firewalld_rich_rule[ssh_lockdown_6]/ensure: created (corrective)
Info: /Stage[main]/P_firewall::Ssh::Lockdown/Firewalld_rich_rule[ssh_lockdown_6]: Scheduling refresh of Class[Firewalld::Reload]
[...]

This repeats every run.

Any additional information you'd like to impart

I don't see the "purge rules" action in a --debug run. Instead, I'm watching the output of /usr/bin/firewall-cmd --zone 99_public --list-rich-rules on a separate terminal. The rules come back when puppet says they come back in its logs.

[tskirvin]

Any word? This is fairly critical to our firewall use case.

[brgerig]

I also have this problem.

[tskirvin]

For what it's worth, my solution to this problem was to abandon firewalld entirely. nftables has treated me better.

[dionrowney]

We are also seeing this issue and have the same situation. Is there any solution in sight for this?

[dionrowney]

Have you noticed any traffic drops or issues when the rich rules get flushed? We have been letting it do this and some have seen DNS timeouts being logged and wonder if that flushing happened to happen at the same time as the dns lookup was occuring.

If this is the case we cannot contiunue to use priorities.

Is any work being done on this?

[dionrowney]

We were noticing short netork DNS outages every time the rules were flushed and had to add "purge_rich_rules: false" to the zone config to prevent this and continue to use priorities. This however does allow for the potential for rules to not be removed. WE STRONGLY RECOMMEND THIS BE FIXED.