New in Debian stable Stretch: nftables | Hacker News Reader

New in Debian stable Stretch: nftables

ral-arturo.org

214 pointsmarksamman59 comments

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."

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

Plus, current iptables runs on top of nftables, doesn't it?

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.

> More churn than javascript frameworks.

4 in 20 years. No.

I believe the poster you are replying to meant that with a touch of sarcasm.

Blatant sarcasm.

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 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.

More details can be found here:

- https://wiki.nftables.org/wiki-nftables/index.php/Supported_...

- https://wiki.nftables.org/wiki-nftables/index.php/List_of_up...

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

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.

Have you seen these examples yet? It's not the exact same but maybe you can use it to the same effect?

https://wiki.nftables.org/wiki-nftables/index.php/Maps

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?

can you expand on

> improvements I expect to filter back over to linux from the dragonfly bsd netstack

I have no clue what this refer too.

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)

Speaking of code duplication, why does nftables have its own byte code and interpreter. Instead of using bpf?

> the code has had to be replicated four times—for IPv4, IPv6, ARP, and Ethernet

This is terrifying, the possible security vulnerabilities which this could spawn are endless.

Pablo Neira Ayuso, maintainer of nftables, in May 2016 gave a presentation Goodbye iptables, Hello nftables [0] and a handson Workshop [1] at the nluug.nl spring conference.

[0] webm http://ftp.nluug.nl/video/nluug/2016-05-26_vj16/Zaal2/21%20-... or https://www.youtube.com/watch?v=0wQfSfDVN94

[1] webm http://ftp.nluug.nl/video/nluug/2016-05-26_vj16/Zaal3/3%20-%... or https://www.youtube.com/watch?v=FXTRRwXi3b4

A good answer to the question "why move to nftables?"

https://developers.redhat.com/blog/2016/10/28/what-comes-aft...

It is worth noting that "Stretch" (Debian Release 9.x) is not yet released as "stable" and as such is not currently recommended for production use. It is currently Debian Testing, not Debian Stable, with "Jessie" (release 8.x) carrying the "Stable" moniker.

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).

Does anyone know if [Shorewall](http://shorewall.org/) has plans to support nftables, or is it staying on iptables for now?

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've used shorewall for some time. As a matter of fact, installed it on my recent laptop as well (archlinux). But till now I didn't like quite often config file format changes, because of which I needed to figure out how to change current config to match the latest one. PF in this regard was more consistent and more readable and didn't requre to use anything on top of it. Then again - I never needed very complex FW rules.

There was a question about that on the list and the answer from shorewall author was "no".

Will we still get the choice to use iptables instead of nftables? I do all the sysadmin stuff for my own servers, and I prefer stability on the tool front.

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.

Yes, you will still be able to use iptables in stretch. I am running stretch on my laptop and can use iptables just fine. I also suspect that the deprecation of iptables is something for a quite far off future, if it ever happens.

I still prefer Vyetta's interface. It can be used in VyOS(https://vyos.io).

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.

Those are just tools that configure the system, in both cases iptables.

Nftables is the replacement for iptables, not just the configuration of them.

I understand what you mean. I was strictly referring to the user interaction with the firewall. Nftables seems easier than iptables, but not as easy as UFW or VyOS.

Doesn't VyOS run an EOL operating system with core packages that are years out of date? I spun up a test server to check it out. I don't see anything on their website about updating it and running "apt-get update/upgrade" just throws errors.

Why would I want an edge security device running something like that?

you can add debian repos but be careful you may break something updating packages. They are currently working on an update to the current version 1.1.7 to 1.2.0. Development was pretty active but as of the last year it's been slower.

Do you think running 1.1.7 is a bad idea security wise?

Yeah. They are working on transitioning to Jessie. But not sure when this will happen.

I am open for switching to something else. Do you know anything good?

It seems to me like it would be easier to build a good UI on top of nftables than it would be to build the same thing on top of iptables. For example support for atomic rule replacement is something which should benefit higher level UIs.

ufw is severely limited.

I got excited for a moment, but debian stretch is not released as stable yet? https://www.debian.org/releases/

IIUC nft tools also provide a way to write the rules in a file and atomically replace the current ruleset with an updated one. To do this with iptables, I've had to use ferm http://ferm.foo-projects.org/ , which, even if it is a nice tool, is a bit of a badaid on top of iptables. I've always liked pf.conf & pfctl, and nft tools seem to be a step in that direction.

Sounds better implementation wise but what about the interface for sys admins? It seems the syntax is complex enough that you need to copy a file to start.

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?

Still, nothing beats OpenBSD's pf

Could you explain what's pf pros and cons ? better semantics ? syntax ?

Can't answer the first question, but for me the pf syntax for firewall rules, NAT and inbound port forwarding is much simpler.

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
    block all
    pass out on en0 inet from en1:network to any nat-to (en0) // source NAT

Human readable syntax. Documentation.

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.

firewalld: I know, let's take the already somewhat user unfriendly interface of iptables AND ADD XML!

Basically I like the pf's syntax. As already mentioned - it reads like a prose

You could use the same argument in favor of COBOL.

As long as nobody attempts implementing a banking system in pf

OpenBSD's pf doesn't handle layer2.

(imo) Nothing beats FreeBSD's IPFW when it comes to features, but OpenBSD is still king of syntax/usability.

Upvote.

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.

Never needed to do something with layer2. I used it mostly for educational purposes for my home network. Can you name some real world examples when OSI layer2 filtering is needed?

I use layer 2 filtering on my home network in order to get direct internet access without going through my "mandatory" ISP-provided gateway that authenticates the port with 802.1x EAP-TLS.

mesh networks that use a layer 2 routing protocoll - or if you have VPNs that use layer2 and you want to filter the clients on the VPN server bridge.

Containers connected to a common bridge, for which you want to restrict traffic (between them). You have to do that at L2.

https://developers.redhat.com/blog/2017/04/11/benchmarking-n...

I still don't understand why $firewall isn't simply a psuedo fs like /proc and control is simply managing trees or chains using basic command line tools.

Well if you are hardcore you could probably hack some fuse abstraction that talks to netlink and does what you want. However it's probably not that straight forward to map nftables to directory/files.

This page is terribly written, it gives almost no information about why nftables is better than iptables. What features does it have? What can it do that iptables can't? The page can't be bothered to tell us.

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?'

> 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.

It'd be useful if the page would tell users this!

That's good to know.

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".

Reply on news.ycombinator.com