First published on TechNet on Mar 03, 2014
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:
-
Domain Controllers on Azure-hosted VMs (using "Infrastructure as a Service" VMs (IaaS – spoken 'EYE-as')
- DCs for DR - hosted in an Azure tenant? Maybe.
-
Hyper-V Recovery Manager (an Azure based service) and DR management
- Use an Azure-based service to help orchestrate your VM DR failover between your HQ and one (or more) of your regional datacenters
- Store your DR plans online in OneDrive for Business (formerly SkyDrive Pro) so that critical information is available both on-site and online in the event of a DR (real or exercise)
-
Backup your systems to Azure (using integrated Windows Server backup >> Azure services) instead of shipping tapes off-site to a data storage warehouse
- How much faster could you recover data if you didn't have to call back tapes?
- …
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.
Let's roll…
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.
- NOTE - There are many screen shots of the CURRENT Azure UI in the post but this Cloud business changes frequently, so the UIs and features/specs may - and likely will - change.
Figure 1: Site To Site VPN Visio Diagram
Pre-notes
- ALL PUBLIC IP ADDRESSES HERE ARE JUST NUMERIC VALUES and are only included to help illustrate the steps and components of this walk-through
-
Azure costs can add up
- I did this all via credits included w/ my MSDN subscription
-
Review the free trial details below - be sure to watch how you setup the trial so you don't automatically roll over into an unexpected credit card bill
- Check out the Azure pricing calculator and have a look at the 'sliders' for estimating charges in Azure - http://www.windowsazure.com/en-us/pricing/calculator/?scenario=full
-
Generally, Azure charges for data going out of Azure (egress), but not data coming into Azure (ingress) – keep that in mind
-
Virtual Networks charge per hour for data egress (per the calculator above):
- "Setting up a Virtual Network is free of charge. However, we do charge for the VPN gateway that connects to on-premises. This charge is based on the amount of time that connection is provisioned and available."
-
Worksheet
On-prem RRAS Router – public IP Address (VPN Device IP Address entered in the Azure Local Network setup): _ 23.23.23.22 __
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: _ 23.23.23.23 _
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 __
Now, on to the rest of the blog …
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.
- SECURITY NOTE – this act has some significant security implications and is NOT a recommended practice. This was an isolated learning experiment, though, and there was no other connectivity beyond these two transient physical systems.
- NOTE - Azure Site to Site VPN connectivity requires a non-NAT'd 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.
-
I used the Windows 2012 R2 RRAS system ONLY as a router .
- Apart from RRAS configurations, I didn't RDP or perform other management tasks of the Azure or on-prem systems in my lab from this system
- I don't know enough about routing or routers to even know what sort of functional network connectivity I had/didn't have
- It was a headless, non-domain joined stand-alone system.
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.
Create a Virtual Network
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"
DNS SERVERS
-
In order for effective and fault-tolerant name resolution to work between on-prem systems and Azure IaaS VMs, you should define multiple DNS servers within your Azure Virtual Network:
-
Local, on-prem DC/DNS server(s)
- You should already know what their names and IPs are (per the planning worksheet above)
-
Remote, Azure-based DC/DNS servers that are in your Azure Virtual Network
- Once you create Azure-based VM DC/DNS server(s), they'll get an IP from Azure DHCP. After that, you can edit the DNS server list in the Azure Virtual Network, adding them in as needed.
- The IaaS VMs only process newly added/removed DNS servers to their vNIC settings upon re/boot of the VM.
- Failure to include one or more Azure-based DC/DNS servers may (likely will) impact name resolution for your Azure-based systems if/when the VPN isn't connected/working
-
- Don't worry if you can't connect to these at the moment – these are just part of the 'definition' of the Virtual Network
-
NOTE - Azure IaaS VMs do not support static IP addresses but they DO support 'persistent' IP addresses (think "an Azure-based DHCP reservation" - which last as long as the VM is provisioned)
- However, all that persists is the IP address. Other TCP/IP settings directly assigned to the vNIC will not persist – which is why you must define your DNS servers within the Azure Virtual Network
-
Why is this unique DNS server definition needed? A good question.
- One reason is VM servicing and portability in Azure. There can be cases where your VM is torn down and re-assembled from the VHD file. When that happens, the vNIC from the original VM is gone (along with its TCP/IP settings) and a new vNIC is plug'n'play'd into the new VM.
- When that new VM comes up, the new vNIC doesn't have any awareness of the prior vNIC settings. Azure automation assigns your new vNIC the same IP you had before and it sets the DNS server values you've defined here on the new vNIC.
- If you want more detail on this, have a look here: http://msdn.microsoft.com/en-us/library/windowsazure/jj156088.aspx#bkmk_BYODNS
- I used a naming standard which matches the AD computer account names for my DNS server entries – i.e. "OnPrem-DC-01"
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.
LOCAL NETWORK
- An Azure Local Network is an Azure-based reference to your on-prem IPv4 address space and is used to automagically create routing rules from Azure to the "on-prem side" of the VPN.
-
The ADD A LOCAL NETWORK wizard begins with a field for a name for your local network in Azure. Choose a descriptive name from your naming standard (I called mine "OnPrem-PNet-192Dot")
- As with anything in IT, give some thorough considerations to your naming standards/conventions for various Azure elements
-
The Local Network definition also includes the public IP of your on-prem VPN end-point/router/server
- It is called the "VPN DEVICE IP ADDRESS" in the Azure UI
- In my example, per my worksheet, this is my imaginary value - 23.23.23.22
-
Next, you get to enter an address space(s) for your local on-prem IPv4 network(s)
- In my example, per my worksheet, this is the 192.168.0.1/24 address space.
- There you have it - a 'Local Network' in Azure
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
VIRTUAL NETWORK
- A Virtual Network in Azure combines the other elements discussed above (DNS Servers and a Local Network) with a few other settings and establishes an IPv4 network for your use in Azure-land
-
As with the Local Network above, enter a descriptive name based on a consistent naming standard for your Azure Virtual Networks
- I called mine "Azure-VNet-01"
-
Check the box to enable "site-to-site VPN" and select the Local Network you defined/created above from the drop-down list
-
You assign the Virtual Network a non-routable (private) IPv4 address space.
- Click the "Starting IP" drop-down and notice this can ONLY be a 10., 192. or 172. address space.
-
Then, you create one or more subnets within that address space and give the subnet a name
- I used 10.10.10.0/27 and called it "Subnet-1" (these were defaults on this page)
- This is where VMs that you create in Azure will live and be DHCP'd via automatic Azure mechanisms (including the DNS servers you defined above).
- The UI here won't let you over-lap with the on-prem address space that you defined (which makes sense if you think about basic TCP/IP networking)
-
Click the green "add gateway subnet" button to assign the Virtual Network a "gateway subnet" which is a small subnet which will automatically acquire a public-facing "gateway IP" (later, when you create the gateway)
- I used 10.10.10.32/29 for my gateway subnet and called it "gateway" (again, these were defaults on this page)
-
For more information about these Virtual Network settings and such, see this link to a great Azure doc
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).
- Several minutes of "behind the scenes magic" happens up in Azure-land (about 10 minutes in my experiences).
- This includes setting up static routes in the Azure Virtual Network so it can 'find a path' to the local, on-prem IP subnets (which were defined in the 'Local Network' portion of the Azure Virtual Network).
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.
- You can download a PowerShell script from the Azure portal that will set up the 2012/R2 RRAS aspects for you
- Download the file onto the WS 2012 R2 router/server – note, it has a .CFG extension
-
Open it with Notepad and review it
- Notice the "plain text" passphrase/key for the connection – this is the equivalent of the 'password' for the VPN connection, as well as public IP addresses. Take care to secure this file .
-
I changed the extension of the file to .PS1 and then ran it from an elevated PowerShell console on the WS 2012 R2 router/server
- The script installed the Remote Access Role/Features/services and configured everything for me ( including static routes to my Azure Virtual Network )
-
I opened up the RRAS console and reviewed the settings/statistics and noticed:
- The connection for the VPN showed as 'disconnected'
- The connection with the gateway IP showed just a few bytes of traffic
- A static route for the 10. subnet (the Azure Virtual Network address space I created) pointing to the gateway IP
After the Gateway has been successfully created and the WS 2012 R2 RRAS server is configured, I chose to CONNECT the Gateway
- This also took a few minutes and I refreshed the portal a time or two before it hooked up and connected.
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
BONUS BLOG CONTENT
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:
- http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx
- http://www.windowsazure.com/en-us/documentation/articles/virtual-networks-install-replica-active-di...
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…
- Within about an hour, I created an Internet-scalable Cloud-based extension to my on-prem network and spun up a licensed, patched WS 2012 R2 Server.
- Does anyone else see that as magical, or is it just me?
- Remember how long it used to take to get a subnet allocated, a physical server spec'd out, priced, budget-approved, ordered, shipped, built, racked, IP'd, OS built, and logged in? I recall MONTHS.
- I just did it in about an hour. That, my friends, is the speed of cloud technology.
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.
- Since the VM wasn't domain-joined yet, it wouldn't successfully register in my on-prem DNS yet so I was not able to resolve the Azure VM by name from my on-prem systems
- However, DNS resolution was working from Azure back to on-prem and I was able to resolve my on-prem DNS records from the Azure VM .
With DNS working from the Azure VM to on-prem, I successfully joined the IaaS VM to the on-prem domain and rebooted it.
- Do an IPCONFIG /ALL on the IaaS VM to view/verify/validate the desired DNS server settings
-
After the domain-join and reboot, I saw a dynamic registration for an A record in my on-prem DNS for my IaaS VM
- At this point, I had DNS resolution working in both directions and I could have used the FQDN to RDP to it from on-prem (or vice-versa)
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).
- Even though I didn't discuss it here, be sure to consider the issue of disk write-through caching and the use of a 'data disk' for your DC's DIT and SYSVOL
- http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx#BKMK_PlaceDB
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.
- For an overview of these aspects of AD, see this link - http://technet.microsoft.com/en-us/library/cc754697.aspx
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
Whew.
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.
Cheers!