Known limitations

The project maintains a page listing its own protocol’s weaknesses. That is rare enough to be worth saying out loud: most software in this category publishes a feature list and leaves you to find the edges yourself.

What follows is a summary of the limitations the project documents. The official page is authoritative and more detailed — read it if any of these bear on your threat model.

It does not hide that it is WireGuard

WireGuard makes no attempt to disguise its traffic. An observer doing deep packet inspection can tell that you are using it, and a network that wants to block it can. The project’s position is that obfuscation belongs in a layer above, not tangled into the crypto, and that WireGuard’s job is to be a small correct tunnel. You can put an obfuscation layer on top; you just have to choose one.

If you need a VPN that survives a hostile network actively filtering VPNs, this is a real gap and you should plan for it rather than hope.

No TCP mode

WireGuard runs over UDP and deliberately will not tunnel over TCP. Carrying TCP inside TCP interacts badly — the two congestion control loops fight each other, and throughput collapses under exactly the conditions where you need it most.

Where UDP is blocked outright, the answer is again an external layer; tools exist that wrap UDP into something a restrictive network will pass.

Roaming can be manipulated

Roaming works because an authenticated packet updates the peer’s recorded endpoint, and it does that with no extra round trip. An active attacker in the middle can therefore rewrite source addresses and cause the recorded endpoint to point somewhere they choose.

The scope of that is narrower than it first sounds. The attacker cannot read the traffic — authenticated encryption still holds — and an active attacker could already redirect packets. What it buys them is the ability to keep relaying after losing their position in the path. Firewalling the WireGuard socket to a fixed address closes it where you need it closed.

Handshake metadata is not fully hidden

Data packets have forward secrecy. The handshake is a partial exception: the initiator’s public key is encrypted to the responder’s static public key, so someone who later obtains the responder’s private key and has kept a log of old handshakes can work out who was connecting, though not what was sent.

Relatedly, part of the handshake is computed over the responder’s public key, which makes it possible to test a guess about who a packet was addressed to.

If unlinkability matters to you, rotating keys is the mitigation.

Not post-quantum secure by default

WireGuard’s handshake is not post-quantum secure as it stands, and the project is straightforward about why: the technique that would help isn’t part of the Noise framework the handshake is built on, and it wouldn’t deliver forward-secure post-quantum secrecy anyway.

There is a practical path. WireGuard has a pre-shared key parameter, and a post-quantum handshake run separately can feed its output into that slot. That gives you an additional layer rather than a replacement.

Denial of service

The protocol includes cookie-style mechanisms designed to make abuse expensive. There is a window before the second of them engages during which an attacker can force elliptic curve computations and consume CPU. In practice the mitigation is usually sufficient, but “usually” is the honest word.

It trusts your clock

WireGuard uses system time as a monotonic counter, which means a system clock under hostile control is a problem. Jumped forward, you can lock yourself out of your own keys by making a later valid value unreachable. Jumped backward, handshakes fail. An adversary who controls the clock can also hold a captured handshake initiation for later use.

For almost everyone this is a non-issue. If your threat model includes an attacker who can set your clock, it isn’t.

Routing loops

As with any tunnel, it is possible to configure routing such that traffic destined for the tunnel is routed into the tunnel. The official page covers the specifics.

Why this page exists

None of the above is a reason not to use WireGuard. Every one of them is a consequence of a decision that bought something worthwhile — small code, no negotiation, roaming that just works, silence when idle.

The reason to read them is that a tool which tells you where its edges are is one you can actually deploy responsibly. Read Cryptography and security for the other half of that picture.