Scenario: A logistics company has a headquarters in Chicago (network: 192.168.10.0/24) and a warehouse in Dallas (network: 10.50.1.0/24). A site-to-site IPsec VPN connects the two firewalls. A Chicago employee's workstation (192.168.10.45) sends a file to the Dallas warehouse management system (10.50.1.20).
Step 1 — Chicago workstation sends normally:
The workstation sends an IP packet destined for 10.50.1.20. It has no knowledge of or involvement in the VPN. The workstation just sends a packet to its default gateway (the Chicago firewall).
Step 2 — Chicago firewall intercepts and encrypts:
The Chicago firewall has an IPsec policy: "traffic from 192.168.10.0/24 destined for 10.50.1.0/24 → encrypt and tunnel to Dallas firewall." It captures the packet, applies the policy, and constructs the IPsec tunnel packet:
Original packet (now encrypted):
[IP: 192.168.10.45 → 10.50.1.20] [File transfer data]
↓ encrypt
Tunneled packet sent across internet:
[IP: Chicago_FW_pubIP → Dallas_FW_pubIP] [IPsec header] [ENCRYPTED: original IP+data] [IPsec trailer]
Step 3 — Internet routers forward the outer packet:
Internet routers see only the outer new IP header — src: Chicago firewall's public IP, dst: Dallas firewall's public IP. They have no idea what is inside. They forward it normally. The encrypted original packet is completely invisible to them.
Step 4 — Dallas firewall decrypts and delivers:
The Dallas firewall recognizes the packet as belonging to an established IPsec security association. It strips the outer headers, decrypts the payload, and recovers the original packet: [IP: 192.168.10.45 → 10.50.1.20] with the file data. It forwards this to 10.50.1.20 on the Dallas internal network.
Step 5 — Warehouse management system replies:
The reply follows the reverse path. The Dallas firewall intercepts it, encrypts it, sends it through the tunnel. The Chicago firewall decrypts it and delivers it to 192.168.10.45. The workstation receives the reply — the entire tunnel process took milliseconds and was completely invisible.
What a network attacker sees:
Someone capturing packets on the internet link between Chicago and Dallas sees: encrypted blobs sent from Chicago_firewall_IP to Dallas_firewall_IP. They cannot determine the original source, original destination, protocol, application, or content of any of the traffic. The IPsec encryption renders the entire communication meaningless to an interceptor.
Scenario: A financial analyst travels to a conference. From the hotel room, she needs to access the company's internal financial modeling application and a sensitive database. The hotel network is untrusted — other guests share the same network and potentially a sophisticated attacker could be eavesdropping.
Without VPN (what the attacker could capture):
- All HTTP traffic: full plaintext visibility of everything she does on unencrypted sites
- DNS queries: which internal hostnames she is looking up (reveals what internal systems exist)
- TCP connections: which IP addresses and ports she is connecting to
- Any unencrypted application traffic from internal apps that do not use TLS
With SSL/TLS VPN (always-on configuration):
The VPN client on her laptop automatically connects to the corporate VPN concentrator when the laptop detects any internet connection. From the moment she connects to the hotel Wi-Fi:
- The VPN client establishes a TLS tunnel to the corporate VPN concentrator over TCP 443. The hotel network sees only an HTTPS connection — indistinguishable from normal web browsing.
- All traffic from the laptop is encrypted by the VPN client before it leaves the laptop and enters the hotel network. DNS queries, TCP connections, application data — everything is inside the encrypted tunnel.
- The tunnel terminates at the corporate VPN concentrator. The concentrator decrypts and routes requests to internal systems normally.
- Return traffic follows the reverse path — encrypted by the concentrator, decrypted by the client.
What the hotel network attacker sees: A single persistent TLS/HTTPS connection to a specific IP (the VPN concentrator). Encrypted data passing through it. No visibility into DNS queries, no visibility into which internal systems are being accessed, no visibility into the financial data being transmitted. The hotel attacker gets nothing useful.
Why TCP 443 was the right choice for the VPN protocol: Hotels, coffee shops, and airports frequently restrict unusual ports to prevent peer-to-peer activity and reduce network load. UDP 500 and ESP (used by traditional IPsec) are commonly blocked on these networks. TCP 443 is never blocked because it breaks HTTPS — the hotel's entire business model depends on guests being able to browse the web. SSL/TLS VPN benefits from this "never block port 443" rule universally.
Organization: A national retail chain with 150 stores and a headquarters. The company has migrated to Microsoft 365 (Exchange Online, SharePoint, Teams) and Salesforce. Each store has 15 employees who use these cloud applications constantly. The WAN architecture is traditional hub-and-spoke with MPLS connections from each store to headquarters.
Before SD-WAN — traffic flow for a store employee opening Outlook:
Store (Dallas) → MPLS WAN → Headquarters (Chicago) → Internet → Microsoft 365 (Seattle)
Latency path: Dallas → Chicago (20ms) → Seattle (50ms) = 70ms total
Plus HQ internet bandwidth consumed by all 150 stores' cloud traffic
Dallas store's Microsoft 365 email arrives 70ms after request
Video call via Teams: 70ms baseline latency → choppy video
After SD-WAN — same scenario:
Store (Dallas) → Local broadband internet → Microsoft 365 (Azure Dallas region)
Latency path: Dallas → Dallas (2ms) = 2ms total
HQ internet bandwidth: used only for internal corporate traffic
Dallas store's Microsoft 365 email arrives in 2ms
Video calls: 2ms latency → crystal-clear video
How the SD-WAN makes this routing decision:
The SD-WAN edge device at each store identifies application traffic by type (using DPI or application signatures). Traffic classified as "Microsoft 365" is tagged with a routing policy: "send via local internet breakout." Traffic classified as "internal ERP system" is tagged: "send via IPsec VPN tunnel to headquarters." The employee's device makes no configuration changes — the SD-WAN handles routing silently based on application type.
The security gap created by SD-WAN's local internet breakout: Without headquarters backhauling, Microsoft 365 traffic leaving the Dallas store no longer passes through the headquarters NGFW. The store's local internet connection has no equivalent inspection. The traffic goes directly to Microsoft — uninspected for DLP, user behavior anomalies, or account compromise indicators. This is why SD-WAN alone is insufficient — it creates a security gap that SASE fills by providing cloud-hosted security inspection at the point of internet breakout.
Organization: A 2,000-person professional services firm that went remote-first during the pandemic and never returned to a central office model. Employees work from homes across 30 countries, connect to Microsoft 365, Salesforce, an internal deal management system (hosted in AWS), and an HR system (hosted in Workday). There is no longer a central corporate network to VPN into — the applications are all cloud-hosted.
The traditional VPN problem: The firm deployed site-to-site IPsec VPN tunnels from regional offices to a central data center. But with 60% of employees now working from home and no central data center (it was decommissioned), the IPsec tunnels connect nothing useful. Home users have SSL/TLS VPN clients that tunnel to a concentrator — but the concentrator just routes them to the same cloud services they could access directly. The VPN adds latency without security benefit.
SASE solution architecture:
- SASE client deployed to all 2,000 devices: Deployed via MDM. When any device connects to any network (home, office, hotel, café), the SASE client automatically connects to the nearest SASE point of presence (PoP). The user is unaware — it is completely automatic.
- Traffic routing: All internet and cloud traffic is routed through the SASE PoP. The PoP is geographically distributed — a user in London connects to the London PoP; a user in Singapore connects to Singapore. Traffic is inspected locally, then forwarded to Microsoft 365, AWS, Workday, or Salesforce from the PoP — a short hop to the nearest cloud region.
- Security inspection at the PoP: Every user's traffic passes through cloud SWG (URL filtering, malware inspection), CASB (which cloud apps, which uploads, DLP for sensitive data), ZTNA (verifies identity + device health before granting access to the deal management system in AWS), and FWaaS (NGFW-equivalent inspection of all traffic).
- Consistent policy enforcement: An employee in London, New York, or Singapore all have the same security posture — same URL filtering, same DLP, same application access rules. There is no "on-premises security = safe, off-premises = unprotected" distinction.
Outcome vs. traditional VPN: Traditional VPN routed all traffic through one central concentrator — high latency for distant users, bandwidth bottleneck, single point of failure. SASE routes traffic through the nearest PoP in each region — low latency everywhere, no central bottleneck, security maintained regardless of user location. The firm decommissioned its VPN concentrators and retired the per-country SSL VPN configuration complexity.
Scenario: A healthcare company has a headquarters, three hospital campuses, 400 mobile physicians who work from multiple locations daily, and all clinical applications migrated to Microsoft Azure. Answer the following questions about their secure communication architecture.
Question 1: Physicians move between the hospital campuses and use their personal devices to access patient records in Azure from parking lots, waiting rooms, coffee shops, and patients' homes. They frequently find VPN connections blocked on public Wi-Fi. Which VPN type should be deployed for physician access and why?
Show Answer
SSL/TLS VPN — specifically because it operates over TCP 443. Port 443 is never blocked on public Wi-Fi (it breaks web browsing, which is what public Wi-Fi is for). Traditional IPsec VPN uses UDP 500 and ESP protocol 50, which are routinely blocked on public networks. The physicians' "VPN blocked" problem is almost certainly caused by a port-restricted network blocking IPsec ports — this problem does not exist with SSL/TLS VPN. Additionally, SSL/TLS VPN supports flexible authentication (the organization can require MFA for HIPAA compliance) and can run as always-on, ensuring that physician access to patient records is always encrypted regardless of which network they are on.
Question 2: The three hospital campuses each need persistent, always-on encrypted connectivity back to headquarters for administrative systems, billing, and lab result sharing. No physician or administrative staff should have to log in to a VPN to access these systems — connectivity should be automatic and transparent. Which technology is appropriate?
Show Answer
Site-to-site IPsec VPN between the firewall at each hospital campus and the headquarters firewall. This creates a permanent, always-on, transparent encrypted tunnel between each campus network and headquarters. Staff at the campuses simply use the network normally — their traffic to headquarters systems is automatically encrypted by the local firewall and decrypted at the headquarters firewall. No client software is installed on any user device. No login prompt. No user action required. The firewalls maintain the tunnels continuously; if a tunnel drops (internet disruption), it automatically re-establishes when connectivity returns.
Question 3: Clinical applications have moved to Azure. Physicians at the hospital campuses are complaining that cloud applications are slow. Investigation reveals that all Azure traffic from each campus is being routed through headquarters' VPN concentrator before going to Azure — adding two extra internet hops. Which technology eliminates this inefficiency, and what security risk does it introduce?
Show Answer
SD-WAN eliminates the backhauling inefficiency. Deploying SD-WAN edge devices at each campus allows the SD-WAN to identify Azure-bound traffic and route it directly from the campus to Azure via the local internet connection — eliminating the HQ hop. Microsoft 365 and Azure applications will have dramatically lower latency (campus-to-nearest-Azure-region instead of campus-to-HQ-to-Azure).
The security risk introduced: Azure-bound clinical application traffic no longer passes through the headquarters NGFW for inspection. The campus is now sending patient health information (PHI) — HIPAA-protected data — to Azure via a local internet connection with no equivalent security inspection. This is a HIPAA compliance risk. Whoever accesses the Azure application, whatever data is downloaded, what happens if a workstation is compromised and starts exfiltrating — none of this is inspected. The solution: pair SD-WAN with SASE, where the cloud-hosted security stack (FWaaS, CASB, DLP) inspects all Azure-bound traffic at the nearest PoP. The performance benefit of SD-WAN is preserved while security inspection is maintained via SASE.
Question 4: The CISO wants a single platform that handles both the network connectivity optimization (Question 3) and the security inspection gap it creates, while also providing consistent security for the 400 mobile physicians regardless of their location. Which technology addresses all three requirements simultaneously?
Show Answer
SASE (Secure Access Service Edge). SASE combines SD-WAN networking (optimized routing to Azure) with cloud-delivered security (inspection of Azure-bound traffic at the PoP) in a single platform. A SASE client on every physician device and SD-WAN integration at each campus routes all traffic through the nearest SASE PoP, which performs FWaaS, CASB (enforcing DLP on PHI uploads to Azure), ZTNA (per-application access verification), and URL filtering — then forwards clean, policy-compliant traffic to Azure. Whether a physician is at the campus, at a patient's home, or at a coffee shop, all traffic goes through the same SASE security stack. The CISO gets consistent security posture and network optimization in one platform, replacing the combination of site-to-site VPN (for campus-to-HQ) and SSL/TLS VPN (for remote physicians) with a unified SASE deployment that handles both.