Virtual Networks in Microsoft Azure (Part 1)

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

Introduction

In Part I of this article, you will learn how to create a new virtual network in Azure. You will also learn how to allow virtual machines and cloud services on different virtual networks to communicate across the Azure backbone by connecting Azure virtual networks to each other. Part II of this article will show you how to extend your on-premise network into the Microsoft Azure public cloud.

Microsoft Azure Virtual Network Overview

Just as you create virtual networks in Hyper-V to connect virtual machines (VM) to each other (private virtual network) or external networks (external virtual network), you can create virtual networks (VNet) in Microsoft Azure to connect VMs and services to each other (Cloud-Only VNet), and also connect an on-premise network to a Windows Azure virtual network (Cross-Premises VNet).

A Cloud-Only VNet is an isolated network that you create to connect virtual machines or cloud services to allow them to communicate across the Azure backbone. You must be proactive and plan out your VNet configuration before virtual machine and cloud service deployments because they acquire their network settings at deployment time. If you create a new VNet and want to connect existing VMs and cloud services to it, you will have to redeploy them to accomplish your objective.

A Cross-Premises VNet allows you to create a secure connection using a VPN device on your on-premises network to an Azure VNet Gateway. After the connection is established, resources connected to your on-premises network can communicate directly and securely with Azure resources connected to the Azure VNet. This is the type of configuration that you would implement if you were deploying a branch office with multiple devices that required access to resources deployed in Azure. It is also possible to setup point-to-site secure connections to an Azure VNet if you require the ability to configure connections from a limited number of on-premises devices. In this case, you configure a connection on each device using a VPN client. If you have on-premises infrastructure that requires fast speed, reliable, low latency, and higher security connections to Azure resources, you can use the Azure ExpressRoute service to build private connections that do not use the public Internet. With ExpressRoute, connections from on-premises networks are established at an ExpressRoute location, or from your wide area network (WAN) through a service provider.

Creating a Cloud-Only VNet

Creating a Cloud-Only VNet using the Azure Management Portal is a fairly easy process. After you create the VNet, you can deploy and connect virtual machines and cloud services that need to communicate with each other.

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

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

Image
Figure 1: Azure Management Portal Screen

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

Image
Figure 2: Creating a VNet with Advanced Options

  1. On the Virtual Networks Details page, enter a virtual network name and select a location from the dropdown, as shown in Figure 3. The virtual network name can be anything you like, but you should develop and use a naming convention that identifies the purpose of the VNet. 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.

Image
Figure 3: Defining VNet Details

  1. On the DNS Servers and VPN Connectivity page, you do not need to make any changes. Azure will provide name resolution by default, as shown in Figure 4. Since you are creating a Cloud-Only VNet, you do not need to select the Site-to-Site or Point-to-Site Connectivity options.

Image
Figure 4: Defining DNS Server and VPN Connectivity

  1. On the Virtual Network Address Spaces page, you do not need to make any changes unless you require a specific subnet definition or internal IP address range, as shown in Figure 5. If you want to associate multiple subnets to the VNet, select the add subnet option. When you deploy new VMs to this VNet, Azure allocates IP addresses from the defined ranges to communicate within the VNet only.

Image
Figure 5: Defining VNet Address Spaces

  1. 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 6.

Image
Figure 6: New VNet in Azure Management Portal

  1. When you create new VMs to deploy to the new VNet through the Azure Management Portal, you must select the From Gallery option to have the option to select the new VNet.

VNet to VNet Connection Background

If you deploy VMs and cloud services on different Azure VNets, and at a later time you require them to communicate with each other, you have to configure a VNet to VNet connection to create a communication path. A VNet to VNet connection requires the use of an Azure VPN gateway with dynamic routing. VNets can be connected using IPSEC tunnels, and a single VNet can connect to up to 10 VNet to VNet gateways. By default, a VNet only allows network traffic across a single VNet to VNet gateway connection. VNets can be in the same or different Azure subscriptions, and same or different Azure regions.

VNet to VNet connections can be configured either using a hub and spoke model or a daisy chain model, as shown in Figure 7 and 8, respectively.

Image
Figure 7: Hub and Spoke VNet Connection Model

In the hub and spoke model, a VM on VNet1 can communicate to VMs on VNet2, VNet3, VNet4, and VNet5. However, a VM on VNet2, VNet3, VNet4, or VNet5 can only communicate to a VM on VNet1 because of the default single hop isolation for a VNet to VNet connection.

Image
Figure 8: Daisy Chain VNet Connection Model

In a daisy chain model, a VM on VNet1 can communicate to VMs on VNet2, but not to VMs on VNet3, VNet4, and VNet5. However, a VM on VNet2 can communicate to a VM on VNet1 and VNet3, but not VNet4 or VNet5 because of the default single hop isolation.

