Azure P2S VPN: A Secure Blueprint for Remote Access

Azure Point-to-Site (P2S) VPN creates an encrypted connection from an individual computer to an Azure virtual network (VNet). It is a practical choice when employees, contractors, or administrators need controlled access to Azure virtual machines, private endpoints, databases, and internal applications without operating a traditional site-to-site appliance. Unlike site-to-site VPN, P2S does not require a branch firewall or a fixed office network; each approved client authenticates directly to the Azure VPN gateway.

This guide is aimed at intermediate IT administrators. It uses certificate authentication for a predictable baseline and also explains Microsoft Entra ID authentication for identity-based access. Azure changes portal labels and supported SKUs over time, so verify current limitations in Microsoft’s Point-to-site VPN documentation before production deployment. Keep a change record containing the VNet CIDR, client pool, gateway SKU, authentication method, DNS servers, certificates, and owners.

1. Plan the Address Space and Prerequisites

Begin with an Azure subscription, permission to create networking resources, and a resource group. You will also need a VNet, a non-overlapping client address pool, and a supported client operating system. The client pool is virtual address space assigned to connected users; it must not overlap the user’s home network, a corporate LAN, peered VNets, on-premises networks, or another VPN pool. A private range such as 172.30.0.0/24 is common, but choose a range owned by your organization rather than copying this example.

Plan the VNet before clicking through the portal. For example, use 10.40.0.0/16 for the VNet, 10.40.1.0/24 for workloads, and 10.40.255.0/27 for GatewaySubnet. Azure requires the exact subnet name GatewaySubnet; do not attach an NSG or user-defined route table to it, and do not deploy workloads there. A /27 or larger gateway subnet provides room for gateway instances and future features, while a /28 can be too restrictive for expansion.

Decide whether users need only Azure resources or also on-premises resources through ExpressRoute or a site-to-site VPN. Select DNS early: Azure-provided DNS works for many Azure-only designs, whereas an Azure DNS Private Resolver, domain controller, or reachable corporate DNS service may be required for private zones and internal names. Record the DNS suffixes that users should resolve, and remember that DNS reachability and authorization are separate from VPN encryption.

Recommended planning values: VNet 10.40.0.0/16, workload subnet 10.40.1.0/24, GatewaySubnet 10.40.255.0/27, P2S pool 172.30.0.0/24.
Authentication: certificates for simple device-based onboarding; Microsoft Entra ID for user sign-in, MFA, Conditional Access, and centralized offboarding.
Protocol: OpenVPN is usually the most flexible option; confirm platform support, especially for macOS, Linux, and mobile clients.
Screenshot recommendation: capture the final IP-plan spreadsheet and the Azure Portal VNet overview, with public IP addresses and certificates redacted.

Create the resource group, VNet, workload subnet, and gateway subnet with Azure CLI as follows:

az group create --name rg-p2s-prod --location eastus
az network vnet create --resource-group rg-p2s-prod --name vnet-corp-eastus \
  --address-prefixes 10.40.0.0/16 \
  --subnet-name WorkloadSubnet --subnet-prefixes 10.40.1.0/24
az network vnet subnet create --resource-group rg-p2s-prod \
  --vnet-name vnet-corp-eastus --name GatewaySubnet \
  --address-prefixes 10.40.255.0/27

Expected result: the VNet contains two non-overlapping subnets and the GatewaySubnet has no resources. In the portal, navigate to Virtual networks > vnet-corp-eastus > Subnets. Confirm the address ranges, delegation status, NSG association, and route-table association before continuing.

2. Deploy and Configure the Virtual Network Gateway

In the Azure Portal, select Create a resource > Virtual network gateway. Choose the subscription, resource group, region, and the planned VNet. Set Gateway type to VPN, select a route-based VPN type, create a Standard static public IP, and choose a gateway SKU. The gateway can take 30–45 minutes to provision, and the VNet cannot be moved between regions after deployment.

SKU selection should reflect concurrency, throughput, active-active requirements, and protocol support rather than only price. Basic is intended for limited legacy scenarios and has important feature restrictions; VpnGw1 or a current generation VPN SKU is a more sensible starting point for many small deployments. Higher SKUs improve aggregate throughput and connection capacity but do not automatically make a single user’s internet connection faster. Check the current gateway SKU comparison for supported authentication, zone redundancy, and generation details.

