Edit

Share via

VPN Gateway FAQ

  • Article

Connecting to virtual networks

Can I connect virtual networks in different Azure regions?

Yes. There's no region constraint. One virtual network can connect to another virtual network in the same region, or in a different Azure region.

Can I connect virtual networks in different subscriptions?

Yes.

Can I specify private DNS servers in my VNet when configuring a VPN gateway?

If you specified a DNS server or servers when you created your virtual network, VPN Gateway uses the DNS servers that you specified. If you specify a DNS server, verify that your DNS server can resolve the domain names needed for Azure.

Can I connect to multiple sites from a single virtual network?

You can connect to multiple sites by using Windows PowerShell and the Azure REST APIs. See the Multi-Site and VNet-to-VNet Connectivity FAQ section.

Is there an additional cost for setting up a VPN gateway as active-active?

No. However, costs for any additional public IPs will be charged accordingly. See IP Address Pricing.

What are my cross-premises connection options?

The following cross-premises virtual network gateway connections are supported:

  • Site-to-site: VPN connection over IPsec (IKE v1 and IKE v2). This type of connection requires a VPN device or RRAS. For more information, see Site-to-site.
  • Point-to-site: VPN connection over SSTP (Secure Socket Tunneling Protocol) or IKE v2. This connection doesn't require a VPN device. For more information, see Point-to-site.
  • VNet-to-VNet: This type of connection is the same as a site-to-site configuration. VNet to VNet is a VPN connection over IPsec (IKE v1 and IKE v2). It doesn't require a VPN device. For more information, see VNet-to-VNet.
  • ExpressRoute: ExpressRoute is a private connection to Azure from your WAN, not a VPN connection over the public Internet. For more information, see the ExpressRoute Technical Overview and the ExpressRoute FAQ.

For more information about VPN Gateway connections, see About VPN Gateway.

What is the difference between a site-to-site connection and point-to-site?

Site-to-site (IPsec/IKE VPN tunnel) configurations are between your on-premises location and Azure. This means that you can connect from any of your computers located on your premises to any virtual machine or role instance within your virtual network, depending on how you choose to configure routing and permissions. It's a great option for an always-available cross-premises connection and is well suited for hybrid configurations. This type of connection relies on an IPsec VPN appliance (hardware device or soft appliance), which must be deployed at the edge of your network. To create this type of connection, you must have an externally facing IPv4 address.

Point-to-site (VPN over SSTP) configurations let you connect from a single computer from anywhere to anything located in your virtual network. It uses the Windows in-box VPN client. As part of the point-to-site configuration, you install a certificate and a VPN client configuration package, which contains the settings that allow your computer to connect to any virtual machine or role instance within the virtual network. It's great when you want to connect to a virtual network, but aren't located on-premises. It's also a good option when you don't have access to VPN hardware or an externally facing IPv4 address, both of which are required for a site-to-site connection.

You can configure your virtual network to use both site-to-site and point-to-site concurrently, as long as you create your site-to-site connection using a route-based VPN type for your gateway. Route-based VPN types are called dynamic gateways in the classic deployment model.

Privacy

Does the VPN service store or process customer data?

No.

Virtual network gateways

Is a VPN gateway a virtual network gateway?

A VPN gateway is a type of virtual network gateway. A VPN gateway sends encrypted traffic between your virtual network and your on-premises location across a public connection. You can also use a VPN gateway to send traffic between virtual networks. When you create a VPN gateway, you use the -GatewayType value 'Vpn'. For more information, see About VPN Gateway configuration settings.

Why can't I specify policy-based and route-based VPN types?

As of Oct 1, 2023, you can't create a policy-based VPN gateway through Azure portal. All new VPN gateways will automatically be created as route-based. If you already have a policy-based gateway, you don't need to upgrade your gateway to route-based. You can use Powershell/CLI to create the policy-based gateways.

Previously, the older gateway SKUs didn't support IKEv1 for route-based gateways. Now, most of the current gateway SKUs support both IKEv1 and IKEv2.

Gateway VPN type Gateway SKU IKE versions supported
Policy-based gateway Basic IKEv1
Route-based gateway Basic IKEv2
Route-based gateway VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 and IKEv2
Route-based gateway VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 and IKEv2

Can I update my policy-based VPN gateway to route-based?

No. A gateway type can't be changed from policy-based to route-based, or from route-based to policy-based. To change a gateway type, the gateway must be deleted and recreated. This process takes about 60 minutes. When you create the new gateway, you can't retain the IP address of the original gateway.

  1. Delete any connections associated with the gateway.

  2. Delete the gateway using one of the following articles:

  3. Create a new gateway using the gateway type that you want, and then complete the VPN setup. For steps, see the Site-to-site tutorial.

Can I specify my own policy-based traffic selectors?

Yes, traffic selectors can be defined via the trafficSelectorPolicies attribute on a connection via the New-AzIpsecTrafficSelectorPolicy PowerShell command. For the specified traffic selector to take effect, ensure the Use Policy Based Traffic Selectors option is enabled.

The custom configured traffic selectors will be proposed only when an Azure VPN gateway initiates the connection. A VPN gateway accepts any traffic selectors proposed by a remote gateway (on-premises VPN device). This behavior is consistent between all connection modes (Default, InitiatorOnly, and ResponderOnly).

Do I need a 'GatewaySubnet'?

Yes. The gateway subnet contains the IP addresses that the virtual network gateway services use. You need to create a gateway subnet for your virtual network in order to configure a virtual network gateway. All gateway subnets must be named 'GatewaySubnet' to work properly. Don't name your gateway subnet something else. And don't deploy VMs or anything else to the gateway subnet.

When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The IP addresses in the gateway subnet are allocated to the gateway service. Some configurations require more IP addresses to be allocated to the gateway services than do others. You want to make sure your gateway subnet contains enough IP addresses to accommodate future growth and possible additional new connection configurations. So, while you can create a gateway subnet as small as /29, we recommend that you create a gateway subnet of /27 or larger (/27, /26, /25 etc.). Look at the requirements for the configuration that you want to create and verify that the gateway subnet you have will meet those requirements.

Can I deploy Virtual Machines or role instances to my gateway subnet?

No.

Can I get my VPN gateway IP address before I create it?

Azure Standard SKU public IP resources must use a static allocation method. Therefore, you'll have the public IP address for your VPN gateway as soon as you create the Standard SKU public IP resource you intend to use for it.

Can I request a static public IP address for my VPN gateway?

Standard SKU public IP address resources use a static allocation method. Going forward, you must use a Standard SKU public IP address when you create a new VPN gateway. This applies to all gateway SKUs except the Basic SKU. The Basic gateway SKU currently supports only Basic SKU public IP addresses. We'll soon be adding support for Standard SKU public IP addresses for Basic gateway SKUs.

For non-zone-redundant and non-zonal gateways that were previously created (gateway SKUs that do not have AZ in the name), dynamic IP address assignment is supported, but is being phased out. When you use a dynamic IP address, the IP address doesn't change after it has been assigned to your VPN gateway. The only time the VPN gateway IP address changes is when the gateway is deleted and then re-created. The VPN gateway public IP address doesn't change when you resize, reset, or complete other internal maintenance and upgrades of your VPN gateway.

How does Public IP address Basic SKU retirement affect my VPN gateways?

We're taking action to ensure the continued operation of deployed VPN gateways that utilize Basic SKU public IP addresses. If you already have VPN gateways with Basic SKU public IP addresses, there's no need for you to take any action.

However, it's important to note that Basic SKU public IP addresses are being phased out. Going forward, when creating a new VPN gateway, you must use the Standard SKU public IP address. Further details on the retirement of Basic SKU public IP addresses can be found here.

How does my VPN tunnel get authenticated?

Azure VPN uses PSK (Pre-Shared Key) authentication. We generate a pre-shared key (PSK) when we create the VPN tunnel. You can change the autogenerated PSK to your own with the Set Pre-Shared Key PowerShell cmdlet or REST API.

