| title | description | author | ms.service | ms.topic | ms.date | ms.author |
|---|---|---|---|---|---|---|
Azure VPN Gateway FAQ |
Learn about frequently asked questions for VPN Gateway cross-premises connections, hybrid configuration connections, and virtual network gateways. This FAQ contains comprehensive information about point-to-site, site-to-site, and VNet-to-VNet configuration settings. |
cherylmc |
vpn-gateway |
conceptual |
06/19/2024 |
cherylmc |
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.
Yes.
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.
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 will be charged accordingly. See IP Address Pricing.
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.
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.
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 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.
[!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, 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.
-
Delete any connections associated with the gateway.
-
Delete the gateway using one of the following articles:
-
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.
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).
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.
No.
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.
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.
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.
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.
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.
We're limited to using pre-shared keys (PSK) for authentication.
- PowerShell: use "AddressPrefix" to specify traffic for the local network gateway.
- Azure portal: navigate to the Local network gateway > Configuration > Address space.
- Azure portal: navigate to the classic virtual network > VPN connections > Site-to-site VPN connections > Local site name > Local site > Client address space.
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.
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.
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.
No. The Basic SKU isn't available in the portal. You can create a Basic SKU VPN gateway using Azure CLI or PowerShell.
See the following articles:
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.
[!INCLUDE legacy SKU deprecation]
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.
[!INCLUDE vpn devices]
For information about editing device configuration samples, see Editing samples.
For IPsec/IKE parameters, see Parameters.
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.
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.
This section applies to the Resource Manager deployment model.
[!INCLUDE P2S Azure cert]
This section applies to the Resource Manager deployment model.
[!INCLUDE vpn-gateway-point-to-site-faq-include]
[!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 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 (~).
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.
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.
Yes, point-to-site (P2S) VPNs can be used 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 VPN connections that coexist.
[!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?
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.
[!INCLUDE Troubleshoot VM connection]
[!INCLUDE customer-controlled network gateway maintenance]
For more information, see the VPN Gateway customer-controlled gateway maintenance article.
- For more information about VPN Gateway, see About VPN Gateway.
- For more information about VPN Gateway configuration settings, see About VPN Gateway configuration settings.
"OpenVPN" is a trademark of OpenVPN Inc.