3.3 Point-to-Site (P2S) VPN & Client Authentication

Point-to-Site (P2S) VPN enables individual client devices (laptops, workstations, mobile devices) to establish secure, encrypted connections to an Azure Virtual Network from remote locations across the public internet. Designing an enterprise P2S architecture requires selecting the appropriate tunneling protocol, planning non-overlapping address pools, enforcing identity-based authentication, and distributing client configurations.

---

1. P2S Tunneling Protocols Comparison

Azure VPN Gateway supports three distinct P2S VPN tunneling protocols, each tailored for specific operating systems, port requirements, and authentication mechanisms.

Protocol Comparison Matrix

[!TIP] AZ-700 Protocol Selection Rule:

• If the exam scenario mentions Microsoft Entra ID (Azure AD), Conditional Access, MFA via Authenticator App, or macOS/Linux support -> OpenVPN is required.
• If the scenario requires connecting Windows-only legacy machines across strict outbound proxies without third-party client software -> SSTP is used.
• If the scenario requires native OS integration on Windows/macOS/iOS with certificate authentication and minimal encryption overhead -> IKEv2 is selected.

---

2. Client Address Pool Planning & Routing Architecture

The Client Address Pool is a dedicated private IPv4 (or dual-stack IPv6) CIDR block configured on the Azure VPN Gateway. When remote users connect, Azure dynamically assigns an IP address from this pool to the client's virtual network adapter.

+---------------------------------------------------------------------------------------------------+
|                                 POINT-TO-SITE ROUTING ARCHITECTURE                                |
|                                                                                                   |
|  +---------------------------------------------------------------------------------------------+  |
|  | Remote Workers (P2S Client Address Pool: 172.16.200.0/24)                                  |  |
|  | User 1 (172.16.200.10) | User 2 (172.16.200.11) | User 3 (172.16.200.12)                   |  |
|  +----------------------------------------------+----------------------------------------------+  |
|                                                 | (Encrypted OpenVPN / TCP 443)                   |
|                                                 v                                                 |
|  +---------------------------------------------------------------------------------------------+  |
|  | Azure Hub VNet (10.100.0.0/16)                                                              |  |
|  |                                                                                             |  |
|  |  +---------------------------------------------------------------------------------------+  |  |
|  |  | GatewaySubnet (10.100.255.0/26)                                                        |  |  |
|  |  | [ Azure VPN Gateway ] <------------------ Dynamic P2S NAT / Route Injection           |  |  |
|  |  +---------------------------------------------------------------------------------------+  |  |
|  |         |                                                           |                       |  |
|  |         | (VNet Peering with Gateway Transit)                       | (S2S IPsec VPN)       |  |
|  |         v                                                           v                       |  |
|  |  +------------------------------+                  +-------------------------------------+  |  |
|  |  | Spoke VNet (10.200.0.0/16)   |                  | On-Premises Network (192.168.0.0/16)|  |  |
|  |  | [ Workload VMs ]             |                  | * CRITICAL: Must have return route  |  |  |
|  |  |                              |                  |   for 172.16.200.0/24 -> Azure VGW! |  |  |
|  |  +------------------------------+                  +-------------------------------------+  |  |
|  +---------------------------------------------------------------------------------------------+  |
+---------------------------------------------------------------------------------------------------+

Address Pool Design Constraints

1. No Overlapping Subnets: The Client Address Pool must never overlap with:
   • The host VNet address space (10.100.0.0/16).
   • Any peered VNets (10.200.0.0/16).
   • Any on-premises subnets connected via S2S VPN or ExpressRoute (192.168.0.0/16).
2. Subnet Sizing: Ensure the pool is large enough to accommodate peak concurrent remote workers. Azure assigns one IP per active tunnel. Sizing too small (e.g., /28 with only 16 addresses) causes connection rejections when the pool is exhausted.
3. On-Premises Return Routing: If P2S clients need to access on-premises networks across a co-existing S2S VPN tunnel or ExpressRoute circuit, the on-premises border routers must have a route for the P2S Client Address Pool pointing back to the Azure Gateway. If the on-premises router does not know how to return traffic to 172.16.200.0/24, packets will be dropped at the on-premises edge.
4. Gateway Transit: To access peered spoke VNets, the peering between Hub and Spoke must have AllowGatewayTransit enabled on the Hub and UseRemoteGateways enabled on the Spoke.

