Intro

Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. VNet enables many types of Azure resources, such as Azure Virtual Machines (VM), to securely communicate with each other, the internet, and on-premises networks.

Documentation

• Azure networking documentation

• Virtual Networking Overview

• Virtual Network documentation

• Virtual Network FAQs

• Azure DDoS Protection Standard documentation

• Explore Azure Virtual Networks

Tips And Tidbits

• VMs and services that are part of the same virtual network can access one another.

• By default, all resources in a VNet can communicate outbound to the internet but they cannot receive unsolicited inbound traffic.

  • You can setup inbound rules and can assign a public IP address to a resource that can receive inbound trafffic.

• A VNET can be connected to a VM and other Azure services such as Azure Kubernetes services.

• The network name must be unique in your subscription, but does not need to be globally unique.

• A VNet is scoped to a single region/location.

  • You can implement multiple virtual networks within each Azure subscription and Azure region.

• Virtual networks from different regions can be connected together using Virtual Network Peering or a VPN gateway

Open

• Each virtual network, including a peered virtual network, can have its own gateway.

• Use the Network watcher to get a drawing, graph, painting, picture of the network topology.

• To analyze data flowing between VMs, use Azure Monitor.

  • Azure Monitor for virtual machines (VMs) collects network connection data that you can use to analyze the dependencies and network traffic of your VMs.

  • You can analyze the number of live and failed connections, bytes sent and received, and the connection dependencies of your VMs down to the process level.

  • https://azure.microsoft.com/en-us/blog/analysis-of-network-connection-data-with-azure-monitor-for-virtual-machines/

• You cannot just move a virtual machine between networks.

  • You need to identify the disk used by the VM,

  • Delete the VM itself while retaining the disk, and

  • Recreate the VM in the target virtual network using the original disk.

VNET Benefits

Azure virtual networks provide key networking capabilities:

• Isolation and segmentation

• Internet communications

• Communicate between Azure resources

• Communicate with on-premises resources

• Route network traffic

• Filter network traffic

• Connect virtual networks

IP Address Space

• Each VNet you create has its own CIDR block.

• Recommend uisng the address ranges enumerated in RFC 1918 which are reserved and non-routable.

  • 10.0.0.0 - 10.255.255.255 (10/8 prefix)

  • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

• The following IP addresses are reserved and can’t be used:

  • 224.0.0.0/4 (Multicast)

  • 255.255.255.255/32 (Broadcast)

  • 127.0.0.0/8 (Loopback)

  • 169.254.0.0/16 (Link-local)

  • 168.63.129.16/32 (Internal DNS)

• Azure assigns resources in a virtual network a private IP address from this CIDR block.

• iIt is important to note that Azure reserves 5 IP addresses within each subnet.

  • These are x.x.x.0-x.x.x.3 and the last address of the subnet.

  • x.x.x.1-x.x.x.3 is reserved in each subnet for Azure services.

    • x.x.x.0: Network address

    • x.x.x.1: Reserved by Azure for the default gateway

    • x.x.x.2, x.x.x.3: Reserved by Azure to map the Azure DNS IPs to the VNet space

  • x.x.x.255: Network broadcast address

  • The first address available is always x.x.x.4

• You can add multiple address spaces to a VNET but you must remove vnet peerings first.

Open

• VNets can be linked to other VNets or on-premises networks as long as the CIDR blocks do not overlap.

  • Address space needs to be unique within your subscription and any other networks that you connect to (eg, your organization’s private networks).

  • VNET1 10.0.0.0/24 (10.0.0.1 - 10.0.0.254). If you then create VNET2 with 10.0.0.0/8 (10.0.0.1 - 10.255.255.254), you will be given a warning because the address spaces overlap.

    • You can still create the overlapping networks.

Name Resolution (DNS)

• Use built-in DNS service, or you can configure the virtual network to use your own internal or external Domain Name System (DNS) server.

• More info here: Name resolution for resources in Azure virtual networks

When resources deployed in virtual networks need to resolve domain names to internal IP addresses, they can use one of three methods:

• Azure DNS private zones

