Re: Rocky Linux 9 with firewalld and nftables always tracks connections

["Kerin Millar" <kfm@plushkava.net>]

On Sun, 31 Mar 2024, at 12:22 AM, Blaine Elzey wrote:

[...]

> Now that I know the underlying nftables configuration, I need to 
> incorporate this configuration into the firewalld configuration.  I 
> understand if this is off-topic and I may need to post in a different 
> forum.
>
> I see that firewalld says that direct rules is deprecated, and to use policies.

How very helpful of it.

>
> Unfortunately policies do not support notrack, and the necessary 
> arguments that I have tried in direct rules are invalid.  I have also 
> come to find that the firewall direct rules only support iptables, 
> while my firewalld.conf is set to use nftables; thus, unable to see 
> nftables tables and chains setup by firewalld.  Maybe the nftable rules 
> from firewalld override the iptables rules from firewalld direct?

Rocky 9 offers iptables-nft, which uses nftables as a backend while continuing to support xtables extensions. Unfortunately, it cannot be relied upon to translate the syntax of a given iptables(8) rule to a native nft(8) rule, even for those rules where it is technically possible. Consider the following.

# nft flush ruleset
# iptables -V
iptables v1.8.10 (nf_tables)
# iptables -t raw -A PREROUTING -j CT --notrack
# nft list ruleset
# Warning: table ip raw is managed by iptables-nft, do not touch!
table ip raw {
	chain PREROUTING {
		type filter hook prerouting priority raw; policy accept;
		counter packets 0 bytes 0 xt target "CT"
	}
}

This shows iptables electing to use the CT extension from xtables, rather than produce the native, equivalent nftables rule. Consequently, one ends up with a hybrid ruleset that can no longer be safely managed with nft alone.

So, should you wish to try the firewall.direct(5) syntax, be sure to define "FirewallBackend=iptables". Further, in each case that the backend is switched, be sure to stop the service and run "nft flush ruleset" before starting it again.

>
> At the moment, I created some workaround scripts from the information 
> in this post, and call the in the systemd  ExecStartPre= for DNS 
> service start.  I remove them in ExecStopPost=.

I fear that this might prove brittle. Presumably, firewalld can be instructed to interact with the ruleset in such a way that the necessary rules are lost, well after the systemd service has been started. Still, I can think of nothing else, other than to forgo the use of firewalld altogether.

-- 
Kerin Millar