After Microsoft announced software based Site-to-Site VPN support between Windows Azure Virtual Networks and Windows Server 2012 Routing And Remote Access I wrote a blog post on how easy it is to configure all of this: Setting up software based Site-to-Site VPN for Windows Azure with Windows Server 2012 Routing and Remote Access. I got lot of positive response on that post and a few people also asked me how they could get this to work in a real corporate network.
That’s why I decided to write this post… I’ll be covering step by step how Contoso moved from everything in their datacenter to a hybrid setup with their datacenter and Windows Azure Virtual Machines, connected with the Site-to-Site VPN available in Virtual Networks.
The original setup
This is how Contoso looked like before moving to Windows Azure. Besides the standard infrastructure like AD, DNS, … their network included the following:
- A firewall + router which was directly connected to the internet. Everything behind that firewall + router was using NAT.
- A developer (Contoso-DEV) connected to the wireless network. This wireless network was connected to the router.
- A webserver (Contoso-WEB001). Using port forwarding (port 80 and 443) this server was available from the internet. Developers from within the network were able to connect to the machine using Remote Desktop, but this was only possible if they were connected to the corporate network.
- A database server (Contoso-SQL001) which was not publicly available. Only the webserver and the developer workstations were able to access it.
Contoso decided to resell their application in a few additional countries so they needed some extra power. And instead of investing in additional hardware, licenses, … they decided to go for Windows Azure. The plan was to have multiple webservers running in Windows Azure depending on number of additional customers. If it would turn out that the application wasn’t selling good enough in these countries, they could just remove the Virtual Machines and that would be the end of it. They loss they would suffer would be minimal.
Preparing the hardware and the network
The first thing I did was install a new physical server with Windows Server 2012. Now take a look at the following picture:
The image in the lower left corner represents my new server. As you can see this server has a public IP since it’s connected to my modem, but it also comes with an internal IP since it’s connected to the firewall/router. The important thing to know here is that you machine needs direct access to the internet, meaning no NAT or blocked ports. If that’s not possible for you, I think it all ends here. Here in Belgium I think it’s almost impossible to get this on a residential line, so I had to buy a new modem + upgrade my internet subscription in order to get this.
Ok so let’s take a look at what we’ve done so far:
- Install a Windows Server 2012 (name: Contoso-RRAS)
- Connect this server to the internet using a direct connection without NAT (so no firewalls, routers, … between your server and the internet)!
- Connect this server to our corporate network. For this connection, NAT is OK
And this is how an ipconfig on the new server looks like:
Here you can clearly see the 2 network interfaces: Ethernet is the one connected to the internet and the Wireless one is the one connected to the corporate network. Note that for the connection to my corporate network I’ve set this to a fixed IP address and remove the gateway (explained here: http://blog.concurrency.com/featured-post/site-to-azure-vpn-using-windows-server-2012-rras/).
Creating the Local Network in Windows Azure
The first thing we’ll need to do in Windows Azure is define our local network. You can create a new local network under Networks > New > Add Local Network. Start by giving it a name and the IP address of the new Windows Server (in my case the public IP address of Contoso-RRAS, 188.8.131.52).
On the next page I’ll enter the internal IP range of the corporate network (this matches the second IP address you saw in the ipconfig screenshot):
And that’s it, your corporate network has been defined in Windows Azure. Next stop, creating a Virtual Network!
Creating the Virtual Network in Windows Azure
So I created a new Virtual Network which I called Contoso-AZURE:
On the next page I defined the DNS server which runs on-premises (in my case 10.0.0.9). This is really important if you want your Virtual Machine to resolve your local resources like a SQL Server (in my case that would be Contoso-SQL001). And on the third page I configured the Virtual Network with a subnet called Web-Frontends and a gateway subnet. The Web-Frontends subnet will hold the Virtual Machines running the webapplication.
After a few seconds the Virtual Network will be created. Now it’s time to set up the gateway as described in my previous post: Setting up software based Site-to-Site VPN for Windows Azure with Windows Server 2012 Routing and Remote Access.
- In the Virtual Network, create a gateway with static routing
- Download the VPN Device Script for Microsoft / RRAS
- Replace the weird characters in that file
- Replace the settings in that file
- Save the file as a *.ps1 file
- Run it on the new server (in my case Contoso-RRAS)
- Wait for the installation to complete
Here’s how I replaced the variables in that file, it might be a useful reference for when you’re comparing this with your own environment:
- SP_AzureGatewayIpAddress: 137.117.x.x (the IP address you’ll see in your Virtual Network after creating the gateway with static routing)
- SP_AzureNetworkCIDR: 10.1.0.0/16 (the address space of my Virtual Network, see previous screenshot)
- SP_AzureNetworkMetric: 10
- SP_PresharedKey: the key you’ll find when clicking Manage Key in your Virtual Network
After running the script on your new server you’ll see that the Routing and Remote Access Role has been configured. Open up RRAS and go to Network Interfaces. This is where you’ll see the gateway as a Demand-dial interface. Right click it and press Connect. The first time I had to do this a few times before it worked (Disconnect / Connect / Disconnect / Connect / …). After the first time everything kept working OK:
Creating the Virtual Machines
So the first part of the network configuration is done. Now we’re going to setup a new Virtual Machine which will allow the developers to deploy the application. And after that we will remove the web server which runs on-premises (in a real project this would keep running in parallel for a few days/weeks).
For the first Virtual Machine I had to create it as a stand-alone Virtual Machine. And it’s on this page that I decide to link the Virtual Machine to the Contoso-AZURE Virtual Network and in which subnet to place it (the Web-Frontends subnet). Finally on the next page I decided to create an availability set called WebFrontEnds in order to get the 99,95% SLA when I connect a second machine.
Immediately after creating the first machine I created the second machine, but for that one I connected it to the first virtual machine:
After a few minutes you’ll see the Virtual Machines popping up in your Virtual Network:
Did you notice that both machines received an IP address which matches the Web-Frontends subnet. This is how we’ll be able to address the Virtual Machines from our corporate network.
Time for some Routing
The networks have been connected, the web application has been migrated to Windows Azure Virtual Machines. This means we only have one task left: configure the routing to make sure that our developers can connect to the Virtual Machines from within our corporate network and to make sure that the Virtual Machines can access the SQL Server running on-premises.
You might be thinking that the developers already have access to the Virtual Machines (since they deployed the web application on the Virtual Machines). That’s true, but in order to do so they had to connect though the public endpoint for Remote Desktop. Now this might be a possible security risk, since anyone with an internet connection could be able to connect to your Virtual Machine (this leaves the door open for brute force attacks). Go ahead and remove these public endpoints and make sure you open ports which are really required for your application like HTTP or HTTPS:
The next step will depend on the type of firewall you have in your corporate network. Since I’m doing this at home I don’t have a fancy firewall, but I’m using a Netgear Genie WNDR4000 instead (which is my firewall + router). But this doesn’t really matter. The only thing you’ll need to do is setup routing in your firewall. In my case I created a static route to my Web-Frontends subnet:
Here is what this means:
- Name: I guess that’s obvious
- Destination: the subnet you want to connect to (the one you defined in the Virtual Network). In my case this is the 10.1.0.0 range.
- Gateway: the server that can “bring you there”. In my case this is the new server I deployed. This server is the only connected to Windows Azure using the Site-to-Site VPN and if you look back to the picture at the start of this post you’ll see that the IP address of the machine is: 10.0.0.2
Once that’s done I’m able to connect to the Virtual Machine from the developer workstation (or any other machine in the corporate network connected to the firewall):
But this also means we could use this for so many other scenarios like secure backup, secure Remote PowerShell, using Windows Shares, Web Deploy, integrating with System Center … And do you remember the DNS Server you assigned to your Virtual Network? Well, take a closer look: the Virtual Machine automatically uses this DNS Server. This means my Virtual Machine will be able to resolve the names of the machines in my corporate network.
Now the other way around just works thanks to RRAS, so from that Virtual Machine I’m able to ping any server in my corporate network like the SQL Server for example (10.0.0.4):
And we’re done! Our servers in the corporate network are able to connect with the Virtual Machines running in Windows Azure and those Virtual Machines can connect to our corporate network!
Our RRAS server is connected to the internet without a firewall sitting in front of it. In order to improve security you could configure the firewall to only allow incoming connections from the internet coming from the gateway you created in the Virtual Network. For the VPN to work only these rules should be enabled for the public profile (besides the Core Networking rules):
And there you go, this should be a good reference to get started with the Windows Azure Virtual Networks Site-to-Site VPN functionality for Routing and Remote Access. Here’s how the network looks like today:
Writing this article was very challenging for me (since I’m not an IT Pro) and it even cost me a few bucks (about 85€ for the line upgrade and the new modem), but I hope this can be a useful start for people who want to move their infrastructure to a hybrid cloud (with Windows Azure of course).