Introduction

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.)

Requirements

The Windows Azure Gateway documentation lists the following requirements for the on-premise VPN device:

• 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

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:

• Create one or more virtual networks (WAVN) in Windows Azure
  These will host you Windows Azure VMs and be your LANs in Windows Azure.
• Define a local netwok in Windows Azure
  Configure this network with all the subnets that you run in your on-premise network, as well as the public IP address of you VPN device.
• Add at least one DNS server to Windows Azure
  These can be any DNS server; on-premise, in Windows Azure and public DNS. All the servers you add will be assigned with Windows Azure DHCP to your VMs.
• Set aside one subnet within the networks you created in Windows Azure to be the link-network
  This network represents the link between you and Windows Azure. It must be within the boundary of the networks you created in Windows Azure in the previous step.
• Enter the public IP of your VPN device
  The VPN device cannot be behind a NAT, not even a 1:1 NAT with public IPs.
• Start the Windows Azure Gateway

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:

• Establish a Site-to-Site VPN Connection
  http://msdn.microsoft.com/en-us/library/windowsazure/jj156210.aspx
• Create a Virtual Network for Cross-Premises Connectivity
  http://www.windowsazure.com/en-us/manage/services/networking/cross-premises-connectivity/

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:

• You cannot establish an IPsec tunnel to a computer that is running Windows 7 or Windows Server 2008 R2 through a NAT device
  http://support.microsoft.com/kb/2523881

The Local Network

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.

Routing

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.

The VPN server

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.

High level setup steps

• Document the public IP of your VPN server and the public IP of your Windows Azure Gateway endpoint, as well as your Windows Azure networks and local networks. You will need these during setup.
• Find you IPSec encryption key from the Windows Azure portal.
• Enable routing
• Configue IPSec tunnel
• Verify connectivity
• Add VM in Windows Azure and promote to domain controller.

Retreive the IPSec encryption key

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:

Enable routing

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.

Configure the IPSec tunnel

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 here. 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:

Add Windows Azure Virtual Machines

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.

Verify connectivity

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:

Scripts

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:

1. Enable IPv4 routing:
   You don’t really need RRAS installed to make Windows Server route IPv4 traffic. You can configure the same functionality directly with NETSH. This removes the requirement for RRAS to be installed. To configure routing you must first find either the interface names or indices of your network interfaces. In this case mine are 12 and 14. 12 is the External interface connected to the Internet and 14 is the Internal interface connected to the LAN. Routing, or IP datagram forwarding, must be configured on both. Use NETSH:
   netsh interface ipv4 set interface “12” forwarding=enable netsh interface ipv4 set interface “14” forwarding=enable
2. Create connection security rule with rule specific quick mode settings:
   netsh advfirewall consec add rule name=”Windows Azure” endpoint1=”192.168.0.0/16″ endpoint2=”10.1.0.0/16″ action=”requireinrequireout” description=”Site-to-site VPN for Windows Azure” mode=”tunnel” profile=”any” type=”static” localtunnelendpoint=”80.212.96.194″ remotetunnelendpoint=”168.63.16.208″ protocol=”any” auth1=”computerpsk” auth1psk=”wL8fC…” qmsecmethods=”ESP:SHA1-AES128+60min+102400000kb”
3. Create main mode rule that matches traffic between the local network and Windows Azure. This rule will then be used by the connection security rule. This is a redundant step since the default settings of Windows Server 2008 R2 match the requirements of Windows Azure. This is just to show how it’s done…
   netsh advfirewall mainmode add rule name=”Windows Azure IPSec Main Mode Settings” mmsecmethods=”dhgroup2:aes128-sha1″ mmkeylifetime=”480min,0sess” description=”Main mode settings compatible with Windows Azure Gateway” endpoint1=”192.168.0.0/16″ endpoint2=”10.1.0.0/16″
4. Configure the TCPMSS size:
   netsh interface ipv4 set subinterface “<name of interface>” mtu=1350 store=persistent

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:

• Windows Firewall and IPsec Policy Deployment Step-by-Step Guide
• Netsh Command Reference

Notes

• IPv6 is currently not supported by Windows Azure so you will have no IPv6 native connectivity. Maybe you can make some of the transition technologies work. I have not tested that.
• The VPN Server itself will not be able to communicate with virtual machines in Windows Azure. Only computers behind the VPN server will have communication.
• I was able to measure a transfer speed of about 9 Mbps between my local network and a Small Instance VM running in Windows Azure. I used IPERF to test.
• I have experienced some instability with this solutions but I am not sure if this has to do with Windows Server or Windows Azure. Leave a comment with your experiences.
• The Windows Firewall protects your VPN Server on the Internet. make sure that it is configured correctly. May I also suggest to remove any unnecessary bindings on the Internet facing NIC. Also remember that the VPN traffic is not inspected by the firewall since it is inside the tunnel.
• The configuration scripts available for supported gateway devices, currently Cisco and Juniper, are quite useful to understand the settings needed to configure your VPN server. These are available for download through the Windows Azure Managmenet Portal, under Networks.
• Windows Azure PowerShell can also be used to manage and set up your networks and gateway.