SOLVED

How to split traffic on VWAN with PALO and AZFW

Brass Contributor

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

2 Replies
best response confirmed by John Wildes (Brass Contributor)
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.
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
1 best response

Accepted Solutions
best response confirmed by John Wildes (Brass Contributor)
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.

View solution in original post