Building an Azure IaaS and on-premise hybrid environment Part 1: The plan and Azure Network Connection
I’ve been meaning to build a test lab to kick the tyres of Windows Azure Networks for a while. Two things combined together to make me get it done, however: First was the need to build exactly that for a customer as part of proof-of-concepts; the second was an invitation to present at Tech.Days Online on the subject.
I’ve built and rebuilt said lab a few times now. I am about to build it again in order to have a demo environment for Tech.Days and I though it would be a good opportunity to blog the steps involved.
I had planned this as one blog post, but it’s going to end up as a series of posts just because of sheer length. In this post I’m going to describe the environment and walk through creating the Azure network and connecting it to my on-premise network.
Constraints
Let’s get the big problem out of the way first: In order to do this you need a static, world-routable IP address. You have to have something at your end that will act as one end of a site-to-site VPN tunnel and that will only work if you have an IP that doesn’t randomly change.
The second issue is the bit of equipment you need to get that VPN working. The easiest is a Windows Server 2012 or 2012 R2 machine, or equipment from Juniper or Cisco which means you should be able to use one of the configuration scripts provided by Microsoft. After that, you’re on your own. I’ve already blogged about getting the connection working with a SonicWall. In theory, anything that supports IKEv2 connections can probably be made to work, but you’ll need to have a good understanding of the technology.
The third issue revolves around whether you are using trial subscriptions of things like Windows Azure and Office 365. I have an MSDN subscription to Azure, so it’s not going to vanish quickly, although I can burn through my MSDN credit quite quickly with this lab. If you are using a trial you need to be aware that you might hit problems. In this post I’m not going to touch Office 365, although I am going to get single sign-on working with Azure AD. The reason for that is I don’t want to connect my Azure AD to an Office 365 trial subscription that will vanish in a few short weeks.
What are we building?
I wanted to build a meaningful test of what Azure Networks could do for me. I turns out that it’s also something that interests a good many of my customers and colleagues in the industry:
- Create a Windows Azure virtual network and connect that to my on-premise network.
- Place a domain controller into the Azure network.
- Build a server in the Azure network to run Dirsync and push my domain users into Azure AD (step one of single sign-on for Office 365 as well)
- Build an ADFS server in the Azure network and connect it to Azure AD (step two of single-sign on for Office 365)
- Build an ADFS Proxy (or a Server 2012 Web Proxy) for internet-access to the federated sign-on mechanism (also needed for Office 365)
What aren’t we doing?
We’re not going to look at Azure Backup in this post. We already use Azure for backup at Black Marble as part of our DPM configuration. There is also a simpler backup client for Windows Server. I’ll blog on those separately.
Why would we want to do this?
I have had many conversations about the practicality of moving virtualised servers from an on-premise environment into Azure. For many organisations this can work out cheaper that running their own tin. A hybird approach allows those VMs to me moved across over time and is important to enable testing.
Description of my rig
I am lucky in that I have a small number of static IP addresses through the internet provision at Black Marble. For my previous builds of this lab I added a USB network adapter to my laptop to connect to the outside world. For this build I am using a server hosted at Black Marble. Why? I need both ends of the lab to be running for my Tech.Days talks and it’s very hard to get a static world-routable IP at the event.
Very importantly, however, none of this lab will be connected to my main networks. I will create an internal Hyper-V network for the on-premise end of the lab and a second Hyper-V network that will connect to the outside world. The Hyper-V host will not be connected to any of these networks.
On my laptop I have Windows 8.1 and built all the VMs as Generation 2 virtual machines. My server, however, runs Server 2012 so the VMs are Generation 1. Does this matter? Not a bit, but I like the simplicity of the generation 2 virtual machines more than generation 1.
On-Premise VMs
For my on-premise network I have two virtual machines:
PremUCDC
Role: Domain Controller, DNS
OS: Windows Server 2012 R2
CPU: 2 core
RAM: Dynamic, min 512MB, max 2048MB
Disk: 120Gb Dynamic
Network: I adapter on internal network
Once the OS has been installed I will add the Active Directory Domain Services role and promote the server to be a domain controller.
For this lab I am using an internet-registered domain and I will use that as the AD domain suffix. This is an important point: If you create an AD forest with a .local suffix then you will have to jump through some more hoops to get single sign-on with Azure AD working.
PremUCRRAS
Role: Remote Access/VPN
OS: Windows Server 2012
CPU: 2 core
RAM: Dynamic, min 512MB, max 2048MB.
Networking: I adapter on internal network; I adapter on internet-facing network
I’ve tried Server 2012 R2 for the RRAS server a couple of times and I have not yet managed to get the VPN connection working, so this lab will use Server 2012.
I won’t add any roles to this server. Once I’ve configured my Azure network I will use the configuration script from Microsoft to add the necessary roles and configure the VPN link.
My on-premise network will use the 192.168.0.0 non-routable address space. I will then use 172.16.0.0 for my Azure network address space.
Azure Network
We need to create a new network in Azure to hold our VMs and we need to tell Azure what our on-premise network looks like, and what DNS servers we already have.
We start by creating a new Local Network in Windows Azure:
We will be asked what to call the new network and we are also asked to provide the IP address of the machine at the on-premise end of the VPN tunnel.
Next, we are asked to specify what address spaces we have on our on-premise network. This is important as it will be used for routing traffic between Azure and our on-premise networks.
As I said earlier, my on-premise network uses the 192.168 address space. I configure the Azure local network as 192.168.0.0/16. I can still subnet that network down on-premise (and I will).
Now we’ve defined what our on-premise network looks like we need to register our DNS servers. We need to do this so that Azure can hand them out via DHCP and machines on the Azure network will then be able to communicate with our on-premise network systems.
Our on-premise network has a single DNS – PremUCDC, 192.168.1.1
Now we can define our Azure network
First we give it a name, and we need to associate it with an affinity group.
Next, we associate the new network with the DNS server we added earlier
We know we want to connect our on premise network so next we select the Configure site-to-site VPN option. Azure will helpfully add the local network we configured earlier.
The next step is to define our address range and subnets on Azure. I’ve chosen to create 172.16.0.0/24 so I can subnet that down. I want two subnets – 172.16.1.0/24 and 172.16.2.0/24. I’ll add the gateway subnet in a moment.
The gateway subnet is that one that has the internal IP address of the VPN endpoint in Azure. I want that to be 172.16.254.0/24.
The network will take a little while to create. Once it’s done we need to create a Gateway that will provide our VPN connection.
The dashboard for the new network will look something like the image below and we can click the button at the bottom to create our gateway. There are two options for the gateway – static or dynamic routing. Four the lab I’m using dynamic routing.
Creating a gateway can take up to fifteen minutes so this is a good time for a coffee break.
Once the gateway is provisioned your dashboard will update to show you the IP address of the Azure end of the VPN and metrics for data in and out. I’ve removed the last two octets of my gateway address in the screenshot.
To bring up the connection to on-premise we need to configure our RRAS server. Conveniently, we can click the Download VPN Device Script link to grab some powershell to do that for us.
The VPN scripts are also available for a range of Cisco and Juniper devices. Simply select the appropriate options in the menus and download the script you need. You will need to edit the scripts to set a number of parameters before running them.
Before we make those script changes we need to know the shared secret that is used in the VPN handshaking. To find that, click the Manage Key button at the bottom of the dashboard.
The shared key will be displayed. Copy it to clipboard and save it somewhere.
Next, we need to edit the powershell script to add the parameters.
As a side note, why the guys at Microsoft didn’t put a variable block at the top of the script to make this easier I don’t know. Search and replace it is, then…
There are a number of edits we need to make:
- Replace <SP_AzureGatewayIpAddress> with the large IP address that’s on the Azure network dashboard. This applies to lines 75, 80, 81 and 87.
- Replace <SP_AzureVnetNetworkCIDR> with the Azure network address range (172.16.0.0/16 in my lab)
- Replace <SP_PresharedKey> with the key we access through Manage Key.
I usually leave line 87 commented out and run the command manually after the configuration is complete.
Copy that script onto the VM that’s going to be the RRAS server. I’m assuming that you’ve already joined it to the domain and configured the network adapters for internal and internet connections.
In order to run the script we will need to modify the execution policy on the server to allow unsigned scripts.
The command for this is set-executionpolicy unrestricted
Now run the powershell script to configure the VPN connection. The script will add the necessary roles to the server and configure the vpn connection.
Once the script is run, assuming you don’t need to restart the server it’s time to bring up the connection.
We need to enable the Azure gateway first by clicking the Connect button on the dashboard. Once that’s done, execute the last line of the powershell script (connect-s2svpninterface …).
We should be able to see the state of the connection from both the RRAS server and the Azure dashboard. On the RRAS server, open the Routing and Remote Access console.
The VPN is listed in Network Interfaces and the connection status should be Connected.
The Azure Network dashboard should also show that the connection has been made.
Next steps…
Now we’ve got our VPN connected the next step is to create a new VM on Azure, join it to our domain and promote it to be a DC and DNS server.
Once that’s done there are more VMs to create in order to configure single sign-on with Azure AD, which also needs to be configured to use the internet-registered DNS domain.
With the VMs in place we can configure directory synchronisation and then configure ADFS for single-sign on.
Each of these will be covered in later articles in this series.