Tag Archives: Azure Networking

Azure Standard Load Balancer | NSGs are a must

Azure Standard Load Balancer is a new Load Balancer SKU that provide 10x performance and more features than the Basic SKU. One of the coolest features is the ability to use two Standard Load Balancers as a public and internal Load Balancer at the same time. This allows a VM NIC to be connected to the backend pool of one public and one internal Load Balancer resource  where both are of Standard SKU.

I’m my test lab I tried to replicate the Internal + External loadbalancing scenario and found that only the Internal Load Balancer has been working. I’ve tried every possible change I could do including:

  • replicating the same inbound rules as the Internal LB,
  • deleting and re-creating the LB,
  • changing the health probes countless time,
  • changing the health probe settings,

and none of the tweaks I did worked for the External Azure Standard LB.

The Culprit

This article explains the security model of the new Azure Standard Load Balancer.  I had a through look in the documentation and found out the following section.

Standard Load Balancer is fully onboarded to the virtual network. The virtual network is a private, closed network. Because Standard Load Balancers and Standard public IP addresses are designed to allow this virtual network to be accessed from outside of the virtual network, these resources now default to closed unless you open them. This means Network Security Groups (NSGs) are now used to explicitly permit and whitelist allowed traffic. You can create your entire virtual data center and decide through NSG what and when it should be available. If you do not have an NSG on a subnet or NIC of your virtual machine resource, we will not permit traffic to reach this resource.

As you can see if we don’t assign an NSG rule to explicitly allow inbound traffic from the Internet to reach the LB backends (VMs) connected to the Azure Standard Load Balancer. Let’s examine a practical example.

In my example the backend VMs are connected to an Azure Standard LB that resides in the DMZ subnet of a VNet. I have created subnet specific NSGs so therefore the rule I’m going to create is assigned to the DMZ NSG.

As you can see all the inbound traffic originating from the Internet which are destined to ports 443,8443,8444 on DMZ subnet 10.150.4.0/24  have been whitelisted in this rule.  Also note that the External Azure Standard LB has three loadbalancing rules corresponsing to the same ports.

It is a simple solution yet can cause a huge trouble in your environment. In my case not having the NSG rules assigned has resulted in a Traffic Manager endpoint (of course the endpoint was an External Azure Standard LB) to be  in a degraded state during a DR drill. Therefore it is quite important to make sure that you have created the appropriate NSG rules if you are using the Standard SKU for your external Azure LBs.

 

Service Tags for Azure Network Security Groups

While you are creating NSG rules have you ever faced a scenario where you need to group a bunch of IP addresses, sources or destinations? Service Tags in Azure denotes a group of IP address prefixes that can help you to simplify the NSG rule creation. Service Tags allow you to restrict (allow or deny) traffic to a specific Azure service both globally or per region.

Microsoft manages and updates the list of undelying IP address for each service tag thus eliminating the need to manually update your NSG rule each time the service endpoint IP addresses are changed. This allows you to leverage service tags insteadof  of specific IP addresses when creating security rules.

What’s available right now?

Following is the list of  service tags that are available to be used in a security rule definition.

Azure Service Tag Purpose
VirtualNetwork (Resource Manager) (VIRTUAL_NETWORK for classic): VNet address space (all CIDR ranges defined in the VNet), all connected on-premises address spaces, and peered VNets or VNets connected to a VNet gateway, are encompassed in this service tag.
AzureLoadBalancer (Resource Manager) (AZURE_LOADBALANCER for classic) If you are using any Internet facing Azure Load Balancer you can use this service tag. This tag translates to an Azure datacenter IP address where Azure’s health probes originate.
Internet (Resource Manager) (INTERNET for classic) Any ingress or egress traffic from IP addresses that are outside the VNet and reachable from the Internet, is encompassed in this service tag. The address range includes the Azure owned public IP address space as well.
AzureTrafficManager (Resource Manager only) The IP address space for the Azure Traffic Manager probe IPs is denoted by this service tags.
Storage (Resource Manager only) Azure Storage service IP range is denoted in this service tag so that once you specify Storage for the value, traffic is allowed or denied to storage. Furthermore, you can specify the region to allow or deny traffic to a storage in a specific region.This tag represents the Azure Storage service, but not specific instances of the service (storage accounts).
Sql (Resource Manager only) Address prefixes of the Azure SQL Database and Azure SQL Data Warehouse services are denoted in this service tag. Specifying Sql for the value allows you to allow or deny traffic to Sql. Regional restrictions are possible as in Storage service tag and also this tag represents the Azure SQL service not individual instances. (databases or data warehouses)

Here is an example of a service tag in action. As you can see we are using the Internet service tag to denote all inbound external traffic in this NSG rule.

Multiple vNICs in Azure ARM VMs

I have recently faced with a challenge to add multiple vNICs to an ARM based Azure VM. The requirement was to add a secondary vNIC while keeping the first one intact. This post explores how  I achieved this task with PowerShell.

Before you do anything make sure that the existing vNIC Private IP address has been set to static as below. Otherwise once the VM Update operation is completed you will lose that IP address. Optionally you can set the Public IP address to reserved (static) as well. The VM should already have at least two NICs and it is not supported to pass from a single NIC VM to multiple NIC VM and vice versa.

1-vnic-private-ip

2-vnic-public-ip
Create a new vNIC

I have defined the properties for the new vNIC as below.

$VNET = Get-AzureRmVirtualNetwork -Name ‘vmnic-rg-vnet’ -ResourceGroupName ‘vmnic-rg’
$SubnetID = (Get-AzureRmVirtualNetworkSubnetConfig -Name ‘default’ -VirtualNetwork $VNET).Id
$NICName = ‘jcb-vnic02’
$NICResourceGroup = ‘vmnic-rg’
$Location = ‘East US’
$IPAddress = ‘10.0.0.7’

Next step is to create the new vNIC.

New-AzureRmNetworkInterface -Name $NICName -ResourceGroupName $NICResourceGroup -Location $Location -SubnetId $SubnetID -PrivateIpAddress $IPAddress

3-vnic-create

Adding the new vNIC to an existing VM

I’ve executed below PowerShell snippet which sets the existing vNIC as primary and and updates the VM once the new vNIC is in place.

$VMname = ‘jcb-nicvm01’
$VMRG =  ‘vmnic-rg’

$VM = Get-AzureRmVM -Name $VMname -ResourceGroupName $VMRG

$NewNIC =  Get-AzureRmNetworkInterface -Name $NICName -ResourceGroupName $NICResourceGroup
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $NewNIC.Id

Then I’m listing the attached NICs in the VM and setting the first one as primary.

$VM.NetworkProfile.NetworkInterfaces

$VM.NetworkProfile.NetworkInterfaces.Item(0).Primary = $true
Update-AzureRmVM -VM $VM -ResourceGroupName $VMRG