Virtual Networks in Microsoft Azure (Part 2)

If you would like to be notified when Janique Carbone releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Virtual Networks in Microsoft Azure (Part 1).

Cross-Premises VNet Overview

A cross-premises VNet is a secure connection from your corporate network to an Azure VNet using an on-premise VPN device. Once the connection is established, resources connected to your on-premises network can communicate directly and securely with Azure resources connected to the Azure VNet. An Azure VNet supports up to 10 connections which can be a combination of cross-premise and VNet-to-VNet connections. There are four types of secured cross-premises connections:

• Site-to-site – secure connection between on-premise site and Azure VNet over IPSEC (IKE v1 and IKE v2)
• Point-to-site – secure connection between individual on-premise devices and Azure VNet over SSTP (Secure      Sockets Tunneling Protocol) with 128 VPN client support
• Multi-Site – secure connection between multiple on-premise sites to a single Azure VNet
• Express Route – secure, direct, and private connection between on-premise infrastructure and Azure datacenters

Your on-premise infrastructure must include an existing Windows Server 2012 deployment with an Azure supported VPN device. Before you embark on the configuration of a cross-premises VNet configuration, check out this link to Azure supported VPN devices. Let’s move on to learn how to configure a site-to-site connection to an Azure VNet.

Site-to-Site Connection Basics

A site-to-site connection is the option that you should choose when you need to provide many devices in a site or an entire site with connectivity to resources on an Azure VNet. This type of connection requires the deployment of VPN hardware on-premise configured with a public IPv4 address.

Figure 1 is a visual representation of a site-to-site connection that enables cross-premises communication to an Azure VNet. The IP address ranges and individual IP addresses in the diagram are purely for illustration purposes and must be replaced with valid IP ranges and addresses for your on-premise network and Azure VNet. In addition, you can see that for your on-premise network, you will probably have to coordinate with your network team to identify the on-premise network address range, the IP address for an accessible DNS server, and the public IP for the VPN device that you want to use for the connection to the Azure VNet.

Figure 1: Site-to-Site Connectivity Diagram for Cross-Premises VNet

In this example, the Azure VNet consists of four (4) subnets that you might find in a typical deployment of a multi-tier cloud service. You will probably define multiple subnets if you intend to deploy tiered cloud services, but an Azure VNet can also be configured with a single subnet.

Creating a Site-to-Site Connection using the Azure Management Portal

Creating a site-to-site VNet using the Azure Management Portal involves three easy steps:

• Creating a virtual network
• Configuring the Azure VNet gateway
• Configuring the VPN hardware on your network

In this example, I use the IP addresses for the on-premise and Azure networks defined in Figure 1 to give you a clear reference point as you go through the Azure virtual network configuration wizards.

From your local system, log in to the Azure Management Portal, and follow this procedure to create a new Azure VNet:

1. Click New, found in the lower left-hand corner of the screen, as shown in Figure 2.

Figure 2: Azure Management Portal Screen

2. In the new pane, click Network Services, and then select Virtual Network, and then the Custom Create option, as shown in Figure 3.

Figure 3: Creating a VNet with Advanced Options

3. On the Virtual Networks Details page, enter a virtual network name and select a location from the dropdown, as shown in Figure 4. You should select the VNet location based on the region where you want to deploy your VMs and cloud services. Once selected, you cannot change the region associated with the VNet.

Figure 4: Defining VNet Network Name and Location

4. On the DNS Servers and VPN Connectivity page, enter your on-premise DNS server name and IP address, check the Configure-Site-To-Site VPN option, and select Specify a New Local Network from the drop-down list, as shown in Figure 5.

Figure 5: Defining DNS Server Parameters and VPN Connectivity Type

5. On the Site-To-Site Connectivity page, enter a name for your on-premise network, the public IP address of your VPN device, and your on-premise subnet address ranges, as shown in Figure 6. Be aware that your VPN device cannot be behind a NAT device.

Figure 6: Defining On-Premise VPN IP Address and Subnets

