Skip to main content
This lesson clarifies the differences between Azure site-to-site (S2S) and point-to-site (P2S) VPN connections, describes the components involved, and provides practical configuration steps and examples. Use this as a concise reference when planning or troubleshooting VPN connectivity between on-premises networks, remote clients, and Azure virtual networks (VNets).

​
Why this matters

  • S2S: Connects entire networks (on-premises <=> Azure VNet) for hybrid networking, branch connectivity, or data center extension.
  • P2S: Connects individual devices (laptops, workstations) to a VNet for remote access and administrative tasks.
For full reference, see the Azure VPN Gateway documentation: Azure VPN Gateway overview.

​
Site-to-Site (S2S) VPN

A site-to-site connection uses an IPsec/IKE tunnel between an on-premises VPN device and an Azure Virtual Network Gateway. Once established, the two networks communicate as if they were on the same local network. Key components and what they do:
  • GatewaySubnet — a dedicated subnet in your VNet that hosts the Azure Virtual Network Gateway. It must be named exactly GatewaySubnet.
  • Azure VPN Gateway (Virtual Network Gateway) — the Azure resource that terminates IPsec/IKE tunnels, performs encryption/decryption, and manages BGP if enabled.
  • Local Network Gateway — an Azure configuration object that stores the on-premises VPN device public IP (or FQDN) and the on-premises address prefixes.
  • On-premises VPN device — physical or virtual appliance configured to match the IPsec/IKE settings used by the Azure VPN gateway.
  • Connection resource — binds the Azure VPN Gateway to the Local Network Gateway and contains the shared key (PSK) and connection options (e.g., BGP).
The GatewaySubnet must be named exactly GatewaySubnet and must have an address range large enough for the gateway SKU you plan to deploy. If you size it too small the gateway deployment will fail.
Recommended S2S setup flow:
  1. Create the VNet and add a GatewaySubnet.
  2. Deploy the Virtual Network Gateway in the GatewaySubnet. Note: gateway provisioning typically takes 20–45 minutes.
  3. Create a Local Network Gateway in Azure with the on-premises VPN device public IP (or FQDN) and the on-premises address prefixes.
  4. Create a Connection resource that references the Virtual Network Gateway and the Local Network Gateway. Configure the pre-shared key (PSK), and optionally enable BGP or specify IKE/IPsec parameters.
  5. Configure the on-premises VPN device with matching PSK and IPsec/IKE settings so the tunnel can establish.
A diagram titled "Site-to-Site Connection" illustrating a linear network flow for a VPN link. It shows the Gateway Subnet, VPN Gateway, Local Network Gateway, and an On-Premises VPN Device connected to a site-to-site endpoint.
Portal configuration notes:
  • When creating a Connection in the Azure portal, choose connection type (for S2S choose Site-to-Site (IPsec)), the Virtual Network Gateway, the Local Network Gateway, and specify the shared key (PSK).
  • You can enable BGP and configure advanced options on the Connection blade.
A screenshot of the Microsoft Azure portal on the "Create connection" page for a virtual network gateway, showing fields for Virtual network gateway, Local network gateway, Shared key (PSK), IKE protocol and other connection options. The bottom shows navigation buttons like "Review + create" and "Next: Tags."
The Local Network Gateway is a simple configuration object: give it a name (for example, on-prem-cisco), set the endpoint (public IP or FQDN) of your on-premises VPN device, and list the on-premises address space (one or more prefixes) that Azure should route to that device.
A screenshot of the Microsoft Azure portal on the "Create local network gateway" page, showing a form with project and instance details (Subscription, Resource group, Region set to East US, Name set to "on-prem-cisco"). The form includes options for Endpoint (IP address/FQDN), IP address entry, and an "Add additional address range" field.
Example Azure CLI commands (common pattern):
  • Create a Local Network Gateway:
  • Create a VPN connection (S2S) tying the VNet gateway to the Local Network Gateway:
