Known Limitations
WireGuard is a protocol that, like all protocols, makes necessary trade-offs. This page summarizes known limitations due to these trade-offs.
Deep Packet Inspection
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. It is quite possible to plug in various forms of obfuscation, however.
TCP Mode
WireGuard explicitly does not support tunneling over TCP, due to the classically terrible network performance of tunneling TCP-over-TCP. Rather, transforming WireGuard's UDP packets into TCP is the job of an upper layer of obfuscation (see previous point), and can be accomplished by projects like udptunnel and udp2raw.
Hardware Crypto
WireGuard uses ChaCha20Poly1305, which is extremely fast in software on virtually all general purpose CPUs. As of writing, there is not an overwhelming amount of dedicated hardware support for it, though this is changing. Practically speaking, this is not a problem, as vector instructions on CPUs wind up being in the same ballpark (and sometimes even faster) than AES-NI instructions.
Roaming Mischief
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.
Identity Hiding Forward Secrecy
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. Mitigations include rotating or regenerating keys, based on expectations of unlinkability.
Post-Quantum Secrecy
WireGuard is not, by default, post-quantum secure. However, the pre-shared key parameter can be used to add a layer of post-quantum secrecy. It could be post-quantum secure were the public keys hashed instead of sent directly, but this is not part of the Noise Protocol Framework, on which WireGuard's handshake is based, and this hashing technique wouldn't enable forward-secure post-quantum secrecy either. The best bet for post-quantum security is to run a truly post-quantum handshake on top of WireGuard, and then insert that key into WireGuard's pre-shared key slot.
Denial of Service
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. In practice, though, mac2 is usually sufficient.
Unreliable Monotonic Counter
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.
Routing Loops
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.
