Chapter 1 Configure and Manage Virtual Networks

This Chapter covers following Topic Lessons

• Virtual Networks
• Public IP Addresses in Azure
• Private IP Addresses
• Network Security Groups
• Azure DNS
• Virtual Networks Peering
• Gateway Transit and Remote Gateways
• Routing within VNET using System Route
• Routing within VNET using User Defined Route (UDR)

This Chapter covers following Lab Exercises

• Create Resource Group RGCloud
• Create Resource Group RGOnPrem
• Create Virtual Network VNETCloud
• Create additional Subnet (DB-Subnet 10.1.2.0/24)
• Create additional Subnet (DMZ-Subnet 10.1.3.0/24)
• Create Virtual Network representing On-Prem Network
• Create Virtual Network VNETCloud2
• Create Virtual Network VNETCloud3
• Create Dynamic Public IP
• Change Dynamic Public IP to Static IP
• Create NSG and add inbound http, RDP and SSH allow rule
• Associate Network Security Group (NSG) with Subnet
• DNS Zone, DNS Records and Delegation to Azure DNS
• Peering between VNETs - VNETCloud & VNETCloud2
• Peering between VNETs - VNETCloud & VNETCloud3
• Routing Traffic between 2 Subnets to pass through another Subnet using UDR

Chapter Topology

In this chapter we will create 4 Virtual Networks - VNETCloud, VNETOnPrem, VNETCloud2 & VNETCloud3. VNETCloud will be our main Virtual Network for all labs in all the Chapters. In some labs we will also use VNETOnPrem.

In This Chapter we will create below Topology using Virtual Network VNETCloud. We will create 3 Subnets. We will add NSG, Azure DNS & Resource Group to the topology. Default Azure AD is created when you sign for Azure subscription.

Figure below shows Topology for Virtual Network VNETOnPrem. We will rename default subnet as OnPrem-Subnet. There was lack of space in above figure so I am showing it separately.

Following Topology will be used in VNET Peering Labs.

In Exercise 16 we will do peering between VNETCloud and VNETCloud2.
In Exercise 17 we will do peering between VNETCloud and VNETCloud3.

The peering connectivity will be over Azure Backbone Network.

Virtual Networks (VNET)

An Azure virtual network (VNET) is Virtual Data Centre in the cloud. Virtual Network is further segmented into subnets. Access to the subnets can be controlled using Network Security groups. Virtual Machines are created in Subnets.

End customers create Virtual Networks. End customers define the IP address blocks, security policies, and route tables within this network.

Figure below shows virtual network KNET1 with 2 subnets - Web-Subnet and DB-Subnet. There are 3 virtual machines in these subnets. End customer has defined Network address of 192.168.0.0/16 for virtual network KNET1, 192.168.1.0/24 for Web-Subnet and 192.168.2.0/24 for DB-Subnet.

Virtual Network is created by the customer. Resources within Virtual Network are created and managed by end customers. Whereas Resources outside of VNET (Azure SQL, Azure AD etc) are Azure Managed Resources with Public IPs. Azure Managed Resources are not only accessed by VMs in VNET but are also accessed through internet.

Virtual Network Subnets

VNET is divided into subnets. Subnets are assigned IP addresses by Subnetting VNET network address space. Access to the subnet can be controlled through Network Security groups (NSG). User defined route (UDR) tables can also be assigned to subnets. Virtual Machines are created in Subnets.

Default Communication within and between Virtual Network Subnets

1. All VM to VM traffic within subnet or between subnets is allowed.
2. VM to internet traffic is allowed.
3. Azure Load balancer to VM is allowed.
4. Inbound internet to VM is blocked.

Note: Default rules can be overridden by new rules you create using NSG.

Private Address Range for Virtual Networks

You can use following class A, Class B and Class C address range for virtual networks.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Once the IP address range is decided, we can then divide this range into subnets.

Virtual Machines NICs in the subnet are assigned private IP addresses via Azure DHCP from the subnet network address range.

There are 5 Reserved addresses within the subnet: Within a virtual network subnet, the protocol reserves the first and last IP addresses of a subnet: a host ID of all 0s is used for the network address, and a host ID of all 1s is used for broadcast. In addition, Azure reserves the first three IP addresses in each subnet (binary 01, 10, and 11 in the host ID portion of th IP address) for internal purposes

Exercise 1: Create Resource Group RGCloud

1. In Azure Portal click Resource Groups in left pane> All Resource Groups pane opens> Click +Add> Create Resource Group blade opens>Enter RGCloud for name and Select East US 2 as location and click Review + Create (Not Shown)>Click Create (Not Shown).

   Figure below shows dashboard of Resource Group RGCloud.

Note : Resource Groups will be discussed extensively in Chapter 15.

Exercise 2: Create Resource Group RGOnPrem

In Azure Portal click Resource Groups in left pane> All Resource Groups pane opens> Click +Add> Create Resource Group blade opens>Enter RGOnPrem for name and Select West US 2 as location and click Review + Create (Not Shown)>Click Create (Not Shown).

Figure below shows dashboard of Resource Group RGOnPrem.

Note : Resource Groups will be discussed extensively in Chapter 15.

Exercise 3: Create Virtual Network VNETCloud

