Native-kernel wireguard support for 21.1 feasible? FreeBSD 13 may have it

[chemlud]

is there an alternative BSD? or only way to go linux as a basis?

[Gauss23]

is there an alternative BSD? or only way to go linux as a basis?

I really wish there would be an OPNsense alternative based on linux. As most of my installations are VMs it really hurts that BSD just does not support virtualization as good as linux does. Network performance is just poor in comparison. And now it even feels like "big" companies are able to push trashy code into the kernel like they wish. That makes it hard to believe that BSD will still be a secure and stable base in the future.

[chemlud]

is there an alternative BSD? or only way to go linux as a basis?

...And now it even feels like "big" companies are able to push trashy code into the kernel like they wish. That makes it hard to believe that BSD will still be a secure and stable base in the future.

But if you have a look at Netgate you could come to the conclusion that is exactly what they want to achieve...

[franco]

https://www.reddit.com/r/PFSENSE/comments/m6k20q/painful_lessons_learned_in_security_and_community/

For all the good intentions I think you can't go much more wrong than this and at the same time frame a WireGuard author as "attacker".

Personally I learned long ago that every company has great ideas and talk a lot about their plans, but you just have to wait and see for them to wreck their plans using textbook management intervention errors and character misjudges in employees. So how you pull it off is the only thing that matters... This one not so much.


Cheers,
Franco

[Greelan]

This has all the sounds of an immense implosion... Plus the sounds of feet rushing to another project like OPNsense

[chemlud]

https://www.reddit.com/r/PFSENSE/comments/m6k20q/painful_lessons_learned_in_security_and_community/

For all the good intentions I think you can't go much more wrong than this and at the same time frame a WireGuard author as "attacker".

Personally I learned long ago that every company has great ideas and talk a lot about their plans, but you just have to wait and see for them to wreck their plans using textbook management intervention errors and character misjudges in employees. So how you pull it off is the only thing that matters... This one not so much.


Cheers,
Franco

Cowboys are planning for Texas Indepence Day and coke is really cheap these days in Mexico...

[Patrick M. Hausen]

But Donenfeld et al. did fix the code which will probably be in FreeBSD 13.1. So what's the problem? Due diligence and regular open source mechanics at work.

Or did I miss yet another new twist to that story?  ;)

[franco]

All the if_wg code will be removed from FreeBSD. Because Scott Long said so? Because the removal includes the latest improvements as well... https://lists.zx2c4.com/pipermail/wireguard/2021-March/006504.html


Cheers,
Franco

[Patrick M. Hausen]

So it will be back in FreeBSD when it's ready. Works for me. Our plans for our future office firewall are to get the Deciso rack mount appliance, largest model. That will have more than enough raw CPU power to burn on WireGuard-go ...

[chemlud]

spoiler: doesn't burn that much. I use wg on linux machines (NAS, clients) as an additional level of encryption. Works quite well so far!

The problem is that Netgate tries to destroy FreeBSD to get away with its Linux firewall and destroy the fork not-to-be-named (you are using)....

[SFC]

For posterity's sake:

https://web.archive.org/web/20210316222619/https://www.netgate.com/blog/painful-lessons-learned-in-security-and-community.html

[franco]

A lot of time and money and reputation could have been saved. As far as I understand the if_wg module will be back as a ports tree based implementation sooner or later so that any currently supported FreeBSD can use it rather than bundling it with the operating system. It's a good idea that the original committer should have considered, but not a lot of PR could be gathered with this approach I think.


Cheers,
Franco

[franco]

Oh, the blog post from Scott Long got pulled already? It's hard to keep up.


Cheers,
Franco

[chemlud]

For posterity's sake:

https://web.archive.org/web/20210316222619/https://www.netgate.com/blog/painful-lessons-learned-in-security-and-community.html

You never know:

Netgate Blog
Painful Lessons Learned in Security and Community
March 16, 2021
By Scott Long

I've been involved in the open source community dating back to the first time I downloaded and installed 386BSD 0.1 in 1992 while a freshman in college. The collaborative community, the transparency of the plain-to-see source code, and the opportunities to learn, grow, and be mentored by others spoke to me on a deep level. Twenty nine years later, I'm still learning, still growing, and still seeking out positive collaboration with others.

I talked about Wireguard in this blog a couple of months ago. My team and I were proud of the work, proud of the results, and eager to share it with the pfSense and FreeBSD communities. One of the inherent advantages to using open source software is that a community will often form around what you're doing, and that community has a multiplier effect on improving the code and reducing the burden of maintenance. It's a symbiotic relationship, and the whole becomes greater than the sum of its parts. That's certainly happened with Netgate and pfSense on a large scale, and we were hoping that it would happen with Wireguard on a smaller scale.

Writing kernel code is hard, and writing security-focused kernel code is even harder. It winds up being a collaborative effort by necessity; even the best developers need code reviews, design feedback, and constructive criticism. Even then, mistakes can slip through, ranging from being simple but overlooked, to being complex and intertwined in the structure of the code. So security is also an iterative and interactive process. The first review might miss a bug, but the second review will catch it. The important things are to always operate openly, collaborate in good faith, and leave your ego at the door.

For Wireguard, our developer started the work in 2019 and put it out for private review in May 2020. In August 2020 he put it out for public review. A lot of iterative feedback and fixes happened during that time; I think I counted 92 exchanges on the public review. When it finally was submitted to the FreeBSD source tree in November 2020, we all felt it was in a state that would be useful for others. During the code review, and all the way through our pfSense Plus and CE release cycles in February 2021, we tested it internally and we encouraged the community to test it as well. There were bugs that were reported, found, and fixed during this time, and by the end, we felt pretty good about it. There were some unresolved issues, but they seemed to either be minor and able to be worked around, or they were in use cases that didn't apply to pfSense software. In particular, the code was not working well in FreeBSD's "jail" container environment. We take all bug reports seriously, but we also prioritize them. Since jails are not a normal use-case for pfSense, we deferred the problem for the release.

Around the same time as the release, interest in the FreeBSD community around Wireguard started to grow and attract the attention of other developers. This is exactly what we had hoped for; many hands make light work, and collaboration strengthens us all. However, open collaboration on security code requires thoughtful handling when that code has already been published. Fixing a bug sometimes means exposing a vulnerability and highlighting an exploit. Sometimes it means taking ownership of a careless mistake or a bad design. There are social norms and community practices, though, for working in this kind of environment that don't compromise openness and transparency and also don't put users at undue risk. The lessons learned in the IT industry on this topic, good and bad, what to do and what not to do, can easily fill a book or two. However, the guiding principles that I've found in my 29 years are to always be transparent, always be respectful and empathetic towards others, and to always keep your ego in check. Omitting any of these principles results in unnecessary pain, conflict, confusion, and distrust.

We are taking the public discussion from the past week about Wireguard and FreeBSD very seriously. The uncoordinated publication caught us off-guard, which is unfortunate and not the norm in the security community. However, every issue that has been disclosed to us is being investigated and evaluated. – Right now, we have not found any issues that would result in a remote or unprivileged vulnerability for pfSense users who are running Wireguard. – We've identified several low-risk issues that are unlikely to be exploitable, except by an attacker who has already compromised the admin permissions of the system. Also, the use of Jumbo Frames appears to be problematic, but this is not a typical use case for most networks and most users. Again, we take these seriously, we are developing and testing fixes right now, and we will disclose our findings as soon as possible.

Unfortunately, the public discussion has also veered into vague claims and slanderous attacks. This is where the lack of transparency, the lack of respect, and the inflation of ego is damaging and unproductive. We had hoped for a better collaboration than this, and it makes me doubt the motives of the attackers. And yes, I make deliberate use of the word "attacker" here, because that's what this is, an attack on Netgate and on the FreeBSD and pfSense communities. Beware of anyone who says that they have all the answers. I also worry about the integrity of those who make vague statements and blanket, over-the-top accusations.

Why did this blow up? It blew up because the attackers broke the process and procedure for progressing an open source project. Not just any project, but a well-established, solid operating system project. A project that should not be ruled by the "move fast and break things" process. It blew up because it surprised people who expected stability and gravitas. It blew up because of a disrespect for our developers, our testers, and our users. We at Netgate, and I personally, tried to engage their effort, only to be rebuked by them.

By following the normal, well understood security disclosure process this entire incident could have been handled quickly and efficiently through normal channels. We have yet to see a full description of the problems claimed; their choice to do a complete rewrite obscures the evidence of what they believe they were fixing, and they have yet to submit their work through the normal FreeBSD Phabricator process for review. That said, we do look forward to the bug reports and subsequent evaluation of the code through this review process. Code development is an iterative process, and one that we continue to strive to be better at. In the end, we will all benefit.

So what have I learned from this? I've learned to be a little less trusting. I've learned to be more proactive in defending against people who have ulterior motives. I've learned that people who emphatically say that they're here to help often aren't. This was definitely not the positive collaborative experience that I alluded to at the beginning of this blog. Does that mean that I don't believe in community collaboration anymore? I hope not. Enduring an attack this insidious needs the strength that comes from the community. We need everyone's help to continue to improve both FreeBSD and the pfSense software and build a strong security community. We need to work together, be transparent, be respectful, and leave our egos at the door. We continue to be committed to quality, community, transparency, and security. Please join us in this effort.

[SFC]

Oh, the blog post from Scott Long got pulled already? It's hard to keep up.


Cheers,
Franco

I can imagine the smug grin on their faces when they posted it to their subreddit quickly changed to shock and horror when the community almost universally responded negatively to them and in support of Jason.

The fact they hastily pulled it without explanation just makes the entire operation look like a clown show.