Installing WireGuard VPN
-
@musicwizard said in Installing WireGuard VPN:
.A lot of people don't know about it or not enough to want it in pfSense. All they see that it doesn't have it. And if it get pitched that its MUCH better then IPSEC and OpenVPN people will start using it.
I don’t agree that wireguard will ever be faster or better than IPSec. OpenVPN is a different question.
- We already have AES-NI accelerated AES-GCM IPSec in pfsense and FreeBSD. Netgate developed this.
- We have async crypto, where all the cores can be used for AES operations. Stormshield developed this.
- We have routed IPSec, courtesy of Yandex.
In each of these cases, Netgate or other companies paid employees to do the work. In each case Netgate subsequently paid its employees to integrate the work into pfsense, then document and test the result.
When it comes to wireguard, it’s completely provable that it can’t be faster than AES-GCM IPsec unless your hardware doesn’t support AES-NI. I am aware of Jason’s published numbers, but these are problematic as they show throughout of 1011Mbps on a 1Gbps NIC. See: https://www.wireguard.com/performance/
Further, Wireguard has two bytes more framing overhead than IPSec using AES-GCM, so with perfectly matched implementations and crypto, they will be roughly the same speed.
There is also a report out of Germany that shows IPSec faster than wireguard, and both far faster than OpenVPN.
https://www.net.in.tum.de/fileadmin/bibtex/publications/theses/2018-pudelko-vpn-performance.pdf
And someone on Reddit got 5Gbps between two machines with 10G NICs
https://www.reddit.com/r/linux/comments/9bnowo/wireguard_benchmark_between_two_servers_with_10/In the same post, the author reported 230Mbps on the same setup using OpenVPN with AES-GCM.
We already have shown 42gbps IPSec with tnsr (limited by the offload cards) and 13gbps on a single core (just using AES-NI) over 40gbps NICs, so we can easily fill a 10gbps NIC using IPSec. That work is done, and is available in tnsr today. We’re working on showing 100gbps IPsec, and I doubt that wireguard will ever go that fast, not without hardware offload for the ChaCha20-Poly1305 AEAD, anyway.
For hardware that supports AES acceleration, AES-GCM is the preferred bulk encryption algorithm in TLS. This is primarily due to performance. For hardware that does not have AES acceleration, ChaCha20-Poly1305 is much faster(~400%) than any AES-based cipher.
Since AES-GCM and ChaCha20-Poly1305 are mature encryption modes (and provide equal bits of security), the choice is really about performance.
https://gist.github.com/raycoll/62a660602b9ec9fb67b6443f16732080
So even in the best case, wireguard won’t be faster than IPsec for a number of reasons.
Thats the current state of play on performance, except to note that the current tun/tap based implementation available for FreeBSD will never be as fast as a kernel based implementation, so until a kernel implementation happens for pfsense & FreeBSD, wireguard will be about as fast as OpenVPN.
The other huge issue right now is that that the tun/tap implementation is very unstable, and I don’t think sending an unstable implementation of wireguard into the installed base is good for pfsense. This said, there is a NetBSD kernel implementation that’s in development, so we’re not dependent on the tun/tap version, and this should be both more performant and, hopefully, stable.
But, of course, people who are able to do this type of work, like the rest of us, enjoy being able to earn a living. They’d like to be paid to do the import and development of such a kernel-resident wireguard implementation for FreeBSD. The money to pay them has to come from somewhere.
Thus my query, which is now rudely responded to, especially in light of the millions of dollars invested in pfsense by Netgate over these past 12 plus years.
Turning to other factors, wireguard has no crypto agility. If the algorithms it uses are ever broken, the entire protocol must be replaced. This is a real risk, and one that bears consideration, as IPSec and OpenVPN do not share this risk. Some of wireguard’s praise is for its “simplicity”, and this lack of agility is one reason for the simplicity of the wireguard codebase in comparison to those of IPSec and OpenVPN.
Net-net: I do agree that wireguard is on a path to usurp OpenVPN. I don’t agree that it will replace IPsec.
And mostly Companies will need/want support so indirectly you might sell more subscriptions.
Support subscriptions are interesting, and we love all our customers, but we make pfsense good enough that most people, when asked, say they don’t need our support services.
Appliance sales cloud images, and support subscriptions are where the money comes from that pays for pfsense development.
Those who take what we make (*), load it on a hardware appliance and sell the result directly interfere with our business and thus our ability to continue to invest in these types of technology.
(*) and give to the community for free, as well as publish the source code
-
veeam started using it https://www.veeam.com/blog/veeam-pn-v2-wireguard.html
-
@jwt Hi, with all that said and all cool, 3 things remain IMO:
- For one, if WireGuard is nearly as fast as IPSEC, but without the configuration and implementation mess IPSEC brings (which is one of the most important reasons - if not the reason - why OpenVPN became so popular in the first place - the main reason being, that ESP or ESP over UDP can be a pain to setup, especially for mobile / NAT clients, as we all know), it's very well worth considering as soon as possible. Until now we had to trade ease of use and flexibility with performance - it looks like this tradeoff might finally be ended by/with WireGuard.
- WireGuard is now reaching more beta than alpha state, with clients available with more and more platforms (including mobile).
Implementing a package as early as possible (with according caution warnings and disclaimers until it reaches maturity) for PfSense does make sense (double-sense :D), because it would enable very valuable feedback and experience reports from early adopters, both for WireGuard and, more importantly, for its usage within PfSense itself. - As WireGuard attracts more and more attention in the sector, having it in PfSense means that this can be leveraged in PfSense marketing too.
Best Regards, and thanks for the huge work so far.
LP
-
Wireguard @pfSense would be pure awesomeness.
-Rico
-
-
there is no telling if WG will be as fast as IPSec. Certainly the implementation over tun/tap is not, and can not be
-
config for IPSec with pfsense is already easy
-
OpenVPN got big because you can do things like policy routing with it, performance sucks compared to IPSec.
-
-
@lopezio said in Installing WireGuard VPN:
@jwt Hi, with all that said and all cool, 3 things remain IMO:
- For one, if WireGuard is nearly as fast as IPSEC, but without the configuration and implementation mess IPSEC brings (which is one of the most important reasons - if not the reason - why OpenVPN became so popular in the first place - the main reason being, that ESP or ESP over UDP can be a pain to setup, especially for mobile / NAT clients, as we all know), it's very well worth considering as soon as possible. Until now we had to trade ease of use and flexibility with performance - it looks like this tradeoff might finally be ended by/with WireGuard.
- WireGuard is now reaching more beta than alpha state, with clients available with more and more platforms (including mobile).
Implementing a package as early as possible (with according caution warnings and disclaimers until it reaches maturity) for PfSense does make sense (double-sense :D), because it would enable very valuable feedback and experience reports from early adopters, both for WireGuard and, more importantly, for its usage within PfSense itself. - As WireGuard attracts more and more attention in the sector, having it in PfSense means that this can be leveraged in PfSense marketing too.
Best Regards, and thanks for the huge work so far.
LP
- WireGuard is UDP
- WireGuard is quite messy to set up
- There's no authentication backend, so for client / server VPN it's no fun.
Try it out yourself and you'll stick to OpenVPN :) Imagine, it's only public/private key .. how do you transfer them? How do you change them (both sides)? Did you try to add a base64 key into your mobile? You need QR implementation etc.
-
Public key means you can transfer your public key in the clear. Super easy transfer of keys.
-
@mephisto said in Installing WireGuard VPN:
veeam started using it https://www.veeam.com/blog/veeam-pn-v2-wireguard.html
Yeah Veeam guys play around on many grounds but not seldomly fail to play stable. It's nice to adapt new tech but you should be able to bring it stable. Also they are playing with it on Linux. As already pointed out: Linux version is a whole other playing field with their implementation status in Kernel etc.
BTW we played with "early implementations" of wireguard on FreeBSD and even took a HW like the SG-5100 (similar hardware) and installed OPNsense and their take on Wireguard. Installation/Configuration was messy (but everyone always blabs about the super-easy configuration
) and didn't work at first. At last we could stabilize it to make some tests and an IPerf test ran below even OpenVPN speeds. As stated: nice to play around but not merely stable/mature enough for it to be enterprise ready. And that's the biggest problem I see with "early adapting Wireguard": if it goes into main-pfSense core now with the buzz and hype everyone pushes around, people/companies are likely to try it without realizing, that the code/implementation on FreeBSD at least are still in an (early) alpha state and not stable/secure like IPSec and OpenVPN. Even the wireguard website tells that to everyone. Hiding that fact and just throwing it into e.g. the 2.5 release would show up to those users/companies as the software is ready to use. And for me (after our tests) it's clearly not. Especially if most of them would try to use it as RoadWarrior setup instead of using tunnels or meshes. For example we had one case, that the wirguard dial in wouldn't work anymore after an update on a client as the startup script and API call changed and some script wasn't adapted. So we had to fix it (or wait a day 'til the fixed version).TL;DR
Would love to see it in pfSense (core at some time) but only if mature enought to actually work securely and (reasonably) fast. -
yeap that is a very good point, I was comparing it to linux and freebsd implementation of it is far behind. Well I guess we can just hope some people can devote their time to help polishing the code so it can eventually becomes more stable on freebsd. Thanks for the clarification :)
-
This post is deleted! -
Why does that sound like a copy/paste marketing spam message? That kind of messaging isn't going to convince anyone.
The security review part was only one reason (not "excuse" -- a valid concern, and a valid reason), there are many others throughout the thread.
We are keeping an eye on it, but while most of that may be fine on Linux, last I saw, FreeBSD support was still not up to par.
-
That is pure spam dude ;) Do you want me to report it and delete it ;)
Well now another user has tagged it as spam jim - your call :) hehehehe
-
Locking this topic.
If and when the situation with Wireguard improves on FreeBSD, it can be revisited. Adding it before it's ready will lead to even more complaints and problems. Its status on Linux or other projects is irrelevant.
FYI- Insulting people, the project, or companies in general (especially via the reporting mechanism and not publicly) is not a tactic that will convince anyone that you are correct. In fact, it tends to have the opposite effect.
-
Remember when I said that there is a plan, but I’m not ready to reveal it yet?
Sometimes what you want takes longer than you hope, but I’m happy to report that the process of bringing a kernel-resident implementation of Wireguard to FreeBSD has begun to land changes in FreeBSD.
https://svnweb.freebsd.org/base?view=revision&revision=357986
https://svnweb.freebsd.org/base?view=revision&revision=357987
-
This is now finished. At lease phase one is finished.
https://www.netgate.com/blog/wireguard-for-pfsense-software.html
