Getting to Know #Azure Virtual Networks

Why are Virtual Networks Important?

As a developer, I used to forget about Virtual Networks. And to be fair, I shied away from pretty much everything that can be considered as infrastructure.

Microsoft Azure is a game changer! It requires Developers and IT Pros to collaborate on projects. Let’s take a moment to set things right. Developers and IT Pros are not competing against each other in this new world. They collaborate in order to produce value for the business and customers.

As we move to a Cloud First and Mobile First world, security is more important than it ever was. On Microsoft Azure, the first step towards securing your application resources is to create a Virtual Network.

Microsoft Azure is constantly evolving and augmenting its security. Everything starts at the edge of the public Internet. This is where mechanisms like DDoS protection kick in. Then traffic is routed through multiple network layers and finally reaches public Endpoints that are configured on Cloud Services.

Cloud Services are containers. Like a firewall, they protect resources such as Roles and Virtual Machines from the outside world. They provide our resources with an internal network. At this point, it’s important to note that Cloud Services can contain up to 25 Roles. However, it is recommended to apply the Single Responsibility Rule (SRP) and to keep the Role count low. This helps reduce accidental complexity when it comes to deployments and maintenance.

Since Cloud Services are internal networks shielded from the outside world, they communicate over public Endpoints. The diagram below illustrates a 3-tier Cloud Service that is accessible from the outside world.

Each tier is discoverable and accessible from the public Internet. In some scenarios, this can be favorable. However, it can be considered as an attack vector.

In order to secure our applications, best practices recommend the use of Virtual Networks and Subnets. As shown below, we can take advantage of Network Security Groups (NSG) and Access Control Lists (ACL) to control network traffic.

This diagram illustrates that a Front End tier of an application is accessible from the public Internet. It also shows that the Middle tier is only accessible from the Front End and that access to the Back End is limited to the Middle tier.

Getting to Know Azure Virtual Networks (VNet)

What is a Virtual Network (VNet)

A Virtual Network (VNet) is a network overlay that you can configure in Azure. Virtual Machines and Services that are part of the same Virtual Network can access each other. However, services outside the virtual network have no way to identify or connect to services hosted within virtual networks unless you decide to configure that specific type of connection, as in the case of VNet to VNet configurations. This provides an added layer of isolation to your services. Azure Virtual Network also lets you extend your network into Azure and treat deployments as a natural extension to your on-premises network.

Take Notice

Virtual Machines and Cloud Services acquire their network settings during deployment. This means you can’t move something into a Virtual Network if it is already deployed. In order to move a deployed resource into a Virtual Network, you need redeploy it.

When Do You Need A Virtual Networks (VNet)?

Whether you need a Virtual Network depends entirely on what you are trying to do. Azure currently supports two categories of Virtual Networks. The first is a Cloud-Only Virtual Network. And the second is a Cross-Premises Virtual Network (Hybrid Cloud Solutions). If you start with a Cloud-Only Virtual Network, you can convert it to a Cross-Premises Virtual Network. Going through a migration from no Virtual Network to a Cross-Premises Virtual Network can be painful and incur unwanted downtime.

The major advantage of starting with the Virtual Network is flexibility. You can create multi-site configurations, VNet to VNet configurations, ExpressRoute connections, and combinations of multiple configuration types.

Considerations for Using a Virtual Network (VNet)

• Name Resolution (DNS) – If you want to connect to your Virtual Machines and Cloud Services by hostname or SRV records, rather than using the IP address, you need a Name Resolution (DNS).
• Enhanced Security and Isolation – Only virtual machines and services that are part of the same network can access each other.
• Extended Trust and Security Boundary – Extends the trust boundary from a single service to the virtual network boundary.
• Extend Your On-Premises Network to the Cloud – Leverage all on-premises investments around monitoring and identity for your services hosted in Azure.
• User persistent Private IP Addresses – Virtual machines within a Virtual Network will have a stable private IP address. Virtual Machines can be configured with a Static Internal IP. However, if you decide to use this feature it is recommended that you separate Virtual Machines that have static DIPs from PaaS instances by creating separate subnets.
• Internal Load Balancing – Enables scenarios like Highly Available (HA) line of business (LOB) apps and SQL Always On.

Using PowerShell to Create a Virtual Network

To create a Microsoft Azure Virtual Network, we must start by creating a Network Configuration File. Referring to the Virtual Network Configuration Schema I created the following XML configuration File.