Creating a VNet to VNet Connection

In order to create a VNet to VNet connection, you have to first ensure that the IP address ranges defined for each VNet do not overlap. For example, if you are connecting virtual networks named SouthCentralVNet1 and SouthCentralVNet2, then the address ranges should be unique as shown in Table 1.

Virtual   Network

Virtual   Network IP Address Definition

SouthCentralVNet1   (VNet1)

10.1.0.0/16

SouthCentralVNet2   (VNet2)

10.2.0.0/16

Table 1: Example VNet IP Address Ranges

Once the virtual networks are created, there are five more steps to perform before the VNet to VNet connection configuration is complete:

  • Configure each VNet to identify the other VNet as a local network site in Azure
  • Create dynamic routing gateways for each VNet
  • Configure each local network with the IP address of the local gateway
  • Configure a shared key for the VNet to VNet connection
  • Connect the VPN gateways

From your local system, log in to the Azure Management Portal, and follow this procedure to create a VNet to VNet connection for two existing Azure virtual networks with unique address ranges:

  1. On the Azure Management Portal, click New, then select Network Services, then Virtual Network, and then select the Add Local Network option, as shown in Figure 9.

Image
Figure 9: Add Local Network Option

  1. On the Specify your local network details page, enter the name of the first VNet that you want to connect, as shown in Figure 10. For the VPN Device IP Address, enter a placeholder address as you will come back and configure this parameter after Azure creates the gateway IP address a little later in the process.

Image
Figure 10: Configuring Local Network Details

  1. On the Specify the address space page, enter the actual IP address range that was created for VNet1, as shown in Figure 11.

Image
Figure 11: Configuring Local Network Address Space

  1. Repeat Steps 1 to 4 for VNet2 using the unique IP Address range defined for the virtual network in Azure.
  2. On the Networks page, click on VNet1 and then select the Configure page as shown in Figure 12.

Image
Figure 12: VNet1 Configure page

  1. In the site-to-site connectivity section, select Connect to the local network, and then select VNet2 as the local network, as shown in Figure 13.

Image
Figure 13: Selecting Site-to-Site Connectivity for VNet1

  1. In the virtual network address spaces section, click add gateway subnet,and then click the save icon, as shown in Figure 14.

Image
Figure 14: Adding a Gateway Subnet for VNet1

  1. Repeat Steps 5 to 7 for VNet2 and specify VNet1 as a local network.
  2. On the Dashboard page for VNet1, select Create Gateway as shown in Figure 15.

Image
Figure 15: Creating a Gateway for VNet1

  1. Make sure to select Dynamic Routing, as shown in Figure 16.

Image
Figure 16: Selecting Dynamic Routing for the VNet Gateway

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

Image
Figure 17: VNet1 Dashboard Status during Gateway Creation

  1. Repeat Steps 9 and 10 to create the gateway for VNet2. You do not need to wait for the first gateway to be created as Azure can create both gateways concurrently.
  2. When the gateway status changes to Connecting, retrieve the IP address for each Gateway from the Dashboard, as shown in Figure 18.

Image
Figure 18: Gateway IP address after Gateway Creation

  1. On the Add a Local Networks page, click on VNet1, and then click Edit at the bottom of the page. For the VPN Device IP Address, enter the IP address of the gateway that you recorded for VNet1, as shown in Figure 19.

Image
Figure 19: Local Network Gateway IP Address Configuration

  1. Repeat Step 14 for VNet2.
  2. The final step to set up the VPN gateway connection is to configure the pre-shared IPSEC key to the same value. You can accomplish this by using the following cmdlets in a Windows Azure PowerShell:
    Set-AzureVnetGatewayKey –VNetName SouthCentralVNet1 – LocalNetworkSiteName VNet2 – SharedKey AB12cd34
    Set-AzureVnetGatewayKey –VNetName SouthCentralVNet2 – LocalNetworkSiteName VNet1 – SharedKey AB12cd34
  3. After these cmdlets complete successfully, you can select the Connect option on the VNet Dashboard page, and the connection will initialize. Once the connection is initialized, the Dashboard will display the VNet to VNet connection, as shown in Figure 20.

Image
Figure 20: Successful VNet to VNet Connection

Conclusion

A Microsoft Azure Cloud-Only VNet default configuration restricts communications between resources deployed on that VNet. A VNet to VNet connection allows you to provide a communication path between resources deployed on two different VNets across the Azure backbone. The configuration of a VNet to VNet connection is very similar to the configuration of an on-premises network to an Azure VNet, which you will learn in Part II of this article.

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

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top