Azure Site-to-Site VPN Configuration with Server 2012 R2 RRAS

Ah, what a beautiful site this is!  With RRAS on Server 2012 R2 and Azure – it’s never been easier to get a Site-to-Site VPN up and running!  Here’s how…

I setup a S2S VPN using this configuration in my lab today and thought I’d throw a quick post together walking through the current configuration for 2012 R2.  I did some searching around on my own for a quick tutorial but wasn’t able to find anything current.  So, here we go.

First things first.  You need the right kind of connectivity from your RRAS internet endpoint to Azure.  Specifically some UDP ports and IP Protocol Type=ESP (value 50).  If these aren’t open on your RRAS internet IP address then the connection won’t work.  So, if you are running this off your home network for a lab like I am – make sure that your internet provider supports this before you get too far down the path.  For me, I’m using ATT Gigapower and have a small subnet of static IP’s.  I assigned one of the static IP’s to the internet facing adapter on my RRAS VM and away it went.

Here’s a good article on what ports you need for VPN for various scenarios.

One tool that I found quite helpful for determining what ports were open/listening was PortQuery GUI.

PortQuery is dead simple to use and effective.  You’ll just want to make sure that the UDP ports are open and listening.

A good utility to use to troubleshoot connectivity from the RRAS server is WireShark.  It’s similar to Network Monitor – but a little easier to use.  If you’re not familiar with packet/network analyzer tools it might be a little much – but it can/will provide some useful information to anyone that is helping you troubleshoot any connectivity issues you might be facing.

Step 1:

• Install Windows Server 2012 R2.
  • You don’t need to install the RRAS components.  The script you will download from Azure later will do all of that for you.  Just get WS2012 R2 running, get all the updates, etc…
  • Configure your network adapters for RRAS.  You will need to two of course.  I simply labeled them “WAN” and “LAN”. 
  • You will want to remove the default gateway from the LAN side interface.  This will ensure any traffic hitting that interface gets routed out the WAN vs going back to your default gateway.  Now, there are other ways to accomplish this – for example, if your existing default gateway has the ability to assign static routes…but for a lab scenario like I have – it was easier to just remove the gateway and configure static routes on all my hosts to point to the RRAS LAN interface when they hit the IP range out in Azure.
  • You will also want to remove some of the ‘bad things’ off the WAN network adapter that can get you into trouble.  Get rid of Client for MSFT Networks and FPR Sharing.   You will also want to go into the TCP/IP IPv4 advanced tab and disable NETBIOS over TCP/IP.  

                     

                       

Step 2:

• Configure your affinity group in Azure.  Azure is a globally dispersed hosting service – where do you want your VM’s to ‘live’?  In the Azure context, these are defined as “datacenters” in “regions”.
• In order to tie VM’s with virtual networks – Azure uses the Affinity Group.  An Affinity Group ties those resources to a specific region.  You probably want to pick the one closest to you if you don’t have a specific preference.
• In Azure on the left hand side menu – click “SETTINGS”.  Now click “Affinity Group” on the menu bar:

           

• Now we need to define a “Local Network”.  A local network defines the properties of the network where your RRAS server resides – specifically the “LAN” side.
  • In my case, I was using the 192.168.1.0/24 for my LAN. 
  • “1.1.1.1” would represent the WAN IP interface on your RRAS server.

                                           

                      

• Now you’ll want to add the hostname/IP address of a DNS server that you want to use.  This DNS server will be added to the VM’s that come online the Azure virtual network we’ll create in a bit.  The significance of this of course is that your Azure VM’s will be able to resolve hostnames across the VPN.  This could be the IP address of an AD Domain Controller across the VPN and/or you could of course bring up a VM in Azure and make it a domain controller in which case you’d make an entry here once you did that so that your Azure VM’s would look to the DC in Azure first for name resolution.

• If you want to install DC’s in Azure – be sure to read this. 

            

• Now we’ve got the CorpNet side under control as far as Azure is concerned.  Next, we need to configure the Azure Virtual Network.  This diagram is basically what we are going for.  I’ll copy my exact configuration from Azure that I used as well for reference and to match it up to the Visio network diagram.

           

• Here is my configuration on the Azure side.  You can do something similar or come up with your own.  I just wanted to put it here so you could match it up with the Visio diagram:

                    

• You are going to click NEW –> Networks –> Virtual Network –> Custom Create:

            

• Now we’re going to set any DNS servers we want our Azure VM’s to connect to (this will be a drop down box and all the DNS servers you created earlier will populate there) and we also want to enable S2S VPN.  Select the local network you created in the drop down.          

           

• The sky is the limit here.  Do whatever works best for you.  You can create a huge address space and then create any number of custom subnets.  You will need to click the button to add the gateway subnet as well.  This will be the default gateway IP address in your Azure VM’s you assign to this vNet.

          

• The next step is to create your gateway.  I forgot to take a pre-screen shot so you’ll see the option here to DELETE mine, but yours will say “CREATE”.  :)  It takes some time for the gateway to complete – so now is a good time to grab lunch, pound through some email, whatever…

           

• Once your gateway is created, you’ll see the gateway IP in big bold on your dashboard.

          

• Next step is grabbing your shared key.  Use the copy button to get it on the clipboard when needed.

           

