A VPN is an encrypted tunnel that makes a remote device behave as if it sat on a private network. The idea is old. Tunneling protocols arrived in 1999, IPsec became the long running standard, and newer designs such as WireGuard now favor small code and modern cryptography.
Why did VPNs appear in the first place?
Before the public internet was everywhere, companies rented private lines between offices. That was safe and expensive. Once the internet offered cheap connectivity, the problem became how to borrow it without exposing traffic to everyone in between.
The answer was tunneling: wrap a private packet inside another packet, send it across the public network, and unwrap it at the far end. Encryption and authentication were then added so the wrapper could not be read or forged.
What did the first generation look like?
Two protocols from 1999 show the shape of the era. RFC 2637 describes the Point to Point Tunneling Protocol (PPTP), published in July 1999 and written by a vendor consortium. It is an informational memo, not an Internet standard, and its own security section is candid about gaps: the control channel messages are neither authenticated nor integrity protected, and the GRE packets forming the tunnel are not cryptographically protected by the protocol itself.
RFC 2661, published a month later in August 1999, specifies the Layer Two Tunneling Protocol (L2TP) on the standards track. L2TP carries link layer frames but leaves confidentiality to other layers, which is why it is commonly paired with IPsec.
The lesson of this era is that a tunnel is not the same as a secure tunnel. Security had to come from somewhere else.
How did IPsec become the standard?
IPsec adds security at the network layer for any traffic between two endpoints. The architecture was first written down in RFC 2401 and replaced by RFC 4301, published in December 2005 on the standards track. Key exchange is handled separately, usually by IKE. NIST SP 800-77 Revision 1 is a practical guide to deploying it and also covers alternatives and when each fits.
IPsec is flexible and widely supported by routers and firewalls. It is also large and has many options, which makes configuration mistakes easy.
What changed with newer designs?
Two pressures pushed designers toward something simpler. People now work from phones and laptops that roam between networks, and large configuration surfaces are hard to audit.
WireGuard, described on its project site, takes the opposite approach to IPsec. It uses a fixed set of modern primitives (Noise protocol framework, Curve25519, ChaCha20, Poly1305), pairs peers by exchanging public keys much as SSH does, and aims for a codebase small enough for one person to review. It started in the Linux kernel and now runs on other platforms. The project's own claims of being simplest or most secure are its own view; read the protocol paper and judge for yourself.
Constructed example: one company, three decades of choices
Imagine a firm that connected two offices with a leased line, then moved to a router based IPsec tunnel in the 2000s, then gave staff a client based VPN for home working. Each step solved one problem and created another. The IPsec tunnel needed careful policy matching. The client VPN put every laptop on the internal network, which raised the question of what an infected laptop could reach. That question is why many teams now pair a VPN with segmentation and per application access.
How to check or apply this
- List which VPN protocols your gateways and clients use. Retire any that rely on tunnels with no cryptographic protection of their own.
- Confirm the cipher suites in use match current NIST guidance in SP 800-77 Revision 1.
- Look at what a connected user can reach. A VPN login should not mean access to every subnet.
- Patch VPN gateways promptly, since they are internet facing by design.
- Keep a written reason for each remaining VPN, and review it yearly.
Quick check
Is a VPN the same as encryption?
No. A VPN creates a tunnel and usually encrypts it, but the protocol decides how strong that protection is. RFC 2637 shows an early tunnel whose own data was not cryptographically protected.
Is WireGuard a replacement for IPsec everywhere?
Not automatically. IPsec is built into a great deal of network equipment and policy, so the right choice depends on your devices, your compliance needs and your team's skills.
Sources
- RFC 2637, Point to Point Tunneling Protocol
- RFC 2661, Layer Two Tunneling Protocol
- RFC 4301, Security Architecture for the Internet Protocol
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- WireGuard project site
Last reviewed: 18 October 2026.
