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.