puppetlabs-firewall confused by options used by the SYNPROXY target extension

[greatflyingsteve]

Use Case

The puppetlabs-firewall module not only cannot create rules which use the SYNPROXY target extension, 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 options from iptables' SYNPROXY target extension.

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).

SYNPROXY is probably no longer necessary for Linux-based operating systems running 4.4 or newer kernels, as kernels of that release and newer have much better native SYN flood support and don't really need the SYNPROXY target to work around the lack of that kernel code (by adding it in an iptables extension), but any Puppet users making a major OS distribution change are unlikely to put a complete rework of their firewall rulesets in the critical path if the existing rules can be expected to work on their next platform at least during transition.