/usr/share/nftables.d/chain-post will not get included if corresponding chain is not used in /etc/config/firewall
I'm building a (hopefully) reusable package to add support to firewall expectations using conntrackd -- helpers essentially. I notice that when I am placing a chain in a directory that matches a "standard" table (e.g srcnat_zone), and if the zone doesn't itself have any rules, the included rules do not get rendered.
This is despite the misleading message that Automatically including '/usr/share/nftables.d/chain-post/srcnat_zone/X.nft is printed when running /etc/init.d/firewall reload.
I dug into the code and it seems like the chains are rendered only if there's a corresponding set of rules in /etc/config/firewall. Should fw4 also emit the chain if an include requests to insert rules into a chain? I'll be happy to work on a patch if this is desirable.
I've been able to workaround this by using the table-post hook instead -- but I would imagine more granular includes would be advantageous.
You can add a chain { .. hook priority +(/-) 1..49 .. } even in separate table to force intended ordering
Yes, that's my workaround. I'm wondering if it's better for the includes to implicitly create those chains anyway?
I don't need any separate priorities, I'm just porting /etc/config/firewall rules to /usr/share/nftables.d. I ran into this when I removed the last rule in a chain, just wondering if we should keep them symmetric.
I think stay with it as long as it works (which is IMHO a priority) With plenty of time one could change helpers listing (and all consumers of it) to plug conntrackd into current kmods read-list-then-test-then-maybe-use eg https://github.com/openwrt/firewall4/blob/b6e5157527d361f99ad52eaa6da273cb0f2dfd59/root/usr/share/ucode/fw4.uc#L1937
Also +/-X priority is nice as it jumps out of the way of iptables-nft....
I think stay with it as long as it works (which is IMHO a priority)
Sure!
With plenty of time one could change helpers listing (and all consumers of it) to plug conntrackd into current kmods read-list-then-test-then-maybe-use eg
conntrackd doesn't register new modules AFAICS. I've got 6 different helpers registered, and I only see nfnetlink_cthelper
No, it is not about modules, but to include usermode/nfqueue helpers in the list. Then in every spot of calling chain handle the new kind of helper gadget... Lets start with proving the concept and simplest integration?