LWN: Comments on "Nftables reaches 1.0"

Nftables reaches 1.0

chaispaquichui — Thu, 09 Sep 2021 04:48:06 +0000

Very useful, thanks !

Nftables reaches 1.0

splitice — Thu, 09 Sep 2021 04:13:25 +0000

I'm in a similar camp. As someone who maintains and has developed alot of iptables modules I can certainly see the room for improvement, but I can't help but think that nftables made just as many steps forward as it did steps backwards.

Fingers crossed bpfilter will hit the mark better.

Nftables reaches 1.0

Chousuke — Fri, 03 Sep 2021 19:10:47 +0000

Maybe picking on iproute2 was a bit unfair; I just remembered spending a lot of time trying to decipher the dense synopsis notation way back when. Taking another look, they're definitely better than what nft has

Lately I've felt a bit spoiled by OpenBSD manual pages. If you want to know what good documentation with man pages can look like, you can take a look at some of them. If everything were documented to the same standard I would never need Google...

For example, If I want a quick overview on how OSPF works, I can just "man ospfd" on OpenBSD. The explanation may not strictly speaking have much to do with configuring ospfd itself, but well-placed context "fluff" is a huge quality-of-life improvement as it helps me understand the kinds of problems I can solve with the software.

Nftables reaches 1.0

ecree — Thu, 02 Sep 2021 14:01:38 +0000

Regarding bpfilter and its stagnation, I have a little story to tell. Back when bpfilter was new, Davem asked me if I'd lend a hand with the code generator (in the user-mode blob that translates iptables rulesets to BPF programs); I replied that I'd like to but that I couldn't find the documentation of the iptables uAPI/ABI and I didn't know it well enough to work without docs. (include/uapi/linux/netfilter_ipv4/ip_tables.h is… unenlightening.)

I heard nothing back, leading me to suspect that maybe the problem is that no-one *else* can remember all the corners of iptables either. 'The implementation is the spec' is fine until you want to replace the implementation.

Nftables reaches 1.0

carORcdr — Thu, 02 Sep 2021 05:19:36 +0000

I can appreciate the concern for the lack of examples, but if you actually look at all the manual pages for the 100+ programs (arpd...tipc-socket) there are actually a significant number of examples. If I decide to list them I will update this comment.

There are many non-iproute2 programs, including significant ones, that have far fewer examples. Some have null.

My definition of an example in the context of a program is a command string--

$|# program argument[s] file|filepath

I realize some may limit the definition of string to alphabetic characters. I do not. My definition of string is a string of characters--alphabetic, numeric and/or symbolic.

Nftables reaches 1.0

Chousuke — Wed, 01 Sep 2021 19:27:51 +0000

Replying to myself since I can't edit to give an actual example:

I tried finding the relevant documentation from the wiki page but I can't; I've forgotten where I found it the last time. The manual page says "Expressions can be combined using binary, logical, relational and other types of expressions", but *nowhere* does it detail what those expressions "binary", "logical" or "relational" expressions are. It doesn't even contain the word "operator".

I did find out that man libnftables-json at least lists "binary operations", but there's no context.

Just in case someone ends up needing it, you can do stuff like this:

ip daddr 10.240.1.0/24 dnat to ip daddr & 0.0.0.255 | 10.140.7.0;

I don't even remember how I figured that out the first time, but it wasn't thanks to the documentation.

Nftables reaches 1.0

Chousuke — Wed, 01 Sep 2021 18:58:18 +0000

Unfortunately the nft manual page seems to take after the iproute2 suite of tools in being extremely light on examples and leaving the reader to figure out how to put things togethers from rather loosely organized grammar descriptions and tables. You basically have to guess how to use it.

For example, if you wanted to know how to perform a 1:1 nat for an entire IP prefix, the manual page would not help because it doesn't even mention that you can use bitwise operators (&, |) with netmasks to perform calculations and modifications on packet fields.

I know there's a partial sentence somewhere on the wiki page that indirectly hints at this being possible because I found it some time ago when I had to do prefix translation, but I can't find it anymore.

nftables is capable, but its documentation makes me sad. It's unbeliveably bad.

Nftables reaches 1.0

flussence — Wed, 01 Sep 2021 18:17:05 +0000

I want to like nftables, honestly, but after years of using it it's still incredibly sharp and brittle for something that's supposed to someday supplant the firewall everyone currently uses.

I'd write out a laundry list of the snags I hit regularly but it turns out one already exists (https://bugzilla.netfilter.org/show_bug.cgi?id=1461). I've got a fail2ban setup that barely works; sometimes after a few hours of operation it refuses to add an address to a set that doesn't contain it (this smells like unhandled hash collision... bug 1392?) — much worse is that sometimes adding a /32 is randomly and silently corrupted into a range covering half the ipv4 internet (bug 1438 - note that it's happened to me even though I'm not setting auto-merge). I've found that appending a literal "/32" to the input prevents the latter, but I don't understand why.

