Any Slackers using nftables rather than iptables? If yes, any comments or observations to offer?

I attempted (studied) using nftables but couldn't really get used with the new syntax and messed up some of my firewalls. While waiting for some other inputs from more experienced Slackers, you could have a look at:
https://linux-audit.com/differences-...les-explained/
https://wiki.nftables.org/wiki-nftab...es_to_nftables
https://developers.redhat.com/blog/2...king-nftables/

Before you decide which one to use, note that if you look for inspiration/examples, you'll find the majority of firewall rules in iptables syntax.
Printing/learning this schematic could be more helpful at the start of the journey:
https://upload.wikimedia.org/wikiped...acket-flow.svg

And, there's already a new kid in town:
https://lwn.net/Articles/747551/
https://linux-audit.com/bpfilter-nex...inux-firewall/

2 members found this post helpful.

I also studied nftables.
RHEL / CentOS and Debian have already switched to nftables.
I am pleased that in Slackware I have the opportunity to choose what I want and can use. I even tried a conversion of my firewall with iptables-translate -> I failed ... but, of course, I still have to learn!
Don't know if I can anymore, I'll try again when I have more free time.

This was partly my reason for starting the thread. Slackware has included nfstables for a while now but I haven't seen any related chatter among Slackers.

From what I understand, iptables does not scale well when you have to write fairly large and complex rules. The newer implementations are supposed to be more efficient and can implement newer features. I don't think iptables will be going anywhere though.

Going off on a slight tangent, I believe one important reason why netadmins haven't been flocking to nftables, is that iptables is a quite powerful tool, and nftables doesn't really bring much to the table (ahem) while introducing an entirely new syntax.

You even see those advocating nftables misrepresenting iptables in terms of what functionality it has to offer. For instance, consider the first of these two articles:
From that article:Really? Does iptables -D and iptables -I not work at the lwn.net offices?

(And as for the syntax, I really detest the nftables config files. They look nothing like the firewall ruleset on any other device I've ever used.)

6 members found this post helpful.

I should also state that this was the information given during a Red Hat Training class by the instructor. I can't really say for sure how factual it is.

Not using nftables, but I did make the effort, so I hope my comments are helpful.

It has been a while ago, but I initially looked into nftables, and my conclusion was this, exactly.

The netfilter kernel hooks and routing infrastructure remain unchanged, as well as connection states... so what do I get other than a new syntax? There are claims of better performance, but I have no performance issues to address.

I have decided to stay with iptables and will continue to maintain and extend my own iptables based management tools without concern that iptables might disappear or fall behind.

4 members found this post helpful.

Those commands "work" the same way an editor works when adding or deleting text in a file, i.e. by creating an entirely new file that includes the changes and then replacing the old file with the new. "iptables -I ..." and "iptables -D ..." extract the entire current rule set from the kernel, make the indicated change, and then load the entire new rule set into the kernel. For a large rule set, that's a very inefficient way to do business and impacts packet flow while that new, large rule set is being loaded.

2 members found this post helpful.

Any idea how large the ruleset would have to be before this would be noticable?

I've never had any issues with traffic being impeded due to inserts or deletions, but admittedly I mostly deal with sub-gigabit Internet uplinks and rulesets with no more than 400-500 filter rules, and perhaps 50 NAT rules at most.

I really don't know. I've never experienced a problem with it myself. I was as surprised as others about the "whole rule set" action -- surprised enough to dig into the source code for the iptables command to confirm it, and yes, that's what it does. It's been a couple of years since I did that, but I doubt it has changed.

Have been looking into setting up my new firewall-to-be using nftables.
For various reasons it's been dragging out, but *most* of those reasons are unrelated to nftables itself.

Main observations;
- Not really having touched/written firewall rules in neither nftables nor iptables for litterally years one would have to (re-)learn stuff in any case. So why not try the new one?
- Finding good documentation for nftables was, or at least felt quite difficult. Most of what I found was either more or less assuming you know iptables fairly well and/or assumes you are a seasoned programmer. I am neither, even though I - for the most part - am able to understand code if I am so inclined. But yeah, it felt a bit more demanding than I hoped for. To be fair I would feel a bit the same about iptables, but since it has been around for longer it's easier to find good documentation for it - for "someone like me".
- After stating the above; it isn't totally black magic when you start figuring out what's going on. Just might take a bit of time to wrap your head around some of it. That said, you *can* write rules that look awfully much like iptables rules if you are so inclined. You would forego some of the simplifications and updates/strengths (whatever you'll call it) in nftables though. But it is possible.

I guess those are the main things I remember right now at least.

The more people starts using nftables, the more resources for it would pop up over time and I guess it will kind of be "demystified" a bit. And yeah, nftables does a fairly good job for most people and it's been around for longer so it's an old habit that will die hard.

--
KarlMag

@Ser Olmy
I didn't read that LWN article (actually presenting BP filter and not nftables) thoroughly and my intention was to provide upnort with some unbiased (by my rejection of nftables - new syntax adoption) info about what nftables brings new.
There is not that much detailed architectural info I could find available in one place about nftables, I knew it has its own virtual machine in the kernel but wasn't aware about how it loads/unloads the rulesets different from iptables.
LWN has an actual article about nftables (kernel mailing list):
https://lwn.net/Articles/324251/
netfiler.org too:
https://netfilter.org/projects/nftables/

Thanks to the very useful insights rknichols provided, I learned now that nftables is more efficient in modifying rules and this article - in section "iptables vs. iptables-nft vs. nft" confirms and details this:
https://www.redhat.com/en/blog/using...linux-firewall

@stormtracknole
KISS always "scales well"

Well.. sometimes you can only keep it as simple as you can.
If you start keeping it simpler than that, something (important) has to give, and then what?

Not exactly a common home setup, but if you have to filter data on a multi homed, multi ISP connected machine (think multiple 10Gb (or even faster) connections). Such a setup, granted, isn't yet extremely common, but also not totally unheard of.
Would be nice if it manages to get as much traffic as possible filtered as needed, preferrably all of it.

--
KarlMag

@karlmag

I keep the firewall as simple as possible considering that every rule has an impact on both the latency (packets delay) and performance (processed pps & throughput). Starting by dropping everything and then focus only on the necessary rules to allow required traffic, no unnecessary additional rules or custom chains.
Modern firewall tools netfilter&nftables are versatile and there is a temptation to connect (route&forward) everything with/to everything and then build complex firewalls as "magical" solutions and single point of failure (security-wise). Wrong IMHO. VLANS, network separation, advanced routing can&should also be employed.
With the KISS approach I haven't got into performance issues, even on gigabit, with iptables and that's why I didn't really focus on nftables. I tried it only because I considered to simplify my 2-3 pages iptables firewalls with the new nftables syntax, reduce them to maybe one page, but failed to adopt/memorize the new syntax - my fault! - and dropped it.

1 members found this post helpful.