Jun 10 2021 05:23 PM - edited Jun 10 2021 05:25 PM
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 like to build a palo alto device in the cloud, and a wvd environment that would use this palo alto device to egress traffic to the internet and essentially serve as the FW for the WVD environment.
We'd also like to enable SECURE VIRTUAL HUB and use the AzFW to serve as FW for the other NON WVD servers that exist in the cloud. There are some requirements that we have to maintain that we cannot achieve with the AzFW for the "end user instances" within the cloud.
Server internet traffic is highly regulated, and really non existent, but we need a separate place to control it rather than using the PA device.
All VNETS are peered to the hub, the DMZ vnet included. The palo device lives in the DMZ vnet because it's not natively supported as a secondary security device by VWAN.
1.) is this architecture possible (secure virtual hub, + NVA on peered VNET)
2.) if so, what do I need to do from a routing perspective because just enabling the secure virtual hub significantly changes my routing tables for all peered vnets.
DIAGRAM ATTACHED TO THIS MESSAGE
Thanks for the help.
-john
Jun 22 2021 09:49 AM
Solution@John Wildes
I've come to the conclusion that this is not a possible configuration.
Found here - About virtual hub routing - Azure Virtual WAN | Microsoft Docs
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.
Aug 20 2021 08:03 AM
Jun 22 2021 09:49 AM
Solution@John Wildes
I've come to the conclusion that this is not a possible configuration.
Found here - About virtual hub routing - Azure Virtual WAN | Microsoft Docs
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.