Reference
AZ-104: Configure and manage virtual networks for Azure administrators – Learn | Microsoft Docs
Explore Azure virtual networking – Learn | Microsoft Docs
Communication between Azure Resources
- Virtual networks
- Service Endpoints
Communication with on-premises network
- Point to site VPN
- Site to site VPN
- Azure Express Route: For environments where you need greater bandwidth and even higher levels of security, Azure ExpressRoute is the best approach. Azure ExpressRoute provides dedicated private connectivity to Azure that does not travel over the Internet.
Traffic Routing
By default, Azure will route traffic between subnets on any connected virtual networks, on-premises networks, and the Internet. However, you can control routing and override those settings as follows:
- Route tables: A route table allows you to define rules as to how traffic should be directed. You can create custom route tables that control how packets are routed between subnets.
- Border Gateway Protocol: Border Gateway Protocol (BGP) works with Azure VPN gateways or ExpressRoute to propagate on-premises BGP routes to Azure virtual networks.
Filter Network Traffic
- Network security groups: A network security group is an Azure resource that can contain multiple inbound and outbound security rules. You can define these rules to allow or block traffic, based on factors such as source and destination IP address, port, and protocol.
- Network virtual appliances: A network virtual appliance is a specialized VM that can be compared to a hardened network appliance. A network virtual appliance carries out a particular network function, such as running a firewall or performing WAN optimization.
Virtual Network Peering: You can link virtual networks together using virtual network peering. Peering enables resources in each virtual network to communicate with each other. These virtual networks can be in separate regions, allowing you to create a global interconnected network through Azure.
Create an Azure virtual network
# Create Resource Group
$Location="EastUS"
# Create subnet & vnet
New-AzResourceGroup -Name vm-networks -Location $Location
$Subnet=New-AzVirtualNetworkSubnetConfig -Name default -AddressPrefix 10.0.0.0/24
New-AzVirtualNetwork -Name myVnet -ResourceGroupName vm-networks -Location $Location -AddressPrefix 10.0.0.0/16 -Subnet $Subnet
# Create a VM
New-AzVm `
-ResourceGroupName "vm-networks" `
-Name "dataProcStage1" `
-VirtualNetworkName "myVnet" `
-SubnetName "default" `
-image "Win2016Datacenter" `
-Size "Standard_DS2_v2"
# Get IP Address
Get-AzPublicIpAddress -Name dataProcStage1
# Disassociate default public IP
$nic = Get-AzNetworkInterface -Name dataProcStage1 -ResourceGroup vm-networks
$nic.IpConfigurations.publicipaddress.id = $null
Set-AzNetworkInterface -NetworkInterface $nic
# Port 3389 is opened automatically by default when you create a Windows VM in Azure.
# Firewall rules can be set by connecting remotely and type "Firewall" in start menu
# Windows firewall with advanced security console appears
# right-click File and Printer Sharing (Echo Request - ICMPv4-In), and then click Enable Rule.
# This is only applicable if you want to ping from inside the Vnet
# to ping from your local computer enable icmp from network security group (in Azure)
Azure VPN Gateway
Each virtual network can have only one VPN gateway. All connections to that VPN gateway share the available network bandwidth. Within each virtual network gateway there are two or more virtual machines (VMs). These VMs have been deployed to a special subnet that you specify, called the gateway subnet. They contain routing tables for connections to other networks, along with specific gateway services. These VMs and the gateway subnet are similar to a hardened network device. You don’t need to configure these VMs directly and should not deploy any additional resources into the gateway subnet.Creating a virtual network gateway can take some time to complete, so it’s vital that you plan appropriately. When you create a virtual network gateway, the provisioning process generates the gateway VMs and deploys them to the gateway subnet. These VMs will have the settings that you configure on the gateway. A key setting is the gateway type. The gateway type determines the way the gateway functions. For a VPN gateway, the gateway type is “vpn”. Options for VPN gateways include:
- Network-to-network connections over IPsec/IKE VPN tunneling, linking VPN gateways to other VPN gateways.
- Cross-premises IPsec/IKE VPN tunneling, for connecting on-premises networks to Azure through dedicated VPN devices to create site-to-site connections.
- Point-to-site connections over IKEv2 or SSTP, to link client computers to resources in Azure.
When you’re planning a VPN gateway, there are three architectures to consider:
- Point to site over the Internet
- Site to site over the Internet
- Site to site over a dedicated network, such as Azure ExpressRoute
It’s important that you choose the right gateway SKU. If you have set up your VPN gateway with the wrong one, you’ll have to take it down and rebuild the gateway, which can be time consuming.
Gateway Design Considerations
When you design your VPN gateways to connect virtual networks, you must consider the following factors:
- Subnets cannot overlap: It is vital that a subnet in one location does not contain the same address space as in another location.
- IP addresses must be unique: You cannot have two hosts with the same IP address in different locations, as it will be impossible to route traffic between those two hosts and the network-to-network connection will fail.
- VPN gateways need a gateway subnet called GatewaySubnet:It must have this name for the gateway to work, and it should not contain any other resources.
VPN Gateway Types
- RouteBased:Route-based VPN devices use any-to-any (wildcard) traffic selectors, and let routing/forwarding tables direct traffic to different IPsec tunnels. Route-based connections are typically built on router platforms where each IPsec tunnel is modeled as a network interface or VTI (virtual tunnel interface).
- PolicyBased: Policy-based VPN devices use the combinations of prefixes from both networks to define how traffic is encrypted/decrypted through IPsec tunnels. A policy-based connection is typically built on firewall devices that perform packet filtering. IPsec tunnel encryption and decryption are added to the packet filtering and processing engine.
Create an AzureVPN Gateway
$VNetName = "VNetData"
$FESubName = "FrontEnd"
$BESubName = "Backend"
$GWSubName = "GatewaySubnet"
$VNetPrefix1 = "192.168.0.0/16"
$VNetPrefix2 = "10.254.0.0/16"
$FESubPrefix = "192.168.1.0/24"
$BESubPrefix = "10.254.1.0/24"
$GWSubPrefix = "192.168.200.0/26"
$VPNClientAddressPool = "172.16.201.0/24"
$ResourceGroup = "VpnGatewayDemo"
$Location = "East US"
$GWName = "VNetDataGW"
$GWIPName = "VNetDataGWPIP"
$GWIPconfName = "gwipconf"
New-AzResourceGroup -Name $ResourceGroup -Location $Location
# frontend , backend and gatewaysubnet
$fesub = New-AzVirtualNetworkSubnetConfig -Name $FESubName -AddressPrefix $FESubPrefix
$besub = New-AzVirtualNetworkSubnetConfig -Name $BESubName -AddressPrefix $BESubPrefix
$gwsub = New-AzVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix
# create VNet
New-AzVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroup -Location $Location -AddressPrefix $VNetPrefix1,$VNetPrefix2 -Subnet $fesub, $besub, $gwsub -DnsServer 10.2.1.3
$vnet = Get-AzVirtualNetwork -Name $VNetName -ResourceGroupName $ResourceGroup
$subnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
# Get reference to the Vnet & gatewaysubnet
$pip = New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $ResourceGroup -Location $Location -AllocationMethod Dynamic
$ipconf = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $subnet -PublicIpAddress $pip
# Create an IP address and GatewayIPconfig
$pip = New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $ResourceGroup -Location $Location -AllocationMethod Dynamic
$ipconf = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $subnet -PublicIpAddress $pip
# create the VPN
New-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $ResourceGroup `
-Location $Location -IpConfigurations $ipconf -GatewayType Vpn `
-VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw1 -VpnClientProtocol "IKEv2"
# add the client address pool
$Gateway = Get-AzVirtualNetworkGateway -ResourceGroupName $ResourceGroup -Name $GWName
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway -VpnClientAddressPool $VPNClientAddressPool
# create a self signed root certificate on local machine
# next generate a client certificate signed by the root certificate
# Export root certificate's public key
# Upload the certificate to Azure
Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -VirtualNetworkGatewayname $GWName -ResourceGroupName $ResourceGroup -PublicCertData $CertBase64
# Configure the native VPN client
$profile = New-AzVpnClientConfiguration -ResourceGroupName $ResourceGroup -Name $GWName -AuthenticationMethod "EapTls"
$profile.VPNProfileSASUrl
# Copy the URL returned in the output from this command and paste it into your browser. Your browser should start downloading a .ZIP file. Extract the archive contents and put them in a suitable location.
# This will install the VPN client on the local machine
Azure ExpressRoute
Microsoft Azure ExpressRoute enables organizations to extend their on-premises networks into the Microsoft Cloud over a private connection implemented by a connectivity provider. This arrangement means that the connectivity to the Azure datacenters doesn’t go over the Internet but across a dedicated link. ExpressRoute also facilitates efficient connections with other Microsoft cloud-based services, such as Microsoft 365 and Dynamics 365. Advantages that ExpressRoute provides include:
- Faster speeds, from 50 Mbps to 10 Gbps, with dynamic bandwidth scaling
- Lower latency
- Greater reliability through built-in peering
- Highly secure
- Connectivity to all supported Azure services
- Global connectivity to all regions (requires premium add-on)
- Dynamic routing over Border Gateway Protocol
- Service-level agreements (SLAs) for connection uptime
- Quality of Service (QoS) for Skype for Business
Connections into ExpressRoute can be through the following mechanisms:
- IP VPN network (any-to-any):provide connectivity between branch offices and your corporate datacenter over managed layer 3 connections. With ExpressRoute, the Azure datacenters appear as if they were another branch office.
- Virtual cross-connection through an Ethernet exchange: If your organization is co-located with a cloud exchange facility, you request cross-connections to the Microsoft Cloud through your provider’s Ethernet exchange. These cross-connections to the Microsoft Cloud can operate at either layer 2 or layer 3 managed connections, as in the networking OSI model.
- Point-to-point Ethernet connection: Point-to-point Ethernet links can provide layer 2 or managed layer 3 connections between your on-premises datacenters or offices to the Microsoft Cloud.
Azure ExpressRoute uses a combination of ExpressRoute circuits and routing domains to provide high-bandwidth connectivity to the Microsoft Cloud.
An ExpressRoute circuit is the logical connection between your on-premises infrastructure and the Microsoft Cloud. A connectivity provider implements that connection, although some organizations use multiple connectivity providers for redundancy reasons.An ExpressRoute circuit isn’t equivalent to a network connection or a network device. Each circuit is defined by a GUID, called a service or s-key. This s-key provides the connectivity link between Microsoft, your connectivity provider, and your organization – it isn’t a cryptographic secret. Each s-key has a one-to-one mapping to an Azure ExpressRoute circuit.Each circuit can have up to two peerings, which are a pair of BGP sessions that are configured for redundancy. They are:
- Azure private
- Microsoft
ExpressRoute circuits then map to routing domains, with each ExpressRoute circuit having multiple routing domains. These domains are the same as the two peerings listed above. In an active-active configuration, each pair of routers would have each routing domain configured identically, thus providing high availability. The Azure private peering names represent the IP addressing schemes.
Azure private peering connects to Azure compute services such as virtual machines and cloud services that are deployed with a virtual network. As far as security goes, the private peering domain is simply an extension of your on-premises network into Azure. You then enable bidirectional connectivity between that network and any Azure virtual networks, making the Azure VM IP addresses visible within your internal network.You can connect only one virtual network to the private peering domain.
- You need to connect Azure resources like Azure virtual machines across geographical regions. Which Azure networking option should you use?
- Azure ExpressRoute
- VPN Gateway
- Virtual network peering
- For a point-to-site Azure VPN gateway, what are the key parameters that you must specify when you create it?
- Gateway type is Vpn and vpn type is RouteBased.
- Gateway type is Vpn, vpn type is RouteBased, and you need to specify a gateway sku.
- Subnet is GatewaySubnet and gateway type is Vpn
- Which peering configuration would you use for your Express route circuit where you need to allow direct connections to Azure compute resources?
- Azure Virtual Network peering
- Azure private peering
- Microsoft peering
- Which protocol provides dynamic routing for Azure ExpressRoute?
- IPVPN
- Border Gateway Protocol (BGP)
- S-key
Reference
Design an IP addressing schema for your Azure deployment – Learn | Microsoft Docs
There are three ranges of non-routable IP addresses that are designed for internal networks that won’t be sent over internet routers:
- 10.0.0.0 to 10.255.255.255
- 172.16.0.0 to 172.31.255.255
- 192.168.0.1 to 192.168.255.255
By default, all subnets in an Azure virtual network can communicate with each other. However, you can use a network security group to deny communication between subnets. The smallest subnet that is supported uses a /29 subnet mask. The largest supported subnet uses a /8 subnet mask. Before you start integrating Azure with on-premises networks, it’s important to identify the current private IP address scheme used in the on-premises network. There can be no IP address overlap for interconnected networks. For example, you can’t use 192.168.0.0/16 on your on-premises network and use 192.168.10.0/24 on your Azure virtual network. These ranges both contain the same IP addresses and won’t be able to route traffic between each other. You can, however, have the same class range for multiple networks. For example, you can use the 10.10.0.0/16 address space for your on-premises network and the 10.20.0.0/16 address space for your Azure network because they don’t overlap. It is vital to check for overlaps when you’re planning an IP address scheme. If there’s an overlap of IP addresses, you can’t integrate your on-premises network with your Azure network.
- Which objects are required when you connect a virtual network to an on-premises network by using an Azure VPN gateway?
- A dedicated leased line
- A dedicated subnet for the gateway
- A dedicated network security group
- Which of the following IP address ranges is routable over the internet?
- 10.0.0.0 to 10.255.255.255
- 215.11.0.0 to 215.11.255.255
- 172.16.0.0 to 172.31.255.255
- 192.168.0.1 to 192.168.255.255
| Property | Basic | Standard |
|---|---|---|
| Allocation Method | Static & Dynamic | Static |
| Idle Timeout | 4-30 mins,default 4 mins | 4-30 mins, Default 4 mins |
| Status | Open by default | Closed, open using n/w sec group |
| Security | Not secure | Secure by default |
| Availability | – | Supports availability Zones |
| Assigned to | nics, VPN gateways, internet facing LB, App g/w, vpn g/w | nics, Public & Stand LB, App g/w, VPN’s |
Public IP address prefix
You can’t bring your own public IP addresses from on-premises networks into Azure. Based on the location of the resource, an IP address is assigned from a pool of available addresses. Public IP addresses are allocated from a range that’s unique to each region in each Azure cloud. Public IP addresses can’t be moved between regions; all IP addresses are region-specific. If your business needs to have datacenters in different regions, you would have a different public IP address range for each region. You can use technology like Azure Traffic Manager to balance between region-specific instances.
The first three IP addresses are reserved for all subnets by default in Azure. For protocol conformance, the first and last IP addresses of all subnets also are reserved. An internal DHCP service within Azure assigns and maintains the lease of IP addresses. The .1, .2, .3, and last IP addresses are not visible or configurable by the Azure customer. These addresses are reserved and used by internal Azure services. In Azure virtual networks, IP addresses can be allocated to the following types of resources:
- Virtual machine network interfaces
- Load balancers
- Application gateways
- Which of the following resources can you assign a public IP address to?
- A virtual machine
- Azure Data Lake
- Azure Key Vault
- What must a virtual machine have to communicate with the other resources in the same virtual network?
- Load balancer
- Network security group
- Network interface