Can I use the Set Pre-Shared Key API to configure my policy-based (static routing) gateway VPN?

Yes, the Set Pre-Shared Key API and PowerShell cmdlet can be used to configure both Azure policy-based (static) VPNs and route-based (dynamic) routing VPNs.

Can I use other authentication options?

We're limited to using pre-shared keys (PSK) for authentication.

How do I specify which traffic goes through the VPN gateway?

Resource Manager deployment model

  • PowerShell: use "AddressPrefix" to specify traffic for the local network gateway.
  • Azure portal: navigate to the Local network gateway > Configuration > Address space.

Classic deployment model

  • Azure portal: navigate to the classic virtual network > VPN connections > Site-to-site VPN connections > Local site name > Local site > Client address space.

Can I use NAT-T on my VPN connections?

Yes, NAT traversal (NAT-T) is supported. Azure VPN Gateway will NOT perform any NAT-like functionality on the inner packets to/from the IPsec tunnels. In this configuration, ensure the on-premises device initiates the IPSec tunnel.

Can I set up my own VPN server in Azure and use it to connect to my on-premises network?

Yes, you can deploy your own VPN gateways or servers in Azure either from the Azure Marketplace or creating your own VPN routers. You must configure user-defined routes in your virtual network to ensure traffic is routed properly between your on-premises networks and your virtual network subnets.

Why are certain ports opened on my virtual network gateway?

They're required for Azure infrastructure communication. They're protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those gateways, won't be able to cause any effect on those endpoints.

A virtual network gateway is fundamentally a multi-homed device with one NIC tapping into the customer private network, and one NIC facing the public network. Azure infrastructure entities can't tap into customer private networks for compliance reasons, so they need to utilize public endpoints for infrastructure communication. The public endpoints are periodically scanned by Azure security audit.

Can I create a VPN gateway with the Basic gateway SKU in the portal?

No. The Basic SKU isn't available in the portal. You can create a Basic SKU VPN gateway using Azure CLI or PowerShell.

Where can I find information about gateway types, requirements, and throughput?

See the following articles:

SKU deprecation for legacy SKUs

The Standard and High Performance SKUs will be deprecated on September 30, 2025. You can view the announcement here. The product team will make a migration path available for these SKUs by November 30, 2024. For more information, see the VPN Gateway legacy SKUs article. At this time, there's no action that you need to take.

Can I create a new Standard/High Performance SKU after the deprecation announcement on November 30, 2023?

No. Starting December 1, 2023 you can't create new gateways with Standard or High Performance SKUs. You can create new gateways using VpnGw1 and VpnGw2 for the same price as the Standard and High Performance SKUs, listed respectively on our pricing page.

How long will my existing gateways be supported on Standard/High Performance SKUs?

All existing gateways using Standard or High Performance SKUs will be supported until September 30, 2025.

Do I need to migrate my Standard/High Performance gateway SKUs right now?

No, there's no action required right now. You'll be able to migrate your SKUs starting December 2024. We'll send communication with detailed documentation about the migration steps.

Which SKU can I migrate my gateway to?

When gateway SKU migration becomes available, SKUs can be migrated as follows:

  • Standard -> VpnGw1
  • High Performance -> VpnGw2

What if I want to migrate to an AZ SKU?

You can't migrate your legacy SKU to an AZ SKU. However, note that all gateways that are still using Standard or High Performance SKUs after September 30, 2025 will be migrated and upgraded automatically to the following SKUs:

  • Standard -> VpnGw1AZ
  • High Performance -> VpnGw2AZ

You can use this strategy to have your SKUs automatically migrated and upgraded to an AZ SKU. You can then resize your SKU within that SKU family if necessary. See our pricing page for AZ SKU pricing. For throughput information by SKU, see About gateway SKUs.

Will there be any pricing difference for my gateways after migration?

If you migrate your SKUs by September 30, 2025, there will be no pricing difference. VpnGw1 and VpnGw2 SKUs are offered at the same price as Standard and High Performance SKUs, respectively. If you don't migrate by that date, your SKUs will automatically be migrated and upgraded to AZ SKUs. In that case, there's a pricing difference.

Will there be any performance impact on my gateways with this migration?

Yes, you get better performance with VpnGw1 and VpnGw2. Currently, VpnGw1 at 650 Mbps provides a 6.5x and VpnGw2 at 1 Gbps provides a 5x performance improvement at the same price as the legacy Standard and High Performance gateways, respectively. For more SKU throughput information, see About gateway SKUs.

What happens if I don't migrate SKUs by September 30, 2025?

All gateways that are still using Standard or High Performance SKUs will be migrated automatically and upgraded to the following AZ SKUs:

  • Standard -> VpnGw1AZ
  • High Performance -> VpnGw2AZ

Final communication will be sent before initiating migration on any gateways.

Is VPN Gateway Basic SKU retiring as well?

No, the VPN Gateway Basic SKU is here to stay. You can create a VPN gateway using the Basic gateway SKU via PowerShell or CLI. Currently, VPN Gateway Basic gateway SKUs only support the Basic SKU public IP address resource (which is on a path to retirement). We're working on adding support to the VPN Gateway Basic gateway SKU for the Standard SKU public IP address resource.

Site-to-site connections and VPN devices

What should I consider when selecting a VPN device?

We've validated a set of standard site-to-site VPN devices in partnership with device vendors. A list of known compatible VPN devices, their corresponding configuration instructions or samples, and device specs can be found in the About VPN devices article. All devices in the device families listed as known compatible should work with Virtual Network. To help configure your VPN device, refer to the device configuration sample or link that corresponds to appropriate device family.

Where can I find VPN device configuration settings?

To download VPN device configuration scripts:

Depending on the VPN device that you have, you may be able to download a VPN device configuration script. For more information, see Download VPN device configuration scripts.

See the following links for additional configuration information:

How do I edit VPN device configuration samples?

For information about editing device configuration samples, see Editing samples.

Where do I find IPsec and IKE parameters?

For IPsec/IKE parameters, see Parameters.

Why does my policy-based VPN tunnel go down when traffic is idle?

This is expected behavior for policy-based (also known as static routing) VPN gateways. When the traffic over the tunnel is idle for more than 5 minutes, the tunnel is torn down. When traffic starts flowing in either direction, the tunnel is reestablished immediately.

Can I use software VPNs to connect to Azure?

We support Windows Server 2012 Routing and Remote Access (RRAS) servers for site-to-site cross-premises configuration.

Other software VPN solutions should work with our gateway as long as they conform to industry standard IPsec implementations. Contact the vendor of the software for configuration and support instructions.

Can I connect to a VPN gateway via point-to-site when located at a Site that has an active site-to-site connection?

Yes, but the Public IP address(es) of the point-to-site client must be different than the Public IP address(es) used by the site-to-site VPN device, or else the point-to-site connection won't work. point-to-site connections with IKEv2 can't be initiated from the same Public IP address(es) where a site-to-site VPN connection is configured on the same Azure VPN gateway.

Point-to-site - Certificate authentication

This section applies to the Resource Manager deployment model.

How many VPN client endpoints can I have in my point-to-site configuration?

It depends on the gateway SKU. For more information on the number of connections supported, see Gateway SKUs.

What client operating systems can I use with point-to-site?

The following client operating systems are supported:

  • Windows Server 2008 R2 (64-bit only)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows Server 2019 (64-bit only)
  • Windows Server 2022 (64-bit only)
  • Windows 10
  • Windows 11
  • macOS version 10.11 or above
  • Linux (StrongSwan)
  • iOS

Can I traverse proxies and firewalls using point-to-site capability?

Azure supports three types of point-to-site VPN options:

  • Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary SSL-based solution that can penetrate firewalls since most firewalls open the outbound TCP port that 443 SSL uses.

  • OpenVPN. OpenVPN is a SSL-based solution that can penetrate firewalls since most firewalls open the outbound TCP port that 443 SSL uses.

  • IKEv2 VPN. IKEv2 VPN is a standards-based IPsec VPN solution that uses outbound UDP ports 500 and 4500 and IP protocol no. 50. Firewalls don't always open these ports, so there's a possibility of IKEv2 VPN not being able to traverse proxies and firewalls.

