VPN protocols have evolved significantly from the early days of PPTP. Modern deployments center on WireGuard for performance-critical and modern use cases, IKEv2/IPsec for enterprise interoperability, and SSL/TLS VPNs for corporate remote access. Legacy protocols like L2TP and PPTP should be retired immediately.
IPsec / IKEv2
The enterprise gold standard for site-to-site VPNs and mobile client connections. IPsec operates at Layer 3, providing authentication (IKEv2 for key exchange) and encryption (ESP for payload). Supported natively by every major OS and network device vendor.
- IKEv2 supports MOBIKE — seamlessly handles IP changes (mobile roaming)
- Strong cipher options: AES-256-GCM, ChaCha20, SHA-384
- Interoperates with Cisco ASA, Juniper, Fortinet, pfSense, strongSwan
- Dead Peer Detection (DPD) for automatic tunnel recovery
- Certificate or PSK authentication; EAP for user-level auth
OpenVPN
Open-source TLS-based VPN that runs over TCP or UDP and can traverse most firewalls and NAT devices. Highly configurable, with a long track record in enterprise and SMB environments. Being displaced by WireGuard in new deployments for performance reasons.
- Runs on virtually any OS; large ecosystem of clients
- TLS 1.3 support; OpenSSL backend provides broad cipher choice
- Can run over TCP 443 — blends with HTTPS traffic
- Lower performance than WireGuard due to userspace TLS processing
- OpenVPN Access Server (commercial) adds GUI and LDAP integration
WireGuard
The modern VPN protocol, merged into the Linux kernel in version 5.6 (March 2020). WireGuard's ~4,000-line codebase is orders of magnitude smaller than IPsec or OpenVPN, dramatically reducing attack surface. Performance benchmarks consistently show 3–5x throughput improvement over OpenVPN.
- Cryptographic primitives: ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF
- Stateless design: peers silently ignore unauthenticated packets
- Handshake completes in 1 round-trip (vs. multi-round for IKEv2)
- Built into Linux kernel 5.6+; Windows/macOS via official client
- Foundation for Tailscale, Headscale, NetBird, Netmaker
SSL/TLS VPNs & Legacy Protocols
Clientless SSL VPNs (web-based) and thick-client SSL VPNs (Cisco AnyConnect / Secure Client, Palo Alto GlobalProtect) are common in enterprises. PPTP is cryptographically broken (MS-CHAPv2 compromised); L2TP without IPsec provides no encryption. Both should be disabled immediately.
- Cisco Secure Client (AnyConnect replacement): DTLS for performance
- Palo Alto GlobalProtect: integrates with PAN-OS policy engine
- Clientless SSL VPN: browser-based, limited application support
- PPTP: broken — RC4/DES encryption, MS-CHAPv2 crackable in <24h
- L2TP/IPsec with PSK: vulnerable to offline dictionary attacks
| Protocol | Security Level | Performance | Port / Transport | Best Use Case |
|---|---|---|---|---|
| WireGuard | Excellent (modern primitives, tiny codebase) | Excellent (kernel-native) | UDP 51820 (configurable) | New deployments, road warriors, mesh networking |
| IKEv2 / IPsec | Excellent (when configured correctly) | Very good (hardware offload) | UDP 500, 4500 | Enterprise site-to-site, mobile clients, iOS/Android native |
| OpenVPN | Good (TLS 1.3, well-audited) | Moderate (userspace) | UDP 1194 or TCP 443 | Cross-platform compatibility, legacy environments |
| Cisco AnyConnect / Secure Client | Good (DTLS, cert-based) | Good (DTLS) | TCP/UDP 443 | Large enterprise with Cisco infrastructure |
| L2TP / IPsec | Fair (IPsec required; PSK is weak) | Moderate | UDP 1701, 500, 4500 | Legacy support only — avoid for new deployments |
| PPTP | Broken — do not use | N/A | TCP 1723 | Retire immediately |
WireGuard represents a philosophical shift in VPN design: instead of a Swiss-army-knife protocol with hundreds of configurable options, it makes deliberate, opinionated cryptographic choices and implements only what is necessary. This minimalism is a security feature — less code means fewer vulnerabilities.
Cryptographic Primitives
WireGuard's cryptographic choices are fixed — there is no cipher negotiation. This eliminates entire classes of downgrade attacks and configuration mistakes. Every implementation uses the same primitives.
- ChaCha20: symmetric encryption — fast in software (no AES-NI required)
- Poly1305: message authentication — authenticated encryption with ChaCha20
- Curve25519: Elliptic Diffie-Hellman key exchange (ECDH)
- BLAKE2s: cryptographic hash function (faster than SHA-2)
- SipHash24: hash table keying to prevent hash-DoS
- HKDF: HMAC-based key derivation function
Peer Model & Configuration
WireGuard has no client/server distinction at the protocol level — every participant is a "peer." Each peer has a public/private key pair and a list of allowed IP prefixes for traffic routing. This symmetric model enables mesh networking as easily as hub-and-spoke.
- PublicKey: derived from PrivateKey via Curve25519
- AllowedIPs: both a routing rule and an access control list
- Endpoint: optional; if omitted, peer initiates connections only
- PersistentKeepalive: maintain NAT mappings for behind-NAT peers
- PresharedKey: optional post-quantum resistant layer
Tailscale & the WireGuard Ecosystem
Tailscale (founded 2019) builds a mesh VPN on top of WireGuard, solving the hard problems: key distribution, NAT traversal, and access control. It uses the Noise protocol framework (which WireGuard implements) and adds a coordination server for peer discovery.
- Tailscale handles NAT traversal automatically (STUN/DERP relay fallback)
- MagicDNS: assigns .ts.net hostnames to every device
- ACL policies in HuJSON — define who can reach what
- Tailscale Funnel: expose services to the public internet via Tailscale
- Headscale: open-source self-hosted Tailscale control plane
- NetBird: open-source mesh with built-in access control UI
Roaming & Mobile Support
WireGuard handles IP address changes transparently. When a mobile device switches from Wi-Fi to cellular, its public IP changes — WireGuard detects the new source IP from incoming authenticated packets and updates the peer's endpoint automatically.
- No re-authentication required on IP change
- Sub-second reconnection after network handoff
- iOS and Android official WireGuard apps available
- Split tunneling: configure AllowedIPs to route only specific traffic
# WireGuard server configuration (/etc/wireguard/wg0.conf)
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY_HERE
# Enable IP forwarding and NAT for internet access through VPN
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
# Peer 1: laptop (road warrior)
[Peer]
PublicKey = PEER1_PUBLIC_KEY_HERE
AllowedIPs = 10.10.0.2/32
# No Endpoint — peer initiates connections
# Peer 2: remote office router (site-to-site)
[Peer]
PublicKey = PEER2_PUBLIC_KEY_HERE
Endpoint = 203.0.113.50:51820
AllowedIPs = 10.10.0.3/32, 192.168.10.0/24
PersistentKeepalive = 25
---
# WireGuard client configuration
[Interface]
Address = 10.10.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY_HERE
DNS = 10.10.0.1 # Use VPN server as DNS resolver
[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0 # Route all traffic through VPN (full tunnel)
# For split tunnel, use specific prefixes: 10.10.0.0/24, 192.168.0.0/16
PersistentKeepalive = 25Why Traditional VPNs Fail Zero Trust
A VPN authenticates a user once and then grants broad network access. If credentials are stolen or a device is compromised, an attacker has the same access as the legitimate user — to the entire network segment, not just the specific application they need. Traditional VPNs also provide no continuous verification, no application-level granularity, and no visibility into what authenticated users do after connecting.
ZTNA Core Principles
ZTNA implements "never trust, always verify" at the application access layer. Rather than granting network access, ZTNA proxies connections to specific applications only, after verifying both the user identity and the device security posture for every request.
- Identity-centric: every request authenticated against IdP
- Device posture checked: OS version, patch level, EDR status, disk encryption
- Least-privilege: access to specific app/port, not entire network
- Application-layer proxy: users never reach the network directly
- Continuous verification: session re-evaluated; anomalies trigger step-up auth
Cloudflare Access
Part of Cloudflare Zero Trust (formerly Cloudflare for Teams), Cloudflare Access acts as a reverse proxy in front of internal applications. Users authenticate through an identity provider before Cloudflare forwards the request to the origin — the origin is never directly reachable from the internet.
- Supports any IdP: Okta, Azure AD, Google, GitHub, SAML, OIDC
- Cloudflare Tunnel (cloudflared): expose internal apps without opening firewall ports
- Short-lived JWT tokens: no persistent VPN session
- Free tier: up to 50 users; competitive pricing above that
- Browser-rendered SSH/RDP: no client software required
- WARP client for device-based access with posture checks
Tailscale as ZTNA
Tailscale provides mesh VPN with ACL-based access control that can implement ZTNA principles. Unlike perimeter-based ZTNA, Tailscale creates direct encrypted peer-to-peer tunnels between devices, with access policy enforced at the coordination server level.
- ACL policies: JSON-based, define which devices/users reach which ports
- Device posture keys: check for up-to-date Tailscale client, OS version
- Grants: ephemeral access for contractors without persistent enrollment
- Subnet routers: expose entire LAN segments through a single Tailscale node
- SSH integration: Tailscale SSH with centralized access logging
- Tailnet lock: protect against compromised coordination server
Other ZTNA Platforms
The ZTNA market has consolidated significantly since 2022. Established vendors offer feature-rich platforms; newer entrants provide open-source options for organizations that want self-hosted control.
- Zscaler Private Access (ZPA): market leader, cloud-native, strong enterprise features
- Palo Alto Prisma Access: integrates with PAN-OS NGFW capabilities
- Microsoft Entra Private Access: Microsoft's ZTNA, integrates with Entra ID
- NetBird: open-source, self-hosted ZTNA on WireGuard
- Teleport: identity-native infrastructure access (SSH, K8s, databases)
| Attribute | Traditional VPN | ZTNA |
|---|---|---|
| Access model | Network-level access (entire subnet or VLAN) | Application-level access (specific app, port, protocol) |
| Trust assumption | Trusted after single authentication event | No implicit trust; every request verified independently |
| Network exposure | Attacker with credentials can scan and move laterally | Application not reachable until auth succeeds; no network view |
| MFA enforcement | Optional; often at VPN gateway only | MFA enforced per-application by IdP integration |
| Device posture | Usually none, or basic certificate check | MDM enrollment, OS patch level, EDR status checked per-session |
| Audit capability | Connection logs (IP, duration, bytes) | Application access logs (user, app, action, time, device) |
| Blast radius of compromise | High — entire network segment accessible | Low — only explicitly authorized applications accessible |
SASE Is an Architecture, Not a Product
SASE (pronounced "sassy") is a Gartner-defined architectural framework that converges network connectivity (SD-WAN) with cloud-delivered security services into a single cloud-native platform. No single vendor delivers every SASE component equally well — most organizations adopt SASE incrementally, replacing point products over 2–5 years. SASE is not a product you buy — it's an architecture converging 5+ security functions.
SASE Components
Gartner's 2019 SASE framework (introduced by Neil MacDonald and Joe Skorupa) converges five major functions into a unified, cloud-native service delivered from globally distributed PoPs:
- SD-WAN: software-defined WAN for branch connectivity and traffic optimization
- CASB: Cloud Access Security Broker — visibility and control over SaaS usage
- FWaaS: Firewall as a Service — L7 inspection at cloud PoPs
- ZTNA: Zero Trust Network Access for application-level remote access
- SWG: Secure Web Gateway — URL filtering, malware inspection for web traffic
SSE — Security Service Edge
Gartner introduced SSE in 2021 as the security subset of SASE — CASB + ZTNA + SWG — without the SD-WAN networking component. SSE is the term used when organizations want cloud-delivered security without replacing their existing WAN infrastructure.
- Zscaler, Netskope, and Broadcom (Symantec) are SSE leaders (Gartner MQ)
- SSE enables gradual SASE adoption without ripping out WAN
- Can connect to existing SD-WAN via IPsec tunnels
- Cloudflare One bundles SSE + network services in unified platform
Cloudflare One
Cloudflare's SASE/SSE platform combines Cloudflare Access (ZTNA), Gateway (SWG + DNS filtering + FWaaS), CASB, DLP, and Magic WAN (SD-WAN replacement) into a unified dashboard, delivered from Cloudflare's 300+ PoP network.
- Cloudflare Gateway: DNS + HTTP filtering, blocks malware and phishing
- Magic WAN: replace MPLS with anycast Cloudflare network
- DLP: detect and block data exfiltration (PII, credentials)
- CASB: discover shadow IT, enforce SaaS security posture
- Strong competitive pricing; generous free tier for small orgs
Zscaler Internet Access & ZPA
Zscaler is the dominant cloud-native SSE/SASE vendor. Zscaler Internet Access (ZIA) proxies all outbound web traffic through Zscaler PoPs for inspection. Zscaler Private Access (ZPA) provides ZTNA for internal applications. Together they form the Zscaler Zero Trust Exchange.
- 100% proxy architecture — no IP pass-through
- SSL inspection at scale with minimal latency impact
- AI-powered threat prevention and data protection
- Suitable for large enterprises; pricing scales with users
- Strong compliance certifications (FedRAMP, ISO 27001, SOC 2)
| Consideration | Standalone VPN | SASE / SSE |
|---|---|---|
| Deployment complexity | Low–Medium (on-prem appliance) | Medium (agent rollout, IdP integration, policy migration) |
| Security posture | Network-level; limited visibility into app usage | Application + data visibility; DLP, CASB, threat prevention |
| Scalability | Appliance-limited; hardware upgrades required | Elastic cloud scale; PoPs absorb traffic globally |
| Cost model | CapEx (hardware) + OpEx (licensing) | OpEx per user/month; no hardware; vendor managed |
| Best fit | Small org, simple network, on-prem apps only | Distributed workforce, heavy SaaS usage, security-first orgs |
| Migration timeline | N/A (existing) | 12–36 months for full SASE adoption; start with SSE |
2024 VPN Appliance Vulnerabilities — Patch Within 24–48 Hours
2024 saw a wave of critical vulnerabilities in major VPN appliances exploited by nation-state actors and ransomware groups. Ivanti Connect Secure (CVE-2023-46805, CVE-2024-21887) was exploited by China-nexus threat actors in mass exploitation campaigns. Fortinet FortiGate and Cisco ASA/FTD also suffered critical auth-bypass CVEs. The Volt Typhoon campaign specifically targeted network edge devices including VPN appliances to establish persistent access to critical infrastructure. VPN appliances are high-value targets — treat them like internet-facing servers: patch aggressively, monitor for IoCs, and consider hardware refresh cycles of 3–4 years.
Always-On VPN vs. Split Tunneling
Always-on VPN routes all traffic through the corporate network, enabling full visibility and policy enforcement but increasing latency and VPN gateway load. Split tunneling routes only corporate traffic through VPN while direct internet traffic bypasses it — better performance but reduced visibility.
- Always-on: required for high-compliance environments (defense, finance)
- Split tunnel: acceptable when DNS filtering and EDR compensate
- Reverse split tunnel: route everything except known SaaS directly
- DNS-over-VPN: ensure DNS queries go through corporate resolver regardless
MFA for All VPN Connections
Credential-based VPN authentication without MFA is a primary attack vector. Phished credentials immediately translate to network access. All VPN connections should require MFA — hardware tokens (FIDO2/WebAuthn) are the strongest; TOTP apps are acceptable; SMS is a last resort.
- FIDO2/WebAuthn hardware keys: phishing-resistant (YubiKey, Google Titan)
- TOTP apps: Authy, Google Authenticator, Microsoft Authenticator
- Certificate + LDAP: machine cert for device auth, user password + TOTP
- Conditional access: block VPN from unmanaged devices regardless of credentials
Device Health Checks
ZTNA and modern enterprise VPNs check device security posture before granting access. A valid credential on an unmanaged, unpatched device should not grant the same access as a managed corporate device.
- MDM enrollment check (Intune, Jamf, Workspace ONE)
- Certificate-based device authentication (not just user auth)
- OS patch level: block connections from devices more than N days behind
- EDR agent running: check for CrowdStrike/SentinelOne/Defender status
- Disk encryption: require BitLocker/FileVault enabled
Kill Switch & DNS Leak Prevention
A kill switch blocks all internet traffic if the VPN connection drops, preventing accidental exposure of traffic on untrusted networks. DNS leak prevention ensures DNS queries cannot leak outside the VPN tunnel even during connection interruptions.
- Kill switch implemented via firewall rules (block all except VPN interface)
- WireGuard: implement with iptables or AllowedIPs = 0.0.0.0/0
- DNS leak test: dnsleaktest.com, ipleak.net for verification
- IPv6 leaks: ensure IPv6 either routed through VPN or blocked entirely
Privileged Remote Access (PAM)
Administrative access to critical systems (servers, firewalls, databases) requires additional controls beyond standard VPN. Privileged Access Management (PAM) platforms provide session recording, just-in-time access, and credential vaulting for privileged sessions.
- CyberArk, BeyondTrust, Delinea: enterprise PAM platforms
- Teleport: open-source identity-native access for SSH/K8s/databases
- Just-in-time (JIT) access: admin rights granted for a fixed window only
- Session recording: full video/text record of all admin sessions
VPN Usage Anomaly Monitoring
Legitimate VPN usage follows patterns. Monitoring for deviations — off-hours access, geographically impossible logins, unusual data volumes, access to uncharacteristic resources — enables early detection of compromised credentials or insider threats.
- Impossible travel alerts: login from NYC then London within 1 hour
- Off-hours access: administrator accounts connecting at 3am weekends
- Data volume anomalies: 10GB downloads from a typically low-usage account
- Concurrent sessions: same user connecting from two different countries