Site-to-Azure VPN using Windows Server 2012 RRAS

UPDATE: Less than 2 weeks after I posted this, Microsoft Azure now officially supports Windows Server 2012 RRAS to establish the Site-to-Site VPN and Point-to-Site VPN using IEKv2!  So don’t follow the steps in this guide anymore, and check out Sandrino Di Mattia’s guide instead.

After you create a new Network Site in Azure to host your Virtual Machines, you can establish a Site-to-Site VPN to enable secure and private network connectivity to your Corpnet using Azure’s Gateway Service.  At the time of this writing, there is a fairly short list of supported devices that can be used to establish this connection which includes 8 Cisco devices and 4 Junipers.  But if you do not have one of these devices, or if you just want to try test things out without making changes to your production network equipment, there are other ways to get connected.  They work great, but you’re not going to get a lot of Sympathy from Azure Technical Support if you’re not using a Cisco or Juniper at this point. Earlier, I wrote an article on How to Configure the Azure Virtual Network for Site-to-Site VPN, which includes the deployment of a virtual machine to do some connection testing with.  In this article, I’ll show you how to use Windows Server 2012 with the Routing and Remote Access Service role to act as your Corpnet gateway to the Azure site.

• Requirements
• Configure Windows Server and Routes
• Configure MTU and NAT-T
• Install and Configure RRAS
• Create the IPSec VPN Tunnel
• Test the Connection

This will allow you to deploy a simple Virtual Machine to your Corpnet that will provide the network path to your cloud hosted Virtual Machines.

Requirements

Microsoft provides setup scripts to configure the supported devices, so if you have such a device, you can pretty safely assume that you meet those requirements.  Since we’re not using a supported device, we will need to pay a little more attention to the details.  The specific requirements can be found in the MSDN Library which states:

• VPN device must have a public facing IPv4 address
• VPN device must support IKEv1
• Establish IPsec Security Associations in Tunnel mode
• VPN device must support NAT-T
• VPN device must support AES 128-bit encryption function, SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode
• VPN device must fragment packets before encapsulating with the VPN headers
• UDP port 500, UDP port 4500 and ESP packets must be permitted to traverse the network edge (open ACLs in the edge to allow these protocols / ports)

Windows Server 2012 can be configured to meet all of these requirements!

Configure Windows Server and Routes

The RRAS Server will be acting as a Router, Firewall and VPN entry point, so this mean the RRAS Server will need two network interfaces, one “Inside” which is attached to the Private Corpnet subnet, and the other which is “Outside” and connected to the Public Internet.  Yes, the the Internet, and not behind a public facing firewall.  You cannot NAT the address.  Even using Null-NAT or 1-to-1 NAT will not work here.

As in the example above, the RRAS server does not need to be the Default Gateway for your entire corpnet to find it’s way to the Internet, but you will need to configure a route on the existing default gateway so that all traffic which is destined for your Azure subnet(s) will send that traffic to the internal interface of the RRAS server which will in turn send that traffic over the site-to-site VPN tunnel.  In the example above, the computers on the Corpnet are configured to 10.26.1.1 as their Default Gateway, and the Gateway is configured to send all 10.30.x.x traffic to the RRAS server on 10.26.77.35.  The RRAS server then knows how to route traffic over the VPN. The Outside interface should be configured with the Public IP, Subnet and Gateway, but NO DNS servers.  Also disable the Client for Microsoft Networks, File and Printer Sharing.

Under the Advanced configuration for TCP/IPv4 you can configure it to NOT Register with DNS and Disable NetBIOS over TCP/IP. The Inside interface should have a Private IP and Subnet for your Corpnet as well as your internal DNS servers configured.Leave the Gateway address blank.  This causes the server to send all traffic which is not destined for the subnet that is directly assigned to the Inside interface to got over the Outside adapter. 

If you happen to have multiple subnets at the Corpnet that you want to make available to your Azure VMs, then you will need to configure the RRAS server with Static Routes to be able to use the Internal Gateway to find the other networks.  For example, if you also have a 10.27.0.0/16 network at the corpnet, then you will need to configure the RRAS server to send that traffic to the default gateway in order to find it’s way there.  You do that by using the “route” command.From an elevated command prompt, execute the following: route add mask metric 1 -p You should now be able to ping resources in the other subnet from the RRAS server.

Configure MTU and NAT-T

UPDATE: It is no longer necessary to modify the MTU or change the Registry to support NAT-T if you use the officially supported configuration of WS2012 RRAS.

The documentation on configuring your VPN device clearly states that the TCP MSS (or “Maximum Segment Size”) should be set to 1350.  This is to control the packet size being sent over the VPN and prevent fragmenting of the traffic once the data is encrypted with IPsec.  We can control that by adjusting the MTU size on the Outside interface of the RRAS server using NetSh to keep the overall packet size under the default of 1500 that the rest of the Internet uses.