For a resilient production design, use zone-redundant SKUs where the region supports them and consider active-active mode with two public IP addresses. Active-active can improve availability but adds operational complexity and must be supported by the chosen configuration. Do not confuse a VPN gateway with Azure Virtual WAN; Virtual WAN is a different architecture for large-scale hub connectivity.

$rg = 'rg-p2s-prod'
$location = 'EastUS'
$vnet = Get-AzVirtualNetwork -ResourceGroupName $rg -Name 'vnet-corp-eastus'
$publicIp = New-AzPublicIpAddress -ResourceGroupName $rg -Name 'pip-vpngw' `
  -Location $location -AllocationMethod Static -Sku Standard
$subnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$ipconfig = New-AzVirtualNetworkGatewayIpConfig -Name 'gwipconfig' `
  -SubnetId $subnet.Id -PublicIpAddressId $publicIp.Id
New-AzVirtualNetworkGateway -ResourceGroupName $rg -Location $location `
  -Name 'vpngw-corp-eastus' -GatewayType Vpn -VpnType RouteBased `
  -GatewaySku VpnGw1 -IpConfigurations $ipconfig

The equivalent CLI operation is:

az network public-ip create --resource-group rg-p2s-prod --name pip-vpngw \
  --location eastus --sku Standard --allocation-method Static
az network vnet-gateway create --resource-group rg-p2s-prod \
  --name vpngw-corp-eastus --location eastus \
  --vnet vnet-corp-eastus --gateway-type Vpn --vpn-type RouteBased \
  --sku VpnGw1 --public-ip-address pip-vpngw

Validation checkpoint: run az network vnet-gateway show -g rg-p2s-prod -n vpngw-corp-eastus –query provisioningState and wait for Succeeded. In the portal, use Virtual network gateway > Overview and Point-to-site configuration. Take a screenshot of the overview and gateway SKU after removing public IP details from any document shared outside the operations team.

3. Configure Authentication and Client Addressing

Open Virtual network gateway > Point-to-site configuration > Configure now. Enter the client address pool, select OpenVPN (SSL) when available, and choose certificate or Microsoft Entra ID authentication. The pool should be large enough for simultaneous users and should include growth room; a /24 provides 256 addresses, although usable allocations and gateway behavior mean it should not be treated as exactly 256 permanent seats.

Certificate authentication uses a trusted root certificate on the gateway and a client certificate on each device. Generate a root certificate and keep its private key offline or in a protected certificate-management system. Issue client certificates from that root, give each device a unique certificate, and never distribute the root private key to users.

$root = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
  -Subject 'CN=Corp-P2S-Root' -KeyExportPolicy Exportable `
  -HashAlgorithm sha256 -KeyLength 2048 `
  -CertStoreLocation 'Cert:\CurrentUser\My' `
  -KeyUsageProperty Sign -KeyUsage CertSign
Export-Certificate -Cert $root -FilePath "$env:USERPROFILE\Desktop\Corp-P2S-Root.cer"
$client = New-SelfSignedCertificate -Type Custom -DnsName 'P2S-User-001' `
  -KeySpec Signature -Subject 'CN=P2S-User-001' `
  -Signer $root -KeyExportPolicy Exportable `
  -HashAlgorithm sha256 -KeyLength 2048 `
  -CertStoreLocation 'Cert:\CurrentUser\My' `
  -NotAfter (Get-Date).AddYears(1)
$password = ConvertTo-SecureString 'Use-A-Strong-Unique-Password!' -AsPlainText -Force
Export-PfxCertificate -Cert $client -FilePath "$env:USERPROFILE\Desktop\P2S-User-001.pfx" -Password $password

Open the exported .cer file in a text editor and copy only the Base64 certificate content, excluding the BEGIN and END lines if the portal requests the encoded body. In the portal, add a root certificate name and paste the root public certificate. Do not upload the root private key. Install the client .pfx into the user certificate store, protect it with a strong delivery password, and define a renewal and revocation process; deleting a client certificate from a device does not revoke a certificate already copied elsewhere.

