Nftables: a new packet filtering engine

Posted Mar 24, 2009 23:24 UTC (Tue) by fuhchee (guest, #40059)
In reply to: Nftables: a new packet filtering engine by clugstj
Parent article: Nftables: a new packet filtering engine

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

And only one third the fun.

to post comments

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