This chapter covers Azure Point-to-Site (P2S) VPN Gateway, a critical networking feature that enables individual clients to securely connect to an Azure virtual network from anywhere over the internet. For the AZ-104 exam, P2S VPN is a high-probability topic, appearing in roughly 5-10% of questions related to hybrid connectivity and network security. You will need to understand its architecture, authentication methods (certificate-based, Azure AD, RADIUS), configuration steps, and how it differs from Site-to-Site VPN and ExpressRoute. Mastering P2S VPN ensures you can design secure remote access solutions for Azure workloads.
Jump to a section
Imagine a corporate headquarters (Azure VNet) with a single, guarded entrance (VPN gateway). The company issues ID badges (client certificates) to employees who work remotely. Each badge has a unique employee number and is digitally signed by the company's HR department (root certificate). To enter, an employee presents their badge to the guard, who verifies the signature against a list of trusted issuers (root certificate trust). The guard then checks a roster (VPN client address pool) to assign a temporary desk number (client IP) for the day. Once inside, the employee can access only the areas (VNet resources) their badge permits (route filters). The guard also keeps a log of who entered and when (diagnostic logs). If an employee loses their badge, HR revokes it (certificate revocation list) and the guard denies entry. This system allows many remote employees to connect securely without needing a dedicated private road (Site-to-Site VPN) or a leased line (ExpressRoute).
What is Point-to-Site VPN?
Point-to-Site (P2S) VPN is a secure tunnel from an individual client computer to an Azure virtual network (VNet). Unlike Site-to-Site (S2S) VPN, which connects entire networks (e.g., an on-premises datacenter to Azure), P2S connects individual devices—such as laptops, desktops, or mobile phones—to Azure resources. P2S uses the Secure Socket Tunneling Protocol (SSTP) (TCP port 443) or IKEv2 VPN (UDP ports 500 and 4500) to establish the tunnel. SSTP can traverse firewalls and NAT devices because it uses HTTPS, while IKEv2 is more resilient to network changes.
Why P2S Exists
P2S solves the problem of providing secure remote access to Azure resources without requiring a dedicated on-premises VPN device or a static public IP address. It is ideal for:
Remote employees who need to access Azure VMs or services.
Developers connecting to dev/test environments.
Administrators managing Azure resources from untrusted networks.
How P2S Works Internally
Gateway Creation: A VPN gateway must be deployed in the Azure VNet. The gateway is a Microsoft-managed service that runs on dedicated Azure infrastructure. It requires a gateway subnet (named GatewaySubnet) with a minimum size of /27. The gateway SKU (Basic, VpnGw1, etc.) determines throughput and feature support.
2. Authentication: P2S supports three authentication methods: - Certificate-based: Uses X.509 certificates. A root certificate is uploaded to Azure, and client certificates (issued by the root) are installed on clients. Azure validates the client certificate against the uploaded root. - Azure Active Directory (Azure AD): Uses Azure AD authentication with OpenID Connect (OIDC). Clients authenticate using Azure AD credentials (e.g., username/password, MFA). This is the recommended method for simplicity and security. - RADIUS: Uses a Remote Authentication Dial-In User Service (RADIUS) server for authentication. The RADIUS server can be on-premises or in Azure.
Tunnel Establishment: The client initiates a VPN connection using the Azure VPN client (or native OS VPN client for IKEv2). The client and gateway negotiate a secure tunnel using SSTP or IKEv2. For certificate authentication, the client presents its certificate during the TLS or IKE handshake.
Address Assignment: The VPN gateway assigns an IP address to the client from a defined client address pool (e.g., 172.16.0.0/24). This pool must not overlap with the VNet address space or any on-premises networks. The client uses this IP to communicate with VNet resources.
Routing: Routes are automatically injected into the client's routing table. By default, the client can reach all VNet resources. Forced tunneling can be configured to route all client traffic through the VPN gateway to on-premises.
Key Components, Values, and Defaults
VPN Gateway SKUs: Basic, VpnGw1, VpnGw2, VpnGw3, VpnGw1AZ, VpnGw2AZ, VpnGw3AZ. Basic does not support IKEv2, RADIUS, or BGP. AZ SKUs are zone-redundant.
Protocols: SSTP (TCP 443) and IKEv2 (UDP 500 and 4500). For SSTP, maximum concurrent connections: Basic – 128, VpnGw1 – 128, VpnGw2 – 128, VpnGw3 – 128. For IKEv2: Basic – 128, VpnGw1 – 250, VpnGw2 – 500, VpnGw3 – 1000.
Client Address Pool: Must be a private IP range (e.g., 192.168.0.0/24) that does not overlap with any VNet or on-premises address space. Size must accommodate the maximum number of concurrent connections.
Root Certificates: Up to 20 trusted root certificates can be uploaded per VPN gateway.
Revoked Certificates: Certificates can be revoked by adding their thumbprint to the revoked list. Up to 1000 thumbprints can be listed.
Authentication Methods: Certificate, Azure AD, RADIUS. Azure AD is the preferred method for new deployments.
VPN Client: For Azure AD authentication, use the Azure VPN Client (available for Windows, macOS, Linux, Android, iOS). For certificate-based, the native OS VPN client can be used with IKEv2.
Configuration Steps (Azure Portal)
Create a VNet with a gateway subnet.
Create a VPN gateway (requires ~45 minutes).
Configure P2S settings:
- Choose authentication type (Azure AD, certificate, RADIUS). - For certificate: Upload root certificate (.cer file). - For Azure AD: Provide tenant ID, audience, and issuer. - Define client address pool. 4. Download and install VPN client configuration package (for certificate-based) or configure Azure VPN Client (for Azure AD). 5. Install client certificate on each device (if using certificate auth). 6. Connect from client.
Verification Commands (Azure CLI)
# List VPN gateways
az network vnet-gateway list --resource-group MyRG
# Show P2S configuration
az network vnet-gateway show --name MyGateway --resource-group MyRG --query 'vpnClientConfiguration'
# Show VPN client connection health
az network vnet-gateway list-bgp-peer-status --resource-group MyRG --name MyGateway
# Revoke a client certificate
az network vnet-gateway revoked-cert create --resource-group MyRG --name MyGateway --thumbprint ABC123...Interaction with Related Technologies
Site-to-Site VPN: P2S can coexist with S2S on the same VPN gateway. Both use the same gateway bandwidth.
ExpressRoute: P2S can coexist with ExpressRoute, but traffic routing must be carefully managed (e.g., using forced tunneling to route client traffic over ExpressRoute).
Network Security Groups (NSGs): NSGs on subnets or NICs can restrict traffic from P2S clients. Client source IPs are from the client address pool.
Azure Firewall: Can be used to inspect/filter P2S traffic if forced tunneling is enabled.
BGP: Not supported for P2S connections (only for S2S).
Limitations
P2S does not support BGP.
Maximum concurrent connections depend on gateway SKU and protocol.
SSTP requires TCP port 443 to be open on the client's network.
IKEv2 may be blocked by some corporate firewalls.
Certificate-based authentication requires certificate lifecycle management.
Create VNet and GatewaySubnet
First, create a virtual network (VNet) with an address space (e.g., 10.1.0.0/16). Within that VNet, create a subnet named 'GatewaySubnet' with a /27 prefix (e.g., 10.1.0.0/27). The GatewaySubnet is reserved exclusively for VPN gateway instances. Azure will allocate IP addresses from this subnet to the gateway. The subnet must not be associated with any route tables or NSGs, as Azure manages those for the gateway. This step is foundational and must be completed before creating the VPN gateway.
Create VPN Gateway
Create a VPN gateway in the GatewaySubnet. Choose a SKU (e.g., VpnGw1) that supports the required features (P2S, IKEv2, etc.). The gateway type must be 'VPN', and the VPN type is 'RouteBased' (required for P2S). During creation, you must specify a public IP address (Basic or Standard SKU) that will be the endpoint for VPN connections. The gateway takes 30-45 minutes to deploy. The gateway's public IP is static; it does not change unless the gateway is deleted and recreated.
Configure P2S Authentication
In the VPN gateway's Point-to-site configuration blade, choose the authentication method. For certificate-based, upload the root certificate (.cer file) and optionally add revoked certificates. For Azure AD, provide the Tenant ID, Audience (application ID of the Azure VPN Client app), and Issuer (e.g., https://sts.windows.net/tenant-id/). For RADIUS, provide the RADIUS server IP and secret. Also define the client address pool (e.g., 192.168.0.0/24). This pool must not overlap with any VNet or on-premises address space. The gateway uses this pool to assign IPs to connected clients.
Download and Install VPN Client
After configuration, download the VPN client configuration package from the Azure portal. For certificate-based, the package includes the VPN profile XML and scripts. For Azure AD, the Azure VPN Client app is used. Install the client on each device. For certificate-based, also install the client certificate (issued by the trusted root) on the device. The client certificate must have the Client Authentication EKU (Enhanced Key Usage) and be in the Current User\Personal certificate store. The VPN client uses the profile to connect to the gateway's public IP.
Connect from Client
Launch the VPN client and connect. For SSTP, the client establishes a TCP connection to the gateway on port 443. For IKEv2, it uses UDP 500 and 4500. The gateway authenticates the client (e.g., validates the client certificate). Upon success, the gateway assigns an IP from the client address pool and pushes routes to the client. The client can now access VNet resources. To verify, check the client's VPN status and IP configuration. The connection is tunneled; all traffic to the VNet is encrypted.
Scenario 1: Remote Developer Access to Dev/Test Environments
A software company has its development and test environments in Azure. Developers work from home or coffee shops. The company deploys a P2S VPN with Azure AD authentication. Developers install the Azure VPN Client on their laptops and authenticate with their corporate credentials (including MFA). The VPN gateway uses a VpnGw2 SKU to support up to 500 concurrent IKEv2 connections. The client address pool is 10.200.0.0/22. A common misconfiguration is using a pool that overlaps with the VNet (10.0.0.0/16) causing routing conflicts. The solution is to choose a non-overlapping range. Performance is generally adequate for SSH and RDP; for heavy data transfers, throughput is limited by the gateway SKU (VpnGw2: 1.25 Gbps aggregate).
Scenario 2: Secure Management of Azure VMs from Untrusted Networks
An IT administrator needs to manage Azure VMs from a hotel or airport Wi-Fi. They use certificate-based P2S VPN with IKEv2. The root certificate is generated using makecert or a public CA. Client certificates are installed on the admin's laptop. The VPN gateway is Basic SKU (cost-saving, but limited to 128 connections). The admin connects and uses private IPs to RDP or SSH into VMs. A common issue is certificate expiration; the admin must renew client certificates before expiry. Revocation is handled by uploading the revoked certificate thumbprint to Azure. This setup ensures no public IPs are exposed on the VMs.
Scenario 3: Remote Access with On-Premises Authentication via RADIUS
A large enterprise wants to use its existing RADIUS infrastructure (e.g., NPS with smart cards) for P2S VPN authentication. They configure the Azure VPN gateway with RADIUS server IP and shared secret. The RADIUS server is on-premises and must be reachable from Azure (via S2S VPN or ExpressRoute). Clients connect using SSTP (since IKEv2 may not support all RADIUS attributes). The gateway forwards authentication requests to RADIUS. A common failure is the RADIUS server not having the correct NAS IP address or shared secret. Also, RADIUS timeouts can cause connection drops; ensure the server is highly available. This setup leverages existing security policies but adds complexity.
What AZ-104 Tests on P2S VPN
The AZ-104 exam tests P2S VPN under objective 'Configure and manage virtual networking' (4.4). Questions focus on:
Authentication methods: Which method supports MFA? (Azure AD). Which method requires certificate upload? (Certificate-based).
Gateway SKU limitations: Which SKU does not support IKEv2? (Basic). Which SKU supports zone-redundancy? (AZ SKUs).
Client address pool: Must not overlap with VNet or on-premises. Size must accommodate max connections.
Coexistence: Can P2S and S2S coexist on the same gateway? (Yes).
Protocol support: SSTP uses TCP 443; IKEv2 uses UDP 500/4500.
Common Wrong Answers and Traps
'P2S VPN requires a public IP on the client.' Wrong. The client is behind NAT; the gateway has the public IP.
'P2S supports BGP for dynamic routing.' Wrong. BGP is only for S2S.
'You can use the same client address pool as the VNet.' Wrong. Overlap causes routing conflicts.
'Basic SKU supports IKEv2 and RADIUS.' Wrong. Basic supports only SSTP and certificate auth.
'For Azure AD auth, you need to upload a root certificate.' Wrong. Azure AD auth does not use certificates; it uses OIDC.
Key Numbers and Terms
Maximum root certificates: 20.
Maximum revoked certificates: 1000.
Maximum concurrent SSTP connections: 128 (all SKUs).
Maximum concurrent IKEv2 connections: Basic – 128, VpnGw1 – 250, VpnGw2 – 500, VpnGw3 – 1000.
GatewaySubnet minimum size: /27.
Client address pool: must be a private IP range not overlapping with VNet or on-premises.
Edge Cases
Forced tunneling: If enabled, all client traffic (including internet-bound) is routed through the VPN gateway to on-premises. This requires a default route (0.0.0.0/0) advertised via S2S or ExpressRoute.
Multi-factor Authentication: Only supported with Azure AD authentication.
Certificate-based auth with IKEv2: The client certificate must have the Client Authentication EKU (1.3.6.1.5.5.7.3.2).
How to Eliminate Wrong Answers
If the question mentions 'MFA' or 'Azure AD', eliminate options that require certificate upload.
If the question asks about 'maximum clients', check the SKU and protocol.
If the question mentions 'BGP', it's likely a distractor for P2S.
If the question says 'overlapping address space', that's a misconfiguration.
P2S VPN allows individual clients to securely connect to an Azure VNet over the internet.
Three authentication methods: certificate-based, Azure AD (recommended), and RADIUS.
SSTP uses TCP 443; IKEv2 uses UDP 500/4500. IKEv2 supports more concurrent connections.
Basic SKU does not support IKEv2, RADIUS, or BGP.
Client address pool must be a private IP range not overlapping with VNet or on-premises.
Maximum concurrent connections: SSTP 128 (all SKUs), IKEv2 up to 1000 (VpnGw3).
P2S can coexist with S2S on the same VPN gateway.
For Azure AD authentication, use the Azure VPN Client app.
These come up on the exam all the time. Here's how to tell them apart.
Point-to-Site (P2S) VPN
Connects individual clients (e.g., laptops) to Azure VNet.
Uses SSTP (TCP 443) or IKEv2 (UDP 500/4500).
No on-premises VPN device required.
Client address pool must not overlap with VNet.
Supports Azure AD, certificate, or RADIUS authentication.
Site-to-Site (S2S) VPN
Connects entire networks (e.g., on-premises datacenter) to Azure VNet.
Uses IPsec (IKEv1 or IKEv2) over UDP 500/4500.
Requires an on-premises VPN device with a public IP.
No client address pool; uses IPsec tunnel with network prefixes.
Supports pre-shared key or certificate authentication. BGP supported.
Mistake
P2S VPN requires a static public IP on the client.
Correct
The client can be behind NAT or have a dynamic IP. The Azure VPN gateway has a static public IP that clients connect to.
Mistake
P2S VPN supports BGP for dynamic routing.
Correct
BGP is not supported for P2S connections. Only static routes are used (the default route to the VNet).
Mistake
You can use the same IP address range for the client address pool as the VNet.
Correct
The client address pool must not overlap with the VNet address space or any connected on-premises networks to avoid routing conflicts.
Mistake
The Basic VPN gateway SKU supports IKEv2 and RADIUS authentication.
Correct
The Basic SKU supports only SSTP and certificate-based authentication. IKEv2 and RADIUS require at least VpnGw1.
Mistake
Azure AD authentication for P2S requires uploading a root certificate.
Correct
Azure AD authentication uses OpenID Connect and does not require certificates. Certificate upload is only for certificate-based authentication.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, a VPN gateway is required. The gateway is a managed service that handles tunnel termination and authentication. Without it, there is no endpoint for clients to connect to.
SSTP uses TCP port 443 and can traverse most firewalls, but is limited to 128 concurrent connections. IKEv2 uses UDP 500/4500 and supports up to 1000 connections (depending on SKU), and is more resilient to network changes. IKEv2 is preferred for higher scale.
In the Azure portal, go to the VPN gateway's Point-to-site configuration, add the certificate thumbprint to the revoked certificates list. The gateway will reject connections from that certificate. You can also use Azure CLI: 'az network vnet-gateway revoked-cert create'.
No, Azure AD authentication requires the Azure VPN Client app. The native Windows VPN client only supports certificate-based or RADIUS authentication.
Yes, forced tunneling can be configured to route all client traffic through the VPN gateway to on-premises. This requires a default route (0.0.0.0/0) to be advertised via S2S or ExpressRoute.
Clients will experience routing conflicts and may not be able to reach VNet resources. The pool must be a unique private IP range that does not overlap with any connected network.
Up to 20 root certificates can be uploaded per VPN gateway. Each root certificate can issue many client certificates.
You've just covered Point-to-Site VPN Gateway — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?