Remember that Azure uses the first three addresses on each subnet. The first and last IP addresses of the subnets also are reserved for protocol conformance. Therefore, the number of possible addresses on an Azure subnet is 2^n-5, where n represents the number of host bits.
Reference
The two types of peering connections are created in the same way:
- Virtual network peering connects virtual networks in the same Azure region, such as two virtual networks in North Europe.
- Global virtual network peering connects virtual networks that are in different Azure regions, such as a virtual network in North Europe and a virtual network in West Europe.
Reciprocal connections
When you create a virtual network peering connection in only one virtual network to connect to a peer in another network, you’re not connecting the networks together. To connect the networks by using virtual network peering, you have to create connections in each virtual network.
Cross-subscription virtual network peering
You can use virtual network peering even when both virtual networks are in different subscriptions. When you use virtual network peering across subscriptions, you might find that an administrator of one subscription doesn’t administer the peer network’s subscription. The administrator might not be able to configure both ends of the connection. To peer the virtual networks when both subscriptions are in different Azure Active Directory tenants, the administrators of each subscription must grant the peer subscription’s administrator the Network Contributor role on their virtual network.
Transitivity
Virtual network peering is nontransitive. Only virtual networks that are directly peered can communicate with each other. The virtual networks can’t communicate with the peers of their peers.
Gateway transit
You can configure transitive connections on-premises if you use virtual network gateways as transit points. Using gateway transit, you can enable on-premises connectivity without deploying virtual network gateways to all your virtual networks.To enable gateway transit, configure the Allow gateway transit option in the hub virtual network where you deployed the gateway connection to your on-premises network. Also configure the Use remote gateways option in any spoke virtual networks.
Overlapping address spaces
IP address spaces of connected networks within Azure and between Azure and your on-premises system can’t overlap. This is also true for peered virtual networks. Keep this rule in mind when you’re planning your network design. In any networks you connect through virtual network peering, VPN, or ExpressRoute, assign different address spaces that don’t overlap.
Reference
- Network security groups are assigned to a network interface or a subnet. When you assign a network security group to a subnet, the rules apply to all network interfaces in that subnet. You can restrict traffic further by associating a network security group to the network interface of a VM.
- When you apply network security groups to both a subnet and a network interface, each network security group is evaluated independently. Inbound traffic is first evaluated by the network security group applied to the subnet, and then by the network security group applied to the network interface.
- Each subnet and network interface can have one network security group applied to it. Network security groups support TCP, UDP, and ICMP, and operate at Layer 4 of the OSI model.
- A network security group contains one or more security rules. Configure security rules to either allow or deny traffic.
- 5
- Rules have several properties: Name, Priority (# between 100 & 4096), Source or destination,Protocol, Direction, Port range, Action
- With network security groups, the connections are stateful. Return traffic is automatically allowed for the same TCP/UDP session.
- When you create a network security group, Azure creates several default rules. These default rules can’t be changed, but can be overridden with your own rules.
Augmented security rule
You use augmented security rules for network security groups to simplify the management of large numbers of rules. Augmented security rules also help when you need to implement more complex network sets of rules. Augmented rules let you add the following options into a single security rule:
- Multiple IP addresses
- Multiple ports
- Service tags
- App security groups
#Create new rule with new NSG
$rules = New-AzureRmNetworkSecurityRuleConfig -Name augmented-rule -Description "Allow RDP" `
-Access Allow -Protocol Tcp -Direction Inbound -Priority 100 `
-SourceAddressPrefix Internet -SourcePortRange * `
-DestinationAddressPrefix "172.16.0.0/24","10.0.0.0/24" -DestinationPortRange 3389 -Verbose
New-AzureRmNetworkSecurityGroup -Name RDP -ResourceGroupName "augmented-security-rules" -Location eastus -SecurityRules $rules -Verbose
App security groups
App security groups let you configure network security for resources used by specific apps. You can group VMs logically, no matter what their IP address or subnet assignment. Use app security groups within a network security group to apply a security rule to a group of resources. It’s easier to deploy and scale up specific app workloads.
Service tags
A service tag represents a group of IP address prefixes from a given Azure service. It helps to minimize the complexity of frequent updates on network security rules.You can use service tags to define network access controls on network security groups or Azure Firewall. Use service tags in place of specific IP addresses when you create security rules. By specifying the service tag name, such as ApiManagement, in the appropriate source or destination field of a rule, you can allow or deny the traffic for the corresponding service.
Virtual network service endpoints
Use virtual network service endpoints to extend your private address space in Azure by providing a direct connection to your Azure services. Service endpoints let you secure your Azure resources to only your virtual network. Service traffic will remain on the Azure backbone, and doesn’t go out to the internet.By default, Azure services are all designed for direct internet access. All Azure resources have public IP addresses, including PaaS services,Service endpoints can connect certain PaaS services directly to your private address space in Azure, so they act like they’re on the same virtual network. Use your private address space to access the PaaS services directly. Adding service endpoints doesn’t remove the public endpoint. It simply provides a redirection of traffic.To enable a service endpoint, you must do the following two things:
- Turn off public access to the service.
- Add the service endpoint to a virtual network.
When you enable a service endpoint, you restrict the flow of traffic, and enable your Azure VMs to access the service directly from your private address space. Service resources that you’ve secured by using virtual network service endpoints are not, by default, accessible from on-premises networks. To access resources from an on-premises network, use NAT IPs. If you use ExpressRoute for connectivity from on-premises to Azure, you have to identify the NAT IP addresses that are used by ExpressRoute. By default, each circuit uses two NAT IP addresses to connect to the Azure backbone network. You then need to add these IP addresses into the IP firewall configuration of the Azure service resource (for example, Azure Storage).
Restrict Access to azure storage by using service endpoints
# create an outbound rule to allow access to Storage
az network nsg rule create \
--resource-group $rg \
--nsg-name ERP-SERVERS-NSG \
--name Allow_Storage \
--priority 190 \
--direction Outbound \
--source-address-prefixes "VirtualNetwork" \
--source-port-ranges '*' \
--destination-address-prefixes "Storage" \
--destination-port-ranges '*' \
--access Allow \
--protocol '*' \
--description "Allow access to Azure Storage"
# create an outbound rule to deny all internet access,
az network nsg rule create \
--resource-group $rg \
--nsg-name ERP-SERVERS-NSG \
--name Deny_Internet \
--priority 200 \
--direction Outbound \
--source-address-prefixes "VirtualNetwork" \
--source-port-ranges '*' \
--destination-address-prefixes "Internet" \
--destination-port-ranges '*' \
--access Deny \
--protocol '*' \
--description "Deny access to Internet."
# create a storage account for engineering documents
STORAGEACCT=$(az storage account create \
--resource-group $rg \
--name engineeringdocs$RANDOM \
--sku Standard_LRS \
--query "name" | tr -d '"')
# Store the primary key for your storage in a variable
STORAGEKEY=$(az storage account keys list \
--resource-group $rg \
--account-name $STORAGEACCT \
--query "[0].value" | tr -d '"')
# create an Azure file share called erp-data-share,
az storage share create \
--account-name $STORAGEACCT \
--account-key $STORAGEKEY \
--name "erp-data-share"
# assign the Microsoft.Storage endpoint to the subnet
az network vnet subnet update \
--vnet-name ERP-servers \
--resource-group $rg \
--name Databases \
--service-endpoints Microsoft.Storage
# deny all access to change the default action to Deny
az storage account update \
--resource-group $rg \
--name $STORAGEACCT \
--default-action Deny
# restrict access to the storage account
az storage account network-rule add \
--resource-group $rg \
--account-name $STORAGEACCT \
--vnet ERP-servers \
--subnet Databases
# Test access to storage resources
APPSERVERIP="$(az vm list-ip-addresses \
--resource-group $rg \
--name AppServer \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
DATASERVERIP="$(az vm list-ip-addresses \
--resource-group $rg \
--name DataServer \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
ssh -t azureuser@$APPSERVERIP \
"mkdir azureshare; \
sudo mount -t cifs //$STORAGEACCT.file.core.windows.net/erp-data-share azureshare \
-o vers=3.0,username=$STORAGEACCT,password=$STORAGEKEY,dir_mode=0777,file_mode=0777,sec=ntlmssp; findmnt \
-t cifs; exit; bash"
# Receive a mount error
ssh -t azureuser@$DATASERVERIP \
"mkdir azureshare; \
sudo mount -t cifs //$STORAGEACCT.file.core.windows.net/erp-data-share azureshare \
-o vers=3.0,username=$STORAGEACCT,password=$STORAGEKEY,dir_mode=0777,file_mode=0777,sec=ntlmssp;findmnt \
-t cifs; exit; bash"
# mount should be successful
Reference
Connect to Azure VM’s using the Azure Bastion service
Azure Bastion provides a secure remote connection from the Azure portal to Azure virtual machines (VMs) over Transport Layer Security (TLS). Provision Azure Bastion to the same Azure virtual network as your VMs or to a peered virtual network. Then connect to any VM on that virtual network or a peered virtual network directly from the Azure portal.
- You connect to a VM in the Azure portal. In the Azure portal, on the VM overview page, select Connect > Bastion > Use Bastion. Then enter your credentials for the VM.
- Browser connects to the Azure Bastion host. The browser connects to Azure Bastion over the internet by using Transport Layer Security (TLS) and the public IP of the Azure Bastion host. Azure Gateway Manager manages portal connections to the Azure Bastion service on port 443 or 4443.
- Bastion connects to the VM by using RDP or SSH. Azure Bastion is deployed in a separate subnet called AzureBastionSubnet within the virtual network. You create the subnet when you deploy Azure Bastion. The subnet can have address spaces with a /27 subnet mask or larger. Don’t deploy other Azure resources to this subnet or change the subnet name.
- Bastion streams the VM to the browser. Azure Bastion uses an HTML5-based web client that’s automatically streamed to your local device. The Azure Bastion service packages the session information by using a custom protocol. The packages are transmitted through TLS.
For Azure Bastion to work, your network security group needs to allow the following traffic.
| Direction | Allow |
|---|---|
| Inbound | RDP and SSH connections from the Azure Bastion subnet IP address range to your VM subnet. |
| Inbound | TCP access from the internet on port 443 to the Azure Bastion public IP. |
| Inbound | TCP access from Azure Gateway Manager on ports 443 or 4443. Azure Gateway Manager manages portal connections to the Azure Bastion service. |
| Outbound | TCP access from the Azure platform on port 443. This traffic is used for diagnostic logging. |
Before you can deploy Azure Bastion, you need a virtual network. You can use an existing virtual network or deploy Azure Bastion as you create a virtual network. Create a subnet in the virtual network called AzureBastionSubnet. If you have a VM that’s on the same or a peered virtual network, you complete the deployment in the Azure portal by selecting Azure Bastion when you connect to the VM.
Enable Azure Bastion when you create a virtual network
Add the subnet to an existing virtual network and provision Azure Bastion resources
On your existing virtual network, add a subnet named AzureBastionSubnet.
# Powershell
$subnetName = "AzureBastionSubnet"
$virtualNetwork = MyVirtualNetwork
$addressPrefix = "10.0.2.0/24"
$subnet = New-AzVirtualNetworkSubnetConfig `
-Name $subnetName `
-AddressPrefix $addressPrefix `
Add-AzVirtualNetworkSubnetConfig `
-Name $subnetName `
-VirtualNetwork $virtualNetwork `
-AddressPrefix $addressprefix
$publicip = New-AzPublicIpAddress `
-ResourceGroupName "myBastionRG" `
-name "myPublicIP" `
-location "westus2" `
-AllocationMethod Static `
-Sku Standard
$bastion = New-AzBastion `
-ResourceGroupName "myBastionRG" `
-Name "myBastion" `
-PublicIpAddress $publicip `
-VirtualNetwork $virtualNetwork
# Azure Client
az network vnet subnet create \
--resource-group myBastionRG \
--vnet-name MyVirtualNetwork \
--name AzureBastionSubnet \
--address-prefixes 10.0.2.0/24
az network public-ip create
--resource-group MyResourceGroup \
--name MyPublicIp \
--sku Standard \
--location westus2
az network bastion create \
--name MyBastion \
--public-ip-address MyPublicIp \
--resource-group MyResourceGroup \
--vnet-name MyVnet \
--location westus2
Azure Bastion can log information about remote user sessions. Review the logs to see who connected to which workloads, at what time, from where, and other relevant logging information. To generate these logs, you must configure diagnostic settings on Azure Bastion. It can take several hours for the logs to stream to a storage account.

- An organization has set up virtual machines (VMs) to act as jumpboxes in each of its six virtual networks. Why should the organization consider using Azure Bastion?
- The organization can eliminate the need to manage its virtual networks.
- The organization can eliminate all of its VM management work.
- The organization can simplify the management of its VMs.
- At what resource level or scope does an Azure Bastion connection apply to?
- Resource group
- Virtual network or peered virtual networks
- Subscription
- You decide to deploy Azure Bastion to an existing virtual network by using the Azure CLI. What resources do you need to create?
- VM, public IP, and Azure Bastion
- Subnet named AzureBastionSubnet and at least one VM
- Subnet named AzureBastionSubnet, public IP, and Azure Bastion
- Several of your peers are having trouble connecting to VMs by using Azure Bastion. What isn’t likely to cause the problem?
- The public IP address of the destination VM
- The number of current remote connections
- Network security group rules
- You want to add an extra layer of security to Azure Bastion. Where can you start?
- Deny all inbound TCP network traffic to the Azure Bastion public IP
- Apply role-based access control (RBAC) and the least privilege to use and manage Azure Bastion
- Remove the reader role on the Azure Bastion resource for all users

Reference
Host your domain on Azure DNS – Learn | Microsoft Docs
Azure DNS enables you to host your DNS records for your domains on Azure infrastructure. With Azure DNS, you can use the same credentials, APIs, tools, and billing as your other Azure services. DNS, or the Domain Name System, is a protocol within the TCP/IP standard. DNS serves an essential role of translating the human-readable domain names, for example, http://www.wideworldimports.com, into a known IP address. IP addresses enable computers and network devices to identify and route requests between themselves. DNS uses a global directory hosted on servers around the world. Microsoft is part of that network that provides a DNS service through Azure DNS. A DNS server carries out one of two primary functions:
- Maintains a local cache of recently accessed or used domain names and their IP addresses. This cache provides a faster response to a local domain lookup request. If the DNS server can’t find the requested domain, it passes the request to another DNS server. This process repeats at each DNS server until either a match is made, or the search times out.
- Maintains the key-value pair database of IP addresses and any host or subdomain that the DNS server has authority over. This function is often associated with mail, web, and other internet domain services.
DNS record types The configuration information for your DNS server is stored as a file within a zone on your DNS server. Each file is called a record. The following record types are the most commonly created and used:
- A is the host record, and is the most common type of DNS record. It maps the domain or host name to the IP address.
- CNAME is the canonical name, or the alias for an A record. If you had different domain names that all accessed the same website, you would use CNAME.
- MX is the mail exchange record. It maps mail requests to your mail server, whether hosted on-premises or in the cloud.
- TXT is the text record. It’s used to associate text strings with a domain name. Azure and Microsoft 365 use TXT records to verify domain ownership.
Additionally, there are the following record types:
- Wildcards
- CAA (certificate authority)
- NS (name server)
- SOA (start of authority)
- SPF (sender policy framework)
- SRV (server locations)
The SOA and NS records are created automatically when you create a DNS zone by using Azure DNS.Some record types support the concept of record sets, or resource record sets. A record set allows for multiple resources to be defined in a single record. For example, here is an A record that has one domain with two IP addresses:
Azure DNS
Azure DNS allows you to host and manage your domains by using a globally distributed name server infrastructure. It allows you to manage all of your domains by using your existing Azure credentials. Azure DNS acts as the SOA for the domain. You can’t use Azure DNS to register a domain name. You use a third-party domain registrar to register your domain. Azure DNS provides the following security features:
- Role-based access control, which gives you fine-grained control over users’ access to Azure resources. You can monitor their usage, and control the resources and services they have access to.
- Activity logs, which let you track changes to a resource, and pinpoint where faults occurred.
- Resource locking, which gives a greater level of control to restrict or remove access to resource groups, subscriptions, or any Azure resources.
Azure DNS lets you create private zones. These provide name resolution for virtual machines (VMs) within a virtual network, and between virtual networks, without having to create a custom DNS solution. Private DNS zones have the following benefits:
- There’s no need to invest in a DNS solution. DNS zones are supported as part of the Azure infrastructure.
- All DNS record types are supported: A, CNAME, TXT, MX, SOA, AAAA, PTR, and SVR.
- Host names for VMs in your virtual network are automatically maintained.
- Split-horizon DNS support allows the same domain name to exist in both private and public zones. It resolves to the correct one based on the originating request location.
The alias record set is supported in the following DNS record types: A, AAAA, CNAME
- What does Azure DNS allow you to do?
- Manage the security and access to your website.
- Register new domain names, removing the need to use a domain registrar.
- Manage and host your registered domain and associated records.
- What security features does Azure DNS provide?
- Role-based access control, activity logs, and resource locking
- Role-based access control, activity logs, and Azure threat detection
- Role-based access control, activity logs, and Azure infrastructure security
- What type of DNS record should you create to map one or more IP addresses against a single domain?
- CNAME
- A or AAAA
- SOA
You use a DNS zone to host the DNS records for a domain, such as wideworldimports.com.
Configure a public DNS zone

- Create a DNS zone in Azure: When creating a DNS zone, you need to supply the following details: Subscription, Resource group, domain Name, Resource group location
- Get your Azure DNS name servers
- Update the domain registrar setting: Changing the NS details is called domain delegation. When you delegate the domain, you must use all four name servers provided by Azure DNS.
- Verify delegation of domain name services: Verify that the delegated domain now points to the Azure DNS zone you created for the domain.
- Configure your custom DNS settings: When it’s used in a browser, the domain resolves to your website. But what if you want to add in web servers, or load balancers? These resources need to have their own custom settings in the DNS zone, either as an A record or a CNAME.
Configure private DNS zone
To provide name resolution for virtual machines (VMs) within a virtual network and between virtual networks, create a private DNS zone.
- create private dns zone
- identify virtual networks
- link your virtual network to a private dns zone
Reference
Manage and control traffic flow in your Azure deployment with routes – Learn | Microsoft Docs
Azure Routing
Network traffic in Azure is automatically routed across Azure subnets, virtual networks, and on-premises networks. This routing is controlled by system routes, which are assigned by default to each subnet in a virtual network. With these system routes, any Azure virtual machine that is deployed to a virtual network can communicate with all other Azure virtual machines in subnets in that network. These virtual machines are also potentially accessible from on-premises through a hybrid network or the internet.You can’t create or delete system routes. But you can override the system routes by adding custom routes to control traffic flow to the next hop.Every subnet has the following default system routes:
| Address Prefix | Next Hop Type |
|---|---|
| Unique to virtual network | Virtual network |
| 0.0.0.0/0 | Internet |
| 10.0.0.0/8 | None |
| 172.16.0.0/12 | None |
| 192.168.0.0/16 | None |
| 100.64.0.0 | None |
The Next hop type column shows the network path taken by traffic sent to each address prefix. The path can be one of the following hop types:
- Virtual network: A route is created in the address prefix. The prefix represents each address range created at the virtual-network level. If multiple address ranges are specified, multiple routes are created for each address range.
- Internet: The default system route 0.0.0.0/0 routes any address range to the internet, unless you override Azure’s default route with a custom route.
- None: Any traffic routed to this hop type is dropped and doesn’t get routed outside the subnet. By default, the following IPv4 private-address prefixes are created: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The prefix 100.64.0.0/10 for a shared address space is also added. None of these address ranges are globally routable.
User defined routes
You use a user-defined route to override the default system routes so that traffic can be routed through firewalls or NVAs.When creating user-defined routes, you can specify these next hop types:
- Virtual appliance: A virtual appliance is typically a firewall device used to analyze or filter traffic that is entering or leaving your network. You can specify the private IP address of a NIC attached to a virtual machine so that IP forwarding can be enabled. Or you can provide the private IP address of an internal load balancer.
- Virtual network gateway: Use to indicate when you want routes for a specific address to be routed to a virtual network gateway. The virtual network gateway is specified as a VPN for the next hop type.
- Virtual network: Use to override the default system route within a virtual network.
- Internet: Use to route traffic to a specified address prefix that is routed to the internet.
- None: Use to drop traffic sent to a specified address prefix.
Border gateway protocol
A network gateway in your on-premises network can exchange routes with a virtual network gateway in Azure by using BGP. BGP is the standard routing protocol that is normally used to exchange routing and information among two or more networks. BGP is used to transfer data and information between different host gateways like on the internet or between autonomous systems.
Route selection and priority
If multiple routes are available in a route table, Azure uses the route with the longest prefix match. For example, if a message is sent to the IP address 10.0.0.2, but two routes are available with the 10.0.0.0/16 and 10.0.0.0/24 prefixes, Azure selects the route with the 10.0.0.0/24 prefix because it’s more specific. The longer the route prefix, the shorter the list of IP addresses available through that prefix. By using longer prefixes, the routing algorithm can select the intended address more quickly. You can’t configure multiple user-defined routes with the same address prefix. If multiple routes share the same address prefix, Azure selects the route based on its type in the following order of priority:
- User-defined routes
- BGP routes
- System routes
- Why would you use a custom route in a virtual network?
- To load balance the traffic in your virtual network.
- To connect to your Azure virtual machines using RDP or SSH.
- To control the flow of traffic in your Azure virtual network.
- To connect to resources in another virtual network hosted in Azure.
- Why might you use virtual network peering?
- To connect virtual networks together in the same region or across regions.
- To assign public IP addresses to all of your resources across multiple virtual networks.
- So that load balancers can control traffic flow across your virtual networks.
- To run custom reports that scan and identify what resources are running across all of your virtual networks, as opposed to running reports on each virtual network.
Create Custom Routes
# Create a route table and custom route
az network route-table create \
--name publictable \
--resource-group [resource group name] \
--disable-bgp-route-propagation false
az network route-table route create \
--route-table-name publictable \
--resource-group [resource group name] \
--name productionsubnet \
--address-prefix 10.0.1.0/24 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address 10.0.2.4
# Create a virtual network and subnets
az network vnet create \
--name vnet \
--resource-group [resource group name] \
--address-prefix 10.0.0.0/16 \
--subnet-name publicsubnet \
--subnet-prefix 10.0.0.0/24
az network vnet subnet create \
--name privatesubnet \
--vnet-name vnet \
--resource-group [resource group name] \
--address-prefix 10.0.1.0/24
az network vnet subnet create \
--name dmzsubnet \
--vnet-name vnet \
--resource-group [resource group name] \
--address-prefix 10.0.2.0/24
az network vnet subnet list \
--resource-group [resource group name] \
--vnet-name vnet \
--output table
# Associate the route table with the public subnet
az network vnet subnet update \
--name publicsubnet \
--vnet-name vnet \
--resource-group [resource group name] \
--route-table publictable
What is an NVA?
Network virtual appliances or NVAs are virtual machines that control the flow of network traffic by controlling routing. You typically use them to manage traffic flowing from a perimeter-network environment to other networks or subnets. A network virtual appliance (NVA) is a virtual appliance that consists of various layers like: a firewall a WAN optimizer application-delivery controllers routers load balancers IDS/IPS proxies You can deploy firewall appliances into a virtual network in different configurations. You can put a firewall appliance in a perimeter-network subnet in the virtual network. Or if you want more control of security, implement a microsegmentation approach. With the microsegmentation approach, you can create dedicated subnets for the firewall and then deploy web applications and other services in other subnets. All traffic is routed through the firewall and inspected by the NVAs. You enable forwarding on the virtual-appliance network interfaces to pass traffic that is accepted by the appropriate subnet.
- What is the main benefit of using a network virtual appliance?
- To control outbound access to the internet.
- To load balance incoming traffic from the internet across multiple Azure virtual machines and across two regions for DR purposes.
- To control incoming traffic from the perimeter network and allow only traffic that meets security requirements to pass through.
- To control who can access Azure resources from the perimeter network.
- How might you deploy a network virtual appliance?
- You can configure a Windows virtual machine and enable IP forwarding after routing tables, user-defined routes, and subnets have been updated. Or you can use a partner image from Azure Marketplace.
- Using Azure CLI, deploy a Linux virtual machine in Azure, connect this virtual machine to your production virtual network, and assign a public IP address.
- Using the Azure portal, deploy a Windows 2016 Server instance. Next, using Azure Application Gateway, add the Windows 2016 Server instance as a target endpoint.
- Download a virtual appliance from Azure Marketplace and configure the appliance to connect to the production and perimeter networks.
- deploy a network virtual appliance (NVA) to secure and monitor traffic between your front-end public servers and internal private servers.
- configure the appliance to forward IP traffic. If IP forwarding isn’t enabled, traffic that is routed through your appliance will never be received by its intended destination servers.
- deploy the nva network appliance to the dmzsubnet subnet. You’ll then enable IP forwarding so that traffic from publicsubnet and traffic that uses the custom route is sent to the privatesubnet subnet.
# Deploy the network virtual appliance
az vm create \
--resource-group [resource group] \
--name nva \
--vnet-name vnet \
--subnet dmzsubnet \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password <password>
# Enable IP forwarding for the Azure network interface
# get ID of the NVA network interface
NICID=$(az vm nic list \
--resource-group [resource-group] \
--vm-name nva \
--query "[].{id:id}" --output tsv)
echo $NICID
# get the name of the NVA network interface.
NICNAME=$(az vm nic show \
--resource-group [resource-group] \
--vm-name nva \
--nic $NICID \
--query "{name:name}" --output tsv)
echo $NICNAME
# enable IP forwarding for the network interface.
az network nic update --name $NICNAME \
--resource-group [resource-group] \
--ip-forwarding true
# Enable IP forwarding in the appliance
# save the public IP address of the NVA virtual machine to the variable NVAIP.
NVAIP="$(az vm list-ip-addresses \
--resource-group [resource-group] \
--name nva \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
echo $NVAIP
# enable IP forwarding within the NVA.
ssh -t -o StrictHostKeyChecking=no azureuser@$NVAIP 'sudo sysctl -w net.ipv4.ip_forward=1; exit;
# Create public & private VM's
code cloud-init.txt
#cloud-config
package_upgrade: true
packages:
- inetutils-traceroute
# create the public virtual machine.
az vm create \
--resource-group [resource-group] \
--name public \
--vnet-name vnet \
--subnet publicsubnet \
--image UbuntuLTS \
--admin-username azureuser \
--no-wait \
--custom-data cloud-init.txt \
--admin-password <password>
# create the private vm
az vm create \
--resource-group [resource-group] \
--name private \
--vnet-name vnet \
--subnet privatesubnet \
--image UbuntuLTS \
--admin-username azureuser \
--no-wait \
--custom-data cloud-init.txt \
--admin-password <password>
# List created vm's
watch -d -n 5 "az vm list \
--resource-group [resource-group] \
--show-details \
--query '[*].{Name:name, ProvisioningState:provisioningState, PowerState:powerState}' \
--output table"
# list IP address
PUBLICIP="$(az vm list-ip-addresses \
--resource-group [resource-group] \
--name public \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
echo $PUBLICIP
# Public IP
PRIVATEIP="$(az vm list-ip-addresses \
--resource-group learn-6d2cdad4-a2f3-4664-8af3-a85655a95128 \
--name private \
--query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
--output tsv)"
echo $PRIVATEIP
# Test traffic routing through the network virtual appliance
ssh -t -o StrictHostKeyChecking=no azureuser@$PUBLICIP 'traceroute private --type=icmp; exit'
ssh -t -o StrictHostKeyChecking=no azureuser@$PRIVATEIP 'traceroute public --type=icmp; exit'
Reference
Connect your on-premises network to Azure with VPN Gateway – Learn | Microsoft Docs
A virtual private network (VPN) is a type of private interconnected network. VPNs use an encrypted tunnel within another network. They’re typically deployed to connect two or more trusted private networks to one another over an untrusted network (typically the public Internet). Traffic is encrypted while traveling over the untrusted network to prevent eavesdropping or other attacks. VPN gateways are deployed in Azure virtual networks and enable the following connectivity:
- Connect on-premises datacenters to Azure virtual networks through a site-to-site connection.
- Connect individual devices to Azure virtual networks through a point-to-site connection.
- Connect Azure virtual networks to other Azure virtual networks through a network-to-network connection.
All transferred data is encrypted in a private tunnel as it crosses the internet. You can deploy only one VPN gateway in each virtual network, but you can use one gateway to connect to multiple locations, including other Azure virtual networks or on-premises datacenters. When you deploy a VPN gateway, you specify the VPN type: either policy-based or route-based. The main difference of these two types of VPNs is how traffic to be encrypted is specified Policy-based VPNs Policy-based VPN gateways specify statically the IP address of packets that should be encrypted through each tunnel. This type of device evaluates every data packet against those sets of IP addresses to choose the tunnel where that packet is going to be sent through. Key features of policy-based VPN gateways in Azure include:
- Support for IKEv1 only.
- Use of static routing, where combinations of address prefixes from both networks control how traffic is encrypted and decrypted through the VPN tunnel. The source and destination of the tunneled networks are declared in the policy and don’t need to be declared in routing tables.
- Policy-based VPNs must be used in specific scenarios that require them, such as for compatibility with legacy on-premises VPN devices.
Route-based VPNs If defining which IP addresses are behind each tunnel is too cumbersome, route-based gateways can be used. Route-based VPNs are the preferred connection method for on-premises devices, since they are more resilient to topology changes such as the creation of new subnets. Use a route-based VPN gateway if you need any of the following types of connectivity:
- connections between virtual networks
- point-to-site connections
- multisite connections
- coexistence with an azure expressroute gateway
Key features of route-based VPNs gateways in Azure include:
- Supports IKEv2.
- Uses any-to-any (wildcard) traffic selectors.
- Can use dynamic routing protocols, where routing/forwarding tables direct traffic to different IPSec tunnels.
Basic VPN Gateway should only be used for Dev/Test workloads. In addition, it is unsupported to migrate from Basic to the VpnGW1/2/3/Az skus at a later time without having to remove the gateway and redeploy.
You’ll need these Azure resources before you can deploy an operational VPN gateway:
- Virtual network. Deploy an Azure virtual network with enough address space for the additional subnet that you’ll need for the VPN gateway. The address space for this virtual network must not overlap with the on-premises network that you’ll be connecting to. Remember that you can deploy only one VPN gateway within a virtual network.
- GatewaySubnet. Deploy a subnet called GatewaySubnet for the VPN gateway. Use at least a /27 address mask to make sure you have enough IP addresses in the subnet for future growth. You can’t use this subnet for any other services.
- Public IP address. Create a Basic-SKU dynamic public IP address if using a non-zone-aware gateway. This address provides a public-routable IP address as the target for your on-premises VPN device. This IP address is dynamic, but it won’t change unless you delete and re-create the VPN gateway.
- Local network gateway. Create a local network gateway to define the on-premises network’s configuration: where the VPN gateway will connect and what it will connect to. This configuration includes the on-premises VPN device’s public IPv4 address and the on-premises routable networks. This information is used by the VPN gateway to route packets that are destined for on-premises networks through the IPSec tunnel.
- Virtual network gateway. Create the virtual network gateway to route traffic between the virtual network and the on-premises datacenter or other virtual networks. The virtual network gateway can be either a VPN or ExpressRoute gateway, but this module deals only with VPN virtual network gateways.
- Connection. Create a Connection resource to create a logical connection between the VPN gateway and the local network gateway.
Active / Standby
by default, vpn gateways are deployed as two instances in an active/standby configuration, even if you only see one vpn gateway resource in azure. when planned maintenance or unplanned disruption affects the active instance, the standby instance automatically assumes responsibility for connections without any user intervention. connections are interrupted during this failover, but they’re typically restored within a few seconds for planned maintenance and within 90 seconds for unplanned disruptions.
Active / Active
With the introduction of support for the BGP routing protocol, you can also deploy VPN gateways in an active/active configuration. In this configuration, you assign a unique public IP address to each instance. You then create separate tunnels from the on-premises device to each IP address. You can extend the high availability by deploying an additional VPN device on-premises.
Another high availability option is to configure a VPN gateway as a secure failover path for ExpressRoute connections. ExpressRoute circuits have resiliency built in but aren’t immune to physical problems that affect the cables delivering connectivity or outages affecting the complete ExpressRoute location. In high availability scenarios, where there’s risk associated with an outage of an ExpressRoute circuit, you can also provision a VPN gateway which uses the internet as an alternative method of connectivity, thus ensuring there’s always a connection to the Azure virtual networks. In regions that support availability zones, VPN and ExpressRoute gateways can be deployed in a zone-redundant configuration. This brings resiliency, scalability, and higher availability to virtual network gateways. Deploying gateways in Azure Availability Zones physically and logically separates gateways within a region, while protecting your on-premises network connectivity to Azure from zone-level failures. These require different gateway SKUs and leverage Standard public IP addresses instead of Basic public IP addresses.
Prepare Azure and on-premises virtual networks by using Azure CLI commands
# Create the Azure-side resources
az network vnet create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name Azure-VNet-1 \
--address-prefix 10.0.0.0/16 \
--subnet-name Services \
--subnet-prefix 10.0.0.0/24
# Add the GatewaySubnet subnet to Azure-VNet-1.
az network vnet subnet create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--vnet-name Azure-VNet-1 \
--address-prefix 10.0.255.0/27 \
--name GatewaySubnet
# create the LNG-HQ-Network local network gateway.
az network local-gateway create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--gateway-ip-address 94.0.252.160 \
--name LNG-HQ-Network \
--local-address-prefixes 172.16.0.0/16
# Create the simulated on-premises network and supporting resources
# create the HQ-Network virtual network and the Applications subnet.
az network vnet create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name HQ-Network \
--address-prefix 172.16.0.0/16 \
--subnet-name Applications \
--subnet-prefix 172.16.0.0/24
# add GatewaySubnet to HQ-Network.
az network vnet subnet create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--address-prefix 172.16.255.0/27 \
--name GatewaySubnet \
--vnet-name HQ-Network
# create the LNG-Azure-VNet-1 local network gateway.
az network local-gateway create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--gateway-ip-address 94.0.252.160 \
--name LNG-Azure-VNet-1 \
--local-address-prefixes 10.0.0.0/16
# Verify the topology
az network vnet list --output table
az network local-gateway list \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--output table
Diagram shows the resources that you’ve deployed:
# Create the Azure-side VPN gateway
# create the PIP-VNG-HQ-Network public IP address
az network public-ip create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name PIP-VNG-HQ-Network \
--allocation-method Dynamic
# create the VNG-Azure-VNet-1 virtual network gateway.
az network vnet-gateway create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name VNG-Azure-VNet-1 \
--public-ip-address PIP-VNG-Azure-VNet-1 \
--vnet Azure-VNet-1 \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw1 \
--no-wait
# Create the on-premises VPN gateway
# create the PIP-VNG-HQ-Network public IP address
az network public-ip create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name PIP-VNG-HQ-Network \
--allocation-method Dynamic
# create the VNG-HQ-Network virtual network gateway
az network vnet-gateway create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name VNG-HQ-Network \
--public-ip-address PIP-VNG-HQ-Network \
--vnet HQ-Network \
--gateway-type Vpn \
--vpn-type RouteBased \
--sku VpnGw1 \
--no-wait
# Use the Linux watch command to run the az network vnet-gateway list command periodically, which allows you to monitor the progress.
watch -d -n 5 az network vnet-gateway list \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--output table
# check whether both virtual network gateways have been created:
az network vnet-gateway list \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--query "[?provisioningState=='Succeeded']" \
--output table
# retrieve the IPv4 address assigned to PIP-VNG-Azure-VNet-1 and store it in a variable.
PIPVNGAZUREVNET1=$(az network public-ip show \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name PIP-VNG-Azure-VNet-1 \
--query "[ipAddress]" \
--output tsv)
# update the LNG-Azure-VNet-1 local network gateway so that it points to the public IP address attached to the VNG-Azure-VNet-1 virtual network gateway.
az network local-gateway update \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name LNG-Azure-VNet-1 \
--gateway-ip-address $PIPVNGAZUREVNET1
# retrieve the IPv4 address assigned to PIP-VNG-HQ-Network and store it in a variable.
PIPVNGHQNETWORK=$(az network public-ip show \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name PIP-VNG-HQ-Network \
--query "[ipAddress]" \
--output tsv)
# update the LNG-HQ-Network local network gateway so that it points to the public IP address attached to the VNG-HQ-Network virtual network gateway.
az network local-gateway update \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name LNG-HQ-Network \
--gateway-ip-address $PIPVNGHQNETWORK
# create a connection from VNG-Azure-VNet-1 to LNG-HQ-Network.
az network vpn-connection create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name Azure-VNet-1-To-HQ-Network \
--vnet-gateway1 VNG-Azure-VNet-1 \
--shared-key $SHAREDKEY \
--local-gateway2 LNG-HQ-Network
# create a connection from VNG-HQ-Network to LNG-Azure-VNet-1.
az network vpn-connection create \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name HQ-Network-To-Azure-VNet-1 \
--vnet-gateway1 VNG-HQ-Network \
--shared-key $SHAREDKEY \
--local-gateway2 LNG-Azure-VNet-1
# Verification steps
az network vpn-connection show \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name Azure-VNet-1-To-HQ-Network \
--output table \
--query '{Name:name,ConnectionStatus:connectionStatus}'
az network vpn-connection show \
--resource-group learn-db52804a-1848-4b3d-accb-f9de93870481 \
--name HQ-Network-To-Azure-VNet-1 \
--output table \
--query '{Name:name,ConnectionStatus:connectionStatus}'
Reference
Introduction – Learn | Microsoft Docs
ExpressRoute overview
Azure ExpressRoute lets you seamlessly extend your on-premises networks into the Microsoft cloud. This connection between your organization and Azure is dedicated and private. Establishing an ExpressRoute connection enables you to connect to Microsoft cloud services like Azure, Office 365, and Dynamics 365. Security is enhanced, connections are more reliable, latency is minimal, and throughput is greatly increased.
Features and benefits of ExpressRoute
- Layer 3 connectivity: ExpressRoute provides Layer 3 (address-level) connectivity between your on-premises network and the Microsoft cloud through connectivity partners.
- Built-in redundancy: Each connectivity provider uses redundant devices to ensure that connections established with Microsoft are highly available.
- Connectivity to Microsoft cloud services
- Across on-premises connectivity with ExpressRoute Global Reach
- Dynamic routing: uses the Border Gateway Protocol (BGP) routing protocol. BGP is used to exchange routes between on-premises networks and resources running in Azure. This protocol enables dynamic routing between your on-premises network and services running in the Microsoft cloud.
ExpressRoute connectivity models
- What is the Azure ExpressRoute service?
- It’s a service that provides a VPN connection between on-premises and the Microsoft cloud.
- It’s a service that encrypts your data in transit.
- It’s a service that provides a direct connection from your on-premises datacenter to the Microsoft cloud.
- It’s a service that provides a site-to-site VPN connection between your on-premises network and the Microsoft cloud.
- Which of the following is not a benefit of ExpressRoute?
- Redundant connectivity
- Consistent network throughput
- Encrypted network communication
- Access to Microsoft cloud services
Prerequisites for ExpressRoute
- An ExpressRoute connectivity partner or cloud exchange provider
- Azure subscription that is registered with your chosen ExpressRoute connectivity partner.
- active Microsoft Azure account
- active Office 365 subscription, if you want to connect to the Microsoft cloud
- Ensure that BGP sessions for routing domains have been configured.
- You or your providers need to translate the private IP addresses used on-premises to public IP addresses by using a NAT service. Microsoft will reject anything except public IP addresses through Microsoft peering.
- Reserve several blocks of IP addresses in your network for routing traffic to the Microsoft cloud.
ExpressRoute supports two peering schemes:
- Use private peering to connect to Azure IaaS and PaaS services deployed inside Azure virtual networks. The resources that you access must all be located in one or more Azure virtual networks with private IP addresses. You can’t access resources through their public IP address over a private peering.
- Use Microsoft peering to connect to Azure PaaS services, Office 365 services, and Dynamics 365.
High availability and failover with ExpressRoute
In each ExpressRoute circuit, there are two connections from the connectivity provider to two different Microsoft edge routers. This configuration occurs automatically. It provides a degree of availability within a single location. Consider setting up ExpressRoute circuits in different peering locations to provide high availability and help protect against a regional outage. You can also have multiple circuits across different providers to ensure that your network stays available even if an outage affects all circuits from a single approved provider. You can set the Connection Weight property to prefer one circuit to another.
ExpressRoute Direct and FastPath
Microsoft also provides an ultra-high-speed option called ExpressRoute Direct. This service enables dual 100-Gbps connectivity. It’s suitable for scenarios that involve massive and frequent data ingestion. It’s also suitable for solutions that require extreme scalability, such as banking, government, and retail. ExpressRoute Direct supports FastPath. When FastPath is enabled, it sends network traffic directly to a virtual machine that’s the intended destination. The traffic bypasses the virtual network gateway, improving the performance between Azure virtual networks and on-premises networks. FastPath doesn’t support virtual network peering (where you have virtual networks connected together). It also doesn’t support user-defined routes on the gateway subnet.
Alternatives to ExpressRoute
- Site-to-site VPN: Azure site-to-site VPN connection enables you to connect your on-premises network to Azure over an IPsec tunnel to build a hybrid network solution.
- Point-to-site VPN: With point-to-site VPN, you can establish a secure connection to a network from individual computers located on-premises.
- What is Microsoft peering?
- It provides a direct connection from your on-premises network to an Azure datacenter.
- It enables you to connect your on-premises network to Office 365 services and Dynamics 365.
- It provides a connection between your on-premises network and an ExpressRoute provider.
- It provides a point-to-site connection for computers in your on-premises location to Office 365 services.
- What is an ExpressRoute circuit?
- An ExpressRoute circuit implements a site-to-site connection across a VPN connection to an Azure datacenter.
- An ExpressRoute circuit is a direct hard-wired connection between your on-premises datacenter and an Azure datacenter.
- A backup service that provides connectivity to the Microsoft cloud if your VPN connection fails.
- A circuit provides a physical connection for transmitting data through the ExpressRoute provider’s edge routers to the Microsoft edge routers.
- What security benefits does Azure ExpressRoute provide?
- An ExpressRoute connection is automatically encrypted, to help protect traffic that passes across the internet to the Microsoft cloud.
- The speed at which data traverses an ExpressRoute connection makes it impossible to intercept by network monitors and packet sniffers.
- ExpressRoute uses a dedicated, private network to connect to the Microsoft cloud. Traffic doesn’t traverse the public internet, so it’s difficult to intercept.
- ExpressRoute uses a proprietary transmission protocol that constantly varies, so it’s difficult to intercept traffic.
- When should you use Azure ExpressRoute instead of Azure site-to-site connectivity?
- For handling enterprise-class and mission-critical workloads.
- For connecting mobile users directly to your virtual network running in Azure.
- For handling small-scale production workloads running on Azure virtual machines.
- To save connection costs for occasionally connected users to the Microsoft cloud.
- Which connection type supports connectivity to Office 365?
- Point-to-site over a VPN connection through an Azure network gateway.
- Site-to-site over a VPN connection through an Azure network gateway.
- An ExpressRoute connection.
Reference
Load balance your web service traffic with Application Gateway – Learn | Microsoft Docs
How Application Gateway routes requests
Clients send requests to your web apps to the IP address or DNS name of the gateway. The gateway routes requests to a selected web server in the back-end pool, using a set of rules configured for the gateway to determine where the request should go. There are two primary methods of routing traffic, path-based routing and multiple site hosting. Let’s take a look at the capabilities for each.