Microsoft Entra ID authentication uses the Azure VPN Client and OpenVPN. In Point-to-site configuration, select Microsoft Entra ID, enter the tenant URL, audience, and issuer values shown by the portal, then follow the current Microsoft setup instructions to register or authorize the required enterprise application. Test MFA and Conditional Access in a pilot group first. Entra authentication improves identity governance, but it does not by itself grant access to every VNet resource; NSGs, firewalls, private endpoint policies, and application authorization still apply.

PowerShell can configure certificate-based P2S settings after the gateway exists:

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName $rg -Name 'vpngw-corp-eastus'
$p2s = New-AzVpnClientRootCertificate -Name 'Corp-P2S-Root' -PublicCertData (Get-Content "$env:USERPROFILE\Desktop\Corp-P2S-Root.cer" -Raw)
$gw | Set-AzVirtualNetworkGatewayVpnClientConfig -VpnClientAddressPool '172.30.0.0/24' `
  -VpnClientRootCertificates $p2s -VpnClientProtocol OpenVPN
$gw | Set-AzVirtualNetworkGateway

Expected result: the gateway’s P2S blade shows the client pool, protocol, and a trusted root certificate. If Entra ID is used, the blade also shows the configured tenant and audience. A screenshot should include those settings but obscure tenant identifiers if the document is public.

4. Download, Deploy, and Validate the VPN Client

After saving the P2S configuration, select Download VPN client from the gateway’s Point-to-site page. Azure generates a package containing profiles for supported platforms. Extract it only on a trusted administrator workstation, inspect the files, and distribute the smallest suitable package through Intune, Group Policy, a software-management platform, or an approved secure portal. For Entra ID authentication, install Azure VPN Client from the platform’s official store and import the generated profile rather than using an unrelated third-party OpenVPN profile.

On Windows, install the certificate in Current User > Personal, import the Azure VPN profile, and sign in. On macOS or Linux, use the supported Azure VPN Client or documented OpenVPN workflow for the selected authentication method. A profile generated before a gateway change may be stale; download a new package after changing the client pool, protocol, authentication, or gateway configuration.

Validate in a deliberate order. First confirm that the client receives an address from 172.30.0.0/24 and that the VPN status is Connected. Next resolve an internal DNS name, test TCP to a known service port, and only then test application login. For a Windows VM, use RDP only after NSG and Windows Firewall rules permit the client pool; for Linux, test SSH with keys and a restricted source range.

ipconfig /all
nslookup app01.corp.example
Test-NetConnection 10.40.1.10 -Port 3389
tracert 10.40.1.10

# Azure CLI checks from an administrator workstation
az network vnet-gateway show -g rg-p2s-prod -n vpngw-corp-eastus \
  --query '{state:provisioningState,sku:sku.name,active:active}'
az network watcher test-connectivity \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-p2s-prod/providers/Microsoft.Compute/virtualMachines/vm01 \
  --dest-address 10.40.1.10 --dest-port 3389 --protocol TCP

The VPN gateway’s client pool routes should include the VNet address space and, when applicable, peered VNet prefixes. For custom DNS, configure the VNet’s DNS servers under Virtual network > DNS servers, then reconnect clients so they receive updated settings. If using Azure Private DNS, link the private zone to the VNet; if using corporate DNS across a site-to-site path, verify that return routes exist for the P2S pool and that DNS servers allow queries from it.

5. Security, Routing, Operations, and Troubleshooting

Apply least privilege at every layer. Permit only the required P2S pool in workload NSGs, VM firewalls, database firewalls, and private endpoint network policies; avoid allowing 0.0.0.0/0 from the VPN pool. GatewaySubnet should remain free of NSGs and route tables, but workload subnets should use carefully reviewed NSGs. A user-defined route may be needed for on-premises prefixes, while forced tunneling and custom routes should be tested because they can change internet egress and DNS behavior.

If a client cannot connect, check the gateway provisioning state, public IP reachability, client clock, installed certificate chain, certificate expiration, certificate EKU, and whether the client profile matches the current gateway. For Entra failures, confirm the account is assigned to the application, MFA and Conditional Access are satisfied, the tenant is correct, and the Azure VPN Client is current. If the tunnel connects but resources fail, inspect routes, NSGs, VM firewalls, DNS suffixes, private DNS links, and return paths before changing authentication settings.

Performance depends on gateway SKU, encryption overhead, user ISP quality, client CPU, protocol, and the destination service. Measure latency and throughput from several locations rather than relying on one speed test. Avoid hairpinning ordinary internet traffic through Azure unless policy requires it; use split tunneling where appropriate, and keep large file transfers or backup traffic off a P2S path. Separate administrator access from general user access with distinct groups, profiles, or gateways when the risk warrants it.

Monitor the gateway from Monitor > Metrics and review connection count, tunnel health, throughput, P2S bandwidth, and packet drops. Enable diagnostic settings under Virtual network gateway > Diagnostic settings and send logs to Log Analytics, Storage, or Event Hubs according to retention requirements. Create alerts for gateway health, unusual connection volume, failed authentication where available, certificate expiry, and public IP or gateway changes. Azure Service Health and Network Watcher help distinguish platform incidents from configuration faults.

Cost includes the hourly VPN gateway charge, public IP address, Log Analytics ingestion and retention, and any data processing or related services. Check the regional pricing page and estimate the gateway’s always-on cost before selecting a SKU. Review usage monthly: downgrading a gateway can reduce cost but may remove capacity or features, while deleting and recreating it can disrupt profiles and public IP associations.

Maintain a certificate inventory with subject, thumbprint, owner, issue date, expiry date, and device. Rotate client certificates before expiration, test the replacement profile with a pilot group, and retain an emergency administrator path. Review Entra assignments, Conditional Access, NSGs, routes, DNS links, gateway SKU, diagnostic retention, and downloaded client packages at least quarterly. Document every change and keep a tested rollback procedure.

6. Real-World Corporate Architecture

A 450-person company deploys a zone-redundant VPN gateway in an East US hub VNet. The hub uses 10.40.0.0/16, reserves 10.40.255.0/27 for GatewaySubnet, and assigns 172.30.0.0/22 to P2S users. Spoke VNets contain application, data, and management subnets and are peered to the hub; gateway transit and forwarded traffic are enabled only where required. A site-to-site VPN connects the hub to the corporate data center, allowing approved administrators to reach selected on-premises systems.

Employees authenticate with Microsoft Entra ID and MFA through Azure VPN Client, while a small break-glass operations group uses short-lived device certificates stored under strict control. Azure DNS Private Resolver forwards corporate zones to on-premises DNS, and Azure Private DNS zones resolve private endpoints. NSGs permit the P2S pool to reach only management jump hosts and approved application ports; users then connect from those jump hosts rather than directly exposing every VM.

Azure Monitor sends gateway diagnostics to a central Log Analytics workspace, with alerts for health and anomalous connection counts. Intune deploys the VPN profile and removes it when a device leaves compliance. The architecture stays maintainable because addressing, identity, routing, DNS, authorization, monitoring, and certificate lifecycle are documented as separate controls instead of treating “VPN connected” as proof that access is safe.

Deployment Checklist

Subscription, resource group, region, permissions, and operating-system support are confirmed.
VNet and P2S address pools do not overlap with Azure, on-premises, home, or partner networks.
GatewaySubnet exists with the exact name, sufficient size, and no NSG or route table.
Workload NSGs and VM firewalls allow only required ports from the P2S pool.
Gateway SKU, public IP SKU, protocol, capacity, and redundancy match the design.
Root certificate is protected; unique client certificates, expiry dates, and renewal owners are recorded.
Entra application assignment, MFA, Conditional Access, tenant, audience, and issuer are tested if applicable.
A fresh VPN client package is deployed through an approved management channel.
Client receives a P2S address, resolves internal names, reaches approved ports, and fails to reach prohibited ports.
Peering, site-to-site routes, return routes, DNS forwarding, and private DNS links are validated.
Metrics, diagnostic logs, alerts, costs, certificate rotation, and quarterly review procedures are operational.
Screenshots, commands, test results, owners, and rollback steps are attached to the change record.