• Notes
  • Subnets
  • Peering
  • User-defined routes
  • Hybrid networking
  • Network security groups
  • Service endpoints
  • Bastion
  • IPv6
• Tasks
  • Create VNet
  • Create peering
  • Create user-defined routes
  • Create NSG
  • View rules
  • Create Bastion
  • Create virtual appliance
• Sources

A Virtual Network (VNet) consists of one or more IP ranges and exists within a single subscription and region.

Virtual Networks (VNets) created through Portal require at least one subnet.

Subnets span Availability Zones.

Azure uses Classless Inter-Domain Routing (CIDR) notation when describing subnets. Subnet names are immutable and must be unique within each VNet, and their IP ranges must be described using CIDR notation. They can only be deleted if empty.

Azure will reserve 5 IP addresses from each subnet IP range. First and last IP addresses in each subnet are reserved for network identification and broadcast. An additional three addresses at the start (bottom) of the range are reserved. This means the smallest possible subnet is /29, providing 3 addresses for use. For example, the first available IP address in range 192.168.1.0/24 is 192.168.1.4.

VNet peering allows VMs in two separate virtual networks to communicate directly using their private IP addresses. It is not required for the peered networks to be in the same region (Global VNet peering), subscription, or tenant (Cross-tenant peering is possible via Azure CLI, PowerShell, or ARM templates, but not the Portal ^{AZ-103: 306}).

• No gateways are required for peering, although each peering is one-way and not transitive (i.e. VNet A can be peered to both VNets B and C, allowing traffic to/from both. But without a peering directly between B and C they will not be able to communicate to each other.)
• There is a maximum of 100 peering connections per VNet
• Peerings cannot be moved to another resource group or subscription, so they must be disabled before moving peered VNets.

Before peering, virtual networks could be connected using S2S VPN or by connecting to the same ExpressRoute circuit.

A virtual appliance refers to a VM running a network application like a load-balancer, firewall, or router. Service chaining refers to the process of deploying a network virtual appliance (NVA) into a hub network to route traffic between spokes using user-defined routes (UDR). This is a method of reducing the complexity of pairing between individual spoke networks in complex hub-and-spoke architectures. ^{AZ-103: 309}

• In such a deployment, the peerings must be set to Allow Forwarded Traffic.

Alternatively, two peered networks can share a single virtual network gateway, say to connect to an external network.

• The pairing connection to the network that contains the gateway must be set to Use Remote Gateways
• The pairing connection from the network containing the gateway must be set to Allow Gateway Transit

ExpressRoute is the main service used to connect Azure to on-premises networks, although P2S and S2S VPNs are also options.

Network Security Groups (NSGs) are assocated with network interfaces and contain an arbitrary number of security rules.

Service tags represent a group of IP address prefixes managed by Microsoft available for use in NSG rules:

• VirtualNetwork: all CIDR ranges defined for the virtual network, all connected on-premises address spaces, peered VNets or VNets connected to a VNET gateway
• AzureLoadBalancer: Virtual IP address of the host where Azure's health probes originate
• Internet: IP address space that is outside the virtual network
• AzureCloud*: IP address space for Azure, including all datacenter public IP addresses
• AzureTrafficManager*: IP address space for the Azure Traffic Manager probe IP addresses
• Storage:

Each rule has the following properties:

• Name
• Priority: number between 100 and 4096, lower numbers indicate a higher priority
• Source or destination: IP address, CIDR block, service tag, or application security group
• Protocol: TCP, UDP, ICMP, or Any
• Direction: Inbound or outbound
• Port range;
• Action: allow or deny

NSG flow logging ,which saves the 5-tuple of all packets, is available as a low-cost way to monitor traffic. Flow logs record all IP flows going in and out of an NSG and are collected per NSG rule. They are charged per GB of logs collected and include a free tier of 5 GB/month.

Service endpoints facilitate restricting traffic from Azure services. Service endpoint policies allow restricting traffic to the granularity of individual Azure service instances.

Azure Bastion is a PaaS service deployed within a VNet that allows connectivity to a VM from the Portal. Once deployed in a VNet, RDP/SSH is available to all VMs in that VNet. This session is streamed to your local device over an HTMLS session using the browser.

• It is not deployed per VM, but once per VNet to its own dedicated subnet, at least /27 or larger
• No public IP is necessary on the VM, the connection from Bastion to the VM is to the private IP. However, the Bastion itself does require a public IP.
• Bastion can now span peered VNets

IPv6 support is limited in Azure. IPv6 addresses are not added to VMs by default and must be explicitly defined by adding an endpoint to each VM to be using it. Routing by IPv6 is also not supported, so load balancers have to be deployed.

