[lstodd]

Not much different. FreeBSD's pf is a port of OpenBSD's pf, and nftables are heavily influenced by them.

At this point I rather doubt the sanity of people still sticking to iptables tbh.

So there is approximately one concept of "packet filter done right". UI madness is on UI authors.

[radlad]

The primary reason I stick to iptables instead of nft is that I already learned iptables decades ago, and some software I interact with still defaults to iptables and/or does not have full support for nft.

Why do you doubt the sanity of people sticking to iptables? What makes nft compelling?

[0xCMP]

My main reason is that nft applies configs atomically. It also has very good tracing/debugging features for figuring out how and why things aren't working as expected.

That said, I think many distros are shipping `iptables` as the wrapper/compatibility layer over nft now anyways.

[znpy]

as somebody that's not a network engineer by day and has barely grokked iptables, could you recommend some resources for learning nftables ?

[0xCMP]

I used the nftables Wiki to learn all the basics I know about nft: https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

Here is their example relevant to the current article: https://wiki.nftables.org/wiki-nftables/index.php/Simple_rul...

[simoncion]

As someone who recently switched over from iptables to nftables on one of my machines, the only thing that's better with nftables are sets and maps...

And, like, maybe I'm missing something, but I've found that sets are insufficiently powerful and maps are insufficiently well-documented. You can't have nested sets... that is sets that are defined (partially or completely) in terms of other sets. You also can't share sets across tables (or have "global" sets)... so that list of interfaces that'd be really good to apply to all of your rules? Yeah, you've gotta duplicate it in every damn table. And maps? My big beef with them is that the documentation makes two things very unclear:

1) What part of the nftables rule is going to do a lookup of the key in the map and what part will get the value. Like, seriously. Check out the nft(8) man page and look at their mapping examples. The k:v selection and insertion logic is clear as mud. I can guess a couple of possible interpretations, but if they explicitly state the logic, I must have skipped over it.

2) If it's even possible to have a multi-component key, to -for example- cook up a "verdict map" that fills out the statements:

  iifname $NAME oifname != $NAME $VERDICT
  iifname $NAME1 oifname $NAME2 $VERDICT

You also lose the really nice tabular status display that 'iptables -L -n -v' provides you... instead you get a nested abomination that (on the one hand) thankfully isn't fucking JSON, but (on the other hand) isn't JSON, so you have to cook up a processor if you want to transform it. You also lose the really nice, well-thought-out CLI help text for doing basic shit, like, suchas "List the goddamn rules in the fucking ruleset". Even the nft(8) man page takes its sweet time getting around to telling you how to do that really fundamental task.

"The CLIs are much less nice to use" is kind of a theme I've noticed with some of these replacement networking-management tools. 'bridge' is way less nice to use than 'brctl' [0], 'ss' is quite a bit more obnoxious than 'netstat', etc, etc.

Though, to be clear, I find 'ip' to be a much better tool than 'ifconfig'... at least the Linux version of 'ifconfig'. Maybe the BSD version is great.

[0] It doesn't help at all that you have to use both 'ip' and 'bridge' to manage bridges.

[hurricanepootis]

There is iptables-nft, which is iptables with an NFT backend.

[craftkiller]

> nftables are heavily influenced by them

Are they? I recently had to learn nftables and they seem to be iptables but with a slightly nicer syntax and without pre-defined chains. But otherwise, nftables directly maps to iptables and neither of them seem similar to pf.