Forum Discussion
Solved
How to split traffic on VWAN with PALO and AZFW
Hello all, I have a virtual wan environment that we'd like to essentially split in two. Traffic from on prem will reach all servers in the cloud. ON prem at the edge is a palo alto device, we'd li...
John Wildes
I've come to the conclusion that this is not a possible configuration.Found here - https://docs.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing#considerations
When using Azure Firewall in multiple regions, all spoke virtual networks must be associated to the same route table. For example, having a subset of the VNets going through the Azure Firewall while other VNets bypass the Azure Firewall in the same virtual hub is not possible.
John Wildes
I've come to the conclusion that this is not a possible configuration.
Found here - https://docs.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing#considerations
When using Azure Firewall in multiple regions, all spoke virtual networks must be associated to the same route table. For example, having a subset of the VNets going through the Azure Firewall while other VNets bypass the Azure Firewall in the same virtual hub is not possible.
Hello John,
Thank you for sharing your idea. My experience so far is that routing traffic over a peered NVA is working perfectly fine, even when the virtual hub is configured as a secured virtual hub. I did not try this yet with a Palo Alto, but only with the Azure Firewall unfortunately.
In my setup, the Azure Firewall part of the vhub is inspecting VNET-to-VNET and VNET-to-Branch traffic (because as far as I tested this is not possible with a VNET peered only firewall) and the VNET peered Azure Firewall is only used for the Egress/DMZ traffic. This does have several advantages, for example, an Azure Firewall deployed in a VNET can be equipped with a NAT-Gateway and Public IP-Prefixes. These features are not available for the vHub Azure Firewall.
To set it up, you must make a couple of changes in your vHub router:
Route tables:
- Deploy a separate route table for your VNET-peered firewall
- Deploy a separate route table for your other VNETs, so it easier to force VNET-to-Branch and visa versa over the vHub Azure Firewall. Add two static routes; point all your private ranges to the hub firewall and point the 0.0.0.0/0 route the VNET-peer where the other firewall is deployed. Set as next hop the private IP of the Firewall.
VNET-connections:
- Make sure you enable Propagate Default Route (or Enable Internet Security) so the 0.0.0.0/0 route is propagated to the peered VNET.
- Associate the VNET with the correct route table (the one with the 0.0.0.0/0 route)
- Propagate to the VNET-peered firewall route table, so the vHub understands how to route return traffic.
I noticed that the vHub does not route traffic to the VNET-peered firewall if there is no connection associated to the Default Route Table. Make sure that you connect at least one network with the Default Route Table.
-Bas
Thank you for sharing your idea. My experience so far is that routing traffic over a peered NVA is working perfectly fine, even when the virtual hub is configured as a secured virtual hub. I did not try this yet with a Palo Alto, but only with the Azure Firewall unfortunately.
In my setup, the Azure Firewall part of the vhub is inspecting VNET-to-VNET and VNET-to-Branch traffic (because as far as I tested this is not possible with a VNET peered only firewall) and the VNET peered Azure Firewall is only used for the Egress/DMZ traffic. This does have several advantages, for example, an Azure Firewall deployed in a VNET can be equipped with a NAT-Gateway and Public IP-Prefixes. These features are not available for the vHub Azure Firewall.
To set it up, you must make a couple of changes in your vHub router:
Route tables:
- Deploy a separate route table for your VNET-peered firewall
- Deploy a separate route table for your other VNETs, so it easier to force VNET-to-Branch and visa versa over the vHub Azure Firewall. Add two static routes; point all your private ranges to the hub firewall and point the 0.0.0.0/0 route the VNET-peer where the other firewall is deployed. Set as next hop the private IP of the Firewall.
VNET-connections:
- Make sure you enable Propagate Default Route (or Enable Internet Security) so the 0.0.0.0/0 route is propagated to the peered VNET.
- Associate the VNET with the correct route table (the one with the 0.0.0.0/0 route)
- Propagate to the VNET-peered firewall route table, so the vHub understands how to route return traffic.
I noticed that the vHub does not route traffic to the VNET-peered firewall if there is no connection associated to the Default Route Table. Make sure that you connect at least one network with the Default Route Table.
-Bas