Configuring and validating VNet or VPN connections

Applies to: AzureVirtual Network

Home users: This article is only intended for technical support agents and IT professionals. If you're looking for help with a problem, please ask the Microsoft Community.

What does this guide do?

This guided walkthrough provides you step-by-step guidance to configure and validate various Azure VPN and VNet deployments, in scenarios, such as, Transit Routing, VNet-to-VNet, BGP, Multi-Site, Point-to-Site and so on.

Who is it for?

Anyone who is working with Azure VPN or VNet deployment.

How does it work?

This guide provides different Azure VNet connectivity scenarios and a sequence of steps to help you configure and check Azure VPN deployments.

Estimated time of completion

15-45 Minutes.

 

Azure VPN gateways enable flexibility in arranging almost any kind of connected Virtual Network (VNet) topology in Azure: you can connect VNets across regions, between VNet types (ARM vs. Classic), within Azure or with on premise hybrid environment, in different subscriptions, etc.

Please select the scenario

Azure VPN gateways enable flexibility in arranging almost any kind of connected Virtual Network (VNet) topology in Azure: you can connect VNets across regions, between VNet types (ARM vs. Classic), within Azure or with on premise hybrid environment, in different subscriptions, etc.

Please select the scenario

Connecting a virtual network to another virtual network (VNet-to-VNet) via VPN is similar to connecting a VNet to an on-premises site location. Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE. The virtual networks can be in the same or different regions, and from the same or different subscriptions.

VnetToVnet

Figure 1 - VNet-to-VNet with IPsec

If your VNets are in the same region, you may want to consider connecting them using VNet Peering which does not use a VPN gateway, increases throughput and decreases latency, select "Configure and validate VNet Peering" to configure a VNet peering connection.

If your VNets are both created by using Azure Resource Manger deployment model, select “Configure and validate a Resource Manger VNet to a Resource Manager VNet connection” to configure a VPN connection.

If one of the VNets is created by using Azure classic deployment model, the other is created by Resource Manager (ARM), select “Configure and validate a classic VNet to a Resource Manager VNet connection” to configure a VPN connection.

Please select the connection type

A Point-to-Site (P2S) configuration lets you create a secure connection from an individual client computer to a virtual network. Point-to-Site connections are useful when you want to connect to your VNet from a remote location, such as from home or a conference, or when you only have a few clients that need to connect to a virtual network. The P2S VPN connection is initiated from the client computer using the native Windows VPN client. Connecting clients use certificates to authenticate.

PointToSite

Figure 2 - Point-to-Site connection

Point-to-Site connections do not require a VPN device. P2S creates the VPN connection over SSTP (Secure Socket Tunneling Protocol). You can connect a Point-to-Site connection to a VNet by using a different deployment tools and deployment models:

Validate your Point-to-Site connections

The following article walks through common issues with Point-to-Site connections.

Is this information helpful? 

You can add a Site-to-Site (S2S) connection to a VNet that already has a S2S connection, Point-to-Site connection, or VNet-to-VNet connection, this kind of connection is frequently known as a "multi-site" configuration.

Multi-Site

Figure 3 - Multi-Site connection

Azure currently works with two deployment models: Resource Manager and classic. The two models aren't completely compatible with each other. To configure “Multi-site” connection with different models, check the following articles:

Note: These steps don't apply to ExpressRoute and Site-to-Site coexisting connection configurations. See ExpressRoute/S2S coexisting connections for more information about coexisting connections.

Is the information helpful?

BGP is the standard routing protocol usually used in the Internet to exchange routing and reachability information between two or more networks. When it's used in the context of Azure Virtual Networks, BGP enables the Azure VPN Gateways and your on-premises VPN devices. These are known as BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and reachability for those prefixes to go through the gateways or routers involved. BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers. For more information, see Overview of BGP with Azure VPN Gateways.

Configure BGP for a VPN connection

To configure a VPN connection that uses BGP, see How to configure BGP on Azure VPN Gateways by using PowerShell.

