Skip to main content
Welcome to the module: Connecting Networks with Site-to-Site VPN Connections. This lesson explains what site-to-site (S2S) VPNs are, when to use them, and how to configure them end-to-end in Azure. You’ll see the Azure-side resources and the typical on‑premises configuration items required so you can set up a practical hybrid network connection. Learning objectives
  • Understand what a site-to-site VPN connection is and how it works.
  • Learn when to use a site-to-site VPN versus other connectivity options.
  • Walk through the Azure-side configuration and the corresponding on‑premises settings necessary to establish an IPsec/IKE tunnel.
A site-to-site VPN securely connects two networks over the public internet—for example, an on‑premises datacenter and an Azure virtual network (VNet). The connection uses an encrypted IPsec/IKE tunnel so that traffic traversing public infrastructure remains confidential and tamper‑resistant. Typically one endpoint is an Azure VPN gateway and the other is a physical VPN device or a compatible virtual appliance in your on‑premises environment. Key terms
  • VPN gateway: An Azure-managed gateway resource that terminates VPN tunnels.
  • Local network gateway: An Azure object that represents your on‑premises VPN device and address prefixes.
  • Connection: The Azure resource that ties the VPN gateway to the local network gateway and holds the shared key and connection type.
Site-to-site VPNs are ideal when:
  • You need persistent network connectivity between two networks (VNet ↔ on‑premises) without requiring each client to connect individually.
  • You want to extend on‑premises addressing to Azure for hybrid applications and management workflows.
  • You need a cost-effective solution for lower-to-moderate throughput requirements where ExpressRoute (private peering) isn’t needed.
Comparison: site-to-site VPN vs point-to-site vs ExpressRoute
Resource TypeUse CaseTypical Example
Site-to-site VPNPersistent network-to-network tunnel over internetConnect datacenter to Azure VNet
Point-to-site VPNIndividual client/dev machine remote accessRemote worker connecting to Azure VNet
ExpressRoutePrivate, high-throughput connection (carrier/partner)Data replication, low-latency workloads
On the Azure side:
  • Virtual Network (VNet) with appropriate address space and subnets.
  • Public IP address for the VPN gateway.
  • VPN gateway (route-based) to terminate the IPsec/IKE tunnel.
  • Local network gateway representing your on‑premises public IP and address prefixes.
  • Connection resource (site-to-site) containing the shared key and linking the gateways.
On the on‑premises side:
  • A compatible VPN device (physical or virtual) configured to establish an IPsec/IKE connection with parameters that match the Azure gateway: shared key, IKE version and algorithms, encryption/hashing algorithms, IP addressing, and the correct gateway type (route-based vs policy-based).
Table: Azure resources and example Azure CLI commands
ResourcePurposeAzure CLI example
Virtual networkHost subnets and VMsaz network vnet create --name MyVNet --resource-group MyRG --address-prefix 10.0.0.0/16 --subnet-name GatewaySubnet --subnet-prefix 10.0.0.0/24
Public IPExternally routable IP for VPN gatewayaz network public-ip create --name MyVnetGatewayIP --resource-group MyRG --allocation-method Dynamic
VPN gatewayTerminates S2S tunnelsaz network vnet-gateway create --name MyVpnGateway --resource-group MyRG --vnet MyVNet --public-ip-address MyVnetGatewayIP --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-wait
Local network gatewayRepresents on‑premises networkaz network local-gateway create --name MyLocalGateway --resource-group MyRG --gateway-ip-address <ONPREM_PUBLIC_IP> --local-address-prefixes 192.168.1.0/24
ConnectionBinds Azure gateway to local gatewayaz network vpn-connection create --name MyConnection --resource-group MyRG --vnet-gateway1 MyVpnGateway --local-gateway2 MyLocalGateway --shared-key "YourSharedKey123!"
Example: minimal Azure CLI sequence 
# Create VNet and Gateway subnet
az network vnet create \
  --resource-group MyRG \
  --name MyVNet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name GatewaySubnet \
  --subnet-prefix 10.0.0.0/24

# Create a public IP for the VPN gateway
az network public-ip create \
  --resource-group MyRG \
  --name MyVpnPublicIP \
  --allocation-method Dynamic

# Create the VPN gateway (this can take 20-45 minutes)
az network vnet-gateway create \
  --resource-group MyRG \
  --name MyVpnGateway \
  --public-ip-address MyVpnPublicIP \
  --vnet MyVNet \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1

# Create a local network gateway representing on-prem
az network local-gateway create \
  --resource-group MyRG \
  --name MyOnPremGateway \
  --gateway-ip-address 203.0.113.12 \
  --local-address-prefixes 192.168.1.0/24

# Create the site-to-site connection with a shared key
az network vpn-connection create \
  --resource-group MyRG \
  --name MyS2SConnection \
  --vnet-gateway1 MyVpnGateway \
  --local-gateway2 MyOnPremGateway \
  --shared-key "YourSharedKey123!"
  • Ensure your device supports the IPsec/IKE versions and encryption algorithms you plan to use.
  • Match the Azure connection parameters exactly: shared key, IKE version, encryption/hashing algorithms, and any DH/PFS settings required.
  • Use route-based (required by many Azure scenarios) or policy-based gateways only when the on‑premises device and Azure gateway types are compatible.
Plan your address spaces and routing before creating resources. Avoid overlapping IP ranges between on‑premises and Azure VNets; if overlap is unavoidable, consider NAT or redesigning subnets to prevent routing conflicts.
  • IKE version: IKEv2 is recommended where supported.
  • Encryption: AES-256 (or AES-128 for legacy devices).
  • Integrity: SHA-256 (or SHA-1 for legacy compatibility).
  • Diffie-Hellman: Group 14 (2048-bit) or higher where possible.
  • PFS: Enable if both sides support it.
Always verify your device’s supported proposals and configure the Azure connection to match.
Do not assume default device settings will match Azure’s configuration. Mismatched proposals (IKE version, encryption, hash, DH groups) are the most common causes of failed tunnel negotiations.
By the end of this lesson you should be able to decide when S2S VPN is the right fit, construct the Azure components, and configure the on‑premises device to establish a secure IPsec/IKE tunnel to an Azure VNet.

Watch Video