Troubleshooting checklist:
  • Confirm GatewaySubnet exists and is correctly sized.
  • Ensure PSK and IKE/IPsec proposals match on both ends.
  • Verify routes: check on-premises device and Azure UDRs/route tables.
  • Check Network Security Group (NSG) or VM firewall rules that might block traffic.
  • Use Azure portal connection diagnostics and on-premises device logs.

​
Point-to-Site (P2S) VPN

A point-to-site connection enables individual client devices to establish an encrypted VPN session to an Azure VNet. This is ideal for remote administrators, developers, or contractors who need secure on-demand access. High-level P2S configuration steps:
  1. Confirm you have a VNet with a GatewaySubnet and a deployed VPN gateway.
  2. Open the VPN gateway’s Point-to-site configuration and define:
    • Client IP address pool — the IP range allocated to connecting clients (must not overlap existing networks).
    • Tunnel types — choose from IKEv2, OpenVPN, SSTP (Windows), or combinations that meet client OS requirements.
    • Authentication method — certificates, RADIUS, or Microsoft Entra ID (Azure AD).
  3. Configure authentication:
    • Certificates: upload root certificate public key to Azure and install client certificates on devices.
    • RADIUS: point to a RADIUS server that validates username/password.
    • Microsoft Entra ID: register apps and provide tenant and app details (tenant ID, audience, issuer).
  4. Generate/upload certificates or configure RADIUS/AAD as required, then download the VPN client package from the Azure portal.
  5. Install the client package (or Azure VPN Client from Microsoft Store for Windows), import client certificates where required, and connect.
A simple diagram titled "Point-to-Site Connection" showing a horizontal workflow with icons and labels for Gateway Subnet, VPN Gateway, P2S Configuration, Download, and Connect. It visually represents the steps to set up a point-to-site VPN connection.
Portal notes:
  • The Point-to-site configuration blade lets you set the address pool, choose tunnel protocols (OpenVPN, IKEv2, SSTP), and configure authentication.
  • For Microsoft Entra ID authentication, provide tenant information and client app details as required by the Azure docs: Point-to-site VPN overview.
A screenshot of the Microsoft Azure portal open to a virtual network gateway's "vpn-prod-demo | Point-to-site configuration" page. The form shows settings like Address pool, Tunnel type (OpenVPN SSL), and Azure Active Directory authentication with empty Tenant/Audience/Issuer fields flagged by validation errors.
After the client is installed and certificates or Azure AD login are set up, the client obtains an IP from the client pool and can access resources in the VNet subject to NSG and VM firewall rules.
If you use certificate-based authentication, protect the root and client private keys. Do not distribute client private keys publicly and follow your organization’s certificate management policies.

​
Comparison: Site-to-Site vs Point-to-Site

​
Quick Checklist before you start

  • Create GatewaySubnet and ensure adequate size for gateway SKU.
  • Reserve a client IP pool (for P2S) that does not overlap your on-premises or VNet ranges.
  • Choose authentication method early (certs vs RADIUS vs Azure AD).
  • Prepare on-premises device configuration (matching PSK and IPsec settings) before creating the Connection.
  • Allow time for VPN gateway provisioning (20–45 minutes).
Common terms to search while troubleshooting: GatewaySubnet, Virtual Network Gateway, Local Network Gateway, vpn-connection diagnostics, and Azure VPN logs.

​
Summary

  • Site-to-site (S2S) VPNs connect an entire on-premises network to an Azure VNet via an IPsec/IKE tunnel using a Virtual Network Gateway and a Local Network Gateway object in Azure.
  • Point-to-site (P2S) VPNs connect individual devices to a VNet using client packages and certificate/RADIUS/Azure AD authentication.
  • Both require a correctly named and sized GatewaySubnet and a deployed Virtual Network Gateway. Azure configuration must be mirrored by the peer device or client to establish the tunnels.
  • These patterns underpin hybrid connectivity scenarios such as hub-and-spoke, gateway transit, and multi-site topology.
Further reading and references:

Watch Video