Re: Future of pf / firewall in FreeBSD ? - does it have one ?

In message <20381608.Hhy3QfhrOP_at_overcee.wemm.org>, Peter Wemm writes:
> On Saturday 19 July 2014 13:06:52 Baptiste Daroussin wrote:
> > On Fri, Jul 18, 2014 at 03:22:18PM -0400, Allan Jude wrote:
> > > On 2014-07-18 15:07, Adrian Chadd wrote:
> > > > On 18 July 2014 07:34, krad <kraduk_at_gmail.com> wrote:
> > > >> that is true and I have not problem using man pages, however tha=
> ts not
> > > >> the
> > > >> way most of the world work and search engines arent exactly new =
> either.
> > > >> We
> > > >> should be trying to engage more people not less, and part of tha=
> t is
> > > >> reaching out.
> > > >=20
> > > > Then do the port and maintain it.
> > > >=20
> > > > The problem isn't the desire to keep things up to date, it's a la=
> ck of
> > > > people who want that _and_ are willing/able to do it _and_ are fu=
> nded
> > > > somehow.
> > > >=20
> > > > So, please step up! We'll all love you for it.
> > > >=20
> > > >=20
> > > >=20
> > > > -a
> > > > _______________________________________________
> > > > freebsd-current_at_freebsd.org mailing list
> > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to
> > > > "freebsd-current-unsubscribe_at_freebsd.org"
> > >=20
> > > At vBSDCon Bapt_at_ volunteered to port the newer pf back to FreeBSD, =
> after
> > > spending some hours driving with Henning.
> >=20
> > I tried and broke pf for month and my changes have been reverted, thi=
> s is
> > not as simple as it looks like, our code as diverge a lot in some par=
> t and
> > we do support things that openbsd does not (vimage). Sync features re=
> quires
> > us to be very careful, my priorities went elsewhere since that time, =
> so now
> > I will probably only focus on bringing features I care about, and not=
>  the
> > entirely new pf.
> >=20
> > So no do not count me as volunteer to maintain pf, I ll probably do s=
> ome
> > work but not a full sync.
> 
> If anyone is looking for a really useful chunk to work on, please go ba=
> ck over=20
> the pf history in openbsd and find where they added ipv6 fragment suppo=
> rt.  It=20
> was fairly well contained and didn't appear to be a big deal to port.  =
> They=20
> did do something with mbuf tags that I'm suspicious of though.
> 
> IPv6 fragments are the biggest pain point we have on the freebsd.org cl=
> uster -=20
> yes, we use pf and IPv6 extensively, but dns with ipv6 involved is real=
> ly=20
> painful without fragment support.
> 
> We sort-of work around it by using dedicated IPv6 address that has noth=
> ing but=20
> the dns resolver clients and allow  ipv6 fragments to it.  Its not idea=
> l but=20
> it gets over the worst problems.
> 
> The other thing we had to do for usability is stop state tracking for u=
> dp dns=20
> =2D the sheer update rate was causing collisions and state drops / resets=
>  of=20
> other connections to the point of being really hard to use.
> 
> Those two tweaks - stopping heavy dns use from thrashing the state tabl=
> es, and=20
> having a safe place to send fragments makes it quite usable for freebsd=
> .org.
> 
> But, lack of ipv6 fragment processing still causes ongoing pain.  That'=
> s our=20
> #1 wish list item for the cluster.

Taking this discussion slightly sideways but touching on this thread a 
little, each of our packet filters will need nat66 support too. Pf doesn't 
support it for sure. I've been told that ipfw may and I suspect ipfilter 
doesn't as it was on Darren's todo list from 2009.


-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.