7.2 VPN Gateway, ExpressRoute Encryption & Virtual WAN Secured Hub

The Encryption Assumption That Fails the Exam

Candidates routinely assume ExpressRoute is encrypted because it is "private". It is not. ExpressRoute private peering is a dedicated layer 3 circuit through a connectivity provider — it bypasses the public internet, but the packets are not encrypted. If a scenario says "data in transit to Azure must be encrypted to satisfy a regulator", a plain ExpressRoute circuit does not satisfy it. Two answers do.

Option 1 — MACsec on ExpressRoute Direct (layer 2)

ExpressRoute Direct gives you 10 Gbps or 100 Gbps ports directly into the Microsoft global network. On those ports you can enable MACsec (IEEE 802.1AE), which encrypts the layer 2 link between your edge routers and the Microsoft Enterprise Edge (MSEE) routers.

• The connectivity association key (CAK) and connectivity association key name (CKN) are stored as secrets in Azure Key Vault, and the ExpressRoute Direct resource is granted access with a managed identity.
• Cipher options are GCM-AES-128 and GCM-AES-256 (and their XPN variants for extended packet numbering).
• MACsec protects the link, not end-to-end sessions, and it is only available on ExpressRoute Direct — not on provider-managed circuits.

Option 2 — IPsec over ExpressRoute private peering (layer 3)

Run a site-to-site VPN tunnel through the ExpressRoute private peering so the payload is IPsec-encrypted end to end between your on-premises VPN device and an Azure VPN gateway. This works on any ExpressRoute circuit, including provider-managed ones, at the cost of gateway throughput and some latency.

---

Site-to-Site VPN Hardening

A site-to-site connection uses IKE (IKEv1 or IKEv2) plus IPsec. The default Azure proposal set is broad for interoperability, which means it will accept algorithms your security policy would reject. Custom IPsec/IKE policy on the connection is the control:

Setting Perfect Forward Secrecy (PFS) means a compromised long-term key cannot decrypt previously captured sessions. Also enable UsePolicyBasedTrafficSelectors only when the on-premises device requires it, and prefer IKEv2 — IKEv1 is legacy and limited to older gateway SKUs.

Additional hardening: use active-active gateways with two public IPs for resilience, choose a zone-redundant (AZ) gateway SKU in supported regions, and use BGP so failover is automatic rather than route-table surgery.

---

Point-to-Site VPN Security

Point-to-site (P2S) lets individual clients dial in without a device tunnel.

Microsoft Entra ID authentication (OpenVPN only) is the security-relevant choice, because it brings the VPN under Conditional Access: you can demand MFA, a compliant device, or a trusted location before a tunnel is established, and you can revoke access by disabling the user rather than by revoking a certificate. Certificate authentication instead relies on a root certificate uploaded to the gateway, and revocation means maintaining a thumbprint revocation list on the gateway.

The Basic gateway SKU is legacy: it does not support IKEv2, OpenVPN, Entra ID authentication, active-active, or zone redundancy. Any hardening scenario implies VpnGw1–VpnGw5 (or their AZ variants).

---

Virtual WAN and the Secured Virtual Hub

Azure Virtual WAN is a Microsoft-managed hub-and-spoke backbone. Each virtual hub terminates VPN, ExpressRoute, and point-to-site connections and connects spoke virtual networks, with transitive routing handled by the platform.

A secured virtual hub is a virtual hub with a security provider deployed inside it:

• Azure Firewall (managed through Azure Firewall Manager), or
• A supported partner security provider for internet-bound traffic.

Routing intent is how you make the firewall actually see traffic. Instead of hand-crafting route tables on every spoke, you declare intent at the hub:

• Internet traffic → next hop Azure Firewall (protects egress and enforces application rules).
• Private traffic → next hop Azure Firewall (inspects VNet-to-VNet, branch-to-VNet, and branch-to-branch flows, giving you east-west inspection).

Virtual WAN also enforces useful constraints: you cannot attach NSGs to hub-managed subnets, so the firewall policy in the hub is the enforcement point rather than a patchwork of subnet rules. Firewall policies themselves are hierarchical — a base policy owned by the security team, inherited by child policies that application teams extend but cannot loosen.

Choose a secured virtual hub when the scenario mentions many branches, global transit, or "managed hub"; choose a customer-managed hub VNet with Azure Firewall when the scenario needs custom NVAs, unusual subnetting, or fine-grained control over the hub itself.