If I restart a client computer configured for point-to-site, will the VPN automatically reconnect?

Automatic Reconnection is a function of the client being used. Windows supports Automatic Reconnection by configuring the Always On VPN client feature.

Does point-to-site support DDNS on the VPN clients?

DDNS is currently not supported in point-to-site VPNs.

Can I have Site-to-Site and point-to-site configurations coexist for the same virtual network?

Yes. For the Resource Manager deployment model, you must have a RouteBased VPN type for your gateway. For the classic deployment model, you need a dynamic gateway. We don't support point-to-site for static routing VPN gateways or PolicyBased VPN gateways.

Can I configure a point-to-site client to connect to multiple virtual network gateways at the same time?

Depending on the VPN Client software used, you might be able to connect to multiple Virtual Network Gateways provided the virtual networks being connected to don't have conflicting address spaces between them or the network from with the client is connecting from. While the Azure VPN Client supports many VPN connections, only one connection can be Connected at any given time.

Can I configure a point-to-site client to connect to multiple virtual networks at the same time?

Yes, point-to-site client connections to a virtual network gateway that is deployed in a VNet that is peered with other VNets might have access to other peered VNets. Point-to-site clients are able to connect to peered VNets as long as the peered VNets are using the UseRemoteGateway / AllowGatewayTransit features. For more information, see About point-to-site routing.

How much throughput can I expect through Site-to-Site or point-to-site connections?

It's difficult to maintain the exact throughput of the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the Internet. For a VPN Gateway with only IKEv2 point-to-site VPN connections, the total throughput that you can expect depends on the Gateway SKU. For more information on throughput, see Gateway SKUs.

Can I use any software VPN client for point-to-site that supports SSTP and/or IKEv2?

No. You can only use the native VPN client on Windows for SSTP, and the native VPN client on Mac for IKEv2. However, you can use the OpenVPN client on all platforms to connect over OpenVPN protocol. Refer to the list of supported client operating systems.

Can I change the authentication type for a point-to-site connection?

Yes. In the portal, navigate to the VPN gateway -> Point-to-site configuration page. For Authentication type, select the authentication types that you want to use. After you make a change to an authentication type, current clients might not be able to connect until a new VPN client configuration profile has been generated, downloaded, and applied to each VPN client.

When do I need to generate a new VPN client profile configuration package?

When you make changes to the P2S VPN gateway configuration settings, such as adding a Tunnel Type or changing an Authentication Type, you need to generate a new VPN client profile configuration package. The new package includes the updated settings that VPN clients need in order to properly connect to the P2S gateway. After generating the package, use the settings contained in the files to update the VPN clients.

Does Azure support IKEv2 VPN with Windows?

IKEv2 is supported on Windows 10 and Server 2016. However, in order to use IKEv2 in certain OS versions, you must install updates and set a registry key value locally. OS versions prior to Windows 10 aren't supported and can only use SSTP or OpenVPN® Protocol.

Note

Windows OS builds newer than Windows 10 Version 1709 and Windows Server 2016 Version 1607 do not require these steps.

To prepare Windows 10 or Server 2016 for IKEv2:

  1. Install the update based on your OS version:

    OS version Date Number/Link
    Windows Server 2016
    Windows 10 Version 1607    		 January 17, 2018 KB4057142
    Windows 10 Version 1703 January 17, 2018 KB4057144
    Windows 10 Version 1709 March 22, 2018 KB4089848

  2. Set the registry key value. Create or set “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD key in the registry to 1.

What is the IKEv2 traffic selector limit for point-to-site connections?

Windows 10 version 2004 (released September 2021) increased the traffic selector limit to 255. Versions of Windows earlier than this have a traffic selector limit of 25.

The traffic selectors limit in Windows determines the maximum number of address spaces in your virtual network and the maximum sum of your local networks, VNet-to-VNet connections, and peered VNets connected to the gateway. Windows-based point-to-site clients will fail to connect via IKEv2 if they surpass this limit.

What is the OpenVPN traffic selector limit for point-to-site connections?

The traffic selectors limit for OpenVPN is 1000 routes.

What happens when I configure both SSTP and IKEv2 for P2S VPN connections?

When you configure both SSTP and IKEv2 in a mixed environment (consisting of Windows and Mac devices), the Windows VPN client will always try IKEv2 tunnel first, but will fall back to SSTP if the IKEv2 connection isn't successful. MacOSX will only connect via IKEv2.

When you have both SSTP and IKEv2 enabled on the gateway, the point-to-site address pool is statically split between the two, so clients using different protocols are IP addresses from either sub-range. The maximum number of SSTP clients is always 128, even if the address range is larger than /24, resulting in a larger number of addresses available for IKEv2 clients. For smaller ranges, the pool is equally halved. Traffic Selectors used by the gateway might not include the point-to-site address range CIDR, but the two sub-range CIDRs.

Other than Windows and Mac, which other platforms does Azure support for P2S VPN?

Azure supports Windows, Mac, and Linux for P2S VPN.

I already have an Azure VPN Gateway deployed. Can I enable RADIUS and/or IKEv2 VPN on it?

Yes, if the gateway SKU that you're using supports RADIUS and/or IKEv2, you can enable these features on gateways that you've already deployed by using PowerShell or the Azure portal. The Basic SKU doesn't support RADIUS or IKEv2.

How do I remove the configuration of a P2S connection?

A P2S configuration can be removed using Azure CLI and PowerShell using the following commands:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

What should I do if I'm getting a certificate mismatch when connecting using certificate authentication?

Uncheck "Verify the server's identity by validating the certificate", or add the server FQDN along with the certificate when creating a profile manually. You can do this by running rasphone from a command prompt and picking the profile from the drop-down list.

Bypassing server identity validation isn't recommended in general, but with Azure certificate authentication, the same certificate is being used for server validation in the VPN tunneling protocol (IKEv2/SSTP) and the EAP protocol. Since the server certificate and FQDN are already validated by the VPN tunneling protocol, it's redundant to validate the same again in EAP.

point-to-site auth

Can I use my own internal PKI root CA to generate certificates for Point-to-Site connectivity?

Yes. Previously, only self-signed root certificates could be used. You can still upload 20 root certificates.

Can I use certificates from Azure Key Vault?

No.

What tools can I use to create certificates?

You can use your Enterprise PKI solution (your internal PKI), Azure PowerShell, MakeCert, and OpenSSL.

Are there instructions for certificate settings and parameters?

  • Internal PKI/Enterprise PKI solution: See the steps to Generate certificates.

  • Azure PowerShell: See the Azure PowerShell article for steps.

  • MakeCert: See the MakeCert article for steps.

  • OpenSSL:

    • When exporting certificates, be sure to convert the root certificate to Base64.

    • For the client certificate:

      • When creating the private key, specify the length as 4096.
      • When creating the certificate, for the -extensions parameter, specify usr_cert.

Point-to-site - RADIUS authentication

This section applies to the Resource Manager deployment model.

How many VPN client endpoints can I have in my point-to-site configuration?

It depends on the gateway SKU. For more information on the number of connections supported, see Gateway SKUs.

What client operating systems can I use with point-to-site?

The following client operating systems are supported:

  • Windows Server 2008 R2 (64-bit only)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows Server 2019 (64-bit only)
  • Windows Server 2022 (64-bit only)
  • Windows 10
  • Windows 11
  • macOS version 10.11 or above
  • Linux (StrongSwan)
  • iOS

Can I traverse proxies and firewalls using point-to-site capability?

