Azure Virtual Network (VNet) Basics – Part 1

Introduction of Azure Virtual Network:
Azure Virtual Network (VNet) is a logically isolated network in Azure, Azure VNets are basically Layer 3 overlay network that are implemented by Azure’s SDN stack. Each Azure VNets runs on same underlying shared physical network infrastructure however they are fully isolated from each other. Azure Networking stack uses VXLAN technology underlying to facilitate all these.
VNET is the foundation of customer’s infrastructure in Azure cloud, you would require to plan and design VNET before you deploy any resources in Azure because it’s the VNET that will facilitate network communication for the resources deployed within Azure VNET.
Azure VNET is a region and subscription specific service, meaning you can’t expand VNET across Azure regions or different subscriptions, however you can connect VNETs in different regions or subscriptions.
You can have multiple VNETs in a region or subscription, there is no default VNET created for customers in Azure subscription. Each VNET can be divided in multiple subnets and different security controls on those subnets can be applied on subnet level based on requirements and scenarios, since VLANs are not supported in Vnets, you can consider subnets as VLAN in on-premises networks.

Note: Similar service provided in AWS called VPC (Virtual Private Cloud).

Below is diagram is a basic representation of Azure Vnet in an Azure Subscription in specific region: 



Virtual Network (VNET) security and traffic filtering:

Implementing security policies and controls within VNETs are customer’s responsibility as its the customer (we) who creates and manage the VNET not cloud service providers and this comes under shared responsibility model of the cloud. Azure has different capabilities/features that can be used to secure VNET, I’m explaining them briefly here:

1. Network Security Groups (NSG):
You can consider NSG as a virtual firewall which filters the traffic at network layer, NSG will have inbound and outbound rules to control the network traffic flow the VNet. So basically, NSG is stateful in nature and can be applied at subnet or network interface level. Best practice is to apply NSG at subnet level. NSG security rules are evaluated by priority using the 5-tuple information (source, source port, destination, destination port, and protocol) to allow or deny the traffic.

Note: People having worked in AWS environment can relate this with AWS Security Groups and Network ACLs (NACL), however we don’t have NACL in Azure as NSG can be applied at Subnet and Interface level both.

2. Network Virtual Appliance (NVA):
NVA in Azure is a software based network appliance that is provided by various known network vendors via Azure Marketplace, NVA is deployed as Virtual Machine in Azure and it can perform various network functions like custom routing, traffic filtering and packet inspections etc. To know what all vendors serves their products as NVA in Azure, please check below documentation.

Network Appliances:
https://azure.microsoft.com/en-in/solutions/network-appliances/

3. Azure Firewall:
We can also use Azure Firewall to filter and inspect network traffic of resources in Azure Virtual Network, Azure Firewall is a fully managed cloud-based stateful firewall-as-a-service with built-in high availability feature. Azure Firewall has all the features that Network Security Groups has but Azure Firewall can also inspect and filter Layer-7 and L-4 traffic as well.

Virtual Network (VNET) Routing:
VNET traffic routing is a big topic in itself to discuss and I would try to cover this in different blog post altogether, however from basics perspective please keep a note of the below important points regarding VNET routing in Azure:

1. By default, all the resources in a Virtual Network can talk to external world outbound.

2. When we create Virtual Network, Azure  by default creates and associates “system routes” to each subnet in a VNET. You can’t create or remove system routes, however you can override some system routes with custom routes (user defined routes – UDR). Below picture shows “system routes” created automatically.



3. We can create custom, or user-defined(static), routes in Azure to override Azure’s default system routes, or to add additional routes to a subnet’s route table. In a scenario where multiple routes contain the same address prefix, Azure selects the route type, based on the following priority:

-UDR
-BGP Route
-System Route

Lets try creating a VNET practically now since we have covered most of the basics theory part, I’m running following commands to create NSG, Subnets, and then finally VNET.

$rdpRule  = New-AzNetworkSecurityRuleConfig -Name rdp-rule -Description "Allow RDP" -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 3389
 
$networkSecurityGroup = New-AzNetworkSecurityGroup -ResourceGroupName LAB-RG -Location southeastasia -Name "LAB-NSG" -SecurityRules $rdpRule
 
$Subnet1 = New-AzVirtualNetworkSubnetConfig -Name Lab-Subnet1 -AddressPrefix "192.168.0.0/24"
 
$Subnet2 = New-AzVirtualNetworkSubnetConfig -Name Lab-Subnet2 -AddressPrefix "192.168.1.0/24"
 
$Subnet3 = New-AzVirtualNetworkSubnetConfig -Name Lab-Subnet3 -AddressPrefix "192.168.2.0/24"
 
New-AzVirtualNetwork -Name LAB-VNET1 -ResourceGroupName LAB-RG -Location southeastasia -AddressPrefix "192.168.0.0/16" -Subnet $Subnet1, $Subnet2, $Subnet3



I will continue to cover Azure Virtual Network topic in multiple upcoming part of this series with more detailed information on specific components and configuration of this service.

Azure SONiC:
https://github.com/Azure/SONiC

Virtual eXtensible Local Area Network (VXLAN) RFC:
https://tools.ietf.org/html/rfc7348

Please stay tuned and happy learning.If you have any feedback please don’t forget to comment here.

Leave a Reply

Your email address will not be published. Required fields are marked *