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.

 

 

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
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”

$RG = “RG-SW-EUS2-VM”

$Region = “East US 2”

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

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

$GWSubName = “GatewaySubnet”

$VNetPrefix11 = “10.11.0.0/16”

$SubPrefix = “10.11.0.0/24”

$GWSubPrefix = “10.11.254.0/24”

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

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

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

 

#1 – Login to Azure

Login-AzureRmAccount

#2 – Select the appropriated subscription

Get-AzureRmSubscription

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.

 

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Disaster Recovery solution within Azure – Part 2

On the previous post (see here), I create the Recovery Service vault that is required to configured the Site Recovery infrastructure to protect the workloads, in order to have a Disaster Recovery solution within Azure. In the post, I will show how you can protect your workloads (Azure VMs) from one region into another region.

First step is to prepare the infrastructure. Azure Site Recovery have many scenarios that you can protect the workloads, but in these case, I will only cover the Azure VM protection to another region.

As mention on the previous blog post, my workloads are running on the West US 2 region. After creating the Recovery Services vault on East US 2 region, I need to prepare the infrastructure.

To step up the infrastructure follow the steps:

  1. On the Recovery Services vault, click on Site Recovery, under GETTING STARTED
  2. It will open another blade. Click on Prepare Infrastructure

  3. Select Azure – PREVIEW, under Where are your machines located?
  4. Make sure that you select To Azure on Where do you want to replicate your machines to?
  5. Click OK

  6. Fill all the details required:
    1. Source Location – is the region where your workloads are running
    2. Azure virtual machine deployment model – make sure that you select Resource Manager
    3. Source resource group – is the recourse group where your workloads are running
      NOTE: If you have more than one resource group on the same region, you must run this setup again, to add more workloads located on another resource group.
  7. Click OK to proceed
  8. Select the workloads that you want to protect.
  9. Click OK

  10. On the Configure settings blade, click Create target resources button to conclude the preparation of the infrastructure.
    NOTE: Under Target location, by default choose the location where you create the Recovery Services vault, although you can select another region where do you want to replicate too. It’s not recommend that you choose the location where your workloads are running.

  11. If you do want to change the default settings, then you can click on Customize. Otherwise you can skip to the last step.
    There are two different settings that you can customize:

    1. Resource group, Network, Storage and Availability sets – On this setting you will configure witch resource group, network, storage account and availability set your workload will run, when your failover the virtual machine.
    2. Replication policy – is where you change the name of the replication policy, RPO and the frequency of the replication.
  12. If you want to change any of the following setting:
    1. Target resource group – This is the Resource group where your workload will run in case of failover. On the drop down, list you will see only the resource group available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    2. Target virtual network – This is where you can define witch network your workload will run in case of failover. On the drop down, list you will see only the networks available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    3. Storage accounts
      1. Target Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
      2. Cache Storage – This is where your workload will be replicated too. On the drop down, list you will see only the storages accounts available on the region that you previous select. Although you can either create a new (by default) or use an existing one.
    4. Availability sets – This is availability set that your workload will be running in case of failover. On the drop down, list you will see only the availability sets available on the region that you previous select. Although you can either create a new (by default), use an existing one or choose not to set an availability set (Not Applicable option).
  13. After you change the settings that you want, click OK

  14. If you want to change the policies setting, these are your options:
    1. Choose by creating a new policy or an existing one.
      NOTE: If you are running these for the first time, it’s recommended that you create a new policy. Although if you are running for the second or more times, you can either choose an existing policy (if the settings are the same) or create a new policy, if the settings are different. It’s not recommended that you create new policies with the same settings.
    2. Name – This is where you can change the name of the policy
    3. Recovery point retention – This is where you can configure how long do you want to keep each recovery point.
    4. App consistent snapshot frequency – This is where you can choose the frequency of the replication.
  15. After you change the settings that you want, click OK

  16. Click Enable replication button, to start the workload protection.

  17. After the configuration is done. Azure will start to replicate the workload from on region to another. The time of the replication it will depend on the size of the disks attached to the workload.

All this process is live. That means you don’t have any downtime while Azure is doing the initial replication.

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Disaster Recovery solution within Azure – Part 1

We know that in the Public Cloud, special Azure, we are cover by the SLA. Although some organizations like to be redundant where it comes to critical workloads. In this post I will cover how you can setup a Disaster Recovery solution within Azure.

In this case I have all my critical workloads running on West US 2 region and the East US 2 is my disaster recovery site.

The first step is to create the Recovery Vault. The Recovery Services Vault is feature inside Azure that makes everything work, as also known by Azure Site Recovery. You can have as many Recovery Services Vaults as you want. Each Recovery Services vault will have its own storage account associated, that means if you create more than one Recovery Service vault you will have more than one storage accounts.

When you create a Recovery Services vault, you need to choose the region where you want to store those workloads. That means the Recovery Services vault is acting as your destination, because of this it’s not recommended to create on the same region that your workloads are running.

To create the Recovery Services vault, follow the steps:

  1. Click on the Create Recovery vaults button
  2. Insert the following details
    1. Name
    2. Select the subscription that you want to create the Recovery Services Vault
    3. Create or Select an existing Resource Group
    4. Choose your location (this need to be a different region of the workloads that you want to protect)
  3. Click on the Create.
  4. After the creation of the Recovery Services vault, you just create the infrastructure require on Azure to setup all the services need.

There are some considerations when you create a Recovery Services vault to protect you workloads within Azure (this considerations are only for this scenario).

  1. At this present moment, you only create the infrastructure that supports Azure Site Recovery and Azure Backup. You are not done yet. The next step is to configure either or both services (Site Recovery and Backup).
  2. If you want to use the Recovery Services for Site Recovery, you need to prepare the infrastructure that will support that. In this case, you need to decide what type of workloads you want to protect from where to Azure. If you want to protect workloads within Azure (i.e between regions), your source workloads (where they are running) should be in a different region. For optimal utilization try to use the “direct” DR Azure site (EastóWest or North óSouth).
  3. You can protect different regions to the same Recovery Service vault. Although the workloads should not be running on the region, that your Recovery Services is created.
  4. You don’t need to setup any VNet-to-VNet between the regions. Recovery Services uses the backbone of Azure, to connect to the workloads that you want to protect.

 

Cheers,

Marcos Nogueira
Azure MVP

azurecentric.com
Twitter: @mdnoga

Deploy ARM Templates using Key Vault

I’ve been deploying to Azure a lot of resources, one of my favorite things is to create templates where I can reuse for other situations. But sometimes, and in some situations, you need to increase the security. That is where I started to leverage the Key Vault to store my secrets.

Over the years, I have been creating a linked template reference where the main template passes parameters and the key vault references to the linked template. Although the template is uploaded to a storage blob container.

Let me exemplify. Imagine that you have the following scenario, you want to leverage the Azure Portal to deploy ARM Templates and you want to use the Key Vault to store the secrets. How I can do it? Although, your Manager concern is, since the URI is public how I can protect the storage container?

The way that I have been getting around on this situation is using private blob storage in conjunction with SAS.

Step 1 – Use Azure File Copy to copy your template to the storage account. Azure File Copy will give you a SAS token. Then use the token to deploy.

Step 2 – On Azure Resource Group Deployment, you have an option to override the template parameters.

Step 3 – You only need to append the SAS token to the final URL.

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga