VPNs and Tunneling


VPN and tunneling technologies carry traffic across a network that does not natively provide the required connectivity. Some tunnels provide encryption and authentication. Others provide only encapsulation and must be paired with a security layer.

Common Use Cases

  • Remote users accessing private applications
  • Site-to-site connectivity between offices or data centers
  • Extending routed networks across an internet connection
  • Connecting cloud and on-premises environments
  • Carrying dynamic routing across an intermediate network
  • Creating encrypted management access

Technology Comparison

TechnologyEncryptionTypical useOperational notes
IPsecYesSite-to-site and standards-based remote accessPowerful but sensitive to proposal, identity, NAT, and routing mismatches
WireGuardYesSimple routed site-to-site and remote accessSmall configuration surface; routing and key distribution remain operator responsibilities
OpenVPNYesRemote access and flexible client deploymentsMature and widely supported; can run over TCP or UDP
GRENoRouted overlays and carrying multicast or routing protocolsOften paired with IPsec when confidentiality is required
VXLANNo by itselfLarge Layer 2 overlays over a Layer 3 underlayCommon in data-center fabrics; requires control-plane and MTU planning

Site-to-Site Versus Remote Access

A site-to-site VPN normally connects networks through gateways. End devices use the tunnel without running VPN software. A remote-access VPN terminates an individual user or device and normally applies identity-based policy.

Route-Based and Policy-Based VPNs

  • Route-based: Creates a tunnel interface and uses normal routing to select traffic.
  • Policy-based: Encrypts traffic that matches defined source and destination selectors.

Route-based designs are usually easier to combine with dynamic routing and multiple subnets. Policy-based tunnels may be appropriate for simple interoperability but can become difficult to manage as selectors grow.

WireGuard Example

[Interface]
Address = 10.200.0.1/30
PrivateKey = <local-private-key>
ListenPort = 51820

[Peer]
PublicKey = <remote-public-key>
AllowedIPs = 10.200.0.2/32, 10.20.0.0/16
Endpoint = 198.51.100.20:51820
PersistentKeepalive = 25

AllowedIPs acts as both a routing selector and a source-address control. Overlapping or overly broad entries can send traffic to the wrong peer.

IPsec Troubleshooting Layers

  1. Can the peers reach each other?
  2. Do IKE version, encryption, integrity, authentication, and Diffie-Hellman settings match?
  3. Do identities and pre-shared keys or certificates match?
  4. Do traffic selectors match?
  5. Are routes sending traffic toward the tunnel?
  6. Are NAT exemption and firewall rules correct?
  7. Does the remote network have a return route?

MTU and MSS

Encapsulation adds headers, which reduces the payload that fits inside the original path MTU. A tunnel may appear healthy while large packets or TCP transfers fail.

  • Set tunnel interface MTU appropriately.
  • Allow Path MTU Discovery messages through firewalls.
  • Use TCP MSS clamping when required.
  • Test with large pings that set the do-not-fragment bit.
ping -M do -s 1372 203.0.113.10
tracepath 203.0.113.10

Routing Over Tunnels

Static routes are sufficient for simple tunnels. Dynamic routing is useful when multiple sites, redundant tunnels, or many prefixes are involved. Keep routing adjacencies authenticated and filter the routes accepted across the tunnel.

NAT Considerations

VPN traffic is commonly broken by NAT rules that run before encryption. Exempt private-to-private traffic from source NAT unless address translation is intentionally part of the design. Overlapping address space between sites may require translation or renumbering.

Security Considerations

  • Use current cryptographic suites and disable obsolete protocols.
  • Rotate keys and certificates.
  • Restrict tunnel access to required networks and ports.
  • Log authentication failures and tunnel state changes.
  • Do not assume encrypted traffic is automatically trusted.
  • Patch internet-facing VPN gateways promptly.

Operational Checklist

  • Document endpoints, tunnel addresses, protected networks, and owners.
  • Monitor tunnel state, latency, loss, and traffic volume.
  • Test failover and key rotation.
  • Back up gateway configuration.
  • Verify IPv4 and IPv6 behavior independently.
  • Record expected MTU and MSS values.