Path-based routing: Path-based routing enables you to send requests with different paths in the URL to a different pool of back-end servers. Multiple site hosting: enables you to configure more than one web application on the same application gateway instance. In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the Application Gateway, specifying the name of each site. Application Gateway uses separate listeners to wait for requests for each site. Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool.
Other routing capabilities
- Redirection – Redirection can be used to another site, or from HTTP to HTTPS.
- Rewrite HTTP headers – HTTP headers allow the client and server to pass additional information with the request or the response.
- Custom error pages – Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.
Load balancing in Application Gateway
Application Gateway will automatically load balance requests sent to the servers in each back-end pool using a round-robin mechanism. However, you can configure session stickiness, if you need to ensure that all requests for a client in the same session are routed to the same server in a back-end pool. Load-balancing works with the OSI Layer 7 routing implemented by Application Gateway routing, which means that it load balances requests based on the routing parameters (host names and paths) used by the Application Gateway rules. Operating at OSI Layer 7 enables load balancing to take advantage of the other features that Application Gateway provides. These features include:
- Support for the HTTP, HTTPS, HTTP/2 and WebSocket protocols.
- A web application firewall to protect against web application vulnerabilities.
- End-to-end request encryption.
- Autoscaling, to dynamically adjust capacity as your web traffic load changes.
- Which criteria does Application Gateway use to route requests to a web server?
- The IP address of the web server that is the target of the request
- The region in which the servers hosting the web application are located.
- The hostname, port, and path in the URL of the request
- Which load balancing strategy does Application Gateway implement?
- Application Gateway selects the server in the backend pool that currently has the lightest load.
- Application Gateway polls each server in the backend pool in turn, and sends the request to the first server that responds.
- Application Gateway follows a round-robin approach, distributing requests to each available server in a backend pool in turn.


