Nftables firewall accept command

Ask Fedora
1

I started to learn nftables and one thing is not clear to me:
DROP and REJECT are clear: the packet goes not further and end of evaluation. But in contrast with iptables, ACCEPT stops the current chain but every other chain in every table with same or lower priority and the same hook can drop the packet. This is complex if other programs enter nftables rules, for example NetworkManager with IPv4=Shared. Allowing forwarding from e.g. wireguard VPN to the interface on “Shared” is overruled by this NetworkManager created table. Is there a way out for this? Is “flowtables” something what can help?

Thanks !

2

For stuff like this, you might find it much easier to manage via firewalld zones, which will then be translated to nftables rules on the backend. This way you can set separate rules for your VPN vs your home LAN/ISP, etc., via multiple zones.

https://fedoraproject.org/wiki/Firewalld?rd=FirewallD#What_is_a_zone.3F

3

Dear Scott,

Thanks for the links, I’ll study them. It was already the way I tried, with iptables-legacy you could just push two rules into FORWARD to allow VPN-wg0 ↔ bridge0 by firewall-cmd --direct. Now there is nftables backend and --direct seems to be deprecated, so I tried the next with firewall-cmd:

set VPN-wg0 to the same zone as bridge0
allow intra-zone forwarding for this zone.

This did not work out, and the reason is the firewall table made by NetworkManager for the interface with IPv4=shared. Nothing wrong with it, it is a good firewall in the forward chain to protect the network using internet connection sharing, but it allows nothing but connection to outside for this interface. The only way I could get it running was injecting the wg0 ↔ bridge0 forwarding into this NetworkManager generated table. That’s the reason of my question: is there a “definitively accept” possibility in nftables to prevent packets to be catched in lower priority chains. I assume it’s designed in the current way for optimal security. In mean time I found that you can switch off in NetworkManager the generation of firewall rules, so probably that is the solution: generate the NAT and FORWARD with firewall-cmd after the “shared” interface is up and leave space for VPN to be plugged in…