The Azure Preview Portal is generally available and Microsoft is recommending that all new deployments be based on the ARM model. What about your existing ASM deployments? Microsoft will in time provide an automated approach to migrate existing ASM deployments to ARM, however if you are ready to take the plunge here is a PowerShell script to get you started with your migration.

The scripts does two things. Firstly, it allows you to copy your source vhd blob from an existing storage account to a new ARM storage account. Secondly it will create a new ARM based Virtual Machine and attach your copied vhd blob. Ensure that you are on the latest version of the Azure PowerShell module, 1.0.1 at the time of writing this article.

The script assumes that you have provisioned a new ARM Resource Group with the required resources (Storage Account, Virtual Network, Subnets etc).

########################################################################

# Connect to an Azure subscription

Login-AzureRmAccount

# Select your subscription if required

Select-AzureRmSubscription -SubscriptionId "yoursubscriptionid"

########################################################################

Copy a Vhd from an existing storage account to a new storage account

########################################################################

# Source VHD

$srcVhd = "https://sourcesa.blob.core.windows.net/vhds/sourcevhd.vhd"

# Destination VHD name

$destVhdName = "destvhd.vhd"

# Destination Container Name

$destContainerName = "vhds"

# Source Storage Account and Key

$srcStorageAccount = "sourcesa"

$srcStorageKey = "sourcesakey"

# Target Storage Account and Key

$destStorageAccount = "destsa"

$destStorageKey = "destsakey"

# Create the source storage account context (this creates the context, it does not actually create a new storage account)

$srcContext = New-AzureStorageContext -StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey

# Create the destination storage account context

$destContext = New-AzureStorageContext -StorageAccountName $destStorageAccount -StorageAccountKey $destStorageKey

# Start the copy 

$blob1 = Start-AzureStorageBlobCopy -Context $srcContext -AbsoluteUri $srcVhd -DestContainer $destContainerName -DestBlob $destVhdName -DestContext $destContext -Verbose

# check status of copy

$blob1 | Get-AzureStorageBlobCopyState

########################################################################

Create a Virtual Machine from an existing OS disk

########################################################################

$resourceGroupName= "dest-rg"

$location= "SouthEastAsia"

$storageAccountName= "destsa"

$vmName= "destvm"

$vmSize="Standard_A1"

$vnetName= "dest-vnet"

# Get storage account configuration for the target storage account

$StorageAccount = Get-AzureRmStorageAccount -ResourceGroupName $resourcegroupName -AccountName $storageAccountNAme

#Get Virtual Network configuration

$vnet = Get-AzureRmVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroupName

# Create VM from an existing image

$OSDiskName="$vmName-C-01"

$vm = New-AzureRmVMConfig -vmName $vmName -vmSize $vmSize

$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName $resourceGroupName -Location $location -SubnetId $vnet.Subnets[1].Id

$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

$destOSDiskUri = "https://destsa.blob.core.windows.net/vhds/destvhd.vhd"

# Set the OS disk properties for the new VM. If you are migrating a Linux machine use the -Linux switch instead of -Windows

$vm = Set-AzureRmVMOSDisk -VM $vm -Name $OSDiskName -VhdUri $destOSDiskUri -Windows -CreateOption attach

New-AzureRmVM -ResourceGroupName $resourceGroupName -Location $location -VM $vm

########################################################################

The good news is Microsoft has recently announced Azure ExpressRoute for Office365 to establish a private, managed connection to Office 365.

Once ExpressRoute for Office 365 becomes available, you will be able to access both Azure and Office 365 over one network to ensure you get the same availability guarantee, data privacy and control over performance.

ExpressRoute for Office 365 in expected to rollout in the third quarter of 2015! Awesome!

You have probably heard of the term Infrastructure as Code. But what does it mean? In summary, Infrastructure as Code is a set of techniques and practices which help IT Pros remove the burden associated with the day to day build and management of modular infrastructure. It allows IT Pros to build and maintain their modern server environment in a way that is similar to how software developers build and maintain application code.

By defining a set of policies which contains your "code", you can provision infrastructure so it resembles your desired state. You can test on one system then deploy to many. You don't have to worry about manually installing and configuring individual components or consistency across the fleet. You can push these policies out to thousands of servers and have the peace of mind that servers which fall outside the desired configuration state will automatically be remediated.

A great tool to deliver infrastructure as code is Chef which has the ability to manage Azure VMs right out of the box! Chef is also cross platform and can manage Windows, Linux, Mac OS and more.

