Developer Access with Point-to-Site VPN¶
With a zero-trust approach most Azure resources have no public endpoint: they are reachable only over a private network. Yet engineers still need to reach storage accounts, Key Vaults and databases in their spokes from where they work. A point-to-site (P2S) VPN into the Virtual WAN is one way to offer that. This page describes a design and the reasoning. It is a pattern, not a description of what every platform has.
What MCP offers
The platform can create a point-to-site VPN gateway (create_point_to_site_vpn_gateway, see
Platform features). The segmentation per workload described below
(user groups with their own address pools, firewall rules per pool) is a design on top of that. Check what your
platform implements before you promise it to teams.
Scope¶
- Access from an engineer's device to workload spokes: private endpoints, Key Vaults, storage accounts, virtual machines.
- Not access to on-premises sites, subsidiary offices or SaaS services. Keep those off the workload VPN.
- Only for consumers of the platform.
Principles¶
| Principle | Reason |
|---|---|
| Use an existing platform (Virtual WAN) instead of a new one | Fewer platforms mean less complexity, cost and maintenance |
| Sign in with Entra ID single sign-on and conditional access | One central place for authentication and authorisation policy |
| Let the data classification decide the conditional access policy | The classification dictates the protection |
| Configure the VPN access when the workload is created | Fewer change requests |
| Base authorisation on the workload role model, not on individual assignments | Less maintenance |
| Non-production spokes: reachable for all consumers, for the allowed protocols | Simple, and production is protected separately |
| Production spokes: access needs a PIM activation approved by the workload's approver | Production access is explicit and logged |
| A production session reaches one workload only | Prevents direct data exchange between production workloads |
Design choices¶
| Choice | Reason |
|---|---|
| A separate P2S gateway in the Virtual WAN, not the site-to-site gateway | Bandwidth of the site connections is not affected, and it scales independently |
| Highly available, but small at first | P2S access is critical for support, but initial usage is limited |
| P2S configuration and firewall rules are maintained in the hub | Prevents misuse |
| Two client address pools: one for non-production, one for production, reserved from the connectivity range | The source IP of a packet then shows whether the user was approved for non-production or for production |
| Inside the production pool, one small subnet per workload (a /28 or /29 depending on the number of users) | Isolates a production session to one workload |
| A production user group has priority over the generic non-production group | A production user keeps the isolation to that workload |
| Firewall rule for non-production is generic and lives with the platform rules. Firewall rules for production are part of the workload's own rule file. | The rule is removed or changed together with the workload |
Technical notes¶
- Protocol and clients. OpenVPN is the protocol that supports Entra ID authentication and both Windows and macOS clients. Check the current client support for other systems.
- User groups. Azure P2S supports user groups that map an Entra ID identity to an address pool. Use one group for non-production and one per workload for production.
- Split tunnelling. Only traffic to Azure goes through the VPN. Internet traffic does not pass the Azure Firewall. Send all DNS to Azure so private names resolve (DNS design).
- Cost. Plan the scale unit and the connection units. A small deployment with one scale unit and a handful of connections is cheap; data transfer is charged on top.
- Monitoring. Alert on gateway availability, bandwidth use and the number of concurrent connections.
Conditional access by data classification¶
| Data classification | Access to | Typical policy |
|---|---|---|
| Low (non-production) | Non-production spokes | MFA required, sign-in and user risk at medium |
| Moderate (production) | The workload's production spoke | MFA required, higher risk thresholds than the non-production policy |
| High (production) | The workload's production spoke | The moderate policy plus a compliant device and a restriction on location |
The levels and thresholds are examples. See Security classification.
Processes¶
When a workload is created:
- Add the users to the group for non-production VPN access.
- Create an Entra ID group for production VPN access.
- Set up the PIM process for that group.
- Create the firewall rule for production access in the workload's rule file.
- Create the user group in the P2S configuration.
When a spoke is added to a workload: change the firewall rule to include the spoke's address range.