Connect an Azure virtual network to a VPNGeek gateway over a route-based IKEv2 VPN — VNet gateway, local network gateway, connection with a custom IPsec/IKE policy, end to end.
This guide connects an Azure virtual network (VNet) to a VPNGeek gateway with a route-based IKEv2 IPsec VPN. On the Azure side you create a VPN gateway in the VNet's GatewaySubnet, describe the VPNGeek side as a local network gateway, then join the two with a connection that carries a shared key and a custom IPsec/IKE policy. Route-based (the default for modern Azure VPN gateways) means selectors are wildcarded and routing decides what enters the tunnel — the cleaner match for a VPNGeek gateway. When you finish, the VNet and the VPNGeek side reach each other over an encrypted link.
Before you start
Collect the following before you touch either side. Azure VPN gateway deployment alone takes 20–45 minutes, so start it early.
- A VPNGeek plan that includes IPsec Gateways, with a static public IP on the gateway.
- An Azure subscription with rights to create network resources, and the Azure CLI (
az) logged in, or the portal. - An existing VNet with address space 10.100.0.0/16 (example) and room for a dedicated
GatewaySubnetof at least /27. - Non-overlapping CIDRs — VNet 10.100.0.0/16 vs the VPNGeek side 10.20.0.0/16.
- A strong shared key (pre-shared key) you generate now and use on both sides.
1. Create the GatewaySubnet and public IP
The VPN gateway must live in a subnet named exactly GatewaySubnet. It also needs a Standard-SKU static public IP for the tunnel endpoint.
az network vnet subnet create \
--resource-group vpngeek-rg \
--vnet-name vpngeek-vnet \
--name GatewaySubnet \
--address-prefixes 10.100.255.0/27
# Static Standard public IP for the gateway
az network public-ip create \
--resource-group vpngeek-rg \
--name vpngeek-vpngw-pip \
--sku Standard --allocation-method Static
2. Create the VPN gateway
Deploy a route-based (--vpn-type RouteBased) VPN gateway. Use a VpnGw2 SKU or higher for IKEv2 and custom-policy support. This step provisions Azure infrastructure and can take 30–45 minutes.
--resource-group vpngeek-rg \
--name vpngeek-vpngw \
--vnet vpngeek-vnet \
--public-ip-addresses vpngeek-vpngw-pip \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw2 \
--no-wait
# Note the gateway's public IP once provisioned — this is
# the peer address you enter on the VPNGeek side:
az network public-ip show \
--resource-group vpngeek-rg --name vpngeek-vpngw-pip \
--query ipAddress -o tsv
3. Create the local network gateway
The local network gateway represents the VPNGeek side: its public IP and the CIDR(s) reachable behind it. With route-based / static routing you list the VPNGeek subnets here; for BGP you would instead set --asn and --bgp-peering-address.
--resource-group vpngeek-rg \
--name vpngeek-lng \
--gateway-ip-address 203.0.113.10 \
--local-address-prefixes 10.20.0.0/16
4. Create the connection with a custom IPsec/IKE policy
Join the VPN gateway and the local network gateway with an IKEv2 connection. Azure's default policy set is broad; pinning a custom policy guarantees both sides agree on exactly one proposal, which is the most reliable way to interop with a VPNGeek gateway.
--resource-group vpngeek-rg \
--name vpngeek-conn \
--vnet-gateway1 vpngeek-vpngw \
--local-gateway2 vpngeek-lng \
--shared-key '<your-shared-key>' \
--connection-protocol IKEv2
# Pin one exact proposal (phase 1 + phase 2) on the connection
az network vpn-connection ipsec-policy add \
--resource-group vpngeek-rg \
--connection-name vpngeek-conn \
--ike-encryption AES256 --ike-integrity SHA256 \
--dh-group DHGroup14 \
--ipsec-encryption AES256 --ipsec-integrity SHA256 \
--pfs-group PFS14 \
--sa-lifetime 27000 --sa-max-size 102400000
5. Configure the VPNGeek side
In the dashboard open Gateways > Tunnels and add a tunnel to the Azure VPN gateway's public IP. Force IKE version 2, mirror the custom policy from step 4 exactly, and paste the same shared key.
ike_version: 2
proposal: aes256-sha256 # matches AES256/SHA256
dh_group: 14 # DHGroup14 / PFS14
pfs: enabled # Azure PFS-group set above
local_subnet: 10.20.0.0/16 # VPNGeek side
remote_subnet: 10.100.0.0/16 # Azure VNet address space
psk: <your-shared-key> # same key as the connection
6. Verify the connection
The connection should move to Connected on Azure and ESTABLISHED in the VPNGeek dashboard within a minute or two. Check the status, then send real traffic from an Azure VM to a host on the VPNGeek side.
az network vpn-connection show \
--resource-group vpngeek-rg --name vpngeek-conn \
--query '{status:connectionStatus,in:ingressBytesTransferred,out:egressBytesTransferred}'
# From an Azure VM in the VNet:
ping 10.20.0.1
# Confirm the VM's NSG allows traffic to/from 10.20.0.0/16
# before assuming the tunnel is at fault.
Troubleshooting
Stuck in Connecting
Usually a shared-key mismatch or a policy that does not agree. Because you pinned a custom IPsec/IKE policy, both sides must match it byte for byte — AES256, SHA256, DHGroup14, PFS14, IKEv2. Re-check the VPNGeek proposal, DH group, and that PFS is enabled.
Connected but no traffic
Missing prefixes on the local network gateway, a VNet subnet whose route table (UDR) diverts traffic, or an NSG blocking it. Confirm 10.20.0.0/16 is listed on the local network gateway and reachable from the VM subnet.
Policy-based vs route-based confusion
A route-based gateway (VpnGw SKUs) is required for IKEv2 and custom policies. A policy-based (Basic SKU) gateway only supports IKEv1 and a single traffic selector — if you deployed Basic, recreate the gateway as RouteBased.
Tunnel rekeys/drops periodically
Align the SA lifetime. The example sets 27000 seconds on Azure; set a matching key lifetime on the VPNGeek side so neither peer forces an early rekey.