# Create a subnet first, to pass to the VNet upon creation
$subnet = New-AzVirtualNetworkSubnetConfig -Name "subnet1" -AddressPrefix "10.0.0.0/24"
$vnet = New-AzVirtualNetwork -Name "vnet" -ResourceGroupName "RG" -Location "East US" -AddressPrefix "10.0.0.0/16" -Subnet $subnet

Add-AzVirtualNetworkPeering -Name 'VNet2-to-VNet1' -VirtualNetwork $vnet2 -RemoteVirtualNetworkId $vnet1.Id
Add-AzVirtualNetworkPeering -Name 'VNet1-to-VNet2' -VirtualNetwork $vnet1 -RemoteVirtualNetworkId $vnet2.Id

Peer VNet1 to VNet2

az network vnet peering create --name VNet1-to-VNet2 --resource-group ExamRefRG --vnet-name VNet1 --allow-vnet-access --remote-vnet VNet2
az network vnet peering create --name VNet2-to-VNet1 --resource-group ExamRefRG --vnet-name VNet2 --allow-vnet-access --remote-vnet VNet1

Check peering

Get-AzVirtualNetworkPeering -ResourceGroupName ExamRefRG -VirtualNetworkName VNet1 |
Format-Table VirtualNetworkName, PeeringState

az network vnet peering list --resource-group ExamRefRG --vnet-name VNet1 -o table
az network vnet peering list --resource-group ExamRefRG --vnet-name VNet2 -o table

First, create the route table resource, then add routes

Create the route table resource

$rt = New-AzRouteTable -Name RouteTable1 -ResourceGroupName ExamRefRG

Add a route to route table

Add-AzRouteConfig -RouteTable $rt -Name Route1 -AddressPrefix 10.3.0.0/16 -NextHopType VirtualAppliance -NextHopIpAddress 10.2.20.4
Set-AzRouteTable -RouteTable $rt

Find the VNet and subnet

$vnet = Get-AzVirtualNetwork -Name VNet1 -ResourceGroupNAme ExamRefRG 
$subnet = $vnet.Subnets | where {$_.Name -eq "Default"}

Update the subnet to specify the route table

Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name Default -AddressPrefix $subnet.AddressPrefix -RouteTable $rt

Commit the VNet back to Azure

Set-AzVirtualNetwork -VirtualNetwork $vnet

Get effective routes for a NIC

Get-AzEffectiveRouteTable -NetworkInterfaceName VNet1-VM -ResourceGroupName ExamRefRG

Create route table

az network route-table create --name rt --resource-group rg 

Add route to route table

az network route-table route create --name Route1 --route-table-name rt --resource-group rg --address-prefix 10.3.0.0/16 --next-hop-type VirtualAppliance --next-hop-ip-address 10.2.20.4

Associate route table with subnet

az network vnet subnet update --name defualt --vnet-name Vnet1 --resource-group rg --route-table rt

Get effective routes for NIC

az network nic show-effective-route-table --name VM1-NIC --resource-group rg

$nsgRules = @()
$nsgRules += New-AzNetworkSecurityRuleConfig -Name "AllowingWinRMHTTP" -Description "To Enable PowerShell Remote Access" -Access Allow -Protocol Tcp -Direction Inbound -Priority 103 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 5985
$nsgRules += New-AzNetworkSecurityRuleConfig -Name "AllowingWinRMHTTPS" -Description "To Enable PowerShell Remote Access" -Access Allow -Protocol Tcp -Direction Inbound -Priority 104 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 5986
$nsg = New-AzNetworkSecurityGroup -Name "wscore-nsg" -ResourceGroupName "RG" -Location "East US" -SecurityRules $nsgRules

Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName examref-vm1638 -ResourceGroupName ExamRefRG

az network nic list-effective-nsg --name examref-vm1638 --resource-group ExamRefRG

Connecting to a VM requires at least Reader role privileges on the VM, its NIC, and on the Bastion itself.

New-AzBastion -ResourceGroupName $g -Name $n -PublicIpAddress $pip -VirtualNetwork $vnet

az network bastion create -g $g -n $n -l $l --public-ip-address $pip  --vnet-name $vnet 

IP forwarding must be enabled on the VM's NIC, then applications installed on the VM can begin accepting packets destined for other IP addresses.

Exam objectives:

• AZ-103 4.1 4.4

• AZ-104 4.1 4.3

• Azure Virtual Network Overview

• Azure Bastion

• Introduction to flow logging for NSGs

• Create Bastion: PowerShell New-AzBastion, Azure CLI az network bastion create