Live data from Hacker News

In-kernel WireGuard is on its way to FreeBSD and the pfSense router

arstechnica.com

21–30 of 167 posts

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#22
post #12
post #5

Earlier quoted context omitted.

I don't think this is completely accurate, nor is it recent. Their "community edition" is open source and free: https://www.pfsense.org/download/ Also, they have https://github.com/pfsense/

Community Edition will diverge from Pfsense+ with the 2.6 release. They have also made no commitments there will be any releases after that - "it's up to the community". They will, however, gatekeep what features the community is allowed to add. Community Edition is more or less a dead man walking at this point, they just refuse to come right out and say that. Someone asked if they'd allow one of the REST API project…

In my case, I don't readily find hostility toward a group that has busted tail to provide me tremendous value while I have contributed very little in return. My interactions over the years have been - perhaps not exclusively positive but overwhelmingly so.

History says one day pfSense will no longer fill my needs. Okay. I'll raise an imaginary glass move on with gratitude.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#23

I'll have to take a look at freebsd, does anyone have a good reference to the differences in a bsd versus Linux?

If it helps, OSX is based on BSD. I've had great success with pfSense. I found great tuning advice here: https://calomel.org Edit: Not sure why I'm getting down votes for trying to provide info. I didn't down vote anything in this thread.

I can't find any logic in downvoting a declaration like this (and the parent Q). It really seems like lashing out at good-faith.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#24

I've been waiting for pfSense+Wireguard for a while. OpenVPN has been very good to me but I'm psyched to trade up.

The opnsense fork has supported wireguard for a while, and has far less restrictive licensing. I highly recommend having a look.

Only if BBCan177 jumps ship. He's my hero.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#25
post #16

Earlier quoted context omitted.

Netgate is weirdly hostile to a lot of opensource stuff, which should be strange given what all their tech is built on top of. This has been going on for years. (see opnsense etc)

Netgate funds a lot of FreeBSD work, and employs FreeBSD committers. I certainly wouldn't describe them as hostile to open source.

I didn't know that. That's kind of awesome.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#26

Earlier quoted context omitted.

If it helps, OSX is based on BSD. I've had great success with pfSense. I found great tuning advice here: https://calomel.org Edit: Not sure why I'm getting down votes for trying to provide info. I didn't down vote anything in this thread.

I can't find any logic in downvoting a declaration like this (and the parent Q). It really seems like lashing out at good-faith.

BSD adheres the POLA principle and is serving many PB of data in production at work. Rock solid and no sudden changes. The manual pages are to me of higher quality when compared to Linux.

POLA Principle Of Least Astonishment

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#27

PSA: pfSense is closed-source [1]. It was discussed last month here on HN [2]. OPNsense is the equivalent FOSS alternative [3]. [1] https://github.com/rapi3/pfsense-is-closed-source [2] https://news.ycombinator.com/item?id=25894420 [3] https://en.wikipedia.org/wiki/OPNsense

The shade I occasionally see thrown toward pfSense is curious to me. This isn't push-back at the parent comment but me expressing a bit of confusion. I've used pfSense since 2009 or so. I was skeptical when Netgate entered the picture but since I've had no reason to complain. It's been a continuous and usually smooth timeline of serving me well. A relevant sidebar is that I've been part of different, stellar voluntee…

> The shade I occasionally see thrown toward pfSense is curious to me.

Every last bit of it is deserved. They made a promise to keep pfSense open source and they broke it as soon as they could. I see them hiding behind it's the newly announced pfSense Plus that is closed source, not pfSense CE and it's pure weaseling.

I still use pfSense but I feel bad for ever being excited about it and contributing to their popularity.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#28
post #11

Link to relevant announcement email: https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649... There's also Jason's reply to apparently not-nice feedback of someone from NetGate: https://lists.zx2c4.com/pipermail/wireguard/2021-March/00649...

Wow. Netgate come off as incredibly unprofessional. According to the article linked and the info here in that email you linked this is my conclusion: * Netgate tried to ship flawed code that has multiple security issues. * Jason Donenfeld, one of the lead Wireguard developers, went out of his way to work on rewriting it to be better in time for the 13.0 release of FreeBSD * This Netgate employee is angry that they we…

That was my impression too, then I went back a couple prior messages, and looked at the earlier announcement. Wihle Netgate looks to have overreacted (at least from the info we have), I can understand why they would be upset. This was in the original announcement:

The first step was assessing the current state of the code the previous developer had dumped into the tree. It was not pretty. I imagined strange Internet voices jeering, “this is what gives C a bad name!” There were random sleeps added to “fix” race conditions, validation functions that just returned true, catastrophic cryptographic vulnerabilities, whole parts of the protocol unimplemented, kernel panics, security bypasses, overflows, random printf statements deep in crypto code, the most spectacular buffer overflows, and the whole litany of awful things that go wrong when people aren’t careful when they write C. Or, more simply, it seems typical of what happens when code ships that wasn’t meant to. It was essentially an incomplete half-baked implementation – nothing close to something anybody would want on a production machine. Matt had to talk me out of just insisting they pull the code entirely, and rework it more slowly and carefully for the next release cycle.

I can understand being upset if that's how you're portrayed publicly.

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#29

I've been waiting for pfSense+Wireguard for a while. OpenVPN has been very good to me but I'm psyched to trade up.

The opnsense fork has supported wireguard for a while, and has far less restrictive licensing. I highly recommend having a look.

OPNsense is criminally underrated. My main routers for my office are virtualized OPNsense VM's in high availability with CARP, DHCP, DNS, VPN endpoints, inter-vlan routing, gateway policies, outbound nat... I could go on. It all works extremely well I can't fathom why people still choose pfSense with all of the community shenanigans and closed source versions.

My only gripe with it over 3 years has been the documentation on their API's for programatically updating firewall rules/aliases could use some more examples, or just mention "use browser's network requests developer mode to see what calls you need to make".

Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router

#30
post #16

Earlier quoted context omitted.

Netgate is weirdly hostile to a lot of opensource stuff, which should be strange given what all their tech is built on top of. This has been going on for years. (see opnsense etc)

Netgate funds a lot of FreeBSD work, and employs FreeBSD committers. I certainly wouldn't describe them as hostile to open source.

It seems clear to me this is a case of passionate coders with different personalities struggling with the difficult work of human communication in a world with limited resources and time.

No one has to be the bad guy here or end up hostile to open source.

Post reply on HN