Design Microsoft Azure Infrastructure and Networking

Objective 1.2: Design Azure virtual networks, networking services, DNS, DHCP, and IP addressing configuration

Today, just about any computer you see is connected to some network. Computers on Azure are no exception. When you provision a new VM on Azure, you never gain physical access to the hosting machine. Instead, you need to operate the machine through remote connections such as remote desktop or Secure Shell (SSH). This is made possible by the networking infrastructure provided by Azure.

This objective introduces Azure Virtual Networks, with which you can create virtualized private networks on Azure. VMs deployed on a virtual network can communicate with one another just as if they were on an on-premises local area network (LAN).

Furthermore, you can connect your virtual networks with your on-premises networks, or with other virtual networks, through cross-network connections. You’ll learn about hybrid networks in objective 1.4.

Creating a cloud-only virtual network

It’s fairly easy to create a new virtual network on Azure. This section walks you through the steps to set up a new virtual network with two subnets on Azure. Then, you will review some of the differences between a virtual network and an on-premises network that you should be aware of when you design your network infrastructures in the cloud.

Creating a virtual network by using the Azure management portal

There are several different ways you can create a new virtual network on Azure, including using the Azure management portal, Azure PowerShell, and xplat-cli. This section walks you through how to use the management portal to create a new virtual network. Scripting options are discussed later in this chapter.

1. Sign in to the management portal (https://manage.windowsazure.com).

2. Select New, Network Services, Virtual Network, and then Custom Create, as shown in Figure 1-2.

   

   FIGURE 1-2 Creating a new virtual network

   The Create A Virtual Network Wizard opens.

3. On the Virtual Network Details page, in the Name box, type a name for the virtual network. In the Location box, select a location where you want the network to reside. If you have multiple Azure subscriptions, you also need to pick which Azure subscription to use. Then, click the right-arrow button to continue, as illustrated in Figure 1-3.

   

   FIGURE 1-3 Specifying the virtual network name and location

   NOTE: About Affinity Groups for virtual networks

   Previously, when you created a virtual network, you needed to associate the network with an Affinity Group. This is no longer a requirement. Now, virtual networks are associated directly with a region (location). Such virtual networks are called regional virtual network in some texts. The previous requirement of having Affinity Groups was because Azure networks were designed in layers. Communication among hardware within the same “branch” was much faster than communication across branches. A new flat network design makes it possible for VMs across the entire region to communicate effectively, eliminating the need to put a virtual network in an Affinity Group.

4. On the DNS Servers And VPN Connectivity page, click Next to continue. (You’ll come back to these options later in this chapter.)

   The Virtual Network Address Spaces page opens, as shown in Figure 1-4.

   

   FIGURE 1-4 The Virtual Network Address Spaces page

   When you manage a larger virtual network, you might want to create multiple subnets to improve performance. To describe this briefly, a network is like a web of roads. When you have more computers sending and receiving packets on the same network, packets can collide and must be resent again. Using subnets, you can control and limit traffic in different areas. It’s similar to using local roads for a short commute, and using shared highways to travel longer distances.

   In many cases, subnets are created not only for performance, but also for manageability. You can create subnets in alignment with business groups. For example, you can create one subnet for the sales department, and another subnet for engineering. You can also create subnets based on server roles. For example, you can have a subnet for web servers and another subnet for file servers.

   NOTE: About CIDR notation

   Classless Inter-Domain Routing (CIDR) notation is a shorthand representation of a subnet mask. It uses the number of bits to represent a subnet mask. For example, a subnet mask of 255.0.0.0 uses 8 bits, hence it’s written as /8. And a subnet mask of 255.255.0.0 uses 16 bits, which is written as /16 in CIDR notation. With CIDR, 10.0.0.0/8 in Figure 1-4 represents a network ID of 10.0.0.0 and a subnet mask of 255.0.0.0, which corresponds to the address range 10.0.0.0 to 10.255.255.255.

5. Click the Add Subnet button to create a new subnet. The updated address space is illustrated in Figure 1-5. In the lower-right corner, click the check button to complete the set up.

   

   FIGURE 1-5 A virtual network with two subnets

Now, your network has two subnets, each has 2,097,152 (2²¹) addresses.

IP Addresses

Each VM has at least two associated IP addresses: a public-facing virtual IP (VIP) address, and an internal dynamic IP (DIP) address.

A VIP comes from a pool of IP addresses managed by Microsoft. It is not assigned directly to the VM. Instead, it’s assigned to the Cloud Service that contains the VM. You can reserve VIPs so that you can assign static public IPs to your VMs. At this point, each Azure subscription is allowed to reserve up to 20 VIPs.

To reserve a VIP, use the following Azure PowerShell command:

New-AzureReservedIP –ReservedIPName "MyReservedIP" –Label "MyLabel" –Location "West US"

After you have the static VIP allocated, you can use it as part of the VM configuration when you create a new VM. VMs are discussed in the next objective.

The DIP address is a dynamic IP address associated with your VM. A DIP is assigned by DHCP with a near-infinite lease. So, it remains stable as long as you don’t stop or deallocate the machine. However, it’s not a static IP address. If your VM resides in a virtual network, you can assign a static IP address to it. For example, when you set up a domain controller or a Domain Name System (DNS) server on your virtual network, you’ll need to assign static IPs to these machines because both services require static IP addresses.

With Azure, you can create multiple virtual network interfaces (NICs) on your VM residing on a virtual network. In this case, your VM has multiple associated DIPs, one for each NIC.

In addition to VIP and DIP, there’s another type of IP address, which is called Instance-Level Public IP (PIP) Address. As stated previously, a VIP is not assigned to a VM, but to the Cloud Service containing the VM. A PIP, on the other hand, is directly assigned to a VM. PIP is appropriate for workloads that need a large number of ports to be opened, such as passive FTP.

Name resolution and DNS servers

VMs on the same network can address one another by DIP addresses. If you want to refer to VMs by hostnames or fully qualified domain name (FQDN) directly, you need name resolutions. Azure provides a built-in hostname resolution for VMs and role instances within the same cloud service. However, for VMs across multiple cloud services, you’ll need to set up your own DNS server.

host names and FQDNs

As is discussed in Objective 1.3, when you create a new VM, the host name is specified by you. And when you define a cloud service role (you can read more about Cloud Services in Chapter 4), you can define the VM host name by using the vmName property in the service configuration file. In this case, Azure will append an instance number to the name to distinguish different role instances. For example, if vmName is MyRole, the actual host names of role instances will be MyRole01, MyRole02, and so on.

When you create a VM (or a cloud service), a DNS name is assigned to the machine with the format [machine name].cloudapp.net, where [machine name] is the name you specify. You can use this FQDN to address your machine directly over Internet. When the VM is provisioned, a public-facing VIP is associated with the machine, and then the DNS name is associated with this VIP.

You can also use CNAME or A records to associate a custom domain name with your VM. When you use A records, however, you need to note that the VIP of your VM might change. When you deallocate a VM, the associated VIP is released. And when the VM is restarted later, a new VIP will be picked and assigned. If you want to ensure that your VM has a static public IP address, you’ll need to configure a static IP address for it as described earlier.

Last but not least, for simple name resolutions, you can also use hosts files (%System32%\Drivers\etc\hosts for Windows; /etc/hosts for Linux) and cross-enter IP-to-host mappings to all the VMs in the same virtual network.

DNS servers

You can set up DNS servers on your virtual network to provide a name resolution service to the machines on the same network. Objective 1.3 presents a couple of examples.

Understanding Access Control Lists and Network Security Groups

You can use both network Access Control Lists (ACLs) and Network Security Groups (NSGs) to control traffic to your VMs. In either case, the traffic is filtered before it reaches your VM so that your machine doesn’t need to spend extra cycles on packet filtering.

Before you continue learning about ACLs and NSGs, you need to first understand how VM endpoints work.

VM endpoints

When you provision a VM on Azure by using the management portal, by default the device is accessible through Remote Desktop and Windows PowerShell Remoting for Windows-based VMs, and through SSH for Linux-based VMs. This is because Azure automatically defines the corresponding endpoints.

Each endpoint maps a public port to a private port. The private port is used by the VM to listen for incoming traffic. For Example, your device might have an Internet Information Services (IIS) server running on it, listening to the private port 80. The public port is not used by the VM itself, but by another entity called Azure Load Balancer.

As mentioned earlier, a VM has a VIP address as well as a DIP address. However, the VIP address is actually not directly associated with the VM. Instead, the VIP address is associated with Load Balancer. It’s Load Balancer that listens to the traffic to the VIP address and the public port, and then forwards the traffic to the VM listening to the DIP address and the private port. Figure 1-6 shows how this traffic forwarding works. At the top, the traffic reaches the endpoint at VIP:[public port]. Then, Load Balancer forwards the traffic to DIP:[private port]. In this example, an endpoint is defined to map a public port 8080 to a private port 80. The IIS server on a VM named myvm is listening to local address 10.0.0.1:80. An end user accesses the website by the public address myvm.cloudapp.net:8080. Note that the “myvm” in the FQDN “myvm.cloudap.net” is the name of the Cloud Service in which the VM resides. It’s not necessarily the same as the VM name (you can have multiple VMs in the same Cloud Service).

Endpoints can be stand-alone or load-balanced. When a load-balanced endpoint is defined, Load Balancer distributes traffic evenly among the VMs within the same load-balanced set. Figure 1-7 shows how it works.

Endpoints are for public accesses. When you provision a VM on a virtual network, it can communicate with other VMs on the same network just as if they were on a physical local network. There are no endpoints needed for private communications.

Network ACLs

ACL provides the ability to selectively permit or deny traffic to a VM endpoint. An ACL comprises an ordered list of rules that either permit or deny traffic to the endpoint. Packets are filtered on the hosting server before they can reach your VM. When a new endpoint is created, by default all traffic from all IP addresses are allowed. Then, you can define ACLs to constrain accesses to certain ranges of IP addresses by defining blocked lists and safe lists, each of which is defined here:

• Blocked list You can block ranges of IP addresses by creating deny rules. Table 1-2 shows an example of ACL that blocks accesses from a specific subnet:

  TABLE 1-2 A sample blocked list

  Rule #	Remote subnet	Endpoint	Permit/deny
  100	10.32.0.0/11	80	Deny

• Safe list You can also create a safe list that allows only specific IP addresses to access an endpoint. First, you’ll define a rule that denies all traffic to the endpoint. Then, you add additional rules to allow accesses from specific IP addresses (ACL uses lowest takes precedence rule order). Table 1-3 shows a sample safe list:

  TABLE 1-3 A sample safe list

  Rule #	Remote subnet	Endpoint	Permit/deny
  100	0.0.0.0/0	80	Deny
  100	10.0.0.0/11	80	Permit

You can apply ACLs to load-balanced endpoints, as well. When you apply an ACL to a load-balanced endpoint, it’s applied to all VMs in the same load-balanced set. You can specify up to 50 ACL rules per VM endpoint.

NSGs

For VMs deployed on a virtual network, NSGs provide more detailed access controls. An NSG is a top-level object of your Azure subscription that you can apply to a VM or a subnet to control traffic to the VM or the subnet. You can also associate different NSGs to a subnet and the VMs contained in the virtual network to establish two layers of protections.

Similar to an ACL, an NSG is made up by a number of prioritized rules. Each NSG comes with a number of default rules that you can’t remove. However, as these rules have lower priorities, you can override them by additional rules. There are two types of rules: inbound rules and outbound rules. Each rule defines whether the traffic should be denied or allowed to flow from a source IP range and port to a destination IP range and port. You can also specify protocols in NSG rules. The supported protocols are TCP and UDP, or * for both.

In NSG rules, IP ranges are represented by named tags. There are three default tags:

• VIRTUAL_NETWORK This tag specifies all network address space on your virtual network. It also includes connected on-premises address spaces and vNet-to-vNet address spaces (you’ll learn about on-premises connections and vNet-to-vNet connections in Objective 1.4).
• AZURE_LOADBALANCER This tag denotes Azure Load Balancer. Load Balancer sends health probe signals to VMs in a load-balanced set. This tag is used to identify the IP address from which the health probes originate.
• INTERNET This tag specifies all IP address that are outside the virtual network.

With an NSG, inbound traffic is denied by the default rules, with the exception of allowing health probes from Load Balancer. Table 1-4 lists the default inbound rules of an NSG. The first rule allows all internal traffic within the same virtual network; the second rule allows health probes from Load Balancer; and the third rule denies all other accesses.

TABLE 1-4 Default inbound rules of an NSG

Priority	Source IP	Source Port	Destination IP	Destination Port	Protocol	Access
65000	VIRTUAL_NETWORK	*	VIRTUAL_NETWORK	*	*	Allow
65001	AZURE_LOADBALANCER	*	*	*	*	Allow
65000	*	*	*	*	*	Deny

Table 1-5 lists the default outbound rules of a NSG. The first rule allow outbound traffic to the virtual network. The second rule allows outbound traffic to Internet. And the third rule denies all other outbound traffic.

TABLE 1-5 Default outbound rules of a NSG

Priority	Source IP	Source Port	Destination IP	Destination Port	Protocol	Access
65000	VIRTUAL_NETWORK	*	VIRTUAL_NETWORK	*	*	Allow
65001	*	*	INTERNET	*	*	Allow
65000	*	*	*	*	*	Deny

NSGs are different from ACLs in a couple of aspects:

• ACLs are applied to traffic to a specific VM endpoint, whereas NSGs are applied to all traffic that is inbound and outbound on the VM.
• ACLs are associated to a VM endpoint, whereas NSGs are associated to a VM, or a subnet within a virtual network.

Objective summary

• You can create private virtual networks in Azure. VMs deployed on the same virtual network can communicate with one another as if they were on the same local network.
• Each machine has a public VIP address and one or multiple PIP addresses, one per NIC.
• You can associate both static virtual IP addresses and static private IP addresses to VMs on a virtual network.
• ACLs are associated to VM endpoints to control traffic to VMs.
• NSGs are associated to VMs or subnets to provide greater traffic control to VMs or virtual networks.
• Both ACLs and NSGs define prioritized rules to control network traffic, but they cannot be used in conjuction.

Objective review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. A VM can have multiple associated IP addresses. Which of the following are possible IP addresses associated with a VM?

   1. Public virtual IP
   2. Dynamic private IP
   3. Static public IP
   4. Static private IP

2. NSGs define a number of default tags. Which of the following tags are default tags?

   1. VIRTUAL_NETWORK
   2. AZURE_LOADBALANCER
   3. INTERNET
   4. VIRTUAL_MACHINE

3. Which of the following are NSG rule fields?

   1. Source IP and source port
   2. Target IP and target port
   3. Protocol
   4. Priority

4. Which of the following are ACL rule fields?

   1. Rule number
   2. Remote subnet
   3. Endpoint
   4. Permit/deny