Skip to main content
Site-to-site VPN connections create a secure, persistent IPsec/IKE tunnel between an on‑premises network and an Azure Virtual Network (VNet). This guide covers the architecture, planning checklist, and a step‑by‑step deployment flow in Azure plus basic on‑premises configuration and verification. From an architectural perspective, an on‑premises VPN device (firewall/router) establishes an IPsec/IKE tunnel over the Internet to an Azure VPN Gateway. Azure hosts the VPN Gateway inside a dedicated GatewaySubnet; the VNet contains the remaining subnets for management, jumpboxes, and application workloads.
A network diagram titled "Site-to-Site Connections" showing an on‑premises gateway connecting over the Internet to an Azure Virtual Network VPN gateway. The Azure side contains a gateway subnet, management subnet (with a jumpbox) and several VMs.

​
Planning checklist

Plan these items before deploying a site-to-site VPN. Proper planning reduces downtime and avoids common pitfalls such as routing conflicts or insufficient throughput.
ConsiderationWhat to decideWhy it matters
Address spacesEnsure Azure VNet and on‑premises networks do NOT overlap (e.g., Azure: 10.1.0.0/16, On‑Prem: 192.168.3.0/24)Overlapping prefixes will prevent correct routing across the VPN.
Gateway SKU & performanceChoose a VPN Gateway SKU (VpnGw1, VpnGw2, VpnGw3, etc.) based on throughput, features (BGP, active/active) and SLA needsSKU determines supported bandwidth, concurrent tunnels, and feature availability.
Encryption & authenticationAgree on PSK, IKE version (IKEv2 recommended), encryption (AES‑256), integrity, DH group, and lifetimesIncompatible settings will prevent tunnel establishment; choose modern algorithms.
On‑prem device compatibilityVerify vendor model/OS is supported by Azure and can be configured with required IPsec/IKE parametersUnsupported devices may require a firmware upgrade or replacement.
High availability & routingDecide active/active or active/standby gateways, and whether to use BGP or static routesHA and routing affect failover behavior and route distribution.
Compliance & key managementEnsure encryption, logging, and key handling meet regulatory obligationsData‑in‑transit requirements (e.g., FIPS, audit logs) may mandate specific controls.
Post‑deployment testingDefine verification steps and monitoring (ping tests, TCP tests, Network Watcher, VPN logs)Confirms tunnel stability and correct traffic flows after setup.
Overlapping IP address ranges between Azure and on‑premises will break routing. Always plan and validate address prefixes before creating VNets or Local Network Gateways.
Use strong pre-shared keys (PSKs), modern encryption (AES‑256 where possible), and IKEv2 (preferred). Ensure both sides match on encryption, integrity, Diffie‑Hellman group, and SA lifetimes. Avoid weak or default keys and document configuration for future troubleshooting.

​
High-level setup steps

Typical sequence for deploying a site-to-site VPN:
  1. Create the Azure VNet and required subnets for workloads.
  2. Create a GatewaySubnet named exactly “GatewaySubnet” and allocate an appropriate range (recommended /27 or larger depending on gateway SKU).
  3. Provision the VPN Gateway in the GatewaySubnet (select the VPN gateway SKU and type: RouteBased for most modern scenarios).
  4. Create a Local Network Gateway (LNG) in Azure that represents your on‑premises public IP/FQDN and on‑premises address prefixes.
  5. Configure the on‑premises VPN device with the Azure VPN Gateway public IP, shared key, and matching IPsec/IKE parameters.
  6. Create the site‑to‑site VPN connection in Azure linking the VPN Gateway and the LNG (specify PSK and BGP if used).
  7. Verify tunnel status and test connectivity between Azure VMs and on‑premises hosts. Monitor and adjust as needed.
The diagram below maps these steps to Azure and on‑prem components and shows their deployment order.
A slide titled "Site-to-Site Connections" showing a step-by-step flow for setting up an Azure VPN: create VNets/subnets, (optional) DNS server, gateway subnet, VPN gateway, local network gateway, configure the on‑prem VPN device, and create the VPN connection. The diagram highlights Azure and on‑prem components and their order in the setup.

​
Example Azure CLI commands (illustrative)

