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?
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?
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 Forced Tunneling?
Yes. See Configure forced 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:
- For information about compatible VPN devices, see VPN Devices.
- Before configuring your VPN device, check for any Known device compatibility issues for the VPN device that you want to use.
- For links to device configuration settings, see Validated VPN Devices. The device configuration links are provided on a best-effort basis. It's always best to check with your device manufacturer for the latest configuration information.
- For information about editing device configuration samples, see Editing samples.
- For cryptographic requirements, see About cryptographic requirements and Azure VPN gateways.
- For information about IPsec/IKE parameters, see About VPN devices and IPsec/IKE parameters for Site-to-Site VPN gateway connections.
- For IPsec/IKE policy configuration steps, see Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections.
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.
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
Can I use any software VPN client for Point-to-Site that supports SSTP?
No. Support is limited only to the Windows operating system versions listed above.
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 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.
Can I traverse proxies and firewalls using Point-to-Site capability?
Yes. We use SSTP (Secure Socket Tunneling Protocol) to tunnel through firewalls. This tunnel will appear as an HTTPs connection.
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. Both these solutions will work if you 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 gateways using the
-VpnType PolicyBased cmdlet.
Can I configure a Point-to-Site client to connect to multiple virtual networks at the same time?
Yes, it is possible. But the virtual networks cannot have overlapping IP prefixes and the Point-to-Site address spaces must not overlap between the virtual networks.
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.
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?
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.
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. 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? (E.g., 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 table below lists the supported cryptographic algorithms and key strengths configurable by the customers. You must select one option for every field.
|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)|
- DHGroup2048 & PFS2048 are the same as Diffie-Hellman Group 14 in IKE and IPsec PFS. Please see Diffie-Hellman Groups for the complete mappings.
- For GCMAES algorithms, you must specify the same GCMAES algorithm and key length for both IPsec Encryption and Integrity.
- IKEv2 Main Mode SA lifetime is fixed at 28,800 seconds on the Azure VPN gateways
- QM SA Lifetimes are optional parameters. If none was specified, default values of 27,000 seconds (7.5hrs) and 102400000 KBytes (102GB) are used.
- UsePolicyBasedTrafficSelector is an option parameter on the connection. Please 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
Refer to Connect multiple on-premises policy-based VPN devices for more details on how to use this option.
The table below lists the supported Diffie-Hellman Groups for IKE (DHGroup) and IPsec (PFSGroup):
|Diffie-Hellman Group||DHGroup||PFSGroup||Key length|
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 will revert back to the default list of IPsec/IKE proposals and re-start 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 will tear down the existing connection and re-start the IKE handshake to re-establish the IPsec tunnel with the new cryptographic algorithms and parameters. Please 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 will 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. You need to ensure both connection resources have the same policy, othereise the VNet-to-VNet connection will not 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.
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.
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?
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?
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.