Seamlessly migrate VNET Traffic from Azure Firewall to Palo Alto Networks Cloud NGFW

[vmehta19]

This article explains how to migrate VNET traffic from being inspected by Azure Firewall to the Cloud NGFW by Palo Alto Networks without disrupting communications across production applications.

Problem Description:
As organizations expand their cloud infrastructure, security requirements inevitably become more sophisticated. While many enterprises initially implement native security services such as Azure Firewall, they often require the advanced threat prevention, comprehensive application visibility, and centralized management capabilities provided by Palo Alto Networks Cloud NGFW for Azure.

In large-scale enterprise environments, immediate full-scale migrations are often impractical. When managing numerous production Virtual Networks (VNETs), attempting a comprehensive migration within a restricted timeframe presents a significant risk of prolonged service interruptions.

Adopting a phased migration strategy is considered the industry standard; however, this approach necessitates addressing a critical technical challenge: the secure, concurrent operation of both firewall solutions while maintaining uninterrupted traffic flows.

The Challenge: The Asymmetric Routing 

The primary obstacle during a phased migration is asymmetric routing. Consider this common scenario during a phased migration:

• VNET A User-Defined Routes (UDR) has been successfully updated with the next hop to be the Cloud NGFW.
• VNET B is still waiting in the migration queue and its UDR points to the legacy Azure Firewall.
• Both firewalls live in their own designated subnets within a centralized Hub VNET.

When an application in VNET A initiates a connection to a service in VNET B:

1. The Outbound Path: VNET A forwards the traffic to the CNGFW, based on its updated UDR. CNGFW inspects it and sends it onward to VNET B.
2. The Return Path: VNET B receives the packet. When it replies, its legacy UDR dictates that the return traffic must go to the Azure Firewall.
3. Packet Drops: Azure Firewall receives the return packet but has no record of the initial handshake. Recognizing this as an invalid stateful connection, it drops the traffic. Communication breaks.

The Solution: Inter-Firewall Routing Co-existence

To prevent asymmetric routing, the firewalls must be explicitly instructed to hand off traffic to one another when communicating across the migration boundary. This is achieved by strategically updating the UDRs attached to the Firewall Subnets themselves in tandem with Spoke VNET updates. By manipulating the next-hop routing logic inside the Hub, you ensure that both the forward and return paths traverse the exact same firewall.

To make VNET A (on CNGFW) and VNET B (on Azure Firewall) talk seamlessly, apply the following workaround:

1. CNGFW Private Subnet UDR: Add a route targeting VNET B's IP space, specifying the next hop as the Azure Firewall Private IP.
2. Azure Firewall Subnet UDR: Add a route targeting VNET A's IP space, specifying the next hop as the Cloud NGFW Private IP.

With these rules in place, if Application VNET A talks to the Application in VNET B:

• VNET A sends traffic to CNGFW.
• CNGFW checks its local subnet UDR, sees the route for VNET B, and forwards the packet to Azure Firewall.
• Azure Firewall evaluates the state, inspects it, and sends it to VNET B.
• The return path mirrors this logic in reverse, ensuring stateful symmetry is maintained across both appliances.

Scaling to multiple VNETs: Operationalizing the Migration

As each individual VNET's UDR is updated to have a next hop of the CNGFW, you must correspondingly update the UDRs of these firewalls. By utilizing phased routing approach, you ensure that regardless of where a VNET is in the migration pipeline, the firewalls know exactly how to hand off traffic to their counterpart for environments that haven't been cut over yet.

 

Important considerations:

• When planning this scaled approach, it is crucial to keep Azure's route table limits in mind. As detailed in Microsoft's Virtual Network UDR overview, each subnet can have zero or one route table associated with it, and a route table can contain up to 400 UDRs. Leverage route-summarization where possible to prevent sprawl of static routes and accidental misconfigurations. 
• If the CNGFW and Azure Firewall are deployed in different Hub VNets, then the above solution still applies, however ensure that VNet peering is enabled between these Hub VNets.
• Simplify the translation of your legacy Azure Firewall rules by using the Cloud Firewall Policy Migration tool in Strata Cloud Manager to automatically discover, analyze, and import your existing policies. For more details, see TechDocs article and Live Community blog-post.
• Even though changing UDRs on Firewall subnets, doesn’t impact other traffic flows, as a best practice make these changes in maintenance window.