First, use “netsh int ipv4 show int” to see the list of your existing network interfaces, then using the Name of your Outside interface, execute the following command: netsh int ipv4 set subint “” mtu=1350 store=persistent Afterward, use the first command again to validate the MTU size has been changed. Support for NAT-T or “NAT Traversal” is required because technically the Gateway in Azure is behind a NAT (which is why your gateway cannot be NAT’d).  But RRAS in Windows Serer 2008 R2 and 2012 does not support NAT-T…by default.  Brian Lewis pointed me to a great blog post by Morgan Simonsen where he mentions that Windows Server 2008 R2 actually has a Hotfix available (KB2523881) which actually “restores the windows 2003 behavior for supporting 1 client over NAT-T IPSEC tunnel”, but there is nothing out there for Windows Server 2012. After some digging and asking around, I was directed to a much older Support article (KB885407) that shows how to enable NAT-T in the Windows XP SP2 Firewall by editing a single registry key.  After hearing that it does the trick on 2008 R2, I decided to try it out on 2012 and it works! “To allow an IPsec NAT-T initiator to connect to a responder that is located behind a NAT, you must create and set the AssumeUDPEncapsulationContextOnSendRule registry value on the initiator.”

This key belongs under HKLMSYSTEMCurrentControlSetServicesIPsec which does not exist on Server 2012, so we need to first open Regedit and create the IPSec Key.

Then create a DWORD value named AssumeUDPEncapsulationContextOnSendRule.

And set the Decimal value to 1 so it can initiate IPsec-secured communications with responders that are located behind network address translators; which is the case with the Azure Gateway.

Install and Configure RRAS

Now you’re ready to set up the server to act as a network router! From the Server Manager start the Add roles and Services wizard and enable the Remote Access role.

We are not going to configure DirectAccess, but we do want VPN (RAS) and Routing enabled.

Complete the wizard and from the Tools menu of the Server Manager open the “Routing and Remote Access” console (NOT the Remote Access Management console which is really geared more towards DirectAccess).Right click your server name and select Configure and Enable Routing and Remote Access.

When promoted, select Custom Configuration. Enable LAN Routing and click Next.  You may see a warning about opening firewall ports which is OK.

Finish the wizard and click Start service when prompted. 

Congratulations, your Windows Server is now a Router!  We’re done with RRAS, so you can now close the console.

Create the IPSec VPN Tunnel

Now that the server is configure to act like a router, we will configure the Firewall to establish the IPSec VPN tunnel.  This is actually similar to the way DirectAccess tunnels are established by leveraging the IPSec rules on the Firewall, but we’re going to manually configure it instead of using a GPO that was generated by a wizard.Open the Windows Firewall with Advanced Security console, right click the Connection Security Rules and create a New Rule.

Select TunnelCreate a Custom configuration and select No to not to exempt any network traffic that matches.

Select Require authentication for inbound and outbound connections.

This next page is really the linchpin that ties the Azure Gateway to your RRAS server.Consider Endpoint 1 to be your Corpnet where the RRAS server is, and Endpoint 2 (scroll down on the page to see it) is the Azure site side of things.

Using the topology diagram from earlier, simply fill in the IP addresses and subnets for each endpoint. 

For the Authentication Method select Advanced and click Customize.

For the First authentication methods click Add and select Preshared key. Paste in the string of text key that you got from the Azure. You can now click OK twice and proceed with the wizard (there is no second method).

If you don’t know what your Preshared key is, then you can find it in the Azure portal by selecting the Virtual Network and clicking Manage Key from the Dashboard.

We want the rule to apply everywhere Name the rule and click Finish.

We have one last thing to change, almost done!From the MMC, right click the Windows Firewall with Advanced Security console and select Properties.

From the IPsec Settings tab click the Customize button for IPsec defaults, then set the Data protection (Quick Mode) to Advanced and click Customize.

Select the AES-CBC 128 algorithm under Data integrity and encryption and click Edit.  Change the Key lifetimes in KB to 102 400 000 which is 100GB to match the Azure security policy.  Click OK a bunch of times and you’re all done!

Test the Connection

Check out the Main Mode and Quick Mode sections under the Security Associations and you should see connections from your c.c.c.c IP under the Local Address going to the a.a.a.a IP under Remote Address.

If you don’t see any associations listed then just try to ping something in your Azure subnet which should bring them up. Note: You will not be able to ping the Azure network from the RRAS server, you will need to test from a computer that is “behind” the RRAS server. If you’ve allowed it through the firewall of your testvm, then you should be able to ping it from a computer that is on the corpnet. 

If you go to the azure Portal and Connect to your Test VM to open a remote desktop session. 

You should also be able to ping from the VM in Azure to something on the Corpnet. Aside from ping, you should also be able to browse UNC Network paths, copy files, remote desktop to other computers, open intranet pages and browse the Internet too. 

You can now join an Azure hosted VM to the domain, even deploy a Domain controller out there if you’d like. After using it for a while, take a look at the Network Dashboard and you’ll see the amount of data that has gone In and Out of the network over the gateway.  

Remember, traffic going in to Azure is free, but outbound traffic is paid for.  In the example above a copied an ISO from the Corpnet to the Azure VM just to watch it work. Note: Your site-to-site VPN operates as a split tunnel, meaning traffic from the Azure VM that is destined for the Corpnet will come over the VPN, but other subnets will go straight out to the internet.

Summary

So with a little bit of doing, you’ve established a permanent link between your office and a private network hosted in Azure.  Again, this is not a supported configuration, but if you want to get connected in a pinch, this does the trick and uses nothing more than native  in-box features too!

UPDATE: While the steps in this guide are not a supported configuration, Azure DOES support using WS2012 RRAS to establish Site-to-Azure VPN tunnels…you just set it up differently now.

N’joy!