Hybrid Network Infrastructure in Microsoft Azure (Part 8)

If you would like to read the other parts in this article series please go to:

Introduction

In part 1 of this series, I began the discussion about hybrid network infrastructure with some thoughts regarding what hybrid clouds are about, and then talked about some of the networking functionality that you get when you adopt Azure Infrastructure Services. There was also an introduction to the Datacenter Extension Reference Architecture Diagram that Tom put together with Jim Dial and several other people at Microsoft. In part 2, Tom joined in as co-author and we went over site to site VPNs and point to site VPNs. In part 3 we took a look at the Azure dedicated WAN link service, which goes by the name of ExpressRoute, and also discussed the Azure Virtual Gateway, which is located on the edge of your Azure Virtual Network and enables you to connect your on-premises network to an Azure Virtual Network.

Then in part 4, we spent the bulk of our time discussing what Azure Virtual Networks are and how they compare to the virtual networks we use in traditional on-premises Hyper-V installations. Part 5 went into a little more detail on Azure Virtual Networks and some special considerations you need to take into account. In Part 6, we discussed Azure Virtual Networks and external load balancers. We will now continue working our way through our list of network capabilities that are available in Azure at the time this article was written (always keeping in mind that Azure is constantly changing and growing and adding new functionalities):

Site to site VPNs

√ Point to Site VPNs

√ Dedicated WAN links

√ Virtual network gateways

√ Azure Virtual Networks

Inter-virtual Network connectivity

External load balancers

> Internal load balancers

> Network Security Groups

  • Virtual machine ACLs
  • Third party proxy firewalls
  • Dual-homed
  • Dedicated public IP addresses
  • Static IP addresses on virtual machines
  • Public addresses on virtual machines
  • DNS

In Part 7, we began our discussion on the subject of internal load balancing and on how to use PowerShell to configure ILB for virtual machines that are contained within an Azure Virtual Network.

Using the Cloud Service Configuration File to configure ILB for Cloud Services

If the virtual machines are within Cloud Services, then you’ll need to configure a .cscfg file. This is a Cloud Service Configuration File that is created in Visual Studio or it can be created manually with command line tools. Azure uses these files to manage your cloud services. This file contains the number of role instances to deploy for each role in the service, the values of configuration settings and the thumbprints for certificates that are associated with each of the roles, as well as configuration information for the network when the service is part of a virtual network.

There are a couple of very important caveats for you to keep in mind about this:

  • You have to set the ILB configuration in the .cscfg file when you create the first deployment of the Cloud Service.
  • You must already have a virtual network created for the Cloud Service before you set the ILB configuration in the .cscfg file.

Before you can edit it, you will need to download the cloud service configuration file with the current configuration for the cloud service. To do that, you need to go to the Configure page for the cloud service and click Download, then Save or Save As.

The steps for setting the configuration in the .cscfg file are as follows:

  1. Use Visual Studio to open the cloud service configuration file for your cloud deployment.
  2. Add a section to the .cscfg file under the last </Role> item for the network configuration that specifies the name of the load balancer, frontend IP configuration type, subnet name and static virtual network IP address as shown in the sample below.
  3. Change the service definition file (.csdef) to add the endpoints to the ILB, with the appropriate values as shown in the second sample below.

Sample 1

<NetworkConfiguration>

<LoadBalancers>

<LoadBalancer name=”name of the load balancer”>

<FrontendIPConfiguration type=”private” subnet=”subnet-name” staticVirtualNetworkIPAddress=”static-IP-address”/>

</LoadBalancer>

</LoadBalancers>

</NetworkConfiguration>

Sample 2

<WorkerRole name=”worker-role-name” vmsize=”worker-role-size” enableNativeCodeExecution=”[true|false]”>

<Endpoints>

<InputEndpoint name=”input-endpoint-name” protocol=”[http|https|tcp|udp]” localPort=”local-port-number” port=”port-number” certificate=”certificate-name” loadBalancerProbe=”load-balancer-probe-name” loadBalancer=”load-balancer-name” />

</Endpoints>

</WorkerRole>

For more detailed step-by-step instructions on how to modify the .cscfg file to set up ILB on your Cloud Services, please go to the Microsoft Azure web site and see the article titled Get Started Configuring an Internal Load Balancer.

Network Security Groups

