Disadvantages of WireGuard

WireGuard does not focus on obfuscation. Obfuscation, rather, should happen at a layer above WireGuard, with WireGuard focused on providing solid crypto with a simple implementation.

WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP.

As of writing, there is not an overwhelming amount of dedicated hardware support for it, though this is changing.

WireGuard's roaming happens without an additional round trip or other authentication, which means an active man in the middle can replace source IP addresses. A man in the middle can already redirect packets, by virtue of being active, but it may be possible for the endpoint address to be updated and for the man in the middle to relay packets after having lost the man in the middle position. These packets, however, remain indecipherable by the attacker, by virtue of WireGuard's usual authenticated encryption. However, if this is an issue, ordinary firewalling can lock down the WireGuard socket to a particular IP address, and it's possible that future revisions of WireGuard will allow this innately. Relatedly, it may be possible to play a TCP sequence number guessing game in order to have a WireGuard server direct packets at an uncontrolled IP address.

WireGuard has forward secrecy of data packets, thanks to its handshake, but the handshake itself encrypts the sender's public key using the static public key of the responder, which means that a compromise of the responder's private key and a traffic log of previous handshakes would enable an attacker to figure out who has sent handshakes, but not what data is inside of them. Similarly, mac1 is made over the responder's public key, which means it is possible to trial hash to guess whether or not a packet is intended for a particular responder, though the mac1 could be forged.

WireGuard is not, by default, post-quantum secure.

WireGuard is supposed to be abuse-resistant, by virtue of its use of mac1 and mac2, though before mac2 kicks in, the ECDH computations may use considerable CPU.

WireGuard uses the system time as a reliable monotonic counter. If this jumps forward, a user might DoS their own keys, by making it impossible to later have a value larger, or an adversary controlling system time could store a handshake initiation for use later. If it jumps backwards, handshakes will similarly be impossible. Thus, the system time should not be under the control of a hostile adversary.

There are currently a few issues with detecting routing loops, locally and over a network, and there are various tricks like changing the outer src to the inner src.

Implements network self-healing similar to the gossip protocol.

Requires signaling the server to break through double NAT.

Automatically assigns and revokes keys through a central server.

Sends original second-layer Ethernet frames, which might have certain implications.