Configuring and validating VNet or VPN connections

Content provided by Microsoft

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.

1

Getting Start

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

VNet-to-VNet VPN connection

Point-to-Site VPN connection

Multi-Site VPN connection

Configure transit routing

Configure BGP for a VPN gateway

Highly available Active-Active VPN connection

Change an Azure VNet gateway type

0

Getting Start

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

VNet-to-VNet VPN connection

Point-to-Site VPN connection

Multi-Site VPN connection

Configure transit routing

Configure BGP for a VPN gateway

Highly available Active-Active VPN connection

Change an Azure VNet gateway type

0

VNet-to-VNet VPN connection

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.

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 "Configureand validateVNet 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 VNetconnection” to configure a VPN connection.

Please select the connection type

Configure and validate VNet peering

Configure and validate a Resource Manager VNet to a Resource Manager VNet (ARM to ARM) connection

Configure and validate a classic VNet to a Resource Manager VNet connection

0

Point-to-Site VPN connection

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.

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?

Yes

No

0

Multi-Site VPN connection

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.

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:

Configure BGP for a VPN gateway

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

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

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-AzureRmLocalNetworkGatewayor Set-AzureRmLocalNetworkGatewayPowerShell command-let.Note Some AS numbers are reserved for azure and you can't use them as described here.

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:

Configure transit routing

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

Configure transit routing in a Point-to-Site connection

Configure transit routing in an ExpressRoute connection

Configure transit routing in a VNet peering connection

Configure transit routing in a VNet-to-VNet connection

Configure transit routing in a Site-to-Site connection

0

Highly available Active-Active VPN connection

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.

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?

Yes

No

0

Change an Azure VPN gateway type after deployment

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:

Delete any connections associated with the original gateway.

Delete the gateway by using Azure Portal, PowerShell or classic PowerShell:

Connect a classic VNet to a Resource Manager VNet

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.

Configure transit routing in a Point-to-Site connection

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 not supported.

Is this information helpful?

Yes

No

0

Configure transit routing in an ExpressRoute connection

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

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 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:

In the pane that appears for the virtual network that you selected, click Peeringsin the SETTINGSsection.

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.

Is this information helpful?

Yes

No

0

Configure transit routing in a VNet peering connection

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.

NoteGateway 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:

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.

Configure transit routing in a Site-to-Site connection

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.

Configure VNet peering for two VNets in the same region

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.