This article titled “Why not WireGuard” is sometimes shared in VPN discussions. Unfortunately, that article contains several misconceptions and some out-of-date information that deserves to be addressed.

Let’s go through his arguments section by section:

Will WireGuard replace my (IPsec) site-to-site VPN?

Commercial VPN hardware/software vendors mostly use a centralized hub and spoke architecture.

Although it’s true that most IPsec VPN vendors are unlikely to upgrade to WireGuard, users we hear from are only rarely trying to make their existing VPN concentrators work with a new protocol. Instead, they are eager to replace their bottlenecked VPN concentrators with something more lightweight and less restrictive. WireGuard replaces your VPN hardware with a simple software solution, so it doesn’t need support from your legacy hardware vendor.

Will WireGuard replace road warriors from laptop to data center?

Right now, WireGuard has a huge backlog of features that it needs to implement to be suitable for this use case. It does not, for example, allow using a dynamic IP address on the server-side of the tunnel which breaks a whole use-case.

The article claims WireGuard is missing a “huge backlog of features,” but only lists dynamic IP addresses as a missing feature. The “huge backlog” may be out-of-date information from earlier WireGuard versions.

This section of the article is confusing at first because it talks about “road warrior” users (who generally have dynamic IP addresses) not being supported by WireGuard. But this is not true; standard WireGuard happily works as long as at least one end (usually the central VPN concentrator) has a static IP address.

The rest of the section appears to be discussing the problems caused by both ends of a connection having dynamic IP addresses (for example, so you can get to an office network whose home connection uses dynamic DNS). It’s true that plain WireGuard does not support this configuration out of the box. However, there are various scripts and higher-level tools (including ours) that make this work fine.

A few people responded that WireGuard does work fine even if both ends are on dynamic IP addresses. This is not true out of the box. You can configure a WireGuard client to point at a server’s DNS name, and that DNS name can be updated periodically using dynamic DNS. However, the standard WireGuard software only resolves the DNS name once at startup, so if the server hops to a new address, you will need to restart each client’s WireGuard instance before it looks up the DNS name again. Various tools and scripts exist to automate this process for both WireGuard and IPsec.

Is it easy to use and Is IPsec really hard to use?

No, it clearly is not if the vendor has done their homework right and provides an interface that is easy to use.

That IPsec is not very hard to use after all in contradiction to the experiences of most readers — and points out that you only need to specify your own public IP address, the public IP of your peer, the subnets you want to make available for each side, and a pre-shared key. After that, the VPN “is compatible with every vendor out there.”

So, that is not the only information needed to configure IPsec: critically, the correct use of IPsec requires you to specify exactly which cipher suites you want to allow. This is an unanswerable question for anyone who is not a cryptography expert. The defaults are virtually never secure or cross-platform.

The selection of cipher suites affects which IPsec vendors are compatible with each other. Far from a VPN that “is compatible with every vendor out there,” the default settings for one vendor almost never work with hardware and software from another vendor.

So, it is necessary to specify public IP addresses for both ends of the tunnel. This is mysterious given that the previous section said, WireGuard requires exactly that, and thus would not work with dynamic IPs. In truth, both IPsec and WireGuard work fine with only one end on a well-defined IP, so in both cases, you only need to configure at most one public IP address.

Finally, better using a pre-shared key (PSK) on both ends. PSKs are one of the weakest forms of authentication. (Passwords are one form of PSK.) Among other things, a key stolen from one node makes it possible to impersonate either end and forge traffic from both ends. Both IPsec and WireGuard allow public-key authentication, which is considerably stronger, but only WireGuard makes it mandatory. We’ll talk about the security dangers of IPsec’s “flexibility” below.

About Protocol Complexity:

The end-user does not have to worry about the complexity of the protocol. If that was an issue we would have definitely gone rid of SIP and H.323, FTP, and other protocols that don’t cope well with NAT and are decades old.

Complexity in some protocols can be acceptable (although never desirable). But insecurity is deadly.

In our opinion, IPsec is too complex to be secure. The design obviously tries to support many different situations with different options. We feel very strongly that the resulting system is well beyond the level of complexity that can be analyzed or properly implemented with current methodologies. Thus, no IPsec system will achieve the goal of providing a high level of security.