In this exercise we will create Virtual Network VNETCloud in Resource Group RGCloud using 10.1.0.0/16 address space in East US 2 Location. We will name Default Subnet as Web-Subnet with address 10.1.1.0/24.

1. In Azure Portal Click +Create a Resource in left pane> Networking> Virtual Networks> Create Virtual Network blade opens> Enter VNETCloud for name, Select RGCloud in Resource Group Box and Select East US 2 in location Box, Enter Web-Subnet in Subnet Name and click create.

   Note : Rest select all values as default- DDoS Protection Basic, Service endpoints disabled and Firewall disabled. You need to scroll down to see these options.

2. Figure below shows dashboard of Virtual Network VNETCloud.

Exercise 4: Create additional Subnet (DB-Subnet 10.1.2.0/24)

1. Go to Virtual Network VNETCloud Dashboard> Click Subnets in left pane> Subnet blade opens. Web-Subnet was created during VNET creation time

2. Click + Subnet>Add Subnet blade opens>Enter DB-Subnet in name and Address Range as 10.1.2.0/24. Select none for NSG and Route table, 0 for Service Endpoints and none for Subnet Delegation>Click Ok. NSG and Route Table will be discussed later in the chapter. Service Endpoints will be discussed in Chapter 5.

Exercise 5: Create additional Subnet (DMZ-Subnet 10.1.3.0/24)

1. In Virtual Network VNETCloud Dashboard Click Subnets in left pane> Subnet blade opens as shown below.

2. Click + Subnet>Add Subnet blade opens>Enter DMZ-Subnet in name and Address Range as 10.1.3.0/24. Select none for NSG, Route table & Subnet Delegation & 0 for Service Endpoints>Click Ok (Not Shown).

Exercise 6: Create Virtual Network representing On-Prem Network

In this exercise we will create Virtual Network VNETOnPrem in Resource Group RGOnPrem using 192.168.0.0/16 address space in West US 2 Location. We will name Default Subnet as OnPrem-Subnet with address 192.168.1.0/24. This Virtual Network will act as on-premises datacentre for our topology .

1. In Azure Portal Click +Create a Resource in left pane> Networking> Virtual Networks> Create Virtual Network blade opens> Enter VNETOnPrem for name, Select RGOnPrem in Resource Group Box and Select West US 2 in location Box, Enter OnPrem-Subnet in Subnet Name and click create.

   Note : Rest select all values as default.

2. Figure below shows the Dashboard of Virtual Network VNETOnPrem.

Exercise 7: Create Virtual Network VNETCloud2

In this exercise we will create Virtual Network VNETCloud2 in Resource Group RGCloud using 10.7.0.0/16 address space. The Default Subnet Address will be changed to 10.7.1.0/24. This Virtual Network will be used in Peering Lab Exercise 14 .

1. In Azure Portal Click +Create a Resource in left pane> Networking> Virtual Networks> Create Virtual Network blade opens> Enter VNETCloud2 for name, Select RGCloud in Resource Group Box and Select East US 2 in location Box and click create. Note : Rest select all default values.

Exercise 8: Create Virtual Network VNETCloud3

In this exercise we will create Virtual Network VNETCloud3 in Resource Group RGCloud using 10.8.0.0/16 address space. The Default Subnet Address will be changed to 10.8.1.0/24. This Virtual Network will be used in Peering Lab Exercise 15.

1. In Azure Portal Click +Create a Resource in left pane> Networking> Virtual Networks> Create Virtual Network blade opens> Enter VNETCloud2 for name, Select RGCloud in Resource Group Box and Select East US 2 in location Box and click create

   Note : Rest select all default values.

Public IP Addresses in Azure

Public IP addresses allow Azure resources to communicate with Internet and to Azure public-facing services such as Azure Redis Cache, Azure Event Hubs, SQL databases, and Azure storage etc.

Public IP Address Allocation Methods

Dynamic Public IP : IP address is not allocated at the time of its creation. Instead, the Dynamic public IP address is allocated when you start or create the associated resource (like a VM or load balancer).
The IP address is released when you stop or delete the resource. This causes the IP address to change when you stop and start a resource.

Static Public IP : IP address for the associated resource remains the same when start or stop the resource.
In this case an IP address is assigned immediately. It is released only when you delete the resource or change its allocation method to dynamic.

You can associate a public IP address resource with following resources:

VMs | Internet-facing load balancers | VPN gateways | Application gateways

Static Public IP Use Case

Static Public IP addresses are often used for Web Servers that require SSL connections in which SSL certificate is linked to an IP address.

Types of Public IP Addresses (Basic & Standard)

Basic IP Address Features

1. Assigned with the static or dynamic allocation method.
2. Network security groups are recommended but optional for restricting inbound or outbound traffic.
3. Assigned to Azure resource such as network interfaces, VPN Gateways, Application Gateways, and Internet-facing load balancers.
4. Can be assigned to a specific zone. Not zone redundant.

Standard IP Address Features

1. Assigned with the static allocation method only.
2. Are secure by default and closed to inbound traffic. You must explicit whitelist allowed inbound traffic with a network security group.
3. Assigned to network interfaces or public standard load balancers.
4. Zone redundant by default.

Default DNS hostname resolution for Resources with Public IP