In spite of that I'll continue to use it because it's easier to reason about rules that look like C instead of COBOL. The fundamental design at least seems sound and none of my gripes are unsolvable, I just wish I didn't have to handhold it so much.

Nftables reaches 1.0

armijn — Mon, 30 Aug 2021 19:59:06 +0000

Yes, this timeline is right. McHardy's contributions took a very sharp dive around September 2011 and he was only sporadically active in the years after that, with almost nothing happening in 2012. Pablo's contributions didn't start increasing until after McHardy dropped out.

Nftables reaches 1.0

nybble41 — Mon, 30 Aug 2021 14:35:11 +0000

The full list of commands is in the nft(8) manual page; it would be too long to include in the --help output. If you're using iptables-nft (which the default iptables backend in Debian starting with Buster) then you can list your current iptables rules in nft syntax with the command "sudo nft -s list ruleset".

Nftables reaches 1.0

pbonzini — Mon, 30 Aug 2021 13:22:44 +0000

I have never done serious C++, but I think the issue there was that the error messages were overly precise and expanded the same template typenames over and over. At some point a couple tweaks were made, teaching the compiler about default template arguments and typedefs.

In C, the problem was abysmal error recovery, causing dozens of cascaded errors for a single missing semicolon or fat-fingered type name (such as "intt" or "unsgined char"). With a recursive descent parser it's relatively easy and maintainable to add heuristics that look ahead and insert missing tokens or fix things up as necessary. For example if you see two consecutive unknown identifiers, it's likely that the first is a misspelled type and the second is a variable name. With some luck, that will remove a lot of errors involving that variable, because the compiler now knows about it and treats it as declared.

Nftables reaches 1.0

evgeny — Mon, 30 Aug 2021 11:22:45 +0000

Writing and maintaining a complex FW config by hand is really a pain - especially when more than one firewall is involved and part of the rules must be kept in sync. Long ago, I started using fwbuilder. There is no support for nftables yet, but hopefully, that will change once nft becomes mainstream.

Nftables reaches 1.0

taladar — Mon, 30 Aug 2021 09:13:42 +0000

I just had a look at the CLI command nft and it still seems extremely unpolished

When I call ntf --help I get

> Usage: nft [ options ] [ cmds... ]
> [...]

but not a single command is listed in the help output, nor another command/option that would display that information.

When I try ntf help I get

> Operation not permitted (you must be root)
> Error: syntax error, unexpected newline, expecting string
> help
> ^

which seems like a weird mix of errors and also "unexpected newline" is an odd error to emit for commandline parameters, not to mention that it is far too low level in general.

There is also no obvious option in the --help output to list the currently active ruleset.

On top of that, since firewalls are quite complex we will be unlikely to maintain an iptables and an nftables version of our rulesets in our Puppet configuration management so a working and usable and fully featured version will have to be part of the oldest distros we use before it is even something to consider, so I would imagine nothing will happen before about 2030 since the current version doesn't really look usable yet.

Nftables reaches 1.0

carORcdr — Mon, 30 Aug 2021 06:46:27 +0000

"The nftables project to replace the kernel's packet-filtering subsystem has its origins in 2008, but is still not being used by most (or perhaps even many) production firewalls. "

Glad to see a substantive article on nftables and iptables. Do you have any numbers on the use in production firewalls?

In Rusty's words:

When your Linux box is the only thing between the chaos of the Internet and your nice, orderly network, it's nice to know you can restrict what comes tromping in your door.

Rusty Russel, Linux IPCHAINS-HOWTO, v1.0.8 (2000-07-04)

Nftables reaches 1.0

moorray — Sun, 29 Aug 2021 13:49:17 +0000

> McHardy decided he had more interesting opportunities to pursue in courtrooms. In 2013, though, Pablo Neira Ayuso restarted the project

Is this timeline right? I remember wondering if Patric got unhinged *because* Pablo’s implementation got picked over his.. The quote makes it sound like Pablo came after. It was before my time tho.

Nftables reaches 1.0

johill — Sun, 29 Aug 2021 07:43:22 +0000

I don't think that's how it works - it wants to compile iptables (not nftables) _rules_, but as far as I can tell it has a separate userspace etc. that does all of that, rather than doing a sort of "VM to VM" translation in the kernel I was thinking of (NFT VM to BPF VM)

Nftables reaches 1.0

nilsmeyer — Sun, 29 Aug 2021 07:12:41 +0000

According to the LWN bpfilter article this is already possible with iptables:
https://lwn.net/Articles/747551/

Under: "Bringing in BPF"
> One of the core design features for bpfilter is the ability to translate existing iptables rules into BPF programs.

Nftables reaches 1.0

josh — Sun, 29 Aug 2021 03:59:26 +0000

I definitely like nftables better than iptables, both for atomicity and for syntax.

But I do wish the documentation was much better, especially the documentation for the kernel-to-userspace interfaces.

Nftables reaches 1.0

Paf — Sat, 28 Aug 2021 21:24:48 +0000

My experience with C++ errors around 2010-2011 (with whatever was in Ubuntu at the time) was there was a lot of multi-page spew when using even fairly simple templates?

Nftables reaches 1.0

pbonzini — Sat, 28 Aug 2021 20:25:34 +0000

> gcc error messages from the era before llvm,

Ahah, that's actually a coincidence. GCC error messages for C were bad mostly due to the usage of yacc for the parser. When the parser was rewritten as recursive decent in 2004 by Joseph Myers that laid the foundation for improving error recovery. They then finally improved when GCC developers including myself got fed up of a few particularly egregious cases[1][2].

But competition with llvm wasn't particularly involved. In fact for C++ (which used recursive descent since before clang was started) error message quality has always been comparable to clang.

More recently (and long after I had stopped working on GCC), David Malcolm did a huge amount of work on caret diagnostics, where GCC's front ends were indeed lagging behind. But that's a different story.

[1] https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg0261...

[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2010-11/msg0180...

Nftables reaches 1.0

hailfinger — Sat, 28 Aug 2021 15:41:36 +0000

I had the questionable idea to set up a nftables based packet filter on various Debian Buster systems in 2020/2021 because nftables was declared to be the future. Lessons learned:
- The syntax is nice once you get used to it and I think most of it is more easily readable due to the structure
- The documentation was incomplete, especially for NAT
- If the documentation says that two ways to specify a rule are equivalent you should verify that instead of blindly rewriting working rules
- Concatenations are cool, but rarely work
- Order within in a single rule matters sometimes
- Combining the same rule from "table ip nat" and "table ip6 nat" into "table inet nat" only works in some cases
- If your kernel and the nftables userspace are not the same age you will run into problems, so either upgrade both or none, this may be different now that 1.0 is released
- Kernel 5.10 is roughly where most of the interesting functions start working if your userspace is new enough and nftables 0.9.6 (Buster Backports) is similarly a point where things start working better
- On Debian Buster without backports the whole thing is really painful, it's manageable with backports
- Priorities as keywords (introduced in 0.9.6) instead of priorities as numbers helps a lot with readability compared to older versions
- Error messages exist, but in netfilter 0.9.6 (from 2020) they were as helpful as gcc error messages ("error: expected ‘asm’ or ‘__attribute__’" instead of "missing semicolon") from the era before llvm, they are a bit better now

Overall, I think nftables has a nice future ahead and I'm looking forward to testing nftables 1.0.

Nftables reaches 1.0

wtarreau — Sat, 28 Aug 2021 06:47:14 +0000

In my opinion it has significantly improved over the years. I'm using it at home as well and it's way better than iptables. There are some places where you still can't merge IPv4 and IPv6 rules, resulting in some duplication effort but I found that it remained reasonable (though more unification would always be welcome of course).

The really nice thing compared to iptables is the instant and atomic load of the rules. No more situation where the nat table loads while the filter table fails etc. And the ability to define objects supporting lists about everywhere (ports, hosts etc) is great. I used to do that using scripts requiring a more complex language to automatically produce iterations. Now it is natural in the config language.

What still really annoys me is the lack of command-line help. I promised Pablo I would some day send him a patch for this but still failed to find sufficient time to work on it. Having to go to the wiki to figure you need to type "nft list rulesets" after not having used it for 2 months is pretty annoying, especially when you've been used to "iptables -h" providing very detailed syntax information. But this minor user-interface aspect aside, nftables is a great technology that is far closer from the spirit of traffic filtering than ipfwadm, ipchains or iptables could be, making it extremely user-friendly.

It's difficult to adopt it, but it's really worth it. Most of the effort is to convert the existing config. I would strongly encourage new firewall deployments to start with nftables, as it will be much easier than iptables for the first setup, an will not require any conversion.

Nftables reaches 1.0

jkingweb — Fri, 27 Aug 2021 22:54:53 +0000

I set up the firewall on my home server using nftables as a learning exercise circa 2016 or thereabouts after my ISP deployed IPv6 service, with no significant prior experience in packet filtering. I found the experience decent-but-finicky, with some disappointing duplication of effort to handle both IPv4 and IPv6.

I'm not sure what documentation I was following at the time; it may have led me down suboptimal paths, or things may have improved in the years since. I'll have to give it another look!

Nftables reaches 1.0

aszs — Fri, 27 Aug 2021 18:11:00 +0000

As amusing as that would be, it doesn't seem likely given https://lwn.net/Articles/858173/, for better or worse...

Nftables reaches 1.0

johill — Fri, 27 Aug 2021 15:57:48 +0000

Couldn't you kind of compile NFT to BPF?

Today NFT has a whole bunch of 'eval' methods, so to compile to BPF you just need to have a function that returns a few BPF instructions instead. Where not implemented, provide a BPF helper function that calls the existing eval function from BPF.

It doesn't even seem that hard, and if you implement the most commonly used 'eval' methods directly and then send the program through the compiler you'll probably already win something?

Nftables reaches 1.0

magfr — Fri, 27 Aug 2021 15:46:32 +0000

I suppose it was inevitable. BPF is used for absolutely everything in the kernel with one exception:
Packet filtering.