AddThis Social Bookmark Button


OpenBSD PF Developer Interview, Part 2
Pages: 1, 2, 3, 4

Federico: Mike, you wrote most of the stateful engine. How did you audit it?

MF: Auditing is more of a continual process than one would think. Whenever something that you never thought of before comes out, you have to go through all your code again to make sure you're not affected. Often that is a self sustaining process. Inspiration often strikes during the audit and you think of more gotchas so you re-audit and think of more gotchas to audit for. I end up staring [at] a lot of weird and funky traffic at work; corner cases of corner cases. Most of my audits are walking those weird packets or connections through PF's state engine to make sure we don't block a valid packet.

Federico: Mike, you wrote most of the scrub feature. What improvements are planned for the future? What about TCP scrubbing and normalization?

MF: Niels Provos did the initial fragmentation and flag scrubbing support based on Paxson and Handley's USENIX paper. My planned improvements are in the normalization of TCP segments. The TCP protocol was designed so that there are only two active participants in any given connection. Making PF more active in the TCP stream will be done very gradually since mistakes lead to massive ACK storms or connections mysteriously freezing.

Federico: Mike, your job focuses on IDS development. Had you any ideas to make PF capable of interacting with an IDS like Snort?

MF: There are a few levels of interaction between a firewall and an IDS. I believe Snort has been able to do intrusion detection on any packet logged by PF for a year or two now (PF logged packets appear on the pflogd0 virtual interface which you can monitor with many libpcap based programs like tcpdump or ethereal).

There are already two ways to emulate Linux's DIVERT sockets and turn an IDS into an IPS (Intrusion Prevention System). One could use PF to route the packets to a tunnel device and read them there. Or one could block the packet in PF and watch the full packet show up on the pflogd0 logging interface.

And a passive IDS running on the firewall could easily tell PF to kill all of an attackers connections and add his IP address to a blacklist or even redirect any new connections from him to a honeypot.

The tools are all there. All it takes is someone to add the code to Snort. Someone whose employer doesn't compete with Snort :-).

Federico: Are there any plans to develop application proxies for common protocols like HTTP, SMTP and POP3?

DH: They are easily done in userland, see ftp-proxy(8). We agree to not do it in kernel. If there is enough demand for protocols besides FTP, someone will step up and do it, I'm sure.

HB: No.

ftp-proxy is needed due to the nature of ftp with its two connections, the place for other proxies is in ports IMHO. That said, some stuff is imaginable in-tree, and if somebody steps up and writes good code, this is certainly welcome. Whether it turns into a port then or goes into the main tree, I can't say yet.

RM: In the kernel? Certainly not, the risk for compromise is too great. In userland, already have ftp-proxy, and there are 3rd party applications which handle many of the other protocols: apache or squid for HTTP; MTAs such as sendmail are basically SMTP proxies by nature.

CEA: These protocols are quite firewall friendly since they use well defined ports. These protocols could benefit from content filtering or caching. OpenBSD already has spamd which is a proxy for spam :) and there are a number of http proxies in the ports tree. I am not aware of any specific plans, but someone might just decide to write one.

CB: I've no idea.

Federico: Some OpenBSD developers wrote various tools to analyze PF logs and statistics (pfstat, Hatchet,...). Is there any project to create a global and unique graphical interface to work with PF?

HB: No.

RM: Not by any OpenBSD developers. Doing a good GUI configuration tool for PF is very difficult because there are so many options, and laying them out intuitively in a graphical interface is nearly impossible.

Federico: Can, could you explain pftop?

CEA: It started as a text-mode realtime display tool for active pf states. It improved quickly with feedback and patches from the community. It now has rule and queue pages, and can compute per state throughput. I should probably find some time to catch up with the new pf features in 3.5 though. pftop is available in the ports tree as sysutils/pftop.

Federico: Please, tell us the all the truth about PF performance tweaking. What are the right settings to build a stable and network optimized kernel?


I totally don't get that tweak tweak tweak attitude. GENERIC works fine in almost all circumstances. If you have a real problem with GENERIC, as in a problem that shows up during real world usage, then post to misc@ and you'll get help.

Of course there are cases where you need to tune; I have machines where I need to crank nmbclusters a little. BUT: the key point is, as long as GENERIC works and doesn't show a problem that is the best you can get. And making GENERIC work for more and more scenarios is one of the major things we are doing since some releases, by switching from compile time options to runtime controllable stuff (mostly sysctl) or at least allow changing from config/ukc.

In fact, a lot of knobs should not ever be touched. This especially is true for nkmemclusters. The myth about that being needed comes from old days where we had a leak in the routing table code under some circumstances... nowadays you will in almost all cases shoot yourself in the foot by mucking with nkmemclusters. You increase it, something else needs more kernel memory, and you run out. You will crash. So don't touch it.

OpenBSD 3.6 will come with big improvements in that area.

Federico: How will PF evolve? More features or performance tweak?

DH: I think addition of new features will slow down over time, most things are covered by now. New features have to be justified against the instability changes introduce. Changes have been frequent at first, I don't mind changes settling down. That allows [us] to more carefully search for performance improvements and plain bugs.

MF: My PF wishlist is almost empty. I imagine most of the next big evolutions will be from spontaneous ideas someone has in the bar or us feeding off ideas of the others during the next PF hackathon.

HB: There's ongoing work on bpf security. We are also looking at further flexibility in the language and some internal changes that solve little problems.

There are no "big" new features planned for pf; maybe some of the stuff we do outside pf gets to interact with it in some way. We've been at the "pf is done" point quite a few times now, and there have been great ideas later on. pf development slowed down, and will slow down even more — not because we don't have enough developers or something, but simply because it is, well, pretty much done.

Compatibility becomes a much larger issue with every release that contains pf and with each and every pf installation, that's an area where I think we have to get better.

CB: The one thing I'd like to have for 3.6 is the ability for firewalls working in a bridged environment to send IP packets (i.e., firewalls without IP address and/or routing table). Currently, features like syn-proxy, return-icmp, return-rst don't work on such a firewall because PF does not know how and where to send packets. Fortunately, I think there are good 95% solutions to that problem, which is probably the most requested feature on PF lists.

Besides that, I'm not aware of any "big" things that would come, but we've been saying that for every past release, as far back as I remember :).

RM: Because of the very clean initial design, PF has never had real performance problems — in the vast majority of PF deployments, the CPU sits essentially idle. So there's not much incentive for developers to spend long hours squeezing a bit more performance out of the code — such efforts would likely increase the complexity and thus the chance of bugs.

With regards to new features, it is hard to say; PF is becoming fairly feature complete and eventually development will slow down to a maintenance mode, like many other areas of OpenBSD. On the other hand, put 2 PF developers in a room together, and they immediately begin to come up with new crazy ideas. So I don't see it stopping within the next few releases.

However, I think the bulk of new work being done will not be in adding new features, but in the following 2 areas: fine tuning the features which already exist as we learn more about how they are used in production deployments, and making internal changes which simplify or reduce the code base. The latter is very boring for users, but actually quite important in reducing the potential for bugs.

CEA: I think, with the recent failover work, the feature range is quite complete. There would definitely be some performance tweaks, and improvements/additions to supporting userland tools before new features.

Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as,,,,,,, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.

Return to the BSD DevCenter.