That paper is more than 16 years old, and IPsec has only increased in complexity. It remains nearly impossible to analyze. In 2020, it is well understood that IPsec’s excessive complexity puts it on the verge of obsolescence, now that better options are available. These problems are some of the reasons for the strong shift toward TLS instead of IPsec in the decades since IPsec was standardized.

User-authentication using username/password or a SIM card WireGuard does not have that.
This statement remains true of core WireGuard. However, WireGuard is a data plane; it is intended to be used with a key exchange mechanism built on top, and there are several available for use in different situations.

About Ignoring Real-World Problems:

If you were to change the cipher you are using from one day to the next one, you would need to upgrade your WireGuard software on all those laptops, phones, etc. at the same time.

This statement is simply false. Someday, WireGuard will need to be upgraded to support a second cipher suite. When this happens, users will be able to configure it peer-by-peer to allow one cipher suite or the other, or both, exactly as they would with any other VPN.

Most VPNs (and TLS) offer thousands of different possible combinations of algorithms to choose from — most of which are insecure or slow or both. In contrast, a hypothetical WireGuard protocol v2 can offer just two suites, the old one and the new one, with simple advice: use the new one if you can, and allow the old one for old nodes until they’re upgraded. There’s nothing unusual about this, except you don’t need to be a cryptography expert to configure it.

Cryptography!

More crypto algorithms make IPsec just as good as WireGuard
So would conclude that practically the same cryptography is available for all VPNs here. Therefore WireGuard is not more or less secure than the others when it comes to encryption or data integrity.

On the surface, this claim is true: you can assemble a cipher suite for IPsec that is roughly the same as the (only) cipher suite used in WireGuard.

However, this leaves out some important details. First of all, you have to know how to choose and configure the right IPsec cipher suite, which only a skilled cryptographer should ever be trusted to do. And second, once you attempt to use that cipher suite, you will likely find that it’s not compatible with virtually any VPN hardware or software you can find.

Ironically, although the IPsec standard allows virtually every cipher suite, it does not mandate any of them. Two nodes can be completely IPsec compliant and yet completely unable to talk to each other, and it’s your job to figure out why.

With WireGuard, there is only one cipher suite, so you don’t need a degree in cryptography to choose it. Someday, there will likely be a second suite available. Unlike IPsec, it’s trivial to confirm whether two WireGuard-capable software packages should be able to talk to each other.

Is WireGuard faster than other VPN solutions?

For almost all use cases, both IPsec and WireGuard are perfectly fine. The symmetric encryption you use (AES or ChaCha20 or anything else) is almost never relevant at all except on extremely fast (well over 10 Gbit/sec) networks.

(One exception is legacy VPN concentrator hardware, which tends to be built on relatively slow processors that bog down with too many IPsec users at once. But this is not really a fault of IPsec itself.)

Mobile processors are somewhat slower than desktop and server processors when doing encryption, of course, but they are also usually on much slower networks. On mobile, you should expect the symmetric crypto to take maybe 1% of the time, and slow networks to take 99% of the time.

Some non-IPsec and non-WireGuard VPN platforms carry their traffic over TCP.
(Most “SSL VPNs” and “BeyondCorp proxies” are in this category.) Carrying VPN traffic over TCP is quirky and can cause slowdowns and lag with real-time traffic, such as VoIP, video calls, and remote desktops. But neither IPsec nor WireGuard has this problem.

Another issue to watch out for is point-to-multipoint versus hub-and-spoke VPN architecture. In general, a hub-and-spoke architecture introduces higher latency due to extra hops. IPsec was originally intended to support point-to-multipoint architecture, but due to some major design flaws, this is almost never attempted in practice.

When configured correctly, WireGuard is capable of operating securely in point-to-multipoint mode and reducing latency. For example, a WireGuard-enabled laptop can have open connections directly to three data centers simultaneously, instead of to one data center that then has tunnels to other data centers.

However, you can use SaturnVPN services to have different types of protocols including PPTP, L2TP, Kerio VPN, Cisco AnyConnect, and OpenVPN. Just go to a VPN setup tutorial to install VPN and then go to pricing to buy a VPN package. You can test our VPN by free trial VPN account. If you have any questions you can contact us.