Skip to main content
This lesson explains how to configure Point-to-Site (P2S) VPN connections in Azure, covering the end-to-end flow from network preparation to client connection and hub-spoke gateway transit. High-level workflow:
  • Create or reuse VNets and subnets.
  • (Optional) Specify custom DNS servers.
  • Create the gateway subnet and VPN Gateway (or reuse an existing VPN Gateway).
  • Configure the Point-to-Site settings on the VPN Gateway.
  • Download and install the VPN profile on client devices.
The image is a slide titled "Site-to-Site Connections" showing an Azure workflow with connected boxes: Create VNets and Subnets, Specify the DNS Server (optional), Create the Gateway Subnet, Create the VPN Gateway, Configure P2S Connection, and Install VPN Profile. It also shows an Azure icon above the steps and a device icon at the end to represent the remote device.
The P2S workflow is straightforward: configure the P2S settings on the VPN Gateway in the Azure portal, download the generated VPN client package, import the client profile into the Azure VPN Client (or a supported third-party client), and connect.
You can reuse an existing VPN Gateway for Point-to-Site connections. Confirm that the gateway SKU supports P2S and the tunnel types/authentication methods you require before enabling P2S.

​
Configure Point-to-Site in the Azure portal

  1. Open the VPN Gateway resource in the Azure portal.
  2. Select the “Point-to-site configuration” blade.
  3. Configure these key fields:
  • Address pool: the IP range assigned to P2S clients (e.g., 172.17.0.0/24). Ensure the pool is large enough for concurrent clients.
  • Tunnel type: OpenVPN, SSTP, IKEv2, or a combination. OpenVPN is commonly used for cross-platform compatibility.
  • Authentication type: Certificate, Azure Active Directory (Microsoft Entra ID), or RADIUS.
A screenshot of the Microsoft Azure portal showing the "vpn-gw-az700 | Point-to-site configuration" page with an address pool set to 172.17.0.0/24 and the Tunnel type dropdown open (options like OpenVPN, SSTP, IKEv2). The left sidebar shows Azure navigation items such as Overview, Settings, and Monitoring.
Key configuration guidance (summary table):
Configuration ItemPurposeRecommendation
Address poolIPs assigned to clientsUse a dedicated, non-overlapping CIDR (e.g., 172.17.0.0/24)
Tunnel typeVPN transport protocol(s)Use OpenVPN for broad client support; add IKEv2/SSTP if required
AuthenticationHow clients authenticateUse Azure AD for centralized identity or certificate auth for simpler setups
Gateway SKUFeature support and throughputEnsure the SKU supports P2S, required tunnels, and concurrent connections
If you select Microsoft Entra ID (Azure AD) as the authentication method, provide three values:
  • Tenant ID — your Azure AD tenant GUID.
  • Audience — the application/audience value used by OpenVPN configuration.
  • Issuer — the issuer URL (varies by cloud). Azure includes guidance and links in the portal for authorizing the Microsoft VPN client application in your tenant. You must usually authorize the client application before Azure AD authentication will work.
Example issuer endpoints (replace ): 
Azure Public:   https://login.microsoftonline.com/{TenantID}/
Azure US Gov:   https://login.microsoftonline.us/{TenantID}/
Azure Germany:  https://login-us.microsoftonline.de/{TenantID}/
Azure China:    https://login.chinacloudapi.cn/{TenantID}/
STS issuer:     https://sts.windows.net/{TenantID}/
Example tenant ID (placeholder — replace with your tenant GUID): 
{TenantID} = 41b23e61-6c1e-4545-b367-cd054e0ed4b4
Fill Tenant ID, Audience, and Issuer fields in the portal according to your cloud and then Save the configuration.
When using Microsoft Entra ID authentication, ensure the VPN client application is authorized in your tenant and that the Audience/Issuer values match the registered app. Misconfigured values will prevent clients from obtaining tokens.

​
Download and import the VPN client profile

After saving the P2S configuration, Azure generates a VPN client package (ZIP) for supported platforms. Steps to get the client connected:
  1. In the VPN Gateway blade, click “Download VPN client” and save the ZIP file.
  2. Unzip the package and locate the platform-specific XML/profile files.
  3. Open the Azure VPN Client application:
    • Click Add -> Import.
    • Select the XML profile from the unzipped folder.
  4. The Azure VPN Client imports the profile and creates a connection entry.
