PF pf in FreeBSD 15.0 is getting on par with OpenBSD

hardworkingnewbie

hardworkingnewbie

Netgate is sponsoring an effort to bring pf in FreeBSD to be on par functionality wise with the version in OpenBSD. As we all know, FreeBSD's version is way behind the features and functionality in OpenBSD since quite a long a time.

Most updates will happen with the release of FreeBSD 15.0 in December 2025, making configs between both pfs more exchangeable. The work has been done mostly by Kristof Provost and Kajetan Staszkiewicz.

www.netgate.com

Updates to the pf packet filter in FreeBSD and pfSense software

Learn about the ongoing synchronization of OpenBSD’s pf advancements into FreeBSD, nearing completion for FreeBSD 15.0, enhances the firewall’s performance, security, and compatibility with multiprocessor kernels.
www.netgate.com www.netgate.com
 
hardworkingnewbie said:
Anyway it's great that this gap has been closed and we all will profit soon from this effort, because it will be in FreeBSD15.
Click to expand...
Most of it, yes.

I still have a few pending commits, mostly for the “once” rules. That won’t be in 15.0, because it didn’t land in time and I don’t want to make Colin’s life (the release engineer) harder than it already is.
I don’t know if the “once” rules will be added to the PHP, but the code will almost certainly be in the next pfSense release.
 
hardworkingnewbie said:
As we all know, FreeBSD's version is way behind the features and functionality in OpenBSD since quite a long a time.
Click to expand...
It all depends on your needs.
Since ALTQ was removed from OpenBSD, in my opinion pf in FreeBSD offers more functionality.

Will ALTQ with HFSC and the RED extension stay, or is it going to be removed?
 
rashey said:
It all depends on your needs.
Since ALTQ was removed from OpenBSD, in my opinion pf in FreeBSD offers more functionality.
Click to expand...
There are a number of features in FreeBSD pf that are not in OpenBSD pf (VIMAGE, dummynet, basic ethernet layer filtering, SCTP support are the first that come to mind. ALTQ is the very last one to come to mind though.

The old "It's an outdated pf" thing is so vague and inaccurate as to be a totally misleading statement.

rashey said:
Will ALTQ with HFSC and the RED extension stay, or is it going to be removed?
Click to expand...
ALTQ is at best only occasionally maintained. While in many ways I'd love to remove it (given that we can do dummynet now the reasons for ALTQ are very thin), but I know of at least two major users, so there are no immediate plans for removal.
At some point it probably will be, but there are no specific plans.
 
Kristof Provost said:
ALTQ is at best only occasionally maintained. While in many ways I'd love to remove it (given that we can do dummynet now the reasons for ALTQ are very thin), but I know of at least two major users, so there are no immediate plans for removal.
Click to expand...
I switched from IPFW and DUMMYNET to PF and ALTQ because of HFSC (most advanced packet scheduling algorithm available in FreeBSD). After more than a decade of use, I can say there's no better QoS solution for me - and it remains the main reason I still use FreeBSD.

Kristof Provost said:
At some point it probably will be, but there are no specific plans.
Click to expand...
If it were ever removed, it would be a sad day, and definitely the end of my FreeBSD journey. 😢
 
Kristof Provost thanks for the work on pf over the years.

I think what happened is perfect Open Source: FreeBSD initially imported from OpenBSD, kept track of changes, updated to suit FreeBSD better but made it incompatible with OpenBSD so features diverge. At some point someone (that has a reason/need) looks to see if converging would be a good idea and someone makes it happen (this also makes future integrations easier)

ALTQ: it sounds like that specific feature may go away but the overall goal will remain but under a different banner. I could be wrong but that's the way I read post #8.
 
"ALTernate Queuing" basically ways of doing QoS on the packets, so some get out quicker. There is an example I think by Daniel Hartimeir (I may have mucked the name) where he had an asymmetric link (more BW down, less up) and he did something with TCP ACKs got higher priority so downloads wouldn't stall
 
mer said:
ALTQ: it sounds like that specific feature may go away but the overall goal will remain but under a different banner.
Click to expand...
That would be a huge regression because DUMMYNET doesn't support HFSC (Hierarchical Fair-Service Curve) algorithm and RED (Random Early Detection) extension like ALTQ does. It's still one of the best QoS solutions available on the market. Anyway, the good news is that at the moment there are no plans to remove it, as Kristof said. That's what I was worried about when I spotted this thread.
 
rashey said:
That would be a huge regression because DUMMYNET doesn't support HFSC (Hierarchical Fair-Service Curve) algorithm and RED (Random Early Detection) extension like ALTQ does. It's still one of the best QoS solutions available on the market. Anyway, the good news is that at the moment there are no plans to remove it, as Kristof said. That's what I was worried about when I spotted this thread.
Click to expand...
Legitimate concerns, but perhaps the algorithms will get moved forward/into/something that is available with dummynet?
That's why you need to follow mailing lists and keep an eye on what's important to you. Providing feedback "I use this all the time" can help keep it on the radar for developers.
 
dave14305 said:
The updated URL is http://www.benzedrine.ch/ackpri.html
Click to expand...
putney said:
Ignore the link to the benzedrine page - that's slop.
Click to expand...

Peter Hansteen's reference on his web page ALTQ - Prioritizing By Traffic Type:
Daniel Hartmeier's ADSL - prioritizing ACKs to improve up/download over asymmetric link
[...]
See http://www.benzedrine.cx/ackpri.html
Click to expand...
Given that he names Daniel Hartmeier (https://www.benzedrine.ch - Daniel Hartmeier) and that:
http://www.benzedrine.cx/ackpri.html
http://www.benzedrine.ch/ackpri.html

differ only in one letter: the correct designation for Switzerland; this looks like a typo.
 
You must log in or register to reply here.
Back
Top