Installing WireGuard VPN

[jimp]

@maglub said in Installing WireGuard VPN:

Given that wireguard already have a very strong following and is up for mainstream linux kernel adoption, I am not sure how to take on the sceptics in this thread.

Because FreeBSD is not Linux, and it does not have a proven track record of stability on FreeBSD.

Why not look into how to integrate this already now, and release it when it has the full blessing of everyone?

Because we don't want to introduce a potentially unstable and insecure new VPN into a security-focused project until it's ready.

[KOM]

@maglub Feel free to package it up yourself just like others have done with other unofficial pfSense packages like E2Guardian and Squidalyzer because no matter how much you complain, Netgate is not going to introduce some bleeding-edge, relatively-untested code that comes with a heap of not-ready-yet disclaimers into a project focused on security. Not going to happen.

[bobert]

Wireguard is the future, it is 4k lines of code and Linus Torvalds declared it a piece of art compared to IPSEC/OpenVPN and recommended it be merged into the kernel ASAP.

[jwt]

@bobert Wireguard May well be the future, but not for pfsense while it’s only available as a GPLed package over tun/tap. When Wireguard is available as a kernel-native implementation on FreeBSD (as it is on Linux), without the external dependencies on Go, we’ll integrate it in pfsense.

Also, just to clarify Linus’ quote:

“Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.”

[maglub]

It seems like there are some work going on for this:

https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113434.html

The thread sort of dies in May last year, and I will have to research a bit more.

The go-dependency is only during build time, not during runtime, so I don't think that should be an issue.

[Wordo]

It's already available and working in FreeBSD, but in some cases you get some crazy stack traces https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233955

[goodthings]

I hope somebody sacrifices their time for an external wireguard package soon, there's a lot of talk about it and I'd like to try it. To my surprise it already has native macOS and iOS clients in the respective app stores.

[Wordo]

Please read the whole thread .. your pfSense installation will crash with most of your service restarts. This is a problem of Wireguard implementation in FreeBSD (or FreeBSD kernel). Doesn't make any sense to build an "external package"

[musicwizard]

Time will tell but would be nice if it can get into PFsense in a official way.

[jwt]

There is a plan, but I’m not ready to discuss in public.

[jwt]

@goodthings iOS and MacOS are far larger installed bases than FreeBSD

[musicwizard]

@jwt now you make me very curious about it :)

[jwt]

@musicwizard Great! Now you have me very curious what you would pay to have Wireguard in pfSense.

[maglub]

@jwt, I would easily pay a million bucks or less.

What kind of question is that anyway?

Together with fleet management or scriptable configuration/REST, this must be one of the most important feature additions to pfSense in quite some time. And that is for a feature that preferably should be/must be in a non paid version of pfSense.

The project that manages to make wireguard even more mainstream, will be the defacto go-to product for many integrators, such as myself, which will lead to revenue in one way or the other.

If you are struggling for money, there are probably better ways to communicate it than in this thread.

Reading this forum, I get the feeling that if a user does not immediately prove that they are extremely competent (i.e if you have to ask about something, you are not), they get shot down.

For myself, I am actually not really sure anymore why I stay "loyal" to pfSense. Whenever I get the chance, I place Netgate hw at customers' sites, with the drawback that I usually have to stock a few in my basement as cold stand-by.

I really do believe that wireguard is a very strategic component of pfSense. Close to be an "implement or die" kind of feature.

IPSEC is just not stable enough cross platform. It is complex and not at all easy to debug. In customer situations I use it when I have to, if a remote party does not have the means to set up an openvpn tunnel.

Openvpn is a mess when it comes to multicast and streaming media, and is a cpu hog. To reach gbit speed you need hw for a couple of thousand bucks.

I have strong hopes for wireguard. If netgate manage to set up even a half buggy admin gui page for it, they will attract many new users, of which some will actually pay for support.

They should not treat non paying users as second class citisens, but rather embrace them (us) and se them as a gate to new paying customers.

[musicwizard]

@jwt said in Installing WireGuard VPN:

@musicwizard Great! Now you have me very curious what you would pay to have Wireguard in pfSense.

@maglub said in Installing WireGuard VPN:

@jwt, I would easily pay a million bucks or less.

What kind of question is that anyway?

Together with fleet management or scriptable configuration/REST, this must be one of the most important feature additions to pfSense in quite some time. And that is for a feature that preferably should be/must be in a non paid version of pfSense.

The project that manages to make wireguard even more mainstream, will be the defacto go-to product for many integrators, such as myself, which will lead to revenue in one way or the other.

If you are struggling for money, there are probably better ways to communicate it than in this thread.

Reading this forum, I get the feeling that if a user does not immediately prove that they are extremely competent (i.e if you have to ask about something, you are not), they get shot down.

For myself, I am actually not really sure anymore why I stay "loyal" to pfSense. Whenever I get the chance, I place Netgate hw at customers' sites, with the drawback that I usually have to stock a few in my basement as cold stand-by.

I really do believe that wireguard is a very strategic component of pfSense. Close to be an "implement or die" kind of feature.

IPSEC is just not stable enough cross platform. It is complex and not at all easy to debug. In customer situations I use it when I have to, if a remote party does not have the means to set up an openvpn tunnel.

Openvpn is a mess when it comes to multicast and streaming media, and is a cpu hog. To reach gbit speed you need hw for a couple of thousand bucks.

I have strong hopes for wireguard. If netgate manage to set up even a half buggy admin gui page for it, they will attract many new users, of which some will actually pay for support.

They should not treat non paying users as second class citisens, but rather embrace them (us) and se them as a gate to new paying customers.

I do agree with you on that one @maglub If Wireguard gets integrated into pfSense standard or by addon it will attract many new users. Even small/medium companies etc would want it.

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. And mostly Companies will need/want support so indirectly you might sell more subscriptions.

[Wordo]

Oh boy .. if IPSec is too complicated you never had setup WireGuard in production. It's way different than IPSec AND OpenVPN. Also key exchange is quite pain if you don't use QR ...

[jwt]

@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

[mephisto]

veeam started using it https://www.veeam.com/blog/veeam-pn-v2-wireguard.html

[lopezio]

@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

[Rico]

Wireguard @pfSense would be pure awesomeness.

-Rico