VPN Gateway FAQ

Connecting to virtual networks

Can I connect virtual networks in different Azure regions?

Yes. In fact, there is 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 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.

What are my cross-premises connection options?

The following cross-premises 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). This connection does not 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 does not require a VPN device. For more information, see VNet-to-VNet.
  • Multi-Site – This is a variation of a Site-to-Site configuration that allows you to connect multiple on-premises sites to a virtual network. For more information, see Multi-Site.
  • ExpressRoute – ExpressRoute is a direct 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 that is not behind a NAT.

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.

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.

What is a policy-based (static-routing) gateway?

Policy-based gateways implement policy-based VPNs. Policy-based VPNs encrypt and direct packets through IPsec tunnels based on the combinations of address prefixes between your on-premises network and the Azure VNet. The policy (or Traffic Selector) is usually defined as an access list in the VPN configuration.

What is a route-based (dynamic-routing) gateway?

Route-based gateways implement the route-based VPNs. Route-based VPNs use "routes" in the IP forwarding or routing table to direct packets into their corresponding tunnel interfaces. The tunnel interfaces then encrypt or decrypt the packets in and out of the tunnels. The policy or traffic selector for route-based VPNs are configured as any-to-any (or wild cards).

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 VNet 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?

No. You have to create your gateway first to get the IP address. The IP address changes if you delete and recreate your VPN gateway.

Can I request a Static Public IP address for my VPN gateway?

No. Only Dynamic IP address assignment is supported. However, this does not mean that the IP address changes 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 re-created. The VPN gateway public IP address doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.

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 auto-generated 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 are 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.
  • Classic portal: add each range that you want sent through the gateway for your virtual network on the Networks page under Local Networks.

Can I configure Force Tunneling?

Yes. See Configure force tunneling.

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 need to 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 VPN gateway?

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

A VPN 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 cannot 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.

More information about gateway types, requirements, and throughput

For more information, see About VPN Gateway configuration settings.

Site-to-Site connections and VPN devices

What should I consider when selecting a VPN device?

We have 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?

See the following links for 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 will be torn down. When traffic starts flowing in either direction, the tunnel will be 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.

Point-to-Site - native Azure certificate authentication

What client operating systems can I use with Point-to-Site?

