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.
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."
More details can be found here:
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.
Edit: Added link to actual feature comparison
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
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
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.
4 in 20 years. No.
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)
This is terrifying, the possible security vulnerabilities which this could spawn are endless.
> improvements I expect to filter back over to linux from the dragonfly bsd netstack
I have no clue what this refer too.
 webm http://ftp.nluug.nl/video/nluug/2016-05-26_vj16/Zaal2/21%20-... or https://www.youtube.com/watch?v=0wQfSfDVN94
 webm http://ftp.nluug.nl/video/nluug/2016-05-26_vj16/Zaal3/3%20-%... or https://www.youtube.com/watch?v=FXTRRwXi3b4
IIRC that is due to change imminently, as Stretch entered full feature freeze in February in preparation for release, and I've not heard of any massive show-stoppers since, but if you install "stable" right now you'll get Jessie (release 8.x) not Stretch (r9).
While I'm excited to hear about a simplified abstraction at the kernel level, for most setups I've had to configure, I really like the highlevel abstraction it provides.
I am not yet ready to learn a new tool, and this new tool does not have all the features as the old tool according to others commenting.
If you have to use it on a regular Linux box, I prefer UFW.
Though, it looks like nftables has finally a nicer syntax than iptables making wrappers like UFW unecessary.
Nftables is the replacement for iptables, not just the configuration of them.
Why would I want an edge security device running something like that?
I am open for switching to something else. Do you know anything good?
Can ufw use nftables as a back end? And/or is there a good clean and easy to understand explanation for how to use nftables and useful reference?
Is there a tool to help with common configuration tasks?
(imo) Nothing beats FreeBSD's IPFW when it comes to features, but OpenBSD is still king of syntax/usability.
ipfw has better performance, too.
I guess what we need is some lex/yacc work to make a pf.conf syntax work with ipfw.
Largest issue is pf is "lastmatch wins" (copied from ipfilter, and a mistake that even Henning admits) and ipfw is “first match wins”.
pfSense makes all of rules "quick" to workaround this issue.
So without a ton of work, we could get the syntax (via an external package), but the semantics of existing pf.conf would be more difficult.
The rest is we would need the equivalent of pfsync.
A complex iptables ruleset is difficult to understand, while a pf.conf almost reads like prose.
Feature-wise, netfilter is richer, if only for the fact that there are more contributors. On the other hand, iptables and other frontends I've had the opportunity to use (ufw, firewalld) down right suck. Did I mention that most HOWTOs regarding iptables lead you down a wrong path, which is writing your ruleset as a shell script which calls the iptables / ip6tables binaries. If you fat finger a rule and run the script, you'll end up loading half the ruleset (which could be harmless, but you could very well lock yourself out a server if doing this remotely). PF rules are loaded atomically using the pfctl tool: either you get the whole new ruleset inplace, or you keep the old one. I believe the same behavior can be obtained with iptables-save/restore.
PF feels much more coherent and also has fantastic documentation. The OpenBSD FAQ as well as the pf.conf and pfctl cover most things you need to know regarding PF (there's also a book by Peter Hansteen called "The Book of PF" that is an excellent resource).
netfilter on the hand feels much more "stitched together". You want to configure IPv4 rules ? iptables. IPv6 ? ip6tables. You have rules tracking state? conntrack. The documentation around each of these tools is of varying quality. The one I'm having most trouble with is "tc", but that may because I don't grok queueing/traffic shaping/QoS yet. I have no experience with the latter on OpenBSD so I can not comment.
I don't trust any box running 300 out-of-date packages plus a PHP GUI, so my edge device is simply a dual-ethernet 8W device that runs OpenBSD with the following rules:
set skip on lo0
pass out on en0 inet from en1:network to any nat-to (en0) // source NAT
Instead, all we get is a vague 'the system is more configurable than in iptables' and 'the syntax is much better than in iptables' (like what good is that to someone who already has iptables set up? The last thing people want to do is mess with firewall rules on a working system)
Yes, I know that Debian is FOSS and I can help improve it, but why introduce a whole new firewall system where the 'Moving from iptables to nftables' docs are pages and pages of shell commands? Wouldn't some kind of automated update, to help common use cases, be a sensible thing to include in such an update? (Maybe such a thing exists, but the page doesn't bother to tell me about any such thing).
Instead of going on about how to set up nftables from scratch, perhaps they should focus a little more on 'I have a system using your older recommended firewall, what do I need to do to keep things working?'
Because you don't need to do anything: you can continue to use iptables. Even in the future, when iptables is removed from kernel, you can continue to use iptables syntax, since iptables user-space program will simply start to output nftables (a.k.a. iptables will be a symbolic link to this: https://wiki.nftables.org/wiki-nftables/index.php/Moving_fro...). nftables is for people who are deploying new systems and want a sane configuration file instead of iptables mess, and at the same time offers improved error messages and better performance, while being more flexible.
So if you want you can continue to use iptables for the future. No need to be snark about OP.
I think the author could have emphasised that more.
«Yes, nftables replaces iptables. You are highly encouraged to migrate from iptables to nftables.» sounds a bit too much like "expect iptables to stop working in another release or two".