6. On the Virtual Network Address Spaces page, enter the specific subnet definitions and IP address ranges for your Azure VNet, as shown in Figure 7. If you want to associate multiple subnets to the VNet, select the add subnet option. Address spaces are entered in CIDR notation from the 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 address spaces depending on your required configuration. In this example, you can see the information for the four (4) Azure VNet shown in Figure 1.

Figure 7: Defining Azure VNet Address Spaces

7. Once you click on the checkmark in the lower right-hand corner of the page, Azure creates the new VNet. The VNet then appears in the Management Portal, as shown in Figure 8.

Figure 8: New VNet in Azure Management Portal

8. Next, you have to configure the Azure VNet gateway, which you begin by clicking the new VNet name, and you will see the page shown in Figure 9.

Figure 9: Selecting the Azure VNet

9. On the VNet page, click on Dashboard and then click on Create Gateway at the bottom of the page, as shown in Figure 10.

Figure 10: Azure VNet Dashboard

10. Make sure to select Dynamic Routing, as shown in Figure 11.

Figure 11: Selecting Dynamic Routing for the VNet Gateway

11. While Azure creates the gateway, which takes about 15 minutes, you will see the status shown in Figure 12.

Figure 12: Dynamic Routing Gateway Creation Status

12. When the gateway status changes to Connecting, retrieve the IP address for the Gateway from the Dashboard, as shown in Figure 13.

Figure 13: Gateway IP address after Gateway Creation

13. Next, you need to copy the Shared Key from the Dashboard by clicking Manage Key at the bottom of the page. Copy the key that you find in the dialog box, as shown in Figure 14.

Figure 14: Managing the Shared Key

14. Next, you need to download the VPN device configuration script template from the Dashboard by clicking Download VPN Device Script under the quick glance section, as shown in Figure 15.

Figure 15: VNet Dashboard Quick Glance Section

15. On the Download a VPN Device Configuration Script page, select the vendor, platform, and operating system that matches your on-premise VPN device, as shown in Figure 16. When complete, click on the checkmark to save the file.

Figure 16: VPN Device Configuration Script Settings

16. The final step is to configure your on-premise VPN device with the information that you just gathered. You must modify the VPN device configuration script that you downloaded and update the following parameters:
• Security policies
• Incoming tunnel
• Outgoing tunnel
17. After the modifications are complete, run the script to configure your VPN device.
18. Finally, test the connection to ensure that the site-to-site VNet is performing as expected.

Network Configuration File

When you use the Azure Management Portal to create a virtual network, Azure creates a network configuration file that uses XML syntax. This file contains the following information:

• DNS Server names and IP addresses for virtual networks
• Local Networks for the subscription
• Virtual networks for the subscription
• Gateway for each virtual network

In order to export a network configuration file from Azure, log on the Azure Management Portal and follow this procedure:

1. Select Networks, then select Export at the bottom of the page, as shown in Figure 17.

Figure 17: Virtual Network Export Option

2. On the Export network configuration page, select the desired subscription from the pulldown menu, and click on the checkmark, as shown in Figure 18.

Figure 18: Export Network Configuration Dialog

3. Save the NetworkConfig.xml file as shown in Figure 19.

Figure 19: Saving the Network Configuration File

Here is the content of the network configuration file exported from Azure after creation of the virtual networks, gateways, and connections performed in Part I and II of this article.

You can use an exported configuration file as a template, edit it to specify different settings, and then import the file back into the Azure Management Portal. This is an easier way to create multiple virtual networks when you have more than one Azure subscription.

Conclusion

Microsoft Azure offers the flexibility to create virtual networks that allow deployed virtual machines and cloud services connected to them to communicate with each other securely, and by default, isolated from other networks. However, you can connect virtual networks to each other and on-premise networks through secure IPSEC tunnels if requirements demand connectivity to be available. It is best for you to know what virtual networks and what network-to-network connections you need before you deploy VMs and cloud services as they acquire their network settings during deployment.

If you would like to be notified when Janique Carbone releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.

If you would like to read the first part in this article series please go to Virtual Networks in Microsoft Azure (Part 1).