| title | description | author | ms.service | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|
Azure VPN Gateway FAQ |
Get answers to frequently asked questions about VPN Gateway connections and configuration settings. |
cherylmc |
azure-vpn-gateway |
conceptual |
07/10/2024 |
cherylmc |
This article answers frequently asked questions about Azure VPN Gateway cross-premises connections, hybrid configuration connections, and virtual network (VNet) gateways. It contains comprehensive information about point-to-site (P2S), site-to-site (S2S), and VNet-to-VNet configuration settings, including the Internet Protocol Security (IPsec) and Internet Key Exchange (IKE) protocols.
Yes. There's no region constraint. One virtual network can connect to another virtual network in the same Azure region or in a different region.
Yes.
If you specify a Domain Name System (DNS) server or servers when you create your virtual network, the virtual private network (VPN) gateway uses those DNS servers. Verify that your specified DNS servers can resolve the domain names needed for Azure.
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.
No. However, costs for any additional public IPs are charged accordingly. See IP address pricing.
Azure VPN Gateway supports the following cross-premises gateway connections:
- Site-to-site: VPN connection over IPsec (IKEv1 and IKEv2). This type of connection requires a VPN device or Windows Server Routing and Remote Access. For more information, see Create a site-to-site VPN connection in the Azure portal.
- Point-to-site: VPN connection over Secure Socket Tunneling Protocol (SSTP) or IKEv2. This connection doesn't require a VPN device. For more information, see Configure server settings for point-to-site VPN Gateway certificate authentication.
- 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 (IKEv1 and IKEv2). It doesn't require a VPN device. For more information, see Configure a VNet-to-VNet VPN gateway connection.
- Azure ExpressRoute: ExpressRoute is a private connection to Azure from your wide area network (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 What is Azure VPN Gateway?.
-
Site-to-site (IPsec/IKE VPN tunnel) configurations are between your on-premises location and Azure. You can connect from any of your computers located on your premises to any virtual machine (VM) 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). The appliance 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 built-in VPN client.
As part of the point-to-site configuration, you install a certificate and a VPN client configuration package. The package contains the settings that allow your computer to connect to any virtual machine or role instance within the virtual network.
This configuration is useful 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 by using a route-based VPN type for your gateway. Route-based VPN types are called dynamic gateways in the classic deployment model.
For normal functioning, the VPN gateway must establish a secure connection with the Azure control plane, facilitated through public IP addresses. This connection relies on resolving communication endpoints via public URLs. By default, Azure VNets use the built-in Azure DNS service (168.63.129.16) to resolve these public URLs. This default behavior helps ensure seamless communication between the VPN gateway and the Azure control plane.
When you're implementing a custom DNS within a VNet, it's crucial to configure a DNS forwarder that points to Azure DNS (168.63.129.16). This configuration helps maintain uninterrupted communication between the VPN gateway and the control plane. Failure to set up a DNS forwarder to Azure DNS can prevent Microsoft from performing operations and maintenance on the VPN gateway, which poses a security risk.
To help ensure proper functionality and healthy state for your VPN gateway, consider one of the following DNS configurations in the VNet:
- Revert to the Azure DNS default by removing the custom DNS within the VNet settings (recommended configuration).
- Add in your custom DNS configuration a DNS forwarder that points to Azure DNS (168.63.129.16). Depending on the specific rules and nature of your custom DNS, this setup might not resolve the issue as expected.
No. VPN clients connected in point-to-site to the same VPN gateway can't communicate with each other.
When two VPN clients are connected to the same point-to-site VPN gateway, the gateway can automatically route traffic between them by determining the IP address that each client is assigned from the address pool. However, if the VPN clients are connected to different VPN gateways, routing between the VPN clients isn't possible because each VPN gateway is unaware of the IP address that the other gateway assigned to the client.
Microsoft is aware of reports about a network technique that bypasses VPN encapsulation. This is an industry-wide issue. It affects any operating system that implements a Dynamic Host Configuration Protocol (DHCP) client according to its RFC specification and has support for DHCP option 121 routes, including Windows.
As the research notes, mitigations include running the VPN inside a VM that obtains a lease from a virtualized DHCP server to prevent the local network's DHCP server from installing routes altogether. You can find more information about this vulnerability in the NIST National Vulnerability Database.
No.
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.
As of October 1, 2023, you can't create a policy-based VPN gateway through the Azure portal. All new VPN gateways are automatically 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 Azure PowerShell or the Azure CLI to create the policy-based gateways.
Previously, the older gateway product tiers (SKUs) didn't support IKEv1 for route-based gateways. Now, most of the current gateway SKUs support both IKEv1 and IKEv2.
[!INCLUDE Route-based and policy-based table]
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, you must delete and re-create the gateway by taking the following steps. This process takes about 60 minutes. When you create the new gateway, you can't retain the IP address of the original gateway.
-
Delete any connections associated with the gateway.
-
Delete the gateway by using one of the following articles:
-
Create a new gateway by using the gateway type that you want, and then complete the VPN setup. For steps, see the site-to-site tutorial.
Yes, you can define traffic selectors by using the trafficSelectorPolicies attribute on a connection via the New-AzIpsecTrafficSelectorPolicy Azure PowerShell command. For the specified traffic selector to take effect, be sure to enable policy-based traffic selectors.
The custom-configured traffic selectors are proposed only when a 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 among all connection modes (Default, InitiatorOnly, and ResponderOnly).
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. Make sure that your gateway subnet contains enough IP addresses to accommodate future growth and possible new connection configurations.
Although 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, and so on). Verify that your existing gateway subnet meets the requirements for the configuration that you want to create.
No.
Azure Standard SKU public IP resources must use a static allocation method. You'll have the public IP address for your VPN gateway as soon as you create the Standard SKU public IP resource that you intend to use for it.
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 requirement applies to all gateway SKUs except the Basic SKU. The Basic SKU currently supports only Basic SKU public IP addresses. We're working on adding support for Standard SKU public IP addresses for the Basic SKU.
For non-zone-redundant and non-zonal gateways that were previously created (gateway SKUs that don't 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's assigned to your VPN gateway. The only time that the VPN gateway IP address changes is when the gateway is deleted and then re-created. The public IP address doesn't change when you resize, reset, or complete other internal maintenance and upgrades of your VPN gateway.
We're taking action to ensure the continued operation of deployed VPN gateways that use Basic SKU public IP addresses until the retirement of Basic IP in September 2025. Before this retirement, we will provide customers with a migration path from Basic to Standard IP.
However, Basic SKU public IP addresses are being phased out. Going forward, when you create a VPN gateway, you must use the Standard SKU public IP address. You can find details on the retirement of Basic SKU public IP addresses in the Azure Updates announcement.
Azure VPN Gateway uses preshared key (PSK) authentication. We generate a PSK when we create the VPN tunnel. You can change the automatically generated PSK to your own by using the Set Pre-Shared Key REST API or PowerShell cmdlet.
Can I use the Set Pre-Shared Key REST API to configure my policy-based (static routing) gateway VPN?
Yes. You can use the Set Pre-Shared Key REST API and PowerShell cmdlet to configure both Azure policy-based (static) VPNs and route-based (dynamic) routing VPNs.
You're limited to using preshared keys for authentication.
For the Azure Resource Manager deployment model:
- Azure PowerShell: Use
AddressPrefixto specify traffic for the local network gateway. - Azure portal: Go to local network gateway > Configuration > Address space.
For the classic deployment model:
- Azure portal: Go to the classic virtual network, and then go to VPN connections > Site-to-site VPN connections > local site name > local site > Client address space.
Yes, network address translation traversal (NAT-T) is supported. Azure VPN Gateway does not perform any NAT-like functionality on the inner packets to or from the IPsec tunnels. In this configuration, ensure that the on-premises device initiates the IPSec tunnel.
Yes. You can deploy your own VPN gateways or servers in Azure from Azure Marketplace or by creating your own VPN routers. You must configure user-defined routes in your virtual network to ensure that traffic is routed properly between your on-premises networks and your virtual network subnets.
They're required for Azure infrastructure communication. Azure certificates help protect them by locking them down. Without proper certificates, external entities, including the customers of those gateways, can't cause any effect on those endpoints.
A virtual network gateway is fundamentally a multihomed device. One network adapter taps into the customer private network, and one network adapter faces the public network. Azure infrastructure entities can't tap into customer private networks for compliance reasons, so they need to use public endpoints for infrastructure communication. An Azure security audit periodically scans the public endpoints.
No. The Basic SKU isn't available in the portal. You can create a Basic SKU VPN gateway by using the Azure CLI or the Azure PowerShell steps.
See the following articles:
The Standard and High Performance SKUs will be deprecated on September 30, 2025. You can view the announcement on the Azure Updates site. 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.
[!INCLUDE legacy SKU deprecation]
We've validated a set of standard site-to-site VPN devices in partnership with device vendors. You can find a list of known compatible VPN devices, their corresponding configuration instructions or samples, and device specifications in the About VPN devices article.
All devices in the device families listed as known compatible should work with virtual networks. To help configure your VPN device, refer to the device configuration sample or link that corresponds to the appropriate device family.
[!INCLUDE vpn devices]
See Editing device configuration samples.
See Default IPsec/IKE parameters.
This behavior is expected for policy-based (also known as static routing) VPN gateways. When the traffic over the tunnel is idle for more than five minutes, the tunnel is torn down. When traffic starts flowing in either direction, the tunnel is reestablished immediately.
We support Windows Server 2012 Routing and Remote Access servers for site-to-site cross-premises configuration.
Other software VPN solutions should work with the gateway, as long as they conform to industry-standard IPsec implementations. For configuration and support instructions, contact the vendor of the software.
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 addresses of the point-to-site client must be different from the public IP addresses that the site-to-site VPN device uses, 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 addresses where a site-to-site VPN connection is configured on the same VPN gateway.
[!INCLUDE P2S FAQ All]
[!INCLUDE P2S Azure cert]
RADIUS authentication is supported for all SKUs except the Basic SKU.
For earlier SKUs, RADIUS authentication is supported on Standard and High Performance SKUs.
No.
RADIUS requests are set to time out after 30 seconds. User-defined timeout values aren't currently supported.
Yes.
What are the connectivity requirements to ensure that the Azure gateway can reach an on-premises RADIUS server?
You need a site-to-site VPN connection to the on-premises site, with the proper routes configured.
Can traffic to an on-premises RADIUS server (from the VPN gateway) be routed over an ExpressRoute connection?
No. It can be routed only over a site-to-site connection.
Is there a change in the number of supported SSTP connections with RADIUS authentication? What is the maximum number of supported SSTP and IKEv2 connections?
There's no change in the maximum number of supported SSTP connections on a gateway with RADIUS authentication. It remains 128 for SSTP, but it depends on the gateway SKU for IKEv2. For more information on the number of supported connections, see About gateway SKUs.
What is the difference between certificate authentication through a RADIUS server and Azure native certificate authentication through the upload of a trusted certificate?
In RADIUS certificate authentication, the authentication request is forwarded to a RADIUS server that handles the certificate validation. This option is useful if you want to integrate with a certificate authentication infrastructure that you already have through RADIUS.
When you use Azure for certificate authentication, the 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 integration for multifactor authentication?
If your multifactor authentication is text based (for example, SMS or a mobile app verification code) 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.
Yes, RADIUS authentication is supported for both IKEv2 and SSTP VPN.
RADIUS authentication is supported for the OpenVPN protocol.
[!INCLUDE vpn-gateway-vnet-vnet-faq-include]
If you want to enable routing between your branch connected to ExpressRoute and your branch connected to a site-to-site VPN, you need to set up Azure Route Server.
Can I use a VPN gateway to transit traffic between my on-premises sites or to another virtual network?
-
Resource Manager deployment model
Yes. See the BGP and routing section for more information.
-
Classic deployment model
Transiting traffic via a VPN gateway is possible when you use the classic deployment model, but it relies on statically defined address spaces in the network configuration file. Border Gateway Protocol (BGP) isn't currently supported with Azure virtual networks and VPN gateways via the classic deployment model. Without BGP, manually defining transit address spaces is error prone and not recommended.
Does Azure generate the same IPsec/IKE preshared key for all my VPN connections for the same virtual network?
No. By default, Azure generates different preshared keys for different VPN connections. However, you can use the Set VPN Gateway Key REST API or PowerShell cmdlet to set the key value that you prefer. The key must contain only printable ASCII characters, except space, hyphen (-), or tilde (~).
No. All VPN tunnels, including point-to-site VPNs, share the same VPN gateway and the available bandwidth.
Can I configure multiple tunnels between my virtual network and my on-premises site by 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 autonomous system (AS) path prepending to help make routing decisions when BGP is enabled. A shorter AS path is preferred in BGP path selection.
No. Such a setting is reserved for ExpressRoute gateway connections. If you want to influence routing decisions between multiple connections, you need to use AS path prepending.
Yes. You can use point-to-site VPNs with the VPN gateways connecting to multiple on-premises sites and other virtual networks.
Yes, this is supported. For more information, see Configure ExpressRoute and site-to-site coexisting connections.
[!INCLUDE vpn-gateway-ipsecikepolicy-faq-include]
[!INCLUDE vpn-gateway-faq-bgp-include]
Yes. See Configure forced tunneling.
[!INCLUDE vpn-gateway-faq-nat-include]
If my virtual machine is in a virtual network and I have a cross-premises connection, how should I connect to the VM?
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 specify the private IP address and the port that you want to connect to (typically 3389). You 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 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's contained in the virtual network's local network IP address ranges that you specified goes through the virtual network gateway.
Traffic that 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 you use forced tunneling, the traffic is sent through the VPN gateway.
[!INCLUDE Troubleshoot VM connection]
[!INCLUDE customer-controlled network gateway maintenance]
For more information, see the Configure customer-controlled gateway maintenance for VPN Gateway article.
- For more information about VPN Gateway, see What is Azure VPN Gateway?.
- For more information about VPN Gateway configuration settings, see About VPN Gateway configuration settings.
"OpenVPN" is a trademark of OpenVPN Inc.