Earlier quoted context omitted.
Untangle NG Firewall, perhaps. [1] 1. https://wiki.untangle.com/index.php/NG_Firewall_Installation
what about vyos ? https://vyos.io/products/#vyos-router
In-kernel WireGuard is on its way to FreeBSD and the pfSense router
151–160 of 167 posts
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#152PSA: 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…
Like you, i have used pfSense since the 1.2.3 days...which is about 2008-2009 or so. I even bought the book to support the devs at the time (which to my knowledge have left for greener pastures). In some sites I even replaced failing hardware with a legit appliance. And even with COVID, pfsenese allowed me to quickly spin up OpenVPN appliances as standalone boxes (something i tried on OPNsense but couldnt get stable, largely due to the interface changes and my lack of familiarity with them). All of that is to say that I have been a big supporter of theirs, having submitted small bug fixes pre-netgate days and even buying/financially some of their later endeavors.
But the issues are as much
1. Starting with the 2.4 train, you can no longer really compile from source. Their build.sh relies on some closed source components not in their git repo. Specifically a small program called gnid that creates a unique ID and AT LEAST calls home to netgate to report that. They have been very cagey about what all occurs but it does happen outside of the firewalls application itself (ie: you cant block it with a state rule). Bringing this up in forums brings in ad-hoc attacks and open hostility. Gonzo is on-record saying if you cant compile its because you dont know what you are doing or something of the sort.
2. They are openly hostile to FreeBSD, forks like OPNsense (which at one point they squatted a similar domain and even tried to spread amlicious misinformation). https://opnsense.org/opnsense-com/. Theres more...entire threads of nonsense and reading. its out there if you want...But all that is to say...everyone has mud of their face when its slung around like it has been.
You may say this is childish and so comically so theres no way its true. But if you see how they conduct themselves on reddit and listservs its actually somewhat inline.
3. Finally, when gonzo or whatever his name is started back into the project and spawned netgate that was mainly to sell certified appliances as a means to support development. Initially he attacked storefronts on sites like amazon that would pre-package the Community edition onto supermicro boxes etc. And that seemed reasonable (at least to me), even though it was kosher within the terms of the Apache license.. But then with 2.5 they initially announced it would require AES-NI, which a lot of these low power boxes dont support. They backed off of that and eventually said it wouldnt be a requirement. Ive been on 2.3 for a while now because with 2.4 they dropped x86 and went x64 only. Ive avoided opnsense because im used tot he pfsense interface and some of its more advanced tweaks. And moving to x64 is an in place rebuild and re-import. But I held largely to see how further development shakes out and frankly I'm now spending the time migrating my config over to the primary fork.
2.6 (well their move to year.month releases) will diverge from their "Open Source" code with no promises for them to stay near track. Basically its going closed source. And while they claim its up to community for further support, they also hold the keys to the PR and commits/merges....so they have the ability (and given their history) to deny commits for features/bugs that would conflict with their closed source aspirations.
From the announcment below
>In general, features that are part of FreeBSD or the other open source components that comprise pfSense will be upstreamed to those projects and made available to pfSense CE. This includes features mentioned above, like improved packet filter performance. Some features that we add to Plus will contain code that is part of these open source projects and also GUI or middleware modules that are part of pfSense Plus. In those cases, the open source code will still be contributed back and made available to CE, but work will need to happen in CE community to enable it.
https://docs.netgate.com/pfsense/en/latest/releases/2-5-0.ht...
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#153Note that there's additional follow-up available here: https://lists.freebsd.org/pipermail/freebsd-hackers/2021-Mar...
Absolutely the best outcome. BSDs has always been ( to me at least ) about getting things right, take time to get it baked before committing. The old, out of fashion style of getting things done properly and not shipping for the sake of it. Which is both a good thing and a bad thing in the modern world. But it is a trade off. I also hope FreeBSD sort of look into why it was committed in the first place. Hopefully thi…
It is a widely desired feature that no one else was working on and unfortunately, did not see adequate review. FreeBSD largely trusts committers to seek out review and submit quality code. There are certainly downsides to this model, sometimes more impactful than others. Unfortunately, FreeBSD does not have the large body of employer-paid maintainers Linux has available to thoroughly code review every patch that lands.
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#154Earlier quoted context omitted.
Sounds like Jason should trademark Wireguard (the name). Or build an alternative brand. That way Netgate's actions, or the actions of other wireguard implementations, will not reflect on the reputation of his project/product/technology.
He did trademark the name. I don't think Jason is going to tell the FreeBSD project that they can't use the name "wireguard" for their implementation of "wireguard" just because Netgate put out shoddy code. It's not the FreeBSD project's fault. https://www.wireguard.com/trademark-policy/
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#155Earlier quoted context omitted.
I'd say anything remotely security relevant.
Is that based in any way on the relative capabilities and security track records of OpenWRT and pfSense, or is a highly security-conscious userbase merely what's left for pfSense after eliminating anyone who wants good WiFi support and the ability to run on cheap commodity consumer appliances with tight memory and storage limits?
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#156Earlier quoted context omitted.
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.
Well instead of pfSense no longer fulfilling your needs than maybe its time to beam up to the mothership. FreeBSD can do everything pfSense does without a web interface.
This wasn't a case of us not knowing how to configure stuff in the OS, we moved from configuring OpenBSD firewalls with pf+pfsync, ipsec+sasync and carp to pfSense because it just made it easier to deploy and configure, given we had about ten or more of these we maintained for customers.
Even recently at a new job we were talking about upgrading or replacing some HA FreeBSD firewall pairs, and I was suggesting pfSense because it's simple to use, and just BSD underneath. Given what I've learned in this thread about the state of the project and company behind them now, I don't think I would recommend it anymore, but I still think a similar project with similar features has something to offer over vanilla BSD.
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#157Earlier quoted context omitted.
Is that based in any way on the relative capabilities and security track records of OpenWRT and pfSense, or is a highly security-conscious userbase merely what's left for pfSense after eliminating anyone who wants good WiFi support and the ability to run on cheap commodity consumer appliances with tight memory and storage limits?
Both I suspect. OpenWRT sacrifices safety to work on low power devices i.e. no https package updates.
opkg install wget ca-bundle
sed -i "s/http/https/" /etc/opkg/distfeeds.conf
Done. And now packages have cryptographic signatures verified and are downloaded over HTTPS.Are there other things pfSense can offer me? :)
(Thanks for giving me the push, btw)
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#158PSA: 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
Woah, I have been using pfsense for quite a while but never knew it was closed source until now.
With 2.6 they are basically diverging entirely. Albeit they are still trying to argue they are foss.
The issue I have is if I’m going with an edge security appliance that has code that can’t be easily audited by security pros better than me, I’ll go with Pali Alto or Cisco who has entire branches and teams dedicated to security like Talos/snort. They are less succeptible to security errors and have a customer base that straight affects national security. So even Alphabet agencies will report exploits and 0days to them.
With their wire guard shenanigans it’s clear they are a small team and closing off the code base means I’m now relying on people that act this way to criticisms for security. I don’t really care about internet drama and it’s a reason I’ve stayed with pfsense to now. But pragmatically their choices mean I have to change. Which is okay too.
https://www.netgate.com/blog/painful-lessons-learned-in-secu...
https://old.reddit.com/r/networking/comments/m6zjie/wireguar...
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#159is there any linux equivalent of pfsense+freebsd ?
Re: In-kernel WireGuard is on its way to FreeBSD and the pfSense router
#160PSA: 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 dramas [0] between PFSense, OPNsense, and IPFire [1] always seems to come up. I ended up going with PFSense and it works fine. It's open enough that you can always dive in to figure out what's going on. Perhaps philosophically suboptimal, but for all practical purposes it's worked great for my home! [0] https://www.reddit.com/r/homelab/comments/dg2wme/opnsense_vs... [1] https://www.ipfire.org/
> Why fuck netgate?
> [deleted]
> Exactly this. Well said.
As a sidenote, can anyone recommend me a service which lets me see the contents of now deleted Reddit comments?