Cross-Premises Connectivity with Site-to-Site VPN – Modernizing Your Infrastructure With Hybrid Cloud (Part 15)

image in our “Modernizing Your Infrastructure with Hybrid Cloud” series, Matt Hester described how to create a virtual network “in the cloud” in Microsoft Azure in order to support cloud-based Virtual Machines and their ability to communicate with each other and with the outside world.  We of course have the ability to connect to our VMs individually using Remote Desktop connections, but if we’re going to treat the location of these cloud based machines as just an extension of our own datacenter, we’re going to want to have a secured connection to them.

That’s what the VPN Gateway is all about.

In this article I’m going to show you step-by-step how to connect your Azure virtual network to your on-premises network.  Here are the steps we’ll go through:

  • Collect Some Information
  • Define the “Local Network”
  • Enable Site-to-Site
  • Create the Gateway
  • Configure the Local VPN Device

And as an added bonus, I might throw in a little something extra.


I hope you’ll think so.  But for starters, let’s begin where Matt left off.  I have an Azure subscription with a virtual network named AzureNet1, located in the South Central US datacenter region.  In my scenario, I want to connect this Azure network to my Fabrikam office (Fabrikam was recently purchased by Contoso).  Once the connection is established, I will want to join servers in that office to the domain.

Here’s what the AzureNet1 network dashboard tab currently looks like.  Note the two virtual machines currently in this network; a domain controller and an application server.

AzureNet1 Dashboard

As you can see on the configure tab, I’ve set up two subnet ranges (their purposes are obvious based on the names I’ve given them) as part of an 8-bit-masked 10.x.x.x subnet.:


Notice that I’ve also defined my DNS server as  My domain controller has that address.


Collect Some Information

Before we start adding the site-to-site connection, I need to collect some information so that I can carefully use it to make the correct configurations.  As you probably know first-hand, when doing networking configuration it’s easy to make simple little mistakes that cause everything to NOT work, so let’s make quick note of a couple of important items:

  • Local Network Address Range
  • Gateway Address

Your local network address range refers to the addressing of your local network.  By that name, though, it’s a little misleading.  “Local” assumes you’re connecting your Azure network to some “Local” office.  But in reality it could be some other branch office or even another virtual network somewhere else in the Azure world.  So, just think of “local network” as being “the network I’m connecting to my Azure network”.  And I’ll keep using “local network” in “quotes” throughout the rest of this article for just that reason.

