Learn WireGuard - Core Concepts & Main Architecture

#Introduction

WireGuard looks simple from the outside, but inside there are three pillars that determine how it works: cryptokey routing, the Noise Protocol Framework, and the kernel architecture. Understanding all three will make you far more confident reading wg show output and debugging problematic connections.

Episode 2 dissects these three pillars one by one. There are no new commands here — this is purely concepts — but these concepts are the language used by every following episode.

Additionally, this episode reinforces one mindset you will need throughout the series: WireGuard is a protocol with few commands but rich consequences. Every small option like AllowedIPs carries large security and routing implications, and understanding them early prevents hard-to-trace mistakes.

#Cryptokey Routing

#The Public Key as Router

Cryptokey routing is the core of WireGuard's design. Each interface has one private key and a list of peers, and each peer is identified by its public key. Data is encrypted for a specific public key, and only the recipient holding the matching private key can open it.

[Interface]
PrivateKey = (rahasia, tidak pernah dikirim)
Address = 10.0.0.1/24
ListenPort = 51820
 
[Peer]
PublicKey = (kunci publik client)
AllowedIPs = 10.0.0.2/32

Notice AllowedIPs. For WireGuard, this line is not just a firewall: it declares which addresses are "owned" by the peer with that public key. Traffic to 10.0.0.2 is automatically encrypted for that peer, and incoming packets claiming to be from 10.0.0.2 are only accepted when validly encrypted by that peer. There is no protocol negotiation like IKE here.

This mechanism is called key-based routing because the security decision and the routing decision are merged: who is allowed to send to an address also determines through which path packets are sent. There is no separate table between access permissions and the routing table.

#No "Negotiation Protocol"

This is the most fundamental difference from IPsec. IPsec spends time building a Security Association through IKE. WireGuard has no such concept: once the key and AllowedIPs are in place, every matching packet is processed directly. The handshake happens in the background when the first packet is sent, not as a separate configuration phase.

For those of you used to IPsec, the consequences feel big: there is no configuration phase that can fail before the connection is used, and no SA state that can hang. If the peer configuration is correct, the connection just runs.

In practice, this makes debugging much faster: if traffic is not flowing, the problem is almost always in just three places — the key, the endpoint, or AllowedIPs. There is no negotiation phase to unravel first.

#Noise Protocol Framework

#One-Round-Trip Handshake

WireGuard uses the Noise Protocol Framework with a handshake pattern known as Noise IKpsk2. Under normal conditions, the handshake takes only one round trip: the initiator sends a handshake initiation, the responder replies with a handshake response, and after that encrypted data can flow in both directions.

Its cryptographic basis is:

• Curve25519 for Diffie-Hellman-based key exchange.
• ChaCha20-Poly1305 for authenticated encryption of data.
• BLAKE2s for hashing.
• SipHash24 for internal data structures.

This combination of four was chosen for efficiency and security on modern hardware, including CPUs with special instructions. WireGuard offers no alternatives, and that is the essence of the crypto-first approach we discussed in episode 1.

#Rekeying and Anti-Replay

After the handshake, the session is not idle. WireGuard automatically replaces session keys roughly every two minutes, or after a certain number of packets. The goal is to preserve forward secrecy: if one session key leaks, the damage is limited. Replayed packets are also rejected through a sliding window counter.

The two-minute interval is not a random number. It is a balance between strict forward secrecy and low handshake overhead. Because the handshake is cheap and involves no negotiation, replacing session keys that often does not meaningfully burden the CPU.

wg show wg0 latest-handshakes

If the handshake is old, the latest-handshakes column shows the time in UNIX timestamp format. A value of zero means no handshake has ever happened.

#Kernel Architecture

#Module, Interface, and CLI

Architecturally, WireGuard consists of three layers that communicate over netlink:

• Kernel module wireguard.ko: creates the wg0 interface and processes all packets in kernel-space.
• Interface wg0: a virtual network device of type wireguard that looks like a regular NIC.
• CLI wg: a userspace tool that sends configuration to the module over netlink.

ip link add dev wg0 type wireguard
wg set wg0 listen-port 51820
wg show wg0

The wg set wg0 listen-port 51820 command above shows that all changes are made live over netlink, without restarting the interface. This is what enables real-time key rotation and peer changes, which we will practice in episode 12.

This separation of layers also makes debugging easier: when there is a problem, you can inspect each layer separately, from the module state to the configuration sent by the CLI.

Once these three pillars are mastered, all subsequent episodes are just variations on the same theme: interfaces, peers, and keys. So take your time understanding this section before moving on to practice.

#Why Kernel-Space Matters

By placing encryption in kernel-space, WireGuard processes packets without a kernel/userspace context switch for each packet. This explains why WireGuard is almost always faster than OpenVPN, which runs in userspace. We will test its performance in detail with iperf3 in episode 15.

The practical impact is felt when many clients connect to one server: with packet processing in the kernel, WireGuard can handle high throughput without a userspace process becoming the bottleneck. We will measure the exact numbers in episode 15.

#Closing

Episode 2 gave you the language to understand WireGuard: cryptokey routing, which makes the public key a route; Noise IKpsk2, which completes the handshake in one round trip with periodic rekeying; and a three-layer architecture of kernel module, interface, and CLI.

Key takeaways:

• AllowedIPs is a key-based routing decision, not just a firewall.
• There is no negotiation protocol like IKE; the handshake happens when the first packet is sent.
• The handshake uses Noise IKpsk2 with Curve25519 and ChaCha20-Poly1305.
• Session keys are rekeyed automatically roughly every two minutes.
• wg communicates with the kernel over netlink; all changes are live.

In episode 3 we start practicing: installation and initial setup — installing WireGuard on Debian/Ubuntu and other distributions, generating a key pair, creating your first wg0.conf, and bringing the interface up with wg-quick up. Get your two VMs ready now.