The following az CLI examples demonstrate one common deployment flow. Replace resource names, prefixes, locations, and the PSK with values for your environment. Create a resource group: 
az group create --name MyResourceGroup --location eastus
Create a VNet and a GatewaySubnet (GatewaySubnet name is required): 
az network vnet create \
  --resource-group MyResourceGroup \
  --name MyVNet \
  --address-prefix 10.1.0.0/16 \
  --subnet-name Workloads \
  --subnet-prefix 10.1.1.0/24

az network vnet subnet create \
  --resource-group MyResourceGroup \
  --vnet-name MyVNet \
  --name GatewaySubnet \
  --address-prefix 10.1.255.0/27
Create a public IP for the VPN Gateway: 
az network public-ip create \
  --resource-group MyResourceGroup \
  --name MyVpnGatewayPIP \
  --sku Standard
Create the VPN Gateway (RouteBased, choose sku like VpnGw1/VpnGw2): 
az network vnet-gateway create \
  --resource-group MyResourceGroup \
  --name MyVpnGateway \
  --public-ip-address MyVpnGatewayPIP \
  --vnet MyVNet \
  --gateway-type Vpn \
  --vpn-type RouteBased \
  --sku VpnGw1 \
  --no-wait
Create a Local Network Gateway that represents your on‑premises device (example: public IP 33.2.1.5, on‑prem subnet 192.168.3.0/24): 
az network local-gateway create \
  --resource-group MyResourceGroup \
  --name OnPrem-LNG \
  --gateway-ip-address 33.2.1.5 \
  --local-address-prefixes 192.168.3.0/24
Create the site-to-site VPN connection (replace ‘YourPresharedKeyHere’): 
az network vpn-connection create \
  --resource-group MyResourceGroup \
  --name S2S-Connection \
  --vnet-gateway1 MyVpnGateway \
  --local-gateway2 OnPrem-LNG \
  --shared-key 'YourPresharedKeyHere'
Note: If you use BGP, add —enable-bgp true and provide appropriate ASN configuration on both sides.

​
Local Network Gateway (LNG)

A Local Network Gateway (LNG) is a logical Azure object that represents your on‑premises VPN endpoint and its reachable address prefixes. It contains:
  • The public IP address (or FQDN) of the on‑premises VPN device.
  • The on‑premises IP address ranges that Azure should route to the LNG.
Create one LNG per remote site/data center. For multiple branch offices, create multiple LNG objects and multiple corresponding VPN connections (or use active/active gateways with BGP where appropriate). Example: if your on‑premises public IP is 33.2.1.5 and the local network is 192.168.3.0/24, create an LNG in Azure using those values (see CLI example above).
A presentation slide titled "Creating LNG" showing the Azure "Create local network gateway" form with example values (Name VNet1LocalNet, IP address 33.2.1.5, address space 192.168.3.0/24). The right side contains explanatory boxes about purpose, public IP requirement, on‑premises address space, and multiple sites support.
After creating the VNet, GatewaySubnet, VPN Gateway, and LNG:
  1. Configure your on‑premises VPN device with:
    • Azure VPN Gateway public IP
    • The agreed pre‑shared key
    • Matching IPsec/IKE parameters (algorithms, DH group, lifetimes)
  2. Create the site‑to‑site connection in Azure (if not created already).
  3. Verify that the tunnel establishes and routes traffic correctly.

​
Post-deployment verification and monitoring

Verify connection and troubleshoot using the az CLI: Check connection status: 
az network vpn-connection show \
  --resource-group MyResourceGroup \
  --name S2S-Connection \
  --query "connectionStatus"
List VPN connections and inspect diagnostics: 
az network vpn-connection list --resource-group MyResourceGroup
az network vnet-gateway show --resource-group MyResourceGroup --name MyVpnGateway
Use Azure Network Watcher and VPN Gateway diagnostic logs for deeper troubleshooting. Validate end‑to‑end connectivity by testing from an Azure VM to an on‑premises host (ICMP/ping, TCP port tests) and confirm expected routing via effective routes and NSG evaluation. Use these resources to align device-specific configuration (vendor commands) with Azure settings and for advanced scenarios like active/active gateways, BGP, and VNet-to-VNet connections.

Watch Video