# Create virtual machines and deploy the vehicle registration site
RG=loadbalanceAppGW
az group create --name $RG --location eastus
az network vnet create \
--resource-group $RG \
--name vehicleAppVnet \
--address-prefix 10.0.0.0/16 \
--subnet-name webServerSubnet \
--subnet-prefix 10.0.1.0/24
git clone https://github.com/MicrosoftDocs/mslearn-load-balance-web-traffic-with-application-gateway module-files
#
az vm create \
--resource-group $RG \
--name webServer1 \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--vnet-name vehicleAppVnet \
--subnet webServerSubnet \
--public-ip-address "" \
--nsg "" \
--custom-data module-files/scripts/vmconfig.sh \
--no-wait
az vm create \
--resource-group $RG \
--name webServer2 \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--vnet-name vehicleAppVnet \
--subnet webServerSubnet \
--public-ip-address "" \
--nsg "" \
--custom-data module-files/scripts/vmconfig.sh
az vm list \
--resource-group $RG \
--show-details \
--output table
APPSERVICE="licenserenewal$RANDOM"
az appservice plan create \
--resource-group $RG \
--name vehicleAppServicePlan \
--sku S1
az webapp create \
--resource-group $RG \
--name $APPSERVICE \
--plan vehicleAppServicePlan \
--deployment-source-url https://github.com/MicrosoftDocs/mslearn-load-balance-web-traffic-with-application-gateway \
--deployment-source-branch appService --runtime "DOTNETCORE|2.1"
az vm list \
--resource-group $RG \
--show-details \
--output table
# Create App Service and deploy the license renewal site
APPSERVICE="licenserenewal$RANDOM"
az appservice plan create \
--resource-group $RG \
--name vehicleAppServicePlan \
--sku S1
az webapp create \
--resource-group $RG \
--name $APPSERVICE \
--plan vehicleAppServicePlan \
--deployment-source-url https://github.com/MicrosoftDocs/mslearn-load-balance-web-traffic-with-application-gateway \
--deployment-source-branch appService --runtime "DOTNETCORE|2.1"

