Nftables probably first came to my attention in comments on my recent entry about how I don't understand Linux NAT as well as I should, although I may have heard of it in passing before then. At least in theory, it's the next generation replacement for iptables, which is broadly held to have some architectural issues and limitations. In practice, who knows, since nftables has been in progress for some time now (per the history section of the Wikipedia page). My current interest was sparked by running across Florian Westphal's recent blog entry introduction to nftables. Okay, particularly I got interested because of this statement:

The special 'route' type tells the netfilter core that it should perform a new route lookup after the packet has traversed the chain. [...] In the old iptables world, this property is hard-coded into the mangle table; in nftables, it is a base chain property.

I've had a certain amount of heartburn with the inflexibility of when iptables (re)routes packets, as discussed here. Being able to fix all of that is a clear win for nftables.

But that's not my only iptables problem. To be honest, my current set of iptables rules have slowly turned into a kind of a mess. Some of them are automatically generated, not particularly well, from a high level language I glued together a very long time ago because writing iptables rules by hand was tedious. Others have been glued on by hand since then, sometimes with hacks. And the whole collection is IPv4 only because making them work for IPv6 too requires too much changing things and manual duplication even though I would be happy to just replicate all the blocks over.

(This has led to a patchwork quilt of using various modern features like ipsets only in some situations. If I was redoing my iptables rules from scratch, I would make a lot more use of sets and rule chains than I did in the past. Past me didn't really get the advantage of putting things in custom chains and ipsets were years in the future when I wrote the initial collection.)

I've toyed with the idea of razing everything to the ground and rebuilding my rules with something like FireHOL, but as usual it seems like a lot of work to wind up back at the status quo. Razing everything to the ground and rebuilding it with nftables at least offers the appealing prospect that the result could be better than I started with; more featureful, easier to manipulate in various ways, and it would finally be able to easily do some things that I've always wanted to be able to make work.

(nftables seems to have quite powerful and general capabilities in the area of sets and (hash)maps, ones that seem to be in the area of OpenBSD pf's capabilities.)

Finally, I have to admit another motivation: I don't really like iptables. To make an analogy, iptables is basically firewall rule assembly language. You can do a lot in assembly once you know how, but writing it is always verbose and tedious because you have to spell out absolutely everything in detail. This assembly nature is why I wrote my program to auto-generate iptables rules from a higher level language way back when (and why I've kept it even as things became increasingly creaky and awkward). Nftables doesn't seem to be the kind of high level thing that OpenBSD pf is, but at least it has a bunch of powerful abstractions (including sets) that hold out promise to reduce the tedium and verbosity.

(My rule-generation program is so old that it originally generated ipchains rules.)