How WireGuard Works: Modern VPN Protocol Explained

WireGuard is a modern VPN protocol designed from scratch to be simpler, faster, and more secure than its predecessors. Created by Jason Donenfeld and first released in 2015, WireGuard takes a radically minimalist approach: its Linux kernel module is roughly 4,000 lines of code, compared to over 100,000 lines for OpenVPN or 400,000+ for IPsec. This small surface area is not a limitation but a deliberate design choice — it makes the protocol auditable, verifiable, and far less likely to harbor undiscovered vulnerabilities.

WireGuard operates at Layer 3 of the network stack, creating a virtual network interface (e.g., wg0) that looks and behaves like any other network interface. Packets sent to this interface are encrypted, encapsulated in UDP, and transmitted to the peer. Packets arriving from the peer are decrypted and injected into the network stack as if they arrived on a normal interface. There is no concept of a "connection" or "session" in the traditional sense — WireGuard is stateless in its network interface model, though it does maintain cryptographic session state internally.

From a routing perspective, WireGuard integrates directly with the operating system's routing table. You assign IP addresses to the WireGuard interface and use standard routing rules to direct traffic through it. This means WireGuard works seamlessly with existing networking tools, firewall rules, and subnet configurations. There is no custom routing daemon or proprietary configuration language — just a network interface that encrypts packets.

Cryptographic Primitives

Unlike OpenVPN or IPsec, which offer a dizzying menu of cipher suites, key exchange algorithms, and hash functions, WireGuard uses a single, fixed set of modern cryptographic primitives. There is no cipher negotiation. Every WireGuard peer uses exactly the same algorithms:

• Curve25519 for Elliptic Curve Diffie-Hellman (ECDH) key exchange. This provides 128-bit security with 32-byte keys that are easy to generate and fast to compute. Curve25519 was designed by Daniel J. Bernstein specifically to resist timing side-channel attacks and to be implementable without branching on secret data.
• ChaCha20-Poly1305 for authenticated encryption. ChaCha20 is a stream cipher that operates on 64-byte blocks using 20 rounds of quarter-round operations. Poly1305 is a one-time authenticator that produces a 16-byte tag. Together, they provide both confidentiality (nobody can read the data) and integrity (nobody can modify it without detection). ChaCha20-Poly1305 is an AEAD (Authenticated Encryption with Associated Data) construction standardized in RFC 8439.
• BLAKE2s for hashing and keyed MAC operations. BLAKE2s is a cryptographic hash function optimized for 32-bit platforms that is faster than MD5 while providing 256-bit security. WireGuard uses it for key derivation, message authentication codes within the handshake, and cookie MAC verification.
• SipHash for hashtable key derivation. SipHash is a pseudorandom function used internally for hashtable operations, protecting against hash-flooding denial-of-service attacks.
• HKDF (HMAC-based Key Derivation Function) built on top of BLAKE2s. HKDF is used to derive multiple symmetric keys from the shared secrets produced during the Diffie-Hellman exchange, following the extract-then-expand paradigm defined in RFC 5869.

This fixed-cipher approach eliminates an entire class of vulnerabilities. In TLS and IPsec, cipher negotiation has historically been a source of downgrade attacks — where an attacker forces two peers to agree on a weaker cipher. WireGuard avoids this by removing the choice entirely. If a vulnerability is ever found in one of these primitives, the entire protocol would be versioned (e.g., "WireGuard v2") with new primitives, rather than attempting to negotiate between old and new algorithms.

The Noise Protocol Framework and the IK Handshake

WireGuard's handshake is built on the Noise Protocol Framework, a framework for building cryptographic protocols developed by Trevor Perrin. Noise defines a set of handshake patterns that specify exactly how public keys and Diffie-Hellman operations are combined. WireGuard uses the Noise_IKpsk2 pattern — a variant of the IK (Interactive, Known) pattern with a pre-shared key (PSK) mixed in at the second step.

In the IK pattern, the initiator knows the responder's static public key in advance (the "K" in IK), and the initiator transmits its own static public key during the handshake (the "I" in IK). This means both sides authenticate each other using their long-term Curve25519 key pairs, while also establishing ephemeral session keys for forward secrecy.

The handshake consists of just two messages — one round trip — to establish a fully authenticated, forward-secret session. This is significantly fewer messages than the multi-round-trip handshakes of IKEv2 (IPsec) or the TLS 1.3 handshake.

Handshake Message 1: Initiator to Responder

The initiator constructs the first message containing:

1. A 4-byte message type identifier (type = 1) and a 4-byte sender index — a random 32-bit value the initiator uses to identify this session.
2. The initiator's ephemeral public key (Ei) — a fresh Curve25519 key pair generated for this handshake only.
3. The initiator's static public key (Si), encrypted using a key derived from DH(Ei, Sr) — the Diffie-Hellman of the initiator's ephemeral key and the responder's static key. This ensures only the intended responder can decrypt the initiator's identity.
4. A timestamp (TAI64N format, 12 bytes), encrypted with a key derived from DH(Si, Sr) — the static-static Diffie-Hellman. This timestamp prevents replay attacks: the responder rejects any handshake with a timestamp not strictly greater than the last accepted one from this peer.
5. A MAC1 computed over the entire message using a key derived from the responder's static public key. This allows the responder to quickly reject messages from parties that do not know the responder's public key.
6. A MAC2, which is normally zero but is set to a cookie-based MAC when the responder is under load. This is part of the DoS protection mechanism.

Throughout this construction, the Noise framework maintains a chaining key that accumulates entropy from each Diffie-Hellman operation. The chaining key is mixed with each DH output using HKDF, ensuring that the derived encryption keys incorporate all prior handshake state. This is called the "chaining" because each step builds on all previous steps — compromising one DH operation does not compromise the entire handshake.

Handshake Message 2: Responder to Initiator

If the responder successfully decrypts the first message and validates the timestamp, it constructs a response containing:

1. A 4-byte message type (type = 2), the initiator's sender index, and the responder's own sender index.
2. The responder's ephemeral public key (Er) — also freshly generated.
3. An empty encrypted payload authenticated with a key derived from DH(Er, Ei), DH(Er, Si), and the pre-shared key (PSK) if configured. The empty payload serves as authentication — if the responder can produce a valid AEAD tag, the initiator knows the responder possesses the correct static private key.
4. MAC1 and MAC2, constructed the same way as in Message 1.

After this exchange, both sides derive two symmetric keys from the accumulated chaining key: one for sending and one for receiving. These are the transport data keys used to encrypt actual tunnel traffic using ChaCha20-Poly1305. The handshake is complete in a single round trip — 1-RTT, comparable to TLS 1.3.

Forward Secrecy and Key Rotation

Because each handshake generates fresh ephemeral Curve25519 key pairs, WireGuard provides perfect forward secrecy. Even if an attacker compromises a peer's long-term static key, they cannot decrypt any previously captured traffic — they would also need the ephemeral private keys, which are destroyed after key derivation.

WireGuard automatically re-initiates the handshake every 2 minutes (or after 2⁶⁴ - 2¹⁶ - 1 messages, whichever comes first) to rotate transport keys. This re-keying happens transparently — the new handshake is performed while the old transport keys are still valid, so there is no interruption to data flow. After the new handshake completes, the old keys are securely zeroed.

The optional pre-shared key (PSK) provides an additional layer of protection: a 256-bit symmetric key shared between two peers, mixed into the handshake alongside the Diffie-Hellman outputs. This offers post-quantum resistance — even if Curve25519 is broken by a future quantum computer, an attacker would still need the PSK to derive the session keys. The PSK is typically distributed out-of-band and configured statically.

Cryptokey Routing

