Nftables: a new packet filtering engine

Posted Mar 24, 2009 18:51 UTC (Tue) by quotemstr (subscriber, #45331)
Parent article: Nftables: a new packet filtering engine

Yet another filtering language? Granted, the system looks a little less imposing than iptables, and that's a good thing.

But there's already a perfectly good, free, and Free filtering solution that's portable to quite a few operating systems. Why not just port pf to Linux?

I can't help but think that nftables is a case of NIH syndrome.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 19:11 UTC (Tue) by kaber (guest, #18366) [Link] (9 responses)

It is a lot less flexible than even iptables. Less features is always a hard sell. It would also need massive changes to be able to represent an iptables ruleset, so there's really nothing to gain from it.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 19:45 UTC (Tue) by patrick_g (subscriber, #44470) [Link]

>>> Less features is always a hard sell

Could you please tell us wich features are missing in pf ?

>>> there's really nothing to gain from it

You gain a very modern and efficient packet filter with a good and clear syntax. pf is part of OpenBSD, FreeBSD, NetBSD, DragonflyBSD and I think it would be wise to, at least, consider and discuss this option.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 19:45 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (4 responses)

Too true on the "less flexible" bit. PF is a nice idea, but the OpenBSD folk did not add nearly as much flexibility to the system as iptables offers. Doing NAT with it is easy enough in the default setting, but more complex stuff, I found painful.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 19:51 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (3 responses)

What exactly were you trying to do?

Nftables: a new packet filtering engine

Posted Mar 24, 2009 20:08 UTC (Tue) by flewellyn (subscriber, #5047) [Link] (2 responses)

Route between two NATted LANs and the WAN, with port forwarding and connection tracking. It got hairy when I tried to set up the connection tracking between the two LANs. The WAN-to-LANs tracking wasn't too hard.

This was in 2005, so I will grant that things may have changed since then.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 20:11 UTC (Tue) by Alan_Hicks (guest, #20469) [Link] (1 responses)

Yeah, that's really pretty easy to do with pf. You should give it a look next time you need a firewall, particularly one with several different interfaces and needs.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 13:54 UTC (Wed) by rvfh (guest, #31018) [Link]

How about a PF to Nftables translator, along with the iptables to Nftables translator? Isn't that one of the real strength of Nftables, flexibility?

Nftables: a new packet filtering engine

Posted Mar 24, 2009 20:00 UTC (Tue) by Alan_Hicks (guest, #20469) [Link] (2 responses)

Could you please expand on the "lot less flexible than iptables" comment? In my experience, I've found it to be far far more flexible than iptables. With the ability to update tables in pf from userspace, not to mention the insane performance boost from tables over individual rules[0], it's not only more flexible but outperforms iptables.

Setting up class-based or priority-based queues is also ridiculously easy with pf and included right in the code, not as some add-on. One of the features mentioned in the article about nftables is the ability to easily jump to a different rule or class of rules. This was solved years and years ago by pf with the use of anchors.

As far as features go, I just gave you three. There are plenty more (scrubbing packets and antispoof instantly come to mind), but perhaps the best is the sane and clearly readable syntax for pf, not to mention the more powerful pfctl tool[1].

As for porting, pf originated with OpenBSD and has been ported to FreeBSD, NetBSD, and Dragonfly BSD. I'm not programmer though, so I can't say for certain how easy it would be to port to Linux, but my understanding is that there are some fairly radical architecture differences in those four BSDs, particularly in regards to the new off-shoot Dragonfly. I would make a SWAG that porting it wouldn't be any more difficult than writing an entirely new packet filter.

[0] There's an out-of-tree module for iptables that allows binary lists and functions similarly to pf's tables I'm told.
[1] As compared to iptables. I have not looked at the userspace component of nftables at all.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 11:58 UTC (Wed) by osma (subscriber, #6912) [Link] (1 responses)

What I particularly like (as a sysadmin) in pf are two things:

the configuration syntax is concise, very readable and it is easy to do infrequent adjustments without having to look at the documentation
after editing the ruleset file, the pfctl tool can be used to do a live update of the kernel ruleset without e.g. breaking existing connections

I don't have an opinion on whether to port pf or not, but I hope that whatever replaces iptables will consider these features. It sounds like the nftables approach has the potential for these, as the ruleset processing is done mostly in user space.

Nftables: a new packet filtering engine

Posted Apr 2, 2009 10:39 UTC (Thu) by jengelh (guest, #33263) [Link]

>after editing the ruleset file, the pfctl tool can be used to do a live update of the kernel ruleset without e.g. breaking existing connections

You can do the same with iptables-restore.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 19:18 UTC (Tue) by clugstj (subscriber, #4020) [Link] (6 responses)

"just port pf to Linux"

I know nothing about this particular case, but many times, the effort to port something is nearly the same as re-inventing it.

Nftables: a new packet filtering engine

Posted Mar 24, 2009 23:24 UTC (Tue) by fuhchee (guest, #40059) [Link] (5 responses)

the effort to port something is nearly the same as re-inventing it

And only one third the fun.

Nftables: a new packet filtering engine

Posted Mar 25, 2009 3:26 UTC (Wed) by kaber (guest, #18366) [Link] (4 responses)

Indeed :)

To clarify: I certainly did consider the way pf does things and there are quite a few things I like better than in iptables, starting with having a language specifically designed for filtering rules, compared to the quite primitive shell command invocation mainly used with iptables.

But porting the kernel side doesn't make sense at all. The code structure doesn't match how things are done in the Linux kernel, the API doesn't match what we want, its tightly coupled to a different NAT and state tracking system and even basic things like rule evaluation order are different from what iptables does. There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it.

Nftables: a new packet filtering engine

Posted Mar 27, 2009 4:54 UTC (Fri) by rusty (guest, #26) [Link] (3 responses)

The thing I really like about pf is that it's an all-in-one control. No separate tools for traffic
shaping and filtering, which is so fragmented in Linux. But I haven't used it in anger.

That said, I feel they've made the same mistake as just about everyone else in conflating NAT
and filtering (the two shouldn't be related: changing your NAT rules should not imply a change to
your filtering rules unless you're being very tricky).

But I always intended iptables as the assembler language of firewalls. Someone was supposed
to write the cool GUI tool which monitored traffic, let you shape and firewall it without touching
this stuff. I'm still waiting :)

Nftables: a new packet filtering engine

Posted Mar 27, 2009 5:21 UTC (Fri) by quotemstr (subscriber, #45331) [Link] (1 responses)

Someone was supposed to write the cool GUI tool

Oh, people have written neat front-ends. But because there was no de facto standard rule compiler distributed with iptables, all the tutorials, guides, and so on focused on what was universal, direct iptables manipulation. Since everyone was familiar with raw iptables, front-ends were seldom used, and seldom distributed.

pf also has a fairly primitive kernel-side "assembly language", but because pfctl is the way everyone manipulates the kernel state, nobody notices the difference between pf.conf and the raw rules as seen when reading the firewall state back from the kernel.

If, from the start, iptables had an official and useful front-end language tied to exactly the same kernel architecture, I doubt we'd be talking about a replacement today.

changing your NAT rules should not imply a change to your filtering rules unless you're being very tricky

It's still very useful to be able to specify them in the same place. When writing filtering and NAT rules, we mentally track the path of a packet as it transits the network stack; since a packet is subject to filtering and address translation in sequence, it's useful to be able to specify the rules in the same place.

Nftables: a new packet filtering engine

Posted Mar 29, 2009 19:49 UTC (Sun) by job (guest, #670) [Link]

Another reason may be that few network professionals really wants a GUI tool. They want something that's readable yet concise, supports just the right amount of macro processing, and is easy to deploy on a large scale. It's not strange that Cisco is still highly regarded despite the fact that they never made a GUI tool that people actually use.

Most home users just use a web based configuration tool, and there are many capable ones. No waiting necessary, but that's a very different problem space.

Nftables: a new packet filtering engine

Posted Mar 27, 2009 18:06 UTC (Fri) by kaber (guest, #18366) [Link]

I agree, one more reason is that NAT rules affect connections, while filtering rules affect both packets and connections and are evaluated on a per-packet base.

iptables is, just like the kernel side of nftables, indeed the assembler of firewalling. Userspace is missing a compiler in my opinion though :) One of the differences is that nftables performs file-based parsing by default, so it can collect more information about the entire ruleset. So far it doesn't use much of that context, but I have some ideas for when the important parts are done :)