Update: I’ve posted a version using the Azure Portal and/or PowerShell. You can find the updated post here.
The next step in preparing an Azure lab for this blog would be to connect my on-premises network to a Virtual Network in Azure.
In the meantime some colleagues and I decided we’d go for certification on Azure so we get together once a week, brainstorm for a while, and start building stuff we think is either fun to do, has educational value towards certification, or is just MS Freaky in general. The contents of this post are created on efforts I did with colleague Tom Loos.
And again a little disclaimer for those who want to build based on my “Building an Azure lab” guides.
I’m not claiming these are best practices, or that these are “the way to go”. I’m simply providing step-by-step guides set up by me and my colleagues on occasion to document how we did things to achieve the goals that were set. These guides get the job done, for me.
That said, on to the techy bits.
The goal for this session is as the title suggests: Implementing S2S (Site-to-Site) VPN between my IT-WorXX network and a Virtual Network on Azure.
For reference, check this article.
It lists the requirements for creating a S2S VPN:
•The on-premises VPN device must have an Internet-facing IPv4 IP address. This cannot be behind a NAT
I’m using my cable internet connection at home. I have a cheap NAT Router running DD-WRT, which can’t act as a VPN Endpoint for Azure VPN. Might be a showstopper, but we’ll see how far we can go with this.
•You must have VPN device that is compatible
We’ll be configuring Windows 2012R2 RRAS as a VPN Endpoint. This is a supported configuration.
•The VPN device you use must be compatible with the gateway type that is required for your solution
Windows 2012R2 RRAS, check.
•The Gateway SKU will also impact aggregate throughput
So keeping the connection alive, and probably running data through it will cost money. Makes sense.
•If you’re using a firewall (recommended!) make sure the required ports are open to the VPN Endpoint
•Open UDP port 500 to the VPN Endpoint
No problem, DD-WRT can handle that
•Open UDP port 4500 to the VPN Endpoint
No problem, DD-WRT can handle that
•Open IP Protocol 50 to the VPN Endpoint
That’s another problem right there. DD-WRT can only forward TCP and UDP ports. Again, this might be a showstopper, but we’ll see how far we can go with this.
Hmm what to do? After discussing this for a bit Tom and I assumed the whole thing would be impossible given the current setup in my meter cupboard, and not meeting 2 major requirements for the complete setup.
Stubborn, and eager to learn about the steps we can take using this crappy setup, we continued anyway.
I’m not going to discuss how we forwarded the 2 UDP ports on DD-WRT. Each firewall is different, consult your firewall’s manual if necessary, but open those ports to the IP address you have on the Windows 2012R2 machine that is going to act as your RRAS server.
Find the Networks menu option on the left, click that, then click the Local Networks tab, and click Add a local Network:
Enter a descriptive name for the local network, and enter your Public IP (if you don’t know your own public IP check http://www.myip.nl or http://moanmyip.com if you’re into that, but turn down your computer’s volume, especially if you’re at work ;) ):
Then click the Next button.
Fill in your local network subnet. If you need to add more than one subnet click the Add address space button, click the Finished button when you’re done:
I added just the one address space, because well, I only have one address space for now:
In the same menu click the DNS Servers tab and click Register a DNS Server:
On the bottom of the portal screen a Wizard will popup.
Enter Descriptive name for your DNS Server (I like to use the FQDN here, but fill in whatever suits you) and click the Finish button:
Still in the same menu we’ll create the Azure Virtual Network by going to the Virtual Networks tab and clicking Create a Virtual Network:
Again, fill in something descriptive and select a Datacenter Location for your network (I selected the Datacenter closed to my on-premises network), and click the Next button:
Select your registered DNS Server and while we’re here, also check Configure a site-to-site VPN, and select the local network you defined two steps earlier. Click the Next button when you’re done:
Now create the address space you want to use for the Virtual Network.
As you can see I defined 172.16.0.0/16 for my overall address space and defined to subnets in that same space, 172.16.1.0/24 and 172.16.2.0/24. I’ll be using the first one to extend my local network and I’m planning to use the second one for a semi-standalone Lab environment somewhere in the future.
The last step, and this is because we check the site-to-site option in the previous step, we click Add Gateway Subnet, which adds a subnet in the overall range. In my case the Wizard added 172.16.0.0/29 which gives us 8 addresses for Gateway devices.
The nice graphic shows us what we’re building here exactly.
This whole step of defining the address spaces requires some planning, so take your time, and maybe consult a colleague if you’re not sure what you’re doing here.
Click the Finish button when you’re done to create the Virtual Network.
And we’re still in the same menu when the Virtual Network is created. We can now click the Virtual Network name to enter the Virtual Network menu, so click it:
This brings you to your current Virtual Network setup and its status:
That red graphic tells you something is wrong in your setup, and I’ve highlighted the “problem”. The Gateway itself, the one which we’ll use to actually connect to the Windows 2012R2 RRAS server, still needs to be created.
The interface for doing that is at the bottom of the portal interface. Click the Create Gateway button:
When you do, you need to choose between using Static Routing, or Dynamic Routing. Choose Dynamic Routing for this gateway.
And here it goes! The Azure magic is creating a Software based VPN Gateway for you.
And the nice little graphic shows it’s status. Do not hold your breath waiting though, this process will take 20-25 mins. Read some of my other posts while you do that, or go make sure the Windows 2012R2 machine is ready to go for the RRAS configuration. Whatever you decide to do, this will take a while.
After what seems like forever the graphic changes. The Azure side of things has turned to blue, which resembles the picture we remember from the Wizard when it showed us what we we’re building. It’s just that the IT-WorXX side of things hasn’t turned to green yet. Is that because we don’t meet all the requirements for this configuration?
Fortunately, in this case it just means we still need to configure the RRAS side.
The Wizard that created the Gateway has created several configuration scripts for several VPN solutions by different vendors.
Luckily for us, Microsoft has also created a script voor RRAS VPN Endpoints.
Click the Download VPN Device Script button.
In the window that pops up select Microsoft Corporation in the Vendor drop-down. The Platform drop-down will change to RRAS and then select Windows 2012R2 from the bottom drop-down.
Click the Finish (download) button:
A download will start for VpnDeviceScript.cfg:
Copy this file to the RRAS server and rename it to VpnDeviceScript.ps1:
Opening the VpnDeviceScript in a text editor shows us the magic that is about to happen:
– Add RRAS related roles and features if not present
– Note the reboot notice, more on that later
– Install a VpnS2S VPN
– Add an interface
– Configure IPSec
– Configure the interface
– Create and configure a profile
– Restart the Remote Access service
– Start the connection
Thank you Microsoft. Not that we couldn’t do this by hand ourselves, but this is so much easier.
So, open up an Administrative Poweshell window and execute the script.
Adding roles and features without a problem.
Successfully added even.
Oh noes! At first I thought we finally ran into the missing requirements bit, but if you read the messages it seems something else is wrong. If you check your Server Manager you’ll immediately know what’s wrong, and probably also remember that note we’ve seen in the configuration script: might need a reboot here, restart script after that.
If you have a bunch of red text when the script tries to configure RRAS, fret not, just reboot the server and when it’s back up, run the script again:
Whether you needed to reboot or not, your screen probably looks like this one as well.
No change needed on roles and features. Predictable. Warning about IPv6. Predictable. Warning that the service needs to be restarted for the changes to take effect. Acceptable.
And there’s that red text again. So are we now hitting the missing requirements? No, we’re not. This one just means that the service didn’t start fast enough for the script. It continues while the service is in a starting state, but not fully started. The step that fails is the last step: connect the VPN interface.
And this is not a big deal. This VPN interface is a demand dial interface and it will open when we try to connect to the Azure subnet or when Azure tries to connect to the on-premises network. We can also connect it manually using the RRAS Gui.
While we’re here, open the IPv4 node and click on Static Routes. A route to the complete subnet we defined in the Azure Virtual Network was added by the script. So the RRAS server now knows it should route every IP packet destined for the Azure Virtual Network through the Azure VPN interface that is now connected.
Are we done now?
If I try to ping a resource on the Azure subnet I created to extend my local subnet here’s what happens now:
All machines on my network have the internet router configured as Default Gateway. Packets destined for the Azure networks, including the ping packets are routed to the internet and end up in the bit-bin because the host won’t be found there.
The only machine on the network that knows the correct route is the RRAS server. We need to tell the internet router that if it receives packets for the Azure networks, it needs to send them to the RRAS server. In my case my Azure networks are defined by the 172.16.0.0/16 scope.
To accomplish that you need to add a static route on your internet router if you have the same setup. I added 172.16.0.0/24 with the RRAS server’s IP address as a Gateway in the routing table of my DD-WRT machine:
Consult the manual or your favorite search engine on how to do that on your hardware.
So what about those pre-requisites we didn’t meet? Quite frankly, we have no idea. We started this whole thing thinking we would never be able to establish connectivity between the Azure Gateway and the RRAS server at all. Missing a protocol to forward, behind a NAT router, those sound like pretty serious requirements.
Perhaps we’ll run into problems in the future, but for now: All goals for this step in the Azure Lab saga are accomplished.
In this post we’ve tested connectivity using ping, which is normally not a very good test, but a first step. We’ve also successfully deployed a VM and we’re able to join it to the it-worxx.local domain. The deployed VM had a dynamic IP address, as with everything you deploy or create, and it was assigned the DNS Server I registered, the DNS Server that I have on-premises.
For now that’s all we need to be able to successfully deploy domain joined or workgroup virtual machines Azure, with what seems like full connectivity so far.
Next up will be the addition of a P2S (point-to-site) VPN Gateway in the same Virtual Network. We have decided to do connectivity related stuff first, fun and freaky stuff later.
Thank you Tom Loos for your collaboration on this part of the project!