If you read our article on Azure Virtual Networks earlier in this series, you might remember that when you create an Azure Virtual Network, you have to assign that Azure Virtual Network a network ID. After you have assigned the network ID, you can then subnet the network in any way you desire. This is very useful because you can create different subnets and then you can place virtual machines that perform different roles into each of the subnets.

For example, suppose you have created an Azure Virtual Network and assigned it the network ID 10.0.0.0/8. You can now create multiple subnets within that address space, such as 10.0.1.0/24 and 10.0.2.0/24, and so on. Then you can assign a role to each of these subnets; for example, you could designate a subnet for front-end web services, a subnet for application tiers, a subnet for database tiers and a subnet for infrastructure services (Active Directory, DNS, DHCP, Certificate services, etc.).

This is a pretty handy capability but then security rears its ugly head. You see, by default the connections between these subnets are fully routable and there are not any default access controls between any of them. Obviously, this isn’t going to work for most of us. However, the good news is that you can fix this problem and there are a couple of ways for you to do it. Let’s look at both methods:

  • Azure now supports multi-homed network devices that you can place between subnets; these virtual appliances are available in the Azure Marketplace. These can be used to create the isolation that you need, but the bad news is that you will have to pay whatever price is set by the vendor who makes the virtual appliance available to you. You will also have to deal with the learning curve of configuring whichever device you choose and the vagaries of third party support.
  • Alternatively, you can use an Azure Network Security Group (NSG), something that is part of Azure and which is in effect a packet filtering router that you can use to control traffic moving to and from subnets or virtual machines. NSGs are configured with access rules to allow or deny specific traffic and you can modify these rules whenever you want.

How Network Security Groups Work

For example, suppose you created a subnet that is not Internet facing, but contains front-end web servers for internal applications. You only want to allow:

  • HTTP/HTTPS traffic from the on-premises network
  • RDP/Remote PowerShell traffic from the on-premises network

You can use a Network Security Group and configure rules that will allow only this type of traffic. This example only includes incoming traffic, but you can also configure a Network Security Group to control outbound traffic. In this example, you might configure the Network Security Group to allow outbound traffic from the front-end web server subnets to the application tier subnet that supports the multi-tier application.

Something that you need to know about Network Security Groups is that you can configure them to allow traffic inbound and outbound to and from an entire subnet, or just a single VM. Network Security Groups, like any other packet filtering solution, are based on rules. You can create rules based on the entire subnet or just a virtual machine. In fact, you can create rules for both. Each NSG can contain as many as two hundred rules and you’re allowed to have up to a hundred NSGs with your Azure subscription.

When you create a rule that applies to both an entire subnet and a virtual machine within the subnet, you are getting two layers of network protection. For incoming traffic, the subnet rule will be applied first, and if the traffic makes it through the subnet rules, then the per-VM rules are applied. For outbound traffic, the per-VM rule is applied first, and it the traffic makes it past that rule, then the traffic is exposed to the subnet-based rules. Rules are processed in the order of their priority numbers.

An NSG contains some default rules that you can’t delete, but they are assigned the lowest priority (which is 65500) so you can override them with your own custom rules that will be processed first when set to a higher (lower numbered) priority. When a match is found, no more rules are processed.

If you wanted to implement higher security from a network perspective, you can also configure rules in a host-based firewall. In this case, you’ll have to do that within the virtual machine itself, because the Azure fabric management system will not configure or monitor the rules you configure within each virtual machine.

As great as NSGs can be, they have their limitations and caveats like most technologies. The important ones are that you cannot use them with virtual networks that are associated with affinity groups. Also be aware that a VM or subnet can be associated with only one NSG. Finally, keep in mind that you can’t use endpoint-based ACLs and NSGs with the same VM instance. Any endpoint ACLs that are already attached to a VM will have to be removed before you can use NSGs with that VM.

For more information on Network Security Groups and how they work and how you can configure them, check out the great article What is a Network Security Group (NSG)?

Summary

In this article, Part 8 of our series on the Hybrid Network Infrastructure in Microsoft Azure, we expanded on our previous discussion on internal load balancing and you learned how we can take advantage of load balancing on virtual machines that aren’t Internet facing by using Internal Load Balancing with Cloud Services. Then we talked about Network Security Groups, which are essentially stateful packet inspection devices that allow you to segment traffic between subnets within an Azure Virtual Network. Next time, in Part 9, we’ll be delving into the topic of virtual machine access control lists (ACLs) so be sure to join us then.

If you would like to read the other parts in this article series please go to:

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