As we all know, the Cloud is here, it's here to stay and its benefits are forcing businesses to consider it. We are in a transition period in Information Technology and I'd say we're far down the road to nearly every IT infrastructure having some sort of Cloud interoperability, service or connection. These changes are evolving the IT Pro career, too. We all know, you can't stop progress, so embrace the changes and evolve your skillset to include "cloud technologies."
I know, I know … I can already hear you: "Nice…now I have yet another thing to ramp up on and maintain for my skillset." This is true, but it has always been true in IT. We gotta keep learning/re-learning in this field we've chosen.
My own cloud journey has run the gamut … a while ago, I tried to ignore it because I didn't understand it. Then, I dabbled in a few Azure services/scenarios. After attending a recent internal training event with a lot of content for Windows Azure, I've jumped into the deep end of the pool and I'm trying to stay afloat in this rapidly evolving space.
Lately, I've been exploring some interesting Azure-blend ideas:
One scenario I worked through recently was a cross-premises Site to Site VPN to Azure but only now did I take the time to document it and write it up.
Herein, I share with you my 'dummies guide' to setting up a site-to-site VPN between Azure and an on-premises site (corporate network or basement lab in my case). After I get the VPN up and running, if you're still reading, I cover a high-level process of creating an Azure IaaS VM and promoting it to be a replica DC for an on-prem Active Directory environment.
I created the Visio below to help those visual learners (like me) and I've also included a "worksheet" to help you plan/prep for this endeavor.
Figure 1: Site To Site VPN Visio Diagram
On-prem RRAS Router – public IP Address (VPN Device IP Address entered in the Azure Local Network setup): _ 22.214.171.124 __
On-prem RRAS Router – private IP Address (used as the gateway for on-prem systems): __ 192.168.0.20 ___
On-prem IP Address Spaces (and added to AD Sites): _____ 192.168.0.1/24 _______
On-prem DC/DNS Server name and IP Address (as will be entered in the Azure Local Network setup): _192.168.0.22 : ONPREM-DC-01 ___
On-prem AD Site name: __ ONPREM __
Site Link name, cost and replication interval/schedule: _OnPrem-Azure : 100/15 min_
Azure Local Network Name: __OnPrem-PNet-192Dot___
Azure Virtual Network Name: __Azure-VNet-01__
Azure Virtual Network IP Address Space(s) and Subnet Name(s): __10.10.10.0/27 : Subnet-1 __
Azure Virtual Network Gateway IP Subnet: _10.10.10.32/29 __
Azure Virtual Network Gateway IP Address: _ 126.96.36.199 _
Azure IaaS VM DC name(s) and IP Addresses (discovered after they rec'd IP from Azure DHCP): __AZURE-DC-01 : 10.10.10.4___
Azure AD Site name: __AZURE __
Azure AD IP Subnet(s): __10.0.0.0./24__
On most days, I have a typical home network with a cable modem, then a wireless router, and then PCs.
Before I started this work, I filed a change-control request with my family because they were going to suffer an 'enterprise-wide' Internet outage while I did this. I by-passed all of my typical home network gear for this lab and plugged one leg of a dual-homed physical server (2012 R2) directly into my cable modem and let it pull a public-facing IP. I did an IPCONFIG on the router/server and made a note in my worksheet of the public IP.
Next, per my worksheet planning, I configured the private leg of my dual-homed physical server with a static IP address of 192.168.0.20 but left the gateway blank. With gateways, as with Highlanders, there can be only one.
Before getting too far, I'll try to clarify some Azure terminology. The vocabulary is often my first stumbling block when I'm learning something new and Azure was no different.
What does Azure mean by 'Local Network?' What is a 'Gateway subnet?' What does a 'DNS Server' in an Azure Virtual Network refer to and what should I put in there? I heard Azure doesn't support static IP addressing – how do I assign IPs to my systems? How do I define other NIC settings for Azure-based VMs? Can I use WINS? No, you can't use WINS. J
Allow me to try to simplify/clarify/paraphrase:
An Azure Virtual Network consists of numerous settings, including DNS Server(s), Local Network(s), VPN settings and TCP/IP v4 address space(s). I think of an Azure Virtual Network as a sort of 'branch office network' in my mind.
Let's go through and cover each section of creating a Virtual Network in Azure, starting with DNS Servers.
Sign in to the Azure portal and Click "NETWORKS" then "DNS SERVERS" then "REGISTER A DNS SERVER" to get started:
Figure 2: Getting started with Azure Virtual Network "DNS SERVERS"
Figure 3: Register a DNS SERVER in the Virtual Network Wizard
Figure 4: On-prem DNS Servers are defined. I can edit this list later and add in my IaaS DC/DNS servers and IP addresses to provide DNS local to the Azure Virtual Network for fault tolerance in the event the VPN has issues. You can add up to 9 entries here.
Figure 5: Add a LOCAL NETWORK
Figure 6: Local Network details
Figure 7: Specify the on-prem network address space(s)
Figure 8: An Azure Local Network has been defined
Figure 9: Create a Virtual Network
Figure 10: Name the Virtual Network and create an Affinity Group in a regional Azure Datacenter
Figure 11: Add the DNS Servers you defined before, enable site-to-site connectivity, select the Local Network
Figure 12: Establish the Address Space, create a subnet within the Address Space and define the Gateway Subnet
Figure 13: Address space, subnet and gateway subnet review. The "Network Preview" graphic helped me visualize all the pieces.
Figure 14: An Azure Virtual Network has been created
Once my Local Network, DNS Servers and Virtual Network were all defined/created in the Azure portal, I clicked CREATE GATEWAY with Dynamic Routing (below).
Figure 15: Create the Gateway – I chose Dynamic Routing
Figure 16: VPN Gateway is being created
Figure 17: VPN Gateway created but not yet connected (IP Address is for illustration purposes only)
Ta-da! The gateway was created (the blue GATEWAY in the graphic above) but note, it shows "DISCONNECTED" on the OnPrem side. Before the connection will work, I need to configure the on-prem Windows Server as a VPN RRAS router.
After the Gateway has been successfully created and the WS 2012 R2 RRAS server is configured, I chose to CONNECT the Gateway
Figure 18: VPN is connected and data is passing. HOO-HAH!!
Once the Azure VPN gateway connected to my on-prem 2012 R2 VPN/router, I reviewed/refreshed the RRAS console again. At that point, it showed "Connected" with substantial incoming and outgoing traffic.
If you're following along at home and this is all working for you, congratulations!!
Trust me … this ain't no Little Feat (shout-out to one of my favorite bands)
Figure 19: VPN Interface "Connected"
Figure 20: Incoming and outgoing traffic
Figure 21: Static route settings
Once I connected my on-prem environment to Azure via VPN, I built out a replica DC on an Azure IaaS VM.
A few links with some GREAT content with much more detail for this:
I don't walk through each step of the VM build process here (it's really very simple) but notice the VM was created on the IP subnet in Azure that I created within the Azure Virtual Network back at the top of this post ("Subnet-1").
Figure 22: New VM attached to the 10.10.10.0 "Subnet-1" created in the Virtual Network above.
Once the VM was provisioned, I used the Azure Portal to connect to the new workgroup VM (below) …
Take a moment and think about this…
Since I had VPN connectivity at this point, I could have connected directly via RDP from an on-prem system using the VM's private IP address (which can be obtained from the Azure Portal):
Recall, when the IaaS VM re/boots, it picks up its "Azure reserved" IP address and the DNS servers I defined in the Azure Virtual Network.
With DNS working from the Azure VM to on-prem, I successfully joined the IaaS VM to the on-prem domain and rebooted it.
Figure 23: DNS console showing the Azure IaaS VM successfully registered in DNS
It was really quite exciting to get this all set up and working ... but we ain't done yet!
Next, I added the AD DS Role to the IaaS VM and promoted it into AD as a replica DC in the HYBRID.LAB forest (my demo/lab).
I had already created the proper AD Sites, Site Link and Subnets for my Azure world and my on-prem world in my lab AD forest configuration.
As a result of that pre-work, during the promotion wizard, I was able to choose the target AD Site for the new Azure-based DC, as well as select the on-prem DC for initial replication:
Figure 24: Selecting the destination AD Site (Azure) for the new Azure IaaS VM DC
Figure 25: Selecting the source DC (OnPrem-DC-01) for initial AD replication
After the DC promotion and reboot, I saw my shiny new DC up in Azure-land (AZURE-DC01):
Figure 26: AD Sites and Services Console showing the on-prem and Azure DCs, AD sites, subnets and Site Link
Figure 27: Active Directory Users and Computers Console showing both the on-prem and Azure IaaS DCs
There are a lot of new concepts here. If you're struggling, give yourself a break ... take a deep breath; hum a tune; go chase some squirrels or something. Then come back to this - it took me more than just a bit of patience before it all clicked and I got the VPN dance to succeed.
Like I said at the outset, the Cloud is here; the time is now to start thinking about how Cloud technologies will fit into your IT career and the solutions you design/operate/support.
Thanks for reading and I hope you found it useful.