Resources with Public IP have Fully Qualified Domain Name in the format resourcename.location.cloudapp.azure.com.

For Example, if you create a public IP resource with test as a resource name in the West US Azure location, the fully qualified domain name (FQDN) test.westus.cloudapp.azure.com resolves to the public IP address of the resource.

DNS hostname resolution for Resources using Custom Domain options

If you want use your own domain name (Test.com) with Azure Resource with Public IP, you have 2 options depending upon IP Address allocation method.

Dynamic IP: Use cname record to point to Azure resource FQDN.

Static IP: You can either use A record name to point to Azure resource Public IP or use cname record to point Azure Resource FQDN.

Private IP Addresses

Private IP addresses allow Azure resources to communicate with other resources in a virtual network or an on-premises network through a VPN gateway or ExpressRoute circuit, without using an Internet-reachable IP address.

Private IP address is associated with following types of Azure resources:

1. VMs
2. Internal load balancers (ILBs)
3. Application gateways

Private IP Addresses are assigned from the subnet address range in which the resource is created. Private IP Address can be Static or Dynamic. Private IP Address is created during resource creation time.

Private Dynamic IP Address: Azure assigns the next available unassigned or unreserved IP address in the subnet's address range. Once assigned, dynamic IP addresses are only released if a network interface is deleted, assigned to a different subnet within the same virtual network, or the allocation method is changed to static, and a different IP address is specified. Dynamic is the default allocation method.

Private Static IP Address : You select and assign any unassigned or unreserved IP address in the subnet's address range. Static addresses are only released if a network interface is deleted. Static Private IP Addresses are often used with DNS or Domain Controller VMs.

Internal DNS hostname resolution for virtual machines with Private IP using Azure Managed DNS Servers

When you create a virtual machine, a mapping for the hostname to its private IP address is added to the Azure-managed DNS servers by default.

These DNS servers provide name resolution for virtual machines that reside within the same virtual network. To resolve host names of virtual machines in different virtual networks, you must use a custom DNS server.

Exercise 9: Create Dynamic Public IP

In this Exercise we will create Dynamic Public IP in Resource Group RGCloud.

1. In Azure Portal Click All Services in left pane>Scroll down and Under Networking Click Public IP Addresses>All Public IP Addresses Dashboard opens>Click +Add>Create Public IP Address blade opens> Enter DPIPCloud in name box, Select Basic SKU, Select IP address as Dynamic, Give a unique DNS name dpipcloud, select RG RGCloud and Location EastUS2 > Click create.

   Note: You can create Public IP separately or create during Resource creation time.

2. Figure below shows Dynamic Public IP “DPIPCloud” Dashboard . Note that no address is assigned. Dynamic public IP address is allocated when you start or create the associated resource (like a VM or load balancer).

Exercise 10: Change Dynamic Public IP to Static IP

In Public IP “ DPIPPortal ” Dashboard Click Configuration in left pane>Select Static and click save.

Network Security Groups

Network Security Group (NSG) is a Virtual Firewall. NSGs control inbound and outbound access to network interfaces (NICs) and subnets. Each NSG contains one or more rules specifying whether or not traffic is approved or denied based on source IP address, source port, destination IP address, destination port and protocol.

NSGs can be associated with subnets and network interfaces of Virtual Machines within that subnet. When a NSG is associated with a subnet, the ACL rules apply to all the VM instances in that subnet. In addition, traffic to an individual VM can be further restricted by associating a NSG directly to that VM NIC.

Figure below Shows VNET with 2 Subnets. Virtual Machine in Web-Subnet is protected by 2 Levels of NSG - NSG at Subnet level and NSG at Virtual Machine Network Interface level. Whereas Virtual Machine in DB-Subnet is protected by one level of NSG applied at Virtual Machine Network Interface Level.

Default NSG rules

NSGs contain a set of default rules. The default rules cannot be deleted, but because they are assigned the lowest priority, they can be overridden by creating new rules with higher priority. Higher the Number Lower the priority .

* Represent all addresses, Ports & Protocols.

We can infer following from the above default rules:

1. All VM to VM traffic within subnet or between subnets is allowed.
2. VM to internet traffic is allowed.
3. Azure Load balancer to VM is allowed
4. Inbound internet to VM is blocked.
5. Default rules can be overridden by creating new rules with higher priority.

NSG Design Rules

1. By Default there is no NSG assigned to a subnet. But you have option of adding NSG during subnet creation or after subnet is created. To assign a NSG to a subnet you need to first create NSG.
2. Associating NSG to subnet is recommended and not compulsory.
3. You can apply only one NSG to a subnet or a VM NIC. But same NSG can be applied to multiple resources.
4. Deploy each tier of your workload into different subnet and then apply NSG to the subnets.
5. When implementing a subnet for a VPN gateway, or ExpressRoute circuit, do not apply an NSG to that subnet. If you do so, your cross-VNet or cross- premises connectivity will not work.
6. Each NSG rules has a priority. Higher the priority number, lower the priority. You can override default NSG by creating new NSG rules with higher priority than default rules.

Service Tags for identification of category of IP Addresses in NSG Rules

Service tags are system-provided identifiers to address a category of IP addresses. Service tags are used in the source address prefix and destination address prefix properties of any NSG rule.

1. VirtualNetwork: This default tag denotes virtual network address space assigned to Azure Virtual Network.
2. AzureLoadBalancer: This default tag denotes Azure’s Infrastructure load balancer. This will translate to an Azure datacenter IP where Azure’s health probes originate.
3. Internet: This default tag denotes the IP address space that is outside the virtual network and reachable by public Internet. This range includes Azure owned public IP space as well.
4. AzureTrafficManager: This tag denotes the IP address space for the Azure Traffic Manager probe IPs.
5. Storage: This tag denotes the IP address space for the Azure Storage service. If you specify Storage for the value, traffic is allowed or denied to storage. If you only want to allow access to storage in a specific region, you can specify the region.
6. Sql: This tag denotes the address prefixes of the Azure SQL Database and Azure SQL Data Warehouse services. If you specify Sql for the value, traffic is allowed or denied to Sql.
7. AzureCosmosDB (Resource Manager only): This tag denotes the address prefixes of the Azure Cosmos Database service. If you specify AzureCosmosDB for the value, traffic is allowed or denied to AzureCosmosDB.
8. AzureKeyVault (Resource Manager only): This tag denotes the address prefixes of the Azure KeyVault service. If you specify AzureKeyVault for the value, traffic is allowed or denied to AzureKeyVault.

Effective NSG Permissions or Rules

NSG can be applied at Subnet or VM NIC level or both Subnet and VM NIC

Let’s take an example to check what’s the effective traffic reaching Virtual Machine when NSG is applied at both Subnet and VM NIC level. We have 2 VMs (App-Prod & App-Test) created in App Subnet as shown in below figure.

NSGSubnet has 3 inbound allow rules - http, https & RDP.
NSGProd has 2 inbound allow rules - https & RDP.
NSGTest has 2 inbound allow rules - http & RDP.

Effective traffic entering the subnet is http, https & RDP. NSGSubnet blocks any other traffic apart from http, https & RDP.

Effective traffic entering VM App-prod is https & RDP. NSGProd blocks http traffic.

Effective traffic entering VM App-Test is http & RDP. NSGTest blocks https traffic.

Exercise 11: Create NSG and add inbound http, RDP and SSH allow rule

In this Exercise we will create Network Security Group NSGCloud in resource group RGCloud and in US East 2 Location. We will add inbound http, RDP & SSH allow rule in NSGCloud. This rule will allow http, RDP & SSH traffic to Windows VM & Linux VM in Web-Subnet. Windows and Linux VM will be created in compute chapter 2. In Next exercise we will associate this rule with Web-Subnet in Virtual Network VNETCloud.

1. In Azure Portal Click + Create a resource>Networking>Network Security Group>Create Network Security Group opens> Enter a name, Select resource group RGCloud, Select Location East US 2 and Click create.

2. Figure below shows Network Security Group NSGCloud Dashboard with default inbound and outbound security rules.

   Note on Inbound Rules

   Note 1 : In inbound security rules, all inbound traffic is set to deny (Rule number 3) except for VNET to VNET and Azure Load Balancer to Any.

   Note 2 : Best Practice is to create a new inbound rule and allow traffic which is needed. Do not make this rule allow for all the traffic.

   Note 3 : Override Default inbound rule by creating new rule with higher priority or lower number than the default inbound rule.

   Note 4 : In next step we will allow inbound HTTP, RDP and SSH traffic to windows server VM and Linux VM in web-subnet. Windows Server VM and Linux VM will be created in compute chapter.

   Note on Outbound Rules

   Note 1 : Internet outbound is allowed.
   Note 2: Outbound VNET to VNET is allowed.

3. Add inbound RDP rule : In NSG dashboard click inbound security rules in left pane>In Right pane click +Add>Add inbound security rule blade opens> In Destination Port Ranges Enter RDP port number 3389 > Assign Priority of 100 >Give a name to the rule> Rest select all default values and click Add.

   Note : Readers are advised to click the Source and destination drop boxes to see the options.

4. Add inbound allow http rule : Similarly add allow http rule. Enter http port 80 in destination port range> Assign Priority of 110 >Give a name to the rule> Rest select all default values and click Add.

5. Add inbound allow SSH rule : Similarly add allow SSH rule. Enter SSH port 22 in destination port range> Assign Priority of 120 >Give a name to the rule> Rest select all default values and click Add.

6. Figure below shows inbound rules with 3 new rules added.

   Note 1: You can edit the rule by clicking the rule in the right pane or delete the rule by clicking ellipsis ..(Not shown).

   Note 2: You cannot edit or delete the default rules (65000, 65001 & 65500).

Exercise 12: Associate Network Security Group (NSG) with Subnet

In this exercise we will associate Network Security Group NSGCloud created in previous exercise with Web-Subnet in Virtual Network VNETCloud.

1. In NSG Dashboard click Subnets in left pane.

2. In right pane click +Associate > Associate Subnet blade opens> In Associate Subnet Blade select Virtual Network VNETCloud & Subnet Web-Subnet and click ok (Not Shown).

3. Figure below shows Web-Subnet in VNETCloud associated with NSG.

Name Resolution with Azure DNS

Before going into Azure DNS let’s discuss about DNS. DNS or Domain Name System translates domain name to IP Address. The process of DNS resolution involves converting a hostname such as www.test.com into IP address such as 192.168.10.1. When a user wants to access www.test.com, a translation occurs between test.com and the IP address assigned to End user Server. This whole translation involves Global infrastructure of DNS Servers including top level name servers, root servers and Authoritative name server for that particular domain etc.

Azure DNS is a managed hosting service which provides Global infrastructure of name servers to translate Domain Name to IP Address. Azure DNS is a hosting service for DNS domains (Containing DNS Records of a Domain), providing name resolution using Microsoft Azure infrastructure.

Design Nugget : You can't use Azure DNS to buy a domain name.

Features and Benefits of Azure DNS

Availability : DNS domains in Azure DNS are hosted on Azure's global network of DNS name servers which can withstand Datacentre or a Region failure.

Performance : Azure DNS uses anycast networking so that each DNS query is answered by the closest DNS server available to user. This provides fast performance

Ease of use : You can manage your DNS records using the same credentials, APIs, tools, and billing as your other Azure services. You can use Azure portal, Cli or PowerShell to manage Azure DNS.

Security : Azure DNS can be secured using RBAC & Resource locking. You can use Activity logs to monitor user actions and for troubleshooting.

DNS Record types : Azure DNS supports all common DNS record types including A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT records.

Solution Components of Azure DNS

DNS Zones
DNS Records
Delegation to Azure DNS Name Servers from Domain Registrar of your domain

Working in Brief

Using Azure DNS create DNS Zone. DNS Zone creates 4 Name Servers for Your Domain. In DNS Zone, you add DNS records (A, CNAME or MX) pointing to your resource. In domain registrar where you have registered you domain, add Azure DNS Name servers which will delegate DNS Name resolution to Azure DNS Name servers for your domain.

DNS Zones & Records

A DNS zone is used to host the DNS records for a particular domain. DNS record for your domain is created inside this DNS zone. For example, the domain 'contoso.com' may contain several DNS records, such as 'mail.contoso.com' (MX record for a mail server) and 'www.contoso.com' (A record for a web site).

DNS Records

DNS records are mapping files that tell the DNS server which IP address each domain is associated with, and how to handle requests sent to each domain

Each DNS record has a name and a type. Azure DNS supports all common DNS record types including A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV, and TXT.

A Record : An A record points a domain or subdomain to an IP address. MX Record : A MX record specifies a mail server responsible for accepting email messages on behalf of a recipient's domain.

CNAME or Alias Record : A CNAME Record points one domain or subdomain to another domain. For Example when you create Azure VM it is assigned a domain name in the form pipportal.eastus2.cloudapp.azure.com. Using CNAME records you can use www.test.com to point to pipportal.eastus2.cloudapp.azure.com.

NS Record : NS record set contains the names of the Azure DNS name servers assigned to the zone. The NS record is set at the zone apex and is created automatically with each DNS zone, and is deleted automatically when the zone is deleted

SOA Record : A start of authority (SOA) record is information stored in a domain name system (DNS) zone about that zone and about other DNS records. Each zone contains a single SOA record. The SOA record stores information about the name of the server that supplied the data for the zone; the administrator of the zone; the current version of the data file; the number of seconds a secondary name server should wait before checking for updates; the number of seconds a secondary name server should wait before retrying a failed zone transfer; the maximum number of seconds that a secondary name server can use data before it must either be refreshed or expire; and a default number of seconds for the time-to-live file on resource records.

Time to Live (TTL)

TTL specifies how long each record is cached by clients before being requeried.

Exercise 13: DNS Zone, DNS Records and Delegation to Azure DNS

For this exercise we will use mykloud.in domain which is registered with Domain Registrar Go Daddy. We will Create DNS Zone and Add DNS A Record pointing to VM VMFE1 Public IP Address (137.116.68.235). We will then delegate DNS Resolution for myKloud.in domain to Azure DNS

Name servers.
Note 1: Do this Exercise after you have done Exercise 18 in Chapter 2 where VM VMFE1 was deployed.

Step 1 Create DNS Zone

1. In Azure Portal Click All Services>Networking>DNS Zone>All DNS Zone blade opens>Click +ADD>Create DNS Zone blade opens as shown below>In Resource Group select RGCloud>In Name enter mykloud.in > Click Review + Create>After validation is passed click create.

2. Figure below shows DNS Zone Dashboard. There are 4 Name Serversns1, ns2, ns3 & ns4. The SOA is ns1.

   Step 2 Create DNS Records: In DNS Zone dashboard click +Record Set>Add Record Set Blade opens>In Name enter www >Select Record type A> In IP address enter 137.116.68.235 >Click Ok (Not Shown).

1. Copy the Name servers from DNS Zone Dashboard

2. Go to Go Daddy DNS Management page>Scroll down and you can see Name Servers for mykloud.in

3. Click change>Select Custom from dropdown box>Click Add Name Server two Times to make space for 4 Name Servers>Add the Azure DNS Name Servers copied from DNS Zone dashboard>Click save> You can see Azure DNS Name servers in Go Daddy DNS Management responsible for domain mykloud.in

   With this step Azure DNS servers become Authoritative Name Servers for domain mykloud.in.

Step 4: Test the name resolution

1. From DNS zone dashboard copy the name of Azure DNS name server and run following nslookup command on your laptop command prompt. nslookup www.mykloud.in ns1-02.azure-dns.com.

   The domain name www.mykloud.in resolves to 137.116.68.235 which is the IP address of VM VMFE1. The result verifies that name resolution is working correctly using Azure DNS Name Servers.

2. Open Browser and enter www.mykloud.in. You can see the VM VMFE1 default website opens. Do this step after 5-10 Minutes as it takes time to propagate DNS changes.

Azure DNS for private domains

Azure DNS also supports Domain Name Resolution (DNS) for Private Domains in Azure Virtual Network.

Azure DNS Private Zone feature resolves private domain names in a virtual network without needing to add a custom DNS solution. By Using Private DNS

Zone you can assign Custom Private Domain names to Azure VMs instead of using Azure assigned DNS names such as x.eastus2.cloudapp.azure.com

Figure below shows Azure DNS providing Name resolution to Azure VMs which are assigned Custom Private Domain name such as x.contoso.local.

You can link virtual network to a DNS private zone as a Registration Virtual Network or as a Resolution Virtual Network. With a Registration virtual network, Azure will automatically register DNS records for the VMs. In case of Resolution Virtual Network you need to manually add DNS records into the zone for VMs. Only one registration virtual network is allowed per private zone . A Reverse DNS (PTR) query is supported only by Registration Virtual Network.

Benefits of Azure DNS for Private Domains

1. Removes the need for custom DNS solutions .
2. Supports all common DNS records types . Azure DNS supports A, AAAA, CNAME, MX, PTR, SOA, SRV, and TXT records.
3. Automatic hostname record management . Along with hosting custom DNS records, Azure automatically maintains hostname records for the VMs in the specified virtual networks.
4. Hostname resolution between virtual networks . Unlike Azure-provided host names, private DNS zones can be shared between virtual networks. This capability simplifies cross-network and service-discovery scenarios.
5. Split-horizon DNS support. With Azure DNS, you can create Public and Private zones with the same name that resolve to different answers from within a virtual network and from the public internet. The following diagram depicts this scenario.

In this case we have created both Public and Private DNS Zone with same name contoso.com. When an internet client issues a DNS query to look up VNETA-VM1.contoso.com, Azure will return the Public IP record from the public zone. If the same DNS query is issued from another VM (for example: VNETA-VM2) in the same virtual network A, Azure will return the Private IP record from the private zone.

Creating Private DNS Zone using PowerShell

New-AzDnsZone -Name private.contoso.com -ResourceGroupName MyAzureResourceGroup -ZoneType Private -RegistrationVirtualNetworkId @($vnet.Id)

Note: In this case A records of VMs in Virtual Network will be automatically added to the Zone private.contoso.com as we have used Registration Virtual Network option. You also have the option to use ResolutionVirtualNetworkId.

You can add DNS records using Command New-AzDnsRecordSet.

Creating Private DNS Zone using Azure CLI

az network dns zone create -g MyAzureResourceGroup -n private.contoso.com --zone-type Private --registration-vnets myAzureVNet

Note: In this case A records of VMs in Virtual Network will be automatically to the Zone private.contoso.com as we have used registration-vnets option. You also have the option to use resolution-vnets.

You can add DNS records using Command az network dns record-set.

Virtual Networks Peering

Virtual network (VNET) peering connects two VNETs in the same region or different region through the Azure backbone network. Once peered, the two VNETs appear as one for connectivity purposes. Virtual machines (VM) in the peered VNETs can communicate with each other directly by using private IP addresses.

You no longer have to configure Site-to-Site (S2S) VPN between Virtual Networks using Virtual Network gateway. The disadvantage of this option is that connectivity between VNET is over the internet backbone.

Figure Below shows VNET peering between 2 Virtual Networks (VNET1 & VNET2). VMs in both VNETs can now communicate with each other using their Private IPs.

Advantages of VNET Peering

1. VNET-VNET connectivity happens over a low-latency, high-bandwidth connection instead of internet in the case S2S VPN.
2. You no longer have to configure Site-to-Site (S2S) VPN between Virtual Networks using Virtual Network gateway. This results in operational simplicity as Installing and Configuring VPN Gateway is a complex operation. Installation of VPN Gateway takes around 45 Minutes.

Pre-requisite for VNET-VNET Connectivity

1. The peered VNETs must have non-overlapping IP address spaces

Features of VNET Peering

1. You can peer across VNETs in the same region or different regions.
2. You can globally peer across subscriptions.
3. Traffic across peered links is completely private and stays on the Microsoft Backbone Network.

Note 1 : You pay for Data charges for inbound and outbound traffic

Note 2 : You pay more data charges for inbound and outbound traffic when VNETs are in different regions.

Gateway Transit and Remote Gateways

A Virtual Network can connect to on-premises Network even if it does not have its own Virtual Network Gateway. It can use the Gateway of Peered Network.

During Peering configuration you must Enable Use Remote gateways option in Virtual Network for Virtual Network to use Virtual Network Gateway of Peered Virtual Network.

During Peering configuration you must Enable Allow Transit gateway option in Virtual Network for Virtual Network to provide its Virtual Network Gateway to other Peered Virtual Networks.

Figure below shows VNETCloud and VNETOnPrem are connected through Virtual Network Gateway over Internet Connectivity. By enabling Use Remote Gateway option in VNETCloud2, VNETCloud2 can use Gateway of VNETCloud. You also need to enable Allow Gateway Transit on VNETCloud.

Note: Use Remote Gateway functionality requires Virtual Network Gateway (VNG) to be present in peered Network.

Exercise 14: Peering between VNETs - VNETCloud & VNETCloud2

In this exercise we will do peering between Virtual Networks VNETCloud & VNETCloud2. See the topology on Page 29.

1. Go to VNETCloud Dashboard>Click Peering in left pane> In Right Pane Click +Add > Add Peering blade opens > Enter a name>Select VNETCloud2 in Virtual Network> click ok.

2. Go to VNETCloud2 Dashboard>Click Peering in left pane> In Right Pane Click +Add > Add Peering blade opens> Enter a name> Select VNETCloud in Virtual Network>click ok.

3. The 2 VNETs are now peered and connected. You can check the peering status by clicking peering in Virtual Network dashboard. Figure below shows VNETCloud Dashboard with Peering selected in left pane.

4. Figure below shows VNETCloud2 Dashboard with Peering selected in left pane.

You can see in above configuration how easily VNET peering was done in just 2 steps. Secondly there was no complex configuration to be completed as we do in S2S VPN using Virtual Network gateway.

Exercise 15: Peering between VNETs - VNETCloud & VNETCloud3

In this exercise we will do peering between Virtual Networks VNETCloud & VNETCloud3. See the topology on Page 29.

1. Go to VNETCloud Dashboard>Click Peering in left pane> In Right Pane Click +Add > Add Peering blade opens >Enter a name> Select VNETCloud3 in Virtual Network> click ok.

2. Go to VNETCloud3 Dashboard>Click Peering in left pane> In Right Pane Click +Add > Add Peering blade opens > Enter a name> Select VNETCloud in Virtual Network> click ok.

3. The 2 VNETs are now peered and connected. You can check the peering status by clicking peering in Virtual Network dashboard. Figure below shows VNETCloud Dashboard with Peering selected in left pane.

4. Figure below shows VNETCloud3 Dashboard with Peering selected in left pane.

Routing within VNET using Default System Route

Azure automatically creates Default system routes and assigns the routes to each subnet in a virtual network. You can't create system routes, nor can you remove system routes, but you can override some system routes with Custom Routes which can be User Defined Routes (UDR) or BGP Routes or both.

For Example Virtual machines (VMs) in virtual networks can communicate with each other and to the public internet, automatically. You do not need to specify a gateway, even though the VMs are in different subnets.

This happens because every subnet created in a virtual network is automatically associated with a system routes that contains the following system route rules:

• Local VNET Rule: This rule is automatically created for every subnet in a virtual network. It specifies that there is a direct link between the VMs in the VNET and there is no intermediate next hop.

• Internet Rule: This rule handles all traffic destined to the public Internet (address prefix 0.0.0.0/0) and uses the infrastructure internet gateway as the next hop for all traffic destined to the Internet.

• On-premises Rule: This rule applies to all traffic destined to the onpremises address range and uses VPN gateway as the next hop destination.

Azure automatically creates the following default system routes for each subnet:

Traffic routed to the None next hop type is dropped, rather than routed outside the subnet. But for these Addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10) Azure automatically changes the next hop type for the route from None to Virtual network (Local VNET Rule).

Optional Default System Routes

Azure creates default system routes for each subnet, and adds additional optional default routes to specific subnets, or every subnet, when you enable specific Azure capabilities.

System routes control the flow of communication in the following scenarios:

• From within the same subnet.
• From a subnet to another within a VNET.
• From VMs to the Internet.
• From a VNET to another VNET through a VPN gateway.
• From a VNET to another VNET through VNET Peering
• From a VNET to your on-premises network through a VPN gateway
• From a Subnet to Azure Services through VirtualNetworkServiceEndpoint.

Figure Below shows Default System Route associated with Subnets.

Routing within VNET using User Defined Route (UDR)

With user-defined routes you not only override Azure's default system routes but can also add additional routes to a subnet's route table.

With User Defined routes, Virtual Machine traffic in a Subnet goes through a Network virtual appliance (NVA) located in another subnet. This is done by creating Route table (Consisting User Defined Routes) and associating Route Table with the Subnets where traffic originates and terminates.

With UDR, NVA VM acts the gateway for other VMs in your virtual network.

In Figure below a Custom route table consisting of UDR is created and Associated with Web-Subnet and DB-Subnet. Traffic from Web-Subnet to DB-subnet and Vice versa goes through network virtual appliance (NVA) located in DMZ subnet as UDR Route is preferred over Default System Route .

Network virtual appliance (NVA) VM : NVA VM is a Windows Server VM with Private IP and with IP forwarding enabled on Network Interface of the VM.

How Azure selects a route

Subnets rely on Default system routes until a route table is associated to the subnet. Once an association exists, routing is done based on Longest Prefix Match (LPM) among both user defined routes and system routes. If multiple routes contain the same address prefix, Azure selects the route type, based on the following priority:

1. User defined route.
2. BGP route (when ExpressRoute is used).
3. System route.

Route Table

A route table is a collection of individual routes used to decide where to forward packets based on the destination IP address. Route table is associated with Subnet. A route consists of the following:

Address prefix : The destination address in CIDR format.
Next hop type : Next hop type can be Virtual Network, Virtual Network gateway, Internet, virtual appliance (NVA) or none.
Next hop Address : It is the Address of the Virtual Appliance VM. Next hop values are only allowed in routes where the next hop type is Virtual Appliance.

IP Forwarding

To allow Virtual Machine (NVA) to receive traffic addressed to other destinations, enable IP Forwarding for the NVA VM.

Design Nugget UDR

Design Nugget 1 : User defined routes are only applied to traffic leaving a subnet. You cannot create routes to specify how traffic comes into a subnet.

Design Nugget 2 : The appliance you are forwarding traffic to cannot be in the same subnet where the traffic originates. Always create a separate subnet for your appliances.

Design Nugget 3: Each subnet can be associated with one or zero route table apart from system routes. But the same route table can be associated to one or more subnets. All VMs in a subnet use the route table associated to that subnet.

Exercise 16: Routing Traffic between 2 Subnets to pass through another Subnet using UDR

For this Demonstration Exercise we will create user-defined routes to route traffic between Web-Subnet and DB-Subnet to pass-through a network virtual appliance located in DMZ-Subnet as shown in figure below. For this Demonstration lab we will use Virtual Network VNETCloud created in Exercise 3.

Note : Readers are requested to attempt this Exercise at the end of the book otherwise by mistake you can break the topology.

Pre-Req for this Exercise

Windows Server 2016 NVA VM (myvm-nva) is created in DMZ-Subnet with Private IP only. You can do this Exercise even If you have not created NVA VM. If you have not deployed NVA VM then just skip step 1.

Solution

Figure below shows the architecture of the solution.

Step 1: To allow NVA Virtual Machine in DMZ subnet to receive traffic addressed to other destinations, enable IP Forwarding for the NVA VM.

Enable IP Forwarding in NVA Virtual Machine in DMZ subnet : Go to NVA VM Dashboard> Click Networking under settings> In Right pane click Private

Network Interface attached to NVA VM>Network Interface Dashboard opens>Click IP Configuration in left Pane>In Right Pane Click Enabled.

Step 2 Create Route Table (To be associated with Web-Subnet) : In Azure Portal Click All services>Networking>click Route Tables> All Route Tables blade opens> Click + Add> Create Route Table Blade opens>Enter name ToDBSubnet, Select Resource Group RGCloud, Location East US 2 and click create (Not Shown).

Figure below shows Dashboard of Route Table ToDBSubnet.

Step 3 Add a route in Route Table (ToDBSubnet): Go to ToDBSubnet Route table Dashboard> Click Routes in left Pane>Click +Add> Add Route Blade opens > Enter following information and click ok (Not Shown). Route name: RouteToDBSubnet

Address Prefix: Network Address of DB-Subnet 10.1.2.0/24.
Next Hop type: Select Virtual Appliance from Drop Down box.
Next Hop Address: IP Address of NVA VM (myvm-nva) 10.1.3.4.

Step 4 Associate Route Table (ToDBSubnet) with Web-Subnet : Go to Route Table ToDBSubnet Dashboard>click Subnets in left pane>In Right pane click +

Associate>Associate Subnet Blade opens>Click Virtual Network and select VNETCloud>Click Subnet and select Web-Subnet>Click Ok (Not Shown).

Figure below shows Route Table Dashboard. It has one Route and is associated with Web-Subnet.

Step 5 : Create Route Table (To be associated with DB-Subnet) : ) : In Azure Portal Click All services>Networking>click Route Tables> All Route Tables blade opens> Click + Add> Create Route Table Blade opens>Enter name ToWebSubnet, Select Resource Group RGCloud, Location East US 2 and click create (Not Shown).

Step 6 Add a route in Route Table (ToWebSubnet): Go to ToWebSubnet Route table Dashboard> Click Routes in left Pane>Click +Add> Add Route Blade opens > Enter following information and click ok (Not Shown). Route name: RouteToWebSubnet.

Address Prefix: Network Address of Web-Subnet 10.1.1.0/24.
Next Hop type: Select Virtual Appliance from Drop Down box.
Next Hop Address: IP Address of NVA VM (myvm-nva) 10.1.3.4.

Step 7 Associate Route Table (ToWebSubnet) with DB-Subnet : Go to Route Table ToWebSubnet Dashboard>click Subnets in left pane>In Right pane click + Associate>Associate Subnet Blade opens>Click Virtual Network and select VNETCloud>Click Subnet and select DB-Subnet>Click Ok (Not Shown).

Figure below shows the Dashboard of Route Table ToWebSubnet. It has one Route and is associated with DB-Subnet.

Result 1 of above actions : We have both default route and User defined Route associated with Web-Subnet & DB-Subnet.

Result 2 of above actions: Network traffic between Web-Subnet and DBSubnets flows through the network virtual appliance (NVA). Though system route specify that Traffic can flow directly between Web and DB subnet but Traffic flows through NVA as UDR is preferred.