OPNsense Forum
Archive => 21.1 Legacy Series => Topic started by: TheLinuxGuy on January 19, 2021, 06:34:10 am
-
Hi,
I'm wondering if the 21.1 version may have the kernel module for wireguard rather than the golang version?
It seems like FreeBSD 13 will have it soon if https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-WireGuard-Lands is accurate.
-
Maybe 21.7 or 22.1 .. it depends on how fast backporting while be done.
-
See https://forum.opnsense.org/index.php?topic=20947.msg97702#msg97702
-
@Greelan: I stripped the taptalk redirect URL for the direct link. But thanks for linking, otherwise I would have done it :)
Cheers,
Franco
-
@Greelan: I stripped the taptalk redirect URL for the direct link. But thanks for linking, otherwise I would have done it :)
Cheers,
Franco
great thanks for the link. So if pfsense 2.5 includes it in FBSD 12 that would translate to opnsense adding it as well in the current FreeBSD 12 release and thus possibly coming on 21.1?
-
I think 21.1 would be hard to match, wouldn't it? Franco?
Otherwise with screenshots already posted by Netgate about Wireguard Kernel Module hitting the next pfSense 2.5 Snapshots (https://www.netgate.com/blog/wireguard-for-pfsense-software.html) I suppose backporting to FreeBSD 12.x stable should be almost (or already?) done :) Sooo perhaps we'll see it later on in 21.1.x or 21.7?
Looking forward to the first benchmarks between the three in a S2S scenario :)
-
If I rememeber correctly, Olivier tested it on FBSD13 and it was around 2,9Gbit while IPsec 2,6Gbit or so
-
21.1 is next week and more or less in freeze mode so that is a little out of scope, but 21.1.x seems possible if we can motivate Michael to bring this one home. ;)
Cheers,
Franco
-
I'm all in 8)
-
That sounds promising - both 21.1.x and the estimated throughput ;) Could put many IPsec scenarios out of business if you control both ends ;)
-
That sounds promising - both 21.1.x and the estimated throughput ;) Could put many IPsec scenarios out of business if you control both ends ;)
In one of our offices even wireguard-go already does. Throughput limited by provider bandwidth, delay *much* better than any other VPN protocol I tried.
-
I did these tests with older Intels (without microcode updates) and wireguard-go was really close to IPsec (compared to OpenVPN):
https://www.routerperformance.net/comparing-opnsense-vpn-performance/
-
I'm all in 8)
Where do I donate beer money or late late `git push` energy drinks :P
-
I have to disappoint, but Bavaria already has all the beer in the world to push through. ;D
Cheers,
Franco
-
Just discovered I have a small brewery nearby. Bergfeld Beer :)
-
I have to disappoint, but Bavaria already has all the beer in the world to push through. ;D
Cheers,
Franco
I'm sure a pizza would help soak up the beer, so he can get through all this beer easier 😋
-
For those of us using wireguard via the plugin will it be possible to migrate the setup to this new method? I have quite a few devices setup using the normal current method.
-
We try to add a checkbox if required
-
For those of us using wireguard via the plugin will it be possible to migrate the setup to this new method? I have quite a few devices setup using the normal current method.
Came here to ask this.
-
What I mean is can the current config in the plugin be migrated to the native version when its released so i dont have to reconfigure all my devices in the wild?
-
Sure, everything important is saved in config.xml, rest is magic :)
-
I believe since the only difference is crypto offload to kernel a checkbox should be all the user-facing settings for this and the rest keeps working (even if the configuration needs to be rearranged underneath, plugin job, not user job).
Cheers,
Franco
-
Thank you.
-
Sorry to ask... did this get implemented in Opnsense already?
-
No
-
:D
thatswhy I always try to ask open-ended question, that cannot be answered by a single word
-
Backport of the FreeBSD-CURRENT state is done now:
https://github.com/opnsense/src/commit/bb8e65da8e
Cheers,
Franco
-
Great...so it is included in 21.1.3?
-
Define "included". The kernel patch doesn't help anyone with the wireguard plugin yet so rushing this is not useful and creates false expectations.
Furthermore, due to complications in iflib code we will not be targeting 21.1.3 to avoid unnecessary changes in functional areas at this point.
Cheers,
Franco
-
Whoopsie... https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-New-WireGuard
Cheers,
Franco
-
Fail. I remember reading a mailing list thread some months ago where, after learning that Netgate was working on a port, Donenfeld reached out to ask them to collaborate. The Netgate dev seemed strangely resistant. Can’t readily put my hands on the thread again but it was eye-opening
Edit: found it - https://lists.freebsd.org/pipermail/freebsd-net/2020-February/055414.html
-
Define "included". The kernel patch doesn't help anyone with the wireguard plugin yet so rushing this is not useful and creates false expectations.
Considering the Netgate cowboy kernel module fiasco, I will gladly take this approach any day of the week.
To say this is scathing is being kind.
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006494.html
-
Define "included". The kernel patch doesn't help anyone with the wireguard plugin yet so rushing this is not useful and creates false expectations.
Considering the Netgate cowboy kernel module fiasco, I will gladly take this approach any day of the week.
To say this is scathing is being kind.
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006494.html
;D
-
Is there any estimate on when OpnSense will have Jason's implementation of WG ? I'm currently fine with OpenVPN, but looking toward WG.
-
Hmmm, as the cowboy wrote in his rant, Netgate will block any secure and reliable kernel implementation of wg.
So it would be HardendBSDs turn to implement that. Maybe we should start a fund-raiser here? I would be happy to do some testing, if necessary...
-
Is there any estimate on when OpnSense will have Jason's implementation of WG ? I'm currently fine with OpenVPN, but looking toward WG.
OPNSense already has it via the official Go module. It’s not kernel based which is slightly (very slightly) slower, but it’s secure and MUCH faster than anything else out there. Go Wireguard with reckless abandon now on OPNSense.
-
Wow netgate wireguard implementation reads great.
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.
-
Things are still developing in real time it seems. One thing that stands out is that Netgate owns this debacle and has a lot of pull (money) in FreeBSD that it can get away with the initial merge. Then it tries the same approach when the WireGuard author works on FreeBSD improvements to get WireGuard out of all the source trees because they say so?
I mean we have this disaster now but we want to still trust the same people to solve the situation by making it worse after it got better? FreeBSD has a structural issue within its ranks that it needs to address. It only hurts the FreeBSD reputation as a whole to let this situation continue into the next couple of years.
For now we will merge whatever upstream work is going into the kernel module no matter if it is removed over there at some point or not. We can always trust in the available userland implementation. ;)
Cheers,
Franco
-
Guys .. you need to read the answer of Jason to what Scott wrote him directly ... somebody bring popcorn please ..
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006499.html
-
Guys .. you need to read the answer of Jason to what Scott wrote him directly ... somebody bring popcorn please ..
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006499.html
Bavaria is a little late to this party, see the posts above :-p
-
6499 is a different one .. not everyone goes to threads and look at the replies in the archives, and this reply is even more joy to read ;)
-
Ok, we need a cross-link for you ;-p
https://forum.opnsense.org/index.php?topic=22081.msg104688#msg104688
-
...at least the trash is gone from the kernel, hope to see something better soonish
https://lists.zx2c4.com/pipermail/wireguard/2021-March/006504.html
-
That means Netgate convinced FreeBSD to do what Scott Long suggested. Oh man, get ready for more shit in the next couple of years. This is just the beginning of the drama.
Cheers,
Franco
-
That means Netgate convinced FreeBSD to do what Scott Long suggested. Oh man, get ready for more shit in the next couple of years. This is just the beginning of the drama.
Cheers,
Franco
I'm not sure which is worse, that Netgate rammed their broken implementation of Wireguard into FreeBSD a few weeks before a release, expecting it to be part of the release, or that FreeBSD let them. It's amazing.
-
is there an alternative BSD? or only way to go linux as a basis?
-
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.
-
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...
-
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
-
This has all the sounds of an immense implosion... Plus the sounds of feet rushing to another project like OPNsense
-
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...
-
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? ;)
-
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
-
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 ...
-
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)....
-
For posterity's sake:
https://web.archive.org/web/20210316222619/https://www.netgate.com/blog/painful-lessons-learned-in-security-and-community.html
-
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
-
Oh, the blog post from Scott Long got pulled already? It's hard to keep up.
Cheers,
Franco
-
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.
-
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.
-
For the sake of completeness
https://www.reddit.com/r/PFSENSE/comments/m5shda/wireguard_in_freebsd_13/
https://www.reddit.com/r/PFSENSE/comments/m6k20q/painful_lessons_learned_in_security_and_community/
and
https://www.reddit.com/r/PFSENSE/comments/m6zcml/netgate_appears_to_have_removed_scotts_latest/
-
Back in 2014, I got a real bad feeling that the project might go sideways with the new owner‘s attitude. https://forum.netgate.com/topic/68346/was-re-developersbootstrapanddeviso-guide-missing-now-more-random-hate/3?_=1616007208751
-
Oh, that was a classic Jim moment for sure. What wild discussions we had regarding licensing and availability of source code (pfsense-tools) back then. Does anyone remember the "ESF" license?
https://www.pfsense.org/ESF_License_Agreement_v1.2.pdf
On positive note Jason is still dashing forward. https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html
-
For those not-so-deep inside the sheepfencing Netgate story: Gonzopancho is Jim Thompson
https://www.linkedin.com/in/jimthompson7
...and btw doktornotor is... special... :-D
https://github.com/doktornotor/pfsense-still-closedsource
-
For those not-so-deep inside the sheepfencing Netgate story: Gonzopancho is Jim Thompson
https://www.linkedin.com/in/jimthompson7
...and btw doktornotor is... special... :-D
https://github.com/doktornotor/pfsense-still-closedsource
Running a business, you have to deal with special customers. Back then, reading that, I decided for myself that I should probably stay away from being "on the customer end" with them.
Great to see that the WG developer is working on a speedy implementation! Looking forward to replace my Linux box at some point and run WG on OPNsense.
-
We are making progress... https://github.com/freebsd/freebsd-ports/commit/e2b5b355f64b
As far as I understood the latest code it supports the native wg commands so that we can start testing this soon with the existing plugin.
Cheers,
Franco
-
Good news Franco,
let us know when it's time and let's test the experimental Wireguard kernel module.
Then we will see if everything will be good.
Greetings from Germany
-
let us know when it's time and let's test the experimental Wireguard kernel module.
Then we will see if everything will be good.
2nd to this. Thanks Franco.
--
Stay safe.
-
Still a bit to manage around the wireguard-tools, but the wireguard-kmod package is already where it should be. Then last step is a development version of the plugins that can handle the kernel module. Maybe we can start public testing when 21.1.5 arrives.
Cheers,
Franco
-
Ars put out a well balanced investigation and summary of this whole mess:
https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
-
From ars article
Empty validation function
In order to confirm or deny the claim of an empty validation function—one which always "returns true" rather than actually validating the data passed to it—we searched for instances of return true or return (true) in Macy's if_wg code, as checked into FreeBSD 13.0-HEAD.
root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir 'return.*true' . | wc -l
21
This is a small enough number of returns to easily hand-audit, so we then used grep to find the same data but with three lines of code coming immediately before and after each return true:
root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir -A3 -B3 'return.*true' .
Among the valid uses of return true, we discovered one empty validation function, in module/module.c:
wg_allowedip_valid(const struct wg_allowedip *wip)
{
return (true);
}
It's probably worth mentioning that this empty validation function is not buried at the bottom of a sprawling mass of code—module.c as written is only 863 total lines of code.
We did not attempt to chase down the use of this function any further, but it appears to be intended to check whether a packet's source and/or destination belongs to WireGuard's allowed-ips list, which determines what packets may be routed down a given WireGuard tunnel.
and
Printf in crypto loops
Some pfSense 2.5.0 users reported strange hexadecimal output spamming the root console of their router. This matches Donenfeld's description of printf statements deep in crypto code, and we were able to easily discover the source in much the same way we found the empty validation function above.
-
Adding some more contents, hopefully from the closest to FreeBSD it can be:
https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057127.html
Dear FreeBSD Community,
In light of the recent commentary on FreeBSD's development practices,
members of the Core team would like to issue the following statement.
Code quality is an essential FreeBSD value: From the 1980s when work on
BSD became the de facto standard TCP/IP stack, to our more recent work
around performance scalability on multicore, attention to detail is
critical. The recent concerns regarding the WireGuard patches remind us
that our development processes must always continue to mature. While the
project has historically, and aggressively, led the way in adopting new
development methodologies - from public version control to being early
adopters of static analysis tools such as Coverity - these events have
brought to light a real gap that needs to be addressed.
The high stability and quality of FreeBSD is a testimony to the
experience of our developers. As in any open source project, we rely on
developers to exercise good judgement in seeking review and committing
new features, and to follow the guidelines laid out in the Committer's
Guide. We make heavy use of public code review, and FreeBSD developers
spend a significant amount of time improving each others' contributions.
We were excited to provide a kernel WireGuard implementation in FreeBSD
13.0. Before the if_wg(4) rewrite was committed, several FreeBSD
developers proactively worked on fixing bugs and writing tests and
documentation for the original implementation. In other words, we had
spent time during the release's Q/A period looking for problems, and
that unfortunately culminated in if_wg(4) being removed from 13.0 during
the release cycle. As FreeBSD developers, it is incumbent on each of us
to support each other's work by providing code review and helping test
and fix the code. This incident highlights the need to do this work more
proactively, and to maintain a robust, multi-layered development process
that can catch problems as they fall through the cracks.
Over the next month the FreeBSD Core Team will lead a discussion on
appropriate pre-commit testing, static analysis, code review, and
integration policies to avoid a repeat of this situation and to continue
improving FreeBSD's code quality. We know there will be challenges in
key areas, such as third-party device drivers, and components of the
system where fewer developers have sufficient expertise. The FreeBSD
Foundation has full-time staff members participating in significant code
review today, and is committed to supporting the needs identified by the
Core team and the developer community for this effort.
We look forward to input from the community on our proposals for updated
policies as we move forward, maintaining high code quality as a core
value for FreeBSD.
Thanks,
-Mark, with core@ hat on
-
Well, again, this is not a code quality issue... it's a management issue:
Before the if_wg(4) rewrite was committed, several FreeBSD
developers proactively worked on fixing bugs and writing tests and
documentation for the original implementation. In other words, we had
spent time during the release's Q/A period looking for problems, and
that unfortunately culminated in if_wg(4) being removed from 13.0 during
the release cycle.
The conclusion is really weird. Either they didn't know what they were looking for or they didn't care. Mind you some of these proactive developers were also sponsored by Netgate which then gets to decide to pull WireGuard from the kernel forever after it got fixed if we can trust Scott Long who is a Netgate employee and a FreeBSD core member whose duties do not overlap according to Netgate interview in the Ars article... ;)
Pulling it from 13.0 release is ok, pulling it out of the development tree for 14.0 or a potential backport of 13.1 is insane if you think about all the work that was done to get it there in the first place.
Cheers,
Franco
-
Pulling it from 13.0 release is ok, pulling it out of the development tree for 14.0 or a potential backport of 13.1 is insane if you think about all the work that was done to get it there in the first place.
It's in ports now, which is a perfectly sane approach in my book:
https://svnweb.freebsd.org/ports/head/net/wireguard-kmod/
-
The big question to me: Is pfsense 2.5 safe to be run with this trash code on board? I still have one running, which has to be updated soon... :-/
The image is still the old one published in February. Anyone seen efforts to remove the trash code from daily snapshots of 2.5.1?
-
The big question to me: Is pfsense 2.5 safe to be run with this trash code on board? I still have one running, which has to be updated soon... :-/
As long as you don't run WireGuard ... ;)
-
It's in ports now, which is a perfectly sane approach in my book:
https://svnweb.freebsd.org/ports/head/net/wireguard-kmod/
I know, it's going to be available for early bird testing in 21.1.4 ;)
https://github.com/opnsense/tools/commit/7fbb0fc74cb6
Cheers,
Franco
-
The big question to me: Is pfsense 2.5 safe to be run with this trash code on board? I still have one running, which has to be updated soon... :-/
As long as you don't run WireGuard ... ;)
...but that was the plan... :-(
-
Any idea when 21.1.4 will ship? :) No worries if you can't say.
-
I can quite possibly say tomorrow :D
Cheers,
Franco
-
I can quite possibly say tomorrow :D
Cheers,
Franco
There will be no problems for users of the WG-GO implementation?`:-)
-
All we did was add wireguard-kmod to the binary packages without tying it a plugin or core. So as far as 21.1 is concerned nothing changes about WireGuard in production.
Cheers,
Franco
-
Now that 21.1.4 has released, how do you transition to the kernel wireguard module? Do you have to uninstall wireguard-go first? Thanks.
-
Im using if_wg.ko at the moment and i must say im impressed.
Im maxing out my 400/200 Mbit/s line with absolutely 0 issues.
(https://i.imgur.com/wpyBQxo.png)
On the download speed test i see the following system load:
CPU: 1.8% user, 0.0% nice, 15.3% system, 33.4% interrupt, 49.6% idleThats on a Intel(R) Celeron(R) J4115 CPU @ 1.80GHz (4 cores)
If you want to try it yourself on 21.1.4, all i did was the following:
pkg install wireguard
reboot (not strictly needed but cant hurt)
wg-quick down wg0
wg-quick up wg0
Verify that if_wg.ko is loaded with kldstat and check top or ps so that no wireguard-go process exists.
Nice work from the upstream devs and huge thanks to @franco for including it as a port!
Edit: See https://forum.opnsense.org/index.php?topic=20978.msg106204#msg106204 for the numbers i had before on wireguard-go.
-
What was your throughput before?
-
What was your throughput before?
~400 but i maxed 2 cores of the cpu during these peak times, im gonna switch back and update this post later!
Edit:
CPU: 29.7% user, 0.0% nice, 27.5% system, 33.5% interrupt, 9.3% idle
Mem: 1078M Active, 48M Inact, 568M Wired, 296M Buf, 14G Free
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
40505 root 12 52 0 715M 27M uwait 3 0:29 222.05% wireguard-go
Thats a hefty reduction in resource usage!
-
Nice! Wanna have--- :-D
-
It looks like removing wireguard-go from the command line removes os-wireguard (which includes the UI interface for wireguard). Any way to remove this dependency?
[root@OPNsense ~]# pkg delete wireguard-go
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):
Installed packages to be REMOVED:
os-wireguard: 1.5
wireguard-go: 0.0.20210323,1
Number of packages to be removed: 2
The operation will free 3 MiB.
Proceed with deinstalling packages? [y/N]
-
Do not remove wireguard-go its not needed in order to use the kmod.
Just install the kmod using the wireguard meta package, wg will automatically pick if_wg if its available.
See my post for more details
-
Cool, I managed to get the kernel module to work, was able to maintain 900Mbit/sec through the tunnel with iperf3 running on the firewall. I have to believe load will be lower if I just route through it.
-
Keep in mind that's currently considered an experimental drop in replacement.
We will work on the plugin integration first then see what we need to do on the kernel side. Jason published a TODO list:
https://git.zx2c4.com/wireguard-freebsd/tree/TODO.md
Cheers,
Franco
-
please dont break my wireguard plugin install when it changes over to a new way - I rely on it daily. Would be a nightmare to reconfigure all deployed clients.
-
Nothing changed in the way OPNsense WireGuard (go) works. We are looking into reports that the upstream WireGuard tooling has issues in its latest update but too early to tell and several users reported WireGuard works fine on 21.1.4 using go or experimental kmod.
Cheers,
Franco
-
Nice throughput! :)
Tested with a MacBookPro 2020 M1 using a 2.5G adapter, connected to the OPNsense WAN network.
OPNsense runs on a Proxmox host with an i3-7100 CPU using Virtio ethernet. Mainboard is Supermicro with 2 10G SFP+ (Supermicro card).
-
I'm very curious about the kernel implantation of Wireguard and I have already tried it out and was able to nearly max out my 1gbit connection on a AM4 200GE. I am really loving the performance of Wireguard so far, and even more the kernel version, however the only downside so far I have noticed playing around with Wireguard so far is that you can't use two Wireguard connections on two different Wan interfaces. Currently Wireguard will always use the default gateway no matter what you'll do. I am wondering if it would be possible to implement dual Wan support with the new kernel version?
-
Jason told me it should work now
-
Jason told me it should work now
This is great to hear. This also means load balancing with two Wireguard connections should be possible then too right? Would love to try this out at some point.
-
Just install the kmod package and reboot, then it should be fine.
-
Hi all,
I have to say this worked beautifully for me, I tried this out using 3 WireGuard connections in a Gateway Group on a 1Gbps up/down line. Was not able to get over around 400MBps down before and CPU was maxed out, now it is peaking around 900Mbps. CPU still fluctuates, but it seems like the speed is much better :D
https://ibb.co/Sy6pnXz
https://ibb.co/Vm9pXkJ
https://ibb.co/cNf0Ryq
Be careful what speedtest binary you are using, I was originally trying alpine linux package and the results were nonsensical around 150Mbps, these results are using Ookla 1.0.0.2 (5ae238b). Thanks to all who put in their hard work on this.
-
Glad to hear it working great for you. I also find it worth using a known good speedtest server.
I usually try and use http://ovh.net as I know all their test locations are 10gbit connections, if speedtest.net is looking to give odd/varying results.
-
Glad to hear it working great for you. I also find it worth using a known good speedtest server.
I saw you have a script for PIA, curious if you were able to get port forwarding working using the new kernel mod with PIA, and if so how? :)
-
Glad to hear it working great for you. I also find it worth using a known good speedtest server.
I saw you have a script for PIA, curious if you were able to get port forwarding working using the new kernel mod with PIA, and if so how? :)
Port forwarding works and its mentioned at the bottom of my Scripts README :)
-
Port forwarding works and its mentioned at the bottom of my Scripts README :)
Ok thanks for confirming, I have been unable to get it working, if you wouldn't mind sharing your rules (https://forum.opnsense.org/index.php?topic=22856.0) I would appreciate it.
-
Glad to hear it working great for you. I also find it worth using a known good speedtest server.
I usually try and use http://ovh.net as I know all their test locations are 10gbit connections, if speedtest.net is looking to give odd/varying results.
"ovh.net" does not even open for me in the browser, is that a public speedtest service by the way?
-
Glad to hear it working great for you. I also find it worth using a known good speedtest server.
I usually try and use http://ovh.net as I know all their test locations are 10gbit connections, if speedtest.net is looking to give odd/varying results.
"ovh.net" does not even open for me in the browser, is that a public speedtest service by the way?
I get https by redirect, but it's unsecure as only ssl 1.0 and 1.1 are supported. Not worth the hassle....