The most conceptually important idea in WireGuard is Cryptokey Routing — the binding of public keys to allowed IP addresses. Every peer in a WireGuard configuration has two essential properties: a public key and an AllowedIPs list. These two properties create a bidirectional mapping that serves as both an access control mechanism and a routing table.

The Cryptokey Routing table works in two directions:

• Outbound (sending): When the WireGuard interface wants to send a packet, it looks at the packet's destination IP and checks the AllowedIPs list for each peer. It selects the peer whose AllowedIPs most specifically matches the destination (longest prefix match, just like a normal routing table) and encrypts the packet with that peer's session key.
• Inbound (receiving): When an encrypted packet arrives, WireGuard decrypts it and checks the source IP of the decrypted inner packet against the AllowedIPs of the peer it was decrypted from. If the source IP is not in that peer's AllowedIPs, the packet is dropped. This prevents a peer from spoofing traffic from IP addresses it is not authorized to use.

Consider a server with this configuration:

[Interface]
PrivateKey = sKJ3...base64...
ListenPort = 51820
Address = 10.0.0.1/24

[Peer]
PublicKey = xTIB...base64...
AllowedIPs = 10.0.0.2/32

[Peer]
PublicKey = gN65...base64...
AllowedIPs = 10.0.0.3/32, 192.168.1.0/24

When the server receives an encrypted packet from the peer with key gN65..., it decrypts the packet and checks whether the inner source IP is either 10.0.0.3 or within 192.168.1.0/24. If a client tries to send a packet with source IP 10.0.0.2 using the key gN65..., the packet is silently dropped — that address belongs to a different peer's AllowedIPs.

This is fundamentally different from how traditional VPNs work. In OpenVPN or IPsec, routing and encryption are configured separately, and the mapping between tunnel users and allowed IP ranges is typically enforced by firewall rules or routing policy. In WireGuard, the cryptographic identity is the routing identity. A peer's key is its address authorization. This eliminates an entire category of misconfiguration errors where a VPN client is accidentally given access to subnets it should not reach.

AllowedIPs as a Routing Table

AllowedIPs is often set to 0.0.0.0/0, ::/0 on the client side when configuring a "full tunnel" VPN — all traffic, regardless of destination, is routed through the WireGuard interface. For split-tunnel configurations, you list only the specific subnets that should traverse the tunnel.

Internally, WireGuard implements AllowedIPs using a compressed trie (a radix tree / Patricia trie) over IP prefixes, giving O(log n) longest-prefix-match lookups — the same data structure used in high-performance IP routers. This is not a coincidence: WireGuard is a router, one that happens to encrypt and authenticate every packet it forwards.

Transport Data Packets

After the handshake is complete, data packets are sent as type 4 messages. Each transport data message contains:

• A 4-byte message type (type = 4).
• A 4-byte receiver index — the session index assigned by the receiving peer during the handshake.
• An 8-byte nonce (counter) — a monotonically increasing 64-bit integer. Each peer maintains its own send counter, incremented for every packet. This nonce is never reused with the same key, which is critical for the security of ChaCha20-Poly1305.
• The encrypted payload — the full IP packet (layer 3) encrypted and authenticated with ChaCha20-Poly1305 using the transport key and the nonce. The AEAD additional data (AD) is empty.

The nonce counter also serves as an anti-replay mechanism. WireGuard maintains a sliding window of recently received nonces (similar to the anti-replay window in IPsec). Packets with a nonce below the window floor or already seen within the window are dropped. The window size is large enough (typically 2048 or more) to accommodate packet reordering common in UDP transport.

Because WireGuard uses UDP as its transport, the complete overhead per packet is: 20 bytes (outer IPv4 header, or 40 for IPv6) + 8 bytes (UDP header) + 16 bytes (WireGuard header: type + receiver index + nonce) + 16 bytes (Poly1305 authentication tag) = 60 bytes for IPv4 or 80 bytes for IPv6. This is comparable to IPsec ESP in transport mode and lower than OpenVPN's typical overhead of 69+ bytes (with tls-crypt).

