If you’ve been using Azure for a while there’s a good chance you’re using the classic deployment model. ARM is the new model which will eventually replace classic, and already there is an amount of feature disparity where new features are only being added to ARM. I started looking into the logistics of moving the networking components over to ARM recently and was worried about cost, where you would potentially need to run two environments while moving from the old to the new. One of the big drivers for the change (from a networking perspective) is that NSG’s in ARM support logging:

  • Event logs: You can use this log to view what NSG rules are applied to VMs and instance roles based on MAC address. The status for these rules is collected every 60 seconds.
  • Counter logs: You can use this log to view how many times each NSG rule was applied to deny or allow traffic.

Great news for people that have been running blind out there!

Until recently an express route circuit created in the classic model could not coexist with one created in ARM – it meant no easy way of connecting these two environments. Microsoft have announced that this month you are able to upgrade ExpressRoute to ARM from Classic, and have VNET’s connected together that have been provisioned in both deployment models.

The documentation is here. I’ll be looking to upgrade our secondary express route connection in the comings weeks, so we can start exploring how easy the rest of the infrastructure will be to move.


Microsoft have been adding networking appliances to their marketplace recently, I see firewall offerings from Checkpoint, Barracuda,  Fortinet, and Cisco to name a few. Given the laborious situation I’m in where all of our NSG’s need to be updated manually by CSV files, I thought I would take a closer look at the Cisco ASAv.

The ASAv is only supported on the ARM / Azure v2 deployment model and requires a D3 as a bare minimum. This will provide 4 interfaces, one for management and 3 for joining to your inside network or DMZ’s. The basic license (effectively perpetual, you will pay for just the compute time) provides 100 connections and throughput of just 100Kbps, this will be fine for the sake of just testing it. I won’t cover the setup as this is covered in the Cisco quick start document here.

Having played around a bit with this I feel it’s not really ready for enterprise use.

  • You are limited to one public address on the ASA, and even this is natted automatically to a private address before it hits the ASA. Although you can add several VIP addresses to the cloud service, the firewall isn’t aware of these. Natting between those other VIP’s and the private address on the ASA means by the time the traffic reaches the ASA you cannot distinguish what has been sent to say and This means that if you wanted to run two web servers behind the ASA, one would need to be on port 80, and one would need to be on port 81. Awful. Microsoft should allow these public addresses to allocated directly to the firewall.
  • Clustering is not supported. In order to get Azure SLA’s you need to have two devices in an availability set. if you can’t cluster the two devices you would need to make configuration changes on each device – it’s not sensible to do this and you are likely to end up with differing configs if you’re not careful. You could use a firewall manager like CSM but this would require another machine in Azure.
  • No console access. If you fat finger a config update and lock yourself out, how are you supposed to recover?
  • Traffic is routed from each subnet via a user defined route table. There is nothing stopping another admin simply changing the routing table on a machine to circumnavigate your firewall! This may be an old way of thinking as separation of duty has truly become rather blurred in ‘the cloud’. In the old world a VLAN assigned to a machine would mean this could never happen.

I look forward to seeing how these networking appliances evolve, but I won’t be suggesting we change from using the native NSG’s just yet.