Custom nftable rule doesn't work

I have this table present in /usr/share/nftables.d/ruleset-post/0-dqos.nft (I also tried placing it in /usr/share/nftables.d/ruleset-pre/0-dqos.nft`

table bridge dqos
flush table bridge dqos

table bridge dqos {
                chain download {
                        type filter hook postrouting priority 0; policy accept;
                        ether daddr 98:0D:AF:45:29:05 accept
                        ether daddr 3C:7C:3F:23:5C:50 accept
                        limit rate over 3125 kbytes/second drop

                chain upload {
                        type filter hook prerouting priority 0; policy accept;
                        ether saddr 98:0D:AF:45:29:05 accept
                        ether saddr 3C:7C:3F:23:5C:50 accept
                        limit rate over 3125 kbytes/second drop

What I want to achieve is for 3C:7C:3F:23:5C:50 and 98:0D:AF:45:29:05 to be immune from the rate limit limit rate over 3125 kbytes/second drop but for some reason every client on the network including the "whitelisted" ones is rate limited to 25 mbits/second (or 3125 kbytes/second).

The rules are read top to bottom and it's first match wins right? If so what is it that is going wrong here? I have kmod-nft-bridge installed and I'm using the v23.05.2 release on a BPI-R3 without offloading enabled.

I tried substituting the bridge table with inet and a bunch of ip and ip6 rules but the

limit rate over 3125 kbytes/second drop

Seems to apply in any case

My lan device is a bridge:

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        list ports 'sfp2'
        list ports 'lan1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        list ipaddr ''
        list dns ''
        option ip6assign '64'
        list ip6class 'local'
        list ip6class 'wan6'

I think the problem here is an assumption that the postrouting hook only applies for download traffic, and that the prerouting hook only applies for upload traffic.

I don't know anything about the specifics of bridges, but I'm pretty sure that forwarded traffic in both directions will go through both prerouting and postrouting.

If that's correct, upload traffic going through your "download" chain won't match either of the destination MAC addresses, so it will fall through to the limit rule. Similarly for the "upload" chain, download traffic will never match the source MAC address rules.

When I have to isolate upload/download traffic I do so by checking the incoming and/or outgoing interfaces.

(It's possible I'm missing something here and there are quirks with bridges that I'm not aware of. Happy to be corrected if that's the case.)

That makes sense what device would I give in the download and upload chains? I suppose I have to give oif/iif names to each blanket drop rule?

My wan iface is pppoe-wan and lan iface is br-lan

As always I'm sure there are many different ways of achieving the same thing, but this seems sensible to me - i.e. modify the limit rules so that they only apply to packets that are travelling in the right direction.

An alternative would be to add a rule at the beginning of each chain to accept immediately if the packet is travelling in the "wrong" direction for that chain.

I don't know enough about nftables to say which approach is optimal for performance.

Those seem like sensible interfaces to use, but I'm not 100% sure because my experience of firewalls is entirely limited to my router, which doesn't have either of them - I only have eth0, eth1 etc.

1 Like

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