AVS HCX Migration Connectivity via Azure VPN Gateway in Hub VNet—Supported Design

Hi Paul,

Your design is mostly supported and aligns with Microsoft's reference architectures for hybrid connectivity and AVS migrations using VMware HCX. There are important limitations, and recommendations that need to be considered to ensure a fully functional and supportable configuration.

Site-to-Site VPN is supported for AVS connectivity and HCX migrations, but it is not recommended for production-scale migrations. VPN connections have higher latency, lower throughput, and are less reliable compared to ExpressRoute. Microsoft and VMware recommend ExpressRoute for production HCX migrations, especially for large workloads or latency-sensitive applications.

VPN bandwidth is typically limited (often 1 Gbps or less per tunnel), which can bottleneck large migrations. ExpressRoute offers much higher, dedicated bandwidth. vMotion over VPN is NOT supported by HCX. It requires high throughput and low latency, only supported with ExpressRoute.

Is it correct that BGP routes from the AVS ExpressRoute connection will propagate into the Hub VNet and, by extension, to Spoke VNets if peering is configured with route propagation?

Yes — BGP route propagation works as follows:

• AVS exposes BGP-learned prefixes via Private Peering on the ExpressRoute circuit.
• When you do “Add VNet Connection” in AVS, it establishes a route table injection into the Hub VNet.
• If you enable Use remote gateway and Allow gateway transit in VNet peering, these routes can propagate to Spoke VNets**.**https://free.blessedness.top/en-us/azure/route-server/expressroute-vpn-support

Also, see General design considerations and recommendations

Hub-spoke vs. Virtual WAN network topology

If you don't have an ExpressRoute connection from on-premises to Azure and you're instead using S2S VPN, you can use Virtual WAN to transit connectivity between your on-premises VPN and the Azure VMware Solution ExpressRoute. If you're using a hub-spoke topology, you need Azure Route Server. For more information, see Azure Route Server support for ExpressRoute and Azure VPN.

HCX communication relies on L3 IP reachability and port access. Routing traffic through Azure Firewall is fine, as long as:

Required HCX ports are opened

Traffic is correctly NATed or routed

HCX Mobility Optimized Networking (MON) is an optional feature to enable when using HCX Network Extensions (NE). MON provides optimal traffic routing under certain scenarios to prevent network tromboning between the on-premises and cloud-based resources on extended networks.

Internet Access for AVS-Hosted VMs

• Options:
  • Azure VMware Solution Managed SNAT: Microsoft-managed outbound NAT for AVS VMs. Simple, but limited control and visibility.https://free.blessedness.top/en-us/azure/azure-vmware/architecture-design-public-internet-access
  • Internet Service Hosted in Azure: Use Azure Firewall or a third-party NVA in the Hub VNet to provide outbound internet access. This is the most common and recommended pattern for centralized security and logging.
  • Public IP to NSX-T Edge: Assign a public IP directly to NSX-T Edge for direct internet access (less common, more exposure).
• Best Practice: Route all AVS VM internet-bound traffic through Azure Firewall in the Hub VNet. Use UDRs to direct default (0.0.0.0/0) traffic from AVS towards the firewall, ensuring security and compliance.

Your design is supported for connectivity and small-scale migrations, but for production workloads and to avoid unsupported scenarios, ExpressRoute is required for HCX migrations. Proper NSX-T, firewall, and routing configuration is essential for a smooth experience. https://www.provirtualzone.com/migrating-workloads-to-azure-vmware-solution-with-vmware-hcx-a-practical-guide/

Hope it helps!

Let me know if you have any further queries!

If the information is helpful, please click "upvote" to let us know!

May I inquire whether it is possible to utilize User-Defined Routes (UDRs) in place of Azure Route Server for traffic routing? The following is my current understanding.

• Traffic Flow – On-Prem → AVS

On-Prem VM

→

On-Prem VPN Device

→

VPN Tunnel

→

Azure VPN Gateway

→

(UDR: Next hop = Azure Firewall)

→

Azure Firewall

→

(System Route)

→

AVS ExpressRoute

→

AVS vCenter / Workload VM

• Return Traffic Flow – AVS → On-Prem

AVS Workload

→

AVS ExpressRoute

→

Azure Hub VNet

→

(UDR: Next hop = Azure Firewall)

→

Azure Firewall

→

(UDR: Next hop = VPN Gateway)

→

Azure VPN Gateway

→

VPN Tunnel

→

On-Prem VM

• Traffic Flow – Spoke VNet → AVS

Spoke VM

→

(UDR: Next hop = Azure Firewall)

→

Azure Firewall

→

(System Route)

→

AVS

Hi Paul

On-Prem → AVS (via VPN, Azure Firewall, UDRs)

• You can use UDRs in the Hub VNet to direct traffic from the VPN Gateway to Azure Firewall, then rely on system routes to reach the AVS ExpressRoute Gateway.
• This approach is supported for basic traffic inspection and control.
  https://free.blessedness.top/en-us/azure/cloud-adoption-framework/scenarios/azure-vmware/virtual-network-connectivity

AVS → On-Prem (Return Path)

• UDRs can be used to direct return traffic from AVS (via the Hub VNet) through Azure Firewall and then to the VPN Gateway.
• However, AVS itself does not support UDRs; it learns routes dynamically via BGP. This means you must ensure that the correct routes are advertised to AVS via BGP for the return path to function as intended.
• If you rely solely on UDRs in Azure, you may face challenges with route propagation and symmetry, especially as your environment scales or changes.

Spoke VNet → AVS

• UDRs in spoke VNets can direct traffic to Azure Firewall, which then forwards to AVS via system routes.
• This is a common and supported pattern for centralized inspection. https://free.blessedness.top/en-us/azure/cloud-adoption-framework/scenarios/azure-vmware/network-design-guide-intro

As per my understanding, UDRs are suitable for basic traffic steering in Azure, but they cannot fully replace ARS for AVS route propagation and dynamic routing needs. For production or complex scenarios, use ARS to ensure supported and maintainable connectivity.

Hope it helps!

Please tag me if you have any further queries!

If the information is helpful, please click "upvote" to let us know!

I have deployed Azure VMware Solution (AVS) and configured hybrid connectivity as follows:

On-premises connectivity: Site-to-Site VPN to Azure Hub VNet using Azure VPN Gateway (BGP enabled)

AVS connectivity: AVS ExpressRoute circuit linked to Hub VNet (using express route gateway and expressroute connection)

Routing: Manual UDRs forcing all traffic through Azure Firewall for inspection

Firewall: Network rules permitting required ports for AVS management and HCX

Current Status:

From Azure Hub and Spoke VNets, I can successfully access the AVS vCenter URL and other management interfaces.

However, from an on-premises VM, the vCenter URL is not reachable.

Request for Assistance:

Could you please help confirm:

1. Are there any additional configuration steps needed to ensure on-premises clients can reach the AVS vCenter over the Site-to-Site VPN path?
2. Is there any known limitation regarding AVS management endpoint access from on-premises networks when using Site-to-Site VPN
3. Do we need to create specific DNS records or firewall rules (in Azure Firewall or NSX-T) to enable this connectivity?
4. What are the recommended steps to troubleshoot this scenario (e.g., packet capture locations, effective routes validation, or NSX-T Edge firewall configuration)?

Paul

To route traffic from on-prem → Azure VPN Gateway → AVS via ER, you must enable:

ExpressRoute Global Reach between your Azure VPN Gateway and the AVS ExpressRoute circuit.

Without Global Reach, the AVS private cloud prefixes are not reachable from the on-prem network.

To check:

• Go to AVS → Connectivity → Global Reach
• Ensure it shows "Connected" to the VPN Gateway’s ExpressRoute circuit
• If not, establish it by linking the on-prem circuit and AVS circuit via Global Reach.https://free.blessedness.top/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway
• 

AVS itself does not support UDRs. All routing within AVS is handled by BGP and NSX-T. Ensure that routes to on-premises are advertised into AVS via BGP.

If accessing https://vcenter.cloud.com, DNS must resolve the AVS vCenter IP.

DNS options:

• Use AVS-built-in DNS forwarder or a custom DNS server that resolves AVS management names.
• Or use IP directly (e.g., https://10.10.0.10 for vCenter).

Allow required ports (e.g., 443 for vCenter, 902/903 for ESXi management) in Azure Firewall and NSX-T Gateway Firewall. https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/administration-guide/network-address-translation.html

https://www.virtualworkloads.com/2022/07/azure-vmware-solution-connect-avs-and-site-to-site-vpn-connected-on-premises-location/

On-premises access to AVS vCenter via Site-to-Site VPN is supported, but requires correct BGP route propagation, DNS configuration, and firewall rule alignment. Azure Route Server is strongly recommended for dynamic routing between VPN and ExpressRoute gateways. Troubleshoot by validating routes, DNS, and firewall rules at each hop, and use packet captures and NSX-T Traceflow for deeper analysis.

Hope it helps!

Let me know if you have any further queries!

If the information is helpful, please click "upvote" to let us know!