A few years back we tried to get nftables to work for QoS marking QoS and nftables … some findings to share at the time, there were problems with OpenWrt not quite supporting nftables correctly.
Then last year, there was some more effort... Nftables custom QoS, round 2 and the thing that people complained about the most was DNSmasq not having support for adding ip addresses to an nftables set based on lookups (so for example you couldn't easily downprioritize googlevideo.com to force YouTube to not bork your interactive video calls). But at the end of that thread the patches to dnsmasq landed, and I believe this should work now.
Meanwhile, Nftables migration maturity in OpenWrt 21.02 we have reports that nftables comes up reliably on OpenWrt 21 and that @jow has put together fw4 which allows you to use nftables as the backend and still configure a firewall through uci (though I much prefer the nftables firewall syntax).
So, show of hands, how many people want to take yet another stab at building an nftables firewall example with QoS tagging and Dnsmasq support and such?
I don't know. If I were going to use nftables on OpenWrt I'd do it using the nftables scripting language. The existence of fw4 though makes it so that getting nftables to work on OpenWrt is more of a priority. this ultimately means that these days it's reported that you can switch to nftables and there are no hitches.
This is like asking why Python and not x86 Assembler. nftables is a high level language for describing packet rules, and eBPF is a bytecode for injecting verifiable instruction sequences into the linux kernel. It's entirely possible for nftables to compile its rules to eBPF (though at the moment it doesn't). They're not really separate.
eBPF by itself is useless without something human usable to describe the computations of interest that compiles to eBPF. at the moment this is mostly low level languages like C, though Julia does have an eBPF compiler as well... but in general you don't want to program packet filters in C or even Julia. eBPF is literally a machine language for a virtual machine so it does things like "Load into register" "add 1 to contents of register" "divide register by other register" etc.
QoSify is basically a high level language for doing packet tagging which compiles to eBPF. I have nothing against it but have found that in general nftables is comprehensive language for packet manipulation and extremely powerful and useful, with a much broader applicability domain.
good evening daniel I have a lot of availability at the moment, I had followed pres nftables round 2, if I do the test I would do it on a test router if you are up and running, we can start when you want;)
several questions come to mind
1 would using nftables increase the throughput and the processor capacity, in my case dual core 1.4 ghz armv8 for larger connections which in the future will be present in homes
2: can we convert our iptables into nftables what seems possible to me
In general there are a lot of things in nftables which make the firewall use less cpu resources, yes. Including offloading is available.
In general yes, but I think it's easier to start from scratch, and maybe then convert a few special purpose rules.
I'm thinking what we need is a git gist for a general purpose OpenWrt firewall based on nftables, with packet classification, then people can grab the gist and edit it for their needs, and test.
I don't have a ton of time available, but if I can get people engaged, then we can make a lot of progress by people editing the base script and doing testing, and I'm all for that!
Ok, I have set up a Git Repo for this project. I'd appreciate if people would try to test. If possible when you have errors try to fix them first using https://wiki.nftables.org/wiki-nftables/index.php/Main_Page to refer to syntax in nftables.
The Github is:
I believe the easiest way to install this is to grab the raw file using wget:
cd /etc/
wget https://raw.githubusercontent.com/dlakelan/OpenWrtNFTables/main/nftables.conf
then disable the standard openwrt firewall (in Luci), and enable this by running
nft -f /etc/nftables.conf
in your /etc/rc.local
With this script, the ingress will not do the more sophisticated marking, but the postrouting will do that marking, so if you use a veth with cake on egress of LAN you can get the benefit of the more sophisticated prioritization
Yes, It looks like you need to install related packages. Let's figure out what those are, and then I'll stick it in the README. Nice find @dave14305 I'll put that in the README as well
`root@OpenWrt:~# nft -f /etc/nftables.conf
/etc/nftables.conf:109:29-35: Error: The inet family does not support this hook
type filter hook ingress device eth1 priority 0; ## FIXME, this can't be a variable so put your WAN device here
^^^^^^^
root@OpenWrt:~# nft -f /etc/nftables.conf
/etc/nftables.conf:109:29-32: Error: unknown chain hook
type filter hook eth1 device eth1 priority 0; ## FIXME, this can't be a variable so put your WAN device here
^^^^
root@OpenWrt:~# nft -f /etc/nftables.conf
/etc/nftables.conf:109:29-32: Error: unknown chain hook
type filter hook eth1 device WAN priority 0; ## FIXME, this can't be a variable so put your WAN device here
^^^^
root@OpenWrt:~# nft -f /etc/nftables.conf
/etc/nftables.conf:109:29-31: Error: unknown chain hook
type filter hook WAN device eth1 priority 0; ## FIXME, this can't be a variable so put your WAN device here
^^^
root@OpenWrt:~# nft -f /etc/nftables.conf
/etc/nftables.conf:109:29-31: Error: unknown chain hook
type filter hook wan device eth1 priority 0; ## FIXME, this can't be a variable so put your WAN device here
^^^
root@OpenWrt:~#
`
i can install snapshot if you want maybe for that this error ?