Example Azure VPN Client log entries after importing: 
08/18/2025 23:17:26: Information The VPN connection profile MSFT-AzVPN-Manual is added/imported successfully.
08/18/2025 23:17:26: Information Application Initialized
Connect using the imported profile. If using Azure AD authentication, you’ll be prompted to sign in with your Microsoft Entra account. Example successful connection and connection properties: 
08/18/2025 23:43:46: Information Dialing VPN connection vnet-az700-p2s-hub. Status = Success
08/18/2025 23:43:44: Information Successfully Received Microsoft Entra Credential Token. User: rithinskaria@kodekloudlab.onmicrosoft.com

Connection Properties
Connection Name: vnet-az700-p2s-hub
VPN Server: azuregateway-1ac10077-09be-432f-908f-e2a20435c638-63e3e296b904.vpn.azure.com
Authentication Type: Microsoft Entra ID
Connect Time: 08/18/2025 23:43
VPN IP Address: 172.17.0.2
Bytes in/out: 0/0
VPN Routes:
10.90.0.0/24
172.17.0.0/24
In this example the client received 172.17.0.2 from the P2S address pool and learned routes to the directly connected VNets.

​
Hub-spoke scenario and gateway transit

If your VPN Gateway is in a hub VNet and you want P2S clients to access spoke VNets, enable gateway transit through VNet peering.
  1. Open the Virtual Networks blade and identify the hub and spoke VNets.
  2. Edit the hub-to-spoke peering:
    • Enable “Allow gateway or route server to be used in the remote virtual network” (portal text may show Allow gateway transit / Use remote gateways).
  3. Edit the spoke-to-hub peering:
    • Enable “Use remote gateway” (so the spoke uses the hub’s VPN gateway).
Start by locating the VNets in the portal.
A screenshot of the Microsoft Azure portal showing the "Network foundation | Virtual networks" page. It lists three virtual networks (e.g., vnet-az700-demo, vnet-az700-p2s-hub, vnet-az700-p2s-spoke) with their resource groups and locations.
Edit the peering from the hub to the spoke and enable gateway transit, then Save.
A screenshot of the Microsoft Azure portal showing the "peer-hub-to-spoke" virtual network peering page. It displays the local virtual network summary and peering settings with several checkboxes (connected state) and Save/Cancel buttons.
After updating peering, the spoke learns to use the hub gateway. You may need to disconnect and reconnect the VPN client so it pulls the updated route table. Once propagated, the client should show routes to the spoke networks via the hub gateway. Example updated connection properties showing transit routes: 
Connection Properties
Connection Name: vnet-az700-p2s-hub
VPN Server: azuregateway-1ac10077-09be-432f-908f-e2a20435c638-63ea3e296b904.vpn.azure.com
Authentication Type: Microsoft Entra ID
Connect Time: 08/18/2025 23:52
VPN IP Address: 172.17.0.2
Bytes in/out: 0/0
VPN Routes:
10.91.0.0/16
10.90.0.0/24
172.17.0.0/24

Status Logs
08/18/2025 23:52:48: Information Dialing VPN connection vnet-az700-p2s-hub. Status = Success
08/18/2025 23:52:36: Information Disconnecting VPN connection vnet-az700-p2s-hub. Status = Success

​
Verify access to internal resources

With the VPN connected and peering/gateway transit configured:
  • Test connectivity to internal private IPs (VMs or services without public IPs).
  • Verify network security group (NSG) rules allow the necessary inbound traffic from the P2S address pool or hub subnets.
  • Confirm effective routes on target VMs or network interfaces if needed.
Quick troubleshooting checklist:
CheckWhy
VPN client IPEnsure client received an IP from the P2S address pool
VPN routesEnsure routes to the hub and spokes are present in the client
VNet peeringHub peering should allow gateway transit; spoke peering should use remote gateway
NSGs / FirewallConfirm rules permit traffic from P2S CIDR to the target resources
Gateway SKU & limitsEnsure SKU supports required tunnels and client count
This completes the end-to-end P2S configuration and verification steps.

​
References and next steps

Next: move on to an advanced networking topic (for example, configuring Site-to-Site VPNs or managing Azure Firewall + P2S scenarios).

Watch Video