Situation: Deployed two Palo Alto VM firewalls in Azure in a 'Transit VNet' following the Palo Alto Networks design, https://www.paloaltonetworks.com/resources/reference-architectures/azure.
When you peer a VNet to the Transit VNet, the remote VNet’s network is learned in all of the routing tables on the Transit VNet. To force traffic to take the Palo Alto firewalls:
-The Route Table on the remote VNet needs a UDR installed to point traffic to the load balancer’s frontend IP.
-The Route Table on the Virtual Network Gateway Subnet needs a UDR for the remote VNet’s network to point traffic to the load balancer’s frontend IP.
Route Tables have a UDR entry limitation of 400 entries, https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-...
Some resources when deployed create an InterfaceEndpoint route which advertises it’s own /32 route to the Transit VNet:
-Since these are more specific routes than the existing UDR on the Virtual Network Gateway Subnet, /32 versus /23 as an example, that covers the Subscriber VNet’s network, traffic bypasses the firewall.
-The only resolution that Microsoft has given is to update the UDR on the Virtual Network Gateway Subnet to cover the /32 route for the individual InterfaceEndpoint's IP address.
This causes the following issues:
-It causes a security problem because anytime an InterfaceEndpoint route is created, it bypasses the firewall. This causes a secondary problem in that folks managing the Transit VNet have to catch these being built so you can add the needed UDR on the Virtual Network Gateway Subnet's Route Table to get traffic routed to the load balancer so it can get to the firewall.
-It’s un-scalable to be adding a UDR on the Virtual Network Gateway Subnet's Route Table every time a InterfaceEndpoint route Is created with the 400 UDR limitation on route tables.
Has anybody else experienced the same thing and if so, what was the resolution? If you haven't seen it, any suggestions for resolution?
