“The NetBSD Foundation is pleased to announce NPF, a new packet filter by Mindaugas Rasiukevicius. NPF is designed for high performance on multiprocessor machines, and for easy extensibility.”
“The NetBSD Foundation is pleased to announce NPF, a new packet filter by Mindaugas Rasiukevicius. NPF is designed for high performance on multiprocessor machines, and for easy extensibility.”
It looks to me that they started NPF from scratch.
Wait… What? Yet another packet filter in the BSD world? I understand the needs, but it might have been easier to work on the grounds of another packet filter (pf anyone?).
Well, if some guy wants to write a packet filter, I say, let him write a packet filter! Personally I think it sounds interesting; I have never used PF on a SMP machine (actually, I’ve pulled processors from OpenBSD / PF machines to save power) but the PF docs are pretty up front about SMP often not being helpful. If somebody’s enthusiastic about trying a different way, that’s great.
OpenBSD’s pf has gone through some significant restructuring as of late, there are changes with syntax and code.. and it uses several kernel API’s that make porting to the other BSD’s complicated.
If you want pf, use OpenBSD.. NetBSD/FreeBSD have an implementation somewhat equivalent to what was in the early 4x releases and the primary OpenBSD pf hacker considered them ancient.
FreeBSD has ipfw, ipf, and old pf.
NetBSD has npf, ipf and old pf.
I’m guessing they will tend to emphasize ipfw/npf instead of pf, especially considering the OpenBSD pf FAQ and documentation is largely incompatible for those users.
At least on FreeBSD, IPF is not updated all that often, and it’s generally frowned upon in an SMP environment.
Best supported packet filters really break down into:
FreeBSD: IPFW
NetBSD: NPF
OpenBSD: PF
I’m not sure about that order, OpenBSD’s pf is still well documented and the new syntax changes are quite easy to pick up for a long time user.
While I’m not fond of statistics, there are more people using OpenBSD over NetBSD as well, especially in the role of filtering/firewall.
Peter N. M. Hansteen also announced that the second edition of the “Book of PF” will be released by the time 4.8 is released.. it also traditionally covers the available pf implementations in the other BSD’s.
* http://marc.info/?l=openbsd-misc&m=128456424732391&w=2
* http://nostarch.com/pf2.htm
Edited 2010-09-15 20:44 UTC
I didn’t mean “order” as in FreeBSD is at the top and OpenBSD is at the bottom. I meant “on each of the BSDs, the best supported packet filter is …”
As in, on FreeBSD, the best supported packet filter is IPFW (PF is several major versions behind OpenBSD, IPF is all but abandoned, and neither work well on MP systems).
On NetBSD, NPF will be the default, as PF is several major versions behind and doesn’t work well on MP systems.
On OpenBSD PF is king.
Forgot about DragonflyBSD. They use PF as well, but they’ve done a lot of MP work on their network stack including the PF support.
Edited 2010-09-16 00:56 UTC
Right, my apologies, misinterpreted what you wrote. 🙂
I wonder how long it will take before FreeBSD gets a port of this.
That shouldn’t take long. 🙂
Edited 2010-09-15 17:50 UTC
This depends, a lot of people are forgivably ignorant about just how much each of the BSD’s have diverged.. it is still a considerable porting effort to bring things over from another project, although someone may indeed attempt this once NPF has matured.
Edited 2010-09-15 20:43 UTC
I’m using OpenBSD and PF at many places, from little routers for few computers up to hundrets clients in LAN. While it;s working generally good, there are problems. some limitations that are by default in kernel (like only 64 hfsc queues), that make it unusable in real enviroments. Then when You find some error (like pfctl crashing) and You ask for help on mailing list, they will tell You to use generic kernel. Also PF donot use SMP at all, so if You want to filter really many packets PF will be too slow because it will use only 1 core of Your PC. Well OpenBSD is sometimes greate, but it;s “stable” status is overrated i think. It’s good OS, but for past. Today world needs something better, and i hope, maybe some of this NPF will bring. Time to check it
Well, it’s clear OpenBSD is the most conservative among the free OSes.
It always has obsolete components when compared to Linux or even the other BSDs for certain “unneeded” features. However it always catches up eventually, after they have proved their worth.
If the project it’s still around by then, when most routers need more than one processor to do their job properly, there will be a quick update to PF and the kernel to make them really SMP clean. And up to the previous day the official stance will be that multi-core PF is stupid. That’s the way things work there, and the end result is usually good.
BTW, if you use a recent OpenBSD, you do use PF, you just don’t know. One warning in the nmap port is that you can’t do OS detection in OpenBSD because PF filters your own malformed packets.
This is trivia, but i had a quick look over OSNews and my eyes stopped on lithuanian name – wow, a guy from my country programmed it
The same fact caught my attention too:)
I ‘m not sure what that means about NetBSD or IPV6. I would think at this late juncture, that the lack of IPV6 in a new project would be considered a deal breaker for many people.
NetBSD supports IPv6, this new packet filter lacks support for IPv6.. which itself isn’t a big deal, OpenBSD’s pf lacked IPv6 initially.
Its just a bit concerning that as we are running out of IpV4 space, new networking apps are not written for ip v6, and it doesn’t seem to be that big of a deal to many people. OpenBSD’s pf was first written nine years ago. The lack of IPV6 back then, wouldn’t have surprised me.
Its just that a lot of networking gear out there doesn’t support ipV6, or only supports IPV6 at a reduced throughput than IPV4. Many Manufacturers of networking gear are really running a *BSD under the hood. So it would be *awesome* if the networking stack in *BSD treated IPV6 as the rule, rather than the exception.
One of big BSD IPv6 guys died a few years back, Jun-ichiro “itojun” Hagino.
There is no doubt that the IPv4 pool is quickly being exhausted, but there do exist some people who believe IPv6 is not the right solution.. mostly because there have been some problems found along the way that have taken away a lot of confidence.
No doubt someone will indeed work on IPv6 support for this new NetBSD packet filter, in fact I believe the BSD’s were among the first operating systems to receive an IPv6 stack from the KAME project.
When this developer started writing the new NPF implementation I doubt his intent was to exclude IPv6, it probably just made sense to prototype using the protocols he happened to be using on his own networks.
Each of the BSD projects have a long history of coming up with their own innovative approach to things, and while they share a history they have their own methodologies.
And contrary the popular belief, it is often BSD at the forefront of technological growth in the industry, especially in the area of networking.
Edited 2010-09-17 02:05 UTC
That’s not contrary to my belief, which is why I’m complaining about the lack of IPV6
pf code has become over the years kinda messy. The openbsd developers accepted this as a fact and are working towards a resolution.
http://www.openbsd.org/papers/asiabsdcon2010_pf/index.html
So, pf has complexity issues, doesn’t strive for portability outside of openbsd and isn’t exactly SMP friendly.
Sounds like there is space for a new packet filter.
Cheers.
It’s been a few years since I’ve used OpenBSD and FreeBSD (and perhaps things have changed), but back when I used the BSDs I felt that there was a vital need for a GUI interface to configure these packet-filtering systems. There are a number of GUI front-ends for Linux’s system (iptables), my favorite one being Guarddog because it makes it easy to target which ports you want to block. There are even simpler tools like Firestarter, but these don’t give you so many tweaking options – nevertheless, it’s adequate for 99% of desktop users.
If you’re building your own firewall from scratch, and you have programming skills, a GUI might not matter. But for dumb end-users like myself, spending hours or days trying to write firewall rules just isn’t worth the hassle – especially since I’m not good at it and thus may unknowingly leave a big hole in my firewall.
When I asked (again, years ago) on the OpenBSD mailing list about such a GUI front-end for PF, I was referred to a GUI tool which turned out to be anything but simple. It was basically a programmer’s GUI tool. Sorry that I can’t remember it’s name, but it was so complex that it was almost easier to write the packet-filtering rules in text mode.
Hopefully it’s all changed and now a simple GUI front-end for PF exists. Anyone have info on that?
Edited 2010-09-17 01:28 UTC
If you need one, you’re not the target audience.. the syntax is documented and being a “programmer” is not necessary to understand pf configuration, just an above average grasp of networking.
Having a GUI front end would reduce some of the benefits of pf, and the learning experience is rewarding, by choosing BSD you’re already making the choice to learn about the environment.. hopefully you’ll be actually taking the time to keep up regular maintenance of the system and not just putting it in a corner to forget about it.
Generally the idea is that making the process simpler is counterproductive, giving some an helpful GUI wizard only serves to let people who probably shouldn’t be tinkering with such things do so without understanding their effect.. any reaction you received on the list is probably from the people thinking you’re looking for a “quick fix” which is not the right idea.
Edited 2010-09-17 05:40 UTC
Well Brynet, i think that “quick fix” isn;t bad at all. It should be leaved to people choice if they want something advanced, or easy. Even developers should not tell to anyone, what is best fot someone other. I must say, that reading mailing list for years now shows that some devs should better sometimes shut up instead of trolling how the users are bad, because they do not fit what they (devs) think about OpenBSD. Criticism isn’t bad if it’s constructive. Telling people go away in such ways because they do not understand devs philosophy is rude and infantile.
ozonehole try m0n0wall or PFSense, they are PF on top of FreeBSD with web administration (GUI). Maybe you will like one of them.
Edited 2010-09-17 13:45 UTC
If you need a GUI to configure a firewall, the *BSD operating systems really aren’t for you.
Firestarter is a poor excuse for a firewall frontend and Guarddog is a complete joke that is lacking many features. These are fine on simple home machines, as that is their intended use, but no knowledgeable system admin would use them on a server. Any good Linux admin would use iptables, from the command line, because of the sheer control the command line allows when compared to a limiting GUI application.
Both FreeBSD and OpenBSD provide excellent documentation for configuring IPFW/PF, especially when compared to iptables on Linux. All that is required by the end user is a little reading and the ability to follow instructions. If you cannot do this, you have no reason to be administrating such a complex firewall to begin with.
Writing firewall rules in a configuration file is not the same as programming by any stretch of the imagination. Using your logic, it could be reasoned that no end user could ever configure a hard drive mount because “programming” /etc/fstab is just too difficult. Please.
It’s not so much that one needs a GUI as it is that having a usable GUI makes it easier to stand behind the recommendation of a solution which will survive me departing the company. If the MCSE can’t poke his way through it then it’s too expensive a solution.
If the MCSE doesn’t know enough about networking to understand English sentences (allow protocol from subnet to subnet in recv interface), then they have no business being anywhere near a firewall, let alone a network server of any kind.
A well-documented text file is a heck of a lot easier to understand than a bunch of icons and arrows onscreen.
You can say that as much as you want but it doesn’t help one iota. Maybe I find a well documented text file easier to understand, and maybe you find a well documented text file easy to understand, but when everyone else has the IQ of a chimp you simply cannot afford to require that the admin be able to (1) read english, (2) understand english, (3) have the wit to comprehend that computers aren’t magic and syntax matters.
Big shiny button is easy. “Click here, click here, click here” is easy. Even if these things are not easy these things are expected and understood by the chimps. If the company employs 9 morons and one you then anything a moron can’t do creates a single point of failure.
It’s sad, it’s stupid, but it’s reality.
Sadly in my experience the overwhelming majority of MCSEs and those filling the position that would be filled by an MCSE are required at some point to work with the corporate firewalls. If it had been a command line interface almost all of these would end up throwing up their hands in despair because they have difficulty enough understanding the basic concepts of network flow. The GUIs on the Sonicwall and Cisco units have been able to some extent protect them from themselves. Not completely since I’ve been called in far too many times to fix their misconfigured firewalls, but it’s at least made it more difficult for them.
Yes I have an MCSE and yes I prefer to manage from the CLI.
If you need a GUI to configure the packet filter, there’s something wrong with that packet filter.
This is one of my biggest complaints about ipchains/iptables/netfilter/whatever on Linux systems. The CLI syntax is so horribly convoluted and complex with so many interdependencies and a mixture of -s and –long options that it’s *very* hard to wrap your head around it. Thus, a lot of GUIs have sprung up to try and hide all that complexity.
Contrast that with IPF, PF, or IPFW syntax which is about as close to plain English as you can get. It’s *extremely* easy to read a ruleset for these packet filters, and it’s very easy to wrap your head around it all. Thus, anyone with a text editor and some networking knowledge can craft a ruleset for them.
You don’t need programming skills. You need knowledge of how networking works, how packets enter/exit a system, how IP addresses and routing work, etc. IOW, “Joe Blow” who can barely double-click a mouse should not be configuring packet filters.
You’d be amazed how many questions crop up on forums from people who don’t know an IP address from a port number, who’ve pointed and clicked their way through Linux GUIs, but can’t figure out an IPFW rule. If you won’t put in the time to learn a little bit about networking, then you shouldn’t be playing with a packet filter.
A GUI won’t help in those situations.
Why bother with packet filters then? Just plug in a router (wireless or not) and be done with it.
It’s caled pfSense, and is based on FreeBSD.
You do not, and I repeat emphatically, do not need a GUI for iptables. I’ve certainly never used one and have written many a complex and simple rule set.
You can argue that a different syntax would be easier or whatever but what we have is not very hard and works very well.
How does it stack up to netfilter/iptables? I get that it beats the pants off of pf for multicore performance, but how badly does it trash Linux?