The following client operating systems are supported:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8 (32-bit and 64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows 10
  • OSX version 10.11 for Mac (El Capitan)
  • macOS version 10.12 for Mac (Sierra)

How many VPN client endpoints can I have in my Point-to-Site configuration?

We support up to 128 VPN clients to be able to connect to a virtual network at the same time.

Can I traverse proxies and firewalls using Point-to-Site capability?

Azure supports two 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 TCP port that 443 SSL uses.

  • IKEv2 VPN

    IKEv2 VPN is a standards-based IPsec VPN solution that uses UDP port 500 and 4500 and IP protocol no. 50. Firewalls do not always open these ports, so there is 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?

By default, the client computer will not reestablish the VPN connection automatically.

Does Point-to-Site support auto-reconnect and DDNS on the VPN clients?

Auto-reconnect and DDNS are 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 do not 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 networks at the same time?

No. A Point-to-Site client can only connect to resources in the VNet in which the virtual network gateway resides.

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. Refer to the list of supported client operating systems.

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

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

Point-to-Site - RADIUS authentication

What client operating systems can I use with Point-to-Site?

The following client operating systems are supported:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8 (32-bit and 64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows 10
  • OSX version 10.11 for Mac (El Capitan)
  • macOS version 10.12 for Mac (Sierra)

How many VPN client endpoints can I have in my Point-to-Site configuration?

We support up to 128 VPN clients to be able to connect to a virtual network at the same time.

Can I traverse proxies and firewalls using Point-to-Site capability?

Azure supports two 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 TCP port that 443 SSL uses.

  • IKEv2 VPN

    IKEv2 VPN is a standards-based IPsec VPN solution that uses UDP port 500 and 4500 and IP protocol no. 50. Firewalls do not always open these ports, so there is 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?

By default, the client computer will not reestablish the VPN connection automatically.

Does Point-to-Site support auto-reconnect and DDNS on the VPN clients?

Auto-reconnect and DDNS are 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 do not 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 networks at the same time?

No. A Point-to-Site client can only connect to resources in the VNet in which the virtual network gateway resides.

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. Refer to the list of supported client operating systems.

Is RADIUS authentication supported on all Azure VPN Gateway SKUs?

RADIUS authentication is supported for VpnGw1, VpnGw2, and VpnGw3 SKUs. If you are using legacy SKUs, RADIUS authentication is supported on Standard and High Performance SKUs. It is not supported on the Basic Gateway SKU.

Is RADIUS authentication supported for the classic deployment model?

No. RADIUS authentication is not supported for the classic deployment model.

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 VPN Site-to-Site 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 is no change in the maximum number of SSTP connections supported on a gateway with RADIUS authentication. It remains 128. The maximum number of connections supported is 128, irrespective of whether the gateway is configured for SSTP, IKEv2, or both.

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.

VNet-to-VNet and Multi-Site connections

The VNet-to-VNet FAQ applies to VPN Gateway connections. If you are looking for 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 using 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. Refer to the VPN Gateway pricing page for details. If you are connecting your VNets using VNet Peering, rather than VPN Gateway, see the Virtual Network pricing page.

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

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

Is VNet-to-VNet traffic secure?

Yes, it is 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 are not in the same subscription, do the subscriptions need to be associated with the same AD 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 public Azure and the Chinese / German / US Gov Azure instances. For these scenarios, consider using a Site-to-Site VPN connection.

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 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 does not support connecting virtual machines or cloud services that are not 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 are connected together.

Can I used 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 be using 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.

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 is not 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 be alphanumerical string of length between 1 to 128 characters.

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.

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 Azure VpnGw1, VpnGw2, VpnGw3, Standard, and HighPerformance VPN gateways. The Basic SKU is not supported.

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 is not allowed.

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

The following table lists the supported cryptographic algorithms and key strengths configurable by the customers. You must select one option for every field.

IPsec/IKEv2 Options
IKEv2 Encryption AES256, AES192, AES128, DES3, DES
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 Seconds (integer; min. 300/default 27000 seconds)
KBytes (integer; min. 1024/default 102400000 KBytes)
Traffic Selector UsePolicyBasedTrafficSelectors ($True/$False; default $False)
Important
  1. DHGroup2048 & PFS2048 are the same as Diffie-Hellman Group 14 in IKE and IPsec PFS. See Diffie-Hellman Groups for the complete mappings.
  2. For GCMAES algorithms, you must specify the same GCMAES algorithm and key length for both IPsec Encryption and Integrity.
  3. IKEv2 Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways
  4. QM SA Lifetimes are optional parameters. If none was specified, default values of 27,000 seconds (7.5 hrs) and 102400000 KBytes (102GB) are used.
  5. UsePolicyBasedTrafficSelector is an option parameter on the connection. See the next FAQ item for "UsePolicyBasedTrafficSelectors"

Does everything need to match between the Azure VPN gateway policy and my on-premises VPN device configurations?

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
  • IKE integrity algorithm
  • DH Group
  • IPsec encryption algorithm
  • IPsec integrity algorithm
  • PFS Group
  • Traffic Selector (*)

The SA lifetimes are local specifications only, do not need to match.

If you enable UsePolicyBasedTrafficSelectors, 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. 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, see Connect multiple on-premises policy-based VPN devices.

Which Diffie-Hellman Groups are supported?

The table below lists the supported Diffie-Hellman Groups for IKE (DHGroup) and IPsec (PFSGroup):

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 ECP284 384-bit ECP
24 DHGroup24 PFS24 2048-bit MODP

For more information, see RFC3526 and RFC5114.

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.

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.

BGP

Is BGP supported on all Azure VPN Gateway SKUs?

No, BGP is supported on Azure Standard and HighPerformance VPN gateways. Basic SKU is NOT supported.

Can I use BGP with Azure Policy-Based VPN gateways?

No, BGP is supported on Route-Based VPN gateways only.

Can I use private ASNs (Autonomous System Numbers)?

Yes, you can use your own public ASNs or private ASNs for both your on-premises networks and Azure virtual networks.

Are there ASNs reserved by Azure?

Yes, the following ASNs are reserved by Azure for both internal and external peerings:

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

You cannot specify these ASNs for your on premises VPN devices when connecting to Azure VPN gateways.

Are there any other ASNs that I can't use?

Yes, the following ASNs are reserved by IANA and can't be configured on your Azure VPN Gateway:

23456, 64496-64511, 65535-65551 and 429496729

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

No, you must assign different ASNs between your on-premises networks and your Azure VNets if you are 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 creating the VPN gateway, or change the ASN after the gateway is created. You will need to assign your on-premises ASNs to the corresponding Azure Local Network Gateways.

What address prefixes will Azure VPN gateways advertise to me?

Azure VPN gateway will advertise the following routes to your on-premises BGP devices:

  • Your VNet address prefixes
  • Address prefixes for each Local Network Gateways connected to the Azure VPN gateway
  • Routes learned from other BGP peering sessions connected to the Azure VPN gateway, except default route or routes overlapped with any VNet prefix.

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

Yes.

Please note this will force all VNet egress traffic towards your on-premises site, and will prevent the VNet 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 the Azure platform. However you can 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 could advertise 10.0.0.0/8. But you cannot advertise 10.0.0.0/16 or 10.0.0.0/24.

Can I use BGP with my VNet-to-VNet connections?

Yes, you can use BGP for both cross-premises connections and VNet-to-VNet connections.

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 will NOT advertise default routes to other BGP peers. To enable transit routing across multiple Azure VPN gateways, you must enable BGP on all intermediate VNet-to-VNet connections.

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

Yes, you can establish more than one S2S VPN tunnel between an Azure VPN gateway and your on-premises network. Please note that all these tunnels will be 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 will consume 2 tunnels out of the total quota for your Azure VPN gateway (10 for Standard and 30 for HighPerformance).

Can I have multiple tunnels between two Azure VNets 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 ExpressRoute/S2S VPN co-existence configuration?

Yes.

What address does Azure VPN gateway use for BGP Peer IP?

The Azure VPN gateway will allocate a single IP address from the GatewaySubnet range defined for the virtual network. By default, it is the second last address of the range. For example, if your GatewaySubnet is 10.12.255.0/27, ranging from 10.12.255.0 to 10.12.255.31, the BGP Peer IP address on the Azure VPN gateway will be 10.12.255.30. You can find this information when you list the Azure VPN gateway information.

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. 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. Specify this address 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?

Azure Local Network Gateway specifies the initial address prefixes for the on-premises network. With BGP, you must allocate the host prefix (/32 prefix) of your BGP Peer IP address as the address space for that on-premises network. If your BGP Peer IP is 10.52.255.254, you should specify "10.52.255.254/32" as the localNetworkAddressSpace of the Local Network Gateway representing this on-premises network. This is to ensure that the Azure VPN gateway establishes the BGP session through the S2S VPN tunnel.

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

You should add a host route of the Azure BGP Peer IP address on your VPN device pointing to the IPsec S2S VPN tunnel. For example, if the Azure VPN Peer IP is "10.12.255.30", you should add a host route for "10.12.255.30" with a nexthop interface of the matching IPsec tunnel interface on your VPN device.

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 are 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 are having trouble connecting to a virtual machine over your VPN connection, check the following:

  • Verify that your VPN connection is successful.
  • Verify that you are 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 are connecting. If the IP address is within the address range of the VNet that you are 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 VNet. 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.

Virtual Network FAQ

You view additional virtual network information in the Virtual Network FAQ.

Next steps