Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 1 Aug 2014 12:46:08 +0000
From:      Mark Felder <feld@freebsd.org>
To:        Darren Pilgrim <list_freebsd@bluerosetech.com>, Gleb Smirnoff <glebius@FreeBSD.org>
Cc:        freebsd-current@freebsd.org, freebsd-questions@FreeBSD.org
Subject:   Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Message-ID:  <74dec781e44c3a81c78e9c4ff1d51c2a@mail.feld.me>
In-Reply-To: <53D9F300.2010308@bluerosetech.com>
References:  <53D9F300.2010308@bluerosetech.com> <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <20140729101806.GB89995@FreeBSD.org>

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 =
to
>> look at what pf, ipf, nbtables, etc. are all doing as a source of =
ideas
>> for what we can do with ipfw. A decade ago, there was justification =
for
>> 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=
y.
>>

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:

@ng_security
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

https://twitter.com/ng_security/status/494982307905040384


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:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html

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

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: <http://docs.FreeBSD.org/cgi/mid.cgi?74dec781e44c3a81c78e9c4ff1d51c2a>