In this two part blog I will show you how to setup your Chef environment to provision Azure Virtual Machines and then walk you through creating a policy or "cookbook".

Part one of the blog will cover the setup of the Chef environment and provisioning of an Azure VM. Part two will cover policy creation and policy application.

Let's begin!

Chef Basics

I'm not going to go into detail about Chef as there is great material here and I recommend you have a quick read to familiarize yourself before you attempt this walk through. I will however recap the basics before we get started.

This diagram depicts the high level Chef architecture.

Chef has three main architectural components. The Chef Server, Chef Client (Node) and the Chef Workstation.

The Chef Server is our management point and there are two options for the Chef Server, a hosted solution or an on-premises solution. We will be using a hosted solution.

The Chef Client (node) is the agent that sits on the servers you are managing.

The Chef Workstation is our admin workstation where we create our policies and execute our management commands. We run the "knife" command from the Chef Workstation to manage our infrastructure.

There are also these things called "Cookbooks" and "Recipes". These are effectively the policies we define and apply to our servers.

Now that we have that out of the way let's get started!

Preparing the Workstation

First lets prep the workstation. I am using a standard Windows workstation.

We need to create a directory to store our config files and cookbooks.

First create a directory called C:\chef.

Then create a second directory c:\chef\cookbooks

We now need to download our Azure settings file so Chef can communicate with our Azure subscription.

Download your publish settings from here:  https://manage.windowsazure.com/publishsettings/

Save the publish settings file in C:\chef

Creating a managed Chef Server account

Sign up for a hosted Chef account :

https://manage.chef.io/signup

During the signup process you will be asked to create a new organisation.

Once your organization is created download the starter kit.

Note: If you receive a prompt warning you that your keys will be reset it is ok to proceed as we have no existing infrastructure configured as yet.

This starter kit zip file contains your organization config files and keys.

Configuring the Chef Workstation

Extract the content of the chef-starter.zip to C:\chef

Copy all files under chef-starter\chef-repo\.chef to your c:\chef

Your directory should now look something like this:

You should now have 4 files including the Azure publishing file in the root of c:\chef

The PEM files contain your organisation and admin private keys for communication. The knife.rb file contains your knife configuration. We need to edit the knife.rb file.

Open the file in your editor of choice and modify the "cookbook_path" by removing the /../ from the path so it appears as below:

cookbook_path            ["#{current_dir}/cookbooks"]

Also add the following line reflecting the name of your Azure publish settings file.

knife[:azure_publish_settings_file] = "yourfilename.publishsettings"

Your knife.rb file should now look similar to this:

These lines will ensure Knife references our cookbooks directory under c:\chef\cookbooks and also uses our Azure Publish Settings file during Azure operations.

Installing the Chef Development Kit

Next Download and install the ChefDK (Chef Development Kit) to setup your Chef Workstation.

https://downloads.getchef.com/chef-dk/windows

This is straight forward. Let it install in its default location of c:\opscode.

This install will take around 10 minutes.

Confirm your PATH variable contains entries for C:\opscode\chefdk\bin;C:\opscode\chefdk\embedded\bin;c:\users\yourusername\.chefdk\gem\ruby\2.0.0\bin

If they are not there make sure you add these paths!

NOTE THE ORDER OF THE PATH IS IMPORTANT! If your opscode paths are not in the correct order you will have issues.

Reboot your workstation before you continue.

Next we install the Knife Azure extension. This provide Knife with the "Azure Plugin".

Run the following command:

chef gem install knife-azure

To ensure everything is configured correctly run:

knife azure image list

If everything is configured correctly you will see a list of available Azure images scroll through.

Congratulations. The workstation has been setup!

Creating a Virtual Machine with Knife Azure

We will now create an unmanaged VM with chef:

In order to do this we need to use the knife azure server create command.

Here is an example with the parameters highlighted in bold:

knife azure server create --azure-dns-name 'diegotest01' --azure-vm-name 'testserver01' --azure-vm-size 'Small'  --azure-storage-account 'portalvhdxxxx' --azure-source-image 'a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-R2-201411.01-en.us-127GB.vhd' --azure-service-location 'Southeast Asia' --winrm-user azureuser --winrm-password 'myPassword123' --tcp-endpoints 3389:56798

The parameters are self-explanatory. Substitute your particular variables and run.

Once you run the command, pop over to the Azure Portal, you will see your machine begin to provision.