• Azure-provided name resolution

  • If you use this option the DNS zone names and records will be automatically managed by Azure and you will not be able to control the DNS zone names or the life cycle of DNS records.

  • The DNS suffix is consistent across the all virtual machines within a virtual network, so the FQDN is not needed.

  • You can use the service in conjunction with your own DNS servers, to resolve both on-premises and Azure host names.

  • When you are using Azure-provided name resolution, Azure Dynamic Host Configuration Protocol (DHCP) provides an internal DNS suffix (.internal.cloudapp.net) to each VM.

  • The Azure DNS IP address is 168.63.129.16. This is a static IP address and will not change.

  • The Azure-created DNS suffix cannot be modified.

  • DNS lookup is scoped to a virtual network. DNS names created for one virtual networks can't be resolved from other virtual networks.

  • WINS and NetBIOS are not supported. You cannot see your VMs in Windows Explorer

• Name resolution that uses your own DNS server  (which might forward queries to the Azure-provided DNS servers)

  • DNS servers within a virtual network can forward DNS queries to the recursive resolvers in Azure.

    • A domain controller (DC) running in Azure can respond to DNS queries for its domains, and forward all other queries to Azure.

    • Forwarding queries allows VMs to see both your on-premises resources (via the DC) and Azure-provided host names (via the forwarder).

    • When you are using your own name resolution solution, a place holder DNS suffix (reddog.microsoft.com) is supplied to VMs by DHCP

  • In order to resolve a VM's host name, the DNS server VM must reside in the same virtual network, and be configured to forward host name queries to Azure. 

    • Because the DNS suffix is different in each virtual network, you can use conditional forwarding rules to send DNS queries to the correct virtual network for resolution.

Subnets

• Subnets enable you to segment the virtual network into one or more sub-networks and allocate a portion of the virtual network's address space to each subnet.

• Subnet address spaces cannot overlap one another.

• You can create one or more subnets that partition the virtual network's address space.

  • You can define one subnet that encompasses all the virtual networks' address ranges, though this is not a good practice.

  • When you design the address ranges of your subnets, remember that the first three IP addresses in each subnet are reserved by Azure for internal use.

• You can segment VNets into different size subnets, creating as many subnets as you require for organization and security within the subscription limit.

• The smallest supported IPv4 subnet is /29, and the largest is /2

• Routing between subnets will then depend on the default traffic routes, or you can define custom routes.

• Subnet names must begin with a letter or number, end with a letter, number or underscore, and may contain only letters, numbers, underscores, periods, or hyphens.

• A default subnet is pre-filled when creating a network in the portal. Only a portion of the address space is apportioned to it.

• Azure automatically creates a route table for each subnet within an Azure virtual network, and adds system default routes to the table.

• Subnet address range can't be changed as long as there is VM connected to it.

• You can limit access to Azure resources to specific subnets with a virtual network service endpoint.

  • You can create multiple subnets, and enable a service endpoint for some subnets, but not others.

• Subnets are scoped to virtual networks, so each subnet within a virtual network must have a distinct name.

Naming Convention

• A well-chosen name helps you quickly identify the resource's type, its associated workload, its deployment environment, and the Azure region hosting it.

• For example, a public IP resource for a production SharePoint workload residing in the West US region might be pip-sharepoint-prod-westus-001.

• All Azure resource types have a scope that defines the level that resource names must be unique.

  • A resource must have a unique name within its scope.

  • There are four levels you can specify a scope: management group, subscription, resource group, and resource.

Availability Zones

• Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.

• Zonal services: Resources can be pinned to a specific zone.

• Zone-redundant services: Resources are replicated or distributed across zones automatically.

  • Azure replicates the data across three zones so that a zone failure does not impact its availability.

• Non-regional services: Services are always available from Azure geographies and are resilient to zone-wide outages as well as region-wide outages.

Azure Services Deployed To Protect VNet

• BastionHost: The Azure Bastion service is a new fully platform-managed PaaS service that you provision inside your virtual network.

  • It provides secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL.

  • When you connect via Azure Bastion, your virtual machines do not need a public IP address.

• Distributed Denial of Service (DDoS) protection You can select to enable Standard DDoS protection.

  • Standard DDoS Protection is a paid service plan that offers enhanced DDoS mitigation capabilities via adaptive tuning, attack notification, and telemetry to protect against the impacts of a DDoS attack for all protected resources within this virtual network.

  • Basic DDoS protection is integrated into the Azure platform by default and at no additional cost.