• The next thing you’ll want to do is create a VM that gets placed into the vNet you just created.  You have to be a bit careful here because you need to place the VM in the right virtual network for it to be able to access resources via the VPN we are creating.  You can’t just put it anywhere and expect it to be able to communicate across the VPN.

       

• The final piece here is finalizing your RRAS configuration.  We’ve already got our server running, dual-homed, with the proper network configuration.  Now we just need to get RRAS installed and get the S2S VPN configured.  Luckily, there’s a script for that. :)  From your S2S VPN dashboard – look in the lower right corner.  You’ll see a link to download the VPN device script.

         

• Choose Microsoft/RRAS/Server 2012 and download the file.

          

• This is going to download a .cfg file.  The easiest way I found to edit this is to simply open it in PowerShell ISE.  You can also use something like Notepad++ to make editing easier.
• You’ve got a few variables that you need to play with here.  You’ll have to copy/paste in a few things custom to your environment to make the VPN configuration on RRAS work properly.
• I opted for the find/replace all option in PowerShell ISE.  You don’t need the brackets <> – you can remove those when you paste the IP addresses into the script.

• Here are your variables you’ll need to grab the IP info for:

• <SP_AzureGatewayIpAddress>: This is the BIG number on the dashboard for your S2S VPN in Azure.
• <SP_AzureVnetNetworkCIDR>:100: This one you have to be careful with.  Azure uses a few more addresses in a standard subnet than usual.  Let’s say in a /24 or 255.255.255.0 subnet – you get to use 252 of those address.  Azure takes 3 addresses, not just two.  So, the 252 is really 251.  This is the number you use in place of the “100” that they show in the sample variable in the script.  So, to find this – go to the ‘configure’ tab in your S2S VPN and take a look at what you have in the first line of the address space.  This is what you’ll use to populate this in the script.  In this specific example it would be:

• IPv4Subnet @("10.0.0.0/24:251")

                                   

• • • -SharedSecret <SP_PresharedKey>: This is an easy one.  Just copy and paste the shared key we created back a few steps ago.

• Now, save the script and run it.  You will probably see the same error message as I did – it just means that you need to go to the RRAS console and start the service on the server.  For whatever reason in my script – it didn’t restart it.  No biggie.

           

• Now from the RRAS console, you should see the S2S VPN connection named for your IP Gateway in Azure.  Right-click and choose CONNECT.

            

• Now, come back over to the Azure portal and go back to your S2S VPN dashboard and click CONNECT on the bar at the bottom of the screen: (mine says disconnect but you get the idea…)

           

• Once that is done you should see the connection come up on both sides and you can start moving traffic across the VPN!!
• One easy way to test connectivity is to log into your Azure VM that you created in the S2S VPN network and ping the LAN IP address of your RRAS server.  If you can’t ping that – then you’ve got something messed up somewhere. 
• Your Azure VM’s will pickup the DNS IP you assigned earlier so provided communication is working and firewalls are configured properly, you will be able to domain join those VM’s since they will have name resolution to your DNS servers as soon as they boot up.

One thing to be aware of.  Depending on your setup, you may need to configure a static route for other computers on your network to see across to Azure.  For example, if an Azure VM with an IP of 10.0.0.4 tries to ping across the VPN to a machine with an IP address of 192.168.1.50, without a static route on 192.168.1.50 to tell it how to get back over to 10.0.04 – the ping will time out.

On the 192.168.1.50 machine you’d need to add a persistent route with the command:

route add –p 10.0.0.0 netmask 255.255.255.0 192.168.1.1

Of course, 192.168.1.1 is the LAN IP of the RRAS server or any other router that you may have that knows the route to get over to the 10.0.0.0/24 network.

GOOD LUCK!!

Comments

• Anonymous
  January 01, 2003
  ...I think it would depend on the device. I know on the IP printers that I work with there is an option to enter a default gateway. As long as that gateway as a route to get to the Azure virtual network then it should work.
• Anonymous
  January 01, 2003
  ...awesome - glad it worked for you!
• Anonymous
  October 10, 2014
  I’m in the process of building out new scenario’s for my EMS focused lab. RemoteApp seemed to be a natural
• Anonymous
  October 16, 2014
  Ken, thanks for the walkthrough...something I needed for my home office as well!
• Anonymous
  January 13, 2015
  The comment has been removed
• Anonymous
  January 19, 2015
  This is great. A step by step guide. Thanks for sharing. But just have one question, could a VPN let's say, HMA, could be used here easily? I got a good read regarding the IP address athttps://www.bestvpnservicemag.com/what-is-my-ip-address/ and just wondering if it functions the same way after these steps. Many thanks.
• Anonymous
  March 29, 2015
  I’m on the my 3rd iteration of my EMS lab. Meaning, I had something up and running (twice) then tore
• Anonymous
  May 03, 2015
  I found that i could add that same route to my home wireless/router to take care of need to add those routes to each vm... I used destination == 10.0.0.0 subnetmask == 255.255.0.0 destinationip == 192.168.2.1 (the ip address of my RRAS VM with S2S setup to Azure... saved me writing a powershell startup/logon script and use group policy
• Anonymous
  May 31, 2015
  i found that the configuration script that you download from azure is preconfigured post creation of the static/dynamic gateway.
• Anonymous
  June 01, 2015
  That is correct. If you try to publish that script prior to that you'll have to populate the values on your own (and I kinda show which ones in the blog post). Just wait until the last step when everything is configured and you should be good to go.