Azure supports three types of point-to-site VPN options:

  • Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary SSL-based solution that can penetrate firewalls since most firewalls open the outbound TCP port that 443 SSL uses.

  • OpenVPN. OpenVPN is a SSL-based solution that can penetrate firewalls since most firewalls open the outbound TCP port that 443 SSL uses.

  • IKEv2 VPN. IKEv2 VPN is a standards-based IPsec VPN solution that uses outbound UDP ports 500 and 4500 and IP protocol no. 50. Firewalls don't always open these ports, so there's a possibility of IKEv2 VPN not being able to traverse proxies and firewalls.

If I restart a client computer configured for point-to-site, will the VPN automatically reconnect?

Automatic Reconnection is a function of the client being used. Windows supports Automatic Reconnection by configuring the Always On VPN client feature.

Does point-to-site support DDNS on the VPN clients?

DDNS is currently not supported in point-to-site VPNs.

Can I have Site-to-Site and point-to-site configurations coexist for the same virtual network?

Yes. For the Resource Manager deployment model, you must have a RouteBased VPN type for your gateway. For the classic deployment model, you need a dynamic gateway. We don't support point-to-site for static routing VPN gateways or PolicyBased VPN gateways.

Can I configure a point-to-site client to connect to multiple virtual network gateways at the same time?

Depending on the VPN Client software used, you might be able to connect to multiple Virtual Network Gateways provided the virtual networks being connected to don't have conflicting address spaces between them or the network from with the client is connecting from. While the Azure VPN Client supports many VPN connections, only one connection can be Connected at any given time.

Can I configure a point-to-site client to connect to multiple virtual networks at the same time?

Yes, point-to-site client connections to a virtual network gateway that is deployed in a VNet that is peered with other VNets might have access to other peered VNets. Point-to-site clients are able to connect to peered VNets as long as the peered VNets are using the UseRemoteGateway / AllowGatewayTransit features. For more information, see About point-to-site routing.

How much throughput can I expect through Site-to-Site or point-to-site connections?

It's difficult to maintain the exact throughput of the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the Internet. For a VPN Gateway with only IKEv2 point-to-site VPN connections, the total throughput that you can expect depends on the Gateway SKU. For more information on throughput, see Gateway SKUs.

Can I use any software VPN client for point-to-site that supports SSTP and/or IKEv2?

No. You can only use the native VPN client on Windows for SSTP, and the native VPN client on Mac for IKEv2. However, you can use the OpenVPN client on all platforms to connect over OpenVPN protocol. Refer to the list of supported client operating systems.

Can I change the authentication type for a point-to-site connection?

Yes. In the portal, navigate to the VPN gateway -> Point-to-site configuration page. For Authentication type, select the authentication types that you want to use. After you make a change to an authentication type, current clients might not be able to connect until a new VPN client configuration profile has been generated, downloaded, and applied to each VPN client.

When do I need to generate a new VPN client profile configuration package?

When you make changes to the P2S VPN gateway configuration settings, such as adding a Tunnel Type or changing an Authentication Type, you need to generate a new VPN client profile configuration package. The new package includes the updated settings that VPN clients need in order to properly connect to the P2S gateway. After generating the package, use the settings contained in the files to update the VPN clients.

Does Azure support IKEv2 VPN with Windows?

IKEv2 is supported on Windows 10 and Server 2016. However, in order to use IKEv2 in certain OS versions, you must install updates and set a registry key value locally. OS versions prior to Windows 10 aren't supported and can only use SSTP or OpenVPN® Protocol.

Note

Windows OS builds newer than Windows 10 Version 1709 and Windows Server 2016 Version 1607 do not require these steps.

To prepare Windows 10 or Server 2016 for IKEv2:

  1. Install the update based on your OS version:

    OS version Date Number/Link
    Windows Server 2016
    Windows 10 Version 1607    		 January 17, 2018 KB4057142
    Windows 10 Version 1703 January 17, 2018 KB4057144
    Windows 10 Version 1709 March 22, 2018 KB4089848

  2. Set the registry key value. Create or set “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD key in the registry to 1.

What is the IKEv2 traffic selector limit for point-to-site connections?

Windows 10 version 2004 (released September 2021) increased the traffic selector limit to 255. Versions of Windows earlier than this have a traffic selector limit of 25.

The traffic selectors limit in Windows determines the maximum number of address spaces in your virtual network and the maximum sum of your local networks, VNet-to-VNet connections, and peered VNets connected to the gateway. Windows-based point-to-site clients will fail to connect via IKEv2 if they surpass this limit.

What is the OpenVPN traffic selector limit for point-to-site connections?

The traffic selectors limit for OpenVPN is 1000 routes.

What happens when I configure both SSTP and IKEv2 for P2S VPN connections?

When you configure both SSTP and IKEv2 in a mixed environment (consisting of Windows and Mac devices), the Windows VPN client will always try IKEv2 tunnel first, but will fall back to SSTP if the IKEv2 connection isn't successful. MacOSX will only connect via IKEv2.

When you have both SSTP and IKEv2 enabled on the gateway, the point-to-site address pool is statically split between the two, so clients using different protocols are IP addresses from either sub-range. The maximum number of SSTP clients is always 128, even if the address range is larger than /24, resulting in a larger number of addresses available for IKEv2 clients. For smaller ranges, the pool is equally halved. Traffic Selectors used by the gateway might not include the point-to-site address range CIDR, but the two sub-range CIDRs.

Other than Windows and Mac, which other platforms does Azure support for P2S VPN?

Azure supports Windows, Mac, and Linux for P2S VPN.

I already have an Azure VPN Gateway deployed. Can I enable RADIUS and/or IKEv2 VPN on it?

Yes, if the gateway SKU that you're using supports RADIUS and/or IKEv2, you can enable these features on gateways that you've already deployed by using PowerShell or the Azure portal. The Basic SKU doesn't support RADIUS or IKEv2.

How do I remove the configuration of a P2S connection?

A P2S configuration can be removed using Azure CLI and PowerShell using the following commands:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Is RADIUS authentication supported on all Azure VPN Gateway SKUs?

RADIUS authentication is supported for all SKUs except the Basic SKU.

For legacy SKUs, RADIUS authentication is supported on Standard and High Performance SKUs. It isn't supported on the Basic Gateway SKU.

Is RADIUS authentication supported for the classic deployment model?

No. RADIUS authentication isn't supported for the classic deployment model.

What is the timeout period for RADIUS requests sent to the RADIUS server?

RADIUS requests are set to timeout after 30 seconds. User defined timeout values aren't supported today.

Are 3rd-party RADIUS servers supported?

Yes, 3rd-party RADIUS servers are supported.

What are the connectivity requirements to ensure that the Azure gateway is able to reach an on-premises RADIUS server?

A site-to-site VPN connection to the on-premises site, with the proper routes configured, is required.

Can traffic to an on-premises RADIUS server (from the Azure VPN gateway) be routed over an ExpressRoute connection?

No. It can only be routed over a site-to-site connection.

Is there a change in the number of SSTP connections supported with RADIUS authentication? What is the maximum number of SSTP and IKEv2 connections supported?

There's no change in the maximum number of SSTP connections supported on a gateway with RADIUS authentication. It remains 128 for SSTP, but depends on the gateway SKU for IKEv2. For more information on the number of connections supported, see Gateway SKUs.

What is the difference between doing certificate authentication using a RADIUS server vs. using Azure native certificate authentication (by uploading a trusted certificate to Azure)?

In RADIUS certificate authentication, the authentication request is forwarded to a RADIUS server that handles the actual certificate validation. This option is useful if you want to integrate with a certificate authentication infrastructure that you already have through RADIUS.

When using Azure for certificate authentication, the Azure VPN gateway performs the validation of the certificate. You need to upload your certificate public key to the gateway. You can also specify list of revoked certificates that shouldn’t be allowed to connect.

Does Radius authentication support Network Policy Server (NPS) integration for multifactor authorization (MFA)?

If your MFA is text based (SMS, mobile app verification code etc.) and requires the user to enter a code or text in the VPN client UI, the authentication won't succeed and isn't a supported scenario. See Integrate Azure VPN gateway RADIUS authentication with NPS server for multifactor authentication

