Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Aug 2014 12:46:08 +0000
From:      Mark Felder <>
To:        Darren Pilgrim <>, Gleb Smirnoff <>
Subject:   Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
July 31 2014 2:41 AM, "Darren Pilgrim" wrote:

>> No. I believe pf should be removed from FreeBSD and efforts refocused
>> on keeping ipfw up to date and feature complete. It makes more sense =
>> look at what pf, ipf, nbtables, etc. are all doing as a source of =
>> for what we can do with ipfw. A decade ago, there was justification =
>> adding pf: at the time, ipfw lacked some major features.
>> Ipfw has since caught up. I see no remaining value in having more than
>> one packet filter in the base. Ipfw is more mature and less broken, so
>> we should keep it and ditch the rest in the name of survival efficienc=

pf is not simply replaceable in many environments. For example, people =
use it specifically for its integration with the spamd greylisting =
daemon. I think it's reasonable to assume they did so because the whole =
spam filtering stack performs better on FreeBSD than on OpenBSD. This =
was just recently mentioned on twitter:

Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able =
to load my full spamd blacklist anymore. @freebsd #spamd #pf

I personally use pf for many reasons, spamd included. I don't think =
anyone out there is interested in forking spamd to play ball with ipfw =
so we would also be alienating these users who can't just change packet =
filters. Is there even an equivalent to pfsync for ipfw? I didn't think =
so, but I could be wrong...=20

In the world of firewalls pf has been put on a quite a pedestal. OpenBSD =
pushed it hard and it marketed it well; people found it both powerful =
and easy to use which created a cult following and lots of word of mouth =
advertising. I find it hard to agree with removing pf from FreeBSD =
because of the existing userbase. If there was an experimental label on =
it I would find its removal easier to swallow.

I think it's worth pointing out that nobody really wanted to maintain an =
incompatible fork of ZFS indefinitely either; it would be a monumental =
if not suicidal task. And who wants to deal with the bad PR about =
FreeBSD being years behind Illumos features or, *gasp*, even letting a =
native Linux implementation one-up us? People found a way to collaborate,=
 OpenZFS movement was founded, and this is a mostly solved problem, OS =
nuances aside. I can appreciate that people seem to care more about =
their data than their packet filters and FreeBSD ZFS certainly moves a =
lot of servers and appliances furthering the userbase whether or not =
they're using FreeBSD or TrueOS or some other derivative. Let's continue =
to give people another reason to put FreeBSD in their datacenters. Let's =
try to compete in the firewall/packet filter space too.

On a side note I'd also like to point out that FreeBSD has been advertisi=
ng pf by listing it first in the handbook:

I'm sure there's a subliminal message being sent there, intentional or =

I don't want to see FreeBSD lose mindshare from its absence in a time =
where FreeBSD uptake seems to be rising thanks in part to bad decisions =
in the GNU/Linux camp. This feels like a solvable problem if funding and =
enthusiasm is put behind it. OpenBSD really sounds willing to collaborate=
 if not just because they're tired of seeing neglected forks of one of =
their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS...

Want to link to this message? Use this URL: <>