Azure Virtual WAN with an NVA
Setting up Azure Virtual WAN (VWAN) with Network Virtual Appliance (NVA) like a Palo Alto, Juniper SRX, etc is a not as straightforward as one would think. The documentation they provide isn’t quite explicit enough so my goal here is to fill some of the gaps I had to work through.
This is the documentation I followed: https://docs.microsoft.com/en-us/azure/virtual-wan/scenario-route-through-nvas-custom
Note**** – This deployment design does not allow for east/west traffic, or traffic to/from on-premise locations to be filtered. It can only filter traffic inbound/outbound to the internet. If you require these filtering scenarios you’ll either have to use the Azure Firewall (or other supported vendors) and deploy it in the VWAN Hub, or use a hub/spoke VNET (transit VNET) design. At the time of this writing in July of 2021, only the Azure Firewall, and Barracuda firewalls are the only supported for deployment in the VWAN Hub. If you use other 3rd party firewall NVA’s, for now you won’t be able to deploy them in the VWAN Hub, but hopefully those will be supported in the future. For now you’ll need to use a design like the one below.
If you’re just learning Azure like me some of the gaps are a bit frustrating. One thing to note with this “Virtual WAN” or “Alternate Workflow” setup, is that with these designs you can only protect traffic from VNETs to the Internet. Reminder, you can not protect traffic from one VNET to another VNET, and you can’t protect traffic to/from On-Premise (branches) to VNETs. This is a pretty heavy shortcoming in my opinion so it’s not as likely you’d want to use this deployment type.
The first thing that isn’t clear from the instructions is where/how to create the static routes in the route tables and connections. The routes in the red box are created in the Route Tables associated with the VWAN Hub (Virtual WAN–>Connectivity–>Hubs–>hub_name–>Connectivity–>Routing). The routes in the green box are created on the VNET connections from the VNET to the VWAN Hub (Virtual WAN–>Connectivity–>Virtual Network Connections). This was one of the largest confusion points for me since when you create the in the Route tables, it also creates it in the connections, and if you name them the same Azure doesn’t warn you and just combines it into one object, so if you alter it in the VNET connection routes it also updates it in the VWAN Route table, breaking the routing.
Secondly, you have to link all your spoke subnets to the VWAN Hub. This is why you can’t filter east/west traffic with the NVA in this design. Each VNET will have routes to each other directly and unless you can pair down your routes to something smaller, you can’t static route this traffic with UDRs (User Defined Route-tables).