In our example, my Fabrikam network is with a 16-bit subnet mask.  (

The Gateway Address is the externally accessible IP address of the gateway.  In the Fabrikam network, let’s say that I have a VPN device connected to the Internet with an external Internet-exposed address of  I will also have a gateway address on the AzureNet1 gateway, but that address will be assigned when I create the gateway for my virtual network.  So, in simple terms, the gateway address is the connection point on either end of the VPN connection.


Define the “Local Network”

Before enabling the site-to-site connectivity and creating the gateway, we need to define the “local network” Fabrikam, so that our network knows what addresses it will be routing to over the VPN through the gateways.

To define my “local network” (which I’ll name “Fabrikam”), I clicked on +New in the bottom-left corner of the Azure portal, and selected Network Services –> Virtual Network –> Add Local Network.

Add Local Network

I give my local network a name, an optionally the gateway address (I can add it later if I don’t know it right now.)


Then on the next screen I add the address spaces that exist at my “local network” at Fabrikam.


Once created, you’ll see it in the list on the local networks tab.

Local Networks


Enable Site-to-Site

Back on my AzureNet1 network and on the Configure tab, now I can check the box to enable Site-to-Site Connectivity.  Notice that a couple of things change.  I now will choose which “local network” I’m going to connect to (Fabrikam), and it also requires (and defines) a “Gateway Subnet” for me.


“Hey Kevin.. What’s that ‘ExpressRoute’ option?”

That’s actually what my friend Keith Mayer is going to cover in tomorrow’s article in the series. I’ll include the link to his article after it’s published.

UPDATE: Here is Keith’s article – Modernizing Your Infrastructure with Hybrid Cloud – Step-by-Step: Cross-Premises Connectivity with Azure ExpressRoute (Part 16)

Anyway, after checking Connect to the local network, clicking Save starts the process of updating the network configuration.  After a couple of minutes it completes, and now back on the dashboard tab we see this:


This means the gateway is in defined, but not actually created.  That’s our next step.


Create the Gateway

At the bottom of the dashboard screen, click on Create Gateway.


Notice when you click it that you are given a choice between a static and dynamic routing VPN gateway.

“What’s the difference?”

Your choice will be based on a number of factors.  Often the VPN hardware you are using will limit you to one or the other.  A static routing VPN gateway is one that routes traffic based on policy definitions (which is why it’s often referred to as a Policy-based VPN).  Packets are routed through the gateway based on a defined policy; an “access list”.  A dynamic routing VPN gateway, also known as a “route-based VPN”, is a simple forwarding of packets between two networks.  If the network doesn’t locally contain the destination for this packet, I’ll assume the gateway knows where to send it.  And if it’s known by the gateway as existing on the other network, it sends it securely through the tunnel.  For more information about these choices, and about various devices and gateway types that support either static or dynamic VPN gateways, check out this excellent documentation.  Even if your device is not on that list, it may still work if your hardware supports

In my scenario I’m creating a simple tunnel to a device that supports the other end of dynamically routed VPN, so I’ll choose Dynamic Routing.  Creating the gateway does take a good amount of time (as much as 15 minutes), so be patient.  Eventually our display will go from this:

Creating Gateway

…to this:


…and eventually, this:


Notice that we’ve been assigned an official actual external gateway IP address.  We’re still not actually connected. (Connected would be GREEN in color.)  We haven’t addressed the configuration of the “local network” side of our connection yet.  At the bottom of the page you see a Connect button:


But let’s not click that just yet.  We still need to…

Configure the Local VPN Device

Other than collecting some information about our Fabrikam network, we’ve only focused on the AzureNet1 side of our VPN tunnel.  We still need to create the gateway on our Fabrikam network.

On the AzureNet1 dashboard, notice this hyper-link towards the right-side of the page:

VPN Device Script

Clicking on Download VPN Device Script this brings up a very interesting page that allows us to specify what kind of hardware (or software) we have on the “local network” side of our connection.  The beauty of this is that, based on our selection of hardware (or even Windows Server 2012  and 2012 R2 Routing-and-Remote-Access (RRAS) working as your gateway), you are generating a script that can then be used to automatically configure your gateway on the “local network” side.

VPN Device Configuration Script

Once we’ve selected our Vendor, Platform, and Version, and clicked the check mark, we’re immediately sent a text file containing the configuration script for our selected device.

VPN Device Script

Use this script to configure your device, establish the connection from the local network, and then come back to the Azure network dashboard and click connect.  And if you’ve done everything correctly, you should see something happy (and GREEN) like this:


“What kind of hardware do you have on Fabrikam’s network, Kevin?”

I don’t know.  I’m not actually using a local network.  For this demonstration, I’ve actually connected my AzureNet1 network, which is located in the South Central US datacenter region to a Fabrikam virtual network that host in the Central US datacenter region and manage through an entirely different Azure subscription.  So.. I’m doing Site-to-Site between two Azure virtual networks. That’s my “something extra” that I promised earlier.  Now I’m going to show you what I needed to do to make that connection work.

Connecting two Azure networks via a Site-to-Site VPN requires two things:

  1. Dynamic Routing Gateway, and
  2. A shared private key. 

I’ve already showed you where you choose Dynamic Routing when you create the gateway.  And other than the shared key, everything else I did for configuring the Fabrikam network was identical to what I configured in AzureNet1, except that my network in Fabrikam is – identical to what I defined the “Fabrikam” “local network” to be on this side. IMPORTANT: These have to match.  The range and mask have to be correct and consistent on both ends both the “local network’' definition and the actual network (or Azure virtual network as in my case) for this to work.

Also in the definition of the “local network” on either side was the specification of the Gateway IP Address.  Again, ordinarily, your configuration script is populated with the Azure virtual gateway’s IP address.  But in this instance, I need to create the gateway first, and let it fail connecting, just so I can see what the actual assigned gateway IP address on that side of the connection is going to be.  Then I can take that address and configure it into the “local network” definition on the other side.

As for the shared private key.. Notice at the bottom of the AzureNet1 dashboard that there is a Manage Key button:


If I click this, I can see (and copy) the generated long key.  I’ll copy it to the clipboard.

Manage Shared Key

This key was created when we created the gateway, and is included for you in the configuration script on behalf of your “local network” device.  But…

“We don’t have a local network device!”

Bingo.  And we also don’t (as of this writing) have a way to use the Azure portal to set the shared key in and the configuration of the virtual network!  But we will need to do that to at least one end of the tunnel to make sure they match.  (Or both if we want to just use our own text as the shared key.)

This is where PowerShell comes in.

I’ve installed the Azure PowerShell cmdlets onto my local system, and then in PowerShell I connected to my Azure subscription where the Fabrikam virtual network resides.  And now I use the following PowerShell command to set the shared key for the gateway connected the Azure network Fabrikam to the (from this point of view) “local network” named AzureNet1.

Set-AzureVNetGatewayKey -VNetName fabrikam -LocalNetworkSiteName AzureNet1 -SharedKey 2kDsdqXnxeXrGjI4r4rLltKKT1g9E9gY

(For the Windows PowerShell command-line tools, go to the Azure downloads page, and scroll down to “Windows PowerShell” section.  Instructions for setting this up are found there as well.)

That’s how I was able to get the common shared key into the other side of my connection.  After this command completes, and soon after clicking Connect in the dashboard, I was happily sending data back and forth.

“But Kevin… Prove to us that you have the connection established!  Finish your domain-joining scenario!”


In the AzureNet1 network I have two servers.  One is a domain controller, and the other is a member server.  All machines here are assigned their DNS server as They reside in the South Central US datacenter region.


On my Fabrikam network (which, you’ll recall remember, resides in the Central US datacenter region, so not in the same location as the AzureNet1 network and machines) I have one server that I’ve just created:

Fabrikam Network Machines

Importantly, I’ve also created a “DNS Server” designation here, and assigned to the Fabrikam network, with the address.  Note the configure tab of the Fabrikam network.


In this way my machines in this Fabrikam network will be assigned as their DNS server, and so will know how to find the DC in the AzureNet1 network.  To verify this I can establish a remote desktop connection to my new karContosoDC2 server and look at the status of the network adapter:

Network Status

Trusting that my VPN is happily and dynamically routing traffic between Fabrikam and AzureNet1, and knowing that my new server in Fabrikam is going to look for DNS at the domain controller in AzureNet1, I attempt to join the domain:

Joining the Domain

I am asked for domain credentials (a very good sign!)…

Prompted for Creds


I'm in!

I’m in!  That’s proof that I have successfully connected these two virtual networks!

For more information on configuring secure cross-premises connectivity, check out the official documentation here:

Here are some more specific configurations and their documents:

And be sure to keep watching for the full series of articles on modernizing your infrastructure.

6 thoughts on “Cross-Premises Connectivity with Site-to-Site VPN – Modernizing Your Infrastructure With Hybrid Cloud (Part 15)

  1. Hybrid Cloud is all about leveraging the "best of both worlds" by combining the low-latency access of an on-premises datacenter with the elastic, pay-as-you-go nature of a public cloud platform like Microsoft Azure . Cross-premises connectivity


  2. Hi Kevin,

    I am trying to set the cross premise scenario between Azure and AWS…Aws being the "Local" in the blog scenario…my issue is that the preshared key that AWS provides for the tunnel is not "Alphanumeric" and has special characters, so any help would be really


  3. Hi Bala,

    I haven’t done this personally, so I don’t know if you can do it. I should think that AWS would also have a way to set the shared key on their end. It’s only important that you somehow set the two ends to be the same.

    I haven’t read through it in any detail, but you might find a solution in this article I discovered while doing my own research on the topic. It’s an article called "Connecting Clouds – Creating a site-to-site Network with Amazon Web Services and Windows Azure"

    Hope this helps!


  4. Thanks Kevin…yes I saw this article , and using open swan was not preferred (our sysadmins) said it was not reliable enough :-), so what we did now is have setup two vpn's from the actual on-premise to AWS and Azure and then routing from the on-prem
    router. Thanks for taking the time to reply…really appreciate it…and great articles from you and the team…


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s