VPN Type Comparison — Full Reference
| Attribute | SSL/TLS VPN (Remote Access) | Site-to-Site IPsec VPN | SD-WAN | SASE |
|---|---|---|---|---|
| Primary use case | Individual user remote access from any location | Permanent network-to-network connection between two sites | Optimized WAN routing for cloud applications | Complete cloud-native network + security platform for all users |
| Who initiates | Individual user (on-demand) or auto-connect (always-on) | Firewalls — automatic, no user action | SD-WAN edge device — automatic per-flow routing | SASE client on device — automatic, transparent |
| Client software | Required on user device (browser or lightweight client) | None on user devices — only firewalls involved | SD-WAN edge device (hardware or software at branch) | SASE client installed on all devices |
| Port / protocol | TCP 443 (TLS) — passes through all firewalls | IPsec (UDP 500, 4500, ESP protocol 50) | Multiple transports (MPLS, broadband, LTE, SD-WAN overlay) | Cloud-hosted PoPs — all transports |
| Authentication | Flexible: username/password, MFA, SSO, certificates — no requirement for certs | Pre-shared key or certificates; stronger key management required | Device-based (no per-user auth at WAN level) | Identity-based; ZTNA per-application verification |
| Always-on | Optional (can be configured) | Yes — tunnels are persistent | Yes — routing is always active | Yes — client connects automatically |
| Security provided | Encrypts traffic between user and concentrator | Encrypts traffic between two network gateways | Routing optimization; limited security | Full security stack: ZTNA, SWG, CASB, FWaaS, DLP, threat prevention |
| Cloud optimization | No — traffic still routes through corporate concentrator | No — all traffic routes through both firewalls | Yes — direct-to-cloud routing | Yes — traffic inspected at nearest cloud PoP, then sent directly |
IPsec Tunnel Mode — Packet Structure
ORIGINAL PACKET (before tunneling):
┌──────────────────────┬────────────────────────────────────┐
│ Original IP Header │ Data Payload │
│ (src: 192.168.1.10 │ (application data, unencrypted) │
│ dst: 10.10.1.30) │ │
└──────────────────────┴────────────────────────────────────┘
TUNNELED PACKET (after IPsec encapsulation):
┌──────────┬──────────┬──────────────────────────────────┬──────────┐
│ New IP │ IPsec │ ENCRYPTED PAYLOAD │ IPsec │
│ Header │ Header │ [Original IP Header] [Data] │ Trailer │
│ │ │ │ │
│ src: user│ Security │ ← completely invisible to routers │ Marks │
│ dst: VPN │ assoc ID │ between user and concentrator │ payload │
│ conc. IP │ │ │ end │
└──────────┴──────────┴──────────────────────────────────┴──────────┘
↑ ↑
Routers read this to forward Concentrator reads this to decrypt
The concentrator strips New IP Header + IPsec Header, decrypts the payload, recovers the original packet, and forwards it to the internal destination.
SSL/TLS VPN vs. Site-to-Site IPsec VPN
| Attribute | SSL/TLS VPN | Site-to-Site IPsec VPN |
|---|---|---|
| Also called | Remote access VPN | Site-to-site VPN; LAN-to-LAN VPN |
| Transport protocol | TLS over TCP 443 | IPsec (AH / ESP); uses UDP 500 (IKE), UDP 4500 (NAT-T), protocol 50 (ESP) |
| Firewall traversal | Almost never a problem — port 443 is universally allowed | Can be blocked if UDP 500/4500 or ESP protocol is blocked; NAT-T helps in most cases |
| Client software on user device | Required (browser, OS-built-in, or lightweight client) | Not required on user devices — only the two firewalls are involved |
| Authentication flexibility | High — username/password, MFA, SSO, SAML, certificates (not required) | Lower — pre-shared key or PKI certificates required for IKE negotiation |
| User awareness | User must initiate (or always-on auto-connects) | Completely transparent to users — no action needed |
| Scope of access | Typically per-user session; can be scoped to specific resources | Network-to-network — all devices on both networks can communicate |
| Typical endpoint devices | Laptops, smartphones — user endpoint devices | Firewalls, routers — network infrastructure only |
Traditional WAN vs. SD-WAN — The Cloud Problem
| Attribute | Traditional Hub-and-Spoke WAN | SD-WAN |
|---|---|---|
| Architecture | All branch traffic routes through headquarters before reaching cloud or internet | Traffic routed directly to destination (cloud apps go direct to cloud; internal apps go via tunnel) |
| Cloud app path | Branch → WAN → HQ → Internet → Microsoft 365 (2 internet hops, backhauling) | Branch → Local internet → Microsoft 365 (1 hop, direct) |
| Latency for cloud apps | Higher — extra hop through HQ adds latency | Lower — direct path to cloud app |
| HQ bandwidth consumption | High — all branch cloud traffic passes through HQ | Lower — cloud traffic bypasses HQ |
| Security for cloud traffic | Inspected by HQ firewall (good security but poor performance) | Requires SASE or cloud-hosted security — SD-WAN alone provides no security for direct-to-cloud traffic |
| Routing intelligence | Static — same path for all traffic | Dynamic — chooses best path per-flow based on application type and link quality |
SASE Architecture — Three Service Pillars
| Pillar | Services Included | What It Replaces / Enhances |
|---|---|---|
| Network as a Service | SD-WAN, VPNs, QoS, routing, SaaS acceleration | Replaces traditional MPLS/hub-and-spoke WAN; provides cloud-optimized routing |
| Security as a Service | Zero Trust Network Access (ZTNA), Cloud Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Firewall as a Service (FWaaS), DLP, DNS security, threat prevention | Replaces on-premises VPN (with ZTNA), on-premises web proxy (with cloud SWG), and on-premises NGFW (with FWaaS) |
| User Experience | SASE client on all devices, automatic connections, consistent security posture across all locations | Eliminates per-location VPN configuration; uniform experience whether at office, home, or mobile |
Technology Selection Guide
| Requirement | Technology | Why |
|---|---|---|
| Remote employee needs access to corporate apps from hotel Wi-Fi | SSL/TLS VPN (remote access) | Port 443 works everywhere; flexible auth; user-initiated or always-on client |
| Branch office needs persistent encrypted connection to headquarters | Site-to-site IPsec VPN | Always-on tunnel between firewalls; transparent to users; no client software |
| Organization migrating to cloud — employees backhauling cloud traffic through HQ | SD-WAN | Enables direct-to-cloud routing; eliminates HQ backhauling; optimizes cloud app performance |
| Cloud-first org needs consistent security for users anywhere — office, home, mobile | SASE | Cloud-delivered network + security; ZTNA replaces VPN; SWG/FWaaS replace on-prem appliances |
| SD-WAN is deployed but cloud-bound traffic is leaving branches uninspected | SASE (adds Security as a Service to SD-WAN) | SD-WAN routes traffic; SASE inspects it at cloud PoP before delivery to cloud app |
| Organization wants to limit remote users to specific apps, not entire VPN subnet | ZTNA (SASE component) | Per-application access control; user gets access only to authorized apps — not the full network |