A very common Azure network topology found in larger enterprise environments is that of a hub and spoke using Azure virtual WAN and secure hubs along with an NVA or Azure firewall.
Having recently deployed this exact hub and spoke scenario into two twinned regions with an Azure firewall in each a question arose around lateral movement in the network…
By default in a virtual WAN secure hub implementation spoke to spoke traffic will pass via the Azure secure hub firewall, meaning firewall rules are required for inter peered vnet communications. This also importantly means inter vnet traffic can be inspected with IDPS and logged.
Below is a diagram showing this out of the box configuration –
However, what about traffic within those vnets? The green and yellow dotted lines.
Well, by default all traffic within the vnet e.g resources within the vnets subnets can communicate with each other unrestricted aside from NSGs on the NICs / subnets. This behavior is similar to that of VLANs on premise, anything within the layer 2 network has unrestricted access to anything else in the same broadcast domain.
So why would we want to change this?
Well… the answer to this of course depends on your environment and requirements, however micro segmentation greatly increases your network security by not only requiring firewall rules in place for all traffic going anywhere but also allowing you to inspect all traffic using IDPS controls. This does mean you have to define every connection in firewall rules, which can be quite a bit of work initially, however the resulting security benefits are great.
Implementing a micro segmented network would make our diagram look like this –
So, now we know what micro segmentation is, how do we achieve it in Azure with our secured VWAN hub?
The answer is actually relatively simple… when you know how….
Firstly we need to create an Azure user defined route table (UDR) in which we will add routes for all our vnets address spaces (NOTE: vnets not subnets) with a next hop of our Azure firewall / NVA IP address which resides in the secure hub.
My setup is multi region, so I have a micro segmentation route table in each region with the next hop of that regions Azure firewall set in each.
Taking the example in the above diagram this would make our UDR look something like this…
NOTE: Although its not visible in the above screenshot the “VirtualAppliance” next hop value is in our case the IP of the Azure firewall – 10.127.0.132.
Propagate gateway routes should be set to yes, this will allow subnets using the UDR to learn routes from the secure hub along with the custom routes defined.
We then apply this UDR to all subnets we wish to implement micro segmentation on.
IMPORTANT NOTE: Although this can be applied to subnets containing managed instances and other Azure services using managed route tables **DO NOT DO THIS** as when the managed instance / service is created it will add a load of its own routes into the micro segmentation UDR and cause havoc on all the subnets its applied to when trying to access the MI / service!
The above config effectively overrides the Azure default learned route to the locally connected vnet by providing an equally as specific route learned from within the micro segmentation UDR. As this route is a user defined route it will take priority over the default learned route and as such the traffic is sent to the virtual appliance as specified in the UDR, in our case the Azure firewall.
The below screenshot shows the effective routes for a VM living within the 10.127.1.0/24 vnet with the micro segmentation route table applied –
As you can see the first route in the table shows as “Invalid”, this is due to the 2nd to last route in the table being equally as specific but user defined from our micro segmentation UDR and therefore taking over to make the first route invalid.
Another important note is around private endpoints which by default will not honor UDRs, meaning even when the subnet the private endpoint lives in has the micro segmentation route table applied it will not be micro segmented.
The solution to this is changing the “network policy for private endpoints” setting on the subnet to “Route tables” as can be seen in the below screenshot –
This will then force private endpoints to honour the micro segmentation UDR.
And a final note – if you wish to only micro segment specific subnets within a vnet then a slight change to the above will be required, instead adding routes to the micro segmentation UDR only for the individual subnets rather than the whole vnet address space. If you fail to do this then you will end up with asymetric routing when sending traffic to other subnets with the micro segmentation UDR applied within the same vnet.
This happens as traffic can be sent directly due to the source subnet not having a UDR applied and therefore using the default directly connected route, however on its return is forced via the Azure firewall / NVA as the destination subnet sending the return traffic has got the micro segmentation UDR applied forcing all traffic destined to the whole vnets address space to be sent via the Azure firewall / NVA.
And finally…. with all that said and done! You should have a nice and very secure micro segmented networking setup!