Through the
Tunnel

What a VPN Actually Is

A virtual private network builds an encrypted, authenticated tunnel between two points over a network you don't control. The mechanism is encapsulation: each original packet is wrapped inside a new outer packet whose payload is encrypted, so the transit network routes the outer packet while the inner one stays confidential and tamper-evident.

Two deployment shapes cover almost everything: remote-access (a laptop dialing into the corporate gateway) and site-to-site (two offices' gateways linked into one routed network). The rest of this guide is mostly about how the tunnel is built and secured — IPsec, IKE, WireGuard, TLS — and then, in §8, the trust question those mechanisms don't answer.

IPsec — AH, ESP & the Modes

IPsec is not one protocol but a suite (architecture: RFC 4301). Two protect the data, and each has a mode:

• AH — Authentication Header (RFC 4302): integrity and origin authentication, but no encryption. Because its integrity check covers parts of the outer IP header, AH breaks when a NAT rewrites those fields — which is why it's rarely used today and is optional in modern IPsec.
• ESP — Encapsulating Security Payload (RFC 4303): encryption and integrity/authentication of the payload. This is what essentially every real IPsec VPN uses.

Each protected flow runs over a Security Association — a simplex (one-way) agreement on algorithms, keys, and mode, indexed by a Security Parameter Index (SPI). A two-way tunnel therefore uses a pair of SAs. Setting those SAs up securely is the job of the next protocol.

IKE — Negotiating the Keys

Someone has to agree on the algorithms and derive the keys before ESP can protect anything. That's IKE (Internet Key Exchange). Version matters: IKEv1 is deprecated — RFC 9395 (2023) moved its defining RFCs (2407, 2408, 2409) to Historic — because its de-facto negotiated algorithms are dated and its handshake is more complex and weaker. Use IKEv2 (RFC 7296, an Internet Standard, STD 79).

Two authentication styles dominate: pre-shared key (PSK) — simple, but a shared secret to distribute and rotate — and certificate-based — scalable and individually revocable, at the cost of running a PKI. For remote-access, both are normally paired with user auth and MFA (see the Identity guide); the tunnel proving a device or shared key is not the same as proving the person.

Crypto Choices & What's Deprecated

A tunnel is only as strong as the algorithms it negotiated, and old defaults linger in configs for years. The IETF publishes implementation requirements — RFC 8221 for ESP/AH and RFC 8247 for IKEv2 (both updated by RFC 9395) — and the short version is: prefer authenticated encryption and modern groups, and actively remove the legacy options.

WireGuard — the Minimalist

WireGuard is the deliberate opposite of IPsec's flexibility. It ships a single, fixed cryptographic suite with no negotiation: the Noise protocol framework's IK handshake, Curve25519 for key exchange, ChaCha20-Poly1305 for authenticated encryption, and BLAKE2s for hashing. It runs only over UDP (default port 51820), and has been in the mainline Linux kernel since version 5.6 (March 2020). The codebase is on the order of a few thousand lines — small enough to audit — which is much of the point.

TLS VPNs & the Gateway as Target

Not every VPN is IPsec or WireGuard. TLS-based VPNs tunnel traffic inside a TLS session — convenient because TLS (typically over TCP 443) traverses firewalls and captive portals that block IPsec. OpenVPN is the classic example (a userspace daemon using TLS for its control channel); SSL-VPN appliances add clientless, browser-based access to internal apps. The convenience comes with a performance ceiling (TCP-over-TCP can stall) and, more importantly, a concentrated attack surface.

The defensive posture that follows: patch edge appliances first and fast, put the management interface out of band, assume that a compromised gateway means the credentials and secrets stored on it are exposed (rotate them; see Incident Response), and reduce what a single breached tunnel can reach — which is the argument of §8.

Full vs Split Tunnel & Ports

Once the tunnel is up, a routing decision remains: does all the client's traffic go through it, or only traffic bound for corporate resources?

• Full tunnel — every packet goes to the gateway. You can inspect and filter all of it, but you pay in latency and backhaul, and the user's general browsing rides through the corporate egress.
• Split tunnel — only corporate-bound traffic uses the tunnel; the rest goes direct. Faster and lighter, but the client is simultaneously attached to the corporate network and the open internet, so a compromised endpoint can bridge the two. That bridging risk is the security cost of split tunneling.

Firewall and NAT behavior depends on the protocol's ports. The IANA-registered defaults (all configurable in practice):

Tunnel ≠ Trust: VPN vs ZTNA

Here is the claim the whole guide has been building toward: a tunnel authenticates and encrypts a path; it does not authorize access. Classic remote-access VPNs grant the connected client a place on the network — and network location, in the Zero Trust model, is exactly the thing that should confer no trust. A phished credential, a compromised laptop, or a breached gateway turns "on the VPN" into broad lateral reach.

None of this makes VPNs obsolete — site-to-site IPsec still joins networks, and encrypted transit is still necessary. The correction is narrower: stop treating tunnel membership as authorization. Where you can, move remote access toward per-application, identity- and device-aware brokering (ZTNA), and everywhere, assume the tunnel can be entered by someone you didn't intend. That assumption is the Zero Trust guide's whole subject, and the reason this guide sits in both the Networking and the security conversation.

Troubleshooting

VPN tickets split cleanly by symptom. As always, change one thing at a time and read the phase the failure occurs in.

Myths That Mislead

Quick-Reference Card