7.3 Virtual WAN and VPN Security
Key Takeaways
- Azure Virtual WAN provides Microsoft-managed hub-and-spoke global transit with integrated site-to-site VPN, point-to-site User VPN, ExpressRoute, and VNet connections.
- A secured Virtual WAN hub adds Azure Firewall (via Firewall Manager policies) for centralized inspection of branch, user, and VNet traffic.
- Classic VPN Gateway attaches to a VNet; Virtual WAN VPN lives in the managed hub—choose based on scale, multi-region transit, and operational model.
- Site-to-site uses IPsec/IKE; point-to-site supports OpenVPN, IKEv2, and (Windows) SSTP with certificate, Microsoft Entra ID, or RADIUS authentication.
- Microsoft Entra authentication for P2S (OpenVPN + Azure VPN Client) enables Conditional Access and MFA; forced tunneling and custom routes control internet egress for remote clients.
Why Virtual WAN and VPN Security Matter on SC-500
The skills outline includes configure security for an Azure Virtual WAN and implement and configure security for virtual private network (VPN) connections. Hybrid paths are high-value targets: if a branch VPN or remote user tunnel is weak, attackers land inside your address space past many cloud-edge controls.
This section connects three ideas:
- Transit architecture — how traffic enters Azure (VPN, ExpressRoute, User VPN).
- Encryption and authentication — IPsec/IKE, TLS-based VPN, certificates, Microsoft Entra ID, RADIUS.
- Hub security — secured Virtual WAN hubs, firewall policies, and routing controls such as forced tunneling.
Azure Virtual WAN Architecture (Security Lens)
Azure Virtual WAN is a Microsoft-managed hub-and-spoke service that combines connectivity and (optionally) security:
| Resource | Role |
|---|---|
| Virtual WAN | Overlay container for hubs |
| Virtual hub | Microsoft-managed hub VNet in a region with gateways/router |
| Hub VNet connection | Attaches your spoke VNet to the hub (a VNet connects to one hub) |
| VPN site | Represents on-premises VPN/SD-WAN device for S2S |
| Hub route tables | Association/propagation control traffic paths |
Standard vs Basic:
| Type | Capabilities (security-relevant) |
|---|---|
| Basic | Site-to-site VPN only; limited |
| Standard | S2S, User VPN (P2S), ExpressRoute, any-to-any transit through hub router, Azure Firewall, NVA scenarios |
You can upgrade Basic → Standard but not downgrade. Full mesh of Standard hubs enables global transit over the Microsoft backbone (branch-to-branch, branch-to-VNet, VNet-to-VNet with proper routing flags).
Security implication: Traffic between spokes can transit the hub. Without a secured hub or careful route tables, you may have connectivity without inspection. Design routing intentionally so sensitive flows hit Azure Firewall or an NVA.
Secured virtual hub
A secured hub is a Virtual WAN hub with Azure Firewall managed through Azure Firewall Manager. Benefits:
- Centralize SNAT/DNAT, network rules, application (L7 FQDN) rules, and threat intelligence.
- Apply firewall policies consistently across hubs.
- Inspect traffic between branches, VNets, and Internet egress from the hub.
- Upgrade path from Firewall Standard to Premium (TLS inspection, IDPS) when the threat model requires it—plan maintenance windows.
Exam contrast: NSGs filter at subnet/NIC; Azure Firewall in the hub is the centralized policy enforcement point for hybrid transit. AVNM security admin rules govern VNet packet filters at scale but do not replace firewall URL/threat intel features.
VPN Gateway vs Virtual WAN VPN
| Topic | VPN Gateway (classic VNet gateway) | Virtual WAN VPN |
|---|---|---|
| Placement | GatewaySubnet in your VNet | Inside Microsoft-managed hub |
| Topology | Often hub VNet you build + peerings | Managed global hubs + VNet connections |
| Scale ops | You size gateway SKUs, AZs, connections | Scale units / hub infrastructure; partner automation |
| P2S / S2S | Fully supported on route-based gateways | S2S and User VPN on Standard WAN |
| Best fit | Simpler single-region or few VNets | Many branches, multi-region transit, SD-WAN partners |
Both use IPsec/IKE for site-to-site. Security principles (strong algorithms, certificate or Entra auth for users, least-privilege routes) apply to both. SC-500 cares more about secure configuration choices than product marketing.
Site-to-Site (S2S) Security
S2S connects on-premises networks to Azure over IPsec/IKE (IKEv2 commonly).
Hardening checklist:
- Route-based VPN for modern features (P2S, custom policies, active-active patterns where applicable).
- Prefer custom IPsec/IKE policies that meet organizational crypto standards (strong encryption/integrity, modern DH groups) instead of legacy weak defaults when policy requires.
- Use BGP when you need dynamic routing and resilient multi-link designs; static routes for simple labs.
- Restrict on-premises firewalls to the Azure gateway public IPs and required UDP 500/4500 (and ESP) as designed.
- Combine with ExpressRoute when private connectivity is required; Virtual WAN can interconnect VPN and ExpressRoute with branch-to-branch flags and hub routing—understand that this expands the trusted boundary.
- For Virtual WAN, partner CPE automation reduces misconfiguration risk versus manual device templates—but still validate proposals and prefixes.
Encryption note: ExpressRoute is private connectivity but not encrypted by default. Virtual WAN supports IPsec over ExpressRoute patterns when encryption-in-transit over the private peering is required—do not claim “ExpressRoute equals encrypted.”
Point-to-Site (P2S) / User VPN Security
P2S (Virtual WAN User VPN or VPN Gateway P2S) connects individual clients into Azure. Useful for remote admins and small user sets without full S2S.
Protocols
| Protocol | Notes |
|---|---|
| OpenVPN | TLS-based; works across many OSes; required path for Microsoft Entra ID auth |
| IKEv2 | IPsec; strong standards-based option (for example macOS native) |
| SSTP | TLS-based; Windows-oriented; not the Entra OpenVPN path |
Authentication methods
| Method | Security value | Constraints |
|---|---|---|
| Certificates | Client certs issued from uploaded root; gateway validates cert | Lifecycle: issue, revoke, protect private keys; not tied to Entra CA policies alone |
| Microsoft Entra ID | Users authenticate with Entra; enable MFA and Conditional Access | OpenVPN + Azure VPN Client; aligns remote access with Zero Trust identity |
| RADIUS / Active Directory | Reuse enterprise NPS/RADIUS, MFA integrations | Gateway must reach RADIUS (often via S2S); operational complexity |
SC-500 preference signal: When the scenario emphasizes Conditional Access, MFA, or centralized identity governance for remote users, choose Microsoft Entra authentication for P2S—not long-lived shared certificates alone. Certificates remain valid when Entra is unavailable or for device-centric designs, but identity-centric questions push Entra.
You may combine authentication types on a gateway with protocol compatibility rules (Entra pairs with OpenVPN). Clients need profiles regenerated when topology or auth settings change.
Authorization beyond authentication
Authentication proves who connects; still control:
- Client address pool design (non-overlapping).
- NSGs / admin rules / firewall on destinations the pool can reach.
- Route advertisement so clients only receive required prefixes.
- Optional user/group access patterns for Entra-based P2S (limit who can use the VPN app / audience configuration).
Forced Tunneling and Internet Egress Control
Forced tunneling sends client or subnet Internet-bound traffic to a security inspection point (on-premises firewall or Azure Firewall) instead of breakout from the client’s local ISP or from Azure without inspection.
| Context | Concept |
|---|---|
| On-premises / S2S | Advertise default route (0.0.0.0/0) into Azure carefully so VNet egress hairpins to on-prem for inspection—or reverse, send branch Internet via Azure secured hub |
| P2S clients | Advertise custom/default routes so remote user traffic to Internet or to on-prem goes through the tunnel for DNS filtering, DLP, or firewall policy |
| Secured vWAN hub | Route Internet-bound traffic from VNets/branches to Azure Firewall before egress |
Exam trap: Forced tunneling is a routing security control, not an encryption algorithm. It reduces shadow IT and uncontrolled egress but can break clients that need local Internet split tunneling—design explicitly (full tunnel vs split tunnel).
Securing Hybrid Connectivity: Layered Model
Apply defense-in-depth:
- Identity: Entra MFA/CA for User VPN; certificate hygiene for device certs; PIM for admins who change gateways.
- Encryption: IPsec/IKE or TLS VPN; encrypt ExpressRoute when policy demands.
- Network access: NSGs/ASGs on workloads; AVNM admin baselines; Azure Firewall in secured hubs for transit inspection.
- Private data path: Prefer private endpoints for PaaS so hybrid users hit private IPs, not public PaaS endpoints.
- Monitoring: Gateway diagnostic logs, Firewall logs, connection monitors, Sentinel analytics on VPN anomalies.
- Least exposure: No broad 0.0.0.0/0 NSG allows “because VPN users need access”—scope to client pool CIDR and required ports.
Scenario: A global retailer connects 200 stores via SD-WAN partners into Virtual WAN Standard hubs, enables secured hubs with Firewall Premium policies denying risky categories, uses User VPN with Entra ID + Conditional Access for contractors, disables split tunneling for contractors (forced tunnel to hub firewall), and segments store VNets with NSGs so POS subnets only reach payment APIs. That multi-control story is how SC-500 expects you to reason—not a single product checkbox.
SC-500 Exam Traps (vWAN / VPN)
- Basic Virtual WAN ≠ User VPN / Firewall features—need Standard for full security scenarios.
- Entra P2S requires OpenVPN + Azure VPN Client, not SSTP-only thinking.
- ExpressRoute private ≠ automatically encrypted.
- VPN Gateway in a VNet ≠ Virtual WAN hub gateway—architecture answers differ.
- Secured hub = Azure Firewall integration, not “NSG on the hub automatically.”
- Forced tunneling is routing intent; still need firewall policy content.
A company wants remote employees to connect to Azure VNets with multifactor authentication and Conditional Access evaluation at sign-in. Which point-to-site design best meets this requirement?
What is a secured Virtual WAN hub?
Which statement correctly contrasts Azure VPN Gateway with Virtual WAN VPN connectivity?
Security policy requires that traffic from point-to-site VPN clients to the Internet be inspected by Azure Firewall in a Virtual WAN secured hub rather than breaking out locally on the laptop. Which concept primarily enables this path?