Quite a few advantages to nftables. I have been advocating for people to start learning it now instead of later. One of the primary issues I have seen in systems from a sysadmin perspective is poorly configured iptables. I disagree with all the abstractions that make it "easier" but result in more misconfigs. Besides improvements I expect to filter back over to linux from the dragonfly bsd netstack, nftables is one of the biggest moves in a while. Next up, routing engines like Cjdns, but that's a different discussion.
From the nftables wikipedia:
"...iptables firewalling code, which has protocol awareness built-in so deeply into the logic that the code has had to be replicated four times—for IPv4, IPv6, ARP, and Ethernet bridging—as the firewall engines are too protocol-specific to be used in a generic manner.[10]
The main advantages of nftables over iptables are the simplification of the Linux kernel ABI, reduction of code duplication, improved error reporting, and more efficient execution, storage and incremental changes of filtering rules. Traditionally used iptables(8), ip6tables(8), arptables(8) and ebtables(8) (for IPv4, IPv6, ARP and Ethernet bridging, respectively) are intended to be replaced with nft(8) as a single unified implementation, providing firewall configuration on top of the in-kernel virtual machine.
nftables also offers an improved userspace API that allows atomic replacements of one or more firewall rules within a single Netlink transaction. That speeds up firewall configuration changes for setups having large rulesets; it can also help in avoiding race conditions while the rule changes are being executed. Also, a planned compatibility layer is going to provide translation of already existing iptables firewall rules into their nftables equivalents."
I use and recommend nftables, and while it's very usable I also think it's important to acknowledge that nftables is not yet at full feature parity with iptables.
All the basics are there and I'm already using it for my home firewall so don't get the wrong idea, but if you use any of the more interesting iptables features you might want to test those features out in nft before committing yourself to it. Your kernel version is key.
Also, let me extend a Thank You to everyone who's worked to make nftables a reality! My favorite parts are atomic ruleset replacement and the ability to do 'log and drop' in one rule.
Damn, it does not support NETMAP which I use on one of my machines. :( Maybe I could work around that though by rethinking how I rewrite the addresses. But either way I will start using nftables everywhere I can after upgrading to stretch.
But that is nothing at all like NETMAP, unless I use a script to generate a map for all 65k addresses in the subnet. Maybe you are thinking of IP sets?
These are all very kernel-orientated improvements. My guess is that a 'common' user (whatever that may be), cares very little about the efficiency or improved storage benefits of a new firewall command.
As for users with poorly configured iptables, fair enough but the latest and greatest new firewall toolset will give ample opportunity to create new poorly configured nftables too.
This is all coming from a bitter old sysadmin who has had to re-tool through ipfwadm, ipchains and iptables, and who knows what else in the coming future. I'm sure each iteration has brought improvements to newer setups and advanced networking, but this smells like just another "let's re-write some tools" project.
ipfwadm - pre 1996 (I think?)
ipchains - pre 1998 according to wikipedia
iptables - 1998 according to wikipedia
nftables - 2014
More churn than javascript frameworks.
Realistically iptables isn't going anywhere, though I'm def looking forward to nftables being more widely used. My main interest is around the newer setups and advanced networking, but if you're not dealing with one of them, then you 1) probably won't have to port anything to nftables this decade, and 2) could probably get away with using a higher level tool like UFW
iptables the kernel component might run on top of netfilter (i.e. there are various `nf_` modules loaded in my kernel, some of which are being used by `iptables_` modules), though I doubt iptables the user space component relies on ntf/nftables the user space component. Could be wrong I guess (comment and I shall edit this out if I'm wrong)
As an aside, that's one of the nice things about nftables. No more conflating the user space binary, the user space format, the kernel module and so on.
My understanding is that iptables and nftables are both user interfaces to configure rule-sets in the NetFilter code, though I think that glosses over some important bits.
I can't really speak to nftables, as I've only used it in passing once or twice (I don't do nearly as much sysadmin work anymore), but once you've experienced OpenBSD's PF it becomes immediately obvious how poor of an abstraction iptables is. Anything which brings the Linux firewall capabilities and configuration closer to what is achieved through PF is a good thing in my book, and from what I've gleaned nftables goes some way towards this.
I'm kind of looking forward to nftables, all the underlying technology driving it shows good learning from the weaknesses of iptables. Last time I looked, though, documentation was kind of nasty. Hopefully that's improved.
One random thing I stumbled across with docker recently, is docker swarm requires a version of itpables that does locking (not entirely sure why, but it actually verifies that locking can happen, so presumably they got burned by it at some stage). The version of iptables stock from RHEL 6 (and thus CentOS 6) doesn't support it. So if you want to run docker swarm, RHEL6 and derivatives are a no go (other than Oracle Linux which seems to be determined to be as docker friendly as possible)
From the nftables wikipedia:
"...iptables firewalling code, which has protocol awareness built-in so deeply into the logic that the code has had to be replicated four times—for IPv4, IPv6, ARP, and Ethernet bridging—as the firewall engines are too protocol-specific to be used in a generic manner.[10]
The main advantages of nftables over iptables are the simplification of the Linux kernel ABI, reduction of code duplication, improved error reporting, and more efficient execution, storage and incremental changes of filtering rules. Traditionally used iptables(8), ip6tables(8), arptables(8) and ebtables(8) (for IPv4, IPv6, ARP and Ethernet bridging, respectively) are intended to be replaced with nft(8) as a single unified implementation, providing firewall configuration on top of the in-kernel virtual machine.
nftables also offers an improved userspace API that allows atomic replacements of one or more firewall rules within a single Netlink transaction. That speeds up firewall configuration changes for setups having large rulesets; it can also help in avoiding race conditions while the rule changes are being executed. Also, a planned compatibility layer is going to provide translation of already existing iptables firewall rules into their nftables equivalents."