This article helps you configure an Azure route-based VPN gateway to connect to the Digi on-premises policy-based VPN device leveraging custom IPsec/IKEv2 policies on S2S VPN connections.
About policy-based and route-based VPN gateways
Policy-based vs. route-based VPN devices differ in how the IPsec traffic selectors are set on a connection:
- Policy-based VPN devices use the combinations of prefixes from both networks to define how traffic is encrypted/decrypted through IPsec tunnels. It's typically built on firewall devices that perform packet filtering. IPsec tunnel encryption and decryption are added to the packet filtering and processing engine.
- Route-based VPN devices use any-to-any (wildcard) traffic selectors, and let routing/forwarding tables direct traffic to different IPsec tunnels. It's typically built on router platforms where each IPsec tunnel is modeled as a network interface or VTI (virtual tunnel interface).
Currently, Azure supports both modes of VPN gateways: route-based VPN gateways and policy-based VPN gateways.
Digi DAL based devices now support Policy-based gateways and GRE Route-based VPN. Azure does not support GRE tunnel interfaces. To make a policy-based VPN connection in Azure using a route-based VPN gateway, configure the route-based VPN gateway to use prefix-based traffic selectors with the option "PolicyBasedTrafficSelectors".
Considerations
To enable this connectivity, your on-premises policy-based VPN device must support IKEv2 to connect to the Azure route-based VPN gateways.
The on-premises networks connecting through policy-based VPN devices with this mechanism can only connect to the Azure virtual network; they cannot transit to other on-premises networks or virtual networks via the same Azure VPN gateway.
The configuration option is part of the custom IPsec/IKE connection policy. If you enable the policy-based traffic selector option, you must specify the complete policy (IPsec/IKE encryption and integrity algorithms, key strengths, and SA lifetimes).
Because Basic SKU public IP addresses are announced to retire September 30, 2025, Microsoft is no longer permitting new gateways to be created using Basic SKU public IP addresses. Starting December 1, 2023, when you create a new VPN gateway, you must use a Standard SKU public IP address.
You can use any All Generation1 and Generation2 virtual network gateway SKUs except Basic.
To enable connectivity, use the following workflow in Azure Cloud:
- Create a virtual network.
- Create a VPN gateway.
- Create a local network gateway.
- Create a VPN connection.
- enable the policy-based traffic selectors on the connection.
Below, we are focusing on the details of the Azure VPN gateway configuration, which allows the establishment of a connection between Azure and DAL.
Before you create a VPN gateway, you must create a gateway subnet. The gateway subnet contains the IP addresses that the virtual network gateway VMs and services use. When you create your virtual network gateway, gateway VMs are deployed to the gateway subnet and configured with the required VPN gateway settings.
Azure Virtual network gateway configuration:
Local network gateway configuration:
A local network gateway is different than a virtual network gateway. When you're working with a VPN gateway site-to-site architecture, the local network gateway usually represents your on-premises network and the corresponding VPN device. When you configure a local network gateway, you specify the name, the public IP address or the fully qualified domain name (FQDN) of the on-premises VPN device, and the address prefixes that are located on the on-premises location.
Connections configuration under the virtual network gateway configuration:
Here, you must enable the policy-based traffic selectors on the connection and set up local and remote address ranges.
Below you can find a standard policy based routing configuration of DAL device with source and destination IP matches the traffic selector in Azure Cloud:
Tunnel mode and authentication configuration.
Local and Remote endpoints configuration.
Traffic selector configuration.
IKE Phase 1 and 2 configuration.
Whether the IPsec tunnel is up and running, you can check it on both sides of the connection.
In Azure cloud:
All resources >Connections
On the Digi router with CLI command:
TX64> show ipsec verbose
Status of IKE charon daemon (strongSwan 5.9.13, Linux 6.12.22-ac0, x86_64)
uptime : 107 minutes, since Jul 02 08:21:25 2025
worker threads : 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins : charon unbound random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pgp dnskey sshkey pem openssl pkcs8 fips-prf xcbc cmac kdf drbg curl attr kernel-netlink resolve socket-default stroke vici updown xauth-generic counters
Listening IP addresses
192.168.172.64
192.168.169.64
192.168.210.1
169.254.100.100
10.8.0.1
37.82.172.130
Connections
TO_AZURE_policy0 : 37.82.172.130...128.251.255.102 IKEv2, dpddelay=60s
local: [37.82.172.130] uses pre-shared key authentication
remote: [128.251.255.102] uses pre-shared key authentication
child: 192.168.169.0/24 === 10.1.0.0/24 TUNNEL, dpdaction=start
Security Associations (1 up, 0 connecting)
TO_AZURE_policy0[4] : ESTABLISHED 102 minutes ago, 37.82.172.130[37.82.172.130]...128.251.255.102[128.251.255.102]
IKEv2 SPIs: a9c6b8f007d98010_i* c6786d6661e75e28_r, pre-shared key reauthentication in 67 minutes
IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_768
TO_AZURE_policy0{4} : INSTALLED, TUNNEL, reqid 1, ESP SPIs: c880e13d_i 7957f290_o
AES_CBC_256/HMAC_SHA2_256_128, 1240 bytes_i (15 pkts, 48s ago), 668 bytes_o (8 pkts, 48s ago), rekeying in 28 minutes
192.168.169.0/24 === 10.1.0.0/24
Last updated:
Jul 07, 2025