Posted on

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

Posted on

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.

 

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga

Posted on

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

Posted on

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

Posted on

Azure Resource Manager PowerShell Module

If you are like me that like to have all the tools on your desktop/laptop, special the Azure PowerShell module, now your live is way easier. Not long time ago, you had to download the Azure PowerShell module through the Web Platform. But now, there a simpler way.

I found this when I need to replace my Surface Pro. Through PowerShellGet module, all the modules related to Azure are on GitHub, so it is way simpler to get always the most update version of the cmdlets to manage Azure. The PowerShellGet comes on Windows 10. To verify if you are running the most updated version, run the following cmdlet:

Get-Module PowerShellGet -list | Select-Object Name,Version,Path

You should get an output like this:

To install all the Azure Resource Manager modules, just follow the steps and you will all the magic happens.

  1. Open an PowerShell session with elevated privileges (Administrator mode)
  2. Run the following command
    Install-Module AzureRM -AllowClobber

    Note: by default, PowerShell Gallery is configured as untrusted repository, so you have trust in this repository to be able to install the Azure RM module.
  3. Answer Yes or Yes to All on the output of the command to be able to continue the installation
  4. Just watch the progress bar finishes
  5. Import the Azure RM module, by running the command
    Import-Module AzureRM

To verify if the install was successful, you can use the following command:

Get-Module AzureRM -list | Select-Object Name,Version,Path

Cheers,

Marcos Nogueira
Azure MVP
azurecentric.com
Twitter: @mdnoga