Networking and Protocols

VPN

Encrypted tunneling that extends a private network across an untrusted network.

Where you will see it: Shows up in packet captures, network diagrams, firewall rules, and system or network logs.

What it is

A VPN (Virtual Private Network) is a technique for carrying one network's traffic across another network securely. Your original packets are wrapped inside an outer transport that provides encryption and integrity, forming a tunnel between two endpoints.

Key points
  • Works by encapsulating packets inside an encrypted outer packet.
  • Key exchange and authentication decide who is allowed into the tunnel.
  • Routing, DNS, and MTU behavior change when a tunnel is active.

How it works in broad strokes

  1. A VPN client or gateway starts by contacting the VPN server or peer and authenticating, often with certificates, shared secrets, or user credentials.
  2. The endpoints perform a key exchange and agree on cryptographic parameters, for example via IKEv2 in IPsec or the Noise based handshake in WireGuard.
  3. A virtual interface is created on the client, and routes are added so certain traffic is sent into the tunnel.
  4. When an application sends a packet, the OS routes it to the virtual interface. The VPN software encrypts it and encapsulates it in a new outer packet.
  5. The outer packet is sent across the Internet to the VPN peer. Only the outer headers are visible to intermediaries.
  6. The peer decrypts, verifies integrity, removes the outer wrapper, and forwards the inner packet toward its destination.
  7. Keepalive traffic and rekeying maintain the tunnel and refresh keys over time, and the tunnel must account for MTU overhead introduced by encapsulation.

Concrete example

You are on a hotel network and open a corporate internal dashboard. Your laptop sends internal IP traffic into the VPN tunnel. The hotel only sees encrypted packets to the VPN server, and the corporate network sees your traffic as if you were on the office network.

Why it matters

The Internet is not private. Organizations need remote access and site connectivity without exposing internal traffic or relying on the security of intermediate networks. VPNs provide confidentiality, integrity, and often identity based access to internal resources.

Security angle

  • Key management is core. Strong authentication and regular key rotation are more important than brand names.
  • Treat VPN access as privileged. Monitor logins, enforce device posture when possible, and limit reachable subnets.
  • Modern designs often move toward zero trust where VPN becomes one tool among others rather than a blanket network bridge.

Common pitfalls

  • Split tunnel confusion. Some traffic goes through the VPN, some does not, which can cause inconsistent behavior.
  • DNS leaks. If DNS queries do not follow the intended path, you can reveal internal names or browsing activity.
  • MTU and fragmentation problems due to encapsulation overhead.
  • Overly broad access. A VPN can accidentally grant full internal network reach instead of least privilege.
  • Assuming VPN equals security everywhere. If the endpoint is compromised, the tunnel becomes a safe path for the attacker too.

DEEP DIVE

The mental model: a virtual interface and new routes

A VPN client typically creates a virtual network interface on your device. Your operating system can route some traffic into that interface based on rules. Packets sent into the tunnel are then encapsulated: wrapped inside an outer packet whose destination is the VPN gateway or peer.

From the application viewpoint, nothing special happens. It sends IP packets as usual. The VPN layer intercepts and wraps them. At the far end, the gateway decapsulates and forwards the inner packet into the private network, as if your device were locally attached.

This is why split tunneling versus full tunneling matters. In split tunneling, only certain destinations go through the tunnel. In full tunneling, the default route points into the VPN, so almost everything goes through it, including DNS unless configured otherwise.

Authentication and key agreement before any tunnel traffic

A secure tunnel needs shared keys. That usually begins with an authentication step: you prove you are allowed to join, and the server proves its identity. The end result is a set of keys used to encrypt and authenticate tunnel packets.

In IPsec, this setup is formalized through security associations. IKE negotiates parameters and keys, then ESP carries the protected traffic. The keys and policies define which traffic is protected and how. IPsec can run in transport mode, protecting the payload of an IP packet, or tunnel mode, wrapping an entire IP packet inside a new one.

In WireGuard, the model is simpler. Peers are identified by static public keys, and allowed IP ranges act like a combined routing and access control list. A short handshake establishes ephemeral session keys, and data packets are then protected with modern authenticated encryption.

What actually happens when you connect

A remote access VPN often starts with the client reaching the gateway over the public internet, usually over UDP or TCP depending on the protocol. After authentication and handshake, the client may receive a virtual IP address, DNS settings, and a list of routes to send through the tunnel.

Once up, tunnel traffic is just packets. Your device sends an inner packet destined for a private server. The VPN encapsulates it and sends it to the gateway. The gateway decrypts, checks policy, then forwards the inner packet to the private destination. Replies make the reverse trip, encapsulated back to the client.

Because the tunnel is stateful, keepalives are common. NAT devices can time out idle mappings, so VPN clients often send periodic traffic to keep the path open. If you see disconnects after idle periods, NAT timeouts or aggressive firewall policies are common causes.

Common operational pitfalls

MTU issues are frequent. Encapsulation adds overhead, which reduces effective MTU. If path MTU discovery fails, large packets can black hole. Many VPN setups require adjusting the tunnel MTU or enabling proper ICMP handling.

DNS is another source of confusion. If DNS queries do not go through the tunnel when they should, you can leak internal names to public resolvers or fail to resolve private domains. Good VPN configurations explicitly set DNS and ensure the resolver traffic follows the intended route.

Finally, trust boundaries matter. A VPN does not automatically make a device safe. It extends network reach. Organizations often pair VPN access with device posture checks, segmentation, and least privilege rules so that joining the VPN does not imply full internal access.