FW4 or nftables not including ruleset-pre directory?

Installing and Using OpenWrt
1

I don't think I'm missing anything obvious here, but I can't get .nft files from nftables.d/ruleset-pre to be included. I'm trying to do some weird broadcast relaying for some janky hardware, and the only way I was able to get this working is adding the rule in its own table:

table ip relay4 {
        chain input {
                type filter hook input priority filter; policy accept;
                iifname "br-lan.1" udp dport 9999 ip daddr 255.255.255.255 dup to 192.168.2.108
        }
}

But I can't figure out how to preserve this between restarts because I can't figure out how to create tables using the nftables.d directory. My understanding was that putting that definition in an .nft file in the ruleset-pre directory would insert it before the inet fw4 table. I've also tried adding:

table ip relay4
flush table ip relay4

to the top of the file, but this also doesn't seem to work.

I'm suspicious the file isn't being processed at all though, since if I just type in gibberish I don't get any errors restarting the firewall service. And for what it's worth, ruleset-post doesn't work either. I do have some rules successfully being included from files in the nftables.d directory into the inet fw4 table, so at least that bit is working.

Edit: Sorry, should have added that I'm running 23.05-rc1

2

The files in /etc/nftables.d are included into the main table before any of the chains are created, and those files should contain only chain definitions. Also, the only files included have a .nft extension, which is probably the reason you aren't seeing errors from this (it's simply being ignored).

Try this, see what you get (I'll trim out a bunch of noise, but you should be able to figure it out):

$ fw4 print | more
table inet fw4 {
...
        #
        # User includes
        #

        include "/etc/nftables.d/*.nft"
...
        chain input {
...

If you just want to add a single rule or maybe a couple to an existing chain, then the easiest way I know to do that is using /etc/firewall.user, which requires a few edits to make work:

First, create the new user file with your rule.

$ cat > /etc/firewall.user <<RULES
#!/bin/sh
nft add rule inet fw4 input 'iifname "br-lan.1"   udp dport 9999   ip daddr 255.255.255.255   dup to 192.168.2.108'
RULES

Second, update the network config file.

$ cat >> /etc/config/firewall <<INCLUDE
config include
        option enabled '1'
        option type 'script'
        option path '/etc/firewall.user'
        option fw4_compatible '1'
INCLUDE

Finally (optional but highly recommended), make sure that sysupgrade, auc and asu all keep your firewall.user file around during upgrades.

$ echo '/etc/firewall.user` >> /etc/sysupgrade.conf
$ sysupgrade -l | grep firewall.user
... should show the file

When this is all done, you can run fw4 reload, then check it with something like nft list ruleset | grep 'port 9999' to see that it's in the active rules.

1 Like
3

Is your *.nft file in /usr/share/nftables.d/ruleset-pre/? This is different than the purpose of /etc/nftables.d. Make sure you don’t have auto_includes set to 0 in your firewall config.

Test with fw4 print and look for any errors/warnings.

1 Like
4

Well.... no. It was not. :grimacing: Moved it from /etc/nftables.d/ruleset-pre over there and it works great now. I suspect all the documentation I was reading actually said /usr/share/ and I just wasn't looking closely enough. Thank you!

Also, thanks for the quick response @efahl, unfortunately I can't figure out how to get dup to work by adding a chain/rule to the inet fw4 table (it complains about "unsupported family" something); I've only been able to get it working in its own separate table. I'd have preferred to keep it all in the fw4 table just for convenience, so maybe I'll keep troubleshooting that. Extra thanks for the tip on sysupgrade though, because I suspect /usr/share/ also isn't preserved by default.

1 Like
5

FYI, we just had a thread about dup and inet recently:

2 Likes
6

Thanks, yeah, @efahl 's results there with a single-family table is what lead me to making a separate table in the first place. Though it looks like now there might be a solution over there in the main table so I'll have to give that a try too.

Thanks again!

7

Quite correct, almost nothing you add will be included by default, so you almost always should update /etc/sysupgrade.conf every time you add a file. Even some standard software that you think would "do the right thing" doesn't (htop uses /root/.config/, but doesn't add it to the backup list).

1 Like
8

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.