Topic 22

VPNs and Encrypted Tunnels

VPN

A VPN builds an encrypted tunnel across an untrusted network so remote traffic is confidential and appears to originate inside a trusted zone. It is the traditional remote-access control, and understanding what it does — and the trust assumption it bakes in — is necessary to see why zero-trust access is replacing the "VPN equals inside" model.

This topic covers how tunnels work (IPsec, WireGuard, TLS VPNs), the split-versus-full tunnel choice, and the VPN's security limits, so Meridian's remote access lands engineers somewhere narrow rather than handing them the whole network.

What a Tunnel Provides

A tunnel gives encryption and encapsulation, so traffic crosses hostile networks unread and unaltered, plus an internal address that places the remote user "inside." What it provides is confidentiality and integrity — not, by itself, authorization. That distinction is the root of the VPN's central weakness: it establishes a secure pipe and then typically trusts whoever is at the end of it far too broadly.

IPsec vs WireGuard vs TLS VPNs

IPsec is the entrenched standard — ubiquitous and complex. WireGuard is the modern option: small, fast, auditable, and built on current cryptography. TLS-based VPNs (OpenVPN, SSL-VPN appliances) traverse firewalls easily but have been a rich source of critical vulnerabilities, and an exploited VPN gateway drops an attacker straight inside. The engine matters less than keeping it patched and landing users somewhere narrow.

Split vs Full Tunnel

A full tunnel routes all of a device's traffic through the corporate network — inspectable, but slower. A split tunnel sends only corporate traffic through the tunnel and everything else directly — faster, but the device is simultaneously on the untrusted internet and the corporate network, bridging the two. It is a real security-versus-usability tradeoff, decided by how much you need to inspect and how much you trust the endpoint.

The VPN's Trust Problem

A VPN authenticates a user or device onto the network and then usually trusts them broadly, so a stolen VPN credential or an exploited VPN appliance drops the attacker straight into the interior — exactly the perimeter weakness zero trust addresses. The fix is to land VPN users in a narrow, segmented zone (Chapter 4's segmentation), require phishing-resistant MFA to connect, and move broad remote access toward per-application zero-trust brokering.

VPN vs Zero-Trust Access

VPN — puts you on the network, then trusts you; broad access, one credential to steal, and the appliance itself is a juicy target. Still fits narrow, segmented access.

Zero-trust access (ZTNA) — brokers you to specific applications per authenticated request, with device-posture checks and no network-level trust. The direction for broad remote work.

Common Mistakes
  • Treating VPN access as full trust — landing remote users on a flat internal network so a stolen VPN credential reaches everything.
  • Running an unpatched VPN appliance — SSL-VPN gateways are among the most-exploited internet-facing devices, and a VPN vulnerability is a direct route inside.
  • Full-trust split-tunnel setups where the device bridges the untrusted internet and the corporate network with no inspection.
  • Weak or no MFA on the VPN, making a phished password sufficient for internal access.
  • Assuming the tunnel's encryption also provides authorization, when it only provides confidentiality and integrity.
Best Practices
  • Land VPN users in a narrow, segmented zone with least-privilege rules, not on the whole internal network.
  • Require phishing-resistant MFA to establish the tunnel, and monitor VPN logins for anomalies.
  • Keep VPN gateways patched aggressively — they are high-value internet-facing targets — or replace them with ZTNA.
  • Prefer modern tunnels like WireGuard, and move broad remote access toward zero-trust, per-application brokering.
  • Decide split vs full tunnel deliberately by how much traffic you need to inspect and how much you trust the endpoint.
Comparable toolsTunnels IPsec · WireGuard · OpenVPN · SSL-VPN appliancesZero-trust access Tailscale · Cloudflare Access · Zscaler · BeyondCorpLightweight SSH tunneling

Knowledge Check

A VPN establishes an encrypted tunnel. What does it NOT inherently provide?

  • Authorization — it grants access, then trusts broadly
  • Encryption of the traffic in transit
  • Encapsulation across the untrusted network
  • An internal routable address for the remote user's device

Why are unpatched SSL-VPN gateways such a serious risk?

  • They are internet-facing and drop an attacker straight inside
  • They silently stop encrypting all traffic once a single patch is missed
  • They automatically disable MFA when outdated
  • They only affect split-tunnel configurations

What is the security downside of a split tunnel?

  • The device is on the untrusted internet and the corporate network at once, bridging the two with no inspection
  • All corporate traffic becomes unencrypted
  • The VPN can no longer authenticate the user
  • It routes personal traffic through the corporate network

You got correct