Cross-Premises Connectivity with Site-to-Site VPN - Modernizing Your Infrastructure With Hybrid Cloud (Part 15)
Yesterday 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.
“Sweet!”
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 contoso.com 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.
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 10.0.0.4. 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 192.168.0.0 with a 16-bit subnet mask. (192.168.0.0/16)
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 23.101.125.64. 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.
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.
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:
…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:
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.
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.
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:
- Dynamic Routing Gateway, and
- 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 192.168.0.0/16 – 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.
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!”
Right!
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 10.0.0.4. 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:
Importantly, I’ve also created a “DNS Server” designation here, and assigned to the Fabrikam network, with the 10.0.0.4 address. Note the configure tab of the Fabrikam network.
In this way my machines in this Fabrikam network will be assigned 10.0.0.4 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:
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:
I am asked for domain credentials (a very good sign!)…
And..
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:
https://msdn.microsoft.com/en-us/library/azure/dn133798.aspx
Here are some more specific configurations and their documents:
- Configure a Site-to-Site VPN in the Management Portal
- Configure a Point-to-Site VPN in the Management Portal
- Configure a Multi-Site VPN
- Configure a VNet to VNet Connection (like what we did here)
And be sure to keep watching https://aka.ms/ModernCloud for the full series of articles on modernizing your infrastructure.
Comments
- Anonymous
September 04, 2014
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 - Anonymous
September 05, 2014
The comment has been removed - Anonymous
September 05, 2014
thanks for sharing. - Anonymous
September 10, 2014
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 appreciated... - Anonymous
September 10, 2014
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" - http://michaelwasham.com/2013/09/03/connecting-clouds-site-to-site-aws-azure/
Hope this helps! - Anonymous
September 10, 2014
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...