Re: Update to PF from OpenBSD 6.5
On 8/20/2019 5:49 AM, Kristof Provost wrote: > [snip] > We’ve not done wholesale imports from OpenBSD in a long time, yes, but > FreeBSD’s pf is maintained, and regularly gets new features and bug > fixes. Fixes even flow in both directions between OpenBSD and FreeBSD. Around the time the work was done on the OpenBSD pf to make it suitable for what FreeBSD wanted, I suggested that FreeBSD at least change the name to make looking for information about a specific flavor a bit easier. Given the major changes listed in this thread and elsewhere, I am still a bit surprised the name was not changed. ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Update to PF from OpenBSD 6.5
Hey Kristof, Thatnk you for your very thorugh explanation! It is very interesting to read that FreeBSD's PF is, in some ways, "better" than OpenBSD's (with regards to scalability). It was also very simplistic to state FreeBSD's version of PF essentially equals OpenBSD 4.1's version. I made this statement based on the information on http://pf4freebsd.love2party.net/: " In HEAD - pf is at OpenBSD 4.1 - at this time." Of course this website might be outdated (it gives a date of March 8, 2004!) but it also presents it in a very simplistic manner. Anyway, thanks again for the many insights. On Tue, 20 Aug 2019 at 13:06, Kristof Provost wrote: > On 20 Aug 2019, at 12:32, Goran Mekić wrote: > > On Tue, Aug 20, 2019 at 11:49:18AM +0200, Kristof Provost wrote: > > One thing I’ve thought of trying, and that might be an interesting stepping > stone, is to create a port (/usr/ports/net/opf or whatever) of OpenBSD’s > pf. > In that version it’d be acceptable to not fix any of the above issues. It’d > still give users to option of getting the new syntax. I’d expect this to be > a relatively straightforward exercise. > > That would be cool, but only if FreeBSD PF can not be "fixed" to support > OpenBSD PF syntax. > > The main issue there is one of compatibility. How happy will our users be > if their rulesets suddenly stop working after an upgrade? > > Anyway, none if this is on my active todo list. Don’t expect to see it any > time soon. > > In principle there’s nothing to stop us from doing that same work in base, > but we’re **NOT** going to import a fourth firewall. We’re just not. > > Are you sure? https://2019.eurobsdcon.org/talk-speakers/#NPF. At least I > hope the import is pfil based. > > I don’t know what George’s plans are exactly, but it’s likely that he’s > doing the porting work to get an apples-to-apples comparison of firewall > performance, not because he wants to maintain another firewall. > Either way, I’m not pushing for another firewall. George gets to own one > if he wants to. > > Regards, > Kristof > ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Re: Update to PF from OpenBSD 6.5
On 20 Aug 2019, at 12:32, Goran Mekić wrote: > On Tue, Aug 20, 2019 at 11:49:18AM +0200, Kristof Provost wrote: >> One thing I’ve thought of trying, and that might be an interesting stepping >> stone, is to create a port (/usr/ports/net/opf or whatever) of OpenBSD’s pf. >> In that version it’d be acceptable to not fix any of the above issues. It’d >> still give users to option of getting the new syntax. I’d expect this to be >> a relatively straightforward exercise. > That would be cool, but only if FreeBSD PF can not be "fixed" to support > OpenBSD PF syntax. > The main issue there is one of compatibility. How happy will our users be if their rulesets suddenly stop working after an upgrade? Anyway, none if this is on my active todo list. Don’t expect to see it any time soon. >> In principle there’s nothing to stop us from doing that same work in base, >> but we’re **NOT** going to import a fourth firewall. We’re just not. > Are you sure? https://2019.eurobsdcon.org/talk-speakers/#NPF. At least I > hope the import is pfil based. > I don’t know what George’s plans are exactly, but it’s likely that he’s doing the porting work to get an apples-to-apples comparison of firewall performance, not because he wants to maintain another firewall. Either way, I’m not pushing for another firewall. George gets to own one if he wants to. Regards, Kristof signature.asc Description: OpenPGP digital signature
Re: Update to PF from OpenBSD 6.5
On Tue, Aug 20, 2019 at 11:49:18AM +0200, Kristof Provost wrote: > One thing I’ve thought of trying, and that might be an interesting stepping > stone, is to create a port (/usr/ports/net/opf or whatever) of OpenBSD’s pf. > In that version it’d be acceptable to not fix any of the above issues. It’d > still give users to option of getting the new syntax. I’d expect this to be > a relatively straightforward exercise. That would be cool, but only if FreeBSD PF can not be "fixed" to support OpenBSD PF syntax. > In principle there’s nothing to stop us from doing that same work in base, > but we’re **NOT** going to import a fourth firewall. We’re just not. Are you sure? https://2019.eurobsdcon.org/talk-speakers/#NPF. At least I hope the import is pfil based. Regards, meka signature.asc Description: PGP signature
Re: Update to PF from OpenBSD 6.5
On 20 Aug 2019, at 11:36, Tom Marcoen wrote: Hey all, I'm quite new to FreeBSD so appologies if this is a stupid question. Is there a good reason for not upgrading PF to the version from OpenBSD 6.5? There are several reasons why updating pf is a non-trivial problem. From an e-mail I sent on this subject in April: It’s a good goal, but there are three major issues along the way to importing the latest OpenBSD version. (And I’m sure a whole bunch of smaller ones.) Those are: - scalability - syntax - vimage The scalability issue is the obvious difference: OpenBSD’s pf is still very much single-core oriented, whereas the FreeBSD pf version can cope with multiple cores (somewhat) and is significantly faster on multicore hardware. Our version is by no means perfect, but it’s much faster than OpenBSD’s version. Much of the imperfections we have now is there because pf was designed in a giant locked kernel in the first place. Multi-core scalability was not part of its original design. Adopting OpenBSDs pf would mean redoing all of the locking work Gleb did years ago. Given the differences in OpenBSD’s pf (e.g. they keep states in a tree, not a hash table) it’s not a matter of replaying the previous work on a new pf version. This is a from the ground up introduction of fine grained locking in a code base that assumes a single giant lock. As I understand it the OpenBSD people are working on the problem as well, but I’ve not seen any diffs yet. If they’ve made significant progress we may be able to base our work on theirs. I don’t think it’d be acceptable to not have this, as it’d mean a very large performance regression. For reference, before I did the pfsync work we essentially had a single-threaded pf when pfsync was enabled. On my test hardware this meant a throughput of ~1.1Mpps, rather than the ~3.9Mpps without pfsync. I’d expect OpenBSDs pf to perform at around that ~1.1Mpps number without locking work. The second issue is one of syntax, and that’s what I assume is the main reason people want OpenBSDs pf. We’re still on an older iteration of the pf syntax, but changing that would inevitably mean breaking old configurations. That might be acceptable on a major version update (i.e. going into 13), but would mean the new work could never be backported. That’s probably the only way forward though. I’m playing with importing the ‘match’ keyword and not breaking the ‘scrub’ syntax at the same time, but it’s a non-trivial problem, and that’s only one of the steps along the way. Finally there’s vimage. That’s a FreeBSD-only feature, so naturally OpenBSDs pf is not aware of this. I expect that to be relatively easy to add back in, but it’s another obstacle. As vimage is what lets us have the pf tests we’ve got now I’d be very reluctant to let it go. It’s a supported feature in 12.0, so users will start to rely on it as well. TL;DR: It’s possible, but *hard*. Expect is to be many person-months of effort, and there’s no way it’s going to be a smooth ride. One thing I’ve thought of trying, and that might be an interesting stepping stone, is to create a port (/usr/ports/net/opf or whatever) of OpenBSD’s pf. In that version it’d be acceptable to not fix any of the above issues. It’d still give users to option of getting the new syntax. I’d expect this to be a relatively straightforward exercise. In principle there’s nothing to stop us from doing that same work in base, but we’re **NOT** going to import a fourth firewall. We’re just not. Currently it seems to be at the version from OpenBSD 4.1. That’s so simplistic as to be outright wrong. We’ve not done wholesale imports from OpenBSD in a long time, yes, but FreeBSD’s pf is maintained, and regularly gets new features and bug fixes. Fixes even flow in both directions between OpenBSD and FreeBSD. Regards, Kristof ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
Update to PF from OpenBSD 6.5
Hey all, I'm quite new to FreeBSD so appologies if this is a stupid question. Is there a good reason for not upgrading PF to the version from OpenBSD 6.5? Currently it seems to be at the version from OpenBSD 4.1. Regards, Tom ___ freebsd-pf@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
