AVS HCX L2 Extension – Routing from Extended VM to Azure-Native Subnet

Yes. If the VM is on an HCX L2 extended network and keeps its on-premises default gateway, traffic to the Azure-native subnet can hairpin back on-premises. The documented behavior is that without migrating the VM gateway to the cloud side, MON does not ensure an optimal path for traffic flow, and policy routes are not evaluated.

A supported way to optimize this is HCX Mobility Optimized Networking (MON), but only when the VM gateway is migrated to the cloud side.

Key points for this scenario:

1. Without gateway migration to AVS
   • Traffic optimization is not achieved by MON alone.
   • Traffic can follow the non-optimal path back toward on-premises, creating tromboning/hairpinning.
   • MON policy routes are not evaluated.
2. With gateway migration to the cloud side in AVS
   • MON can optimize traffic for the migrated VM.
   • Egress traffic from the VM can bypass the Network Extension IPsec tunnel and exit through the AVS NSX-T Tier-1/Tier-0 path toward Azure networking.
   • This is the documented model for avoiding the tromboning effect and getting an optimal path between the AVS VM and Azure-connected resources.
3. Routing behavior to Azure-native networks
   • In MON-enabled designs, ingress traffic to the MON-enabled VM uses an injected /32 host route so connected networks learn a direct path to that VM instead of using the Network Extension tunnel.
   • For egress, MON changes the path so traffic does not loop back on-premises and instead exits through AVS routing.
4. Important design caution
   • MON requires careful planning to avoid asymmetric routing.
   • Default MON policy routes include RFC 1918 ranges. That can force private-address traffic over the Network Extension path and create asymmetric flows, especially with Azure, on-premises, and stateful firewalls in the path.
   • General guidance is to remove default policy routes unless the network is specifically designed to prevent asymmetry.
   • If policy routes are used, they must match each required subnet precisely; otherwise traffic goes via the AVS Tier-0 gateway instead of the Network Extension path.

So for the exact scenario described:

• Yes, with the on-premises default gateway retained, traffic to the Oracle database can traverse back through on-premises.
• Yes, there is a supported optimization path, but it is HCX MON with the VM gateway migrated to AVS/cloud side.
• No, the provided documentation does not describe another AVS/NSX mechanism that gives local optimized routing for this HCX L2 extension scenario while the VM continues to use the on-premises default gateway.

• VMware HCX Mobility Optimized Networking (MON) guidance
• VMware HCX Mobility Optimized Networking (MON) guidance
• Use a single-region Azure VMware Solution design that doesn't have Global Reach
• Use a dual-region Azure VMware Solution design that doesn't have Global Reach