<?xml version="1.0" encoding="utf-8"?>
<NetworkConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
  <VirtualNetworkConfiguration>
    <Dns />
    <VirtualNetworkSites>
      <VirtualNetworkSite name="AzureVNet" Location="East US 2">
        <AddressSpace>
          <AddressPrefix>10.0.0.0/24</AddressPrefix>
        </AddressSpace>
        <Subnets>
          <Subnet name="FrontEnd">
            <AddressPrefix>10.0.0.0/27</AddressPrefix>
          </Subnet>
          <Subnet name="MiddleTier">
            <AddressPrefix>10.0.0.32/27</AddressPrefix>
          </Subnet>
          <Subnet name="BackEnd">
            <AddressPrefix>10.0.0.64/27</AddressPrefix>
          </Subnet>
        </Subnets>
      </VirtualNetworkSite>
    </VirtualNetworkSites>
  </VirtualNetworkConfiguration>
</NetworkConfiguration>

Subnets are defined within the Virtual Network’s Address Space. Make sure to give yourself enough room to grow. Address Prefixes are used to define available IPs for each subnet. To create a new Subnet on a deployed Virtual Network, export the current Virtual Network Configuration from your Azure Subscription and add a new node to the Subnets XML node. Then import the configuration back to your Azure Subscription through PowerShell or the Azure Management Portal.

Azure Virtual Networks use the CIDR notation to define Usable Address Ranges.

CIDR notation is a compact representation of an IP address and its associated routing prefix. The notation is constructed from the IP address and the prefix size, the latter being equivalent to the number of leading 1 bits in the routing prefix mask. The IP address is expressed according to the standards of IPv4 or IPv6. It is followed by a separator character, the slash (‘/’) character, and the prefix size expressed as a decimal number.

The address may denote a single, distinct interface address or the beginning address of an entire network. The maximum size of the network is given by the number of addresses that are possible with the remaining, least-significant bits below the prefix. This is often called the host identifier.

For example, ‘192.168.100.0/24’ represents the given IPv4 address and its associated routing prefix 192.168.100.0, or equivalently, its subnet mask 255.255.255.0, which has 24 leading 1-bits.

For those who are not comfortable with the CIDR notation, The Azure team has provided us with detailed dropdown menus to guide us through this configuration.

I saved the above XML configuration as C:\demo\AzureVNet.netcfg. Then Using PowerShell, I setup the proper PowerShell console context and applied the Virtual Network configurations to my subscription.

# Switch to Azure Service Management

Switch-AzureMode -Name AzureServiceManagement

# Refresh Credentials

Add-AzureAccount

# Select Subscription

$subscriptions = Get-AzureSubscription

# Select the first Subscription
# (I did not specify my target Subscription for this demo)

$firstSubscription = $subscriptions `
                        | Select-Object -First 1 `
                                        -Verbose

# Select the Azure Subscrition and set it as Default

Select-AzureSubscription -SubscriptionId $firstSubscription.SubscriptionId `
                         -Default `
                         -Verbose

# Create Virtual Network 

Set-AzureVNetConfig -ConfigurationPath 'C:\demo\AzureVNet.netcfg' `
                    -Verbose

Once the command completes, I navigated to the Azure Management Portal and was able to verify that everything had been created.

Take Notice

Using the Set-AzureVNetConfig from PowerShell will replace all the Virtual Networks associated with your subscription and apply the new configurations present in the Network Configuration File.

Best Practices

• Use Subnets to create multi-tier typologies
• Control flow over Network Segments using Network Security Groups
• Use Access Control Lists (ACL) to filter conditions with allow / deny
• Configure internal Load Balancing for Highly Available tiers
• RDP to internal endpoints for added security
• Design Virtual Networks with the following in mind
  • Maximum of 2048 machines (Virtual Machines and Web/Worker role instances).
  • 500 000 concurrent TCP connections for a virtual machine or role instance.
  • 50 Access Control Lists (ACLs) per endpoint.
  • 10 local network sites per Virtual Network.
  • Each Virtual Network supports a single virtual network gateway.

More Resources

Be sure to read through the Virtual Network FAQ, you’ll find answers to most of your queries. Then go though these additional resources for more in depth information.

• Azure Subscription and Service Limits, Quotas, and Constraints
• Virtual Network Overview
• Azure Networking Guidance
• Designing Networking and Hybrid Connectivity Infrastructure
• About Secure Cross-Premises Connectivity
• Virtual Network Configuration Tasks
• Azure Virtual Network Configuration Schema
• How does a Network Security Group Work
• About Network Access Control Lists (ACLs)
• Configure a Point-to-Site VPN
• Configure a Static Internal IP Address for a Virtual Machine
• Configure a Cloud-Only Virtual Network in the Management Portal
• General Availability of Network Security Groups
• Great Blog Post about Network Security Groups