Together with the launch of Windows Azure Infrastructure as a Service (IaaS) this summer, Microsoft also introduced a way for customers to connect their on-premise networks with Windows Azure using site-to-site VPN.
The service responsibel for this feature is called Windows Azure Gateway. It uses IPSec to establish a site-to-site VPN tunnel between your network and your networks in Windows Azure. Effectively adding a second site to your network. Currently only Cisco and Juniper devices are officially supported as your local part of the tunnel. However since Windows Azure Gateway is using standard IPSec site-to-site tunneling you could theoretically use any device supporting the requirements. One such scenario using Windows Server 2008 R2 as our on-premise router, is the purpose of this port. (If you’re wondering why I’m not using Windows Server 2012, the answer is simply that it does not support the requirements. Specifically Windows Server 2012 does not do NAT-T like Windows Server 2008 R2 does.)
The Windows Azure Gateway documentation lists the following requirements for the on-premise VPN device:
Fortunately for us Windows Server 2008 R2 supports all of these! So let’s set it up.
Before you can configure your local device you have to perform these steps in the Windows Azure Management Portal:
These are high-level steps. The Windows Azure documentation goes into great detail about how to configure your cloud networks etc. This post focuses on using Windows Server as you local VPN device so I will not repeat the specific steps here. Instead I refer you to the documentation:
After completing the setup in Windows Azure you are ready to configure your local device.
The Windows Server 2008 R2 machine you will be using as your VPN device must have hotfix 2523881 installed. This patch enables the old Windows Server 2003 mode of NAT-Traversal (NAT-T) which is required by Windows Azure Gateway. If you do not have this hotfix installed, you will receive traffic into your network but return traffic will not work. Here is the link to the hotfix:
This is the local network topology in my test environment:
Our task here is to connect our on-premise network with our Windows Azure networks and then promote a server in Windows Azure to a domain controller for our Active Directory domain.
Your local VPN server does not need to be the default gateway for your local network, but if it is, it will make your setup easier. Suffice it to say that you need to work out the routing requirements in your environment. In this example I assume that the VPN server is also your local default gateway. Your VPN server should not have a default gateway IP set on the NIC connected to the local network (LAN). If you require custom routing use RRAS, the route command or NETSH to set up your routes.
Your local Windows Server machine needs at least two NICs, one connected to your local network and one to the public Internet. The server does not need to be joined to your domain. I highly recomment you keep the Windows Firewall enabled on the VPN server. Having a server directly connected to the Internet without a firewall is not a good idea.
Log on to the Windows Azure portal and select Networks. Click the network your are connectin your on-site network to and select View Key (you will find this at the bottom of the screen):
Copy the displayed key:
Install the Routing and Remote Access (RRAS) Role Service which is part of the Network Policy Server and Access Services role. You will need to select both Remote Access Service and Routing, one cannot be installed without the other. You can do this either through Server Manager or PowerShell.
The PowerShell command is:
Add-WindowsFeature NPAS-RRAS-Services –IncludeAllSubFeature
Enable and configure Routing and Remote Access for LAN routing only. Right click Routing and Remote Access and select Configure and Enable Routing and Remote Access:
Select Custom Configuration and the select LAN Routing:
What this step does is turn Windows into an IPv4/IPv6 router. It simply tells it to start forwarding IP datagrams. Unless you have special routing requirements in your environment you are finished with configuring RRAS.
In Windows Server 2008 and newer IPSec settings have been merged into the Windows Firewall.
1. Open Windows Firewall with Advanced Security and select Connection Security Rules:
2. Right click and select New Rule. On the Rule Type page, select Tunnel:
3. On the Tunnel Type screen, leave the default Custom configuration and No for IPSec exemptions selected and click Next:
4. On the Requirements screen leave the default: Require authentication for inbound and outbond connections selected and click Next:
5. Next, on the Tunnel Endpoints screen, configure the tunnel endpoints and networks. (You will have to scroll down to configure the networks for Endpoint 2):
NOTE: It is extremely important that the networks you define here match your local network configuration in Windows Azure or your traffic will not be routed.
6. On the Authentication Methods screen, select Advanced and then press the Customize button:
7. In the Customize Advanced Authentication dialogue add a Preshared key authentication for the First Authentication Methods:
8. On the Profile screen select the Firewall Profiles for which this rule will apply. Usually it will be all three:
9. At the Name screen, give the rule an appropriate name and description:
10. Windows Azure Gateway requires that you change the TCP Maximum Segment Size (MSS) to aviod fragmentation. You do this with NETSH on your external (Internet facing) interface. First list your interfaces:
netsh interface ipv4 show subinterfaces
In the Interface column you should recognize your interface names. Now change the TCP MSS value:
netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent
Run the first NETSH command again to verify the change.
11. Configure the IPSec Quick Mode key lifetimes. Windows Azure Gateway uses a Quick Mode (Phase 2) key lifetime of 1 hour (3600 seconds) or 100 GB of traffic, whichever happens first. The Phase 1 key lifetime is 8 hours, which is the default in Windows Server 2008 R2 so there is no need to change that.
Right click the Windows Firewall with Advanced Security node at the top of the Windows Firewall console, and select Properties. Then select the IPSec tab, and press the Customize button:
Next select the Advanced radio button under Data protection (Quick Mode) and press the Customize button. Under Data integrity and encryption select the entry called ESP/SHA1/AES-CBC 128 etc. and press the Edit button:
Under Key lifetimes the timeout value in minutes is already set correctly to 60 minutes (3600 seconds) so we only need to configure the KB timeout. Set it to 102 400 000 KB (100 GB).
Exit out of all the boxes by pressing OK.
NOTE: These are global settings which affect all connection security rules on the server. If you want to specify these settings only on the connection security rule that pertains to Windows Azure, use NETSH. Unfortunately you cannot configur connection security rules specific main mode or quick mode settings in the GUI. Also you cannot use NETSH to configure global quick mode settings, only main mode settings. The logic behind this escapes me…. If you do decide to configure rule specific quick mode settings with NETSH, the GUI will inform you that your rule “…contains properties that are not supported through this interface”. That said I would actually recommend using rule specific quick mode settings because that way you won’t have to change the computer defaults which could potentially cause problems for other rules. Although not needed by Windows Azure Gateway, because the default settings match the required settings, you can also configure specific main mode rules that match e.g.endpoints, using NETSH. More about the diffrences between the Advanced Firewall GUI and NETSH . Also have a look at the scripts section at the end of the post.
12. Verify that the IPSec tunnel has been created using the Monitoring node of the Windows Firewall with Advanced Security console. Under Security Associations you should have an association under both the Main Mode and Quick Mode nodes:
If you do not see any security associations, try to ping an address in one of your Windows Azure networks. This should establish the tunnel.
13. Verify connectivity in the Windows Azure portal:
Now you can add Windows Azure VMs to your Windows Azure networks. These machines will receive IP addresses from the Windows Azure DHCP service. The addresses will be leased to the machine for its lifetime so it will be the same as having a static IP. Windows Azure DHCP will also configure the servers with the DNS servers you have defined in Windows Azure. These can be both on premise and in the cloud. The default gateways for the machines will be set to the first address on the subet that the machine is connected to.
After the first Windows Azure VM is online (and its firewall opened) you should be able to send traffic across the VPN. In my case I can now ping between my Windows Azure VM and on-premise machines:
Now I can add the make the Windows Azure VM a domain controller:
Since network devices like routers and switches are usually configured using scripts, here are the NETSH commands to configure Windows Server as a VPN device from the CLI:
So if you combine all the commands in a nice cmd file you have something resembling a router configuration script.
More info on NETSH syntax is available here: