This is the most reliable selection trigger on VPN questions. The exam frequently places a user at a hotel, coffee shop, airport, or behind a restrictive firewall and asks which VPN type will still work. The answer is almost always SSL/TLS VPN — and the reason is exactly one fact: it uses TCP 443.
Why TCP 443 matters: Port 443 is the HTTPS port. Every organization, every hotel Wi-Fi, every airport network allows outbound TCP 443 — because blocking it breaks all web browsing. Any VPN that uses TCP 443 inherits this universal permission. The local firewall operator cannot selectively block "VPN traffic on 443" without also blocking all HTTPS web traffic — which is not acceptable.
Why IPsec VPN fails in the same scenario: IPsec uses UDP 500 (IKE key exchange) and UDP 4500 (NAT traversal), plus IP protocol 50 (ESP encapsulation). These are non-standard protocols that many restrictive firewalls block. If a hotel or airport firewall blocks UDP 500/4500, the IPsec tunnel cannot establish — the key exchange never completes.
The exam question patterns:
- "A user at a hotel cannot establish their VPN connection — the hotel blocks all UDP traffic. Which VPN type should be deployed instead?" → SSL/TLS VPN (TCP 443)
- "An organization needs a VPN that works from any location without firewall traversal issues" → SSL/TLS VPN
- "Which VPN type uses the same port as HTTPS?" → SSL/TLS VPN
- "A site-to-site VPN is already deployed. Remote users also need access from anywhere. Which additional VPN type is needed?" → SSL/TLS VPN (for individual user access)
Secondary SSL/TLS VPN facts to remember:
- Authentication: does NOT require digital certificates — username/password, MFA, SSO, and SAML are all valid. IPsec typically requires pre-shared keys or certificates for IKE negotiation.
- Client: lightweight software or browser-based — not a heavy dedicated client. Operating systems often include built-in SSL VPN support.
- Always-on option: SSL/TLS VPN can be configured to auto-connect (always-on) — this is a configuration option, not a defining characteristic. Site-to-site IPsec is always-on by definition.
This is the highest-frequency misconception on SD-WAN/SASE questions. SD-WAN and SASE are related but fundamentally different — SD-WAN is about how traffic gets routed; SASE is about how traffic is secured while being routed efficiently. Confusing them leads to wrong answers on scenario questions.
What SD-WAN provides:
- Intelligent traffic routing — cloud app traffic goes directly to the cloud; internal app traffic still routes through the corporate WAN
- Eliminates WAN backhauling — branch cloud traffic does not need to loop through headquarters
- Central software-defined policy control — routing rules pushed to all edge devices from one controller
- Better performance for cloud-first organizations — fewer internet hops for SaaS applications
What SD-WAN does NOT provide:
- Security inspection for cloud-bound traffic — branch traffic leaving directly for Microsoft 365 bypasses the corporate security stack entirely
- Threat prevention, URL filtering, CASB, DLP — none of these are SD-WAN capabilities
- Identity-based access control — SD-WAN routes based on application type and destination, not user identity
The security gap SD-WAN creates:
Traditional WAN: Branch → HQ firewall (inspected) → Internet → Microsoft 365
SD-WAN: Branch → Internet → Microsoft 365 (NO inspection at HQ)
SASE: Branch → SASE cloud PoP (inspected: ZTNA, SWG, CASB, FWaaS) → Microsoft 365
The exam question pattern: "An organization deployed SD-WAN to improve cloud application performance. A security auditor notes that branch internet traffic is now bypassing headquarters security controls. Which technology addresses this?" → SASE. Not "add more SD-WAN rules" — SD-WAN cannot inspect traffic, only route it. Not "add a site-to-site VPN back to headquarters" — that reintroduces backhauling. SASE is specifically designed to add cloud-hosted security to SD-WAN's direct-to-cloud routing.
Remember the relationship: SASE includes SD-WAN as its networking component and adds Security as a Service on top. SD-WAN is a subset of SASE. Deploying "just SD-WAN" means you have the network optimization without the security — SASE completes the picture.
These two VPN deployment models are consistently tested together. Students frequently confuse them because both "connect to a corporate network." The difference is who or what initiates the tunnel, and what the scope of access is.
Site-to-site IPsec VPN — the key identifiers:
- Who initiates: The firewalls at each site — automatically, when both are online. No user action. No user awareness.
- Client software: None on user devices. Only the perimeter firewalls are involved.
- Scope: Network-to-network — entire subnets at both sites can communicate. A user at headquarters sends to the branch subnet address; the firewall intercepts and tunnels it. The user just sees it as local connectivity.
- Always-on: By definition. The tunnel is persistent — established when firewalls are online, maintained continuously. Not configurable — it is just how site-to-site VPNs work.
- Primary use case: Branch office to headquarters. Two fixed locations that need permanent connectivity.
Remote access SSL/TLS VPN — the key identifiers:
- Who initiates: The user's device (VPN client software) to the corporate VPN concentrator.
- Client software: Required on the user's device — browser plugin, OS built-in, or lightweight dedicated client.
- Scope: Individual user access — one device gets VPN access. The user can reach the corporate network; other people on the same home network cannot.
- Always-on option: Configurable — can be on-demand (user clicks "connect") or always-on (auto-connects when device detects internet, all traffic through tunnel).
- Primary use case: Traveling employee, remote worker, or contractor accessing corporate resources from any location.
The exam question patterns:
- "Employees at headquarters complain they cannot reach the file server at the branch office" → Site-to-site IPsec VPN between the two firewall concentrators
- "A remote employee needs to access internal systems from home" → SSL/TLS remote access VPN with client software on their laptop
- "Which VPN requires no client software on user devices?" → Site-to-site IPsec VPN (concentrators are only at the firewalls)
- "A managed corporate laptop should always be protected regardless of network location" → Always-on SSL/TLS VPN configured on the laptop client
SASE questions fail when students think of it as "VPN in the cloud" or confuse it with a single component. SASE is an entire platform — it replaces multiple on-premises appliances (VPN concentrator, proxy, web filter, NGFW) with cloud-delivered equivalents, unified under one service with one client.
The SASE component breakdown to memorize:
- ZTNA (Zero Trust Network Access): Replaces traditional VPN. Grants identity-verified, per-application access — not full network subnet access. The user proves identity per session; access is scoped to specifically authorized applications only.
- Cloud SWG (Secure Web Gateway): Replaces on-premises forward web proxy. Applies URL filtering, malware scanning, and content inspection to web-bound traffic — from the cloud instead of from a corporate appliance.
- CASB (Cloud Access Security Broker): Enforces security policy for cloud application usage. Provides visibility into which cloud apps employees are using (including shadow IT), applies DLP controls to cloud uploads, and controls access to specific cloud services.
- FWaaS (Firewall as a Service): Replaces on-premises NGFW. Delivers next-generation firewall capabilities from a cloud-hosted PoP — traffic is inspected by the cloud NGFW before reaching its destination.
- DLP, DNS security, threat prevention: Additional integrated security services in the SASE platform.
ZTNA vs. traditional VPN — the exam distinction:
Traditional VPN: authenticate once → access entire 10.0.0.0/8 subnet → lateral movement risk
ZTNA: authenticate per session → access only app1.corp and app2.corp
→ compromised credential cannot reach file servers, databases, etc.
The "zero trust" principle in ZTNA: No implicit trust based on network location. Traditional security assumed: if you are inside the corporate network, you are trusted. Zero trust says: even if you are on the corporate network, verify identity and authorize explicitly for each access. ZTNA applies this to remote access — being "connected via VPN" does not grant trust; each application access is individually verified.
The exam question patterns:
- "A cloud-first organization wants to provide consistent security for office, home, and mobile users without on-premises VPN concentrators" → SASE
- "An organization wants to limit remote users to only the specific applications they are authorized for, rather than granting full VPN subnet access" → ZTNA (the SASE component that replaces VPN)
- "Which SASE component enforces security policy on cloud application usage and provides visibility into shadow IT?" → CASB
- "SD-WAN is deployed but the security team needs threat prevention, URL filtering, and DLP applied to direct-to-cloud traffic" → SASE (adds Security as a Service to SD-WAN's networking)
Scenario A: A 500-person financial services firm has three office locations (headquarters, a domestic branch, and an overseas branch), 150 remote employees working from home, and a cloud-hosted trading platform on AWS. The CISO is designing the secure connectivity architecture. Currently: (1) the two branch offices connect to headquarters via MPLS; (2) remote employees use SSL/TLS VPN; (3) all traffic — including Microsoft 365 and Salesforce — routes through headquarters before reaching the internet. Users complain that Teams calls drop and Salesforce is slow. Design a connectivity architecture that improves cloud performance while maintaining strong security. Name the technologies involved and explain the role of each.
Show Answer
The problem: Hub-and-spoke routing through headquarters means cloud traffic (Teams, Salesforce) takes two internet hops — branch → HQ → internet → cloud. This doubles latency for cloud-bound traffic and saturates headquarters internet bandwidth. The performance complaints are a direct symptom of this architecture.
Recommended architecture:
1. Replace MPLS with SD-WAN at all three offices: SD-WAN edge devices replace the static MPLS routing. Cloud app traffic (Teams, Salesforce, Microsoft 365) is identified and routed directly from each office to the cloud via local internet — eliminating the HQ backhauling hop. Internal application traffic (trading platform on AWS, internal file servers) still routes through secure tunnels between offices. The central SD-WAN controller defines these routing policies and pushes them to all three sites.
2. Deploy SASE to secure direct-to-cloud traffic: SD-WAN's direct-to-cloud routing bypasses the headquarters NGFW — so branch and remote employee cloud traffic would leave uninspected. SASE adds cloud-hosted security PoPs geographically close to each office. When a branch user accesses Salesforce, traffic flows: branch → nearest SASE PoP (inspected: URL filtering, DLP, threat prevention, CASB for Salesforce policy enforcement) → Salesforce. Security policies are applied at the PoP, not at headquarters. The CASB component specifically enforces which cloud applications are permitted and applies DLP controls on uploads to cloud services.
3. Replace SSL/TLS VPN for remote employees with ZTNA (via SASE): The 150 remote employees currently connect via SSL/TLS VPN, which grants full corporate subnet access once authenticated. Replace with ZTNA (the SASE remote access component): employees connect to the nearest SASE PoP and are granted access only to the specific applications they are authorized for (trading platform, internal systems), not the entire corporate network. ZTNA also applies the same security inspection (SWG, CASB, threat prevention) to remote employee traffic as to office traffic — consistent posture.
Result: Headquarters is no longer a traffic bottleneck for cloud applications. Cloud traffic is inspected at geographically distributed SASE PoPs rather than centrally. Remote employees have per-application access control that limits lateral movement risk. MPLS cost can be reduced or eliminated for cloud-bound traffic.
Scenario B: A packet capture between two sites shows the following packet structure: [outer IP: src=203.0.113.5, dst=198.51.100.10] [IPsec header: SPI=0x12345678] [encrypted payload] [IPsec trailer]. The security team asks you three questions: (1) What does the outer IP header tell you? (2) What is inside the encrypted payload? (3) At which point in the network does the encrypted payload become readable, and what happens to the packet at that point?
Show Answer
Question 1 — What does the outer IP header tell you?
The outer IP header (src=203.0.113.5, dst=198.51.100.10) tells you the public IP addresses of the two VPN concentrators (the perimeter firewalls). 203.0.113.5 is the sending concentrator's public IP; 198.51.100.10 is the receiving concentrator's public IP. This is all internet routers need to know — they forward the packet from hop to hop using these addresses. The outer header deliberately hides all internal addressing: you cannot determine the source or destination of the original communication from these addresses alone.
Question 2 — What is inside the encrypted payload?
The encrypted payload contains the entire original IP packet: the original IP header (with the actual internal source IP and internal destination IP of the communicating devices) plus the original data payload (application data — could be HTTP, database queries, file transfers, anything). Both are fully encrypted. An observer who captures the packet can see the concentrator-to-concentrator addressing and the IPsec header's security association identifier (SPI), but cannot determine who is talking to whom internally, what application they are using, or what data they are exchanging.
Question 3 — Where does decryption happen and what occurs?
Decryption occurs at the VPN concentrator at 198.51.100.10 — the destination perimeter firewall. When the packet arrives, the concentrator: (1) strips the outer IP header (it served its purpose — routing to this concentrator); (2) reads the IPsec header SPI to identify the security association (which encryption keys and algorithms to use for this tunnel); (3) decrypts the encrypted payload using the negotiated session keys; (4) recovers the original IP packet in plaintext — now showing the real internal source and destination IPs and the original application data; (5) forwards the original packet onto the internal network toward its actual destination. From this point, the packet travels unencrypted on the internal network to the destination device.
Scenario C: A CISO is evaluating four secure connectivity technologies for different use cases in their organization. Match each use case to the technology and explain the selection: (1) The legal department (25 attorneys at one office) needs to connect to the firm's document management server at headquarters with no user interaction. (2) Individual attorneys need to access case files securely from courthouses and client sites — many of these locations have restrictive Wi-Fi. (3) The firm is migrating from on-premises Exchange to Microsoft 365 and all email traffic currently routes through headquarters. (4) The IT security team wants to ensure that remote employees can only access the case management system and document portal — not browse the entire internal network.
Show Answer
Use case 1 — Site-to-site IPsec VPN:
The legal department office needs persistent, always-on, transparent connectivity to headquarters. Users should be able to access the document management server without any VPN client interaction — they just use it as if it were local. Site-to-site IPsec VPN between the perimeter firewall at the legal office and the headquarters firewall creates a permanent encrypted tunnel. The attorneys never think about VPN — their firewall handles all encryption and routing automatically. Client software on user devices is not required or deployed.
Use case 2 — SSL/TLS VPN:
Individual attorneys connecting from courthouses and client sites need remote access VPN that works from any network — including restrictive courthouse Wi-Fi that blocks non-standard protocols. SSL/TLS VPN uses TCP 443 (universally allowed as HTTPS) and establishes the tunnel from VPN client software on their laptop to the corporate concentrator. It works everywhere HTTPS works. IPsec VPN would fail in restrictive environments that block UDP 500/4500.
Use case 3 — SD-WAN (or SASE for the security component):
Email traffic to Microsoft 365 currently backhauled through headquarters is a classic SD-WAN optimization use case. SD-WAN routes Microsoft 365-bound traffic directly from the office to Microsoft's cloud via local internet, eliminating the headquarters roundtrip. If the security team also needs to ensure that Microsoft 365 traffic is inspected and DLP policies enforced on email uploads, add SASE — which routes traffic through a cloud security PoP with CASB and DLP before delivery to Microsoft 365. Pure SD-WAN alone addresses the routing inefficiency; SASE addresses routing + security.
Use case 4 — ZTNA (Zero Trust Network Access):
The requirement to limit remote employees to specific authorized applications (case management system and document portal only, not the full internal network) is the exact definition of ZTNA. Traditional SSL/TLS VPN would give them access to the entire corporate subnet — they could potentially reach other servers, internal databases, printers, and network devices. ZTNA grants access only to the explicitly authorized applications per session, with identity verification required. A compromised attorney credential grants access to only the two authorized applications — not the full network.