What a VPN Is
A Virtual Private Network (VPN) encrypts private data and sends it across a public network — typically the internet — so that an observer who captures the traffic in transit sees only encrypted, unintelligible data. The "private" in VPN refers to the privacy of the data; the "virtual" refers to the fact that the private network does not exist as dedicated physical infrastructure — it is a logical construct, created by encryption, over shared public infrastructure.
VPNs are used in two primary scenarios: a remote user connecting to a corporate network from a public location, and two geographically separated office locations connecting their networks together. In both cases, the goal is the same — ensure that data crossing the public internet is encrypted so that its interception reveals nothing useful to an attacker.
VPN Concentrators
A VPN concentrator is the device that serves as the endpoint of an encrypted VPN tunnel. It is responsible for two operations: encrypting outbound traffic before it enters the public network, and decrypting inbound traffic that arrives from the tunnel before forwarding it to the internal network.
VPN concentrators come in several forms:
- Dedicated hardware appliance: A purpose-built device using specialized cryptographic hardware for high-performance encryption and decryption. These devices are designed to handle thousands of simultaneous VPN sessions efficiently.
- Integrated into a firewall (most common today): Modern firewalls — particularly NGFWs — include built-in VPN concentrator functionality. Because the firewall already sits at the network edge, it is the natural VPN endpoint. Most organizations use their existing perimeter firewall as the VPN concentrator rather than deploying a separate appliance.
- Software-based: VPN concentrator software running on a general-purpose server. Less efficient than dedicated hardware but lower cost and easier to deploy in cloud environments. Common for cloud-hosted VPN endpoints.
- Client software: On the remote user's side, VPN client software (sometimes built into the operating system) establishes the tunnel to the concentrator and handles the encryption/decryption on the user's device.
How an IPsec Tunnel Works — Packet Anatomy
Understanding what happens inside an encrypted tunnel at the packet level is critical for the exam. An unencrypted IP packet has two components: an IP header (containing source and destination IP addresses, protocol, etc.) and data payload. This packet is perfectly legible to anyone who intercepts it.
To send this packet securely through the internet inside a VPN tunnel, the following transformation occurs:
Original packet: [Original IP header] [Data]
Step 1 — Encrypt: [Original IP header] [Data] → Encrypted payload
Step 2 — Wrap: [New IP header] [IPsec header] [Encrypted payload] [IPsec trailer]
↑ ↑
Points to VPN concentrator IP Marks end of encrypted payload
The new outer IP header contains the source address of the sending device and the destination address of the VPN concentrator — not the original internal destination. Routers across the internet forward this packet to the concentrator's IP. The IPsec header and trailer mark the boundaries of the encrypted content and carry authentication information. The original IP header and data are entirely encrypted and invisible to everything between the sender and the concentrator.
When the packet arrives at the VPN concentrator:
- The concentrator strips the outer new IP header (it served its purpose: routing to the concentrator)
- The concentrator reads the IPsec header to identify the security association (which encryption keys to use)
- The concentrator decrypts the payload using the agreed-upon encryption algorithm and keys
- The original IP header and data are recovered in plaintext
- The concentrator forwards the original packet to its destination on the internal network
This entire process happens invisibly — the application sending the data has no knowledge that its packets are being encrypted and re-wrapped. From the application's perspective, it is communicating normally. The VPN tunnel is transparent to the software using it.
SSL/TLS VPN — Remote Access for Individual Users
An SSL/TLS VPN uses the same protocol (TLS) and the same TCP port (443) as HTTPS web traffic. This choice is deliberate and strategic: because port 443 is universally allowed through firewalls (almost every organization allows outbound HTTPS), an SSL/TLS VPN essentially never has firewall traversal problems. A user connecting from a hotel, coffee shop, airport, or home network can establish a VPN session without worrying about whether the local firewall blocks the VPN protocol.
Key characteristics of SSL/TLS VPNs:
- Flexible authentication: SSL/TLS VPNs support a wide range of authentication methods — username/password, MFA, SAML-based SSO. They do not require digital certificates or pre-shared keys (unlike IPsec, which often does). This makes user onboarding simpler.
- Minimal client requirements: Some SSL VPN implementations run entirely within a standard web browser, requiring no software installation. Others use lightweight VPN client software. Many operating systems include built-in SSL VPN client capability.
- On-demand or always-on: An SSL VPN can be configured for on-demand access (the user manually initiates the VPN session when needed) or always-on (the VPN client automatically connects whenever the device has internet access, ensuring all traffic is always encrypted). Always-on is often used for managed corporate devices where consistent security posture is required.
- Primary use case: Remote access from a single device — a traveling employee, a remote worker, or a contractor accessing specific corporate resources from their laptop or smartphone.
SSL/TLS VPN flow:
Remote user (laptop) → [internet — encrypted TLS tunnel on TCP 443] → VPN concentrator
VPN concentrator decrypts → routes into corporate network
Return traffic: corporate network → VPN concentrator encrypts → [internet] → remote user
Site-to-Site IPsec VPN — Always-On Network-to-Network Tunnels
A site-to-site VPN connects two complete networks — typically a branch office and a headquarters — with a permanent encrypted tunnel. Users at either end are completely unaware of the VPN. They simply send traffic to the other network's resources normally; the VPN is transparent to them. No client software is installed on user devices. The encryption happens automatically at the network boundary.
In a site-to-site VPN, the VPN concentrators at each end are typically the existing perimeter firewalls. Organizations that already have firewalls in place can enable site-to-site IPsec VPN functionality on those same devices — the firewall at each site acts as the tunnel endpoint. Traffic from the corporate office that is destined for the branch office subnet is automatically captured by the local firewall, encrypted, encapsulated in an IPsec tunnel, and sent through the internet to the branch firewall, where it is decrypted and forwarded to the destination device.
Key characteristics of site-to-site IPsec VPNs:
- Always-on: The tunnel is established when both firewalls are online and maintained continuously. Users experience seamless connectivity to remote sites without any VPN login steps.
- No user-side client software: Users connect to the remote network exactly as they would to any local resource. The VPN is completely transparent — only the firewalls are involved in encryption/decryption.
- Network-to-network scope: Entire subnets communicate through the tunnel — all devices on both networks can reach each other, not just specific users or applications.
- Primary use case: Connecting branch offices, remote data centers, or partner organizations to a central corporate network with persistent, automatic encrypted connectivity.
Site-to-site IPsec VPN flow:
Corporate network [192.168.1.0/24] → [Firewall/VPN concentrator]
↓ IPsec tunnel (encrypted) ↓
Branch office [10.10.1.0/24] ← [Firewall/VPN concentrator]
A user at 192.168.1.50 sends to 10.10.1.30 — they just send normally
Their firewall intercepts, encrypts, tunnels — completely transparently
The Problem Traditional VPNs Have with Cloud
Traditional VPN architectures assumed a centralized model: all corporate applications live in a central data center, and all remote users and sites connect back to that data center through VPN tunnels. This model was efficient when the data center contained everything.
Cloud migration broke this assumption. Organizations have moved their applications — email (Microsoft 365, Google Workspace), CRM (Salesforce), ERP (SAP), collaboration (Teams, Slack) — out of their own data centers and into cloud providers. Now a remote user at a branch office who wants to access Microsoft 365 must: connect via VPN to headquarters, hairpin through the headquarters data center, and then exit to Microsoft's cloud. Two internet crossings instead of one. Higher latency, unnecessary bandwidth consumption at headquarters, and a performance bottleneck — all to access an application that is directly available on the internet.
SD-WAN — Software Defined Networking in a Wide Area Network
SD-WAN is a WAN architecture specifically designed for the cloud era. It decouples WAN management from individual hardware devices using software-defined control — a central controller defines routing policies that are pushed to SD-WAN edge devices at every location.
The key SD-WAN capability: intelligent traffic routing. Instead of sending all traffic through a central hub (traditional hub-and-spoke WAN), SD-WAN can route traffic directly to its destination:
- Traffic destined for Microsoft 365 → sent directly from the branch to Microsoft's cloud over the local internet connection
- Traffic destined for sensitive internal applications → still sent via VPN to headquarters
- Traffic destined for another branch → sent via the most efficient path (direct branch-to-branch, or via hub if that is faster)
SD-WAN makes the WAN intelligent enough to know where each application lives and choose the optimal path to it. This eliminates the performance penalty of backhauling cloud traffic through headquarters. However, SD-WAN is fundamentally a networking technology — it optimizes traffic paths and connectivity. It does not, by itself, provide comprehensive security for those traffic flows. This is where SASE enters.
SASE — Secure Access Service Edge
SASE (pronounced "sassy") is the next evolution — it takes the networking flexibility of SD-WAN and adds a comprehensive cloud-delivered security stack. Rather than routing traffic directly to cloud services through an uncontrolled local internet breakout, SASE routes all traffic through a cloud-hosted security platform that is geographically distributed close to the cloud services being accessed.
SASE combines two service categories delivered from the cloud:
Network as a Service (the SD-WAN component):
- SD-WAN for dynamic, intelligent routing
- VPN services for encrypted connectivity
- QoS (Quality of Service) for application prioritization
- Routing and SaaS acceleration
Security as a Service (the cloud security stack):
- Zero Trust Network Access (ZTNA): Replaces traditional VPN with identity-verified, application-specific access. Users are verified per-session; they get access only to the specific applications they are authorized for — not the full internal network.
- Cloud Secure Web Gateway (SWG): Web proxy and URL filtering in the cloud — applies the same content inspection to cloud-routed traffic that a corporate forward proxy would apply on-premises.
- Cloud Access Security Broker (CASB): Enforces security policies for cloud application usage — which cloud apps are allowed, data classification for cloud uploads, DLP for cloud services.
- Firewall as a Service (FWaaS): Next-generation firewall capabilities delivered from the cloud — the user's traffic is inspected by the cloud-hosted NGFW before reaching the internet or cloud applications.
- DLP (Data Loss Prevention), DNS security, threat prevention.
User Experience: A SASE client installed on every device connects automatically to the nearest SASE point of presence (PoP). The connection is seamless, consistent, and automatic — the user simply accesses their applications as if everything is local, while SASE enforces security policies and provides network optimization in the background. Corporate office, home user, mobile user: the same security posture and access experience for all.
Selecting the Right Technology
Organizations often deploy multiple of these technologies together, each for a different purpose:
- SSL/TLS VPN: Remote access for individual users — employees working from home, traveling, or using personal devices. On-demand or always-on client software.
- Site-to-site IPsec VPN: Persistent network-to-network connectivity between branch offices and headquarters — always-on, transparent, no user involvement required.
- SD-WAN: Optimizes WAN connectivity for organizations with significant cloud application usage — routes cloud-bound traffic directly without backhauling. Primarily a network optimization tool, not a security solution.
- SASE: The complete solution for cloud-native organizations — combines SD-WAN networking with cloud-delivered security. Best for organizations that have moved the majority of their workloads to cloud services and need consistent security policy enforcement regardless of user location.