Installing WireGuard VPN

juppin

Hello pfSense community,

as i have many mips routers as OpenVPN client boxes and the best router with a dual core mips 1004k 880 MHz cpu does only reach a max throughput of 15MBit/s on aes256-gcm.
The limitation / bottleneck is the user space implementation of OpenVPN, WireGuard does run almost in kernel space and does not need that much context switches.

Some guy in the lede-project.org forum reported that with WireGuard VPN the throughput is about 80 MBit/s with such a low powered mips router.

I thought about trying wireguard on my pfSense (FreeBSD) gateway...

WireGurad was ported in may 2018 to FreeBSD, so it should be possible to get this running on pfSense...
Info from FreeBSD mailing list: https://lists.freebsd.org/pipermail/freebsd-ports/2018-May/113434.html
Package: https://www.freshports.org/net/wireguard/

Is there anyone that has tried to install WireGurad from a non pfSense repo?
Is there anything that i should consider to install it from non pfSense package repos?
As i see there is only the dependency of bash and this is already included in pfSense...

Would be great to see a pfSense Package for WireGuard soon :-)

Greets

ekke

This is a high priority feature!

johnpoz

It is? Wow didn't know you were part of the development team and or steering committee of netgate/pfsense ;)

Pretty strange 1st post for someone so well connected.

Did you mean to say you would would like to see this as well ;)

ekke

Naturally I only speak for me self , aswell as everyone else except those with official mandate for a specific group :)

jimp

It will never be a "high priority feature" until they actually make a proven secure/stable release.

https://www.wireguard.com/#about-the-project

About The Project
Work in Progress

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots.

However, if you're interested in helping out, we could really use your help and we readily welcome any form of feedback and review. There's currently quite a bit of work to do on the project todo list, and the more folks testing this out, the better.

It may be fast, but that means nothing with all of those disclaimers around it.

juppin

https://www.xda-developers.com/us-senator-pushes-government-use-wireguard-vpn/

jimp

@juppin said in Installing WireGuard VPN:

https://www.xda-developers.com/us-senator-pushes-government-use-wireguard-vpn/

A member of the US Government endorsing it that enthusiastically could just as well mean they have backdoored the encryption or that it has a known flaw they can exploit.

It's just not ready for prime time yet. Give it time to mature, get audited properly.

Pushing this hard for it only makes it seem even more suspicious.

Wordo

This comes when starting wg-quick on FreeBSD:

[#] wg-quick tun
WARNING WARNING WARNING WARNING WARNING WARNING WARNING
W G
W This is alpha software. It will very likely not G
W do what it is supposed to do, and things may go G
W horribly wrong. You have been warned. Proceed G
W at your own risk. G
W G
WARNING WARNING WARNING WARNING WARNING WARNING WARNING

jwt

As OP pointed out, there is a Wireguard port for FreeBSD (but not pfSense, yet). Note that this port has dependencies on Go and bash and uses an implementation (in 'Go') over tun. There is a thread on the FreeBSD mailing lists with more info.

Further through that thread, there is a performance claim that Wireguard on FreeBSD 'seems to be faster than OpenVPN'. Note that the posting doesn't say how much faster.

There may be some flaw in their benchmarking, as the Wireguard site claims 1011mbps on a 1gbps Ethernet NIC using iperf3. As previously discussed on this forum, reddit and elsewhere, it's impossible to pass more than 949mbps over IPv4 and TCP on a 1gbps NIC.

Max payload on Ethernet is 1500 bytes (yes, I know these are actually octets).
Preamble + SFD = 8 bytes
MAC DST + SRC = 6 bytes each for 12 bytes.
Ethernet Type = 2 bytes
FCS = 4 bytes
Intra-Frame Gap = 12 bytes of (otherwise empty on the wire) time.

1500+8+12+2+4+12 = 1538
Sending TCP over IPv4 consumes another 20 bytes each for the IPv4 and TCP headers. Thus, we can send 1460 bytes of TCP for 1538 bytes 'on the wire'.

1460/1538 = .94928, so max throughput possible with iperf3 over TCP and IPv4 on a 1gbps NIC is 949.28mbps.

According to this post by the primary author of Wireguard:

The overhead of WireGuard breaks down as follows:

 20-byte IPv4 header or 40 byte IPv6 header
   8-byte UDP header
  4-byte type
  4-byte key index
  8-byte nonce
  N-byte encrypted data
 16-byte authentication tag

So, if you assume 1500 byte ethernet frames, the worst case (IPv6)
winds up being 1500-(40+8+4+4+8+16), leaving N=1420 bytes. However, if
you know ahead of time that you're going to be using IPv4 exclusively,
then you could get away with N=1440 bytes.

Modifying the math above, for a 1440 byte inner frame, and adding the 38 bytes of headers (and time) on Ethernet, we get to send 1440 bytes/1538 bytes. If the inner packet is TCP over IPv4, then an additional minimum of 40 bytes will be used for the inner IPv4 and TCP headers.

The result is that we send 1400 bytes of TCP payload and additional overhead totaling 1538 bytes on the wire at 1gbps, so the maximum bandwidth obtainable using Wireguard is 1400/1538 x 1gbps or 910.27mbps.

Moving on, the packet overheads for IPsec are actually ever so slightly lower than for Wireguard.

Additional overhead from ESP includes 20 bytes for an outer IP header, 8 bytes for an ESP header, 2 bytes for padding length & next header type, 16 (AES-CBC) or 8 (AES-GCM) bytes for an initialization vector, and 12 (HMAC-SHA1) or 16 (AES-GCM) bytes for an integrity check value. The total extra overhead is 58 bytes (AES-CBC HMAC-SHA1) or 54 bytes (AES-GCM).

Thus your 1460 becomes 1404. 1404 / 1538 = .9128, and we see that AES-GCM won’t flow more than 912.8mbps. For AES, CBC mode requires padding input to the block size, thus GCM mode produces smaller output if input is not multiple of block size. I may be flubbing something with required multiple of 16 bytes and padding for CBC:

    87*16 = 1392
    88*16 = 1408

so it might be (and probably is) 1392/1538 or 905.07mbps. It's far too late at night to dive much deeper and figure out which is true. In either case, the actual protocol overheads for both Wireguard and IPsec are incredibly similar, so there isn't a protocol advantage for either.

If you skipped past all that, the summary is:

    Wireguard protocol overhead = 20+8+4+4+8+16 == 60 bytes for IPv4
    IPsec protocol overhead = 58 bytes (AES-CBC HMAC-SHA1) or 54 bytes (AES-GCM) (both IPv4)

To be absolutely fair, Wireguard uses UDP encapsulation to get past NAT devices, and one would need to use UDP-Encapsulated ESP Headers (aka "NAT Traversal") as documented in RFC 3948 to provide an equivalent solution. pfSense has this, but it costs another 8 bytes. I don't know if it was used for the Wireguard performance testing though. In this case, AES-GCM overhead would be 62 bytes, .vs Wireguard's 60 bytes of framing overhead.

In addition to the per packet overheads due to framing, there are other overheads for traditional (policy-based) IPsec that will slow the packet processing down. Policy-based IPsec encrypts and encapsulates a subset of traffic flowing through an interface according to a defined policy. On a router running IOS or JunOS, this is often an access list. On FreeBSD and linux, it is implemented as something strongly resembling a list of firewall rules. There is additional overhead for traversing this list of 'policies'.

In contrast to a policy-based VPN, a route-based VPN employs routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are used to direct the desired traffic through the VPN tunnel interface. To be clear, both route-based and policy-based IPsec uses the same framing 'on the wire'.

Wireguard is a route-based VPN, and since there is less processing per packet with a route-based VPN such as Wireguard, I would expect a performance increase .vs a policy based VPN over the same link(s).

Fortunately, with pfSense 2.4.4, we have implemented route-based IPsec (based on the work in FreeBSD 11.2). This has occurred earlier than I promised in May of 2017. While we've not tested performance yet, I expect the route-based solution to be more performant given the explanation above.

TNSR also implements route-based IPsec, and we've measured 36.32 gbps (8 concurrent sessions) throughput on 40gbps NICs using AES-CBC + HMAC-SHA1 and QAT offload. We've also measured 13.70 gbps single-stream for AES-GCM using just AES-NI on an i7-6950x over those 40gbps NICs. (All benchmarking in this post is with max-sized packets.)

There are other issues. Wireguard tested AES-GCM-256 against 256-bit ChaCha20 with Poly1305 for MAC. AES-GCM-256 is roughly 20% slower than AES-GCM-128, yet Chacha20-Poly1305 is functionally comparable to AES128-GCM (giving confidentiality and integrity), but is easier to implement securely and efficiently, especially without AES support (such as AES-NI) in hardware. Still, pitting ChaCha20/Poly1305 against AES-GCM-256 in a benchmark seems a bit like stacking the deck to me.

Further on still, the FreeBSD thread points out some additional issues that may give the readership here some pause.

Wireguard also currently has performance issues at moderate packet rates. See this post (and it's responses) on the Wireguard list. FYI, 2.5Mpps is less than 1.7gbps of tinygrams, and a bit less than 25gbps of throughput assuming 1400 byte frames, but you won't run the crypto at 25gbps. TNSR will do 3.3 - 3.9Mpps with AES-GCM-128 (AES_NI) or AES-CBC + HMAC-SHA1 (QAT) (faster QAT cards exist than what we tested with.)

Finally, the Wireguard kernel implementation for linux, and the userspace implementation are both GPLv2. This presents an additional hurdle to anyone implementing a kernel variant of Wireguard for FreeBSD (or any BSD), as GPL code can't be upstreamed to the project if it's part of base. Until someone has the time to implement a ground-up rewrite of Wireguard, (and security evaluation of same), this serves as an effective barrier to a high-performance implementation of Wireguard on FreeBSD and pfSense. (One could, perhaps, leverage the route-based IPsec interface code as a blueprint for implementing Wireguard's interfaces, and use the GPL userspace code, but I doubt the FreeBSD project would be in-favor of upstreaming just the kernel components of same.)

When you add all the above to the concerns that @jimp expressed, the result is, quite simply: "Not Yet".

THAT ALL SAID, one could make a pfSense package that included (or depended on a separate package that implemented) the requisite GUI changes.

johnpoz

Fantastic post Jim - thanks!!!

yon 0

me too, i need wireguard. i have test it, faster than openvpn 2.4 now.

eric.sysmin

Has anyone created an integration for this yet in pfSense? Just curious.

Wordo

Thee FreeBSD port itself is broken. There were some changes with 20181018 snapshot but you'll run into a stacktrace when restarting the service too often :)

yon 0

My point of view should try to increase it now, although there is no official version, but everything has started, there is no absolute perfection, as long as it has no malicious security problems, you can try it, and now there are many people using it. To people More choices of the latest advanced technology.

Wordo

Indeed, but the port itself crashes the kernel when installed on UFS, this has to be fixed first.

jimp

@yon-0 said in Installing WireGuard VPN:

there is no absolute perfection,

While true, there is a big difference between an unstable, unaudited, alpha software package and one that has been tested and found to be stable.

as long as it has no malicious security problems, you can try it,

Their own page says it might have those: https://www.wireguard.com/#about-the-project

WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change.

That should scare the hell out of you and anyone wanting to use it in production. If it doesn't, then you shouldn't be in charge of a firewall.

and now there are many people using it. To people More choices of the latest advanced technology.

Just because people use it doesn't make it good, secure, or desirable. Lots of people fall for phishing e-mails and scams, that doesn't mean they are a good idea.

After it passes 1.0 and is stable and audited as secure, then maybe it could be considered for a package.

yon 0

Every new product has a starting process, but if it's a good project, you can provide an option for everyone to try. Only use it to find the problem. Any formal product can't guarantee that there are no security issues, you need more People use to find problems. This is just a feature that you can choose to use, so let everyone decide if they need to use it.

maglub

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.

https://lists.openwall.net/netdev/2018/08/02/124

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

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

jwt

@lopezio

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.

Wordo

@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.