Back at the command prompt:

This winrm error is expected as we have not enabled winrm on the server.

We can then go ahead and initiate an RDP connection from the Azure Portal and Bam! 

This completes part one of the two part blog. Stay tuned for the next blog where we will configure Chef to deploy an Azure Virtual Machine and then automatically provision IIS!

Cheers

Diego

Azure's Multi-Site VNETs allow you to create a fully meshed network architecture that provides great flexibility. I can connect VNETs within region and even across regions. I can also include my on-premises site within the multi-site topology! Very cool!

Another nice gem is that all VNET to VNET traffic flows internally within Microsoft's data centers, so traffic does not traverse the internet.

In this blog I will show you how to configure a multi-site VNET to VNET topology which also includes an on-premises site in the mesh.

If you followed my previous blog here, I showed you how to configure a S2S VPN from an Azure VNET to an on-premises network using an RRAS server as an on-premises gateway.

If you have not read it, I highly advise that you do as I provided a detailed walk-through for creating VNETs and RRAS Demand Dial Interfaces which I will not step through again. I also leverage the S2S VPN connection established in my previous blog as the basis for this scenario.

Setup Overview

The process of creating a Multi-Site VNET mesh is no different to creating multiple S2S VPNs. In fact we will need to establish VPN tunnels between all networks to create the fully meshed topology. My target architecture is as follows:

We are going to complete this exercise in two phases. The first phase will connect vNet1 to vNet2. The second phase will connect vNet2 to our Local On-Premises gateway. Why two phases? This will help demonstrate the connectivity differences between non meshed and meshed topology.

OK, let's get started!

Quick recap of VNET1 to Local On-Premises S2S VPN setup

In my previous blog here, I had established a S2S VPN from Azure vNet1 to my Local On-Premises RRAS gateway. We will use this as our starting point. As such we have an established connection from vNet1 to my Local on-premises network.

We are now here:

Defining our Local Networks

Planning your network is important, and in my case I will have three networks which require three separate non overlapping address spaces. I have defined my network as follows:

Defining these networks allows Azure to perform routing decisions. These networks are then associated with the Azure VPN gateways.

Let's define these networks in the Azure Portal. In the Networks view click on Local Networks.

I already have my Local On-Premises network defined from my previous blog.

We now need to create two additional networks, the first for VNET1 and the second for VNET2.

Click NEW located at the bottom left and select ADD LOCAL NETWORK.

The following screen should be familiar as we have added a local network before in my previous blog. We fill in the Name for the Local Network, VNET1 in our case. Now in the VPN Device IP Address field we enter the IP address of the vNet1 gateway. The IP address of the vNet1 gateway is already available as we had previously created a gateway for vNet1 to establish our S2S VPN to our On-Premises site. 

On the next page we need to define the address space we will be using with VNET1. As per my address space table, we will define 10.10.0.0/16.

Now we need to define our VNET2 details. Repeat the wizard. This time we can leave the VPN Device IP Address blank as we have not created the gateway as yet. My address space for VNET2 is 172.16.0.0/24, so I will define this in the address space section. Once complete, our Local Networks will look like this:

Creating VNET2, our second virtual network

Now that we have defined our local networks, let's move on and create our second virtual network, vNet2.

As vNet1 has been created in Southeast Asia, I will create vNet2 in the West US data center to provide our cross region connectivity.

In the Azure Portal lets Custom Create a new Virtual Network and create our vNet2 in West US.

Let's click through the wizard. We leave DNS and VPN connectivity blank for now and click next to define the address space. Following my address space plan, I am defining 172.16.0.0/24 for vNet2.

Note:  Because we are going to need a subnet for the VPN gateway, I am subdividing my address space and using only 128 of the 256 addresses (/25). This will leave room in the pool for the VPN gateway subnet.

Finish the wizard. You can now see my two VNETs. Each VNET is in a different region.

Establishing a connection between VNET2 and VNET1

We have already established a S2S VPN from vNet1 to my Local on premises network, so I am going to establish a VPN connection between vNet2 and vNet1. As we have done in my previous blog, under the vNet2 page click Configure and enable the site to site VPN by selecting Connect to the local network. For the Local Network select VNET1. Your gateway subnet will automatically be created. Once that is completed. Select SAVE at the bottom of the page.

Let us head back to the dashboard view for vNet2 and create a Dynamic Gateway.

Note: Multi-site connectivity is only supported with Dynamic Gateways.

