Site-to-Site VPN in Azure Virtual Network using Windows Server 2012 Routing and Remote Access Service (RRAS)
Updated: April 14, 2015
Authors: Piyush Ranjan, Sanjay Mishra, Steven Schneider
Reviewers: Silvano Coriani, Rama Ramani, Aaron Lower, Chris Clayton
This article walks you through the site-to-site VPN setup using the Windows Server 2012 RRAS capability. Virtual Network (VNET) in Azure extends the connectivity boundary that is imposed by Cloud Services and provides a larger container for hosting virtual machines. This extension permits the virtual machines to communicate with each other on their private IP addresses, unrestricted by the Cloud Service boundaries. In addition, VNET also provides a mechanism for extending a customer’s on-premises address space into Azure by using VPN tunnels. This second capability of connecting the on-premises network to the network in the cloud leads to interesting hybrid scenarios, such as the deployment of secondary replicas in a Microsoft SQL Server AlwaysOn configuration for the purpose of disaster recovery.
A site-to-site VPN connection from the on-premises corporate network to the VNET in Azure is typically made through the use of hardware devices such as those from Cisco Systems or Juniper Networks. For a list of hardware devices that are compatible with Azure, see Known compatible VPN devices. For a step-by-step walkthrough of the site-to-site VPN using a hardware device, see Create a cross-premises virtual network - Azure. While the overall process, as described in the walkthrough, is straightforward, its configuration requires specialized knowledge of the actual VPN device that is used (Cisco, Juniper etc.). This step often creates a barrier to a quick adoption of the technology; in particular, it affects the agility of workloads where rapid deployment of the solution is highly desirable. To address this concern, Azure Virtual Network now supports a new mechanism for VPN that relies on the Routing and Remote Access (RRAS) capability of the Windows Server 2012 operating system. This RRAS-based VPN configuration essentially replaces a hardware device by a Windows Server 2012 machine, thereby significantly lowering the barrier to implement hybrid scenarios.
The prerequisites for this walkthrough are the following:
At least one or preferably two publicly visible IP addresses: One of the IP addresses is used on the Windows Server 2012 machine that acts as the VPN device by using RRAS. The other optional IP address is to be used as the Default gateway for out-bound traffic from the on-premises network. If the second IP address is not available, it is possible to configure network address translation (NAT) on the RRAS machine itself, to be discussed in the following sections. It is important to note that the IP addresses must be public. They cannot be behind NAT and/or a firewall.
One Windows Server 2012 machine with two NICs: This machine serves as the RRAS-based VPN server. It requires two network interface cards (NICs) where one NIC is to be assigned the public IP address as discussed previously, and the other is to be assigned a private IP address within the on-premises address space. Also note that the operating system must be a Windows Server operating system beginning with Windows Server 2012. The RRAS feature should not be configured upfront; it is configured later through Windows PowerShell.
Another Windows Server machine with two NICs: This machine is optional. Its purpose is to serve as the Default Gateway for outbound traffic from the on-premises network. If provisioned, this machine also requires two NICs so that the public IP address could be assigned to one of them and the other to a private IP address within the on-premises network. The operating system does not have to be Windows Server 2012, although it is preferred.
Additional machines for testing: Some additional machines are deployed within the on-premises network for testing or for deploying components that are appropriate for the workload.
An active Azure subscription: This subscription is used for provisioning the Virtual Network and virtual machines, which are to be connected to the on-premises network via a VPN tunnel.
The on-premises machines do not have to be physical machines; they can be virtual machines.
The following figure shows the topology of the machines that are used toward this walkthrough in a test environment.
Figure 1: Network topology used for the walkthrough in a test environment
The address space of the on-premises network is 192.168.1.0/24.
A single Windows Server 2012 machine was designated for use as an RRAS/VPN/NAT server. The RRAS or NAT features were not installed or configured at this stage.
The NIC used for private IP address was assigned 192.168.1.11, Subnet mask = 255.255.255.0 and DNS = 192.168.1.10. The Default gateway was left blank.
The NIC used for public IP address was assigned 131.107.x.x, along with Mask and Default gateway. For DNS, the Google DNS = 18.104.22.168 was specified. Also on the Properties for the public interface, the options Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks were cleared.
- The NIC used for private IP address was assigned 192.168.1.11, Subnet mask = 255.255.255.0 and DNS = 192.168.1.10. The Default gateway was left blank.
A Windows Server machine was deployed to serve as the Active Directory domain controller and DNS server for the on-premises network. This machine is shown in Figure 1 with IP address 192.168.1.10, Subnet mask = 255.255.255.0, and Default gateway = 192.168.1.11. This is the internal IP address of the RRAS server as discussed previously. The DNS was 127.0.0.1.
The workload that was tested in this scenario was for the SQL Server AlwaysOn configuration. Therefore, a machine was deployed to act as an instance of SQL Server and was assigned the IP address 192.168.1.12, Subnet mask = 255.255.255.0, Default gateway as 192.168.1.11, which is the internal IP address of the RRAS machine, and the DNS pointed to 192.168.1.10, which is the Active Directory/DNS machine.
The address space in Azure Virtual Network was 192.168.2.0/24. The configuration of the Virtual Networks is discussed in the next section.
Ports were opened on all machines for Internet Control Message Protocol (ICMP) to enable ping to go through by using netsh advfirewall firewall add rule name="ICMP Allow V4 echo" protocol=icmpv4:8,any dir=in action=allow. This command is used only for easily testing connectivity between virtual machines. After the configuration is complete, ping should be blocked again as a defense-in-depth best practices measure.
The steps for the creation of a Virtual Network and the preparation for a VPN connection are described in this section.
An affinity group is required as a container to ensure that all storage and virtual machines provisioned in the Virtual Network are located in close proximity. In the Management Portal, click Settings, navigate to Affinity Groups, and then click Add to open the dialog box as shown in the following figure.
Figure 2: Create an affinity group in the Management Portal
Give a suitable name to the affinity group that indicates its regional location or the purpose for its use, such as project name.
In Azure, local network refers to the on-premises network. In particular, its definition consists of the on-premises address space and the public IP address of the RRAS server. In the present example, the on-premises address space is 192.168.1.0/24 and the public IP address of the RRAS server is 131.107.x.x. From the Management Portal, navigate to Network, to Local Networks, and then, click Add a Local Network to create a local network. Enter the information as shown in the following Figures 3.1 and 3.2.
Figure 3.1: Create a local network in the Management Portal – enter the IP address of the RRAS server
Figure 3.2: Create a local network in a Management Portal – enter the address space of an on-premises network
In the Management Portal, begin to create a Virtual Network. Enter the information in the form as shown in the following figure.
Figure 4: Create a Virtual Network– enter the Virtual Network name and affinity group
For the present example, the on-premises DNS server with IP address 192.168.1.10 is to be used in the Azure Virtual Network after the VPN connection is established. Select the option Site-to-Site VPN and also specify the previously created Local Network that informs the Virtual Network about the on-premises address space and the IP address of the VPN (RRAS) device. The following figure shows the information that was entered for the walkthrough setup.
Figure 5: Create a Virtual Network– enter the DNS server and Local Network information
The following figure shows the address space to be used in Virtual Network and to be carved into subnets.
Figure 6: Create a Virtual Network– carve the subnets in the Virtual Network address space
For the present example, the address space was 192.168.2.0/24, of which Subnet-1 was carved as 192.168.2.0/28 for 16 virtual machines and another subnet for VPN Gateway was created as 192.168.2.16/29.
In the next step, create the VPN Gateway. Click the Create Gateway icon at the bottom of the Management Portal, as shown in the following figure, and select Dynamic Routing for the Gateway type.
Figure 7: Create the VPN Gateway for the Virtual Network
Azure takes some time to complete the provisioning of the gateway virtual machines. After they are provisioned, the interface displays the IP address of the newly provisioned VPN Gateway, as shown in figure 8.
Figure 8: The VPN Gateway has been created
Click the hyperlink “Download VPN Device Configuration Script” to see the form as in Figure 9.
Figure 9: Download a VPN device configuration script
Because the VPN connection is to be established by using the RRAS capability of Windows Server 2012, select the options as shown in Figure 9, and then download the script. The downloaded script is a Windows PowerShell script. For information about the Windows PowerShell format, see Routing and Remote Access Service templates.
The VPN device configuration script that was downloaded in the previous section is a Windows PowerShell script. It installs the RRAS services and configures them for a VPN connection with the VPN Gateway in the Azure Virtual Network. Rename the file name extension of the downloaded file from a .cfg to a .ps1 file name extension to indicate that it is a Windows PowerShell script. Then, on the RRAS/VPN server, run the script by using a Windows PowerShell console with administrative privileges. Note that in order to run the VPN configuration script, the Windows PowerShell Execution policy on the RRAS machine must be set to Unrestricted. To do so, start a Windows PowerShell console with administrative permissions, and then run Set-ExecutionPolicy Unrestricted.
On the RRAS/VPN server, from Server Manager, start the Routing and Remote Access Microsoft Management Console (MMC) as shown in the following figure.
Figure 10: Routing and Remote Access MMC
There should be a Network interface for the VPN connection that is identified by the IP address of the VPN Gateway in Azure. If it shows that the interface is not connected, right-click the interface, and then click Connect.
This step completes the VPN configuration and, after a short delay, the gateway for the Virtual Network in the Management Portal should also show that it is connected as shown in the following figure.
Figure 11: Fully operational VPN
Deploy a few test machines in the Azure Virtual Network. In the present example, two virtual machines were deployed for running instances of SQL Server. You should be able to join the newly provisioned Azure virtual machines to the on-premises Active Directory domain and access other machines in the on-premises network.
This last step is optional and intended to enable the on-premises machines to access the Internet, that is, out-bound traffic. For instructions for the configuration, see Enable RRAS as a VPN Server and a NAT Router. Follow the steps from 5 through 13 in the section “To configure an existing RRAS server to support both VPN remote access and NAT routing”.