Timer-Based State Machine

WireGuard uses a timer-driven state machine instead of an explicit connection/disconnection protocol. There is no "connect" command, no "disconnect" command, and no keepalive negotiation. Instead, several timers govern the lifecycle of a WireGuard session:

• REKEY_AFTER_TIME (120 seconds): After sending a transport data message, if the current session is older than 120 seconds, the initiator begins a new handshake. This ensures regular key rotation for forward secrecy.
• REJECT_AFTER_TIME (180 seconds): A session key is never used after 180 seconds. If a rekey has not completed by this deadline, all transport packets are dropped until a new handshake succeeds. This provides a hard upper bound on key lifetime.
• REKEY_AFTER_MESSAGES (2⁶⁰): If a peer has sent 2⁶⁰ messages (well before the nonce space of 2⁶⁴ is exhausted), a rekey is triggered.
• KEEPALIVE_TIMEOUT (configurable): If configured (e.g., PersistentKeepalive = 25), WireGuard sends an authenticated empty packet every N seconds. This serves two purposes: it keeps NAT mappings alive, and it ensures the peer has an up-to-date endpoint address.
• REKEY_TIMEOUT (5 seconds): If a handshake initiation does not receive a response within 5 seconds, the initiator retransmits. After several failures (REKEY_ATTEMPT_TIME = 90 seconds total), the initiator gives up.

This timer-based approach means WireGuard is always in one of several implicit states: no session exists (cold start), a session is active and current, a session is active but nearing expiry (rekey in progress), or a session has expired. The transitions between these states are driven entirely by timers and packet events, not by explicit protocol messages. If there is no traffic, nothing is sent (unless PersistentKeepalive is configured) — the interface is completely silent. A peer can disappear and reappear without any renegotiation overhead beyond a single handshake.

Roaming and Endpoint Mobility

WireGuard supports transparent roaming. A peer's endpoint (IP address and UDP port) is not fixed — it is learned from the most recently authenticated packet received from that peer. When a peer moves from one network to another (for example, a laptop switching from Wi-Fi to a cellular network), its IP address changes. The peer on the other side notices that the next authenticated packet arrives from a different source address and silently updates the endpoint.

This works because WireGuard identifies peers by their public key, not by their IP address. When a packet arrives and is successfully decrypted and authenticated using a known peer's session key, the source IP and port of the outer UDP packet are recorded as that peer's current endpoint. No additional signaling is needed. The next reply packet is sent to this new endpoint.

There is one subtlety: only the initiator of a handshake needs a known endpoint to reach the responder. The responder learns the initiator's endpoint from the incoming handshake packet. This means at least one side must have a stable, publicly reachable address (or a port forwarded through NAT). In the common client-server VPN topology, the server has a static endpoint configured in the client's configuration, and the server learns each client's endpoint from incoming packets — including whenever a client roams to a new address.

For NAT traversal, the PersistentKeepalive option sends an empty authenticated packet every N seconds (commonly 25). This keeps the NAT mapping alive, ensuring the server can always send packets back to a client behind NAT. Without it, the NAT mapping may expire (typically after 30-120 seconds of UDP inactivity), and the server would lose the ability to send unsolicited packets to the client until the client sends a new packet.

DoS Mitigation: Cookies

WireGuard includes a denial-of-service mitigation mechanism modeled on DTLS and IKEv2 cookie mechanisms, but designed to be completely silent under attack. The system works as follows:

Under normal load, the responder processes handshake initiation messages immediately. But if the responder is under load (detecting this is an implementation decision — it could be based on CPU usage, handshake rate, or memory pressure), it responds with a cookie reply message instead of a handshake response.

The cookie reply contains a cookie value encrypted to the initiator using the initiator's ephemeral public key from Message 1. The cookie is computed as MAC(responder_secret, initiator_source_IP_and_port), where the responder's secret rotates every two minutes. The initiator must then retry the handshake with this cookie placed in the MAC2 field of Message 1.

The responder then checks MAC2 against the expected cookie before doing any expensive cryptographic operations. Because the cookie is bound to the initiator's IP address and port, a spoofed-source-IP flood attack cannot produce valid MAC2 values. An attacker would need to be on the path to intercept the cookie reply, which is itself encrypted to the initiator's ephemeral key — meaning only the actual initiator can decrypt it.

This entire mechanism is invisible during normal operation. MAC2 is zeroed in the common case, and the responder only activates the cookie requirement when under duress.

Kernel-Space Implementation and Performance

WireGuard was designed from the beginning to run inside the operating system kernel rather than in userspace. On Linux, WireGuard has been included in the mainline kernel since version 5.6 (released March 2020). This in-kernel implementation provides significant performance advantages:

• No context switches: When a packet arrives on a WireGuard interface, the encryption/decryption happens directly in the kernel's network stack, without copying data between kernel and userspace. OpenVPN, by contrast, requires reading the encrypted packet from a TUN device into userspace, decrypting it, and writing the plaintext back to the TUN device — at least two context switches and two copies per packet.
• NAPI integration: WireGuard integrates with Linux's NAPI (New API) polling mechanism, allowing it to process packets in batches during high throughput, reducing per-packet overhead.
• Multi-core parallelism: WireGuard uses per-CPU parallel encryption and decryption queues, distributing cryptographic work across all available CPU cores. Handshake operations run on a separate single-threaded queue (since they are computationally expensive and rate-limited), while transport data processing scales linearly with core count.
• Efficient memory management: Packets are encrypted in-place within kernel socket buffers (SKBs) rather than being copied to separate encryption buffers. This eliminates unnecessary memory allocation and copying.

In benchmark comparisons, WireGuard consistently achieves throughput 2-4x higher than OpenVPN and is competitive with IPsec (and often faster due to its simpler processing pipeline). On modern hardware with AES-NI instructions, IPsec with AES-GCM can match WireGuard's ChaCha20-Poly1305 throughput, but on hardware without AES acceleration (common in ARM-based devices, routers, and mobile phones), ChaCha20 significantly outperforms AES because it uses only add, rotate, and XOR operations — no table lookups or special instructions required.

