Windows Azure virtual networking: Now easier and cheaper to use

Windows has made some updates to the Azure Virtual Network, now in production status, that makes it easier to extend your own network or private cloud into Azure.

Last year, I wrote about Azure virtual networking and explained how this technology extends your corporate network or private cloud into Windows Azure, what I called Bring Your Own Network (BYON). In the last fifteen months, Microsoft has moved the original preview service into production status, charging a base rate of a little over one dollar per day for the site-to-site virtual private network (VPN). 

New features that make Azure VPNs easier and cheaper to use have also been released. You can now deploy the on-premise Azure VPN endpoint on a Windows Server 2012 computer or virtual machine (VM)—previously, only specific hardware endpoints were supported. Also a new Point to Site VPN mode keeps individual computers outside Windows Azure, including roaming workers connected to the corporate Azure Virtual Network as well.

Windows RRAS as an Azure gateway

A barrier to using Azure Virtual Network in the first preview release was that Microsoft required your VPN endpoint to be a hardware device (of a router or firewall type) from Cisco or Juniper.  If you were not already invested in those hardware vendors at the network edge, it precluded you from participating in the Azure Virtual Network preview without purchasing new hardware.

Finally, Microsoft has made support and configuration tools available for their own software networking platform: the Routing and Remote Access Service (RRAS) built into Windows Server. Now using a commodity Windows server platform, organizations can on-ramp to Windows Azure with very low or no new infrastructure costs.

Using RRAS to connect to Windows Azure

A very economical way to connect to Azure Virtual Network is to deploy a Windows Server 2012 virtual machine (VM) running RRAS at the Internet edge. Figure A shows how you can connect a VM to the Internet without exposing the host operating system to direct Internet connectivity. In Figure A, on the left side is the private network, which is connected by Azure S2S VPN to Windows Azure at the top of the diagram. Observe that the Internet switch is connected to the RRAS computer only and not presented to the host or any other guest VMs.

Figure A

Economically deploy a VM as the Azure Virtual Network endpoint.

After you configure your S2S VPN in the Windows Azure management portal, a customized PowerShell script can be downloaded directly and run on the Windows computer to perform all necessary configuration. Figure B shows the complete script which deploys the RRAS role and configures the Azure S2S connection in just 10 lines of code.

Figure B

This script is customized and ready to run; just download from Windows Azure customer portal.

Figure C is what an Azure VPN endpoint looks like running on a Windows Server 2012 computer; this is the RRAS console and a detail of the Security tab of the VPN S2S connection properties.

Figure C

The RRAS console on Windows Server is your Azure Virtual Network gateway.

A benefit to using RRAS for your endpoint is that you can more easily keep an eye on the network bandwidth consumption into, and more significantly, out of Windows Azure. You only pay Microsoft networking charges for downloads from Azure (ingress, or uploads to Azure are free). You can proactively monitor Windows performance counters for the download bytes used by the VPN connection. Figure D shows Windows Performance Monitor running against the Bytes Received counter on the S2S VPN connection to the Windows Azure virtual network in RRAS.

Figure D

Keep tabs on chargeable Azure Virtual Network download costs using Windows Performance Monitor.

New Azure Point to Site VPN

When you establish an Azure virtual network, you have the option to enable either the previously released Site to Site (S2S) mode and/or the new Point to Site (P2S) mode. If you establish only an S2S presence initially, you can later enable also the P2S mode without any reconfiguration.  Enabling the P2S mode has these high level steps:

1. Define the address block to be used by Azure P2S clients. The default is 172.16.0.0/16, but if you are using that subnet already in a local network definition, the 173.0.0.0 subnet can be used as an alternative VPN P2S client network.
2. Create a dynamic routing gateway (this might have been done already if you previously enabled S2S mode).
3. Generate a self-signed root and client certificate using makecert.exe and Microsoft Visual Studio.
4. Export the certificates, upload the root certificate to Windows Azure, and install the client certificates on computers to be connected via P2S.
5. Generate and download the VPN client package from the Azure management portal.
6. Install the VPN client package on the computers to be connected. Client packages are available for these OSs:

• Windows 7 (32-bit and 64-bit)
• Windows Server 2008 R2 (64-bit only)
• Windows 8 (32-bit and 64-bit)
• Windows Server 2012 (64-bit only)

After performing these steps, the computers to be connected will have VPN connection objects for Azure P2S VPN. Connect the VPN on demand as you would for a conventional client VPN. The computers will now have routed network access to the VMs in the Azure virtual network.