Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jul 2014 15:51:42 +0200
From:      Franco Fichtner <franco@lastsummer.de>
To:        "Kristian K. Nielsen" <freebsd@com.jkkn.dk>
Cc:        freebsd-current@freebsd.org, freebsd-questions@freebsd.org
Subject:   Re: Future of pf / firewall in FreeBSD ? - does it have one ?
Message-ID:  <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de>
In-Reply-To: <53C706C9.6090506@com.jkkn.dk>
References:  <53C706C9.6090506@com.jkkn.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Kristian,

On 17 Jul 2014, at 01:12, Kristian K. Nielsen <freebsd@com.jkkn.dk> =
wrote:

> a) First of all - are any actively developing pf in FreeBSD?

not directly related to FreeBSD, but I was planning to bring
DragonFly's pf to a new feature state.  We've had a little bit
of discussion over the recent DF SMP fixes on an OpenBSD mailing
list, but the outcome was a tad disappointing to say the least.

> b) We are a major release away from OpenBSD (5.6 coming soon) - is
> following OpenBSD's pf the past? - should it be?

Yes and no.  :) I still stand by my claim that SMP is the fork
on the road for pf development; having three major BSDs tackling
the work in some way or another (NetBSD chose npf, but that's a
different story).

We should merge newer features for sure, but we have to establish
that the forking of pf was an inevitable process and that the
custom SMP bits are not going away and need to be maintained
separately/individually.

> c) We never got the new syntax from OpenBSD 4.7's pf - at the time a =
long discussion on the pf-mailing list flamed the new syntax saying it =
would cause FreeBSD administrators too much headache. Today on the list =
it seems everyone wants it - so would we rather stay on a dead branch =
than keep up with the main stream?

I'd say many people are comfortable with an old state of pf (silent
majority), but that shouldn't keep us from catching up with newer
features (and of course bugfixes).

> d) Anyone working on bringing FreeBSD up to pf 5.6? - seem dead on the =
pf-list.

Not exactly, but I have a strong interest in this happening and
am able to help.  :)

> e) OpenBSD is retiring ALTQ entirely - any thoughts on that?
> http://undeadly.org/cgi?action=3Darticle&sid=3D20140419151959

The reasoning is sound.  I think the direction is good, although
one probably can't rip out ALTQ just like that in FreeBSD.

> f) IPv6 support?- it seem to be more and more challenged in the =
current version of pf in FreeBSD and I am (as well as others) =
introducing more and more IPv6 in networks.
> E.x. Bugs #179392, #172648, #130381, #127920 and more seriously =
#124933, which is the bug on not handling IPv6 fragments which have been =
open since 2008 and where the workaround is necessity to leave an =
completely open hole in your firewall ruleset to allow all fragments. =
According to comment in the bug, this have been long gone in OpenBSD.

Needs to be taken care of.  Getting more and more important.  ;)

> g) Performance, can we live with pf-performance that compared to =
OpenBSD is slower by a factor of 3 or 4, even after the multi-core =
support in FreeBSD 10?
> (Henning Brauer noted that in this talk at =
http://tech.yandex.ru/events/yagosti/ruBSD/talks/1488/ (at 33:18 and =
36:53)) - credit/Jim Thompson

A factor 3 or 4 times is the proverbial "it's one louder".  SMP
scaling can reach more performance im the long run, and pf can
still be tweaked to increase "atomic" performance, although the
physical algorithm limits are a lot more finite than with SMP.

> h) Bringing back patches from pfSense?

Those patches are not available anymore since pfSense changed the
visibility of the pfsense-tools.git.  I would welcome to see those
patches trickle back under a standard BSD license for review and
inclusion when viable.

But first of all, we need those patches back.


Cheers,
Franco=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6326AB9D-C19A-434B-9681-380486C037E2>