After 15 minutes our dashboard will look like this:

Take note of the Gateway IP Address.

Once the gateway is created there are three things we need to do.

1: First we need to update our local networks VNET2 entry and add the VPN Address we have now been assigned after creating the dynamic gateway. Head back to Local Networks. Click on VNET2 and select Edit at the bottom of the page and enter the VPN IP Address for VNET2. Once completed our local network will look like this:

2: Next we need to link vNet1 and vNet2 together. As vNet1 is already connected to our Local On-Premises gateway, we need to make the second connection by exporting the network configuration file and making the edits manually. Adding a second connection is not currently supported in the portal.

Let's export the network configuration file. On the Dashboard page Click the Export button at the bottom of the screen.

During the export process you will be asked to select a subscription. If you have one subscription this is straight forward, if you have multiple, select the subscription that is associated with the Virtual Networks we are working on. You will then be prompted to download the file NetworkConfig.xml.

Note: This configuration file contains all your Azure network configuration details. Please back up the file before you modify its contents.

In order to make our changes, we need to open the networkconfig.xml file with a text editor. I recommend Notepad++.

To simplify editing I recommend that you collapse the nodes so it looks like the following:

To connect VNET1 and VNET2 together we need to modify the xml file accordingly. Expand the VirtualNetworkSite that references VNET1 and look for the Gateway section.

Note: You will see that under the <ConnectionsToLocalNetwork> node, we already have a reference to Local, as this was defined in the Azure Portal during the creation of our S2S VPN to our Local on-premises network from my previous blog.

We now add a reference for VNET2. Under the <ConnectionsToLocalNetwork> node we add the following lines:

<LocalNetworkSiteRef name="VNET2">

  <Connection type="IPsec" />

</LocalNetworkSiteRef>

It should look like the following: 

If we now examine the elements for the VirtualNetworkSite referencing VNET2, we will see that under the <ConnectionsToLocalNetwork> node, it already references VNET1 as we have already defined this in the Azure Portal during the creation of our S2S VPN to VNET1, as such we do not need to make any further modifications.

Once this is complete, we save the XML file and import the file back into Azure.

Under the vNet2 Dashboard page, we click NEW on the bottom left of the page and then, Import Configuration.

We will be prompted for the location of the networkconfig.xml file. Once we upload the file, we will be presented with the following screen:

Note: Azure has detected that the configurations of vNet1 and vNet2 need to be updated.

We finish the wizard and allow the Network configuration to update.

3: The final step is to exchange the gateway pre shared keys between VNET1 and VNET2. As VNET1 is now configured for multi-site connectivity we need to load an additional key which must be done through PowerShell. This is pretty straight forward.

For VNET1 we use the following:

Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName VNet2 -SharedKey sharedkey123

Now that we are in multi-site gateway mode, we will also need to reset the pre-shared key between VNET1 and our Local on-premises network.

Set-AzureVNetGatewayKey -VNetName VNet1 -LocalNetworkSiteName Local -SharedKey sharedkey123

For VNET2 we use the following:

Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName VNet1 -SharedKey sharedkey123

Note: The shared key can be anything, but they must match.

Our screen will look like this.

If we have done everything correctly, our dashboards will look as follows:

VNET1 Dashboard:

Note that our nice VPN graphic has now been replaced by a table to show multi-site connectivity.

VNET2 Dashboard:

We have now establish a multi-site VPN from VNET1 to the Local and VNET2 networks. Our connections now looks like this:

Testing connectivity between networks

I have a VM in each VNET to test connectivity. I have allowed ICMP for our testing.

NOTE: You will see that we can ping between VNET1 and VNET2 and VNET1 and Local On-Premises, but VNET2 and Local On-Premises cannot communicate.

VNET1:

I can ping from VNET1 (10.10.x.x) to VNET2 (172.16.x.x). I can ping from VNET1 (10.10.x.x) to Local (192.168.x.x)

VNET2:

Can only ping to VNET1

On-Premises:

Can only ping to VNET1

This demonstrates that VNET connectivity is limited to a single hope. In other words I cannot communicate from VNET2 to Local via VNET1 or from Local to VNET2 via VNET1. I must directly connect VNET2 to Local to have this connectivity.

Completing the fully meshed topology

To complete the full mesh topology we now need to connect VNET2 to our Local On-Premises network and we will do this by once again exporting the networkconfig.xml file and modifying the file as we did previously. This time I am modifying the vNet2 gateway section adding "Local" to the <ConnectionsToLocalNetwork>  node as per below:

Once complete, save the file and import it into the Azure Portal as we did previously. We now need to set our pre-shared key between VNET2 and our Local on-premises VPN:

Set-AzureVNetGatewayKey -VNetName VNet2 -LocalNetworkSiteName Local -SharedKey sharedkey123

Once completed, our dashboard will update to show a multi-site connection for vNet2:

We are now fully meshed from the Azure side. To complete connectivity, I need to add another Demand Dial Interface on my on premises RRAS server to connect back to VNET2. Follow my previous article to walk through the creation of a demand dial interface on RRAS. The only difference in the RRAS Wizard will be to provide the Gateway IP Address of the VNET2 dynamic gateway and to also provide the pre-shared key we used when executing the PowerShell command Set-AzureVNetGatewayKey just above.

Also make sure your static routes are configured correctly:

We verify connectivity back in the Azure Portal VNET2 Dashboard.

You can see that we are now connected to our Local network from vNet2.

Now that we have a meshed network, BAM! we can connect across all networks.

Local On-Premises:

VNET2:

Hope this has been helpful!

In this blog I will show you how to configure a S2S VPN to Azure with RRAS, Hyper-V, a Physical NIC and a router that supports 1:1 NAT (sometimes known as DMZ or gaming mode). It assumes you have knowledge of Hyper-V, Azure and RRAS.

Sound good? Great… Let's get started!

Pre - Requisite check!

Firstly ensure that your ISP does not block the ports required to establish an IKEv2 tunnel. There is plenty of information here on which ports are required. Also please ensure you know how to create a VM in Hyper-V and Azure, how to assign virtual NICs (vNICs) and finally have some working knowledge of RRAS and to be honest, if you don't this article may be hard to follow.

Lab Setup

I have a physical workstation with one physical network card which connects directly to my broadband modem. I have installed Hyper-V 2012 R2 and created a Hyper-V Virtual Switch which connects to this physical network card. My VM virtual NICs (vNICs) will connect to this virtual switch so they can access my physical network. I will be using a private IP range of 192.168.0.x to assign IP addresses to my vNICs, of course you can assign IP addresses in a private range of your choice, just make sure it does not overlap with the private range you will assign in Azure. The logical diagram below serves to illustrate the setup.

Configuring the RRAS VM

Create yourself a Hyper-V Virtual Machine with two network adapters. Both of these adapters should connect to your external virtual switch and sit on your private physical network, (192.168.0.x network in my case) and then deploy Windows Server 2012 R2.

Ensure that you allocate a private IP address to each vNIC and label them so you can easily identify which vNIC will be used for "internal" traffic and which one will have "external" traffic forwarded to it. I've labeled mine "internal" and "external" as per the picture.

Now we need to fine tune the adapter properties of the "external" vNIC. Uncheck all the items as per the picture below and leave only TCP/IP v4 selected. Also ensure that you only have the gateway IP address for your modem set on your "external" vNIC. Ensure you remove it from your "internal" vNIC.

Configuring the Modem for 1:1 NAT

Now, these steps differ for different modems but essentially you need to do some form of Port Forwarding for incoming traffic. In my case I have a mode called DMZ which will forward all ports from the internet to a private IP address of my choosing. I am forwarding to 192.168.0.20 which has been allocated to the RRAS VM vNIC I have labeled as "external".

Configuring the Azure Virtual Network

In any scenario it is usually recommended practice to define your Azure Virtual Network before you start provisioning virtual infrastructure. Very much as in the physical world, planning your network is paramount before rolling out services.

In this case we are going to create a simple Virtual Network. Let's head over to the Azure Portal. In the Azure Portal lets Custom Create a new Virtual Network.

Give it a name of your choice and select your closest region

Now in this section I have specified a DNS server IP address as I am going to spin up a Domain Controller VM in Azure on this network to do our connectivity test. You can however leave this blank as its optional. I am not going to select to configure a S2S VPN at this stage so leave it unchecked.

Note: I will not be showing you have to create a VM in Azure.

This next step is important. We need to define our private address space in Azure. You need to ensure this does not overlap with the range you defined in your home lab. As I am using the 192.168.0.x at home I will used the 10.0.x.x range in Azure. On the screen shot below you can see how I have defined the address space and then sub divided this range into multiple subnets. This provides a nice level of flexibility.

