This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.
This article describes the best practices for connectivity, traffic flows, and high availability of dual-region Azure VMware Solution when using Azure Secure Virtual WAN with Routing Intent and Global Reach. This article breaks down Virtual WAN with Routing Intent topology from the perspective of Azure VMware Solution private clouds, on-premises sites, and Azure native. The implementation and configuration of Secure Virtual WAN with Routing Intent are beyond the scope and are not discussed in this document.
The document assumes readers have a basic understanding of Virtual WAN and Secure Virtual WAN with Routing Intent.
Virtual WAN
Virtual WAN Routing Intent
How to configure Virtual WAN Hub routing intent and routing policies
Secure Virtual WAN with Routing Intent is only supported with Virtual WAN Standard SKU. Secure Virtual WAN with Routing Intent provides the capability to send all Internet traffic and Private network traffic to a security solution like Azure Firewall, a third-party Network Virtual Appliance (NVA), or SaaS solution. In the scenario, we have a network topology that spans two regions. There is one Virtual WAN with two Hubs, Hub1 and Hub2. Hub1 is in Region 1, and Hub2 is in Region 2. Each Hub has its own instance of Azure Firewall deployed(Hub 1 Firewall, Hub 2 Firewall), essentially making them each Secure Virtual WAN Hubs. Having Secure Virtual WAN hubs is a technical prerequisite to Routing Intent. Secure Virtual WAN Hub1 and Hub2 have Routing Intent enabled.
Note
When configuring Azure VMware Solution with Secure 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
Each region has its own Azure VMware Solution Private Cloud and an Azure Virtual Network. Additionally, there is an on-premises site connecting to both regions. Furthermore, Global Reach connectivity exists within the environment. Global Reach establishes a direct logical link via the Microsoft backbone, connecting Azure VMware Solution to on-premises or regional Azure VMware Solution Private Clouds. As shown in the diagram below, Global Reach connections do not transit Hub Firewall 1 and Hub Firewall 2. Consequently, Global Reach traffic between sites is not inspected.
Note
When utilizing Global Reach, consider enhancing security between Global Reach sites by inspecting traffic within the Azure VMware Solution environment’s NSX-T or an on-premises firewall.
| Connection | Description |
|---|---|
| Connections (D) | Azure VMware Solution private cloud connection to its local regional hub. |
| Connection (A) | Azure VMware Solution Region 1 Global Reach connection back to on-premises. |
| Connection (B) | Azure VMware Solution Region 2 Global Reach connection back to on-premises. |
| Connection (C) | Azure VMware Solution Global Reach connection between the two private clouds' managed circuits. |
| Connections (E) | on-premises connectivity via ExpressRoute to both regional hubs. |
| Inter-Hub | Inter-Hub logical connection between two hubs that are deployed under the same Virtual WAN. |
The following sections cover traffic flows and connectivity for Azure VMware Solution, on-premises, Azure Virtual Networks, and the Internet when using Global Reach.
This section focuses on only the Azure VMware Solution Cloud Region 1 and Azure VMware Solution Cloud Region 2. Each Azure VMware Solution private cloud has an ExpressRoute connection to its local regional hub (connections labeled as "D").
Each Azure VMware Solution Cloud Region connects back to an on-premises via ExpressRoute Global Reach. Azure VMware Solution Cloud Region 1 Global Reach connection is shown as "Global Reach (A)". The Azure VMware Solution Cloud Region 2 Global Reach connection is shown as "Global Reach (B)". Both Azure VMware Solution private clouds are connected directly to each other via Global Reach shown as Global Reach (C). Keep in mind that Global Reach traffic will never transit any hub firewalls.
Ensure that you explicitly configure Global Reach (A), Global Reach (B), and Global Reach (C). It is imperative to do this to prevent connectivity issues between Global Reach sites. See traffic flow section for more information.
The diagram below illustrates traffic flows from the perspective of the Azure VMware Solution Private Clouds.
Traffic Flow Chart
| Traffic Flow Number | Source | Direction | Destination | Traffic Inspected on Secure Virtual WAN hub firewall? |
|---|---|---|---|---|
| 1 | Azure VMware Solution Cloud Region 1 | → | Virtual Network 1 | Yes, traffic is inspected at Hub 1 firewall |
| 2 | Azure VMware Solution Cloud Region 1 | → | on-premises | No, traffic bypasses firewall and transits Global Reach (A) |
| 3 | Azure VMware Solution Cloud Region 1 | → | Virtual Network 2 | Yes, traffic is inspected at Hub 2 firewall |
| 4 | Azure VMware Solution Cloud Region 1 | → | Azure VMware Solution Cloud Region 2 | No, traffic bypasses firewall and transits Global Reach (C) |
| 5 | Azure VMware Solution Cloud Region 2 | → | Virtual Network 1 | Yes, traffic is inspected at Hub 1 firewall |
| 6 | Azure VMware Solution Cloud Region 2 | → | Virtual Network 2 | Yes, traffic is inspected at Hub 2 firewall |
| 7 | Azure VMware Solution Cloud Region 2 | → | on-premises | No, traffic bypasses firewall and transits Global Reach (B) |
This section focuses only on the on-premises site. As shown in the diagram, the on-premises site has an ExpressRoute connection to both Region 1 and Region 2 hubs (connections labeled as "E").
On-premises systems can communicate to Azure VMware Solution Cloud Region 1 via connection "Global Reach (A)". On-premises systems are also able to communicate with Azure VMware Solution Cloud Region 2 via connection "Global Reach (B)".
Ensure that you explicitly configure Global Reach (A), Global Reach (B), and Global Reach (C). It is imperative to do this to prevent connectivity issues between Global Reach sites. See traffic flow section for more information.
The diagram below illustrates traffic flows from an on-premises perspective.
Traffic Flow Chart
| Traffic Flow Number | Source | Direction | Destination | Traffic Inspected on Secure Virtual WAN hub firewall? |
|---|---|---|---|---|
| 2 | on-premises | → | Azure VMware Solution Cloud Region 1 | No, traffic bypasses firewall and transits Global Reach (A) |
| 7 | on-premises | → | Azure VMware Solution Cloud Region 2 | No, traffic bypasses firewall and transits Global Reach (B) |
| 8 | on-premises | → | Virtual Network 1 | Yes, traffic is inspected at Hub 1 firewall |
| 9 | on-premises | → | Virtual Network 2 | Yes, traffic is inspected at Hub 2 firewall |
This section focuses only on connectivity from an Azure Virtual Network perspective. As depicted in the diagram, both Virtual Network1 and Virtual Network2 have a Virtual Network peering directly to their local regional hub.
A Secure Hub with enabled Routing Intent always sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to peered Virtual Networks, plus any other prefixes that have been added as "Private Traffic Prefixes" - see Routing Intent Private Address Prefixes. In our scenario, with Routing Intent enabled, all resources in Virtual Network 1 and Virtual Network 2 currently possess the default RFC 1918 addresses and use their local regional hub firewall as the next hop. All traffic ingressing and egressing the Virtual Networks will always transit the Hub Firewalls. See traffic flow section for more information.
Traffic Flow Chart
| Traffic Flow Number | Source | Direction | Destination | Traffic Inspected on Secure Virtual WAN hub firewall? |
|---|---|---|---|---|
| 1 | Virtual Network 1 | → | Azure VMware Solution Cloud Region 1 | Yes, traffic is inspected at Hub 1 firewall |
| 3 | Virtual Network 2 | → | Azure VMware Solution Cloud Region 1 | Yes, traffic is inspected at Hub 2 firewall |
| 5 | Virtual Network 1 | → | Azure VMware Solution Cloud Region 2 | Yes, traffic is inspected at Hub 1 firewall |
| 6 | Virtual Network 2 | → | Azure VMware Solution Cloud Region 2 | Yes, traffic is inspected at Hub 2 firewall |
| 8 | Virtual Network 1 | → | on-premises | Yes, traffic is inspected at Hub 1 firewall |
| 9 | Virtual Network 2 | → | on-premises | Yes, traffic is inspected at Hub 2 firewall |
| 10 | Virtual Network 1 | → | Virtual Network 2 | Yes, traffic is inspected at the Hub 1 firewall, then flows over the inter-hub connection to be inspected by Hub 2 firewall |
This section focuses only on how internet connectivity is provided for Azure native resources in Virtual Networks and Azure VMware Solution Private Clouds in both regions. 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 Dual Region Secure Virtual WAN with Routing Intent, "Option 1: Internet Service hosted in Azure" is the best option when using Secure Virtual WAN with Routing Intent and is the option that is used to provide internet connectivity in the scenario.
With Routing Intent you have the option to generate a default route from the hub firewall. This default route is advertised to your Virtual Networks and Azure VMware Solution private clouds. This section is broken into two sections, one that explains internet connectivity from an Azure VMware Solution perspective and another from the Virtual Network perspective.
From an Azure VMware Solution Private Cloud perspective, you have the availability to achieve internet connectivity redundancy because it will learn the default route from both its local regional hub and its cross-regional hub. However, the Azure VMware Solution private cloud will always prioritize the local regional hub for primary internet access connectivity. Its cross-regional hub will serve as an internet backup in the event the local regional hub is down. This setup provides internet access redundancy for outbound traffic only. For inbound internet traffic to Azure VMware Solution workloads, consider using Azure Front Door or Traffic Manager in case of a regional outage.
Going into more detail, the Azure VMware Solution private cloud's preferred default route "∞ 0.0.0.0/0" is received via connection "D" from its local regional hub. Additionally, the Azure VMware Solution private cloud receives a backup default route "△ 0.0.0.0/0," which originates on the cross-regional hub and advertised across the Global Reach (C) connection. Ensure that you explicitly configure Global Reach (A), Global Reach (B), and Global Reach (C). It is imperative to do this to prevent connectivity issues between Global Reach sites.
When Routing Intent is enabled for internet traffic, the default behavior of the Secure Virtual WAN Hub is to not advertise the default route across ExpressRoute circuits. To ensure the default route is propagated to the Azure VMware Solution from the Azure Virtual WAN, you must enable default route propagation on your Azure VMware Solution ExpressRoute circuits - see To advertise default route 0.0.0.0/0 to endpoints. It is important to note that this setting should not be enabled for on-premises ExpressRoute circuits. Even though connection "D" will advertise the default route "∞ 0.0.0.0/0" to the Azure VMware Solution private clouds, the default route will also be advertised to on-premises via Global Reach (A) and Global Reach (B). As a result, it is recommended to implement a BGP Filter on your on-premises equipment to exclude learning the default route. This ensures that on-premises internet connectivity is not impacted.
Each Virtual Network will egress to the internet using its local regional hub firewall. When Routing Intent for internet access is enabled, the default route generated from the Secure VWAN Hub is automatically advertised to the hub-peered Virtual Network connections. However, this default route is never advertised across regional hubs over the ‘inter-hub’ link. Therefore, Virtual Networks can only use their local regional hub for internet access and will have no backup internet connectivity to the cross-regional hub. For further details, refer to the traffic flow section.
Traffic Flow Chart
| Traffic Flow Number | Source | Direction | Destination | Traffic Inspected on Secure Virtual WAN hub firewall? | Internet Breakout |
|---|---|---|---|---|---|
| 11 | Azure VMware Solution Cloud Region 1 | → | Internet | Yes, traffic is inspected at Hub 1 firewall | Via Hub 1 firewall |
| 12 | Azure VMware Solution Cloud Region 2 | → | Internet | Yes, traffic is inspected at Hub 2 firewall | Via Hub 2 firewall |
| 15 | Virtual Network 1 | → | Internet | Yes, traffic is inspected at Hub 1 firewall | Via Hub 1 firewall |
| 16 | Virtual Network 2 | → | Internet | Yes, traffic is inspected at Hub 2 firewall | Via Hub 2 firewall |
The traffic flow described below is only valid if there is an outage affecting a local regional hub. For instance, if the local regional hub of Azure VMware Solution experiences an outage, internet traffic will be rerouted to the cross-regional hub for internet connectivity.
| Traffic Flow Number | Source | Direction | Destination | Traffic Inspected on Secure Virtual WAN hub firewall? | Internet Breakout |
|---|---|---|---|---|---|
| 13 | Azure VMware Solution Cloud Region 1 | → | Internet | Yes, traffic will transit Global Reach (C) and inspected at Hub 2 firewall | Via Hub 2 firewall |
| 14 | Azure VMware Solution Cloud Region 2 | → | Internet | Yes, traffic will transit Global Reach (C) and inspected at Hub 1 firewall | Via Hub 1 firewall |
- For more information on Virtual WAN hub configuration, see About virtual hub settings.
- For more information on how to configure Azure Firewall in a Virtual Hub, see Configure Azure Firewall in a Virtual WAN hub.
- 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.