How WireGuard works

9 November 2026

WireGuard is a tunnel protocol that works at layer 3, on IP packets, and carries them encrypted inside UDP datagrams. Each side identifies the other by a 32-byte public key, and the two agree on session keys in a single round trip. Every public key is bound to a list of allowed addresses, and that binding drives all of its routing.

Keys: the identity of each side

Every WireGuard device holds a private key that never leaves it. A public key derived from it is given to the other side. Both are Curve25519 keys.

The public key is 32 bytes, which is 44 characters in Base64. There are no usernames and no certificates: the public key is the device's identity.

The protocol does not define how public keys are exchanged. That is left to whoever runs the network, as with SSH keys. On Linux a key pair is created like this:

wg genkey | tee private.key | wg pubkey > public.key

These design details come from the WireGuard paper by its designer.

The handshake: one round trip

The handshake follows the IK pattern of the Noise protocol framework. The full construction name given on the protocol page is Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s.

The K means the initiator already knows the responder's public key. The I means the initiator sends its own public key, encrypted, in the first message.

1. Initiation. The initiator generates a fresh ephemeral key. One message carries that key, its static public key in encrypted form, and an encrypted timestamp that stops replays of old messages.
2. Response. The responder checks the message and generates its own ephemeral key. Its reply proves it holds the private key matching its public key.
3. Session keys. From Diffie-Hellman operations between the ephemeral and static keys, both sides derive two symmetric keys: one for sending, one for receiving.
4. First data packet. The initiator sends the first encrypted packet. The responder does not send data until it receives it, because that packet confirms the handshake completed on both ends.

The algorithms are fixed rather than negotiated: Curve25519 for key agreement, ChaCha20-Poly1305 for authenticated encryption, BLAKE2s for hashing and HKDF for key derivation. Leaving out negotiation is deliberate.

It removes a whole layer of complexity, along with attacks that push both sides down to a weaker cipher. If one primitive is ever broken, the answer is a new version that everyone updates to.

The psk2 part of the name refers to an optional pre-shared key (PresharedKey). It is mixed into the handshake as an extra layer on top of the public keys.

Rekeying and silence

While data is flowing, the handshake repeats roughly every two minutes, so session keys keep rotating. That gives forward secrecy: a key captured today does not decrypt yesterday's traffic.

The paper starts a new handshake after 120 seconds. After 180 seconds, no packet under the old key is accepted.

WireGuard does not answer any packet that fails authentication, and keeps no state for it. Someone probing the port without a valid key gets no reply at all.

Under heavy load, a server first asks the initiator for a cookie tied to its address. Only then does it do the expensive work, which blunts flooding attacks.

A peer that has received data but has nothing to send back for 10 seconds sends an empty encrypted packet. This shows the session is alive.

When nothing flows in either direction, the link goes completely quiet. The PersistentKeepalive option sends a periodic packet for setups that need to keep a NAT mapping open.

Cryptokey routing and AllowedIPs

The paper calls the core idea cryptokey routing. Each peer has a public key and a list of addresses in AllowedIPs, and that one list works in both directions:

• Sending: WireGuard looks up the packet's destination in the lists to find which peer it goes to and which key encrypts it. If no peer matches, the packet is dropped.
• Receiving: after decrypting a packet, WireGuard checks that its inner source address falls in the list of the same peer whose key decrypted it. If not, the packet is dropped.

Every packet that leaves a WireGuard interface therefore carries a trustworthy source address, and a simple firewall rule is enough to tell peers apart. Here is a typical configuration for a device that sends all of its traffic through one server:

[Interface]
PrivateKey = <client-private-key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

0.0.0.0/0, ::/0 covers every IPv4 and IPv6 address, so the tunnel carries everything. The wg-quick tool adds system routes from this list. It handles the default route with separate rules so the tunnel's own packets do not loop back into it, as the wg-quick manual describes.

The DNS line is an option of that tool, not part of the protocol. Narrowing the list to specific networks is what split tunneling means.

Endpoint is optional on one side. The server learns the client's address from the last valid packet it received. That is why a phone can move from Wi-Fi to mobile data without the tunnel dropping.

Compared with IPsec and OpenVPN, in general terms

IKEv2 is a full Internet Standard, defined in RFC 7296. Through two exchanges, IKE_SA_INIT and IKE_AUTH, the peers set up the security associations that protect IPsec traffic. Its choice of algorithms and authentication methods suits corporate networks, and makes it harder to configure.

OpenVPN builds on TLS and runs outside the kernel. The WireGuard paper notes that this costs it repeated packet copies between kernel and user space. Its practical advantage is that it can run over TCP.

How to inspect a WireGuard tunnel

On Linux this command shows the state of each peer:

sudo wg show

• latest handshake: if this line is missing, no handshake has completed. The usual causes are a wrong public key, a wrong Endpoint, or a UDP port blocked along the way.
• transfer: if the sent counter grows while received stays at zero, packets leave and nothing comes back.

Then confirm the address the world sees with the My IP tool. The official WireGuard apps for other systems show the same details in the tunnel view.

General advice

• Give every device its own private key. Do not copy one file to two devices, and do not send a private key by message or email.
• If all traffic should use the tunnel, make sure AllowedIPs includes ::/0 or that IPv6 is disabled. Otherwise IPv6 traffic may leave outside it.
• WireGuard does not try to hide that it is WireGuard. Its packet format is recognisable, and some networks block or throttle UDP.

WireGuard at syriaproxy

We offer WireGuard for iPhone, iPad, macOS and routers, with a file per device from your account for the official app. Traffic exits from the Syriatel 4G network inside Syria, and IPv6 is blocked inside the tunnel because the network is IPv4 only. The steps are in WireGuard setup.

FAQ

Test your tunnel now with the free DNS leak test.