Learn WireGuard - History, Background & Why WireGuard

#Introduction

Before diving into configuration, it is important to know where WireGuard came from. Why is there a new protocol when OpenVPN and IPsec were already established? The answer lies in complexity, performance, and the way security is approached.

Episode 1 takes you on a historical journey: the evolution of VPNs, the birth of WireGuard by Jason A. Donenfeld in 2016, its inclusion in the Linux kernel in version 5.6 in 2020, and the design philosophy that makes it different. This understanding will become the lens through which you read every technical decision in the episodes that follow.

It is important to note that many of the principles discussed today still apply: minimal design, modern cryptography, and direct kernel integration. History gives you the reason behind every technical decision, not just the how-to.

#VPN Evolution Before WireGuard

To understand why WireGuard is considered a leap forward, you need to look at its two most dominant predecessors: OpenVPN and IPsec. Both solved the problem of secure connections between networks, but with very different approaches than WireGuard.

#OpenVPN: Feature-Rich, Heavy on Complexity

OpenVPN appeared around 2001 and became the de facto open-source VPN standard. It runs in userspace, builds tunnels over SSL/TLS, and supports many authentication modes. Its strength is flexibility; its weakness is weight: thousands of lines of code, two process components, and a large attack surface because it relies on a complex TLS stack.

The impact is real in the field: updating an OpenVPN configuration often means reading long documentation, checking compatible cipher suites, and handling two processes that interact with each other. For many teams, this burden itself becomes the main source of hard-to-trace configuration errors.

#IPsec: Standardized, But Complex to Manage

IPsec is an official suite of IETF protocols with negotiation mechanisms such as IKE. To understand it, you have to wrestle with ESP, AH, SA, SPD, and their companions. Two implementations are not even always easy to connect because there are so many options. IPsec is indeed powerful, but using it can feel like starting an airplane to cross the street.

Both approaches solve the same problem, but at a high cost of configuration and maintenance. Jason A. Donenfeld believed this situation could be simpler.

From his experience managing networks and security, Donenfeld concluded that a VPN does not have to be that complicated. His principle was simple: if you need to study hundreds of pages of documentation to connect two servers, the design is already wrong. This became the seed of the WireGuard philosophy we dissect next.

This mindset is important because it determines how WireGuard is evaluated: not by the number of features, but by how few things can go wrong.

#The Birth of WireGuard

#From Patch to the Linux 5.6 Kernel

WireGuard was first released by Jason A. Donenfeld in 2016 as an experimental project. The protocol uses the Noise Protocol Framework, modern keys, and a design called cryptokey routing. After years of testing and widespread deployment, its module was finally merged into the Linux kernel in version 5.6 in March 2020.

The journey from initial patch to kernel acceptance was not a short road. The protocol passed through many security reviews, field tests, and fixes before being considered stable. It is this discipline that made WireGuard accepted by a famously selective kernel community.

uname -r
modinfo wireguard | head -5

If your kernel is 5.6 or later, the modinfo wireguard command will show the description of the kernel's built-in module. Before that, users had to compile the module via wireguard-dkms or wait for their distribution to provide a package.

This built-in module availability removed the biggest adoption barrier: no more external drivers to compile or keep versioned. Since then, WireGuard has been part of every modern Linux installation, just like iptables or OpenSSH.

#Philosophy: Minimal and Crypto-First

WireGuard was built on the conviction that security is stronger when its surface is small. The entire core codebase is only around four thousand lines of code. There are no authentication modes that can be misconfigured, no cipher suites to choose, and no algorithm negotiation. Each key has a single role, and each packet has a single format.

The consequence: security audits become far more feasible, and long-term bugs are easier to find. This is a direct contrast to OpenVPN and IPsec, which offer dozens of options.

Fewer choices does not mean lower quality. On the contrary, every primitive in WireGuard is chosen from the best available, and the fixed combination has been audited repeatedly. This is the opposite strategy from the many-options approach of older VPN technology.

It also means documentation and the learning curve are shorter. You do not need to memorize cipher suite tables or authentication modes; all you need to understand is interfaces, keys, and peers. Simple — and that is exactly where its strength lies.

#Why WireGuard Uses Cryptokey Routing

#The Public Key as Identity

Once a public key is assigned to an interface, it becomes a legitimate identity on the network. There is no login step, no expiring certificate, and no negotiation like IKE. When a packet arrives, WireGuard asks only one question: which public key sent this packet?

Because identity is bound directly to cryptography, the security decision and the routing decision become one and the same. This concept is called cryptokey routing, and we will dissect it in full in episode 2.

From an operational point of view, this means identity management becomes file management: registering a peer is as simple as pasting its public key into the configuration. No certificate authority, no validity periods, and no long onboarding procedures.

#The Problems It Solves

A quick comparison that explains why WireGuard exists:

• Performance: runs in kernel-space, processing packets without waking a userspace process.
• Configuration: one configuration file per interface, readable in minutes.
• Security: curated modern cryptography, with no cipher choices that can be picked wrong.
• Ecosystem: the same single protocol is used on Linux, Windows, macOS, Android, and iOS.

None of these advantages come from having many features; they all come from the discipline of limiting scope. By solving just one problem well, WireGuard managed to be both more secure and faster at the same time.

There is one more thing that should not be forgotten: WireGuard also makes security audits easier because the entire code can be read by anyone. Transparency is not a guarantee, but the opportunity for open review is far greater than with closed code.

#Expansion to Every Platform

#More Than Just the Linux Kernel

Although it was born in the Linux kernel, WireGuard is now officially supported everywhere. There is a userspace implementation called WireGuard-Go for FreeBSD and other platforms, WireGuardNT for Windows, and official apps for Android, iOS, and macOS. It all remains one protocol and one configuration format.

This diversity of implementations is still controlled by one strict specification, so behavior does not drift between platforms. This is the reason you can support many kinds of devices without thinking about vendor differences.

This consistency is a selling point in itself. The wg0.conf file you write in episode 3 can be used almost identically on every platform — unlike the IPsec experience, where each implementation differs in the way you configure it.

This consistency also lowers training costs: one configuration format learned on Linux can be applied directly to a colleague's Windows laptop or your own phone. This is what you will feel when we start practicing in episode 3.

Finally, the tools ecosystem follows the same format: official apps, wg-dashboard, and even Tailscale use a similar configuration structure. The knowledge you build in this series will not be wasted when you try other tools.

#Closing

Episode 1 explained the background of why WireGuard exists: rejecting the complexity of OpenVPN and IPsec, delivering a minimal protocol based on modern cryptography, and successfully entering the Linux 5.6 kernel in 2020.

Key takeaways:

• OpenVPN and IPsec are too complex for most needs.
• WireGuard was created by Jason A. Donenfeld in 2016 and entered the Linux 5.6 kernel in 2020.
• The core codebase is only around 4,000 lines of code.
• Cryptokey routing makes the public key both an identity and a routing decision.
• One protocol is used consistently across all major platforms.

In episode 2 we will dissect the core concepts and main architecture of WireGuard — cryptokey routing in depth, the Noise Protocol Framework that handles the handshake, and how the wireguard.ko kernel module, the wg0 interface, and the wg CLI work together. Prepare your two VMs, because starting from episode 3 we practice directly.