Remote Worker Needs Private Azure Access? Configure a Point-to-Site VPN

Published on:

A remote CloudTrips worker needs access to private Azure resources but is not connected to a company office network. A site-to-site VPN cannot solve this scenario without an office router or another VPN device.

A point-to-site (P2S) VPN creates an encrypted connection from one client computer—the point—to an Azure VNet—the site. The worker starts the connection in Azure VPN Client and authenticates with a Microsoft Entra account. No datacenter or company VPN appliance is required.

This trip builds on: Private Azure Access Needs a VPN Endpoint? Create a VPN Gateway.

Plan the Client Connection

Use:

VPN gateway: vng-cloudtrips-hub-test-weu
Client address pool: 172.30.0.0/24
Tunnel type: OpenVPN (SSL)
Authentication type: Microsoft Entra ID
Azure VPN Client audience: c632b3df-fb67-4d84-bdcf-b95ad541b5c8

The client address pool is not an Azure subnet. Azure assigns one address from this range to each connected VPN client. It must not overlap any CloudTrips VNet or the local network from which the laptop connects. If your current network already uses 172.30.0.0/24, select another unused private range.

Before continuing, confirm that vng-cloudtrips-hub-test-weu shows Provisioning state: Succeeded and that peer-app-to-hub is configured to use the hub’s remote gateway.

Find the Tenant ID

In the Azure portal, open Microsoft Entra ID > Overview and copy the Tenant ID. The tenant ID identifies the CloudTrips Microsoft Entra directory; it is not a client secret.

Use it to construct:

Tenant: https://login.microsoftonline.com/<your-tenant-id>
Issuer: https://sts.windows.net/<your-tenant-id>/

The trailing / on the Issuer value is required.

Configure Point-to-Site Access

Open vng-cloudtrips-hub-test-weu and select Settings > Point-to-site configuration > Configure now.

Configure:

Address pool: 172.30.0.0/24
Tunnel type: OpenVPN (SSL)
Authentication type: Microsoft Entra ID
Tenant: https://login.microsoftonline.com/<your-tenant-id>
Audience: c632b3df-fb67-4d84-bdcf-b95ad541b5c8
Issuer: https://sts.windows.net/<your-tenant-id>/

The Audience value identifies Microsoft’s registered Azure VPN Client. It is the same for Azure Public tenants and does not need an app registration created in the CloudTrips tenant.

The portal might still display Azure Active Directory instead of Microsoft Entra ID. They refer to the same authentication option here.

Point-to-site configuration page showing the CloudTrips client address pool, OpenVPN tunnel, and Microsoft Entra ID values

Select Save and wait for the update to complete.

Download the Client Profile

At the top of Point-to-site configuration, select Download VPN client. Azure can take several minutes to generate the package.

Extract the downloaded ZIP file and open its AzureVPN folder. It contains azurevpnconfig.xml or azurevpnconfig_aad.xml. The file contains the gateway and authentication settings that Azure VPN Client needs; it does not contain your Microsoft Entra password.

CloudTrips Point-to-site configuration page showing Download VPN client after the settings were saved

If the profile does not contain the routes to the CloudTrips spoke VNets, confirm gateway transit on the hub peerings and remote-gateway use on the spoke peerings, then download a new client package.

Install and Connect Azure VPN Client

Install Azure VPN Client from the Microsoft Store on Windows or the App Store on macOS. Cisco Secure Client is not used for this Microsoft Entra ID configuration.

Open Azure VPN Client and select + > Import. Select the XML file from the extracted AzureVPN folder, keep the imported settings, and select Save.

Select the new CloudTrips profile and then select Connect. Sign in with your CloudTrips Microsoft Entra account and complete MFA if requested.

Azure VPN Client showing the imported CloudTrips profile in Connected state

The client should show Connected and receive an address from 172.30.0.0/24. This proves that the laptop authenticated and established the OpenVPN tunnel. The next step verifies access to a private workload.

Prepare a Temporary Private Test Service

The earlier NSG diagnostic trip deleted its temporary VM but preserved nic-cloudtrips-vm-test-weu. Recreate the VM briefly with that NIC:

az vm create \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --location westeurope \
  --zone 3 \
  --nics nic-cloudtrips-vm-test-weu \
  --image Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest \
  --size Standard_D2s_v3 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --os-disk-name osdisk-cloudtrips-nsg-test-weu \
  --os-disk-size-gb 30 \
  --storage-sku Standard_LRS \
  --os-disk-delete-option Delete \
  --nic-delete-option Detach

Allow only VPN clients to reach the test service on TCP 443:

az network nsg rule create \
  --resource-group rg-cloudtrips-network-test-weu \
  --nsg-name nsg-cloudtrips-app-test-weu \
  --name Allow-HTTPS-P2S \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 172.30.0.0/24 \
  --source-port-ranges '*' \
  --destination-asgs asg-cloudtrips-app-test-weu \
  --destination-port-ranges 443

Start a temporary HTTP service on port 443 through Azure Run Command:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --command-id RunShellScript \
  --scripts "systemd-run --unit=cloudtrips-p2s-test --property=Restart=always /usr/bin/python3 -m http.server 443 --directory /tmp"

This is a temporary plain-HTTP connectivity test on TCP 443, not a production HTTPS service.

Test the Private Connection

While Azure VPN Client shows Connected, run this command on the laptop—not in Cloud Shell:

curl http://10.20.1.4:443

The returned directory listing comes from the VM’s private IP. The request travels from the laptop through the point-to-site tunnel, the hub VPN gateway, and the hub-to-application peering. It does not use the VM’s public IP.

Local terminal showing a successful response from the private address 10.20.1.4 while Azure VPN Client is connected

If the VPN connects but the request fails, confirm that the VM is running, its private IP is still 10.20.1.4, the test service is active, the P2S NSG rule exists, and the laptop received the spoke routes from the downloaded profile.

Remove the Temporary Compute

Disconnect Azure VPN Client, and then delete the temporary VM and test rule:

az vm delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-nsg-test-weu \
  --yes

az network nsg rule delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --nsg-name nsg-cloudtrips-app-test-weu \
  --name Allow-HTTPS-P2S

The OS disk is deleted and the existing NIC is detached and preserved. The VPN Gateway continues to incur charges until it is deleted, even when no client is connected.