The protocol is the actual engineering underneath your VPN. It decides how your traffic gets encrypted, how fast the connection is, and how well it holds up when your network changes. Here is where each one came from.
10 min read
In the early 1990s, the internet was growing faster than anyone had a plan for. Companies needed a way to let employees connect to internal networks from home or from branch offices over the public internet. The problem was that the public internet was not designed to be private. Traffic traveled in plaintext across infrastructure that nobody controlled. Anything sensitive going over it was a liability.
The solution that emerged was the Virtual Private Network. The "virtual" part was the key: you could create the effect of a private, isolated network over shared infrastructure. You did not need a dedicated leased line between two offices. You could route traffic through the public internet as long as you encrypted it first.
What changed over the next 25 years was the quality of that encryption, the speed of the connection, and the honesty of the code. Each protocol in this list is a response to the failures of the one before it.
Point-to-Point Tunneling Protocol came out of Microsoft in 1999.1 It was the first VPN protocol that most people ever used, because it shipped inside Windows. You did not need to install anything. It was fast, it was simple, and it was built into every copy of Windows 98 and Windows 2000.
The encryption it used was MS-CHAPv2, which was Microsoft's own password authentication scheme. That decision aged badly. Researchers started finding serious weaknesses in MS-CHAPv2 in the early 2000s, and by 2012 it was considered broken. Moxie Marlinspike and David Hulton demonstrated at DEF CON 20 that MS-CHAPv2 authentication could be cracked within 24 hours using commodity cloud hardware.2
The other structural problem with PPTP was that it used a control channel on port 1723 and a data channel using GRE (Generic Routing Encapsulation). Firewalls and network operators learned to block or interfere with GRE traffic, which made PPTP unreliable on networks that were not set up to allow it.
PPTP is still supported in a lot of VPN software for legacy reasons, but it should not be used. It is preserved for situations where a device is so old that nothing else works.
Layer 2 Tunneling Protocol was a collaboration between Cisco and Microsoft, published as RFC 2661 in 1999 and widely deployed through the early 2000s.3 L2TP on its own does not encrypt anything. It is purely a tunneling mechanism: it wraps packets so they can travel across networks that would not otherwise carry them. The actual encryption came from pairing it with IPsec.4
IPsec (Internet Protocol Security) is a framework that adds authentication and encryption at the network layer. Combining L2TP with IPsec gave you a reasonably secure tunnel. The handshake used real cryptography, and the encryption was stronger than what PPTP offered.
The downside was overhead. Because L2TP and IPsec are separate, packets get encapsulated twice: once by L2TP into a UDP packet, and again by IPsec. Double encapsulation adds latency and burns more CPU. On fast connections the difference was manageable. On slower hardware or high-latency networks it was noticeable.
L2TP/IPsec also ran primarily over UDP port 500 and port 4500, which are commonly associated with VPN traffic. ISPs and firewalls learned to recognise and block them. For users in restrictive network environments, this became a problem that neither Cisco nor Microsoft had a good answer for.
OpenVPN came from a different direction entirely. James Yonan was a software developer who wanted a VPN solution that was open source, auditable, and could run over TCP port 443, which is the same port used by HTTPS.5 That single decision made it significantly harder to block: a firewall that blocked OpenVPN on port 443 would also break all normal web browsing.
The first release was in 2001. OpenVPN used TLS (Transport Layer Security) for authentication and key exchange, and OpenSSL for the encryption itself. This was a deliberately conservative choice. TLS was already widely trusted and extensively reviewed. Rather than inventing new cryptographic mechanisms, OpenVPN built on top of ones that had been scrutinised by a large community.
OpenVPN became the community standard for a decade. Because it was open source, it could be independently audited. Security researchers could read the code, find problems, and report them. Multiple formal audits were conducted over the years. The trust it earned was based on transparency rather than corporate authority.
The weaknesses that eventually pushed developers toward alternatives were mostly about performance. OpenVPN runs in userspace, not in the kernel. Every packet has to make a round trip from kernel space to user space and back. On high-throughput connections, this costs real CPU time. Reconnections after a network change were also slow, which made it less suited for mobile use where devices frequently switch between Wi-Fi and cellular.
OpenVPN is still widely used and still trusted. For servers that need to maintain long-running connections across a broad range of client hardware, it is a reasonable choice. It is also the protocol used in most configurations where port 443 compatibility matters.
Internet Key Exchange version 2 was published as RFC 7296 in 2005.6 Like L2TP, IKEv2 does not encrypt traffic directly; it handles the key exchange that lets two parties agree on encryption keys. The actual traffic encryption comes from IPsec. The combination is usually called IKEv2/IPsec.
The thing that made IKEv2 interesting was MOBIKE: the IKEv2 Mobility and Multihoming Protocol.7 MOBIKE let a VPN session survive a network change. If you were connected to a VPN over Wi-Fi and switched to cellular, the session could migrate without dropping. You did not have to reconnect. For a laptop user moving around an office, this was convenient. For smartphone users, it was a significant improvement.
IKEv2/IPsec is fast. The handshake is efficient, and because IPsec operates at the network layer it avoids some of the overhead that OpenVPN accumulated by running in userspace. Apple and BlackBerry shipped IKEv2 as a native option in their mobile operating systems, which made it the default choice for enterprise mobile VPN deployments.
It still uses UDP ports 500 and 4500, which remain identifiable as VPN traffic. And the spec, while well-designed, is not simple. The RFC runs to over 150 pages. Implementing it correctly requires considerable care, and there have been implementation-specific vulnerabilities in various products over the years. The protocol itself is sound; the complexity of implementing it correctly is where things have occasionally gone wrong.
Jason Donenfeld was a security researcher who had spent time looking at VPN protocol code and found it, in his words, "nightmarishly complicated."8 OpenVPN had grown to hundreds of thousands of lines. IPsec implementations were notoriously difficult to audit. The more code there is, the more surface area there is for bugs.
His response was to start from scratch and build a protocol with the smallest possible codebase that would still do the job. WireGuard's initial implementation was about 4,000 lines of code. OpenVPN at the time was around 400,000. The difference is not just aesthetic. A smaller codebase is easier to audit, easier to verify formally, and statistically less likely to contain subtle security bugs.8
WireGuard used a fixed, opinionated set of modern cryptographic primitives: Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, BLAKE2 for hashing. There were no negotiable cipher suites, no legacy algorithm support, no options that could be misconfigured. You either used WireGuard's cryptography or you did not use WireGuard.
The first public version came out in 2015. In January 2020, Linus Torvalds wrote to the kernel mailing list: "Can I just once again state my love for it and hope it gets merged soon?"9 It was. WireGuard landed in Linux 5.6 in March 2020. Kernel inclusion meant the code would be maintained, reviewed, and improved by the broader Linux community going forward.
WireGuard runs in the kernel, which means packets do not have to cross the user/kernel boundary on every hop. The performance difference over OpenVPN on fast connections is measurable. Handshakes complete in milliseconds. Reconnections after a network change are near-instant.
One tradeoff worth knowing: WireGuard assigns each peer a static IP address on the VPN interface, and by design it does not rotate your IP without intervention. A naive WireGuard implementation could allow a server to correlate connection times with IP addresses. VPN providers that care about privacy address this by assigning IPs dynamically or using double-NAT. It requires active work on the provider's side, not something WireGuard handles automatically.
BuycatVPN supports WireGuard, IKEv2, and OpenVPN. WireGuard is the default: small codebase, kernel-level performance, and fast reconnection. IKEv2 is available for users on iOS and macOS where native integration and MOBIKE-backed session migration on cellular make it a practical alternative. OpenVPN is there for situations where WireGuard's UDP traffic is blocked, since it can fall back to TCP port 443 and pass through most restrictive firewalls.
PPTP is not supported. There is no configuration that makes it safe to use.
K. Hamzeh et al., IETF, July 1999
Moxie Marlinspike & David Hulton, 2012. Demonstrated real-time cracking of MS-CHAPv2 via CloudCracker
W. Townsley et al., IETF, August 1999
S. Kent & K. Seo, IETF, December 2005
James Yonan, initial release 2001. Source code at github.com/OpenVPN/openvpn
C. Kaufman et al., IETF, October 2014 (obsoletes RFC 4306)
P. Eronen, IETF, June 2006
Jason A. Donenfeld, NDSS Symposium 2017
Linus Torvalds, LKML, January 2020. "Can I just once again state my love for it and hope it gets merged soon?"
More in Foundations
