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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sat, 30 Mar 2024 05:08:04 +0000
Blaine Elzey <Blaine.Elzey@xxxxxxxxxxxxx> wrote:

> I enabled the public zone and the dns service (udp/tcp port 53).  Firewalld service is running and nftables service is not.  The connection tracking table gets full on busy servers, and drops packets.  In prior Linux (RHEL7) I set iptables rules via firewalld direct configuration file.  The same rules are not working now.  I set dns to listen on a 2nd port (5353), and tried 2 nft commands:
> 
>   # nft insert rule inet firewalld mangle_PREROUTING udp dport 5353 notrack meta mark set 53
>   # nft insert rule inet firewalld filter_IN_public_allow mark 5353 accept

You go on to show that the mangle_PREROUTING table is defined in the following manner.

chain mangle_PREROUTING {
	type filter hook prerouting priority mangle + 10; policy accept;
}

As concerns the use of notrack, let's consider what the latest nft(8) manual has to say.

"Note that for this statement to be effective, it has to be applied to packets before a conntrack lookup happens. Therefore, it needs to sit in a chain with either prerouting or output hook and a hook priority of -300 (raw) or less."

You have not fulfilled this requirement because your priority level is define as -140 (-150 + 10). Below is an example of how one might correctly employ notrack. It presumes that the DNS server is running at the same host as bears the ruleset.

table inet raw {
	chain PREROUTING {
		type filter hook prerouting priority raw; policy accept;
		# Match packets destined to the DNS server (excluding packets that are to be forwarded).
		fib daddr type local udp dport 5353 notrack
	}

	chain OUTPUT {
		type filter hook output priority raw; policy accept;
		# Match packets locally generated by the DNS server.
		udp sport 5353 notrack
		# Not keeping state for "lo" can also be an effective way of conserving resources.
		oifname "lo" notrack
	}
}

Should you wish to constrain your use of the conntrack table further still, you could potentially go as far as to refrain from using conntrack at all for packets generated by - and destined to - the firewall, instead reserving the use of conntrack for forwarding duty.

-- 
Kerin Millar




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux