puppetlabs-firewall confused by `--tcp-option`

[greatflyingsteve]

Use Case

The puppetlabs-firewall module not only cannot create rules which match on TCP options, it is also confused if it encounters them, and produces a "Skipping unparseable rule" warning. The failure doesn't prevent other rules from being applied, but they are applied out of order relative to the unparseable rule. The module also:

• doesn't (can't?) remove the rule
• can't be used to generate the rule
• can't ignore the rule in any way (which also rules out adding it externally)
• forces the rule to the bottom of the chain it's in
• generates (at least) one warning about this same rule for each instance of a Firewall resource that appears in the catalog

Describe the Solution You Would Like

The puppetlabs-firewall module should (at a minimum) recognize and (optimally) support the use of --tcp-option from iptables' TCP match extensions. Modulo the removal of some ugly historical hacks around --tcp-flags, this was not especially hard to implement.

Describe Alternatives You've Considered

The only viable options are:

• discontinue use of puppetlabs-firewall, and either move to a home-grown solution or attempt to use a different module
• just fix puppetlabs-firewall, which is the route I've taken.

There are too many other good things about the module, and the ability for different teams with entirely unrelated concerns, that coincidentally cut across the same host(s) (e.g. security, application, and operations teams each have competing requirements), to each have their own rule spaces in the codebase that are mediated by the module without needing to worry about who ought to "own" the netfilter subsystem is an enormous organizational win I'm not willing to give up.

Additional Context

I'm (currently) using Puppet 6.19 on CentOS 7. Upgrades to both Puppet 7 and CentOS Stream 9 are in the near future, and the additional overhead of needing to completely reinvent an existing wheel twice in the same year make just about everyone queasy. As noted in #1097 a bit ago, Puppet 6.24 is not strictly required once the module's hood has been cracked open; despite the recent drop of Puppet 6 from formal support in v5.0.0 of the module, the only actual barrier to using it with Puppet <= 6.11.1 is the systemctl daemon-reload exec that's no longer needed in any case (see PUP-10149).

[greatflyingsteve]

I have a PR nearly ready to file that addresses this issue, I just wanted to have this ticket to attach the commits to.

[LukasAud]

Hi @greatflyingsteve, thanks for reporting this issue and creating a PR to address it. We are working on a Firewall project at the moment that should replace our current module with a fully reworked, updated version. We hope this new version will address many ongoing issues and criticism the community might have with our module.