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

Instant Recovery Point and Large Disk Azure Backup support

With everything that happens on Azure, and following what has been announced of the increase of the size of the disk in Azure, from 1TB to 4TB, the only missing part of this was the support of Azure Backup to be able to backup and recovery those volumes.

But what changed? Today the Azure Backup job consist of the Two phases:

  1. Taking a VM snapshot
  2. Transferring the VM snapshot to Azure Backup Vault

So, depending how many recovery points you configure on your policy, it will only be available a recovery point when both phases are complete. With the introduction of Instant Recovery Points feature on Azure Backup, a recovery point is created as soon as the snapshot is finished. That means that you RPO and RTO can be reduced significantly.

You can use the same restore flow on Azure Backup, to restore from this instant recovery point. For this you can identify the recovery point from a snapshot in the Azure Portal, using the Snapshot as a recovery point type. Once the snapshot is on the Azure Backup Vault, the recovery point type will change to Snapshot and Vault.

By default, the snapshots are retained for 7 days. This will allow you to complete restore way faster, from these snapshots and at the same time, reducing the time required to copy the backup from the vault to the storage account where you want to restore.

Instant Recovery Point Features

Please note that all the features are not yet available, this is still on preview

  1. Ability to see snapshot taken as part of backup job to be available for recovery without waiting for data transfer to complete.Note: that this will reduce the wait on snapshot to be copied to vault before triggering restore. Also, this will eliminate the additional storage requirement we have for backing up premium VMs.
  2. As part of above feature, we will also enable some data integrity checks. This will take some additional time as part of backup. We will be relaxing these checks as we move and so it will reduce backup times.
  3. Support for 4TB unmanaged disks
  4. Ability to use original storage accounts (even when VM has disks are distributed across storage accounts). This will make restores faster for a wide variety of VM configurations.Note: this is not same as overriding the original VM.
  5. Ability to do above things for managed disks.


Is important to know that when you enable this feature you will notice the following:

Since the snapshot are store on the Azure Backup vault, to reduce the recovery point and reduce the restore time, you will see some increase on the storage cost, corresponding to the snapshots that are store for 7 days (if you go with the defaults).

When you are doing a restore from a snapshot recovery point for a Premium VM, you will might see a temporary storage location being used while the VM is created, as part of the restore.

Once you enable the preview feature, you can’t revert, that means you can go back and all the future backups will use this feature.

If you have the VMs with Managed Disks, this feature is not support yet. Although if you have VMs that are using Managed Disks, is supported, but they will be using the normal backup (the Instant Recovery Point will not be used, in this case). Virtual Machines migrations from unmanaged and managed are not supported.

If you want to try this feature, run the following commands:

  1. Open PowerShell with elevated privilege
  2. Login to your Azure Account
  3. Select the subscription you want to enable the Instant Recovey Point feature
    Get-AzureRmSubscription –SubscriptionName “<SUBSCRIPTION_NAME>” | Select-AzureRmSubscription
  4. Register for the preview
    Register-AzureRmProviderFeature -FeatureName “InstantBackupandRecovery” –ProviderNamespace Microsoft.RecoveryServices



Marcos Nogueira
Azure MVP
Twitter: @mdnoga

Enhancements on Azure Portal Notifications

If you are like me and your Azure Portal is your center on your day, you probably see this enhancement of the notifications. I found very useful and make my day way more productive when I need to setup new resources/environments.

Be able to deploy different resources through the Azure Portal and from the notifications access those resources is something that I did think why Microsoft doesn’t improve those little details, but guess what? They listen! WOW.

So, from the notification you can now, access direct where the resource is located, as well as pin to the dashboard.

In some case this could be very useful for some Azure Administrators that use the Azure Portal, because they can easily jump into the Resource Group, where you create the resource, instead of going back to the main menu and navigate to where the resource is. Another aspect is on the visualization on the Azure Portal notification areas, because now you have these two buttons, now you can identify way better what you deployed and find the resource that you are looking for.

You might think, why did I spend time writing this blog post, and the answer is very simple. THEY DID LISTEN! LOL! And besides that, this little thing makes, at least me, my days way better. Could not be much for you, but it’s for me.


Marcos Nogueira
Azure MVP
Twitter: @mdnoga