Notes

  1. You must enable BGP on the Virtual Network Gateway by creating an AS number for it. Basic gateways do not support BGP. To check the SKU of the gateway go to the Overview section of the VPN Gateway blade in the portal. If your SKU is "Basic", you have to change SKU (resizing the gateway) to "VpnGw1" SKU. This will cause 20-30 minutes downtime. As soon as the Gateway has the correct SKU, the AS can be added through Set-​Azure​Rm​Virtual​Network​Gateway PowerShell command-let. After you configure the AS number, a BGP peer IP for the gateway will be provided automatically
  2. The LocalNetworkGateway must be manually provided with an AS number and a BGP peer address. You can set the Asn and -BgpPeeringAddress values by using New-AzureRmLocalNetworkGateway or Set-AzureRmLocalNetworkGateway PowerShell command-let.
    Note Some AS numbers are reserved for azure and you can't use them as described
    here.
  3. Finally the Connection object must have BGP enabled. You can set the -EnableBGP value to $True through New-AzureRmVirtualNetworkGatewayConnection or Set-AzureRmVirtualNetworkGatewayConnection

Validate the BGP configuration

To check whether BGP is configured correctly, you can run the cmdlet Get-AzureRmVirtualNetworkGateway and get-AzureRmLocalNetworkGateway, then you will notice BGP-related output in the BgpSettingsText part. For example:

BgpSettingsText: {"Asn": AsnNumber,"BgpPeeringAddress": "IP address","PeerWeight": 0}

 

Is this information helpful?

Transitive routing is a specific routing scenario where you connect multiple networks in a ‘daisy chain’ topology. This enables resources in Vnets at either end of the ‘chain’ to communicate with one another through VNets in-between. Without transitive routing, networks or devices peered through a hub cannot reach one another.

Please select the scenario that you want to enable transit routing

 

The key differences between the active-active and active-standby gateways:

  • You have to create two Gateway IP configurations with two public IP addresses
  • You have to set the EnableActiveActiveFeature flag
  • The gateway SKU must be VpnGw1, VpnGw2, VpnGw3

To achieve high availability for cross-premises and VNet-to-VNet connectivity, you should deploy multiple VPN gateways and establish multiple parallel connections between your networks and Azure. Please see Highly Available Cross-Premises and VNet-to-VNet Connectivity for an overview of connectivity options and topology.

To create active-active cross-premises and VNet-to-VNet connections, follow the instructions in Configure active-active S2S VPN connections with Azure VPN Gateways to configure Azure VPN gateway in Active/Active mode.

Note:

1. When you add addresses to the Local Network Gateway for BGP enabled, active-to-active mode only add the /32 addresses of the BGP peers. If you add more they will be considered static routes and take precedence over BGP routes.

2. You must use different BGP ASNs for your on-premises networks connecting to Azure. (If they are the same, you have to change your VNet ASN if your on-premises VPN device already uses the ASN to peer with other BGP neighbors.)

 

Is this information helpful?

You cannot change an Azure VNet gateway type from policy-based to route-based or the other way directly. You must delete the gateway, after that the IP address and the Pre-Shared Key (PSK) will not be preserved. Then you can create a new gateway of desired type. To do this, follow the steps:

  1. Delete any connections associated with the original gateway.
  2. Delete the gateway by using Azure Portal, PowerShell or classic PowerShell:
  3. Follow the steps in Create the VPN gateway to create the new gateway of desired type and complete the VPN setup.

    Note This process will take around 60 minutes.

Is the information helpful? 

You can configure a connection from one Resource Manager VNet to another Resource Manager VNet directly, or configure the connection with IPsec.

Configure VPN connection between Resource Manager VNets

To configure a connection between Resource Manager VNets without IPsec, see Configure a VNet-to-VNet VPN gateway connection using the Azure portal

To configure a connection with IPsec between two Resource Manager VNets, follow the steps 1-5 in Create a Site-to-Site connection in the Azure portal for each VNet.

Note These steps work only for VNets in the same subscription. If your VNets are in different subscriptions, you must use PowerShell to make the connection. See the PowerShell article.

 

Validate VPN connection between Resource Manager VNets

ARMToARM

Figure 4 - Classic VNet connection to ARM VNet

To check your VPN connection is configured correctly, follow the instructions:

Note: The number after virtual network components like "Vnet 1"in the steps below are corresponding to the numbers in Figure 4.

  1. Check for overlapping address spaces in the connected VNets.
    Note: There cannot be overlapping address spaces in Vnet 1 and Vnet 6
  2. Verify ARM Vnet 1 address range is defined accurately in 'Connection object' 4.
  3. Verify ARM Vnet 6 address range is defined accurately in 'Connection object' 3.
  4. Verify that the Pre-Shared-Keys are matching on both connection objects 3 and 4.
  5. Verify the ARM Vnet Gateway 2 VIP is defined accurately in the ARM 'Connection object' 4.
  6. Verify the ARM Vnet Gateway 5 VIP is defined accurately in the ARM 'Connection object' 3.

 

Is this information helpful?

You can create a connection between VNets that are in different subscriptions and in different regions. You can also connect VNets that already have connections to on-premises networks, as long as you have configured the gateway type as route-based.

To configure a connection between a classic VNet and a Resource Manager VNet (ARM), see Connect virtual networks from different deployment models using the portal for more information.

ASMToARM

Figure 5 - Classic VNet connection to ARM VNet

To check the configuration when connect a classic VNet to an ARM VNet, follow the instructions:

Note: The number after virtual network components like "Vnet 1" in the steps below are corresponding to the numbers in Figure 5.

  1. Check for overlapping address spaces in the connected VNets.
    Note: There cannot be overlapping address spaces in Vnet 1 and Vnet 6
  2. Verify ARM VNet 6 address range is defined accurately in the Classic local network definition 3.
  3. Verify Classic VNet 1 address range is defined accurately in the ARM 'Connection object' 4.
  4. Verify the Classic VNet Gateway 2 VIP is defined accurately in the ARM 'Connection object' 4.
  5. Verify the ARM VNet Gateway 5 VIP is defined accurately in the Classic 'Local Network Definition' 3.
  6. Verify that the Pre-Shared-Keys are matching on both connected VNets
    1. Classic Vnet - Local Network Definition 3
    2. ARM Vnet - Connection Object 4

Is this information helpful?

In this scenario, you configure a site to site VPN connection between VNetA and VNetB, also configure a point to site VPN for client to connect to the gateway of VNetA. Then, you want to enable transit routing for the Point-to-Site clients to connect to VNetB, which passes through VNetA. This scenario is supported when BGP is enabled on the site to site VPN between VNetA and VNetB. For more information, see About Point-to-Site VPN routing.

Is this information helpful?

Microsoft Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a dedicated private connection facilitated by a connectivity provider. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure, Office 365, and Dynamics 365.  For more information, you can check https://docs.microsoft.com/en-us/azure/expressroute/expressroute-introduction

ExpressRouteforVnet

Figure 6 - ExpressRoute 'Private Peering' connection to Azure VNets

Note: We recommend that if VNetA and VNetB are in the same geopolitical region that you simply link both VNets to the ExpressRoute circuit instead of configuring transitive routing. If your VNets are in different geopolitical regions that you can also link them to your circuit directly if you have ExpressRoute Premium.

If you have ExpressRoute and Site-to-Site co-existence, transit routing is not supported; see Configure ExpressRoute and Site-to-Site coexisting connections for more information.

If you have enabled ExpressRoute to connect your local networks to an Azure virtual network, you can enable VNet peering between the VNets you want to have transitive routing. To allow your local networks connect to the remote VNet, you must have configure Virtual network peering.

Note: VNet peering is available only for VNets in the same region.

To check whether you have configured transit route for VNet Peering, follow the instructions:

  1. Log on to the portal with an account that has the necessary roles and permissions.
  2. Create a peering between the VNet A and B as in the diagram earlier (Figure 6).
  3. In the pane that appears for the virtual network that you selected, click Peerings in the SETTINGS section.
  4. Click the peering you want to view and Configuration to validate that you have enabled 'Allow Gateway Transit' on the VNetA connected to the ExpressRoute circuit and 'Use Remote Gateway' on the remote VNetB not connected to the ExpressRoute circuit.
    AzureEnableGatewayTransit

Is this information helpful?

When virtual networks are peered, you can also configure the gateway in the peered virtual network as a transit point to an on-premises network. To configure transit route in VNet peering, check Virtual network-to-virtual network connections.

Note Gateway transit isn't supported in the peering relationship between virtual networks created through different deployment models. Both virtual networks in the peering relationship must have been created through Resource Manager for a gateway transit to work.

To check whether you have configured transit route for VNet Peering, follow the instructions:

  1. Log on to the portal with an account that has the necessary roles and permissions.
  2. In the box that contains the text Search resources at the top of the Azure portal, type virtual networks. When Virtual networks appears in the search results, click it.
  3. In the Virtual networks blade that appears, click the virtual network that you want to check the peering setting.
  4. In the pane that appears for the virtual network that you selected, click Peerings in the SETTINGS section.
  5. Click the peering you want to view and validate that you have enabled 'Allow Gateway Transit' and 'Use Remote Gateway' under Configuration.
    AzureEnableGatewayTransit

 

Is this information helpful?

To configure transit routing between VNets, you must enable BGP on all intermediate VNet-to-VNet connections by using the Resource Manager deployment model and PowerShell, see How to configure BGP on Azure VPN Gateways by using PowerShell for the instructions.

Transit traffic through Azure VPN gateway is possible by 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 by using the classic deployment model. Without BGP, manually defining transit address spaces is very error prone, and not recommended.

Note: Classic VNet-to-VNet connections are configured by using the Azure portal (Classic), or by using a network configuration file in the Classic Portal. You cannot create or modify a Classic virtual network through the Azure Resource Manager deployment model or Azure portal. See https://blogs.msdn.microsoft.com/igorpag/2015/10/01/hubspoke-daisy-chain-and-full-mesh-vnet-topologies-in-azure-arm-using-vpn-v1/ for more information on transit routing for Classic VNets.

Is this information helpful?

To configure the transit routing between your on premise network and a VNet with a Site-to-Site connection, you must enabled BGP on all intermediate Site-to-Site connections by using the Resource Manager deployment model and PowerShell, see How to configure BGP on Azure VPN Gateways by using PowerShell for the instructions.

Transit traffic through Azure VPN gateway is possible by 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 by using the classic deployment model. Without BGP, manually defining transit address spaces is very error prone, and not recommended.

Note: Classic Site-to-Site connections are configured by using the Azure portal (Classic), or by using a network configuration file in the Classic Portal. You cannot create or modify a Classic virtual network through the Azure Resource Manager deployment model or Azure portal. See https://blogs.msdn.microsoft.com/igorpag/2015/10/01/hubspoke-daisy-chain-and-full-mesh-vnet-topologies-in-azure-arm-using-vpn-v1/ for more information on transit routing for Classic VNets.

Is this information helpful?

Before you start the implementation of Azure VNet Peering, make sure that you meet the following pre-requisites to configure VNet Peering:

  • The peered virtual networks must exist in the same Azure region.
  • The peered virtual networks must have nonoverlapping IP address spaces.
  • Virtual network peering is between two virtual networks. There's no derived transitive relationship across peerings. For example, if VNetA is peered with VNetB, and VNetB is peered with VNetC, VNetA is not peered to VNetC.

When you meet the requirements, you can follow Create a virtual network peering tutorial to create and configure the VNet Peering.

To check the VNet Peering configuration, use the following methods:

  • Using Azure Portal in the following steps:
  1. Log in to the portal with an account that has the necessary roles and permissions.
  2. In the box that contains the text Search resources at the top of the Azure portal, type virtual networks. When Virtual networks appears in the search results, click it.
  3. In the Virtual networks blade that appears, click the virtual network you want to create a peering for.
  4. In the pane that appears for the virtual network you selected, click Peerings in the SETTINGS section.
  5. Click the peering you want to check the configuration.

CheckVNetPeering

PS C:\Users\User1> Get-AzureRmVirtualNetworkPeering -VirtualNetworkName Vnet10-01 -ResourceGroupName dev-vnetsName                             : LinkToVNET10-02Id                               : /subscriptions/GUID/resourceGroups/dev-vnets/providers/Microsoft.Network/virtualNetworks/VNET10-01/virtualNetworkPeerings/LinkToVNET10-02Etag                             : W/"GUID"ResourceGroupName                : dev-vnetsVirtualNetworkName               : vnet10-01ProvisioningState                : SucceededRemoteVirtualNetwork             : {                                  "Id": "/subscriptions/GUID/resourceGroups/DEV-VNET                                   s/providers/Microsoft.Network/virtualNetworks/VNET10-02"                                   }AllowVirtualNetworkAccess        : TrueAllowForwardedTraffic            : FalseAllowGatewayTransit              : FalseUseRemoteGateways                : FalseRemoteGateways                   : nullRemoteVirtualNetworkAddressSpace : null

 

Is this information helpful?

We're glad you have completed your VPN configuration by using this guide.

We're sorry for that this guide cannot help you. Here are some additional information: