This text describes the very best practices for connectivity and site visitors flows with single-region Azure VMware Resolution when utilizing Azure Safe Digital WAN with Routing Intent. You be taught the design particulars of utilizing Safe Digital WAN with Routing-Intent with out International Attain. This text breaks down Digital WAN with Routing Intent topology from the attitude of an Azure VMware Resolution non-public cloud, on-premises websites, and Azure native. The implementation and configuration of Safe Digital WAN with Routing Intent are past the scope and are not mentioned on this doc.
In areas with out International Attain help or with a safety requirement to examine site visitors between Azure VMware Resolution and on-premises on the hub firewall, a help ticket have to be opened to allow ExpressRoute to ExpressRoute transitivity. ExpressRoute to ExpressRoute transitivity is not supported by default with Digital WAN. – see Transit connectivity between ExpressRoute circuits with routing intent
Safe Digital WAN with Routing Intent is simply supported with Digital WAN Commonplace SKU. Safe Digital WAN with Routing Intent supplies the aptitude to ship all Web site visitors and Personal community site visitors (RFC 1918) to a safety resolution like Azure Firewall, a third-party Community Digital Equipment (NVA), or SaaS resolution. Within the state of affairs, we have now a community topology that spans a single area. There’s one Digital WAN with a single hub positioned within the Area. The Hub has its personal occasion of an Azure Firewall deployed, primarily making it a Safe Digital WAN Hub. Having a Safe Digital WAN hub is a technical prerequisite to Routing Intent. The Safe Digital WAN Hub has Routing Intent enabled.
The only area additionally has an Azure VMware Resolution Personal Cloud and an Azure Digital Community. There’s additionally an on-premises web site connecting to the area, which we evaluation in additional element later on this doc.
Word
If you happen to’re utilizing non-RFC1918 prefixes in your linked on-premises, Digital Networks or Azure VMware Resolution, be sure you have specified these prefixes within the “Personal Visitors Prefixes” textual content field for Routing Intent. Remember the fact that it is best to all the time enter summarized routes solely within the “Personal Visitors Prefixes” part to cowl your vary. Don’t enter the precise vary that’s being marketed to Digital WAN as this will result in routing points. For instance, if the ExpressRoute Circuit is promoting 40.0.0.0/24 from on-premises, put a /23 CIDR vary or bigger within the Personal Visitors Prefix textual content field (instance: 40.0.0.0/23). – see Configure routing intent and insurance policies by means of Digital WAN portal
Word
When configuring Azure VMware Resolution with Safe Digital WAN Hubs, guarantee optimum routing outcomes on the hub by setting the Hub Routing Choice choice to “AS Path.” – see Digital hub routing desire
| Connection | Description |
|---|---|
| Connections (D) | Azure VMware Resolution non-public cloud managed ExpressRoute connection to the hub. |
| Connections (E) | on-premises ExpressRoute connection to the hub. |
The next sections cowl site visitors flows and connectivity for Azure VMware Resolution, on-premises, Azure Digital Networks, and the Web.
This part focuses on solely the Azure VMware Resolution non-public cloud. The Azure VMware Resolution non-public cloud has an ExpressRoute connection to the hub (connections labeled as “D”).
With ExpressRoute to ExpressRoute transitivity enabled on the Safe Hub and Routing-Intent enabled, the Safe Hub sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to Azure VMware Resolution over connection “D”. Along with the default RFC 1918 addresses, Azure VMware Resolution learns extra particular routes from Azure Digital Networks and Department Networks (S2S VPN, P2S VPN, SDWAN) which can be linked to the hub. Azure VMware Resolution would not be taught particular routes from on-premises networks. For routing site visitors again to on-premises networks, it makes use of the default RFC 1918 addresses that it discovered from connection “D”. This site visitors transits by means of the Hub firewall, as proven within the diagram. The Hub firewall has the precise routes for on-premises networks and routes site visitors towards the vacation spot over connection “E”. Visitors from Azure VMware Resolution, heading in the direction of Digital Networks, will transit the Hub firewall. For extra data, see the site visitors move part.
The diagram illustrates site visitors flows from the attitude of the Azure VMware Resolution Personal Cloud.
Visitors Move Chart
| Visitors Move Quantity | Supply | Path | Vacation spot | Visitors Inspected on Safe Digital WAN Hub firewall? |
|---|---|---|---|---|
| 1 | Azure VMware Resolution Cloud | → | Digital Community | Sure, site visitors is inspected on the Hub firewall |
| 2 | Azure VMware Resolution Cloud | → | on-premises | Sure, site visitors is inspected on the Hub firewall |
This part focuses solely on the on-premises web site. As proven within the diagram, the on-premises web site has an ExpressRoute connection to the hub (connection labeled as “E”).
With ExpressRoute to ExpressRoute transitivity enabled on the Safe Hub and Routing-Intent enabled, the Safe Hub sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to on-premises over connection “E”. Along with the default RFC 1918 addresses, on-premises learns extra particular routes from Azure Digital Networks and Department Networks (S2S VPN, P2S VPN, SDWAN) which can be linked to the hub. On-premises would not be taught particular routes from Azure VMware Resolution networks. For routing site visitors again to Azure VMware Resolution networks, it makes use of the default RFC 1918 addresses that it discovered from connection “E”. This site visitors transits by means of the Hub firewall, as proven within the diagram. The Hub firewall has the precise routes for Azure VMware Resolution networks and routes site visitors towards the vacation spot over connection “D”. Visitors from on-premises, heading in the direction of Digital Networks, will transit the Hub firewall. For extra data, see the site visitors move part for extra detailed data.
As talked about earlier, once you allow ExpressRoute to ExpressRoute transitivity on the Hub, it sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to your on-premises community. Due to this fact, you should not promote the precise RFC 1918 prefixes (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) again to Azure. Promoting the identical actual routes creates routing issues inside Azure. As an alternative, it is best to promote extra particular routes again to Azure to your on-premises networks.
Word
If you happen to’re presently promoting the default RFC 1918 addresses from on-premises to Azure and want to proceed this follow, it is advisable to break up every RFC 1918 vary into two equal sub-ranges and promote these sub-ranges again to Azure. The sub-ranges are 10.0.0.0/9, 10.128.0.0/9, 172.16.0.0/13, 172.24.0.0/13, 192.168.0.0/17, and 192.168.128.0/17.
The diagram illustrates site visitors flows from the attitude of on-premises.
Visitors Move Chart
| Visitors Move Quantity | Supply | Path | Vacation spot | Visitors Inspected on Safe Digital WAN Hub firewall? |
|---|---|---|---|---|
| 3 | on-premises | → | Azure VMware Resolution Cloud | Sure, site visitors is inspected on the Hub firewall |
| 4 | on-premises | → | Digital Community | Sure, site visitors is inspected on the Hub firewall |
This part focuses solely on connectivity from an Azure Digital Community perspective. As depicted within the diagram, the Digital Community has a Digital Community peering on to the hub.
The diagram illustrates how all Azure native sources within the Digital Community be taught routes beneath their “Efficient Routes”. A Safe Hub with Routing Intent enabled all the time sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to peered Digital Networks. Azure native sources within the Digital Community do not be taught particular routes from outdoors of their Digital Community. With Routing Intent enabled, all sources within the Digital Community presently possess the default RFC 1918 tackle and use the hub firewall as the following hop. All site visitors ingressing and egressing the Digital Networks will all the time transit the Hub Firewall. For extra data, see the site visitors move part for extra detailed data.
The diagram illustrates site visitors flows from an Azure Digital Community perspective.
Visitors Move Chart
| Visitors Move Quantity | Supply | Path | Vacation spot | Visitors Inspected on Safe Digital WAN Hub firewall? |
|---|---|---|---|---|
| 5 | Digital Community | → | Azure VMware Resolution Cloud | Sure, site visitors is inspected on the Hub firewall |
| 6 | Digital Community | → | on-premises | Sure, site visitors is inspected on the Hub firewall |
This part focuses solely on how web connectivity is supplied for Azure native sources in Digital Networks and Azure VMware Resolution Personal Clouds in a single area. There are a number of choices to offer web connectivity to Azure VMware Resolution. – see Web Entry Ideas for Azure VMware Resolution
Choice 1: Web Service hosted in Azure
Choice 2: VMware Resolution Managed SNAT
Choice 3: Azure Public IPv4 tackle to NSX-T Knowledge Heart Edge
Though you should utilize all three choices with Single Area Safe Digital WAN with Routing Intent, “Choice 1: Web Service hosted in Azure” is the best choice when utilizing Safe Digital WAN with Routing Intent and is the choice that’s used to offer web connectivity within the state of affairs. The rationale why “Choice 1” is taken into account the best choice with Safe Digital WAN is because of its ease of safety inspection, deployment, and manageability.
As talked about earlier, once you allow Routing Intent on the Safe Hub, it advertises RFC 1918 to all peered Digital Networks. Nevertheless, you may as well promote a default route 0.0.0.0/0 for web connectivity to downstream sources. With Routing Intent, you may select to generate a default route from the hub firewall. This default route is marketed to your Digital Community and to Azure VMware Resolution. This part is damaged into two sections, one which explains web connectivity from an Azure VMware Resolution perspective and one other from the Digital Community perspective.
When Routing Intent is enabled for web site visitors, the default habits of the Safe Digital WAN Hub is to not promote the default route throughout ExpressRoute circuits. To make sure the default route is propagated to the Azure VMware Resolution from the Azure Digital WAN, you could allow default route propagation in your Azure VMware Resolution ExpressRoute circuits – see To promote default route 0.0.0.0/0 to endpoints. As soon as adjustments are full, the default route 0.0.0.0/0 is then marketed by way of connection “D” from the hub. It’s vital to notice that this setting should not be enabled for on-premises ExpressRoute circuits. As a greatest follow, it is really helpful to implement a BGP Filter in your on-premises gear. A BGP Filter in place prevents the inadvertent studying of the default route, provides an additional layer of precaution, and ensures that on-premises web connectivity is not impacted.
When Routing Intent for web entry is enabled, the default route generated from the Safe Digital WAN Hub is routinely marketed to the hub-peered Digital Community connections. You will discover beneath Efficient Routes for the Digital Machines’ NICs within the Digital Community that the 0.0.0.0/0 subsequent hop is the hub firewall.
For extra data, see the site visitors move part.
The diagram illustrates site visitors flows from a Digital Community and Azure VMware Resolution perspective.
Visitors Move Chart
| Visitors Move Quantity | Supply | Path | Vacation spot | Visitors Inspected on Safe Digital WAN hub firewall? |
|---|---|---|---|---|
| 7 | Digital Community | → | Web | Sure, site visitors is inspected on the Hub firewall |
| 8 | Azure VMware Resolution Cloud | → | Web | Sure, site visitors is inspected on the Hub firewall |
HCX Mobility Optimized Networking (MON) is an elective function to allow when utilizing HCX Community Extensions (NE). Mobility Optimized Networking (MON) supplies optimum site visitors routing beneath sure eventualities to forestall community tromboning between the on-premises-based and cloud-based sources on prolonged networks.
Enabling Mobility Optimized Networking (MON) for a selected prolonged community and a digital machine adjustments the site visitors move. After implementing Mobility Optimized Networking (MON), egress site visitors from that digital machine doesn’t trombone again to on-premises. As an alternative, it bypasses the Community Extensions (NE) IPSEC tunnel. Visitors for that digital machine will now egress out of the Azure VMware Resolution NSX-T Tier-1 Gateway> NSX-T Tier-0 Gateway>Azure Digital WAN.
Enabling Mobility Optimized Networking (MON) for a selected prolonged community and a digital machine leads to a change. From Azure VMware Resolution NSX-T, it injects a /32 host route again to Azure Digital WAN. Azure Digital WAN advertises this /32 route again to on-premises, Digital Networks, and Department Networks (S2S VPN, P2S VPN, SDWAN). The aim of this /32 host route is to make sure that site visitors from on-premises, Digital Networks, and Department Networks would not use the Community Extensions (NE) IPSEC tunnel when destined for the Mobility Optimized Networking (MON) enabled Digital Machine. Visitors from supply networks is directed straight to the Mobility Optimized Networking (MON) enabled Digital Machine because of the /32 route that’s discovered.
With ExpressRoute to ExpressRoute transitivity enabled on the Safe Hub and Routing-Intent enabled, the Safe Hub sends the default RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) to each the on-premises and Azure VMware Resolution. Along with the default RFC 1918 addresses, each on-premises and Azure VMware Resolution be taught extra particular routes from Azure Digital Networks and Department Networks (S2S VPN, P2S VPN, SDWAN) which can be linked to the hub. Nevertheless, on-premises networks do not be taught any particular routes from the Azure VMware Resolution, nor does the reverse happen. As an alternative, each environments depend on the default RFC 1918 addresses to facilitate routing again to at least one one other by way of the Hub firewall. Which means extra particular routes, corresponding to HCX Mobility Optimized Networking (MON) Host Routes, aren’t marketed from the Azure VMware Resolution ExpressRoute to the on-premises-based ExpressRoute circuit and vice-versa. The shortcoming to be taught particular routes introduces uneven site visitors flows. Visitors egresses Azure VMware Resolution by way of the NSX-T Tier-0 gateway, however returning site visitors from on-premises returns over the Community Extensions (NE) IPSEC tunnel.
To appropriate any site visitors asymmetry, it is advisable to regulate the HCX Mobility Optimized Networking (MON) Coverage Routes. Mobility Optimized Networking (MON) coverage routes decide which site visitors goes again to the on-premises Gateway by way of an L2 extension. Additionally they determine which site visitors is routed by means of the Azure VMware Resolution NSX Tier-0 Gateway.
If a vacation spot IP matches and is ready to “permit” within the Mobility Optimized Networking (MON) coverage configuration, then two actions happen. First, the packet is recognized. Second, it is despatched to the on-premises gateway by means of the HCX Community Extension equipment.
If a vacation spot IP would not match, or is ready to “deny” within the Mobility Optimized Networking (MON) coverage, the system sends the packet to the Azure VMware Resolution Tier-0 for routing.
HCX Coverage Routes
| Community | Redirect to Peer | Word |
|---|---|---|
| Azure Digital Community Deal with House | Deny | Please guarantee to explicitly embody the tackle ranges for all of your Digital Networks. Visitors supposed for Azure is directed out by way of the Azure VMware Resolution and would not return to the on-premises community. |
| Default RFC 1918 Deal with Areas | Enable | Add within the default RFC 1918 addresses 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. This configuration ensures that any site visitors not matching the above standards is rerouted again to the on-premises community. In case your on-premises setup makes use of addresses that are not a part of RFC 1918, you could explicitly embody these ranges. |
| 0.0.0.0/0 | Deny | For addresses that aren’t lined by RFC 1918, corresponding to Web-routable IPs, or any site visitors that doesn’t match the desired entries above, exits immediately by means of the Azure VMware Resolution and is not redirected again to the on-premises community. |
