Enable Hybrid benefit on all already deployed Windows VMs in your subscription

Hybrid benefit in Azure means that you are purchasing the Windows license elsewhere, instead of “pay-as-you-go” with the VM consumption. The reason to do this is either your organization already owns licenses or purchased licensese to save cost (there is a brake even when it makes sense to buy the license outside of Azure).

To retrofit this to existing subscription, it is quite straight forward with Powershell. It is just a metadata for the virtual machine, so there is no down time required (reference https://docs.microsoft.com/en-us/azure/virtual-machines/windows/hybrid-use-benefit-licensing#convert-an-existing-vm-using-azure-hybrid-benefit-for-windows-server) .

The following Powershell code takes your current logged in Azure subscription context, get all Windows machines that does not have Hybrid benefit enabled and loops thru them, enabling Hybrid benefit.

[Cmdletbinding()]
Param
(
)


$nonehbvm = Get-AzVM -Status | where{$_.StorageProfile.OsDisk.OsType -eq "Windows" -and (!($_.LicenseType))} | Select-Object Name,ResourceGroupName,Licensetype
foreach($i in $nonehbvm)
{
    $vm = Get-AzVM -ResourceGroup $($i.ResourceGroupName) -Name $($i.Name) 
    Write-Verbose "Setting hybrid benefit on VM $($i.Name) "
    $vm.LicenseType = "Windows_Server"
    Update-AzVM -ResourceGroupName $($i.ResourceGroupName) -VM $vm
} 

How routes are distributed to Spoke Virtual networks with a secured hub

Microsoft has a interesting addon for the Virtual WAN offering in preview, Azure Firewall (Manager) in the Azure Virtual WAN. This means that we can filter traffic traversing our Virtual WAN Hub instead of sending it to a NVA or Azure Firewall in another Virtual Network for example.

There is a lot of intresting stuff regarding this, but one that is not that well documented (yet, still preview). Is how routing is working and how the routes are distributed to the different spokes. It differs a bit from the “old” Hub-and-Spoke model, where you had to maintain Route table for each spoke to point to your NVA in the hub. Virtual WAN however solves this differently and at first glance, a more elegant way.

If you press the hyper link on “Learn more” on the configuration page you end up on Azure Firewall manager documentation page, that for the moment lacks the section.

So how does it work? For the default route, choose Send via Azure Firewall, for traffic between VNET, you need to specify the address range for each spoke you add.

When you press save, a deployment is launched and what happens is the Virtual Hub routing tabel get updates. However the Route section on virtual hub in portal is still empty.

However, if you deploy a virtual machine in one of the networks and inspect the route table of the machine you will see the following

Default route is the system learned routes (Virtual Network or VNET peering for example). The interesting are the Virtual Network Gateway, the Virtual Hub injects the routes in the “Gateway” route table to distribute the routes to the different spokes and hence we do not need to maintain a route table on each spoke, compared to the old Hub and spoke model.

Notice, the Firewall manager is still in preview, so this can be changed when the service goes GA.

Avoid Source NAT for none RFC1918 ranges in Azure Firewall

In certain scenarios, some companies are using public IPs for internal purposes. This more common in education or larger old enterprises as they got assigned a sizeable public IP range. This creates some unique challanges for Azure Firewall in combination with ExpressRoute or VPN.
By default, Azure firewall will source NAT communication with IP adresses not defined in the RFC 1918 space (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16).

If the none RFC1918 space is coming from ExpressRoute or VPN, it will source NAT to one of the Azure Firewall interfaces. For example if you got 192.168.0.0/26 defined as your AzureFirewallSubnet, it can be 192.168.0.6 for example. This is choosen “random”, since AzureFirewall consist of at least 2 instances behind the scene. Hence, if a virtual machine (Virtual Machine Windows) in Azure with the source IP of 172.0.0.10, sitting “behind” the firewall, communicating with an on-premise virtual machine (Virtual Machine Linux) with the IP of 30.30.30.10, the target machine, will see one of the Azure Firewall IPs as source IP, for example 192.168.0.5.

For certain applications, this can brake functionality and therefor not a desired behaviour. Lucikly Microsoft released a new feature, where we can defined our own ranges, that should be excluded from source NAT. From Azure Portal, navigate to the Firewall and press Private IP range.

Here, already defined is IANA Private ranges (RFC1918), here we can add our 30.30.30.0/16 range, to make it excluded from Source NAT. After change is applied. Virtual Machine Linux will see 172.16.0.10 of Virtual Machine Windows as the source IP, instead of the Azure Firewall Internal IP.

Via ARM template
If you want to add this via ARM templates instead, add the following snippet under the properties configuration

"additionalProperties": {
                    "Network.SNAT.PrivateRanges": "IANAPrivateRanges , 30.30.30.0/24"
                },

Powershell OneLiners #1

Sometimes, the need for a certificate to verify something quickly. Here is an example how to add certificate that expire after 50 years on two domain names from your Powershell prompt.

New-SelfSignedCertificate -DnsName "app.domain.local", "test-app.domain.local" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-date).AddYears(50) -KeyExportPolicy Exportable

ExpressRoute vs. VPN – what is the difference in practise?

A decision to make when developing a hybrid cloud, or just providing access to Azure (or might as well be AWS or GCP) is if a VPN connection will suffice, or you will need an dedicated circuit like Express Route (AWS – Direct Connect, GCP- Dedicated Internetconnect).

Looking on the Microsoft documentation on ExpressRoute, they promise a 99.9 % SLA uptime on the connection. A VPN connection is no SLA on. This is due to Microsoft provisioning redudant circuits to the provider edge in the ExpressRoute scenario and thus can give an SLA.

Be aware to make sure the provider match the SLA to your customer edge. This may differ.

There is a lot to be said about what and what not you can achieve with ExpressRoute or VPN (or combining). To start somewhere, a simple test were conducted. Two similiar Azure environments were setup, one with ExpressRoute and one with VPN – to the same on-premise datacentre.

The test is one ping message, sent every 5 seconds to each Azure environments over 24 hours. The tests were done at the same time. What we want out of the tests are two things, what is the delay and do we have any packet drops?

This were the results

  • 17280 of 17280 requests succeded – 100 %
  • 22.2 MS in average response time
  • 21 MS minimum response time
  • 187 MS maximum response time

  • 17271 of 17280 requests succeded – 99.9479 %
  • 27.7 MS in average response time
  • 25 MS minimum response time
  • 404 MS maximum response time

So what is the differences?

  • 0.0521 % package loss on VPN vs. 0 % on ExpressRoute
  • Average response time is 19.8 % faster in ExpressRoute then VPN
  • Minimum response time is 16 % faster in ExpressRoute then VPN
  • Maximum response time is 53.7 % faster in ExpressRoute

Summary
The biggest advantage of ExpressRoute seems to mitigate the worst case scenarios and more predictable response time, as advertised by Microsoft. Average Latency wise there is also an advantage of ExpressRoute, however, seen in pure ms, not too much of a difference, depending on your application needs.