You can however choose to consume the entire space as a single subnet if you wish.

Once you finish the Wizard you will see a new virtual network created under Networks. Time to configure our Local Network so Azure understands how to route traffic between the environments. Click on Local Network.

Now go ahead and Add A Local Network

Provide a Name, I've called mine "Local" and then provide the Public IP address of your broadband modem under the VPN Device IP Address. If you're not sure… Ask Bing :)  https://www.bing.com/search?q=whats+my+ip+address

Note: If your ISP provides you with a DHCP IP Address, the VPN Device IP Address may need to be changed periodically.

On the next page, specify the address space for your home network. In my case it is 192.168.0.x and I'm using a /24 mask to tell Azure that everything from 192.168.0.0 to 192.168.0.255 should be routed across the VPN to my home lab.

Done.

Configuring the Azure S2S VPN and Gateway

Now that you have defined your Local Network in Azure lets create our site to site VPN in Azure.

Head over to the Configure section of your Virtual Network and scroll down to select the Connect to the local network option under Site-To-Site connectivity. Also ensure the your "Local" network is selected in the Local Network drop down box. Azure will now automatically add an additional subnet in your Azure network address space for the Gateway and it's worth noting that IP addresses between x.x.x.0 and x.x.x.3 in each Azure subnet will be reserved for services such as the Gateway.

When you're done click Save down the bottom of the page and return to the dashboard view of your Virtual Network. Go ahead and create the actual gateway device by clicking Create Gateway at the bottom of the page and select Dynamic routing. If dynamic routing does not show as an option, you probably have point to site connectivity enabled.

Azure will now spin up a couple of gateways for you. This will take 15 minutes, so go grab a coffee.

Configuring the home lab RRAS Server

Head back to your home lab RRAS VM. Add the Routing and Remote Access role from Server Manager. Once installed lets open up the Routing and Remote Access console to configure our VPN server.

Right Click your server and select Configure and Enable Routing and Remote Access.

Choose to create a Custom Configuration and then Select VPN access and LAN routing from the list.

Once the Wizard completes you will be prompted to start RRAS. Start the service.

Next step is to click Network Interfaces and right click to create a Demand-Dial Interface. Give it a recognizable name. I named mine Azure.

Continue the Wizard. Choose to connect using a VPN.

Ensure you select IKEv2 as the type of VPN

On the next screen you will be prompted to enter a Destination Address. Enter the Azure Gateway IP Address located on the Azure virtual network dashboard.

On the next screen ensure you have NOT selected to Route IP packets on this interface. I will show you how to do this later in the case you want to add other routes. Ensure everything else is unselected.

You will be prompted to enter credentials on the following page, however we will be using a pre-shared key so just put in any username to activate the Next button and complete the wizard.

Now we need to obtain our pre-shared key from the Azure Portal. Head over to the portal and go to your Virtual Network Dashboard. At the bottom of the page you will have a Manage Key icon which will pop up the window below. Copy this pre-shared key.

Back on your home lab RRAS VM, right click your new Demand Dial interface and select Properties. Under Security, enter your pre-shared key.

We now need to add a static route so RRAS understands what traffic to route to Azure. We could of added this through the Wizard as mentioned earlier but I prefer to do it manually.  Under the IPv4 node right click Static Route and select New Static Route. Ensure your "Azure" interface is selected and specify the network. In my case I have added the 10.10.x.x network and given it a metric of 1 to ensure highest routing priority.

Once this is done go ahead and Connect your interface by right clicking your interface and selecting Connect!

After you confirm your interface is connected in RRAS head over to the Azure dashboard to confirm the same.

Note: if you receive an error from RRAS when connecting to the Azure VPN ensure that your public IP address is still the same as what you specified when creating the Local Network which we did earlier.

Testing connection across the VPN

There's a few ways to test that your connectivity is functioning. Some people use ping, but you need to ensure firewalls are configured appropriately. As I mentioned at the beginning of the article I have spun up a VM in Azure with an IP address of 10.10.10.4. My test will be to open up an RDP session from my home lab RRAS VM to my Azure VM.

BAM! Success

Now let's RDP from the Azure VM to my on-premises RRAS VM. Note I am connecting via the "internal" interface - 192.168.0.120

BAM!

Hope this has been helpful!

Thanks to Matt Hitchcock for reviewing the blog. Matt is a Microsoft Consultant as well as an MVP for Powershell. You can catch his blogs over here: https://sgitpro.com