Conectividad transitiva entre VNETs usando ExpressRoute Gateway en Azure

🌐 Introducción

Un ExpressRoute Gateway en un hub puede habilitar conectividad transitiva entre spokes de VNETS en Azure, en una arquitectura de red tipo hub-and-spoke.

Es decir que un VNG de tipo Express Route, puede actuar para permitir la transitividad entre peerings (sabemos que por defecto los peerings no son transitivos) en un entorno donde esos peerings (VNETs) están ubicados exclusivamente en Azure (por extraño que parezca pues ExR se utiliza para conectar on-prem con Azure).

Aunque esto es técnicamente posible, no es una práctica recomendada por Microsoft para escenarios de conectividad entre redes virtuales dentro de Azure.

Este post explica cómo funciona, qué necesitas configurar y por qué deberías considerar alternativas como VNET peering.

¿Qué significa conectividad transitiva?

La conectividad transitiva permite que dos redes (por ejemplo, dos spokes) se comuniquen entre sí a través de un tercero (el hub). Si una Vnet (A) está conectada a una VNET Hub (H), y otra VNET B está conectada a un VNET Hub (H). A y B no tienen conectividad entre si por defecto. Se dice que el peering no es transitivo porque necesita un componente en el HUB (un NVA on un AZFW) para permitir el forwarding entre spokes.

Pero en Azure, esto también puede lograrse si el hub tiene un ExpressRoute Gateway y los spokes están conectados mediante VNET peering a dicho hub con opciones específicas habilitadas.

Requisitos de configuración

Para que esta arquitectura funcione correctamente, debes cumplir con los siguientes requisitos:

• Topología hub-and-spoke: todos los spokes deben estar conectados al hub mediante peering.
• Gateway ExpressRoute en el hub:
  • Crear una subred llamada GatewaySubnet (/27 o mayor).
  • Asignar una SKU adecuada (Ej. ErGwScale, ErGw1Az).
  • Seleccionar tipo de gateway: ExpressRoute.
• Peering entre VNETs:
  • En el hub: activar Allow gateway transit.
  • En los spokes: activar Use remote gateway.
• Habilitar toggles en el gateway:

  • Por defecto, la conectividad VNet-to-VNet y VNet-to-Virtual WAN está desactivada. https://learn.microsoft.com/en-us/azure/expressroute/expressroute-howto-add-gateway-portal-resource-manager#enable-or-disable-vnet-to-vnet-or-vnet-to-virtual-wan-traffic-through-expressroute

  • Debes habilitarla manualmente en la configuración del gateway.

  • Revisar también la SKU del VNG para ver dónde pueden estar ubicados los spokes

Limitaciones importantes

Aunque es posible, Microsoft desaconseja este enfoque por varias razones:

• Gateway en la ruta de datos:
  • El tráfico entre VNETs pasa por el ExpressRoute Gateway, que tiene restricciones de ancho de banda y rendimiento.
• Mayor latencia:
  • El tráfico se enruta a través de dispositivos Microsoft Enterprise Edge (MSEE), fuera de las regiones de Azure.
• Complejidad operativa:
  • Requiere configuración cuidadosa de peering y toggles.

Alternativa recomendada: VNET Peering

Microsoft recomienda usar VNET peering directo entre redes virtuales para lograr:

• Menor latencia
• Mayor rendimiento
• Simplicidad operativa
• Evitar el gateway en la ruta de datos

Diagrama explicativo

!Diagrama de conectividad transitiva de ExpressRoute

Descripción: El hub contiene el ExpressRoute Gateway. Los spokes están conectados al hub mediante peering. El tráfico entre spokes y hacia on-premises pasa por el gateway. Se destacan los requisitos y limitaciones.

Puntos clave de la documentación oficial

Connectivity between virtual networks over Azure ExpressRoute

• La conectividad VNet-to-VNet a través de ExpressRoute requiere habilitación explícita.
• Limitaciones:
  • El gateway está en la ruta de datos → limita el rendimiento.
  • Latencia adicional por dispositivos MSEE.
• Recomendación: usar VNET peering directo para tráfico entre VNETs.

Configure a virtual network gateway for ExpressRoute

• Por defecto, la conectividad VNet-to-VNet está desactivada.
• Debes habilitarla manualmente en el portal.
• Consideraciones adicionales:
  • No usar NSG/UDR con destino 0.0.0.0/0 en GatewaySubnet.
  • Asignar IP pública tipo Standard.
  • Habilitar propagación BGP si aplica.

Conclusión

Aunque el ExpressRoute Gateway puede actuar como punto de tránsito entre spokes, no es la solución óptima para conectividad entre VNETs dentro de Azure. Para ese propósito, VNET peering sigue siendo la mejor práctica.

Usa ExpressRoute Gateway para:

• Conectividad híbrida (on-premises ↔ Azure)
• Acceso centralizado a servicios compartidos
• Control de tráfico de salida

Evita usarlo para tráfico entre VNETs si puedes resolverlo con peering directo.

¿Te gustaría que este post se convierta también en una presentación o que lo acompañe una tabla comparativa entre opciones de conectividad? ¡Estoy listo para ayudarte!