Azure InterfaceEndpoint Routes Bypassing Palo Alto Firewall

Question

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://learn.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?

Answer 1

Hello @BigfootDivorcedMe03 ,

Yes, currently the only way to force the Private Endpoint traffic to firewall is to add UDR with /32 route. And hence, it is advised to use a dedicated Virtual Network for Private endpoints as shown in Scenario 1 of the below article as this configuration reduces administrative overhead and prevents running into the limit of 400 routes.
https://learn.microsoft.com/en-us/azure/private-link/inspect-traffic-with-azure-firewall

The resolution in your scenario would be the use of Public preview feature of UDR support in Private endpoints. This feature enables you to route traffic destined for a Private Endpoint over an NVA or Firewall without complex configuration of specific routes (UDR) on the subnets. This also enables you to easily scale on Private Endpoints without reaching any limit on UDRs while satisfying auditing and compliance requirements.
However, this preview version is provided without a service level agreement, and it's not recommended for production workloads. Certain features might not be supported or might have constrained capabilities.
Refer : https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview#limitations

So, you can either opt for this Public preview of UDR support by registering the feature at the moment or can wait till it's GA with SLA agreement.
In case, you would like to try out the Public preview of UDR support, you can refer the below article:
https://azure.microsoft.com/en-us/updates/public-preview-of-private-link-udr-support/

NOTE: This feature will be available in the following regions:
UsEast2Euap, UsCentralEuap, WestCentralUS, WestUS, WestUS2, EastUS, EastUS2

Kindly let us know if the above helps or you need further assistance on this issue.

----------------------------------------------------------------------------------------------------------------

Please "Accept the answer" if the information helped you. This will help us and others in the community as well.