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
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 (subscriber, #18366)
Posted Mar 24, 2009 19:45 UTC (Tue) by patrick_g (subscriber, #44470)
Posted Mar 24, 2009 19:45 UTC (Tue) by flewellyn (subscriber, #5047)
Posted Mar 24, 2009 19:51 UTC (Tue) by quotemstr (subscriber, #45331)
Posted Mar 24, 2009 20:08 UTC (Tue) by flewellyn (subscriber, #5047)
This was in 2005, so I will grant that things may have changed since then.
Posted Mar 24, 2009 20:11 UTC (Tue) by Alan_Hicks (subscriber, #20469)
Posted Mar 25, 2009 13:54 UTC (Wed) by rvfh (subscriber, #31018)
Posted Mar 24, 2009 20:00 UTC (Tue) by Alan_Hicks (subscriber, #20469)
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.
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.
 There's an out-of-tree module for iptables that allows binary lists and functions similarly to pf's tables I'm told.
 As compared to iptables. I have not looked at the userspace component of nftables at all.
Posted Mar 25, 2009 11:58 UTC (Wed) by osma (subscriber, #6912)
What I particularly like (as a sysadmin) in pf are two things:
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.
Posted Apr 2, 2009 10:39 UTC (Thu) by jengelh (subscriber, #33263)
You can do the same with iptables-restore.
Posted Mar 24, 2009 19:18 UTC (Tue) by clugstj (subscriber, #4020)
I know nothing about this particular case, but many times, the effort to port something is nearly the same as re-inventing it.
Posted Mar 24, 2009 23:24 UTC (Tue) by fuhchee (subscriber, #40059)
And only one third the fun.
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