Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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 (subscriber, #18366)
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.
Posted Mar 27, 2009 4:54 UTC (Fri) by rusty (✭ supporter ✭, #26)
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 :)
Posted Mar 27, 2009 5:21 UTC (Fri) by quotemstr (subscriber, #45331)
Someone was supposed to write the cool GUI tool
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
Posted Mar 29, 2009 19:49 UTC (Sun) by job (guest, #670)
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.
Posted Mar 27, 2009 18:06 UTC (Fri) by kaber (subscriber, #18366)
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 :)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds