Azure VNet-to-VNet VPN configuration – Part 3

In this blog post series, I will cover what you need to configure to create a VNet-to-VNet VPN between to Azure regions on the same subscription. Although is about the same configuration if you want to configure two different VNets on different subscriptions. You can see the part 1 post here and the part 2 here.

So, at this moment I have both networks setup with their gateways configured. Although I need to connect them to each other. For this I only have to choose one of them to setup the connection. Because I’m on the same subscription, this is one of the difference. If I want to connect different VNets on different subscription, I have to setup the connection on both sides. What they need to have in common is the Shared Key.

It’s exactly the same when setup a Site-to-Site VPN. One of the requirements after setup the networks, is connecting them with the Shared Key

How to connect two VNet gateways using Azure Portal

After this running successful, we need to connect both networks. To be able to do it just follow the steps bellow:

  1. On the VNet created, navigate to Connections (in this case I used the network that I configured with PowerShell – SW-EUS2-WUS2-VPN)
  2. Click Add
  3. When the Add connection blade open, you need to configure all the requirement fields:
    1. Name – This is where you insert the name of the VPN connection.
    2. Connection type – This is where you define which of connection want to use. VNet-to-VNet is used between two networks on Azure, Site-to-Site is used between a Azure network and on premise network. ExpressRoute is used between an Azure network and an existing circuit.
    3. First virtual network gateway – This is the network that you are configuring from.
    4. Second virtual network gateway – This where you want to connect. In this case, is the other region.
    5. Shared key – This is the key that is shared on both side to stablish the connection. This key only accepts number and/or letters.
  4. Then click OK
  5. After the connection it’s created, it will connect automatically.




Marcos Nogueira
Azure MVP
Twitter: @mdnoga

Azure VNet-to-VNet VPN configuration – Part 2

In this blog post series, I will cover what you need to configure to create a VNet-to-VNet VPN between to Azure regions on the same subscription. Although is about the same configuration if you want to configure two different VNets on different subscriptions. You can see the previous post here.

On Part 1, I create one side of the network using Azure Portal. Although, that is not my usual method of configured Network and VPN. I prefer using PowerShell. One of the reasons is related to the fact that I spin a lot of environments, for testing, for Proof-of-Concepts, and for production.

As a result of that, I always look a way to automate and be more productive. But the main reason is not only those, it’s more related to the fact that I found through PowerShell I’m reducing the human mistake factor! Yes, as everyone, I also do mistakes!

How to configure using PowerShell

Now that we have on side of the net configured (see previous post), I need to configure the network on a different region. For this I will show my script that I use to configure. I’m sure there way other ways (probably better than mine), to script that. I like to keep it simple.

Here is the script:

#Setting all the variables

$Sub = “Your_Subcription_Name”


$Region = “East US 2”

$VNetName = “SW-EUS2-VM-VNET”

$SubName = “SW-EUS2-VM-SUBNET”

$GWSubName = “GatewaySubnet”

$VNetPrefix11 = “”

$SubPrefix = “”

$GWSubPrefix = “”

$GWName = “SW-EUS2-WUS2-VPN”


$GWIPconfName = “SW-EUS2-WUS2-VPN-CON”


#1 – Login to Azure


#2 – Select the appropriated subscription


Select-AzureRmSubscription -SubscriptionName $Sub

#3 – Create the Resource Group

New-AzureRmResourceGroup -Name $RG -Location $Region

#4 – Create the VNets and Subnets

$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name $SubName -AddressPrefix $SubPrefix

$gwsub = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix

New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG -Location $Region -AddressPrefix $VNetPrefix11 -Subnet $subnet,$gwsub1

#5 – Request the Public IP

$gwpip = New-AzureRmPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Region -AllocationMethod Dynamic

#6 – Create the gateway

$vnet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG

$gwsubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name “GatewaySubnet” -VirtualNetwork $vnet

$gwipconf = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $gwsubnet -PublicIpAddress $gwpip

New-AzureRmVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG -Location $Region -IpConfigurations $gwipconf -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1


So, after you run you should have both VNets configured. Although they are not connected yet. That is the next step.



Marcos Nogueira
Azure MVP
Twitter: @mdnoga

Azure VNet-to-VNet VPN configuration – Part 1

In this blog post series, I will cover what you need to configure to create a VNet-to-VNet VPN between to Azure regions on the same subscription. Although is about the same configuration if you want to configure two different VNets on different subscriptions.

A lot of my costumers think that you setup multiple VNets on Azure they automatically are connected to each other, because it’s Azure. That is a huge misconception, a huge one. A VNet is a totally isolated/segregated network from the other ones, only if you manually decide to connect them, they will communicate.

Even if you have ExpressRoute and you have multiple VNets on the same subscription, you manually have to connected them. This is called peering.

On the scenario bellow I will demonstrate how you can setup a VNet-to-VNet VPN between 2 VNets in Azure on different regions.

So, this is my architecture that I will show how to configure:

In this scenario, you have to configure both sides, that means that I will use the Azure Portal for one and PowerShell on the other. Then you have both ways that you can configure the VNet-to-VNet VPN. Let’s start.

Before to begin the configuration, I already have my VNets configured and being used. I just want to create a VPN between the two regions.

How to configure using Azure Portal

To setup a VNet-to-VNet VPN follow these steps:

  1. On the Azure Portal, navigate to the Virtual network gateways
  2. On the Virtual network gateways blade, click on Create Virtual network gateway button.
  3. At the Create virtual network gateway blade, fill the required information
    1. Name – This is the name of the VNet gateway.
      NOTE: I highly recommend that you create a name convention that make sense for your organization. In this scenario, I use the direction of the connection on the name (EX: SW-WUS2-EUS2-VPN, this means that the connection is from West US 2 to East US 2)
    2. Gateway type – This is the type of gateway. Instead of a VPN, you can have an ExpressRoute configuration.
    3. VPN type – This is where you define if you want your VPN based on policy or routing.
    4. SKU – This is where you define the SKU of the VPN. The SKU will give you different configurations and throughputs. For more information visit About VPN Gateway configuration settings
    5. Virtual Network – This is where you will choose the network that you want to connect the VPN.
    6. Public IP Address – The Public IP is the IP that you will have your other VPN connected too. It’s recommended that you create a new Public IP for the VPN.
    7. Subscription – This is where you configure the subscription
    8. Location – This is the region that you are creating all the configuration.
  4. After configured all the requirements fields, click on Create

  5. After Azure create all the resources to enable the VNet gateway you need to configure the other region’s network.



Marcos Nogueira
Azure MVP
Twitter: @mdnoga

How to configure your Hybrid Network Solution with Azure

By combining the existing Azure networking features, it is possible to configure Azure virtual networks to function as an extension of your on-premises datacenter. You have the option of deploying multi-tier production workloads in Azure and making them available via Azure internal load balancers to on-premises users. Another possibility is to implement your lab or test environment in a dedicated subnet or a virtual network that is fully isolated from your production systems. You can also leverage Azure virtual machines to host your disaster recovery site. ExpressRoute introduces a range of additional options, including hybrid applications with tiers distributed between the on-promises network and the Azure virtual network, high-volume backups, or cross-premises big data workloads.

When architecting solutions such as these, in addition to implementing site-to-site or ExpressRoute connectivity as described in the previous posts (see here and here, respectively), you can also take advantage of a variety of Azure networking technologies, such as load balancers, user-defined routes, network security groups, or forced tunneling. You also have the option to leverage a large assortment of virtual appliances available on Microsoft Azure Marketplace, including products from such vendors as Barracuda, CheckPoint, Cohesive Networks, Fortinet, or SecureSphere.

These technologies also allow you to build another type of hybrid solution: one with an Azure virtual network emulating an on-premises perimeter network (also referred to as a DMZ, demilitarized zone, and screened subnet).

The recommended design in this case involves the following components:

  • Cross-premises connectivity. Cross-premises connectivity by using either a site-to-site VPN or ExpressRoute connection.
  • A pair of virtual network appliances. A pair of virtual network appliances with traffic filtering capabilities placed on the edge of the virtual network.
  • A load balancer. A load balancer positioned in front of the pair of virtual network appliances, handling distribution of incoming traffic and failover in case of an appliance failure. The load balancer further enhances security by filtering traffic according to its load balancing and NAT rules.
  • A user-defined route. A user-defined route applied to the Azure VNP gateway subnet redirecting the incoming traffic to the load balancer. Optionally, you can create a route that will bypass load balancer to allow for direct access to a management subnet.
  • User-defined routes. User-defined routes applied to subnets hosting virtual machines running your production workloads, which allow you to control the flow of outbound traffic.
  • Forced tunneling. Forced tunneling to ensure that the outbound traffic to the Internet flows via an on-premises traffic inspection system for auditing purposes.
  • Network security groups. Network security groups to restrict traffic between virtual machines behind the pair of network virtual appliances.

The specifics of implementing forced tunneling depend on the cross-premises connectivity method. In particular, with site-to-site VPN, you need to create a user-defined route with the default route of, and set its next hop type to be the VPN gateway. In addition, if there are multiple on-premises sites connected to the virtual network, you need to define the default site where traffic will be routed. To do this, run the Set-AzureRmVirtualNetworkGatewayDefaultSite Azure PowerShell cmdlet. ExpressRoute, on the other hand, relies on the advertisement of default routes via private peering sessions.

Note: If you decide to forced tunneling, then you must apply user-defined routing to override the default route for every subnet that requires direct Internet connectivity. To use the Azure-based Key Management Server (KMS) license activation of Windows virtual machines, you need to define a route for the prefix with the next hop type set to Internet.


Marcos Nogueira
Twitter: @mdnoga

Creating an ExpressRoute VPN on Azure

To understand deeper what are the options you have to connect your datacenter/organization with Azure, I recommend read this older post. On this post I want to share what do you need to configure so you can implement an ExpressRoute VPN between your datacenter and your Azure environment.

Implementing ExpressRoute connectivity is a multi-step process that involves interaction with the connectivity or exchange provider to establish physical connectivity. The process relies on the coordinated effort between the provider and Microsoft to provision the virtual circuit. On a high level, it consists of the following sequence of tasks:

  1. Satisfy prerequisites. This includes designating an Azure subscription in which the ExpressRoute connection will be defined, selecting a provider available at your location, and establishing physical connectivity with the provider.
  2. Initiate creation of an ExpressRoute circuit. At the present time, you can use either Azure PowerShell or the Azure portal to accomplish this task. As part of the circuit creation, you will need to specify several circuit properties, including:
    1. Provider. The connectivity or exchange provider that you selected.
    2. Peering location. The location hosting the physical connection.
    3. Tier. Either the Standard or Premium, where the latter represents the Premium add-on option.
    4. Data metering. Either Unlimited or Metered determining the billing model.
    5. This task automatically generates a service key that uniquely identifies the circuit. You need to relay its value to the provider, which will complete the provisioning process.
  3. Configure routing. In general, connectivity providers that deliver Layer 3 services will manage this part of the process for you. When using Layer 2 connectivity providers, satisfying routing prerequisites and configuring routing are your responsibilities, as described on the one of the previous post (see here).
  4. Link virtual networks to ExpressRoute circuits. This is necessary in private peering scenarios. Virtual networks do not have to reside in the same subscription as the ExpressRoute circuit.

Note: Following the proper sequence and timing between the first and the second step are important because billing of an ExpressRoute circuit starts the moment that Microsoft issues the corresponding service key.

When creating an ExpressRoute circuit, you can determine the progress of its provisioning by monitoring its two properties:

  • Service provider provisioning state. This represents progress on the connectivity provider’s side and can take one of the following values:
    • NotProvisioned
    • Provisioning
    • Provisioned
  • This represents progress on the Microsoft side, and includes:
    • Enabling
    • Enabled
    • Disabling

The circuit must be in the Provisioned service provider provisioning state and have the Enabled status in order to be operational. You can identify the values of both properties by using Azure PowerShell (Get-AzureRmExpressRouteCircuit) or the Azure portal.

If you encounter routing issues, you should also check a couple of additional BGP related parameters:

  • BGP provisioning state. This indicates whether BGP-based peering is in effect on the Microsoft edge.
  • Advertised public prefixes state. Use this to detect mismatches between advertised prefixes and ASNs.


Marcos Nogueira
Twitter: @mdnoga