Does RADIUS authentication work with both IKEv2, and SSTP VPN?

Yes, RADIUS authentication is supported for both IKEv2, and SSTP VPN.

Does RADIUS authentication work with the OpenVPN client?

RADIUS authentication is supported for the OpenVPN protocol.

VNet-to-VNet and Multi-Site connections

The VNet-to-VNet FAQ applies to VPN gateway connections. For information about VNet peering, see Virtual network peering.

Does Azure charge for traffic between VNets?

VNet-to-VNet traffic within the same region is free for both directions when you use a VPN gateway connection. Cross-region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions. For more information, see VPN Gateway pricing page. If you're connecting your VNets by using VNet peering instead of a VPN gateway, see Virtual network pricing.

Does VNet-to-VNet traffic travel across the internet?

No. VNet-to-VNet traffic travels across the Microsoft Azure backbone, not the internet.

Can I establish a VNet-to-VNet connection across Microsoft Entra tenants?

Yes, VNet-to-VNet connections that use Azure VPN gateways work across Microsoft Entra tenants.

Is VNet-to-VNet traffic secure?

Yes, it's protected by IPsec/IKE encryption.

Do I need a VPN device to connect VNets together?

No. Connecting multiple Azure virtual networks together doesn't require a VPN device unless cross-premises connectivity is required.

Do my VNets need to be in the same region?

No. The virtual networks can be in the same or different Azure regions (locations).

If the VNets aren't in the same subscription, do the subscriptions need to be associated with the same Active Directory tenant?

No.

Can I use VNet-to-VNet to connect virtual networks in separate Azure instances?

No. VNet-to-VNet supports connecting virtual networks within the same Azure instance. For example, you can’t create a connection between global Azure and Chinese/German/US government Azure instances. Consider using a Site-to-Site VPN connection for these scenarios.

Can I use VNet-to-VNet along with multi-site connections?

Yes. Virtual network connectivity can be used simultaneously with multi-site VPNs.

How many on-premises sites and virtual networks can one virtual network connect to?

See the Gateway requirements table.

Can I use VNet-to-VNet to connect VMs or cloud services outside of a VNet?

No. VNet-to-VNet supports connecting virtual networks. It doesn't support connecting virtual machines or cloud services that aren't in a virtual network.

Can a cloud service or a load-balancing endpoint span VNets?

No. A cloud service or a load-balancing endpoint can't span across virtual networks, even if they're connected together.

Can I use a PolicyBased VPN type for VNet-to-VNet or Multi-Site connections?

No. VNet-to-VNet and Multi-Site connections require Azure VPN gateways with RouteBased (previously called dynamic routing) VPN types.

Can I connect a VNet with a RouteBased VPN Type to another VNet with a PolicyBased VPN type?

No, both virtual networks MUST use route-based (previously called dynamic routing) VPNs.

Do VPN tunnels share bandwidth?

Yes. All VPN tunnels of the virtual network share the available bandwidth on the Azure VPN gateway and the same VPN gateway uptime SLA in Azure.

Are redundant tunnels supported?

Redundant tunnels between a pair of virtual networks are supported when one virtual network gateway is configured as active-active.

Can I have overlapping address spaces for VNet-to-VNet configurations?

No. You can't have overlapping IP address ranges.

Can there be overlapping address spaces among connected virtual networks and on-premises local sites?

No. You can't have overlapping IP address ranges.

How do I enable routing between my site-to-site VPN connection and my ExpressRoute?

If you want to enable routing between your branch connected to ExpressRoute and your branch connected to a site-to-site VPN connection, you'll need to set up Azure Route Server.

Can I use Azure VPN gateway to transit traffic between my on-premises sites or to another virtual network?

Resource Manager deployment model
Yes. See the BGP section for more information.

Classic deployment model
Transit traffic via Azure VPN gateway is possible using the classic deployment model, but relies on statically defined address spaces in the network configuration file. BGP isn't yet supported with Azure Virtual Networks and VPN gateways using the classic deployment model. Without BGP, manually defining transit address spaces is very error prone, and not recommended.

Does Azure generate the same IPsec/IKE pre-shared key for all my VPN connections for the same virtual network?

No, Azure by default generates different pre-shared keys for different VPN connections. However, you can use the Set VPN Gateway Key REST API or PowerShell cmdlet to set the key value you prefer. The key MUST only contain printable ASCII characters except space, hyphen (-) or tilde (~).

Do I get more bandwidth with more site-to-site VPNs than for a single virtual network?

No, all VPN tunnels, including point-to-site VPNs, share the same Azure VPN gateway and the available bandwidth.

Can I configure multiple tunnels between my virtual network and my on-premises site using multi-site VPN?

Yes, but you must configure BGP on both tunnels to the same location.

Does Azure VPN Gateway honor AS Path prepending to influence routing decisions between multiple connections to my on-premises sites?

Yes, Azure VPN gateway honors AS Path prepending to help make routing decisions when BGP is enabled. A shorter AS Path is preferred in BGP path selection.

Can I use the RoutingWeight property when creating a new VPN VirtualNetworkGateway connection?

No, such setting is reserved for ExpressRoute gateway connections. If you want to influence routing decisions between multiple connections, you need to use AS Path prepending.

Can I use point-to-site VPNs with my virtual network with multiple VPN tunnels?

Yes, point-to-site (P2S) VPNs can be used with the VPN gateways connecting to multiple on-premises sites and other virtual networks.

Can I connect a virtual network with IPsec VPNs to my ExpressRoute circuit?

Yes, this is supported. For more information, see Configure ExpressRoute and site-to-site VPN connections that coexist.

IPsec/IKE policy

Is Custom IPsec/IKE policy supported on all Azure VPN Gateway SKUs?

Custom IPsec/IKE policy is supported on all Azure SKUs except the Basic SKU.

How many policies can I specify on a connection?

You can only specify one policy combination for a given connection.

Can I specify a partial policy on a connection? (for example, only IKE algorithms, but not IPsec)

No, you must specify all algorithms and parameters for both IKE (Main Mode) and IPsec (Quick Mode). Partial policy specification isn't allowed.

What are the algorithms and key strengths supported in the custom policy?

The following table lists the supported cryptographic algorithms and key strengths that you can configure. You must select one option for every field.

IPsec/IKEv2 Options
IKEv2 Encryption GCMAES256, GCMAES128, AES256, AES192, AES128
IKEv2 Integrity SHA384, SHA256, SHA1, MD5
DH Group DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
IPsec Encryption GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None
IPsec Integrity GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS Group PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None
QM SA Lifetime (Optional: default values are used if not specified)
Seconds (integer; min. 300/default 27000 seconds)
KBytes (integer; min. 1024/default 102400000 KBytes)
Traffic Selector UsePolicyBasedTrafficSelectors** ($True/$False; Optional, default $False if not specified)
DPD timeout Seconds (integer: min. 9/max. 3600; default 45 seconds)

  • Your on-premises VPN device configuration must match or contain the following algorithms and parameters that you specify on the Azure IPsec/IKE policy:

    • IKE encryption algorithm (Main Mode / Phase 1)
    • IKE integrity algorithm (Main Mode / Phase 1)
    • DH Group (Main Mode / Phase 1)
    • IPsec encryption algorithm (Quick Mode / Phase 2)
    • IPsec integrity algorithm (Quick Mode / Phase 2)
    • PFS Group (Quick Mode / Phase 2)
    • Traffic Selector (if UsePolicyBasedTrafficSelectors is used)
    • The SA lifetimes are local specifications only, and don't need to match.

  • If GCMAES is used as for IPsec Encryption algorithm, you must select the same GCMAES algorithm and key length for IPsec Integrity; for example, using GCMAES128 for both.

  • In the Algorithms and keys table:

    • IKE corresponds to Main Mode or Phase 1.
    • IPsec corresponds to Quick Mode or Phase 2.
    • DH Group specifies the Diffie-Hellman Group used in Main Mode or Phase 1.
    • PFS Group specified the Diffie-Hellman Group used in Quick Mode or Phase 2.

  • IKE Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways.

  • 'UsePolicyBasedTrafficSelectors' is an optional parameter on the connection. If you set UsePolicyBasedTrafficSelectors to $True on a connection, it will configure the Azure VPN gateway to connect to policy-based VPN firewall on premises. If you enable PolicyBasedTrafficSelectors, you need to ensure your VPN device has the matching traffic selectors defined with all combinations of your on-premises network (local network gateway) prefixes to/from the Azure virtual network prefixes, instead of any-to-any. The Azure VPN gateway accepts whatever traffic selector is proposed by the remote VPN gateway irrespective of what is configured on the Azure VPN gateway.

    For example, if your on-premises network prefixes are 10.1.0.0/16 and 10.2.0.0/16, and your virtual network prefixes are 192.168.0.0/16 and 172.16.0.0/16, you need to specify the following traffic selectors:

    • 10.1.0.0/16 <====> 192.168.0.0/16
    • 10.1.0.0/16 <====> 172.16.0.0/16
    • 10.2.0.0/16 <====> 192.168.0.0/16
    • 10.2.0.0/16 <====> 172.16.0.0/16

    For more information regarding policy-based traffic selectors, see Connect multiple on-premises policy-based VPN devices.

  • DPD timeout - The default value is 45 seconds on Azure VPN gateways. Setting the timeout to shorter periods will cause IKE to rekey more aggressively, causing the connection to appear to be disconnected in some instances. This may not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or the physical link condition could incur packet loss. The general recommendation is to set the timeout between 30 to 45 seconds.

For more information, see Connect multiple on-premises policy-based VPN devices.

Which Diffie-Hellman Groups are supported?

The following table lists the corresponding Diffie-Hellman groups supported by the custom policy:

Diffie-Hellman Group DHGroup PFSGroup Key length
1 DHGroup1 PFS1 768-bit MODP
2 DHGroup2 PFS2 1024-bit MODP
14 DHGroup14
DHGroup2048		 PFS2048 2048-bit MODP
19 ECP256 ECP256 256-bit ECP
20 ECP384 ECP384 384-bit ECP
24 DHGroup24 PFS24 2048-bit MODP

Refer to RFC3526 and RFC5114 for more details.

Does the custom policy replace the default IPsec/IKE policy sets for Azure VPN gateways?

Yes, once a custom policy is specified on a connection, Azure VPN gateway will only use the policy on the connection, both as IKE initiator and IKE responder.

If I remove a custom IPsec/IKE policy, does the connection become unprotected?

No, the connection will still be protected by IPsec/IKE. Once you remove the custom policy from a connection, the Azure VPN gateway reverts back to the default list of IPsec/IKE proposals and restart the IKE handshake again with your on-premises VPN device.

Would adding or updating an IPsec/IKE policy disrupt my VPN connection?

Yes, it could cause a small disruption (a few seconds) as the Azure VPN gateway tears down the existing connection and restarts the IKE handshake to re-establish the IPsec tunnel with the new cryptographic algorithms and parameters. Ensure your on-premises VPN device is also configured with the matching algorithms and key strengths to minimize the disruption.

Can I use different policies on different connections?

Yes. Custom policy is applied on a per-connection basis. You can create and apply different IPsec/IKE policies on different connections. You can also choose to apply custom policies on a subset of connections. The remaining ones use the Azure default IPsec/IKE policy sets.

Can I use the custom policy on VNet-to-VNet connection as well?

Yes, you can apply custom policy on both IPsec cross-premises connections or VNet-to-VNet connections.

Do I need to specify the same policy on both VNet-to-VNet connection resources?

Yes. A VNet-to-VNet tunnel consists of two connection resources in Azure, one for each direction. Make sure both connection resources have the same policy, otherwise the VNet-to-VNet connection won't establish.

What is the default DPD timeout value? Can I specify a different DPD timeout?

The default DPD timeout is 45 seconds. You can specify a different DPD timeout value on each IPsec or VNet-to-VNet connection, from 9 seconds to 3600 seconds.

Note

The default value is 45 seconds on Azure VPN gateways. Setting the timeout to shorter periods will cause IKE to rekey more aggressively, causing the connection to appear to be disconnected in some instances. This may not be desirable if your on-premises locations are farther away from the Azure region where the VPN gateway resides, or when the physical link condition could incur packet loss. The general recommendation is to set the timeout between 30 and 45 seconds.

Does custom IPsec/IKE policy work on ExpressRoute connection?

No. IPsec/IKE policy only works on S2S VPN and VNet-to-VNet connections via the Azure VPN gateways.

How do I create connections with IKEv1 or IKEv2 protocol type?

IKEv1 connections can be created on all RouteBased VPN type SKUs, except the Basic SKU, Standard SKU, and other legacy SKUs. You can specify a connection protocol type of IKEv1 or IKEv2 while creating connections. If you don't specify a connection protocol type, IKEv2 is used as default option where applicable. For more information, see the PowerShell cmdlet documentation. For SKU types and IKEv1/IKEv2 support, see Connect gateways to policy-based VPN devices.

Is transit between IKEv1 and IKEv2 connections allowed?

Yes. Transit between IKEv1 and IKEv2 connections is supported.

Can I have IKEv1 site-to-site connections on Basic SKUs of RouteBased VPN type?

No. The Basic SKU doesn't support this.

Can I change the connection protocol type after the connection is created (IKEv1 to IKEv2 and vice versa)?

No. Once the connection is created, IKEv1/IKEv2 protocols can't be changed. You must delete and recreate a new connection with the desired protocol type.

Why is my IKEv1 connection frequently reconnecting?

If your static routing or route based IKEv1 connection is disconnecting at routine intervals, it's likely due to VPN gateways not supporting in-place rekeys. When Main mode is getting rekeyed, your IKEv1 tunnels will disconnect and take up to 5 seconds to reconnect. Your Main mode negotiation time out value determines the frequency of rekeys. To prevent these reconnects, you can switch to using IKEv2, which supports in-place rekeys.

If your connection is reconnecting at random times, follow our troubleshooting guide.

Where can I find configuration information and steps?

See the following articles for more information and configuration steps.

BGP and routing

Is BGP supported on all Azure VPN Gateway SKUs?

BGP is supported on all Azure VPN Gateway SKUs except Basic SKU.

Can I use BGP with Azure Policy VPN gateways?

No, BGP is supported on route-based VPN gateways only.

What ASNs (Autonomous System Numbers) can I use?

You can use your own public ASNs or private ASNs for both your on-premises networks and Azure virtual networks. You can't use the ranges reserved by Azure or IANA.

The following ASNs are reserved by Azure or IANA:

  • ASNs reserved by Azure:

    • Public ASNs: 8074, 8075, 12076
    • Private ASNs: 65515, 65517, 65518, 65519, 65520

  • ASNs reserved by IANA:

    • 23456, 64496-64511, 65535-65551 and 429496729

You can't specify these ASNs for your on-premises VPN devices when you're connecting to Azure VPN gateways.

Can I use 32-bit (4-byte) ASNs?

Yes, VPN Gateway now supports 32-bit (4-byte) ASNs. To configure by using ASN in decimal format, use PowerShell, the Azure CLI, or the Azure SDK.

What private ASNs can I use?

The useable ranges of private ASNs are:

  • 64512-65514 and 65521-65534

These ASNs aren't reserved by IANA or Azure for use, and therefore can be used to assign to your Azure VPN gateway.

What address does VPN Gateway use for BGP peer IP?

By default, VPN Gateway allocates a single IP address from the GatewaySubnet range for active-standby VPN gateways, or two IP addresses for active-active VPN gateways. These addresses are allocated automatically when you create the VPN gateway. You can get the actual BGP IP address allocated by using PowerShell or by locating it in the Azure portal. In PowerShell, use Get-AzVirtualNetworkGateway, and look for the bgpPeeringAddress property. In the Azure portal, on the Gateway Configuration page, look under the Configure BGP ASN property.

If your on-premises VPN routers use APIPA IP addresses (169.254.x.x) as the BGP IP addresses, you must specify one or more Azure APIPA BGP IP addresses on your Azure VPN gateway. Azure VPN Gateway selects the APIPA addresses to use with the on-premises APIPA BGP peer specified in the local network gateway, or the private IP address for a non-APIPA, on-premises BGP peer. For more information, see Configure BGP.

What are the requirements for the BGP peer IP addresses on my VPN device?

Your on-premises BGP peer address must not be the same as the public IP address of your VPN device or from the virtual network address space of the VPN gateway. Use a different IP address on the VPN device for your BGP peer IP. It can be an address assigned to the loopback interface on the device (either a regular IP address or an APIPA address). If your device uses an APIPA address for BGP, you must specify one or more APIPA BGP IP addresses on your Azure VPN gateway, as described in Configure BGP. Specify these addresses in the corresponding local network gateway representing the location.

What should I specify as my address prefixes for the local network gateway when I use BGP?

Important

This is a change from the previously documented requirement. If you use BGP for a connection, leave the Address space field empty for the corresponding local network gateway resource. Azure VPN Gateway adds a host route internally to the on-premises BGP peer IP over the IPsec tunnel. Don't add the /32 route in the Address space field. It's redundant and if you use an APIPA address as the on-premises VPN device BGP IP, it can't be added to this field. If you add any other prefixes in the Address space field, they are added as static routes on the Azure VPN gateway, in addition to the routes learned via BGP.

Can I use the same ASN for both on-premises VPN networks and Azure virtual networks?

No, you must assign different ASNs between your on-premises networks and your Azure virtual networks if you're connecting them together with BGP. Azure VPN gateways have a default ASN of 65515 assigned, whether BGP is enabled or not for your cross-premises connectivity. You can override this default by assigning a different ASN when you're creating the VPN gateway, or you can change the ASN after the gateway is created. You'll need to assign your on-premises ASNs to the corresponding Azure local network gateways.

What address prefixes will Azure VPN gateways advertise to me?

The gateways advertise the following routes to your on-premises BGP devices:

  • Your virtual network address prefixes.
  • Address prefixes for each local network gateway connected to the Azure VPN gateway.
  • Routes learned from other BGP peering sessions connected to the Azure VPN gateway, except for the default route or routes that overlap with any virtual network prefix.

How many prefixes can I advertise to Azure VPN Gateway?

Azure VPN Gateway supports up to 4000 prefixes. The BGP session is dropped if the number of prefixes exceeds the limit.

Can I advertise default route (0.0.0.0/0) to Azure VPN gateways?

Yes. Note that this forces all virtual network egress traffic towards your on-premises site. It also prevents the virtual network VMs from accepting public communication from the internet directly, such RDP or SSH from the internet to the VMs.

Can I advertise the exact prefixes as my virtual network prefixes?

No, advertising the same prefixes as any one of your virtual network address prefixes will be blocked or filtered by Azure. You can, however, advertise a prefix that is a superset of what you have inside your virtual network.

For example, if your virtual network used the address space 10.0.0.0/16, you can advertise 10.0.0.0/8. But you can't advertise 10.0.0.0/16 or 10.0.0.0/24.

Can I use BGP with my connections between virtual networks?

Yes, you can use BGP for both cross-premises connections and connections between virtual networks.

Can I mix BGP with non-BGP connections for my Azure VPN gateways?

Yes, you can mix both BGP and non-BGP connections for the same Azure VPN gateway.

Does Azure VPN Gateway support BGP transit routing?

Yes, BGP transit routing is supported, with the exception that Azure VPN gateways don't advertise default routes to other BGP peers. To enable transit routing across multiple Azure VPN gateways, you must enable BGP on all intermediate connections between virtual networks. For more information, see About BGP.

Can I have more than one tunnel between an Azure VPN gateway and my on-premises network?

Yes, you can establish more than one site-to-site (S2S) VPN tunnel between an Azure VPN gateway and your on-premises network. Note that all these tunnels are counted against the total number of tunnels for your Azure VPN gateways, and you must enable BGP on both tunnels.

For example, if you have two redundant tunnels between your Azure VPN gateway and one of your on-premises networks, they consume 2 tunnels out of the total quota for your Azure VPN gateway.

Can I have multiple tunnels between two Azure virtual networks with BGP?

Yes, but at least one of the virtual network gateways must be in active-active configuration.

Can I use BGP for S2S VPN in an Azure ExpressRoute and S2S VPN coexistence configuration?

Yes.

What should I add to my on-premises VPN device for the BGP peering session?

Add a host route of the Azure BGP peer IP address on your VPN device. This route points to the IPsec S2S VPN tunnel. For example, if the Azure VPN peer IP is 10.12.255.30, you add a host route for 10.12.255.30 with a next-hop interface of the matching IPsec tunnel interface on your VPN device.

Does the virtual network gateway support BFD for S2S connections with BGP?

No. Bidirectional Forwarding Detection (BFD) is a protocol that you can use with BGP to detect neighbor downtime quicker than you can by using standard BGP "keepalives." BFD uses subsecond timers designed to work in LAN environments, but not across the public internet or Wide Area Network connections.

For connections over the public internet, having certain packets delayed or even dropped isn't unusual, so introducing these aggressive timers can add instability. This instability might cause routes to be dampened by BGP. As an alternative, you can configure your on-premises device with timers lower than the default, 60-second "keepalive" interval, and the 180-second hold timer. This results in a quicker convergence time. However, timers below the default 60-second "keepalive" interval or below the default 180-second hold timer aren't reliable. It's recommended to keep timers at or above the default values.

Do Azure VPN gateways initiate BGP peering sessions or connections?

The gateway initiates BGP peering sessions to the on-premises BGP peer IP addresses specified in the local network gateway resources using the private IP addresses on the VPN gateways. This is irrespective of whether the on-premises BGP IP addresses are in the APIPA range or regular private IP addresses. If your on-premises VPN devices use APIPA addresses as BGP IP, you need to configure your BGP speaker to initiate the connections.

Can I configure forced tunneling?

Yes. See Configure forced tunneling.

NAT

Is NAT supported on all Azure VPN Gateway SKUs?

NAT is supported on VpnGw2~5 and VpnGw2AZ~5AZ.

Can I use NAT on VNet-to-VNet or P2S connections?

No.

How many NAT rules can I use on a VPN gateway?

You can create up to 100 NAT rules (Ingress and Egress rules combined) on a VPN gateway.

Can I use / in a NAT rule name?

No. You'll receive an error.

Is NAT applied to all connections on a VPN gateway?

NAT is applied to the connections with NAT rules. If a connection doesn't have a NAT rule, NAT won't take effect on that connection. On the same VPN gateway, you can have some connections with NAT, and other connections without NAT working together.

What types of NAT is supported on Azure VPN gateways?

Only static 1:1 NAT and Dynamic NAT are supported. NAT64 is NOT supported.

Does NAT work on active-active VPN gateways?

Yes. NAT works on both active-active and active-standby VPN gateways. Each NAT rule is applied to a single instance of the VPN gateway. In active-active gateways, create a separate NAT rule for each gateway instance through the "IP configuration ID" field.

Does NAT work with BGP connections?

Yes, you can use BGP with NAT. Here are some important considerations:

  • Select Enable BGP Route Translation on the NAT Rules configuration page to ensure the learned routes and advertised routes are translated to post-NAT address prefixes (External Mappings) based on the NAT rules associated with the connections. You need to ensure the on-premises BGP routers advertise the exact prefixes as defined in the IngressSNAT rules.

  • If the on-premises VPN router uses regular, non-APIPA address and it collides with the virtual network address space or other on-premises network spaces, ensure the IngressSNAT rule will translate the BGP peer IP to a unique, non-overlapped address and put the post-NAT address in the BGP peer IP address field of the local network gateway.

  • NAT isn't supported with BGP APIPA addresses.

Do I need to create the matching DNAT rules for the SNAT rule?

No. A single SNAT rule defines the translation for both directions of a particular network:

  • An IngressSNAT rule defines the translation of the source IP addresses coming into the Azure VPN gateway from the on-premises network. It also handles the translation of the destination IP addresses leaving from the virtual network to the same on-premises network.

  • An EgressSNAT rule defines the translation of the virtual network source IP addresses leaving the Azure VPN gateway to on-premises networks. It also handles the translation of the destination IP addresses for packets coming into the virtual network via those connections with the EgressSNAT rule.

  • In either case, no DNAT rules are needed.

What do I do if my VNet or local network gateway address space has two or more prefixes? Can I apply NAT to all of them? Or just a subset?

You need to create one NAT rule for each prefix you need to NAT because each NAT rule can only include one address prefix for NAT. For example, if the local network gateway address space consists of 10.0.1.0/24 and 10.0.2.0/25, you can create two rules as shown below:

  • IngressSNAT rule 1: Map 10.0.1.0/24 to 100.0.1.0/24
  • IngressSNAT rule 2: Map 10.0.2.0/25 to 100.0.2.0/25

The two rules must match the prefix lengths of the corresponding address prefixes. The same applies to EgressSNAT rules for virtual network address space.

Important

If you link only one rule to the connection above, the other address space will NOT be translated.

What IP ranges can I use for External Mapping?

You can use any suitable IP range that you want for External Mapping, including public and private IPs.

Can I use different EgressSNAT rules to translate my VNet address space to different prefixes to different on-premises networks?

Yes, you can create multiple EgressSNAT rules for the same VNet address space, and apply the EgressSNAT rules to different connections.

Can I use the same IngressSNAT rule on different connections?

Yes, this is typically used when the connections are for the same on-premises network to provide redundancy. You can't use the same Ingress rule if the connections are for different on-premises networks.

Do I need both Ingress and Egress rules on a NAT connection?

You need both Ingress and Egress rules on the same connection when the on-premises network address space overlaps with the virtual network address space. If the virtual network address space is unique among all connected networks, you don't need the EgressSNAT rule on those connections. You can use the Ingress rules to avoid address overlap among the on-premises networks.

What do I choose as "IP configuration ID"?

"IP configuration ID" is simply the name of the IP configuration object you want the NAT rule to use. With this setting, you're simply choosing which gateway public IP address applies to the NAT rule. If you haven't specified any custom name at gateway creation time, the gateway's primary IP address is assigned to the "default" IPconfiguration, and the secondary IP is assigned to the "activeActive" IPconfiguration.

Cross-premises connectivity and VMs

If my virtual machine is in a virtual network and I have a cross-premises connection, how should I connect to the VM?

You have a few options. If you have RDP enabled for your VM, you can connect to your virtual machine by using the private IP address. In that case, you would specify the private IP address and the port that you want to connect to (typically 3389). You'll need to configure the port on your virtual machine for the traffic.

You can also connect to your virtual machine by private IP address from another virtual machine that's located on the same virtual network. You can't RDP to your virtual machine by using the private IP address if you're connecting from a location outside of your virtual network. For example, if you have a point-to-site virtual network configured and you don't establish a connection from your computer, you can't connect to the virtual machine by private IP address.

If my virtual machine is in a virtual network with cross-premises connectivity, does all the traffic from my VM go through that connection?

No. Only the traffic that has a destination IP that is contained in the virtual network Local Network IP address ranges that you specified will go through the virtual network gateway. Traffic has a destination IP located within the virtual network stays within the virtual network. Other traffic is sent through the load balancer to the public networks, or if forced tunneling is used, sent through the Azure VPN gateway.

How do I troubleshoot an RDP connection to a VM

If you're having trouble connecting to a virtual machine over your VPN connection, check the following items:

  • Verify that your VPN connection is successful.
  • Verify that you're connecting to the private IP address for the VM.
  • If you can connect to the VM using the private IP address, but not the computer name, verify that you have configured DNS properly. For more information about how name resolution works for VMs, see Name Resolution for VMs.

When you connect over Point-to-Site, check the following additional items:

  • Use 'ipconfig' to check the IPv4 address assigned to the Ethernet adapter on the computer from which you're connecting. If the IP address is within the address range of the virtual network that you're connecting to, or within the address range of your VPNClientAddressPool, this is referred to as an overlapping address space. When your address space overlaps in this way, the network traffic doesn't reach Azure, it stays on the local network.
  • Verify that the VPN client configuration package was generated after the DNS server IP addresses were specified for the virtual network. If you updated the DNS server IP addresses, generate and install a new VPN client configuration package.

For more information about troubleshooting an RDP connection, see Troubleshoot Remote Desktop connections to a VM.

Customer-controlled gateway maintenance

Which services are included in the Maintenance Configuration scope of Network Gateways?

The Network Gateways scope includes gateway resources in Networking services. There are four types of resources in the Network Gateways scope:

  • Virtual network gateway in the ExpressRoute service.
  • Virtual network gateway in the VPN Gateway service.
  • VPN gateway (Site-to-Site) in the Virtual WAN service.
  • ExpressRoute gateway in the Virtual WAN service.

Which maintenance is supported or not supported by customer-controlled maintenance?

Azure services go through periodic maintenance updates to improve functionality, reliability, performance, and security. Once you configure a maintenance window for your resources, Guest OS and Service maintenance are performed during that window. Host updates, beyond the host updates (TOR, Power etc.) and critical security updates, aren't covered by the customer-controlled maintenance.

Can I get advanced notification of the maintenance?

At this time, advanced notification can't be enabled for the maintenance of Network Gateway resources.

Can I configure a maintenance window shorter than five hours?

At this time, you need to configure a minimum of a five hour window in your preferred time zone.

Can I configure a maintenance window other than Daily schedule?

At this time, you need to configure a daily maintenance window.

Are there cases where I can’t control certain updates?

Customer-controlled maintenance supports Guest OS and Service updates. These updates account for most of the maintenance items that cause concern for the customers. Some other types of updates, including Host updates, are outside of the scope of customer-controlled maintenance.

Additionally, if there's a high-severity security issue that might endanger our customers, Azure might need to override customer control of the maintenance window and push the change. These are rare occurrences that would only be used in extreme cases.

Do Maintenance Configuration resources need to be in the same region as the gateway resource?

Yes

Which gateway SKUs can be configured to use customer-controlled maintenance?

All gateway SKUs (except the Basic SKU for VPN Gateway) can be configured to use customer-controlled maintenance.

How long does it take for maintenance configuration policy to become effective after it gets assigned to the gateway resource?

It might take up to 24 hours for Network Gateways to follow the maintenance schedule after the maintenance policy is associated with the gateway resource.

Are there any limitations on using customer-controlled maintenance based on the Basic SKU Public IP address?

Yes. Gateway resources that use a Basic SKU Public IP address will only be able to have service updates following the customer-controlled maintenance schedule. For these gateways, Guest OS maintenance does NOT follow the customer-controlled maintenance schedule due to infrastructure limitations.

How should I plan maintenance windows when using VPN and ExpressRoute in a coexistence scenario?

When working with VPN and ExpressRoute in a coexistence scenario or whenever you have resources acting as backups, we recommend setting up separate maintenance windows. This approach ensures that maintenance doesn't affect your backup resources at the same time.

I've scheduled a maintenance window for a future date for one of my resources. Will maintenance activities be paused on this resource until then?

No, maintenance activities won't be paused on your resource during the period before the scheduled maintenance window. For the days not covered in your maintenance schedule, maintenance continues as usual on the resource.

How do I find out more about customer-controlled gateway maintenance?

For more information, see the VPN Gateway customer-controlled gateway maintenance article.

Next steps

"OpenVPN" is a trademark of OpenVPN Inc.