Skip to main content
In this guide you’ll learn how to establish a site-to-site (S2S) IPsec/IKE VPN tunnel between an on-premises network and Azure. The example below uses an Azure VNet with address space 10.1.0.0/16 and an on-premises branch network 10.0.0.0/24 — ensure your networks do not overlap. The Azure VPN Gateway terminates the tunnel to your on-premises edge device’s public static IP and authenticates using a pre-shared key (PSK).
A diagram showing an on-premises site-to-site VPN setup connecting a local network gateway appliance (10.0.0.166) to an Azure virtual network and VPN gateway via an S2S tunnel, with IP addressing and Azure Files service endpoints. The right column lists configuration notes like device compatibility, route-based VPN, IPsec/IKE settings, use of a public IP, and a pre-shared key.
Quick architecture summary:
  • Azure VNet: 10.1.0.0/16
  • On-premises: 10.0.0.0/24
  • Tunnel: IPsec/IKE (site-to-site)
  • Authentication: PSK (pre-shared key)
  • On-premises device: reachable static public IP (entered as the Local Network Gateway)

​
Key considerations for the on-premises VPN device

ConsiderationDetails / Recommendation
Device compatibilityVerify your appliance or software against the Microsoft validated devices list. Many modern devices work with Azure if correctly configured.
Route-based vs policy-basedRoute-based VPNs are recommended for most scenarios (flexible, simpler to manage). Policy-based is supported only on certain gateway SKUs and use-cases.
IPsec / IKE parametersEnsure encryption, integrity/hash, DH group, lifetime, and IKE version match on both sides. Mismatches prevent negotiation.
Public IP reachabilityThe on-premises device must have a static public IP (or FQDN). Azure needs this value in the Local Network Gateway (LNG). Dynamic IPs may break the tunnel when they change.
Authentication (PSK)Use a strong PSK; configure the same key on both sides. Store the PSK securely.
Ensure the on-premises device uses a static public IP and that you store the PSK securely. If you must use dynamic addressing, consider alternatives such as certificate-based authentication or a dynamic DNS solution — each has operational implications.
If you need more detail about supported devices and configuration examples, see:

​
Quick checklist before creating the tunnel

  • No overlapping address spaces between Azure and on-premises.
  • On-premises device has a reachable static public IP.
  • PSK chosen and stored securely.
  • IPsec/IKE parameters planned (or default policy on both sides).
  • Routes and firewall rules prepared to allow traffic across the tunnel.

​
Creating the Site-to-Site connection in the Azure portal

  1. Open the Virtual Network Gateway resource that will terminate the Azure side of the tunnel.
  2. In the gateway blade, select Connections → Add.
  3. In the Create connection page:
    • Connection type: Site-to-site (IPsec).
    • Name: a descriptive name, e.g., site-to-site-Azure-to-NYC.
    • Virtual network gateway: (pre-selected when creating from the gateway blade).
    • Local network gateway: select an existing LNG that represents your on-premises device, or create one (instructions below).
    • Authentication type: Shared key (PSK). Enter the same PSK configured on the on-premises device.
    • Optional: enable BGP for dynamic routing or specify a custom IPsec/IKE policy for non-default crypto parameters.
  4. Click Review + create → Create. After creation, the connection will appear in the Connections list with status (Connected / Not connected).
A screenshot of the Microsoft Azure portal showing the "Create connection" Settings page for a virtual network gateway with fields for selecting first/second gateways, authentication method (Shared Key or Key Vault Certificate), Shared Key, IKE protocol, and other VPN options. Tabs (Basics, Settings, Tags, Review + create) and action buttons (Review + create, Previous, Next: Tags) are visible at the bottom.

​
Local Network Gateway (LNG) — what it is and how to create it

The Local Network Gateway is an Azure resource that stores:
  • The on-premises VPN device public IP (or FQDN)
  • The on-premises address prefixes (for routing)
  • Optional BGP ASN and peering information if you use BGP
Create an LNG via the portal:
  • Navigate to Local network gateways → Create.
  • Provide name (e.g., LNG-NYC), region, public IP or FQDN (e.g., 131.1.12.13) and on-premises address prefixes (e.g., 10.0.0.0/24).
  • Add BGP settings under Advanced if using dynamic routing.
Note: Azure stores the LNG metadata; it does not validate connectivity when the LNG is created. The Virtual Network Gateway references the LNG when building the connection. CLI example — create LNG: 
az network local-gateway create \
  --resource-group MyResourceGroup \
  --name LNG-NYC \
  --gateway-ip-address 131.1.12.13 \
  --local-address-prefixes 10.0.0.0/24
CLI example — create Site-to-Site VPN connection: 
az network vpn-connection create \
  --resource-group MyResourceGroup \
  --name site-to-site-Azure-to-NYC \
  --vnet-gateway1 MyVNetGateway \
  --local-gateway2 LNG-NYC \
  --shared-key "REPLACE_WITH_STRONG_PSK"
PowerShell alternative: 
New-AzLocalNetworkGateway -Name "LNG-NYC" -ResourceGroupName "MyResourceGroup" `
  -GatewayIpAddress "131.1.12.13" -AddressPrefix @("10.0.0.0/24")

New-AzVirtualNetworkGatewayConnection -Name "site-to-site-Azure-to-NYC" `
  -ResourceGroupName "MyResourceGroup" -Location "eastus" `
  -VirtualNetworkGateway1 $vnetGateway -LocalNetworkGateway2 $lng `
  -ConnectionType IPsec -RoutingWeight 10 -SharedKey "REPLACE_WITH_STRONG_PSK"

​
Route-based vs Policy-based — when to choose which

TypeWhen to useNotes
Route-basedMost common scenarios; supports dynamic routing (BGP) and multiple tunnelsRecommended for flexibility and simplicity
Policy-basedLimited scenarios, supported on certain gateway SKUsUseful when on-premises devices only support policy-based VPNs — verify SKU compatibility

​
VNet-to-VNet considerations

  • For VPN-based VNet-to-VNet connections, each VNet must have its own VPN Gateway. Each gateway terminates the respective tunnel.
  • This approach requires two gateways (and associated costs). Consider VNet peering (with gateway transit when necessary) if you do not need gateway-level isolation or cross-tenant VPN connectivity.

​
Verification and troubleshooting

After Azure connection creation and on-premises device configuration (peer IP, PSK, matching IPsec/IKE settings, and necessary routes):
  1. Check connection status in the Azure portal (Connections → connection name).
  2. From Azure VM, test connectivity to an on-premises host (ICMP/ping or application traffic). Be aware that:
    • ICMP may be blocked by NSGs or on-prem firewalls.
    • Ensure NSG and on-prem firewall rules allow the traffic and corresponding ports/protocols (e.g., TCP/UDP for your apps).
  3. If the tunnel does not connect:
    • Verify PSK, peer public IP, and IPsec/IKE parameters match exactly.
    • Check for NAT or firewall rules that may block IKE (UDP 500) or NAT-T (UDP 4500).
    • Review gateway diagnostics and on-premises device logs for negotiation errors.
Use these Azure docs for deep troubleshooting and parameter tuning:

​
Summary

By validating device compatibility, using a static public IP, matching PSK and IPsec/IKE settings, and creating a Local Network Gateway followed by a Site-to-Site connection in Azure, you can establish a reliable S2S VPN tunnel between your on-premises network and Azure. Later sections cover point-to-site connections and include a demo on enabling gateway transit.

Watch Video