---

3. P2S Authentication Mechanisms Deep Dive

Azure VPN Gateway supports three enterprise authentication models for Point-to-Site connections.

1. Microsoft Entra ID Authentication

Microsoft Entra ID (formerly Azure AD) authentication represents modern cloud identity management for remote access.

• Prerequisites: VPN Gateway must use the Route-Based model with OpenVPN protocol enabled. Requires the Azure VPN Client app on Windows, macOS, or Linux.
• Gateway Configuration Parameters:
  • Tenant: https://login.microsoftonline.com/<Directory-ID>/
  • Audience: Microsoft Azure VPN enterprise app client ID (c632b343-424a-4467-aa62-28c46726210f for Azure Public Cloud).
  • Issuer: https://sts.windows.net/<Directory-ID>/
• Conditional Access Integration: Administrators can enforce enterprise Conditional Access policies, including mandatory Microsoft Entra Multifactor Authentication (MFA), compliant/managed device requirements (via Microsoft Intune), and sign-in risk evaluation.

2. Azure Certificate Authentication

Uses X.509 digital certificates to authenticate client endpoints.

• Root Certificate: Upload the public key certificate file (.cer) encoded in Base-64 X.509 (.CER) format to the Azure VPN Gateway configuration. You can upload up to 20 root certificates.
• Client (Child) Certificate: Generated from the Root Certificate. Must be installed with its private key (.pfx file) in the client computer's Personal Certificate Store (CurrentUser\My).
• Revocation: To immediately revoke access for a compromised device, add the certificate's thumbprint to the Azure VPN Gateway Revocation List, or delete the Root Certificate if retiring an entire CA chain.

3. RADIUS Authentication

Enables integration with existing enterprise identity infrastructure (e.g., Active Directory Domain Services via Network Policy Server - NPS).

• Architecture: The Azure VPN Gateway acts as a RADIUS client, forwarding authentication packets to a primary (and optional secondary) RADIUS server IP address over UDP port 1812 using a shared secret.
• MFA Extension: Installing the Network Policy Server (NPS) Extension for Microsoft Entra MFA on the on-premises NPS server enables multi-factor authentication push notifications to users' phones during P2S authentication.

---

4. Azure VPN Client Configuration & Profile Distribution

When using OpenVPN with Microsoft Entra ID or certificate authentication, client devices connect using the Azure VPN Client application.

Profile Package Files

Downloading the VPN client profile package from the Azure Portal or Azure CLI (az network vnet-gateway vpn-client generate) produces an archive containing configuration artifacts:

• azurevpnconfig.xml: The primary XML configuration profile consumed by the Azure VPN Client.
• Generic/: Contains PBK and batch script files for native Windows SSTP/IKEv2 connections.

Customizing azurevpnconfig.xml

Network administrators can modify the XML configuration before distributing it to end users via Microsoft Intune or Group Policy:

<azvpnprofile>
  <clientconfig>
    <!-- Microsoft Entra ID Tenant Settings -->
    <tenant>https://login.microsoftonline.com/72f988bf-86f1-41af-91ab-2d7cd011db47/</tenant>
    <audience>c632b343-424a-4467-aa62-28c46726210f</audience>
    <issuer>https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/</issuer>
  </clientconfig>
  <!-- Custom Route Injection (Forced Tunneling / On-Prem Routing) -->
  <includeroutes>
    <route>
      <destination>192.168.0.0</destination>
      <mask>16</mask>
    </route>
    <route>
      <destination>0.0.0.0</destination>
      <mask>0</mask>
    </route>
  </includeroutes>
  <!-- Private DNS Suffix and Custom DNS Resolution -->
  <dnsservers>
    <dnsserver>10.100.254.4</dnsserver>
  </dnsservers>
  <dnssuffixes>
    <dnssuffix>.corp.contoso.com</dnssuffix>
  </dnssuffixes>
</azvpnprofile>

Split Tunneling vs. Forced Tunneling

• Split Tunneling (Default): Azure only pushes routes for the VNet and peered address spaces. Internet-bound client traffic exits directly via the user's local ISP.
• Forced Tunneling: Adding a route for 0.0.0.0/0 under <includeroutes> forces all client internet traffic through the Azure VPN Gateway to be inspected by an Azure Firewall or centralized security appliance before egressing.