Building an Azure lab – Implementing S2S (Site-to-Site) VPN

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.

Log on to the management portal on (to see how this can be done federating with your own domain check this post).

Find the Networks menu option on the left, click that, then click the Local Networks tab, and click Add a local Network:
01 Azure Freaks - S2S
Enter a descriptive name for the local network, and enter your Public IP (if you don’t know your own public IP check or if you’re into that, but turn down your computer’s volume, especially if you’re at work ;) ):
02 Azure Freaks - S2S
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:
03 Azure Freaks - S2S
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:
05 Azure Freaks - S2S
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:
06 Azure Freaks - S2S
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:
07 Azure Freaks - S2S
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:
08 Azure Freaks - S2S
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:
08-2 Azure Freaks - S2S
Now create the address space you want to use for the Virtual Network.
09 Azure Freaks - S2S
As you can see I defined for my overall address space and defined to subnets in that same space, and 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 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:
10 Azure Freaks - S2S
This brings you to your current Virtual Network setup and its status:
11 Azure Freaks - S2S
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:
12 Azure Freaks - S2S
When you do, you need to choose between using Static Routing, or Dynamic Routing. Choose Dynamic Routing for this gateway.
13 Azure Freaks - S2S
And here it goes! The Azure magic is creating a Software based VPN Gateway for you.
14 Azure Freaks - S2S
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.
15 Azure Freaks - S2S
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:
16 Azure Freaks - S2S
A download will start for VpnDeviceScript.cfg:
17 Azure Freaks - S2S
Copy this file to the RRAS server and rename it to VpnDeviceScript.ps1:
18 Azure Freaks - S2S

Opening the VpnDeviceScript in a text editor shows us the magic that is about to happen:
19 Azure Freaks - S2S
– 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.

20 Azure Freaks - S2S
Adding roles and features without a problem.
21 Azure Freaks - S2S
Successfully added even.
22 Azure Freaks - S2S
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:
23 Azure Freaks - S2S
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.

24 Azure Freaks - S2S
At the least the Server Manager status is now green across the board. Notice that the script added the IIS and Remote Access roles.

Open the Routing and Remote Access console (found in Administrative Tools), then click on the Network Interfaces node to open it, and behold, the interface’s status already shows up as Connected:
25 Azure Freaks - S2S

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.
26 Azure Freaks - S2S

Return to the Azure portal, navigate to your Virtual Network if you need to and observe the graphic:
27 Azure Freaks - S2S
Azure Gateway up and running, connected to RRAS VPN Endpoint on my local network.

Are we done now?
Not quite.

If I try to ping a resource on the Azure subnet I created to extend my local subnet here’s what happens now:
28 Azure Freaks - S2S
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 scope.
To accomplish that you need to add a static route on your internet router if you have the same setup. I added with the RRAS server’s IP address as a Gateway in the routing table of my DD-WRT machine:
29 Azure Freaks - S2S
Consult the manual or your favorite search engine on how to do that on your hardware.

If we ping that same machine again:
30 Azure Freaks - S2S
And now it worxx.. ehrm works.

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!




20+ years experience in Microsoft powered environments. Enjoy automating stuff using scripts, powershell, and even batch files. In my free time (hah! as if there is any) I hunt achievements and gamerscore on anything Xbox Live enabled (Windows Mobile, Windows 8, Windows 10, Xbox 360 and Xbox One). When I'm not doing that I enjoy traveling or riding my Yamaha R1 on the edge ;)

Tagged with: , , , ,
Posted in Azure, Networking, RRAS, Step-by-Step guide, Virtual Networking, Windows 2012 R2
3 comments on “Building an Azure lab – Implementing S2S (Site-to-Site) VPN
  1. Aasish says:

    Please help me, I am new to these concept, where should I run configuration scripts after downloading ? Thanks

  2. Moy says:

    I’m about to do this for our prod environment. We don’t have a public IP for our VPN and I’m intending to have it sit behind a NAT like yours. The NAT restriction Microsoft lists is worrying me. Curious, did you run into any connectivity problems (frequent disconnects, etc.)? If not, why did Microsoft even list that restriction?

    Also, why did you need to open UDP ports 500 and 4500?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog Authors

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 399 other followers

Blog Stats
  • 2,696,333 hits
%d bloggers like this: