In this article, you will learn how Virtual WAN with Routing Intent works with the Palo Alto SaaS firewall to connect and route traffic between different networks. You will see how this applies to an Azure VMware Solution private cloud, on-premises sites, and Azure native networks. This article does not cover how to set up or configure Virtual WAN with Routing Intent and Palo Alto SaaS.
Virtual WAN network scenario
Virtual WAN with Routing Intent is only supported with Virtual WAN Standard SKU. Virtual WAN with Routing Intent provides the capability to send all Internet traffic and Private network traffic (RFC 1918 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to a security solution like Azure Firewall, a third-party Network Virtual Appliance (NVA), or Palo Alto SaaS solution. In the scenario, we have a network topology that spans only a single region. There is one Virtual WAN with a single hub(Hub1) and the Hub has the Palo Alto SaaS Firewall deployed. Having a firewall deployed in the Hub is a technical prerequisite to Routing Intent. Virtual WAN Hub1 has Routing Intent enabled.
The diagram shows the Virtual WAN design, which has three components: an Azure VMware Solution Private Cloud, an Azure Virtual Network, and an on-premises site. The Azure VMware Solution and the on-premises site use ExpressRoute to connect to the hub, while the Azure Virtual Network uses a VNet Peering. We will go into more detail about each component later in this document. The design we will go over in this document does not use Global Reach.
Virtual WAN Network Diagram
Note
When configuring Azure VMware Solution with Virtual WAN Hubs, ensure optimal routing results on the hub by setting the Hub Routing Preference option to "AS Path." - see Virtual hub routing preference
ExpressRoute Global Reach deployment options
Global Reach establishes a direct logical link via the Microsoft backbone, connecting Azure VMware Solution to On-Premises.
With Global Reach
A benefit of using Global Reach is that it makes the design simpler with a direct logical connection between Azure VMware Solution and on-premises. It also helps troubleshoot traffic between Global Reach sites and removes the worry of throughput limitations at the Virtual WAN Hub level.
When Global Reach is deployed, traffic between the Global Reach sites bypasses Virtual WAN Hub Firewall. This means the Virtual WAN Hub firewall will not inspect any Global Reach traffic that goes between the Azure VMware Solution and the On-Premises datacenter.
Virtual WAN Network Diagram with Global Reach
Note
When utilizing Global Reach, traffic between these locations bypasses the Virtual WAN and the Hub Firewall. To ensure optimal security, we recommend inspecting traffic within the Azure VMware Solution environment's NSX-T or using an on-premises firewall between these locations.
Without Global Reach
In regions without Global Reach support or with a security requirement to inspect traffic between Azure VMware Solution and on-premises at the hub firewall, a support ticket must be opened to enable ExpressRoute to ExpressRoute transitivity. Once the support ticket has been fulfilled, the Virtual WAN Hub will advertise the default RFC 1918 addresses to Azure VMware Solution and to on-premises (as shown below in the diagram). ExpressRoute to ExpressRoute transitivity isn't supported by default with Virtual WAN with Routing Intent. Transit connectivity between ExpressRoute circuits with routing intent. When using Virtual WAN Routing-Intent without Global Reach, from an on-premises network, you cannot advertise the exact default RFC 1918 address prefixes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) back to Azure. Instead, you must always advertise more specific routes.
To demonstrate how the hub firewall can inspect traffic, the design we will go over in this document does not use Global Reach.
Virtual WAN Network Diagram without Global Reach
Azure VMware Solution connectivity
In this section, we explain how Azure VMware Solution behaves with Routing Intent. We also show examples of NSX-T Tier-0 route table and Palo Alto Cloud NGFW inspection. The diagram shows how the Virtual WAN Hub1 advertises the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to Azure VMware Solution. Unless Azure VMware Solution has a more specific route, it will use the default RFC 1918 addresses to send the traffic back to Hub1.
AVS NSX-T Tier-0 Route Table
The NSX-T Tier-0 has two BGP peerings with ECMP enabled, which results in two routes for each prefix.
The yellow routes indicate that NSX-T Tier-0 has learned the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). These routes will be used by Azure VMware Solution if it lacks a more specific route to the destination. Azure VMware Solution does not learn the on-premises network, 10.234.151.0/24, which is expected as the hub does not advertise this route. Thus, Azure VMware Solution uses the 10.0.0.0/8 route to reach on-premises.
As you can see highlighted in green, Azure VMWare Solution learns the Hub1 network (10.2.0.0/16) and the Spoke VNet (10.255.231.192/28).
Palo Alto Traffic Inspection
The following screenshots show examples of traffic being inspected on the firewall.
Traffic going from the Azure VMware Solution VM to the Azure VNet VM
Traffic going from the Azure VMware Solution VM to the On-Premises VM
On-premises connectivity
In this section, we explain how the on-premises site behaves with Routing Intent. We also show examples of the on-premises route table and Palo Alto Cloud NGFW inspection. The diagram shows how the Virtual WAN Hub1 advertises the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to on-premises. Unless on-premises has a specific route, it will use the default RFC 1918 addresses to send the traffic back to Hub1. You cannot advertise the default RFC 1918 prefixes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) from your on-premises network to Azure; you must advertise more specific routes instead.
To simulate an on-premises environment, I created a virtual machine (VM) in a Google Cloud virtual private cloud (VPC) and connected it to a MegaPort MCR (Megaport Cloud Router).
On-Premises Route Table
The yellow routes indicate that the Google Cloud VPC has learned the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). These routes will be used if it lacks a more specific route to the destination. The on-premises site does not learn the Azure VMware Solution network, 192.168.101.0/24, which is expected as the hub does not advertise this route. Thus, on-premises uses the 192.168.0.0/16 route to reach Azure VMware Solution.
As you can see highlighted in green, on-premises learns the Hub1 network (10.2.0.0/16) and the Spoke VNet (10.255.231.192/28).
Palo Alto Traffic Inspection
The following screenshots show examples of traffic being inspected on the firewall.
Traffic going from the on-premises VM to the Azure VMware Solution VM
Traffic going from the on-premises VM to the Azure VNet VM
Azure Virtual Network connectivity
In this section, we explain how the Azure VNet behaves with Routing Intent. The diagram shows how the Virtual WAN Hub1 advertises the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to the Spoke VNet.
Azure VNet VM Effective Routes
The yellow routes indicate that the Azure VNet VM has learned the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). The VNet will learn only the default RFC 1918 addresses and not learn any specific routes. As you can see highlighted in green, the Azure VM learns the Hub1 network (10.2.0.0/16) because the Spoke VNet is directly peered with Hub1.
Palo Alto Traffic Inspection
The following screenshots show examples of traffic being inspected on the firewall.
Traffic going from the Azure VNet VM to the on-premises VM
Traffic going from the Azure VNet VM to the Azure VMware Solution VM
Internet connectivity
This section focuses only on how internet connectivity is provided for Azure native resources in Virtual Networks and Azure VMware Solution. There are several options to provide internet connectivity to Azure VMware Solution. - see Internet Access Concepts for Azure VMware Solution
Option 1: Internet Service hosted in Azure
Option 2: VMware Solution Managed SNAT
Option 3: Azure Public IPv4 address to NSX-T Data Center Edge
Although you can use all three options with Virtual WAN with Routing Intent, "Option 1: Internet Service hosted in Azure" is the best option when using Virtual WAN with Routing Intent and is the option that is used to provide internet connectivity in the scenario.
As mentioned earlier, when you enable Routing Intent on the Hub, it advertises RFC 1918 to all peered Virtual Networks. However, you can also advertise a default route 0.0.0.0/0 for internet connectivity to downstream resources as shown in the diagram below. The default route is advertised to both the Spoke VNet and Azure VMware Solution.
Below is an example of a screenshot showing the SNAT Public IP address 172.174.86.127 (highlighted in green) that is assigned to the Palo Alto SaaS Firewall. The private IP address 10.2.112.4 (highlighted in yellow) is the internal IP that is used as the next hop to the firewall.
You can choose to advertise the default route over specific ExpressRoute connections. We recommend not to advertise the default route to your on-premises ExpressRoute connections. In our scenario, we are allowing the advertisement of the default route over the "AVS Managed ExpressRoute circuit". You can find this setting under the Hub/ExpressRoute and then you can edit the ExpressRoute. By changing the "Propagate Default Route" to "Enable", we allow the advertisement of the default route over this connection.
AVS NSX-T Tier-0 Route Table
As you can see below the default route 0.0.0.0/0 is being learned within AVS on the NSX-T Tier-0 router.
Azure VNet VM Effective Routes
As you can see below highlighted in blue, the default route 0.0.0.0/0 is being learned on the Azure VM on the Spoke VNet.
The example below shows the Azure VM running a curl ifconfig.me with the result of the Public IP address 172.174.86.27 which is the public IP assigned to the SaaS Firewall.
Traffic being inspected on Palo Alto SaaS Firewall going from the Azure VNet VM to the internet destined to 8.8.8.8 on port 443.
The example below shows the AVS VM running a curl ifconfig.me with the result of the Public IP address 172.174.86.27 which is the public IP assigned to the SaaS Firewall.
Traffic being inspected on Palo Alto SaaS Firewall going from the AVS VM to the internet destined to 8.8.8.8 on port 443.
Wrapping Up
In conclusion, the Routing Intent feature will send the default RFC 1918 addresses over peered virtual networks and over ExpressRoute connections if the hub has ExpressRoute to ExpressRoute connectivity enabled via a support ticket. The hub will learn more specific routes from on-premises, Azure VMware Solution, and Virtual Networks. The hub will send all traffic to the Palo Alto SaaS firewall for inspection and routing. The default route will be advertised only to the Azure VMware Solution and the peered virtual networks. The Azure VMware Solution and the Virtual Network VMs will use the SaaS firewall for internet connectivity.
Next steps
- For more information on Virtual WAN hub configuration, see About virtual hub configuration.
- For more information on how to configure the Palo Alto Next Generation SAAS firewall on Virtual WAN, see Configure Palo Alto Networks Cloud NGFW in Virtual WAN.
- For more information on Virtual WAN hub routing intent configuration, see Configure routing intent and policies through Virtual WAN portal.
Please let me know if you have any questions or comments
Jason Medina