WireGuard is a relative newcomer to the VPN scene but it has quickly gained favor since it’s initial release in 2016. Being directly integrated with the Linux kernel gave it near unrivaled speeds and its small code base promised speedy security audits. and quick bug fixes. WireGuard boasted about a significantly smaller code base then OpenVPN, around 3,700 lines of code where OpenVPN has hundreds of thousands of lines of code. However, this smaller code base means that WireGuard is missing some important features that OpenVPN supports.
I want to clarify before I begin this that I like WireGuard overall. As a Home Laber myself WireGuard works fine for my purposes, but it does have some limitations that might make it not useful for your situation. Let’s dive into some considerations on when/if you should use WireGuard.
Perhaps the largest issue with WireGuard is its lack of proper user management. With OpenVPN you can have multiple ways of authenticating users; you can add users to the server directly, add them to LADP, add them to Active Directory support, or link the server to a Radius server. This makes user management easy. Link the OpenVPN server to your Radius server, add the user to the Radius server, and then provide the user an .ovpn cert. They can then login using the same login information they use for other applications. This also means when a user leaves your organization you can remove them from the Radius Server and now the user is no longer able to connect to your OpenVPN server.
Wireguard does not work this way. It has no user management built in; each client must be added individually, and adding a Wireguard client securely isn’t that simple. Adding a client (peer) in WireGuard requires the client to install WireGuard and generate a public key. This public key then needs to be provided to the WireGuard server as a peer. The Client must also take the public key of the server and manually add it to their config file. Here’s a look at what a basic WireGuard client config file looks like:
[Interface] Address = 10.0.0.3/24 PrivateKey = [PrivateKeyPeer#1] [Peer] PublicKey = [ServerPublicKey] PresharedKey = [PresharedKey] Endpoint = some.domain.com:51820 AllowedIPs = 0.0.0.0/0, ::/0
You have to manually add this to every single client you want to provide access to. Now you might be thinking ‘I’ll just have the IT team premake these files and provide them to the users are hiring.’ except that doesn’t work because of two things. First the config file needs a private key generated on the client itself, and second the server needs the public key generated on the client.
With OpenVPN I generate an .ovpn file on the server and provide that to the client. That file has all of the information built right, except the username and password. The Client just selects the .ovpn file and connects. OpenVPN then pulls all of the configuration data from the server.
Removing a user’s access involves modifying the WireGuard server config file and manually deleting the Peer out of it. If you have hundreds of users this becomes cumbersome vs simply removing a user from your Active Directory, LDAP, or Radius server.
Username and Password
The other concern here is the lack of username and password. WireGuard relies entirely on the public key pairing between client and server. That’s it. There’s no second method of authentication for access. In today’s age of increased work from home businesses face a whole new set of risks. One of those risks come the use of VPNs to connect back to corporate networks.
VPNs are a necessary risk in a work from home era, but they add increased risks to a company. A compromise on the client, work or personal client, could result in the loss of the VPN configuration file. Without a username and password required for authentication that loss could result in an attacker being able to access company resources with ease.
Currently WireGuard does not have any options for username and password authentication, making this risk even greater for those using this service. Now some companies like TailScale and ZeroTier have built in username/password authentication but that’s a front end handling the authentication and not something built into WireGuard itself.
Similar to the Username and Password issue is lack of two factor authentication support. Whenever you’re allowing connections from outside your trusted network in you should always be requiring two factor authentication (2FA). Now, technically 2FA is something you have, something you know, something you are, so using a certificate and username/password would meet that definition. The certificate is something you have and the username/password is something you know; however, users are notoriously bad about passwords and so a better 2FA like a TOTP token should be used instead.
This is again where WireGuard’s “streamlined” code causes some limitations. There is no 2FA support for WireGuard. Someone with the config file will be able to connect to your network.
Another point where WireGuard struggles is with DHCP. Meaning, that it simply doesn’t exist. Take a look at the top of our client configuration file again.
[Interface] Address = 10.0.0.3/24 PrivateKey = [PrivateKeyPeer#1]
In this configuration file, and in the server configuration file we have to manually specify the IP address of each peer. Here’s the server configuration for peer 1.
[Peer] #Peer #1 PublicKey = [Peer#1PublicKey] AllowedIPs = 10.0.0.3/32
This may not seem like a big issue but if you’re a company with hundreds of work from home employees this means you will need a separate method of tracking which IPs are already in use. I’ve worked in IT long enough to know this likely means a large spreadsheet and manually updating the spreadsheet with IPs.
WireGuard is also notoriously difficult to update, and it’s by design. According to Jason Donenfeld in the WireGuard Whitepaper.
Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.
The important part in there is that to update the underlying primitives (cryptography) every client will be required to update. This means that WireGuard will break for people because it lacks the ability to work with multiple Cryptographic primitives, so a new cryptographic primitive can not be added without requiring every client to also update with that new primitive.
Think for a moment about a company with hundreds of work from home employees. These employees are using WireGuard to remote in to work and conduct their business when suddenly a new vulnerability is discovered for the cipher WireGuard is using. Your company wants to change ciphers to avoid this vulnerability. With OpenVPN your IT team could modify the server config file to delist that cipher as an accepted cipher. The Clients configs should have several ciphers they accept and so they will negotiate to a different cipher supported by both the client and server. With WireGuard every client will need to be updated individually before it can connect.
For most companies that means users will need to bring in their work laptops and have the IT team update them manually. Heaven forbid if your employees are running WireGuard on their personal computers. Now you’re going to have to figure out how to instruct hundreds of employees on how to update their WireGuard Client. You’d be writing instructions for Windows, Mac, Debian Based Linux, Red Hat based Linux, and then you’d still get the outliers that use something like Arch or BSD for their personal computer.
Now to be fair this isn’t exclusively a WireGuard issue. OpenVPN also has similar issues. Adding a new cipher requires passing new .ovpn files to all the clients with the new accepted ciphers. The difference here is that you can use an older cipher in the mean time, and things like OpenVPN Access Server allow employees to login and download the newest config file without needing to update the entire OpenVPN client.
UDP over nonstandard ports
Another consideration to make with WireGuard is the protocol it uses. More specifically UDP over a non standard port. Network administrators should be adhering to the principle of least privilege, meaning that they’re blocking ports and protocols not used for standard things.
WireGuard defaults to UDP port 51820 for it’s communications. This means on a properly secured network outbound UDP port 51820 should be blocked. If you’re using WireGuard on your phone to proxy your DNS requests to an adblocker like Pi-Hole (or pfBlocker) when you’re on cellular then this isn’t an issue; however, if you’re expecting to use WireGuard to encrypt your traffic on all public Wi-Fi then you might run into issues if the network administrator has locked down that network.
This can also be changed in server settings, and then also updated on every client.
Where is WireGuard better?
I’ve spent a good amount of time pointing out issues with WireGuard but in the interest of fairness I also wanted to point out where WireGuard is better.
WireGuard is much faster than OpenVPN, it’s not quite as fast as native IPSec but it is faster than OpenVPN. I’ve hit over 500Mbps on a WireGuard VPN where I was lucky to get over 100Mbps on an OpenVPN connection.
It’s easier to set up
I’ll be the first to admit when I first attempted to set up WireGuard I was lost beyond belief and the documentation was not particularly good. The fact that WireGuard is built on a Peer model instead of Client-Server model meant that standard methodology I knew didn’t apply. Even in this I’ve mentioned things as a Client-Server model when in reality the “server” in a WireGuard network is really just another peer that can talk to any other peer on the network with a few lines added to it’s config file.
After a bit of research, experimentation, and excellent write ups online, I finally grasped setting up WireGuard instances and can say that they actually are much easier then setting up an OpenVPN server from scratch.
It handles site-to-site communications better
One of the concepts in the white paper is that WireGuard is trying to replace IPSec which is a standard for site-to-site communications. Since WireGuard is a peer network it allows site-to-site communications with a simple modification of the “server”.
Low Resource Usage
WireGuard is significantly more lightweight then a full OpenVPN install. That means it should work better on more low powered devices, providing faster speeds and using less resources. This also means it’s less battery intensive on phones and laptops.
I like WireGuard but it’s not a replacement for OpenVPN or IPSec, at least not yet. Lack of proper user management, lack of a DHCP server, and lack of cipher flexibility mean that WireGuard is not likely to see wide adoption in the corporate world. Yes some companies have built work arounds to solve some of these issues but that requires your company to hire another service provider.
For those of us in the Home Lab scene WireGuard offers a fast, easy to set up VPN, and doesn’t drain phone battery as quickly. WireGuard also can be useful for those of us who share resources with parents or other family members. I can set up a WireGuard peer on their router and now they can talk to my trusted network securely. Same thing goes for when I take my OpenWRT travel router with me on work trips. I can connect the router to Hotel Wi-Fi and site-to-site connect to my house.
I like WireGuard but it is clearly still a work in progress with an expansive backlog of features needed before it is ever truly able to replace OpenVPN or IPSec.