VPN Connections + Microsoft Entra Private Access
Securing Azure VPN — Site-to-Site IPsec configuration, Point-to-Site authentication options, the security trade-offs of VPN — and the newer Zero Trust path: Microsoft Entra Private Access for identity-based, application-level access without classical VPN.
Classical VPN, and what’s replacing it
For decades, “give the user remote access” meant a VPN — IPsec or SSL tunnel that effectively put the user’s laptop inside the corporate network. Once on the VPN, the user could reach everything the network reached, with whatever lateral-movement risks that brings.
SC-500 still tests classical VPN — both Site-to-Site (S2S) for branch offices and Point-to-Site (P2S) for remote users. But the bigger story is Microsoft Entra Private Access (EPA) — the Zero Trust Network Access (ZTNA) replacement for VPN. With EPA, remote users access specific applications (not whole networks), authenticated and authorised per-application, with Conditional Access policies applying per-app at each access. No tunnel into “the network”.
The exam pattern: scenarios calling out modern Zero Trust principles → Entra Private Access. Scenarios about branch-to-Azure or legacy remote-user → S2S/P2S VPN.
Site-to-Site (S2S) VPN
S2S connects an on-prem network to an Azure VNet over the internet via IPsec. Security best practices:
- IKEv2 with strong cipher suites (AES-256, SHA-256/384, DH Group 14+) — avoid IKEv1 and weak ciphers
- BGP for dynamic routing (preferred over static routes — auto-adapts to topology changes)
- Custom IPsec policies if compliance requires specific algorithm choices
- Active-Active gateway configuration for high availability (two tunnels, two public IPs, BGP between)
- Force tunneling outbound — route on-prem internet through Azure egress for inspection (or vice versa, route Azure egress through on-prem for inspection)
Point-to-Site (P2S) VPN
P2S connects individual remote-user devices to a VPN gateway. Authentication options:
| P2S auth method | Pros | Cons |
|---|---|---|
| Azure certificate authentication | Simple to deploy; cert-based identity | No identity-aware controls (no MFA, no CA); per-user cert provisioning manual |
| RADIUS | Integrates with existing RADIUS/AD infrastructure | Additional moving parts; no native Entra CA |
| Microsoft Entra ID authentication (OpenVPN protocol) | Entra identity; Conditional Access applies (MFA, compliant device, etc.); audit per user | OpenVPN protocol only; requires Azure VPN client |
For SC-500, Microsoft Entra authentication with Conditional Access is the right answer when the scenario requires identity-aware enforcement (MFA, device compliance, posture) on a P2S VPN.
Microsoft Entra Private Access (EPA)
EPA is the ZTNA replacement for VPN in many remote-access scenarios. Architecture:
- Private Access connector — lightweight agent deployed on a Windows server inside the application’s network (Azure VNet, on-prem, AWS). Establishes outbound-only connections to Microsoft’s Global Secure Access edge.
- Application registration in Entra — each internal app is published with its name, FQDN/IP, ports, segment.
- Conditional Access per-app — CA policies target the published application; common stack: require compliant device + Phishing-resistant MFA + low sign-in risk.
- Client — Global Secure Access client on Windows (Mac/iOS/Android via the GSA client too); tunnels only the published-application traffic to Microsoft’s edge, then to the connector.
EPA vs classical P2S VPN
| Aspect | Classical P2S VPN | Entra Private Access |
|---|---|---|
| Access model | User joins 'the network' — can reach everything routable | User accesses specific applications — invisible to anything not published |
| Identity awareness | Authenticated at connect; reach is all-or-nothing thereafter | Authenticated + CA-gated per application access; revocation immediate |
| Network exposure | VPN endpoint is internet-reachable on a public IP | Connector is outbound-only — no inbound exposure |
| Lateral movement | A compromised device can scan / pivot across the entire VPN-reachable network | Compromised device can only reach the apps it has CA-grants for |
| When to use | Legacy fit, broad-network remote access, BYOD with limited management | Modern ZTNA — preferred default; identity-aware per-app access |
Scenario: Dom switches a Kestrel customer from VPN to Entra Private Access
A Kestrel customer’s CISO requests a Zero Trust roadmap. Dom proposes:
- Replace P2S VPN with Entra Private Access for remote staff. Deploy 2 Private Access connectors in the data VNet (HA). Publish 4 internal apps initially (HR portal, payroll, internal documentation, finance app).
- Conditional Access per published app: require compliant device + phishing-resistant MFA + low sign-in risk; finance app additionally requires “Finance” group membership.
- Roll out Global Secure Access client to remote staff via Intune.
- Keep S2S VPN for branch connectivity (branches still need network-level reach) — but configure on the vWAN secured hub with central Azure Firewall inspection.
- Decommission the P2S VPN endpoint after 60 days of EPA pilot — eliminating an internet-reachable VPN concentrator.
Result: remote-user access is now identity-aware per app, no inbound VPN endpoint, lateral movement contained.
Key terms
Knowledge check
Esme at Northwind Bank's CISO wants to replace the bank's P2S VPN for remote staff with a Zero Trust solution — per-application access, identity-aware enforcement, no inbound VPN concentrator. Which Microsoft service fits?
Ravi at Maple Genomics deploys 2 Entra Private Access connectors in the genomics-app VNet. He wants to ensure that when researchers access the published 'genomics-portal' app, they must satisfy MFA + compliant device. Where does he configure this?
What’s next
Next module: Private Endpoints + Private Link — taking PaaS services off the internet and into your VNets.