Userspace implementations of WireGuard also exist for platforms where kernel modules are impractical: wireguard-go (written in Go, used on macOS, Windows, and mobile platforms), boringtun (Cloudflare's Rust implementation), and wireguard-nt (a Windows kernel driver). These implementations share the same protocol and are fully interoperable.

Comparison with IPsec and OpenVPN

To understand why WireGuard has seen such rapid adoption, it helps to compare it against the two protocols it aims to supersede:

IPsec

IPsec is a protocol suite rather than a single protocol. It consists of IKE (Internet Key Exchange, now version 2) for key negotiation, ESP (Encapsulating Security Payload) for encryption, and AH (Authentication Header) for integrity-only protection. IPsec supports dozens of cipher suites, multiple modes (transport vs. tunnel), and a complex policy database (SPD) that maps traffic selectors to security associations (SAs).

The sheer complexity of IPsec means that two "IPsec" deployments may have very different security properties depending on their configuration. A misconfigured IPsec deployment might use 3DES-CBC, while a well-configured one uses AES-256-GCM — both are "IPsec." WireGuard eliminates this variance: every deployment uses the same strong algorithms.

IPsec also operates at the kernel level and achieves excellent performance, but its complexity makes it notoriously difficult to configure. Tools like StrongSwan, Libreswan, and Cisco's IKEv2 implementation each have their own configuration syntax and behavioral quirks. Interoperability between implementations, while much improved with IKEv2, remains a source of operational headaches.

OpenVPN

OpenVPN runs entirely in userspace, using a TUN/TAP device for packet injection. This architecture inherently limits its performance: every packet must cross the kernel-userspace boundary twice (once to read the encrypted packet, once to write the decrypted packet). OpenVPN also runs single-threaded by default, creating a bottleneck on a single CPU core.

OpenVPN's use of TLS for key exchange means it inherits all of TLS's complexity, including certificate management, cipher suite negotiation, and protocol version handling. OpenVPN supports TCP as a transport, which can cause "TCP-over-TCP" performance issues (TCP meltdown) when tunneling TCP traffic over a TCP-based VPN connection — an issue WireGuard avoids entirely by using only UDP.

One area where OpenVPN excels is firewall traversal. Because it can run over TCP port 443, it can disguise itself as normal HTTPS traffic. WireGuard's UDP-only design means it can be more easily detected and blocked by deep packet inspection. Some WireGuard deployments work around this by wrapping WireGuard packets inside a WebSocket or TCP tunnel, but this is not part of the WireGuard protocol itself.

WireGuard in Containers and Kubernetes

WireGuard's design as a simple kernel-level network interface makes it an excellent fit for container networking and Kubernetes cluster connectivity. Several major container networking projects have integrated WireGuard as an encryption backend:

Calico with WireGuard

Calico, one of the most widely deployed Kubernetes CNI (Container Network Interface) plugins, supports WireGuard for pod-to-pod encryption. When enabled, Calico automatically manages WireGuard tunnels between all nodes in the cluster. Each node gets a WireGuard key pair, and Calico's Felix agent distributes public keys and AllowedIPs via the Calico datastore. The AllowedIPs for each node include the pod CIDR ranges assigned to that node, so Cryptokey Routing naturally maps to Kubernetes pod networking.

This means that traffic between pods on different nodes is transparently encrypted without any changes to application code. The pod network remains a flat Layer 3 network — WireGuard encryption is invisible to the pods themselves. From a BGP perspective, Calico can also peer with the physical network using BGP, advertising pod CIDR ranges as routes. WireGuard encryption happens below this routing layer, so the BGP-advertised routes work normally — packets are encrypted at the WireGuard interface before being sent to the physical network.

Cilium with WireGuard

Cilium, the eBPF-based CNI, also supports WireGuard for transparent encryption. Cilium's approach is notable because it creates the WireGuard tunnels from within the eBPF datapath, minimizing overhead. Cilium uses WireGuard when it needs encryption across nodes but wants to avoid the overhead of IPsec's security association management at scale.

Tailscale and Mesh VPNs

Tailscale and similar "mesh VPN" products build their entire product on WireGuard. Tailscale creates a peer-to-peer WireGuard mesh between all of a user's devices, with a coordination server distributing public keys and AllowedIPs. The coordination server is not in the data path — once peers have exchanged keys, traffic flows directly between them via WireGuard.

Tailscale adds NAT traversal on top of WireGuard (since WireGuard itself does not perform NAT hole-punching). Their DERP (Designated Encrypted Relay for Packets) servers act as relays of last resort when direct peer-to-peer connectivity is impossible. But the encryption is always WireGuard end-to-end — the DERP relay only sees encrypted WireGuard packets.

WireGuard for Multi-Cluster Connectivity

In multi-cluster Kubernetes deployments, WireGuard tunnels can connect pod networks across clusters, data centers, or cloud providers. Tools like Submariner use WireGuard as the encrypted data plane for cross-cluster connectivity. Each cluster gateway node establishes WireGuard tunnels to gateway nodes in other clusters, with AllowedIPs configured to include the remote cluster's pod and service CIDR ranges. This creates a flat, encrypted network spanning multiple clusters — each cluster's subnet is routable from any other cluster.

Network Namespace Integration

On Linux, WireGuard interfaces can be created in one network namespace and moved to another. This is a powerful building block for container networking. A common pattern is to create the WireGuard interface in the host namespace (where the UDP socket is bound and can reach the physical network), then move the interface into a container's network namespace. The container sees only the WireGuard interface — it has no direct access to the host's physical network. Packets from the container are encrypted by WireGuard before entering the host network.

This pattern also provides network isolation: the container's traffic is always encrypted, and the AllowedIPs configuration limits which destination IP ranges the container can reach. The container cannot bypass the VPN because it has no other network interface.

Formal Verification

WireGuard's small code size has enabled something rare in networking protocols: formal verification. Multiple independent efforts have mechanically verified properties of the WireGuard protocol:

• A Tamarin Prover model verified the key exchange protocol's security properties, including key secrecy, authentication, key-compromise impersonation resistance, and identity hiding of the initiator.
• The CryptoVerif computational model verified the protocol in the computational (as opposed to symbolic) security model, providing stronger guarantees.
• An independent formalization in the F* programming language verified a reference implementation against the protocol specification.

These formal verification efforts are possible because WireGuard is small and simple. Attempting to formally verify IPsec or OpenVPN would be prohibitively complex due to the combinatorial explosion of cipher suites, modes, and state machine transitions. WireGuard's fixed-algorithm design reduces the verification problem to a tractable size.

Stealth and Detection

WireGuard is designed to be stealthy by default. A WireGuard interface that receives a packet it cannot authenticate simply drops it — no response is sent. This means a port scan of a WireGuard server reveals nothing: the UDP port appears closed or filtered. Only packets with a valid MAC1 (which requires knowing the responder's static public key) elicit any response. An attacker who does not possess the public key cannot even determine that a WireGuard service is running.

This property is described as making WireGuard peers "silent to scanners and invisible to unauthorized parties." It is a significant improvement over OpenVPN, which responds to connection attempts with a TLS handshake (revealing its presence), and IPsec, which responds to IKE_SA_INIT messages from any source.

However, WireGuard's fixed packet format (always UDP, specific message type fields, predictable packet sizes for handshake messages) makes it identifiable by deep packet inspection (DPI). Censorship regimes that block VPN protocols can fingerprint WireGuard handshake packets. This is a trade-off of the minimal design: there is no pluggable transport layer or obfuscation mechanism built into WireGuard itself. Solutions like wstunnel or obfuscation proxies can wrap WireGuard traffic inside other protocols (WebSocket, QUIC, HTTPS) to defeat DPI, but this is external to WireGuard.

Configuration Example

A complete WireGuard configuration is remarkably short. Here is a typical client configuration:

[Interface]
# Client's private key (generated with: wg genkey)
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
# IP address assigned to this client on the VPN
Address = 10.200.200.2/32
# DNS server to use when tunnel is active
DNS = 10.200.200.1

[Peer]
# Server's public key
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
# Server endpoint: public IP and UDP port
Endpoint = 203.0.113.1:51820
# Route all traffic through the tunnel
AllowedIPs = 0.0.0.0/0, ::/0
# Keep NAT mapping alive
PersistentKeepalive = 25

And the corresponding server configuration:

[Interface]
PrivateKey = uJvJNQ4LMgPyi9qnJF7QMFep0NrHTXqKAthmX3BYPX8=
ListenPort = 51820
Address = 10.200.200.1/24

# Client 1
[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2piVFBs2LUlVnc=
AllowedIPs = 10.200.200.2/32

# Client 2
[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.200.200.3/32

Notice what is absent: no cipher selection, no authentication method, no certificate authority, no TLS version, no HMAC algorithm, no key lifetime, no Phase 1/Phase 2 distinction. The configuration is just keys, addresses, and endpoints. Key generation is a single command: wg genkey | tee privatekey | wg pubkey > publickey. Compare this to generating an OpenVPN PKI with easy-rsa or configuring X.509 certificates for IPsec — the operational simplicity difference is dramatic.

Limitations and Trade-Offs

WireGuard's minimalist design involves deliberate trade-offs:

• No TCP transport: WireGuard only uses UDP. On networks that block all UDP traffic (some corporate firewalls, some hotel Wi-Fi), WireGuard cannot connect without an external tunneling layer. OpenVPN's ability to run over TCP port 443 is a genuine advantage in these environments.
• No built-in obfuscation: WireGuard packets have a recognizable fingerprint. In censorship-heavy environments (e.g., China's Great Firewall), WireGuard traffic can be identified and blocked. Obfuscation must be added externally.
• Static peer configuration: Peers must be pre-configured with each other's public keys. There is no built-in mechanism for dynamic peer discovery or key distribution. Solutions like Tailscale, Netmaker, or custom control planes address this by managing key distribution and configuration updates.
• No user authentication: WireGuard authenticates keys, not users. There is no username/password, RADIUS, or LDAP integration. User-level authentication must be handled by the control plane (e.g., Tailscale uses OAuth/SSO to authorize key registration, but WireGuard itself only sees keys).
• AllowedIPs is static: The AllowedIPs for each peer are configured at startup. Dynamically changing which subnets a peer can access requires reconfiguring the interface (though this can be done live with the wg set command without tearing down the tunnel).
• No Layer 2 support: WireGuard operates at Layer 3 (IP packets only). It cannot bridge Ethernet segments or carry non-IP protocols. OpenVPN's TAP mode and IPsec's L2TP integration provide Layer 2 tunneling when needed.

WireGuard and the Network Stack

Understanding how WireGuard fits into the broader networking picture helps explain both its performance and its routing behavior. When a packet enters a WireGuard tunnel:

1. An application sends a packet to a destination IP. The kernel's routing table directs the packet to the wg0 interface based on the destination IP and configured routes.
2. WireGuard looks up the destination IP in its Cryptokey Routing table (the AllowedIPs trie) to find the appropriate peer and session key.
3. The packet is encrypted with ChaCha20-Poly1305 using the session key and an incrementing nonce counter. The entire original IP packet becomes the AEAD ciphertext.
4. The encrypted payload is wrapped in a WireGuard transport header (type + receiver index + nonce) and placed inside a UDP datagram addressed to the peer's current endpoint.
5. This outer UDP packet is routed through the normal network stack — subject to the regular routing table, firewall rules, and physical interface selection. The outer packet's source and destination IPs are the public IPs of the two WireGuard peers.
6. The packet traverses the internet through the standard BGP-routed infrastructure, hopping through autonomous systems and internet exchange points like any other UDP packet.
7. At the receiving peer, the UDP packet arrives at the WireGuard UDP socket. The receiver index identifies the session, the nonce is checked against the anti-replay window, and the payload is decrypted.
8. The decrypted inner IP packet's source address is verified against the peer's AllowedIPs. If valid, the packet is injected into the kernel's network stack as if it arrived on a normal interface.

From the perspective of the physical network and BGP routing, WireGuard traffic is simply UDP traffic between two IP addresses. The routers, switches, and autonomous systems along the path see only the outer UDP packet headers. The inner encrypted IP addresses, ports, and payload are invisible. This means WireGuard traffic benefits from the same path selection, traffic engineering, and redundancy that BGP provides for all internet traffic.

See It in Action

WireGuard endpoints are just servers with IP addresses announced via BGP. You can look up any WireGuard server's IP address to see which autonomous system hosts it, what BGP routes reach it, and how it is connected to the global routing table. Many major VPN providers (Mullvad, IVPN, and others) have adopted WireGuard, and their server IPs are routed through the same BGP infrastructure as all other internet traffic.

Try looking up networks that run large-scale WireGuard deployments:

• Look up AS39351 - Mullvad VPN, a privacy-focused VPN provider that was among the first to adopt WireGuard
• Look up AS13335 - Cloudflare, whose WARP product uses WireGuard-based encryption for consumer VPN service
• Look up AS396356 - Tailscale, which builds its mesh VPN entirely on WireGuard
• Look up AS16509 - AWS, where many WireGuard-based VPN services are hosted

You can also look up any WireGuard server endpoint IP to see its BGP route, origin AS, and AS path. Use the BGP looking glass to trace the routing infrastructure that carries your encrypted WireGuard packets across the internet.