What WireGuard is, and why modern VPNs use it
WireGuard is a small, fast VPN protocol with fixed modern cryptography, a one-round-trip handshake and built-in roaming. How it works and its limits.
WireGuard is a VPN protocol designed to be small, fast and hard to misconfigure. It uses one fixed set of modern cryptography, completes its handshake in a single round trip, runs over UDP, and carries on working when your phone changes networks. It has been part of the Linux kernel since version 5.6, and it is the first protocol most current VPN apps try.
Why small matters
Older VPN protocols grew by accumulation: every cipher anyone had ever needed, every authentication method, every transport option. That flexibility means a large amount of code, and a large amount of code means more places for a mistake to hide and more ways to configure it badly. WireGuard took the opposite approach. It picks one answer to each cryptographic question and offers no alternatives, so the whole implementation is a few thousand lines rather than hundreds of thousands. A reviewer can read it end to end, which is a security property in its own right.
The cryptography it uses
| Job | WireGuard's choice | What it does |
|---|---|---|
| Key exchange | Curve25519 | Lets both ends agree on a shared secret over an untrusted network |
| Encryption and integrity | ChaCha20-Poly1305 | Scrambles each packet and detects any tampering with it |
| Hashing and key derivation | BLAKE2s | Mixes the exchanged secrets into the session keys |
| Handshake framework | Noise protocol (IK pattern) | Defines the order in which keys are exchanged and what each message proves |
There is no negotiation step where the two sides haggle over which of these to use. If a weakness were ever found in one of them, the fix is a new protocol version, not a configuration change. The encryption explainer covers what each of those jobs means in plain terms.
How a connection starts
Each side has a long-term key pair. The phone sends a handshake initiation, a fixed 148-byte UDP packet that contains a fresh ephemeral public key and proves, using the phone's long-term key, who is sending it. The server replies with its own ephemeral key, and both sides now hold the same session keys. That is one round trip, so on a nearby server the tunnel is carrying traffic a few tens of milliseconds after the first packet leaves.
A server that receives an initiation from a key it does not know does not reply at all. To anyone scanning the internet, a WireGuard server is silent. That is good for the server, and it has a side effect worth knowing: a genuine client with the wrong key sees exactly the same silence as a client whose packets are being dropped by the network. The handshake post explains why a VPN app has to treat that silence as a signal and move on.
Rekeying and forward secrecy
Session keys are replaced roughly every two minutes with a fresh handshake, and the old keys are discarded. If a session key were ever recovered, it would decrypt about two minutes of traffic, not the whole session and not any past session. That property is called forward secrecy, and in WireGuard it is automatic rather than optional.
Roaming
WireGuard does not have a "connection" in the way TCP does. The server identifies a client by its key, not by its address. When your phone leaves Wi-Fi and joins mobile data, its next packet arrives from a new address, the server checks it decrypts correctly, and updates where it sends replies. There is no reconnect, no renegotiation, and usually no visible gap. This is the feature that makes WireGuard feel native on a phone.
Where it runs
On Linux it runs inside the kernel, which is why it can move packets faster than a protocol that has to copy every one in and out of a userspace process. On Android an app cannot load kernel modules, so it ships a userspace implementation and feeds it packets through Android's VpnService interface. That is slower than the kernel path in absolute terms but far more than a phone's radio can use, and it works on Android 8 and newer.
What WireGuard does not do
It is UDP only. On a network that drops or throttles UDP, WireGuard cannot connect, and no amount of retrying will change that. It also makes no effort to disguise itself: its packets have a recognisable shape, and a network that filters by protocol rather than port will identify them. For both cases the answer is a different transport, such as a VPN wrapped in TLS on port 443, which is why a good app treats WireGuard as the first thing to try rather than the only thing.
Finally, WireGuard's default tunnel MTU is 1420 bytes, 80 less than a typical network's 1500, to leave room for its own headers. If an app gets that wrong, some websites load and others hang, which is covered in the MTU post.
Culvert VPN uses WireGuard over UDP as its first choice on every connection, trying several ports before moving to a TLS transport on 443 and then IKEv2, and it is available on Google Play.
Questions people also ask
Is WireGuard secure?
Yes. It uses current, well-studied primitives with no legacy options to fall back to, and its small size means the code has been reviewed far more thoroughly than older protocols.
Does WireGuard work on Android?
Yes. A VPN app can ship a userspace implementation and run it through Android's VpnService, which is how most WireGuard-based apps work on phones running Android 8 and newer.
Why does WireGuard need a static key on the server?
Its handshake authenticates both sides with long-term public keys, the same way SSH does. The app learns the server's key when it requests a session, so you never have to handle one yourself.