Application Gateway creation and configuration
Application Gateway comprises a series of components that combine to route requests to a pool of web servers and to check the health of these web servers. Let’s take a look at how these components are related and what role they play in an Application Gateway.
Front-end IP address: Client requests are received through a front-end IP address. You can configure Application Gateway to have a public IP address, a private IP address, or both. Application Gateway can’t have more than one public and one private IP address. Listeners: Application Gateway uses one or more listeners to receive incoming requests. A listener accepts traffic arriving on a specified combination of protocol, port, host, and IP address. Each listener routes requests to a back-end pool of servers following routing rules that you specify. A listener can be Basic or Multi-site. A Basic listener only routes a request based on the path in the URL. A Multi-site listener can also route requests using the hostname element of the URL. Routing rules: A routing rule binds a listener to the back-end pools. A rule specifies how to interpret the hostname and path elements in the URL of a request, and direct the request to the appropriate back-end pool. A routing rule also has an associated set of HTTP settings. These settings indicate whether (and how) traffic is encrypted between Application Gateway and the back-end servers, and other configuration information such as:
- Protocol (HTTP or HTTPS).
- Session stickiness, to pass all requests in a client session to the same web server rather than distributing them across servers with load balancing.
- Connection draining, to enable the graceful removal of servers from a back-end pool.
- Request timeout period, in seconds.
- Health probes, specifying a probe URL, time out periods, and other parameters used to determine whether a server in the back-end pool is available.
Back-end pools: A back-end pool references a collection of web servers. You provide the IP address of each web server and the port on which it listens for requests when configuring the pool. Web application firewall: The web application firewall (WAF) is an optional component that handles incoming requests before they reach a listener. The web application firewall checks each request for many common threats, based on the Open Web Application Security Project (OWASP). These include:
- SQL-injection
- Cross-site scripting
- Command injection
- HTTP request smuggling
- HTTP response splitting
- Remote file inclusion
- Bots, crawlers, and scanners
- HTTP protocol violations and anomalies
Health probes: Health probes are an important part in assisting the load balancer to determine which servers are available for load balancing in a back-end pool. Application Gateway uses a health probe to send a request to a server. If the server returns an HTTP response with a status code between 200 and 399, the server is deemed healthy.
Create and configure an Application Gateway
Exercise – Create and configure Application Gateway – Learn | Microsoft Docs
# Configure the network for Application Gateway
az network vnet subnet create \
--resource-group $RG \
--vnet-name vehicleAppVnet \
--name appGatewaySubnet \
--address-prefixes 10.0.0.0/24
az network public-ip create \
--resource-group $RG \
--name appGatewayPublicIp \
--sku Standard \
--dns-name vehicleapp${RANDOM}
# Create an application gateway
# A back-end pool containing the IP addresses of the web server virtual machines.
# A firewall that blocks malicious requests, such as those used by SQL Injection and Cross-Site Scripting attacks.
# A temporary listener that listens to port 8080, this will be replaced in a later step but is required for Application Gateway creation.
# A rule that routes (and load balances) these requests to the web servers in the back-end pool.
az network application-gateway create \
--resource-group $RG \
--name vehicleAppGateway \
--sku WAF_v2 \
--capacity 2 \
--vnet-name vehicleAppVnet \
--subnet appGatewaySubnet \
--public-ip-address appGatewayPublicIp \
--http-settings-protocol Http \
--http-settings-port 8080 \
--private-ip-address 10.0.0.4 \
--frontend-port 8080
az vm list-ip-addresses \
--resource-group $RG \
--name webServer1 \
--query [0].virtualMachine.network.privateIpAddresses[0] \
--output tsv
az vm list-ip-addresses \
--resource-group $RG \
--name webserver2 \
--query [0].virtualMachine.network.privateIpAddresses[0] \
--output tsv
# add the back-end pools for each web site. First, create the back-end pool for the vehicle registration site running on virtual machines.
az network application-gateway address-pool create \
--gateway-name vehicleAppGateway \
--resource-group $RG \
--name vmPool \
--servers 10.0.1.4 10.0.1.5
az network application-gateway address-pool create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name appServicePool \
--servers $APPSERVICE.azurewebsites.net
# For port 80, create a front-end port.
az network application-gateway frontend-port create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name port80 \
--port 80
# To handle requests on port 80, create the listener.
az network application-gateway http-listener create \
--resource-group $RG \
--name vehicleListener \
--frontend-port port80 \
--frontend-ip appGatewayFrontendIP \
--gateway-name vehicleAppGateway
# Add a health probe
az network application-gateway probe create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name customProbe \
--path / \
--interval 15 \
--threshold 3 \
--timeout 10 \
--protocol Http \
--host-name-from-http-settings true
az network application-gateway http-settings create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name appGatewayBackendHttpSettings \
--host-name-from-backend-pool true \
--port 80 \
--probe customProbe
# Configure path-based routing
az network application-gateway url-path-map create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name urlPathMap \
--paths /VehicleRegistration/* \
--http-settings appGatewayBackendHttpSettings \
--address-pool vmPool
az network application-gateway url-path-map rule create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name appServiceUrlPathMap \
--paths /LicenseRenewal/* \
--http-settings appGatewayBackendHttpSettings \
--address-pool appServicePool \
--path-map-name urlPathMap
az network application-gateway rule create \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name appServiceRule \
--http-listener vehicleListener \
--rule-type PathBasedRouting \
--address-pool appServicePool \
--url-path-map urlPathMap
# delete the rule that was created when we initially deployed the Application Gateway. With your custom rule in place, you no longer need it.
az network application-gateway rule delete \
--resource-group $RG \
--gateway-name vehicleAppGateway \
--name rule1
# Test load balancing for the vehicle registration web app
echo http://$(az network public-ip show \
--resource-group $RG \
--name appGatewayPublicIp \
--query dnsSettings.fqdn \
--output tsv)
# Use a browser to navigate to the URL
# Click Register a Vehicle, enter the details of a vehicle, and then click Register.
# Click Refresh in the address bar of the web browser. Notice that your session should now be connected to a different web server. In this configuration, Application Gateway uses round-robin load balancing.
# Click Refresh a few more times. The requests should oscillate between servers.
# Test the resilience of Application Gateway to a failed server
az vm deallocate \
--resource-group $RG \
--name webServer1
az vm start \
--resource-group $RG \
--name webServer1
Reference
Improve application scalability and resiliency by using Azure Load Balancer – Learn | Microsoft Docs
Load Balancer (LB) vs. Application Gateway (AG)
| LB | AG |
|---|---|
| ALB works with traffic at Layer 4 | Application Gateway handles just Layer 7 traffic |
| Load Balancer is free | Application Gateway is billed per-hour, and has two tiers, depending on features you need (with/without WAF) |
| Azure Load Balancer provides basic load balancing based on 2 or 5 tuple matches. | Application Gateway supports SSL termination, URL-based routing, multi-site routing, Cookie-based session affinity and Web Application Firewall (WAF) features. |
| Load Balancer only supports endpoints hosted in Azure | Application Gateway can support any routable IP address. |
Azure Load Balancer is a service you can use to distribute traffic across multiple virtual machines. Use Load Balancer to scale applications and create high availability for your virtual machines and services. Load balancers use a hash-based distribution algorithm. By default, a five-tuple hash is used to map traffic to available servers. The hash is made from the following elements:
- Source IP: The IP address of the requesting client.
- Source port: The port of the requesting client.
- Destination IP: The destination IP of the request.
- Destination port: The destination port of the request.
- Protocol type: The specified protocol type, TCP or UDP.
Two products are available when you create a load balancer in Azure: basic load balancers and standard load balancers. Basic load balancers can be used only with availability sets. Standard load balancer can be used with availability zones
- What is the default distribution type for traffic through a load balancer?
- Source IP affinity
- Five-tuple hash
- Three-tuple hash
- What is the main advantage of an availability set?
- It allows virtual machines to be available across datacenter failures.
- It allows virtual machines to be available across physical server failures.
- It allows virtual machines to be grouped into logical categories.

Distribution modes
By default, Azure Load Balancer distributes network traffic equally among virtual machine instances. The following distribution modes are also possible if a different behavior is required:
- Five-tuple hash. The default distribution mode for Load Balancer is a five-tuple hash. The tuple is composed of the source IP, source port, destination IP, destination port, and protocol type. Because the source port is included in the hash and the source port changes for each session, clients might be directed to a different virtual machine for each session.
- Source IP affinity. This distribution mode is also known as session affinity or client IP affinity. To map traffic to the available servers, the mode uses a two-tuple hash (from the source IP address and destination IP address) or three-tuple hash (from the source IP address, destination IP address, and protocol type). The hash ensures that requests from a specific client are always sent to the same virtual machine behind the load balancer.
- Which configuration is required to configure an internal load balancer?
- Virtual machines should be in the same virtual network.
- Virtual machines must be publicly accessible.
- Virtual machines must be in an availability set.
- Which of the following statement about external load balancers is correct?
- They have a private, front-facing IP address.
- They don’t have a listener IP address.
- They have a public IP address.

Reference
Troubleshoot inbound network connectivity for Azure Load Balancer – Learn | Microsoft Docs
Azure Load Balancer includes a number of components:
- A front-end IP address
- A back-end pool of VM addresses
- One or more routing rules
- A health probe
- A collection of VMs, typically in a virtual network
Load Balancer provides a transparent, end-to-end connection from a client to an application that runs on a collection of VMs. Load Balancer stores the IP addresses of these VMs in a repository commonly referred to as a back-end pool. Load Balancer exposes its own front-end IP address to clients. When a client sends a request to this address, Load Balancer selects the IP address of a VM from the back-end pool. Load Balancer then routes the request through this back-end IP address to the VM. The payload of messages sent from the client to the VM are opaque to Load Balancer. Load Balancer doesn’t examine the contents of any messages or manipulate them. It readdresses messages so that they’re sent to the selected VM.
Scalability You can start additional VM instances and add their IP addresses to the back-end pool at any time. Load Balancer includes these new instances when it distributes user requests. Load Balancer can expose more than one public front-end IP address, and might have multiple back-end pools. This scheme enables you to reuse the same instance of Load Balancer to handle requests for different systems.
Routing rules You define load-balancing rules to specify how requests directed toward each front-end IP address are mapped to a back-end pool. A load-balancing rule also specifies the protocol to match against, and optionally the source (client) and destination ports. Incoming requests arriving on a front-end IP address that don’t match the protocol and port requirements are discarded by Load Balancer. A load-balancing rule can also configure session persistence so that a given client is likely to have its requests routed to the same VM.
Health probes Load Balancer needs to determine whether each VM referenced by the back-end pool is available for handling requests. You add a health probe to do this. A health probe sends regular ping messages to a port that you specify for the VMs in the back-end pool. You provide a service on the VMs that responds to these ping messages, with an HTTP 200 (OK) message. When the VM fails to respond after a specified number of attempts, Load Balancer assumes it’s unhealthy and removes it from the list of VMs that can accept user requests. The workload is then distributed among the remaining healthy VMs. Load Balancer continues to ping an unresponsive VM. If the VM starts to reply, it’s added back into the list of healthy VMs and starts receiving user requests again.
Virtual network The VMs referenced by the back-end pool are typically in a virtual network subnet, hosted by Azure. You protect the VMs in this network by configuring a network security group (NSG). An NSG implements inbound and outbound security rules that can limit the traffic entering and exiting the virtual network to a set of well-defined endpoints.
- What happens if a health probe isn’t configured and a VM fails?
- Azure Load Balancer won’t notice the failure and continues to route traffic to the failed VM. This issue causes requests to time out.
- Load Balancer removes the VM from the back-end pool.
- Load Balancer doesn’t know which VM has failed and so stops sending requests to all VMs in the back-end pool.
- You closed a port in a network security group used by a virtual network that hosts the VMs in the Load Balancer pool. How might this affect load balancing?
- If one is available, Load Balancer attempts to use a different port. Requests are sent to VMs through this port instead.
- If the port is used to send traffic to the VMs in the pool, then this traffic is blocked. All requests time out and eventually fail. If this port was a probe port, the VM is removed from rotation.
- Load Balancer queues client requests until the port is opened again. At that point, the requests are sent.
You can visualize metrics for Load Balancer by using the Metrics page in the Azure portal. From a connectivity troubleshooting perspective, the most important metrics are Data Path Availability and Health Probe Status.
- The PsPing command tests ping connectivity through an endpoint. This command also measures the latency and bandwidth availability to a service.
- The tcping utility is similar to ping except that it operates over a TCP connection instead of ICMP, which Load Balancer doesn’t route.
- The netsh utility is a general-purpose network configuration tool. Use the trace command in netsh to capture network traffic.
- What does the average Health Probe Status metric indicate?
- The number of virtual machines in the back-end pool that are responding to health probe requests.
- The percentage of virtual machines in the back-end pool that are responding to health probe requests.
- The number of virtual machines available that will respond to client requests.
- You’re monitoring the average packet count metric for a load balancer. The average packet count suddenly increases by a significant amount, although the number of clients doesn’t appear to have changed. What is the most probable cause?
- Additional virtual machines have become available in the back-end pool.
- The load balancing rule has stopped directing traffic to one or more virtual machines in the back-end pool.
- One or more virtual machines in the back-end pool are no longer responding to health probe requests and are no longer participating in load balancing.
Reference
Introduction – Learn | Microsoft Docs
What is Network Watcher
Network Watcher is an Azure service that combines tools in a central place to diagnose the health of Azure networks. The Network Watcher tools are divided into two categories:
- Monitoring tools
- Diagnostic tools
Network Watchers provides three monitoring tools:
- topology: The topology tool generates a graphical display of your Azure virtual network, its resources, its interconnections, and their relationships with each other.
- connection monitor: The Connection Monitor tool provides a way to check that connections work between Azure resources. To check that two VMs can communicate if you want them to, use this tool. This tool also measures the latency between resources. It can catch changes that will affect connectivity, such as changes to the network configuration or changes to network security group (NSG) rules. It can probe VMs at regular intervals to look for failures or changes.
- network performance monitor: The Network Performance Monitor tool enables you to track and alert on latency and packet drops over time. It gives you a centralized view of your network.
Network Watcher includes six diagnostic tools:
- IP flow verify:The IP flow verify tool tells you if packets are allowed or denied for a specific virtual machine. If a network security group denies a packet, the tool tells you the name of that group so that you can fix the problem.
- Next hop: When a VM sends a packet to a destination, it might take multiple hops in its journey. For example, if the destination is a VM in a different virtual network, the next hop might be the virtual network gateway that routes the packet to the destination VM.
- Effective security rules: The effective security rules tool in Network Watcher displays all the effective NSG rules applied to a network interface. Network security groups (NSGs) are used in Azure networks to filter packets based on their source and destination IP address and port numbers. NSGs are vital to security because they help you carefully control the surface area of the VMs that users can access. Keep in mind, though, that a mistakenly configured NSG rule might prevent legitimate communication. As a result, NSGs are a frequent source of network problems.
- Packet capture: You use the packet capture tool to record all of the packets sent to and from a VM. You’ll then review the captured to gather statistics about network traffic or diagnose anomalies, such as unexpected network traffic on a private virtual network. The packet capture tool is a virtual machine extension that is remotely started through Network Watcher and happens automatically when you start a packet capture session.
- Connection troubleshoot: You use the connection troubleshoot tool to check TCP connectivity between a source and destination VM. You can specify the destination VM by using an FQDN, a URI, or an IP address. If the connection is successful, information about the communication is displayed, including: The latency in milliseconds. The number of probe packets sent. The number of hops in the complete route to the destination.
- VPN troubleshoot: You can use the VPN troubleshoot tool to diagnose problems with virtual network gateway connections. This tool runs diagnostics on a virtual network gateway connection and returns a health diagnosis.
- To capture traffic on a VM, Azure Network Watcher requires:
- Network Watcher Agent VM Extension
- Azure Traffic Manager
- An Azure storage account
- To resolve latency issues on the network, which Azure Network Watcher features can you use?
- IP flow verify
- Next hop
- Connection troubleshoot

Answer Key
- c. Use virtual network peering to connect virtual networks to each other so resources in either virtual network can communicate with each other. The virtual networks you connect can be in different Azure regions. Incorrect answer expl: a) ExpressRoute allows you to extend your on-premises networks into the Microsoft Cloud over a private connection implemented by a connectivity provider. B) An Azure virtual network gateway provides an endpoint for incoming connections from on-premises locations to Azure over the Internet.
- b. Use the PowerShell cmdlet ‘New-AzVirtualNetworkGateway’ where you use parameters ‘-GatewayType Vpn’ and ‘-VpnType RouteBased’. Also set the ‘-GatewaySku’ to the SKU that meets your organization’s network requirements. Incorrect answers: a) Those are key parameters but you also need to specify a gateway sku. The default is VpnGw1. If that SKU doesn’t meet your organization’s needs, you’d have to recreate the VPN gateway with the SKU that meets your organization’s network requirements. C) You must create a gateway subnet with the name GatewaySubnet in order for the VPN gateway to function properly. But when you create the VPN gateway with the cmdlet ‘New-AzVirtualNetworkGateway’, you specify the ‘-IpConfigurations’ for that subnet.
- b. Azure private peering lets you directly connect to virtual machines and cloud services on their private IP addresses. Incorrect answers: a) Virtual network peering allows you to connect networks in Azure Virtual Network. C) Microsoft peering supports connections to cloud-based SaaS offerings, such as Microsoft 365 and Dynamics 365.
- b. Border Gateway Protocol is an industry-standard dynamic routing protocol that can exchange routes between your on-premises network, your instances in Azure, and Microsoft public addresses. Incorrect Answers: a) An Any-to-any (IPVPN) network is a connectivity model that ExpressRoute supports. C) An s-key is a GUID that defines an ExpressRoute circuit and provides the connectivity link between Microsoft, your connectivity provider, and your organization.
- b. A dedicated subnet assigns an IP address to devices connected through the tunnel. You must have a dedicated subnet named GatewaySubnet for the VPN gateway.Incorrect Answers: a) A VPN can connect through the internet. You do not need to have a leased line. C) A network security group is used to filter traffic. They are not required when you connect an on-premises network to a virtual network. 
- 2
- a. You can assign public IP addresses to virtual machines.
- c. An IP address is assigned to a network interface, which is assigned to a virtual machine. Incorrect Answers a) Load balancers distribute traffic between virtual machines and are not required for communication within a virtual network. B) Although network security groups are recommended to filter traffic, they are not required to communicate within a virtual network.
- c. Custom routes are used to override the default Azure routing so that you can route traffic through a network virtual appliance (NVA).
- a. Virtual network peering is used to connect multiple virtual networks together. Once peered, the networks become one network, and resources across virtual networks can communicate with one another.
- Azure Bastion is a fully managed PaaS service. It provides seamless RDP/SSH access to VMs over the internet without requiring the installation of connection software like Remote Desktop.
- An Azure Bastion host supports RDP and SSH connections for VMs within the same virtual network or a peered virtual network.
- Create a subnet named AzureBastionSubnet for the virtual network; create a public IP; and then create the Azure Bastion resource with the virtual network and public IP address information.
- You connect to internal VMs by using the public IP of Azure Bastion, not a public IP on the destination VM.
- Use Azure RBAC to apply the least privilege to use Azure Bastion. Apply just the reader role on the Azure Bastion resource, on the virtual machine, and on the NIC with the private IP of the virtual machine.
- Azure DNS allows you to host your registered domains. You can control and configure the domain records, like A, CNAME, MX, and setup alias records.
- Azure DNS is built on Azure Resource Manager, which provides security across all resources in Azure DNS.
- The A or AAAA record maps an IP address to a domain. Multiple IP addresses are known as a record set.
- A network virtual appliance acts like a firewall. It checks all inbound and outbound traffic, and it secures your environment by allowing or denying the traffic.
- Customers often create network virtual appliances. And you can download many appliances from Azure Marketplace.
- c
- c
- b
- d
- c
- a
- c
- C
- C
- b
- b. Availabilty sets allow virtual machines to remain available when a physical server fails.
- a. The virtual machines that you use a load balancer to distribute a load to must be in the same virtual network.
- C. External load balancers have public IP addresses.
- a.
- b. Traffic is blocked and all requests time out and eventually fail unless this port was a probe port. In that case, the VM is removed from rotation.
- b.
- C.
- a. The Network Watcher Agent VM Extension is required when you capture traffic on a VM. It’s automatically installed when you start a packet capture session in the Azure portal.
- C. Connection troubleshoot displays the latency associated with each hop in a route.
Life Less Ordinary 
Leave a Reply