• Firewall: Azure Firewall is a managed cloud-based network security service that protects your Azure Virtual Network resources.

DDoS Protection

• Every property in Azure is protected by Azure's infrastructure DDoS (Basic) Protection at no additional cost.

• Azure DDoS Protection Standard is a premium service. Protection is simple to enable on any new or existing virtual network, and it requires no application or resource changes. I

• t has several advantages over the basic service, including logging, alerting, and telemetry.

• DDoS protection plans have a fixed monthly charge of $2,944 per month which covers up to 100 public IP addresses. 

Public IP services

• Public IP services

• Private networks like your Azure Virtual Network use private IP addresses, which are not routable on public networks.

• A resource without a public IP assigned can communicate outbound through network address translation services, where Azure dynamically assigns an available IP address that isn't dedicated to the resource.

• Some of the resources you can associate a public IP address resource with:

  • Virtual machine network interfaces

  • Internet-facing load balancers

  • VPN gateways

  • Application gateways

  • Azure Firewall

• A dynamic public IP address is an assigned address that can change over the lifespan of the Azure resource.

  • The dynamic IP address is allocated when you create or start a VM.

  • The IP address is released when you stop or delete the VM.

  • In each Azure region, public IP addresses are assigned from a unique pool of addresses.

• A static public IP address is an assigned address that will not change over the lifespan of the Azure resource.

  • To ensure that the IP address for the resource remains the same, set the allocation method explicitly to static.

• For public IP addresses, there are two types of SKUs to choose from: Basic and Standard.

  • All public IP addresses created before the introduction of SKUs are Basic SKU public IP addresses.

• Basic SKU public IPs:

  • can be assigned by using static or dynamic allocation methods.

  • have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed outbound originated flow idle timeout of 4 minutes.

  • are open by default, so the use of Network security groups is recommended but optional for restricting inbound or outbound traffic.

  • do not support availability zone scenarios.

• Standard SKU public IP addresses:

  • always use the static allocation method.

  • have an adjustable inbound originated flow idle timeout of 4-30 minutes, with a default of 4 minutes, and a fixed outbound originated flow idle timeout of 4 minutes.

  • are secure by default and closed to inbound traffic.

    • You must explicitly allow inbound traffic by using a network security group.

  • can be assigned to network interfaces, Standard public load balancers, application gateways, or VPN gateways.

  • zone-redundant by default and optionally zonal (they can be created zonal and guaranteed in a specific availability zone).

• You can't bring your own public IP addresses from on-premises networks into Azure.

• Public IP addresses can't be moved between regions; all IP addresses are region-specific.

• To ensure a static range of public IP addresses, you can create a public IP address prefix.

  • You can't specify the addresses when you create the prefix, but after the prefix is created, the addresses will be fixed.

  • The IP addresses will be a contiguous range.

  • The advantage of a public IP address prefix is that you can specify firewall rules for these IP addresses with the knowledge that they will not change.

•  

Deploying N-tier applications

• Windows N-tier application on Azure

• One VNET and one subnet for each tier

Routing Traffic Through A Network Appliance

• Exercise - Route traffic through the NVA

•  

AzureRM PowerShell Commands

• Create a VNET

• Get VNET

• Create a Subnet

• Write subnet info to VNET

Create VNET Using Azure CLI

• Create a VNET

Services that can be deployed into a virtual network

• Services that can be deployed into a virtual network

What is IPv6 for Azure Virtual Network?

• What is IPv6 for Azure Virtual Network?

• The IPv6 address is 128 bits (16 bytes).

• IPv6 for Azure Virtual Network (VNet) enables you to host applications in Azure with IPv6 and IPv4 connectivity both within a virtual network and to and from the Internet.

• The following diagram depicts a simple dual stack (IPv4/IPv6) deployment in Azure:

  
  
  

• A single service instance can connect with both IPv4 and IPv6-capable Internet clients.

• The subnets for IPv6 must be exactly /64 in size.

  • This ensures future compatibility should you decide to enable routing of the subnet to an on-premises network since some routers can only accept /64 IPv6 routes.

• Add an IPv4 application to IPv6 in Azure virtual network - PowerShell

• Configure all of the VM NICs with an IPv6 address using Add-AzNetworkInterfaceIpConfig