One of the many Azure networking announcements at Microsoft Ignite recently was the release to public preview of Azure Virtual Network Manager (AVNM). AVNM promises to be a service to help apply connectivity and security configurations to groups of virtual networks across multiple Azure subscriptions. This post gives my initial thoughts on this service as it currently stands.
I am not going to write this post as a “how to deploy”, this is documented by Microsoft already so the below are my thoughts on what I have found so far.
Deploying the network manager
After registering the preview feature, you should be able to select the scope of your deployment. This has a requirement to use management groups so if you only have a small number of virtual networks to manage then you may not have any management groups already created. Once these are created, you can then scope the AVNM service to the entire management group or to individual subscriptions within it.
Then you select whether you want to use AVNM to configure connectivity features or security features or both.
An important point to note here is that the scope and feature set cannot be changed once the AVNM service is deployed. Therefore if you are planning to use a single AVNM for your organisation then it is best to plan ahead.
I would recommend to select both feature options and scope the AVNM to your parent management group. This way you can add more subscriptions later if this becomes a future requirement.
Connectivity configuration
With the AVNM service deployed, it’s then a matter of putting your virtual networks into network groups. These are logical units where you want to apply the same connectivity or security configurations. These network groups can span multiple Azure regions if desired.
There are currently two options for connectivity configuration which is really the network topology you want to use – Mesh and Hub and spoke.
I decided I would go with a hub and spoke topology and route all traffic through a hub virtual network with a virtual private gateway deployed.
I already had my virtual networks and VPN gateway in place so it was simply a matter of creating the configuration and then deploying it to my network group.
Although you do get a notification telling you that the configuration needs to be deployed to take effect I would have liked to have seen this highlighted or flagged within the portal so that you know that you have a configuration saved but not yet deployed. This could be something that is easily overlooked if using this service.
The deployment took a couple of minutes to complete and sure enough the network peerings had been created as I had configured. Great!
I tried a mesh configuration next. Same steps, create the configuration and deploy it. This will automatically replace the existing hub and spoke configuration that I had deployed before.
This configuration applied pretty quickly also but when I went to check the network peerings I was surprised to see that there were none. My first thoughts were that something went wrong here but upon checking the documentation I found that the mesh network had indeed been set up correctly.
Connected Groups
AVNM introduces a new way of managing mesh network peering connections through something called a connected group. This works the same way as VNET peering but all of the peered networks appear together in a single connected group.
This is an interesting change and something which I suspect we will probably eventually see outside of use with just the AVNM service.
There are a few downsides to this as it stands currently however, as I see it. If you are using connected groups then you will not see anything appear under the regular network peerings section of your virtual network.
Connected groups also don’t seem to be supported by the network topology tool in network watcher at this time as the virtual networks appear as not connected. This might lead to administrative oversights by some users who are not familiar with this new service.
If you go to the Azure preview portal you will see a network manager section under the settings of the virtual network but it does little more than list any applied connectivity or security configurations applied.
Security configuration
Next up was to test the security configuration options. These need to be configured and deployed exactly the same way as connectivity configurations. Right now, these are limited to a collection of 5-tuple firewall rules exactly the same way as how network security groups work.
However there are two important points to note here. Firstly, these configurations take precedence over NSGs and secondly that NSGs (if associated) are still processed afterwards.
In other works this acts like an additional security layer, if the security configuration allows the traffic then the NSG can still block it. As an example if I created an allow RDP rule from my source IP address in the security configuration but then I had a deny RDP rule on the NSG then I would not get access.
There is a way to override the NSG deny rule however. The security configuration rules provide a third action type called allow all, this will allow the traffic from this rule even if there are lower priority deny rules including any NSG deny rules.
Thankfully, we have a bit more visibility on these security rules and there are a few places where we can check and see what’s actually being enforced.
Firstly, the rules will show underneath the regular NSG rules section on the networking settings of a virtual machine.
There is also a new tab for the associated AVNM resource on the effective security rules of the NIC on a virtual machine.
If you are using the Azure preview portal you will also see the security configuration rules listed within the new network manager section under the settings of the virtual network.
Some downsides:
The NSG diagnostic tool in network watcher unfortunately does not seem to be fully aware of this service yet as I always seemed to get an allowed result against an NSG simply named #. Hopefully this will be added in future to assist with rule troubleshooting.
I had some difficulties trying to delete individual rules from my security configuration ruleset. It appears that once they are associated then although you can modify existing rules if you want to delete any then you have to first deploy a new security configuration of type none to first remove your current configuration. Then you can make your changes and deploy the new configuration once again.
Conclusion
My overall thoughts are that this new service definitely seems unfinished at this point. I can definitely see the potential of such a service when managing virtual networks at scale but for smaller deployments I think it may just add complexity at this point.
My main concerns were the lack of integration with some existing settings views and diagnostic tools in the Azure portal. Depending on your team’s level of experience with Azure networking this may lead to creating more problems than it solves right now.
It will be interesting to see how much effort Microsoft put into improving this service and adding more features over the coming months.
azurealan.ie 