Preguntas más frecuentes sobre VPN Gateway

Conexión a redes virtuales

¿Puedo conectar redes virtuales en diferentes regiones de Azure?

Sí. No hay ninguna restricción de región. Puede conectar una red virtual a otra red virtual en la misma región o en una región distinta de Azure.

¿Puedo conectar redes virtuales en diferentes suscripciones?

Sí.

¿Puedo especificar servidores DNS privados en mi red virtual al configurar una puerta de enlace de VPN?

Si especificó un servidor o varios servidores DNS cuando creó la red virtual, VPN Gateway usará los servidores DNS que especificara. Si especifica un servidor DNS, compruebe que el servidor DNS pueda resolver los nombres de dominio necesarios para Azure.

¿Puedo conectar a varios sitios desde una única red virtual?

Puede conectarse a varios sitios mediante el uso de Windows PowerShell y las API de REST de Azure. Consulte la sección de P+F Conectividad de red virtual a red virtual y de multisitio .

¿Hay un costo adicional para configurar una puerta de enlace VPN como activa-activa?

No. Sin embargo, los costos de las direcciones IP públicas adicionales se cobrarán en consecuencia. Consulte Precios de direcciones IP.

¿Cuáles son mis opciones de conexión entre locales?

Se admiten las siguientes conexiones de puerta de enlace de red virtual entre locales:

• Sitio a sitio : conexión VPN sobre IPsec (IKE v1 e IKE v2). Este tipo de conexión requiere un dispositivo VPN o RRAS. Para obtener más información, consulte Sitio a sitio.
• De punto a sitio: conexión VPN sobre SSTP (Protocolo de túnel de sockets seguros) o IKE v2. Esta conexión no requiere un dispositivo VPN. Para obtener más información, consulte Punto a sitio.
• Red virtual a red virtual: este tipo de conexión es el mismo que el de la configuración de sitio a sitio. La conexión de red virtual a red virtual es una conexión VPN sobre IPsec (IKE v1 e IKE v2). No requiere un dispositivo VPN. Para más información, consulte Red virtual a red virtual.
• ExpressRoute: ExpressRoute es una conexión privada a Azure desde la WAN, no una conexión VPN a través de la red pública de Internet. Para más información, consulte Información técnica de ExpressRoute y P+F de ExpressRoute.

Para más información acerca de las conexiones de VPN Gateway, consulte Acerca de VPN Gateway.

¿Cuál es la diferencia entre una conexión de sitio a sitio y una de punto a sitio?

Las configuraciones de sitio a sitio (túnel de VPN sobre IPsec/IKE) se encuentran entre la ubicación local y Azure. Esto significa que puede conectar cualquiera de las máquinas de sus instalaciones locales con cualquier máquina virtual o instancia de rol de la red virtual, en función de la configuración del enrutamiento y de los permisos. Es ideal para una conexión entre locales que esté siempre disponible y una opción que se adapta bien a las configuraciones híbridas. Este tipo de conexión se basa en un dispositivo (de hardware o de software) VPN sobre IPsec, que se tiene que implementar en el perímetro de la red. Para crear este tipo de conexión, debe tener una dirección IPv4 externa.

Las configuraciones de punto a sitio (VPN sobre SSTP) le permiten conectarse desde una única máquina y desde cualquier lugar con cualquier dispositivo de la red virtual. Usa el cliente VPN incluido en Windows. Como parte de la configuración de punto a sitio, debes instalar un certificado y un paquete de configuración de cliente VPN, que contiene las configuraciones que permiten al equipo conectarse a cualquier máquina virtual o instancia de rol dentro de la red virtual. Es ideal si desea conectarse a una red virtual pero no se encuentra en una ubicación local. También es una buena opción cuando no tenga acceso a un hardware VPN o una dirección IPv4 con orientación externa, ya que ambos son necesarios para una conexión de sitio a sitio.

Puede configurar la red virtual para utilizar las conexiones de sitio a sitio y de punto a sitio simultáneamente, siempre que cree la conexión de sitio a sitio mediante un tipo de VPN basada en enrutamiento para la puerta de enlace. Los tipos de VPN basada en enrutamiento se denominan puertas de enlace dinámicas en el modelo de implementación clásico.

Privacidad

¿El servicio VPN almacena o procesa datos de los clientes?

No.

Puertas de enlace de red virtual

¿Es la puerta de enlace de VPN una puerta de enlace de red virtual?

Una puerta de enlace de VPN es un tipo de puerta de enlace de red virtual. Una puerta de enlace de VPN envía tráfico cifrado entre la red virtual y la ubicación local a través de una conexión pública. También puede utilizar una puerta de enlace de VPN para enviar tráfico entre redes virtuales. Cuando se crea una puerta de enlace de VPN, se usa el valor de -GatewayType 'Vpn'. Para más información, consulte Acerca de la configuración de VPN Gateway.

¿Por qué no puedo especificar tipos de VPN basados en directivas y basados en rutas?

A partir del 1 de octubre de 2023, no puede crear una puerta de enlace de VPN basada en directivas a través de Azure Portal. Todas las nuevas puertas de enlace de VPN se crearán automáticamente como basadas en rutas. Si ya tiene una puerta de enlace basada en directivas, no es necesario actualizar la puerta de enlace a basada en rutas. Puede usar Powershell o la CLI para crear las puertas de enlace basadas en directivas.

Anteriormente, las SKU de puerta de enlace anteriores no admitían IKEv1 para las puertas de enlace basadas en rutas. Ahora, la mayoría de las SKU de puerta de enlace actuales admiten IKEv1 y IKEv2.

Tipo de VPN de la puerta de enlace	SKU de puerta de enlace	Versiones de IKE admitidas
Puerta de enlace basada en directivas	Basic	IKEv1
Puerta de enlace basada en rutas	Basic	IKEv2
Puerta de enlace basada en rutas	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 e IKEv2
Puerta de enlace basada en rutas	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 e IKEv2

¿Puedo actualizar mi puerta de enlace VPN basada en directivas a una basada en el enrutamiento?

No. Un tipo de puerta de enlace no puede cambiarse de basado en directiva a basado en ruta, o de basado en ruta a basado en directiva. Para cambiar un tipo de puerta de enlace, la puerta de enlace debe eliminarse y volver a crearse. Este proceso tarda aproximadamente 60¹minutos. Cuando se crea la nueva puerta de enlace, no se puede conservar la dirección IP de la puerta de enlace original.

1. Elimine las conexiones asociadas a la puerta de enlace.

2. Elimine la puerta de enlace con uno de los siguientes artículos:

   • Azure Portal
   • Azure PowerShell
   • Azure PowerShell: clásico

3. Cree una nueva puerta de enlace utilizando el tipo de puerta de enlace que desee y, a continuación, complete la configuración de la VPN. Para conocer los pasos, consulte el tutorial de sitio a sitio.

¿Puedo especificar mis propios selectores de tráfico basados en directivas?

Sí, los selectores de tráfico se pueden definir mediante el atributo trafficSelectorPolicies en una conexión con el comando New-AzIpsecTrafficSelectorPolicy de PowerShell. Para que el selector de tráfico tenga efecto, asegúrese de activar la opción Use Policy Based Traffic Selectors (Usar selectores de tráfico basados en directivas).

Los selectores de tráfico configurados personalizados solo se proponen si la conexión se inicia mediante una puerta de enlace de VPN de Azure. Las puertas de enlace de VPN aceptarán los selectores de tráfico que proponen las puertas de enlace remotas (es decir, los dispositivos VPN locales). Este comportamiento es coherente entre todos los modos de conexión (Default, InitiatorOnly y ResponderOnly).

¿Necesito una "GatewaySubnet"?

Sí. La subred de puerta de enlace contiene las direcciones IP que usan los servicios de puerta de enlace de la red virtual. Necesitará crear una subred de puerta de enlace de red virtual para configurar la puerta de enlace de la red virtual. Para que funcionen correctamente, todas las subredes de puerta de enlace se deben llamar "GatewaySubnet". No denomine de ninguna otra forma la subred de puerta de enlace. Y no implemente máquinas virtuales ni nada más en la subred de puerta de enlace.

Al crear la subred de puerta de enlace, especifique el número de direcciones IP que contiene la subred. Las direcciones IP de la subred de puerta de enlace se asignan al servicio de puerta de enlace. Algunas configuraciones requieren la asignación de más direcciones IP a los servicios de puerta de enlace que otras. Debe asegurarse de que la subred de puerta de enlace contiene suficientes direcciones IP para soportar el crecimiento futuro y posibles configuraciones de conexión nuevas. Por lo tanto, aunque es posible crear una puerta de enlace tan pequeña como /29, se recomienda que sea de /27 o mayor (/27, /26, /25, etc.). Consulte los requisitos de configuración que desea crear y compruebe que su subred de puerta de enlace los cumple.

¿Puedo implementar máquinas virtuales o instancias de rol en mi subred de puerta de enlace?

No.

¿Puedo obtener mi dirección IP de puerta de enlace VPN antes de crearla?

Los recursos de IP pública de SKU estándar de Azure deben usar un método de asignación estático. Por lo tanto, tendrá la dirección IP pública para la puerta de enlace de VPN en cuanto cree el recurso de IP pública de SKU estándar que pretende usar para esta.

¿Se puede solicitar una dirección IP pública estática para una puerta de enlace de VPN?

Los recursos de IP pública de SKU Estándar deben usar un método de asignación estático. En el futuro, deberá usar una dirección IP pública del SKU estándar al crear una nueva puerta de enlace de VPN. Esto se aplica a todas las SKU de puerta de enlace, excepto a la SKU básica. Actualmente, la SKU de puerta de enlace básica solo admite direcciones IP públicas de SKU básicas. Pronto agregaremos compatibilidad con las direcciones IP públicas de SKU Estándar para las SKU Básica de puerta de enlace.

En el caso de puertas de enlace sin redundancia de zona y no zonales que se crearon anteriormente (SKU de puerta de enlace que no tienen AZ en el nombre), se admite la asignación de direcciones IP dinámicas, pero se está eliminando gradualmente. Cuando se usa una dirección IP dinámica, la dirección IP no cambia después de que se haya asignado a la puerta de enlace de VPN. La única vez que cambia la dirección IP de la puerta de enlace de VPN es cuando se elimina y se vuelve a crear la puerta de enlace. La dirección IP pública de la puerta de enlace de VPN no cambia aunque se cambie el tamaño, se restablezca o se lleven a cabo otras operaciones de mantenimiento interno y actualizaciones de la puerta de enlace de VPN.

¿Cómo afecta la retirada del SKU básico de la dirección IP pública a mis puertas de enlace de VPN?

Estamos tomando medidas para garantizar el funcionamiento continuo de las puertas de enlace de VPN implementadas que usan direcciones IP públicas de SKU Basic. Si ya tuviera puertas de enlace VPN con direcciones IP públicas de SKU básica, no tendrá que hacer nada.

Sin embargo, es importante tener en cuenta que las direcciones IP públicas de la SKU básica se están eliminando gradualmente. En el futuro, al crear una nueva puerta de enlace de VPN, debe usar la dirección IP pública de SKU estándar. Puede encontrar más detalles sobre la retirada de direcciones IP públicas de SKU Basic aquí.

¿Cómo se autentica mi túnel VPN?

VPN de Azure usa autenticación PSK (clave previamente compartida). Se genera una clave previamente compartida (PSK) cuando se crea el túnel VPN. Puede cambiar la clave PSK generada automáticamente por la suya propia a través del cmdlet de PowerShell o la API de REST para establecer la clave precompartida.

¿Puedo usar la API para establecer la clave precompartida y configurar mi VPN basada en directivas (enrutamiento estático) de la puerta de enlace?

Sí, el cmdlet de PowerShell y la API para establecer la clave precompartida se pueden utilizar para configurar tanto las VPN basadas en directivas (enrutamiento estático) de Azure como las VPN basadas en enrutamiento (enrutamiento dinámico).

¿Puedo usar otras opciones de autenticación?

Las opciones están limitadas al uso de claves precompartidas (PSK) para la autenticación.

¿Cómo especifico qué tráfico pasa a través de la puerta de enlace VPN?

Modelo de implementación del Administrador de recursos

• PowerShell: use "AddressPrefix" para especificar el tráfico de la puerta de enlace de red local.
• Azure Portal: navegue a la puerta de enlace de red local > Configuración > Espacio de direcciones.

Modelo de implementación clásica

• Azure Portal: navegue a la red virtual clásica > Conexiones VPN > Conexiones VPN de sitio a sitio > Nombre del sitio local > Sitio local > Espacio de direcciones del cliente.

¿Puedo usar NAT-T en las conexiones VPN?

Sí, se admite NAT traversal (NAT-T). Azure VPN Gateway NO llevará a cabo ninguna funcionalidad similar a la de NAT en los paquetes internos hacia y desde los túneles de IPsec. En esta configuración, asegúrese de que el dispositivo local inicie el túnel IPsec.

¿Puedo configurar mi propio servidor VPN en Azure y usarlo para conectar a mi red local?

Sí, puede implementar sus propias puertas de enlace o servidores VPN en Azure bien desde Azure Marketplace o creando sus propios enrutadores VPN. Tiene que configurar las rutas definidas por el usuario en la red virtual para asegurarse de que el tráfico se enruta correctamente entre las redes locales y las subredes de la red virtual.

¿Por qué hay algunos puertos abiertos en mi puerta de enlace de red virtual?

Son necesarios para la comunicación de la infraestructura de Azure. Están protegidos (bloqueados) mediante certificados de Azure. Sin los certificados apropiados, las entidades externas, incluidos los clientes de esas puertas de enlace, no podrán tener ningún efecto en esos puntos de conexión.

Una puerta de enlace de red virtual es básicamente un dispositivo de hosts múltiples con una NIC que accede a la red privada del cliente y una NIC accesible desde la red pública. Las entidades de la infraestructura de Azure no pueden acceder a redes privadas de clientes por motivos de conformidad, por lo que necesitan usar puntos de conexión públicos para la comunicación de infraestructura. Los puntos de conexión públicos se analizan periódicamente mediante auditoría de seguridad de Azure.

¿Puedo crear una puerta de enlace de VPN con la SKU de puerta de enlace básica en el portal?

No. La SKU básica no está disponible en el portal. Puede crear una puerta de enlace de VPN de la SKU básica mediante la CLI de Azure o PowerShell.

¿Dónde puedo obtener más información acerca de los tipos de puerta de enlace, los requisitos y el rendimiento?

Vea los artículos siguientes:

• Acerca de la configuración de VPN Gateway
• Acerca de los SKU de puerta de enlace

Desuso de SKU para SKU heredados

Las SKU estándar y de alto rendimiento quedarán en desuso el 30 de septiembre de 2025. Vea el anuncio aquí. El equipo del producto hará que una ruta de migración esté disponible para estas SKU el 30 de noviembre de 2024. Para obtener más información, consulte el artículo SKU heredados de VPN Gateway. Por ahora, no tiene que realizar ninguna acción.

¿Puedo crear un nuevo SKU de alto rendimiento o estándar después del anuncio de desuso el 30 de noviembre de 2023?

No. A partir del 1 de diciembre de 2023, no podrá crear nuevas puertas de enlace con SKU estándar o de alto rendimiento. Puede crear nuevas puertas de enlace con VpnGw1 y VpnGw2 por el mismo precio que los SKU estándar y de alto rendimiento, enumerados respectivamente en nuestra página de precios.

¿Cuánto tiempo se admitirán las puertas de enlace existentes en los SKU de alto rendimiento o estándar?

Todas las puertas de enlace existentes que usan SKU estándar o de alto rendimiento se admitirán hasta el 30 de septiembre de 2025.

¿Necesito migrar los SKU de puerta de enlace estándar o de alto rendimiento ahora?

No, no hay ninguna acción que deba realizar en este momento. Podrá migrar los SKU a partir de diciembre de 2024. Enviaremos una comunicación con documentación detallada sobre los pasos de migración.

¿A qué SKU puedo migrar mi puerta de enlace?

Cuando la migración de SKU de puerta de enlace esté disponible, los SKU se podrán migrar de la siguiente manera:

• Estándar: > VpnGw1
• Alto rendimiento: > VpnGw2

¿Qué ocurre si quiero migrar a un SKU de AZ?

No puede migrar el SKU heredado a un SKU de AZ. Sin embargo, tenga en cuenta que todas las puertas de enlace que siguen usando SKU estándar o de alto rendimiento después del 30 de septiembre de 2025 se migrarán y actualizarán automáticamente a los siguientes SKU:

• Estándar: > VpnGw1AZ
• Alto rendimiento: > VpnGw2AZ

Puede usar esta estrategia para que los SKU se migren y actualicen automáticamente a un SKU de AZ. Después, puede cambiar el tamaño del SKU dentro de esa familia de SKU si es necesario. Consulte nuestra página de precios para obtener los precios de SKU de AZ. Para obtener información sobre el rendimiento por SKU, vea Acerca de las SKU de puerta de enlace.

¿Habrá alguna diferencia de precios para mis puertas de enlace después de la migración?

Si migra las SKU antes del 30 de septiembre de 2025, no habrá ninguna diferencia de precios. Los SKU VpnGw1 y VpnGw2 se ofrecen al mismo precio que los SKU estándar y de alto rendimiento, respectivamente. Si no migra antes de esa fecha, los SKU se migrarán y actualizarán automáticamente a los SKU de AZ. En ese caso, hay una diferencia de precios.

¿Habrá algún impacto en el rendimiento en mis puertas de enlace con esta migración?

Sí, obtendrá un mejor rendimiento con VpnGw1 y VpnGw2. Actualmente, VpnGw1 a 650 Mbps proporciona una mejora del rendimiento de 6,5 veces y VpnGw2 a 1 Gbps una mejora de 5 veces al mismo precio que las puertas de enlace estándar y de alto rendimiento heredadas, respectivamente. Para obtener más información sobre el rendimiento de SKU, vea Acerca de las SKU de puerta de enlace.

¿Qué ocurre si no migro los SKU antes del 30 de septiembre de 2025?

Todas las puertas de enlace que todavía usen SKU estándar o de alto rendimiento se migrarán automáticamente y se actualizarán a los siguientes SKU de AZ:

• Estándar: > VpnGw1AZ
• Alto rendimiento: > VpnGw2AZ

La comunicación final se enviará antes de iniciar la migración en cualquier puerta de enlace.

¿También se retira la SKU básica de VPN Gateway?

No, la SKU básica de VPN Gateway sigue disponible. Puede crear puertas de enlace VPN mediante la SKU básica de VPN Gateway a través de PowerShell o la CLI. Actualmente, las SKU básicas de puerta de enlace de VPN Gateway solo admiten el recurso de dirección IP pública de la SKU básica (que se retirará). Estamos trabajando para agregar compatibilidad a la SKU de puerta de enlace básica de VPN Gateway para el recurso de dirección IP pública de SKU estándar.

Conexiones de sitio a sitio y dispositivos VPN

¿Qué tengo que tener en cuenta al seleccionar un dispositivo VPN?

Hemos validado un conjunto de dispositivos estándar VPN de sitio a sitio en colaboración con proveedores de dispositivos. El artículo Acerca de los dispositivos VPN contiene una lista de dispositivos VPN de compatibilidad conocida y sus correspondientes instrucciones de configuración o ejemplos, así como especificaciones del dispositivo. Todos los dispositivos dentro de las familias de dispositivos que aparecen como de compatibilidad conocida, deben funcionar con Virtual Network. Con el fin de configurar el dispositivo VPN, consulte el ejemplo de configuración de dispositivo o el vínculo que corresponde a la familia de dispositivos adecuada.

¿Dónde puedo encontrar los valores de configuración de los dispositivos VPN?

Para descargar el script de configuración de dispositivos VPN:

En función del dispositivo VPN que tenga, es posible que pueda descargar un script de configuración del mismo. Para más información, consulte Descarga de scripts de configuración de dispositivos VPN para conexiones VPN S2S.

En los siguientes vínculos encontrará más información acerca de la configuración:

• Para obtener más información sobre dispositivos VPN compatibles, consulte Dispositivos VPN.

• Antes de configurar el dispositivo VPN, compruebe si hay problemas conocidos de compatibilidad para el dispositivo VPN que desea usar.

• Para obtener vínculos a los valores de configuración del dispositivo, consulte Dispositivos VPN validados. Los vínculos de la configuración de dispositivos se proporcionan dentro de lo posible. Siempre es mejor ponerse en contacto con el fabricante del dispositivo para obtener la información de configuración más reciente. La lista muestra las versiones que hemos probado. Si su sistema operativo no está en esa lista, sigue siendo posible que la versión sea compatible. Póngase en contacto con el fabricante del dispositivo para comprobar que la versión del sistema operativo para el dispositivo VPN es compatible.

• Para ver información general sobre la configuración de dispositivos VPN, consulte Introducción a la configuración de dispositivos VPN.

• Para obtener información sobre cómo modificar los ejemplos de configuración de dispositivo, consulte Edición de ejemplos.

• Para conocer los requisitos criptográficos, consulte About cryptographic requirements and Azure VPN gateways (Acerca de los requisitos criptográficos y la puertas de enlace de VPN de Azure).

• Para obtener información acerca de los parámetros de protocolo de seguridad de Internet/intercambio de claves por red, consulte Acerca de los dispositivos VPN y los parámetros de IPsec/IKE para conexiones de VPN Gateway de sitio a sitio. Este vínculo muestra información acerca de la versión de IKE, Grupo Diffie-Hellman, método de autenticación, algoritmos de cifrado y hash, duración de SA, PFS y DPD, además de otra información de parámetros que necesita para completar la configuración.

• Para conocer los pasos de la configuración de la directiva de protocolo de seguridad de Internet/intercambio de claves por red, consulte Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections (Configuración de la directiva de protocolo de seguridad de Internet/intercambio de claves por red para conexiones para conexiones VPN de sitio a sitio o entre redes virtuales).

• Para conectar con dispositivos VPN basados en directivas, consulte Conexión de puertas de enlace Azure VPN Gateway a varios dispositivos VPN locales basados en directivas con PowerShell.

Edición de ejemplos de configuración de dispositivos VPN

Para obtener información sobre cómo modificar los ejemplos de configuración de dispositivo, consulte Edición de ejemplos.

¿Dónde encuentro los parámetros de IPsec e IKE?

Para los parámetros de IPsec/IKE, vea Parámetros.

¿Por qué mi túnel de VPN basado en directivas deja de funcionar cuando el tráfico está inactivo?

Este es el comportamiento esperado para puertas de enlace de VPN basadas en directivas (también conocido como enrutamiento estático). Cuando el tráfico a través del túnel está inactivo durante más de 5 minutos, el túnel se descompone. Cuanto el tráfico comience a fluir en cualquier dirección, el túnel se restablecerá inmediatamente.

¿Puedo usar una VPN de software para conectarme a Azure?

Se admiten servidores de Enrutamiento y acceso remoto (RRAS) de Windows Server 2012 para la configuración entre entornos de sitio a sitio.

Otras soluciones VPN de software deben funcionar con nuestra puerta de enlace siempre que se ajusten a las implementaciones IPsec estándar de la industria. Póngase en contacto con el proveedor del software para obtener instrucciones de configuración y soporte técnico.

¿Puedo conectarme a una puerta de enlace de VPN través de la opción Punto a sitio cuando se encuentra en un sitio que tiene una conexión de sitio a sitio activa?

Sí, pero las direcciones IP públicas del cliente de Punto a sitio deben ser diferentes de las direcciones IP públicas que usa el dispositivo VPN de sitio a sitio; de lo contrario, la conexión de punto a sitio no funcionará. Las conexiones de Punto a sitio con IKEv2 no se pueden iniciar desde las mismas direcciones IP públicas donde se configura una conexión VPN de sitio a sitio en la misma instancia de Azure VPN Gateway.

Punto a sitio: autenticación de certificados

Esta sección se aplica al modelo de implementación de Resource Manager.

¿Cuántos extremos de cliente VPN puedo tener en mi configuración de punto a sitio?

Depende de la SKU de puerta de enlace. Para más información sobre el número de conexiones admitidas, consulte SKU de puerta de enlace.

¿Qué sistemas operativos de cliente puedo usar para las conexiones de punto a sitio?

Se admiten los siguientes sistemas operativos de cliente:

• Windows Server 2008 R2 (solo 64 bits)
• Windows 8.1 (32 bits y 64 bits)
• Windows Server 2012 (solo 64 bits)
• Windows Server 2012 R2 (solo 64 bits)
• Windows Server 2016 (solo 64 bits)
• Windows Server 2019 (solo 64 bits)
• Windows Server 2022 (solo 64 bits)
• Windows 10
• Windows 11
• macOS, versión 10.11 o posterior
• Linux (StrongSwan)
• iOS

¿Puedo atravesar servidores proxy y firewalls con la capacidad de punto a sitio?

Azure admite tres tipos de opciones de VPN de punto a sitio:

• Protocolo de túnel de sockets seguros (SSTP). SSTP es una solución basada en SSL propietaria de Microsoft que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP 443 que utiliza SSL.

• OpenVPN. OpenVPN es una solución basada en SSL que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP 443 de salida que utiliza SSL.

• VPN IKEv2. VPN IKEv2 es una solución de VPN con IPsec basada en estándares que utiliza los puertos UDP 500 y 4500 de salida y el protocolo IP n.º 50. Los firewalls no siempre abren estos puertos, por lo que hay una posibilidad de que la VPN IKEv2 no pueda atravesar servidores proxy y firewalls.

Si reinicio un equipo cliente configurado para punto a sitio, ¿se volverá a conectar automáticamente la VPN?

La reconexión automática es una función del cliente que se usa. Windows permite volver a conectarse automáticamente al configurar la característica para VPN de cliente Always On.

¿Admite la configuración de punto a sitio el DDNS en los clientes VPN?

Las VPN de punto a sitio no admiten actualmente el DDNS.

¿Puedo tener configuraciones de sitio a sitio y de punto a sitio coexistiendo en la misma red virtual?

Sí. Para el modelo de implementación de Resource Manager, debe tener un tipo de VPN basada en ruta para la puerta de enlace. Para el modelo de implementación clásica, necesita una puerta de enlace dinámica. No se admite la configuración de punto a sitio para puertas de enlace de VPN de enrutamiento estático o puertas de enlace de VPN basadas en directivas.

¿Se puedo configurar un cliente de punto a sitio para conectarse a varias puertas de enlace de red virtual al mismo tiempo?

En función del software cliente de VPN que se use, es posible conectarse a varias puertas de enlace de red virtual, siempre que las redes virtuales con las que se va a establecer la conexión no tengan espacios de direcciones en conflicto entre ellas ni con la red desde la que se conecta el cliente. Aunque el cliente VPN de Azure admite muchas conexiones VPN, no es posible establecer varias simultáneamente.

¿Puedo configurar un cliente de punto a sitio para conectarse a varias redes virtuales simultáneamente?

Sí, las conexiones de cliente de punto a sitio a una puerta de enlace de red virtual implementada en una red virtual emparejada con otras redes virtuales pueden tener acceso a las redes virtuales emparejadas. Los clientes de punto a sitio podrán conectarse a las redes virtuales emparejadas siempre que estas usen las características UseRemoteGateway/AllowGatewayTransit. Para más información, consulte Acerca del enrutamiento de punto a sitio.

¿Qué rendimiento puedo esperar en las conexiones de sitio a sitio o de punto a sitio?

Es difícil de mantener el rendimiento exacto de los túneles VPN. IPsec y SSTP son protocolos VPN con mucho cifrado. El rendimiento también está limitado por la latencia y el ancho de banda entre sus instalaciones locales e Internet. Para una puerta de enlace de VPN únicamente con conexiones VPN de punto a sitio IKEv2, el rendimiento total que puede esperar depende de la SKU de puerta de enlace. Consulte SKU de puerta de enlace para más información sobre el rendimiento.

¿Puedo usar cualquier software de cliente VPN para punto a sitio que admita SSTP o IKEv2?

No. Solo puede usar el cliente VPN nativo en Windows para SSTP y el cliente VPN nativo en Mac para IKEv2. Sin embargo, puede utilizar el cliente OpenVPN en todas las plataformas para conectarse a través del protocolo OpenVPN. Consulte la lista de sistemas operativos cliente compatibles.

¿Puedo cambiar el tipo de autenticación de una conexión de punto a sitio?

Sí. En el portal, vaya a la página Puerta de enlace VPN -> Configuración de punto a sitio. En Tipo de autenticación, seleccione los tipos de autenticación que desea usar. Tenga en cuenta que después de realizar un cambio en un tipo de autenticación, es posible que los clientes actuales no puedan conectarse hasta que se haya generado, descargado y aplicado un nuevo perfil de configuración de cliente VPN para cada cliente VPN.

¿Azure admite VPN IKEv2 con Windows?

IKEv2 se admite en Windows 10 y Server 2016. Pero para poder usar IKEv2 en determinadas versiones de sistema operativo, tendrá que instalar las actualizaciones y establecer un valor de clave del Registro localmente. No se admiten las versiones de sistemas operativos anteriores a Windows 10 y solo se puede usar el protocolo OpenVPN® o SSTP.

Nota:

Estos pasos no son necesarios en las compilaciones del sistema operativo Windows posteriores a Windows 10 versión 1709 y Windows Server 2016 versión 1607.

Para preparar Windows 10 o Server 2016 para IKEv2:

1. Instale la actualización en función de la versión del sistema operativo:

   Versión del SO	Date	Número/vínculo
   Windows Server 2016 Windows 10 Versión 1607	17 de enero de 2018	KB4057142
   Windows 10 Versión 1703	17 de enero de 2018	KB4057144
   Windows 10 Versión 1709	22 de marzo de 2018	KB4089848

2. Establezca el valor de clave del Registro. Cree o establezca la clave REG_DWORD “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” del Registro en 1.

¿Cuál es el límite del selector de tráfico IKEv2 para las conexiones de punto a sitio?

Windows 10 versión 2004 (publicado en septiembre de 2021) aumentó el límite de selector de tráfico a 255. Las versiones Windows anteriores tienen un límite de selector de tráfico de 25.

El límite de selectores de tráfico de Windows determina el número máximo de espacios de direcciones en la red virtual y la suma máxima de redes locales, conexiones de red virtual a red virtual y redes virtuales emparejadas conectadas a la puerta de enlace. Los clientes de punto a sitio basados en Windows no se conectarán a través de IKEv2 si superan este límite.

¿Qué ocurre cuando se configuran SSTP e IKEv2 para conexiones VPN de P2S?

Cuando configure tanto SSTP como IKEv2 en un entorno mixto (que consiste en dispositivos Windows y Mac), el cliente VPN de Windows siempre probará primero el túnel de IKEv2, pero volverá a SSTP si la conexión con IKEv2 no se realiza correctamente. MacOSX solo se conectará a través de IKEv2.

Cuando tenga SSTP y IKEv2 habilitados en la puerta de enlace, el grupo de direcciones de punto a sitio se dividirá estáticamente entre los dos, por lo que a los clientes que usan protocolos diferentes se les asignarán direcciones IP de cualquier sub intervalo. Tenga en cuenta que la cantidad máxima de clientes SSTP es siempre 128, incluso si el intervalo de direcciones es mayor que /24, lo que da lugar a una mayor cantidad de direcciones disponibles para los clientes IKEv2. Para intervalos más pequeños, el grupo se reducirá igualmente a la mitad. Es posible que los selectores de tráfico usados por la puerta de enlace no incluyan el CIDR del intervalo de direcciones de punto a sitio, sino los dos CIDR de intervalo secundario.

Además de Windows y Mac, ¿qué otras plataformas Azure admite para VPN de P2S?

Azure es compatible con Windows, Mac y Linux para VPN de punto a sitio.

Ya tengo implementada una instancia de Azure VPN Gateway. ¿Puedo habilitar VPN de IKEv2 o RADIUS en ella?

Sí, si la SKU de la puerta de enlace que usa admite RADIUS o IKEv2, puede habilitar estas características en puertas de enlace ya implementadas mediante PowerShell o Azure Portal. La SKU de nivel Básico no admite RADIUS ni IKEv2.

¿Cómo se puede quitar la configuración de una conexión P2S?

Se puede quitar la configuración P2S mediante la CLI de Azure y PowerShell mediante los comandos siguientes:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

¿Qué debo hacer si obtengo un error de coincidencia de certificado al realizar la conexión mediante la autenticación de certificado?

Desactive "Comprobar la identidad del servidor validando el certificado"o agregue el FQDN del servidor junto con el certificado al crear un perfil manualmente. Para ello, ejecute rasphone desde un símbolo del sistema y elija el perfil en la lista desplegable.

En general, no se recomienda omitir la validación de la identidad del servidor, pero con la autenticación de certificado de Azure, se usa el mismo certificado para la validación del servidor en el protocolo de túnel VPN (IKEv2/SSTP) y el protocolo EAP. Dado que el certificado de servidor y el FQDN ya están validados por el protocolo de túnel de VPN, se produce una redundancia si se vuelven a validar en EAP.

¿Puedo usar mi propio CA raíz de PKI interna para generar certificados de conectividad de punto a sitio?

Sí. Anteriormente, solo podían usarse certificados raíz autofirmados. Todavía puede cargar 20 certificados raíz.

¿Puedo usar certificados de Azure Key Vault?

No.

¿Qué herramientas puedo usar para crear certificados?

Puede usar la solución Enterprise PKI (la PKI interna), Azure PowerShell, MakeCert y OpenSSL.

¿Hay instrucciones para los parámetros y la configuración de certificados?

• Solución PKI interna/Enterprise PKI: consulte los pasos de Generación de certificados.

• Azure PowerShell: consulte el artículo Azure PowerShell para conocer los pasos.

• MakeCert: consulte el artículo MakeCert para conocer los pasos.

• OpenSSL:

  • Al exportar certificados, asegúrese de convertir el certificado raíz en Base64.

  • Para el certificado de cliente:

    • Al crear la clave privada, especifique la longitud como 4096.
    • Al crear el certificado para el parámetro -extensions, especifique usr_cert.

Punto a sitio: autenticación RADIUS

Esta sección se aplica al modelo de implementación de Resource Manager.

¿Cuántos extremos de cliente VPN puedo tener en mi configuración de punto a sitio?

Depende de la SKU de puerta de enlace. Para más información sobre el número de conexiones admitidas, consulte SKU de puerta de enlace.

¿Qué sistemas operativos de cliente puedo usar para las conexiones de punto a sitio?

Se admiten los siguientes sistemas operativos de cliente:

• Windows Server 2008 R2 (solo 64 bits)
• Windows 8.1 (32 bits y 64 bits)
• Windows Server 2012 (solo 64 bits)
• Windows Server 2012 R2 (solo 64 bits)
• Windows Server 2016 (solo 64 bits)
• Windows Server 2019 (solo 64 bits)
• Windows Server 2022 (solo 64 bits)
• Windows 10
• Windows 11
• macOS, versión 10.11 o posterior
• Linux (StrongSwan)
• iOS

¿Puedo atravesar servidores proxy y firewalls con la capacidad de punto a sitio?

Azure admite tres tipos de opciones de VPN de punto a sitio:

• Protocolo de túnel de sockets seguros (SSTP). SSTP es una solución basada en SSL propietaria de Microsoft que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP 443 que utiliza SSL.

• OpenVPN. OpenVPN es una solución basada en SSL que puede atravesar firewalls, puesto que la mayoría de los firewalls abren el puerto TCP 443 de salida que utiliza SSL.

• VPN IKEv2. VPN IKEv2 es una solución de VPN con IPsec basada en estándares que utiliza los puertos UDP 500 y 4500 de salida y el protocolo IP n.º 50. Los firewalls no siempre abren estos puertos, por lo que hay una posibilidad de que la VPN IKEv2 no pueda atravesar servidores proxy y firewalls.

Si reinicio un equipo cliente configurado para punto a sitio, ¿se volverá a conectar automáticamente la VPN?

La reconexión automática es una función del cliente que se usa. Windows permite volver a conectarse automáticamente al configurar la característica para VPN de cliente Always On.

¿Admite la configuración de punto a sitio el DDNS en los clientes VPN?

Las VPN de punto a sitio no admiten actualmente el DDNS.

¿Puedo tener configuraciones de sitio a sitio y de punto a sitio coexistiendo en la misma red virtual?

Sí. Para el modelo de implementación de Resource Manager, debe tener un tipo de VPN basada en ruta para la puerta de enlace. Para el modelo de implementación clásica, necesita una puerta de enlace dinámica. No se admite la configuración de punto a sitio para puertas de enlace de VPN de enrutamiento estático o puertas de enlace de VPN basadas en directivas.

¿Se puedo configurar un cliente de punto a sitio para conectarse a varias puertas de enlace de red virtual al mismo tiempo?

En función del software cliente de VPN que se use, es posible conectarse a varias puertas de enlace de red virtual, siempre que las redes virtuales con las que se va a establecer la conexión no tengan espacios de direcciones en conflicto entre ellas ni con la red desde la que se conecta el cliente. Aunque el cliente VPN de Azure admite muchas conexiones VPN, no es posible establecer varias simultáneamente.

¿Puedo configurar un cliente de punto a sitio para conectarse a varias redes virtuales simultáneamente?

Sí, las conexiones de cliente de punto a sitio a una puerta de enlace de red virtual implementada en una red virtual emparejada con otras redes virtuales pueden tener acceso a las redes virtuales emparejadas. Los clientes de punto a sitio podrán conectarse a las redes virtuales emparejadas siempre que estas usen las características UseRemoteGateway/AllowGatewayTransit. Para más información, consulte Acerca del enrutamiento de punto a sitio.

¿Qué rendimiento puedo esperar en las conexiones de sitio a sitio o de punto a sitio?

Es difícil de mantener el rendimiento exacto de los túneles VPN. IPsec y SSTP son protocolos VPN con mucho cifrado. El rendimiento también está limitado por la latencia y el ancho de banda entre sus instalaciones locales e Internet. Para una puerta de enlace de VPN únicamente con conexiones VPN de punto a sitio IKEv2, el rendimiento total que puede esperar depende de la SKU de puerta de enlace. Consulte SKU de puerta de enlace para más información sobre el rendimiento.

¿Puedo usar cualquier software de cliente VPN para punto a sitio que admita SSTP o IKEv2?

No. Solo puede usar el cliente VPN nativo en Windows para SSTP y el cliente VPN nativo en Mac para IKEv2. Sin embargo, puede utilizar el cliente OpenVPN en todas las plataformas para conectarse a través del protocolo OpenVPN. Consulte la lista de sistemas operativos cliente compatibles.

¿Puedo cambiar el tipo de autenticación de una conexión de punto a sitio?

Sí. En el portal, vaya a la página Puerta de enlace VPN -> Configuración de punto a sitio. En Tipo de autenticación, seleccione los tipos de autenticación que desea usar. Tenga en cuenta que después de realizar un cambio en un tipo de autenticación, es posible que los clientes actuales no puedan conectarse hasta que se haya generado, descargado y aplicado un nuevo perfil de configuración de cliente VPN para cada cliente VPN.

¿Azure admite VPN IKEv2 con Windows?

IKEv2 se admite en Windows 10 y Server 2016. Pero para poder usar IKEv2 en determinadas versiones de sistema operativo, tendrá que instalar las actualizaciones y establecer un valor de clave del Registro localmente. No se admiten las versiones de sistemas operativos anteriores a Windows 10 y solo se puede usar el protocolo OpenVPN® o SSTP.

Nota:

Estos pasos no son necesarios en las compilaciones del sistema operativo Windows posteriores a Windows 10 versión 1709 y Windows Server 2016 versión 1607.

Para preparar Windows 10 o Server 2016 para IKEv2:

1. Instale la actualización en función de la versión del sistema operativo:

   Versión del SO	Date	Número/vínculo
   Windows Server 2016 Windows 10 Versión 1607	17 de enero de 2018	KB4057142
   Windows 10 Versión 1703	17 de enero de 2018	KB4057144
   Windows 10 Versión 1709	22 de marzo de 2018	KB4089848

2. Establezca el valor de clave del Registro. Cree o establezca la clave REG_DWORD “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” del Registro en 1.

¿Cuál es el límite del selector de tráfico IKEv2 para las conexiones de punto a sitio?

Windows 10 versión 2004 (publicado en septiembre de 2021) aumentó el límite de selector de tráfico a 255. Las versiones Windows anteriores tienen un límite de selector de tráfico de 25.

El límite de selectores de tráfico de Windows determina el número máximo de espacios de direcciones en la red virtual y la suma máxima de redes locales, conexiones de red virtual a red virtual y redes virtuales emparejadas conectadas a la puerta de enlace. Los clientes de punto a sitio basados en Windows no se conectarán a través de IKEv2 si superan este límite.

¿Qué ocurre cuando se configuran SSTP e IKEv2 para conexiones VPN de P2S?

Cuando configure tanto SSTP como IKEv2 en un entorno mixto (que consiste en dispositivos Windows y Mac), el cliente VPN de Windows siempre probará primero el túnel de IKEv2, pero volverá a SSTP si la conexión con IKEv2 no se realiza correctamente. MacOSX solo se conectará a través de IKEv2.

Cuando tenga SSTP y IKEv2 habilitados en la puerta de enlace, el grupo de direcciones de punto a sitio se dividirá estáticamente entre los dos, por lo que a los clientes que usan protocolos diferentes se les asignarán direcciones IP de cualquier sub intervalo. Tenga en cuenta que la cantidad máxima de clientes SSTP es siempre 128, incluso si el intervalo de direcciones es mayor que /24, lo que da lugar a una mayor cantidad de direcciones disponibles para los clientes IKEv2. Para intervalos más pequeños, el grupo se reducirá igualmente a la mitad. Es posible que los selectores de tráfico usados por la puerta de enlace no incluyan el CIDR del intervalo de direcciones de punto a sitio, sino los dos CIDR de intervalo secundario.

Además de Windows y Mac, ¿qué otras plataformas Azure admite para VPN de P2S?

Azure es compatible con Windows, Mac y Linux para VPN de punto a sitio.

Ya tengo implementada una instancia de Azure VPN Gateway. ¿Puedo habilitar VPN de IKEv2 o RADIUS en ella?

Sí, si la SKU de la puerta de enlace que usa admite RADIUS o IKEv2, puede habilitar estas características en puertas de enlace ya implementadas mediante PowerShell o Azure Portal. La SKU de nivel Básico no admite RADIUS ni IKEv2.

¿Cómo se puede quitar la configuración de una conexión P2S?

Se puede quitar la configuración P2S mediante la CLI de Azure y PowerShell mediante los comandos siguientes:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

¿Se admite la autenticación RADIUS en todas las SKU de Azure VPN Gateway?

La autenticación RADIUS es compatible con todas las SKU excepto la SKU básica.

Si usa SKU heredadas, la autenticación RADIUS se admite en SKU estándar y de alto rendimiento. Esta autenticación no es compatible con la SKU de nivel Básico.

¿Es compatible la autenticación RADIUS con el modelo de implementación clásica?

No. La autenticación RADIUS no es compatible con el modelo de implementación clásica.

¿Cuál es el período de tiempo de espera para las solicitudes RADIUS enviadas al servidor RADIUS?

Las solicitudes RADIUS están configuradas para expirar después de 30 segundos. Actualmente, no se admiten valores de tiempo de espera definidos por el usuario.

¿Se admiten servidores RADIUS de terceros?

Sí, se admiten.

¿Cuáles son los requisitos de conectividad para garantizar que la puerta de enlace de Azure pueda comunicarse con un servidor RADIUS local?

Se necesita una conexión VPN de sitio a sitio en el sitio local, con las rutas apropiadas configuradas.

¿Puede enrutarse el tráfico a un servidor RADIUS local (desde la instancia de Azure VPN Gateway) a través de una conexión ExpressRoute?

No. Solo puede enrutarse a través de una conexión de sitio a sitio.

¿Ha cambiado el número de conexiones SSTP admitidas con autenticación RADIUS? ¿Cuál es el número máximo de conexiones SSTP e IKEv2 admitidas?

El número máximo de conexiones SSTP admitidas en una puerta de enlace con autenticación RADIUS no ha cambiado. Sigue siendo 128 para SSTP, pero depende de la SKU de puerta de enlace para IKEv2. Para más información sobre el número de conexiones admitidas, consulte SKU de puerta de enlace.

¿En qué se diferencia la autenticación de certificados con un servidor RADIUS de la realizada con la autenticación mediante certificados nativos de Azure (al cargar un certificado de confianza en Azure)?

En la autenticación de certificados RADIUS, la solicitud de autenticación se reenvía a un servidor RADIUS que realiza la validación del certificado real. Esta opción es útil si desea integrarla con una infraestructura de autenticación de certificados a través de RADIUS de la que ya disponga.

Cuando se utiliza Azure para la autenticación de certificados, la instancia de Azure VPN Gateway realiza la validación del certificado. Debe cargar la clave pública del certificado en la puerta de enlace. También puede especificar una lista de certificados revocados que no podrán conectarse.

¿La autenticación RADIUS funciona con IKEv2 y SSTP VPN?

Sí, la autenticación RADIUS es compatible con IKEv2 y SSTP VPN.

¿La autenticación RADIUS funciona con el cliente de OpenVPN?

La autenticación RADIUS no es compatible con el protocolo OpenVPN.

Conexiones entre dos redes virtuales y multisitio

Las preguntas más frecuentes sobre red virtual a red virtual se aplican a las conexiones de VPN Gateway. Para más información sobre el emparejamiento de redes virtuales, consulte Emparejamiento de redes virtuales.

¿Cobra Azure por el tráfico entre redes virtuales?

El tráfico entre redes virtuales dentro de la misma región es gratuito en ambas direcciones cuando se usa una conexión de puerta de enlace de VPN. El tráfico de salida de red virtual a red virtual entre regiones se cobra según las tarifas de transferencia de datos de salida entre redes virtuales en función de las regiones de origen. Para más información, consulte la página de precios de VPN Gateway. Si conecta las redes virtuales mediante el emparejamiento de redes virtuales en lugar de una puerta de enlace de red virtual, consulte los precios de redes virtuales.

¿Viaja el tráfico entre dos redes virtuales a través de Internet?

No. Viaja por la red troncal de Microsoft Azure, no por Internet.

¿Puedo establecer una conexión de red virtual a red virtual entre inquilinos de Microsoft Entra?

Sí, las conexiones de red virtual a red virtual que usan puertas de enlace de VPN de Azure funcionan entre los inquilinos de Microsoft Entra.

¿Es seguro el tráfico entre dos redes virtuales?

Sí, se protege mediante cifrado IPsec/IKE.

¿Necesito un dispositivo VPN para conectar redes virtuales?

No. La conexión simultánea de varias redes virtuales de Azure no requiere dispositivos VPN, a menos que sea necesaria la conectividad entre locales.

¿Deben estar mis redes virtuales en la misma región?

No. Las redes virtuales pueden estar en la misma región de Azure o en regiones distintas (ubicaciones).

Si las redes virtuales no están en la misma suscripción, ¿las suscripciones tienen que estar asociadas con el mismo inquilino de Active Directory?

No.

¿Puedo usar una conexión entre redes virtuales para conectar redes virtuales en instancias independientes de Azure?

No. La conexión entre redes virtuales permite conectar redes virtuales dentro de la misma instancia de Azure. Por ejemplo, no puede crear una conexión entre instancias de Azure del gobierno estadounidense, chino o alemán con una instancia global de Azure. Considere la posibilidad de usar una conexión VPN de sitio a sitio en estos escenarios.

¿Puedo usar las conexiones entre dos redes virtuales con conexiones multisitio?

Sí. La conectividad de red virtual se puede usar de forma simultánea con VPN de varios sitios.

¿A cuántos sitios locales y redes virtuales se puede conectar una red virtual?

Consulte la tabla Requisitos de la puerta de enlace.

¿Puedo usar la conexión entre dos redes virtuales para conectar máquinas virtuales o servicios en la nube fuera de una red virtual?

No. VNet a VNet admite la conexión de redes virtuales. No admite la conexión de máquinas virtuales ni servicios en la nube que no estén en una red virtual.

¿Abarca redes virtuales un servicio en la nube o un punto de conexión de equilibrio de carga?

No. Un servicio en la nube o un punto de conexión de equilibrio de carga no puede abarcar varias redes virtuales, aunque estas estén conectadas entre sí.

¿Puedo usar un tipo de VPN PolicyBased para las conexiones entre dos redes virtuales o multisitio?

No. Las conexiones entre dos redes virtuales y multisitio requieren puertas de enlace de VPN de Azure con tipos de VPN RouteBased (antes denominado enrutamiento dinámico).

¿Puedo conectar una red virtual con un tipo de VPN RouteBased a otra red virtual con un tipo de VPN PolicyBased?

No, ambas redes virtuales TIENEN que usar VPN basadas en enrutamiento (antes denominado enrutamiento dinámico).

¿Comparten ancho de banda los túneles de VPN?

Sí. Todos los túneles de VPN de la red virtual comparten el ancho de banda disponible en la puerta de enlace de VPN de Azure y el mismo SLA de tiempo de actividad de puerta de enlace de VPN en Azure.

¿Se admiten túneles redundantes?

Los túneles redundantes entre dos redes virtuales se admiten cuando la puerta de enlace de una red virtual está configurada como activa-activa.

¿Puedo tener espacios de direcciones superpuestos para configuraciones de red virtual a red virtual?

No. No puede tener intervalos de direcciones de IP superpuestos.

¿Puede haber espacios de direcciones superpuestos entre las redes virtuales conectadas y los sitios locales?

No. No puede tener intervalos de direcciones de IP superpuestos.

¿Cómo habilito el enrutamiento entre mi conexión VPN de sitio a sitio y mi ExpressRoute?

Si quiere habilitar el enrutamiento entre la rama conectada a ExpressRoute y la rama conectada a una conexión VPN de sitio a sitio, debe configurar Azure Route Server.

¿Puedo usar la puerta de enlace de VPN de Azure para el tráfico en tránsito entre mis sitios locales o a otra red virtual?

Modelo de implementación del Administrador de recursos
Sí. Para más información, consulte la sección BGP.

Modelo de implementación clásica
el tráfico en tránsito a través de Puerta de enlace de VPN de Azure es posible mediante el modelo de implementación clásica, pero se basa en espacios de direcciones definidos estáticamente en el archivo de configuración de red. BGP aún no se admite con instancias de Azure Virtual Network y VPN Gateway mediante el modelo de implementación clásica. Sin BGP, definir manualmente los espacios de direcciones de tránsito es difícil de hacer sin errores y no se recomienda.

¿Azure genera la misma clave precompartida de IPsec/IKE para todas mis conexiones VPN para la misma red virtual?

No, Azure de forma predeterminada genera distintas claves precompartidas para distintas conexiones VPN. Sin embargo, puede utilizar la API REST Set VPN Gateway Key para establecer la clave de VPN Gateway o el cmdlet PowerShell para establecer el valor de clave que prefiera. La clave DEBE contener únicamente caracteres ASCII imprimibles con la excepción del espacio, el guion (-) o la tilde (~).

¿Tengo más ancho de banda con más VPN de sitio a sitio que si tengo una única red virtual?

No, todos los túneles VPN, incluidas las VPN de punto a sitio, comparten la misma puerta de enlace de VPN de Azure y el ancho de banda disponible.

¿Puedo configurar varios túneles entre mi red virtual y mi sitio local utilizando VPN multisitio?

Sí, pero debe configurar BGP en ambos túneles de la misma ubicación.

¿Respeta Azure VPN Gateway la anteposición de la ruta de acceso de AS para influir en las decisiones de enrutamiento entre varias conexiones a mis sitios locales?

Sí, Azure VPN Gateway respetará la anteposición de la ruta de acceso de AS para ayudar a tomar decisiones de enrutamiento cuando el protocolo de puerta de enlace de borde esté habilitado. Se preferirá una ruta de acceso de AS más corta en la selección de la ruta de acceso del protocolo de puerta de enlace de borde.

¿Puedo usar la propiedad RoutingWeight al crear una conexión VPN VirtualNetworkGateway?

No, esta configuración está reservada para las conexiones de puerta de enlace de ExpressRoute. Si quiere influir en las decisiones de enrutamiento entre varias conexiones, debe usar la anteposición de la ruta de acceso AS.

¿Puedo usar VPN de punto a sitio con mi red virtual con varios túneles VPN?

Sí, las VPN de punto a sitio (P2S) se pueden usar con las puertas de enlace de VPN para conectarse a varios sitios locales y a otras redes virtuales.

¿Puedo conectar una red virtual con VPN sobre IPsec a mi circuito de ExpressRoute?

Sí, se admite, Para más información, consulte Configurar conexiones VPN ExpressRoute y sitio a sitio que coexistan.

Directiva de IPsec o IKE

¿Se admite la directiva de IPsec o IKE personalizada en todas las SKU de Azure VPN Gateway?

La directiva de IPsec o IKE personalizada se admite en todas las SKU de Azure, excepto la SKU básica.

¿Cuántas directivas puedo especificar en una conexión?

No puede especificar más de una combinación de directivas para una conexión dada.

¿Se puede especificar una directiva parcial en una conexión? (por ejemplo, solo algoritmos IKE, pero no IPsec)

No, es preciso especificar todos los algoritmos y parámetros de IKE (modo principal) e IPsec (modo rápido). No se permite la especificación de una directiva parcial.

¿Cuáles son los algoritmos y los niveles de las claves que se admiten en la directiva personalizada?

En la tabla siguiente se enumeran los algoritmos criptográficos y los valores de clave admitidos que puede configurar. Es preciso seleccionar una opción en cada campo.

IPsec o IKEv2	Opciones
Cifrado IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128
Integridad de IKEv2	SHA384, SHA256, SHA1, MD5
Grupo DH	DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, No
Cifrado IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, No
Integridad de IPsec	GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, No
Vigencia de SA QM	(Opcional: Se usan los valores predeterminados si no se especifica ningún valor) Segundos (entero; mín. 300/predeterminado 27000 segundos) KBytes (entero; mín. 1024/predeterminado 102400000 KBytes)
Selector de tráfico	UsePolicyBasedTrafficSelectors** ($True/$False; Opcional, valor predeterminado $False si no se especifica)
Tiempo de expiración de DPD	Segundos (entero; mín. 9/máx. 3600; predeterminado 45 segundos)

• La configuración de su dispositivo VPN local debe coincidir o contener los siguientes algoritmos y parámetros que se especifican en la directiva de IPsec o IKE de Azure:

  • Algoritmo de cifrado de IKE (modo principal/fase 1)
  • Algoritmo de integridad de IKE (modo principal/fase 1)
  • Grupo DH (modo principal/fase 1)
  • Algoritmo de cifrado de IPsec (modo rápido/fase 2)
  • Algoritmo de integridad de IPsec (modo rápido/fase 2)
  • Grupo PFS (modo rápido/fase 2)
  • Selector de tráfico (si se usa UsePolicyBasedTrafficSelectors)
  • Las vigencias de SA solo son especificaciones locales y no es preciso que coincidan.

• Si GCMAES se usa para el algoritmo de cifrado IPsec, es preciso seleccionar el mismo algoritmo GCMAES y longitud de clave para la integridad de IPsec; por ejemplo, usar GCMAES128 para ambos.

• En la tabla de algoritmos y claves:

  • IKE corresponde al modo principal o fase 1.
  • IPsec corresponde al modo rápido o fase 2.
  • El Grupo DH especifica el grupo Diffie-Hellman utilizado en el modo principal o fase 1.
  • El grupo PFS especificó el grupo Diffie-Hellman utilizado en el modo rápido o la fase 2.

• La vigencia de SA del modo principal de IKE se fija en 28 800 en las puertas de enlace de VPN de Azure.

• "UsePolicyBasedTrafficSelectors" es un parámetro opcional en la conexión. Si establece UsePolicyBasedTrafficSelectors en $True en una conexión, configurará la puerta de enlace de VPN de Azure para que se conecte al firewall de VPN basado en directivas de forma local. Si habilita PolicyBasedTrafficSelectors, debe asegurarse de que el dispositivo VPN tiene los selectores de tráfico coincidentes definidos con todas las combinaciones de sus prefijos de red local (puerta de enlace de red local) a o desde los prefijos de red virtual de Azure, en lugar de cualquiera a cualquiera. La puerta de enlace de VPN de Azure acepta cualquier selector de tráfico propuesto por la puerta de enlace de VPN remota independientemente de lo que esté configurado en la puerta de enlace de VPN de Azure.

  Por ejemplo, si sus prefijos de red local son 10.1.0.0/16 y 10.2.0.0/16, y sus prefijos de red virtual son 192.168.0.0/16 y 172.16.0.0/16, debe especificar los siguientes selectores de tráfico:

  • 10.1.0.0/16 <====> 192.168.0.0/16
  • 10.1.0.0/16 <====> 172.16.0.0/16
  • 10.2.0.0/16 <====> 192.168.0.0/16
  • 10.2.0.0/16 <====> 172.16.0.0/16

  Para obtener más información sobre los selectores de tráfico basados en directivas, consulte Connect multiple on-premises policy-based VPN devices (Conectar varios dispositivos VPN basados en directivas locales).

• Tiempo de expiración de DPD: el valor predeterminado es 45 segundos en las puertas de enlace de VPN de Azure. Si se establece el tiempo de expiración en un periodo menor, IKE volverá a especificar la clave de forma más agresiva, lo que provoca que en algunos momentos parezca que la conexión está desconectada, algo que no se desea si las ubicaciones locales están lejos de la región de Azure en la que reside la puerta de enlace de VPN o si el estado de vínculo físico puede llegar a provocar la pérdida de paquetes. La recomendación general es establecer el tiempo de expiración entre 30 y 45segundos.

Para más información, consulte Connect multiple on-premises policy-based VPN devices (Conexión de varios dispositivos VPN basados en directivas locales).

¿Qué grupos Diffie-Hellman se admiten?

En la tabla siguiente se muestran los grupos Diffie-Hellman admitidos en la directiva personalizada:

Grupo Diffie-Hellman	Grupo DH	Grupo PFS	Longitud de clave
1	DHGroup1	PFS1	MODP de 768 bits
2	DHGroup2	PFS2	MODP de 1024 bits
14	DHGroup14 DHGroup2048	PFS2048	MODP de 2048 bits
19	ECP256	ECP256	ECP de 256 bits
20	ECP384	ECP384	ECP de 384 bits
24	DHGroup24	PFS24	MODP de 2048 bits

Consulte RFC3526 y RFC5114 para ver información más detallada.

¿Reemplaza la directiva personalizada los conjuntos de directivas de IPsec o IKE predeterminados en las puertas de enlace de VPN de Azure?

Sí, una vez que se especifica una directiva personalizada en una conexión, Azure VPN Gateway solo utilizará la directiva en la conexión, no solo como iniciador de IKE sino también como respondedor de IKE.

Si quito una directiva de IPsec o IKE personalizada, ¿se que la conexión desprotegida?

No, IPsec o IKE seguirán protegiendo la protección. Una vez que se quite la directiva personalizada de una conexión, Azure VPN Gateway vuelve a la lista predeterminada de las propuestas de IPsec o IKE, y vuelve a iniciar el protocolo de enlace de IKE con un dispositivo VPN local.

¿Afectarían a mi conexión VPN la incorporación o actualización de una directiva de IPsec o IKE?

Sí, podría producirse una pequeña interrupción (unos segundos), ya que Azure VPN Gateway anula la conexión existente y vuelve a iniciar el protocolo de enlace de IKE para restablecer el túnel IPsec con los nuevos parámetros y algoritmos criptográficos. Asegúrese de que el dispositivo VPN local también se configura con los algoritmos y niveles de claves coincidentes para minimizar dicha interrupción.

¿Se pueden usar distintas directivas en conexiones diferentes?

Sí. La directiva personalizada se aplica en función de la conexión. Puede crear y aplicar distintas directivas de IPsec o IKE en conexiones diferentes. También puede elegir aplicar directivas personalizadas a un subconjunto de las conexiones. Las restantes usan los conjuntos de directivas de IPsec o IKE predeterminados de Azure.

¿Se puedo usar la directiva personalizada también en una conexión entre redes virtuales?

Sí, puede aplicar directivas personalizadas en las conexiones entre entornos de IPsec o las conexiones entre redes virtuales.

¿Es preciso especificar la misma directiva en los dos recursos de la conexión entre redes virtuales?

Sí. Un túnel entre redes virtuales consta de dos recursos de conexión en Azure, una para cada dirección. Asegúrese de que los dos recursos de conexión tienen la misma directiva, ya que, de no ser así, la conexión entre redes virtuales no se establecerá.

¿Cuál es el valor predeterminado del tiempo de espera de DPD? ¿Se puede especificar otro tiempo de espera de DPD?

El tiempo de espera de DPD predeterminado es de 45 segundos. Se puede especificar otro valor del tiempo de espera de DPD diferente en cada IPsec y en cada conexión de red virtual a red virtual, desde 9 segundos hasta 3 600 segundos.

Nota

El valor predeterminado es de 45 segundos en las pasarelas VPN de Azure. Si se establece el tiempo de expiración en un periodo menor, IKE volverá a especificar la clave de forma más agresiva, lo que provoca que en algunos momentos parezca que la conexión está desconectada, Esto puede no ser deseable si sus ubicaciones locales están más alejadas de la región de Azure donde reside la puerta de enlace VPN, o cuando la condición física del vínculo podría provocar la pérdida de paquetes. La recomendación general es establecer el tiempo de expiración entre 30 y 45segundos.

¿Funciona la directiva de IPsec o IKE personalizada en una conexión ExpressRoute?

No. La directiva de IPsec o IKE solo funciona en conexiones entre redes virtuales a través de las puertas de enlace de VPN de Azure y VPN de S2S.

Creación de conexiones con el tipo de protocolo IKEv1 o IKEv2

Se pueden crear conexiones IKEv1 en todas las SKU de tipo VPN RouteBased, excepto la SKU básica, SKU estándar y otras SKU heredadas. Puede especificar un tipo de protocolo de conexión IKEv1 o IKEv2 al crear conexiones. Si no especifica un tipo de protocolo de conexión, se utiliza IKEv2 como opción predeterminada cuando proceda. Para más información, consulte la documentación del cmdlet de PowerShell. Para los tipos de SKU y la compatibilidad con IKEv1 y IKEv2, consulte Conexión de puertas de enlace a dispositivos VPN basados en directivas.

¿Se permite el tránsito entre las conexiones IKEv1 y IKEv2?

Sí. Se admite el tránsito entre conexiones IKEv1 e IKEv2.

¿Puedo tener conexiones de sitio a sitio de IKEv1 en SKU básicas del tipo de VPN RouteBased?

No. La SKU Básica no admite esto.

¿Puedo cambiar el tipo de protocolo de conexión después de crear la conexión (IKEv1 a IKEv2 y viceversa)?

No. Cuando se crea la conexión, los protocolos IKEv1 y IKEv2 no se pueden cambiar. Debe eliminar y volver a crear una nueva conexión con el tipo de protocolo deseado.

¿Por qué se reconecta mi conexión IKEv1 con frecuencia?

Si el enrutamiento estático o la conexión IKEv1 basada en rutas se desconectan a intervalos rutinarios, es probable que se deba a que las puertas de enlace de la VPN no admiten volver a especificar las claves in situ. Cuando se vuelve a especificar la clave del modo principal, los túneles IKEv1 se desconectan y tardan hasta 5 segundos en volver a conectarse. El tiempo de espera de negociación del modo principal determina la frecuencia para volver a especificar las claves. Para evitar estas reconexiones, vuelva a usar IKEv2, que admite volver a especificar las claves in situ.

Si la conexión se restablece a intervalos aleatorios, siga nuestra guía de solución de problemas.

¿Dónde puedo encontrar información y pasos de configuración?

Consulte los siguientes artículos para obtener más información y pasos de configuración.

• Configuración de una directiva IPsec o IKE para conexiones S2S o conexiones de red virtual a red virtual: Azure Portal
• Configuración de una directiva IPsec o IKE para conexiones S2S o conexiones de red virtual a red virtual: Azure PowerShell

BGP y enrutamiento

¿Se admite BGP en todas las SKU de Azure VPN Gateway?

El protocolo de puerta de enlace de borde se admite en todas las SKU de Azure VPN Gateway, excepto en la SKU básica.

¿Se puede usar BGP con puertas de enlace de VPN de Azure Policy?

No, BGP solo es compatible con puertas de enlace de VPN basadas en rutas.

¿Qué ASN (números de sistema autónomo) se pueden usar?

Se pueden usar los ASN públicos propios o los ASN privados tanto para las redes locales como para las redes virtuales de Azure. No se pueden usar los rangos reservados por Azure o IANA.

Los siguientes ASN están reservados por Azure o IANA:

• ASN reservados por Azure:

  • ASN públicos: 8074, 8075, 12076
  • ASN privados: 65515, 65517, 65518, 65519, 65520

• ASN reservados por IANA:

  • 23456, 64496-64511, 65535-65551 y 429496729

Al conectarse a las puertas de enlace de VPN de Azure, no puede especificar estos ASN para los dispositivos VPN locales.

¿Se pueden usar ASN de 32 bits (4 bytes)?

Sí, VPN Gateway ahora admite ASN de 32 bits (4 bytes). Para usar ASN en formato decimal en la configuración, use PowerShell, la CLI de Azure o el SDK de Azure.

¿Qué ASN privados se pueden usar?

Estos son los rangos de ASN privados que se pueden usar:

• 64512-65514 y 65521-65534

Ni IANA ni Azure han reservado estos ASN para su uso, por lo que se pueden utilizar para asignarlos a una puerta de enlace de VPN de Azure.

¿Qué dirección utiliza VPN Gateway para la IP del par de BGP?

De manera predeterminada, VPN Gateway asigna una única dirección IP del rango de GatewaySubnet para las puertas de enlace de VPN en modo activo/en espera, o bien dos direcciones IP para puertas de enlace de VPN en modo activo/activo. Estas direcciones se asignan automáticamente al crear la puerta de enlace de VPN. Para obtener la dirección IP de BGP real asignada, utilice PowerShell, o bien búsquela en Azure Portal. En PowerShell, use Get-AzVirtualNetworkGateway y busque la propiedad bgpPeeringAddress. En Azure Portal, en la página Configuración de puerta de enlace, fíjese en la propiedad Configurar ASN BGP.

Si los enrutadores locales de la red privada virtual utilizan las direcciones IP (169.254.x.x) de APIPA como direcciones IP del protocolo de puerta de enlace de borde, es preciso especificar una o más direcciones IP de BGP de APIPA de Azure en la puerta de enlace de VPN de Azure. Azure VPN Gateway selecciona las direcciones de APIPA que se van a usar con el par BGP de APIPA especificado de la puerta de enlace de red local, o bien una dirección IP privada, en el caso del par BGP local que no sea APIPA. Para más información, consulte el artículo sobre la configuración del protocolo de puerta de enlace de borde.

¿Cuáles son los requisitos de las direcciones IP del par BGP en mi dispositivo VPN?

La dirección del par BGP local no debe coincidir con la dirección IP pública del dispositivo VPN ni con el espacio de direcciones de red virtual de la puerta de enlace de red virtual. Use otra dirección IP en el dispositivo VPN para la dirección IP del par BGP. Puede ser una dirección asignada a la interfaz de bucle invertido del dispositivo (puede ser una dirección IP normal o una dirección de APIPA). Si el dispositivo usa una dirección de APIPA para el protocolo de puerta de enlace de borde, es preciso especificar una o más direcciones IP de APIPA BGP en una puerta de enlace de VPN de Azure, como se describe en Configuración de BGP. Especifique estas direcciones en la puerta de enlace de red local correspondiente que representa la ubicación.

¿Qué debo especificar como mis prefijos de dirección para la puerta de enlace de red local al utilizar BGP?

Importante

Aquí se ha producido un cambio, con respecto al requisito que estaba documentado. Si usa el protocolo de puerta de enlace de borde para una conexión, deje vacío el campo Espacio de direcciones del recurso de la puerta de enlace de red local correspondiente. Azure VPN Gateway agrega internamente una ruta de host a la IP del par BGP local a través del túnel IPsec. No agregue la ruta /32 en el campo Espacio de direcciones. Es redundante y si usa una dirección de APIPA como la IP del protocolo de puerta de enlace de borde del dispositivo VPN local, no podrá agregarla a este campo. Si agrega otros prefijos en el campo Espacio de direcciones, se agregan como rutas estáticas en la puerta de enlace de VPN de Azure, además de las rutas aprendidas a través del protocolo de puerta de enlace de borde.

¿Se puede usar el mismo ASN para redes VPN locales y redes virtuales de Azure?

No, si va a conectar redes locales y redes virtuales de Azure con el protocolo de puerta de enlace de borde, debe asignar ASN diferentes a cada una de ellas. Las puertas de enlace de VPN de Azure tienen un ASN predeterminado de 65515 asignado, independientemente de que BGP esté habilitado, o no, para la conectividad entre locales. Para invalidar este valor predeterminado, asigne otro ASN al crear la puerta de enlace de VPN o cambie el ASN después de crearla. Tiene que asignar los ASN locales a las puertas de enlace de red local de Azure correspondientes.

¿Qué prefijos de direcciones de puertas de enlace de VPN de Azure se me anunciarán?

Las puertas de enlace anuncian las siguientes rutas a los dispositivos BGP locales:

• Los prefijos de direcciones de red virtual.
• Los prefijos de dirección de las puertas de enlace de red local conectadas a la puerta de enlace de VPN de Azure.
• Las rutas aprendidas de otras sesiones de emparejamiento de BGP conectadas a la puerta de enlace de VPN de Azure, excepto la ruta predeterminada o las rutas que se superpongan con cualquier prefijo de red virtual.

¿Cuántos prefijos se pueden anunciar en Azure VPN Gateway?

Azure VPN Gateway admite hasta 4000 prefijos. Si el número de prefijos supera el límite, se elimina la sesión BGP.

¿Puedo anunciar la ruta predeterminada (0.0.0.0/0) para puertas de enlace de VPN de Azure?

Sí. Tenga en cuenta que esto obliga a que todo el tráfico de salida de red virtual se dirija hacia el sitio local. También impide que las máquinas virtuales de la red virtual acepten directamente la comunicación pública desde Internet, como RDP o SSH desde Internet a las máquinas virtuales.

¿Puedo anunciar los mismos prefijos que mis prefijos de red virtual?

No, Azure bloqueará o filtrará el anuncio de los mismos prefijos que los de cualquiera de sus otros prefijos de dirección de red virtual. Sin embargo, se puede anunciar un prefijo que sea un superconjunto de lo que contenga su red virtual.

Por ejemplo, si una red virtual ha usado el espacio de direcciones 10.0.0.0/16, se puede anunciar el 10.0.0.0/8. Sin embargo, no se pueden anunciar el 10.0.0.0/16 ni el 10.0.0.0/24.

¿Se puede usar el protocolo de puerta de enlace de borde con las conexiones entre redes virtuales?

Sí, BGP se puede usar tanto para conexiones entre locales como para conexiones entre redes virtuales.

¿Puedo combinar BGP con conexiones no de BGP para mi puertas de enlace de VPN de Azure?

Sí, puede mezclar conexiones de BGP y no de BGP para la misma puerta de enlace de VPN de Azure.

¿Admite Azure VPN Gateway el enrutamiento del tránsito de BGP?

Sí, se admite el enrutamiento del tránsito de BGP, pero las puertas de enlace de VPN de Azure no anuncian las rutas predeterminadas a otros pares de BGP. Para habilitar el enrutamiento del tránsito a través de varias puertas de enlace de VPN de Azure, es preciso habilitar el protocolo de puerta de enlace de borde en todas las conexiones intermedias entre las redes virtuales. Para más información, consulte Acerca de BGP.

¿Puedo tener más de un túnel entre una puerta de enlace de VPN de Azure y mi red local?

Sí, puede establecer varios túneles VPN de sitio a sitio (S2S) entre una puerta de enlace de VPN de Azure y la red local. Tenga en cuenta que todos estos túneles se incluyen en el recuento total de túneles de las puertas de enlace de la VPN de Azure y el protocolo de puerta de enlace de borde debe habilitarse en los dos túneles.

Por ejemplo, si tiene dos túneles redundantes entre una puerta de enlace de VPN de Azure y una de las redes locales, consumen dos de los túneles de la cuota total para la puerta de enlace de VPN de Azure.

¿Puedo tener varios túneles entre dos redes virtuales de Azure con BGP?

Sí, pero al menos una de las puertas de enlace de la red virtual debe estar en una configuración activa-activa.

¿Se puede usar BGP para VPN de sitio a sitio en una configuración en que coexisten una VPN de sitio a sitio y ExpressRoute?

Sí.

¿Qué debo agregar a mi dispositivo VPN local para la sesión de emparejamiento BGP?

Agregue una ruta de host de la dirección IP del par BGP de Azure al dispositivo VPN. Esta ruta apunta al túnel VPN de sitio a sitio de IPsec. Por ejemplo, si la dirección IP del par VPN de Azure es 10.12.255.30, debe agregar una ruta de host para 10.12.255.30 con una interfaz de próximo salto de la interfaz de túnel IPsec coincidente en el dispositivo VPN.

¿Admite la puerta de enlace de red virtual BFD para las conexiones S2S con BGP?

No. Detección de reenvío bidireccional (BFD) es un protocolo que se puede usar con el protocolo de puerta de enlace de borde para detectar el tiempo de inactividad del vecino más rápidamente que si se usan conexiones persistentes BGP estándar. BFD usa temporizadores de subsegundo diseñados para funcionar en entornos de LAN, pero no en las conexiones de red de área extensa o de la red pública de Internet.

En el caso de las conexiones a través de la red pública de Internet, no es inusual que algunos paquetes se retrasen, o incluso se eliminen, por lo que la introducción de estos agresivos temporizadores puede agregar inestabilidad, y dicha inestabilidad podría provocar que BGP amortiguara las rutas. Como alternativa, puede configurar un dispositivo local con temporizadores inferiores al intervalo de conexión persistente predeterminado de 60 segundos el temporizador de retención de 180 segundos, con lo que se obtiene un menor tiempo de convergencia. Sin embargo, los temporizadores por debajo del intervalo predeterminado de 60 segundos "keepalive" o por debajo del temporizador de retención predeterminado de 180 segundos no son confiables. Se recomienda mantener los temporizadores en o por encima de los valores predeterminados.

¿Las puertas de enlace de VPN de Azure inician conexiones o sesiones de emparejamiento BGP?

La puerta de enlace iniciará sesiones de emparejamiento de protocolo de puerta de enlace de borde (o BGP) con las direcciones IP del par BGP especificadas en los recursos de puerta de enlace de red local mediante las direcciones IP privadas de las puertas de enlace de VPN. Este escenario se da con independencia de si las direcciones IP BGP locales están en el intervalo APIPA o son direcciones IP privadas normales. Si los dispositivos VPN locales usan direcciones APIPA como IP BGP, debe configurar el altavoz BGP para iniciar las conexiones.

¿Puedo configurar una tunelización forzada?

Sí. Consulte Configurar una tunelización forzada.

NAT

¿Se admite NAT en todas las SKU de Azure VPN Gateway?

NAT se admite en VpnGw2~5 y VpnGw2AZ~5AZ.

¿Puedo usar NAT en conexiones de red virtual a red virtual o P2S?

No.

¿Cuántas reglas NAT puedo usar en una puerta de enlace de VPN?

Puede crear hasta 100 reglas NAT (reglas Ingress y Egress combinadas) en una puerta de enlace de VPN.

¿Puedo usar / en un nombre de regla NAT?

No. Recibirá un error.

¿Se aplica NAT a todas las conexiones en una puerta de enlace de VPN?

NAT se aplica a las conexiones con reglas NAT. Si alguna conexión no tiene ninguna regla NAT, no se le aplicará NAT. En la misma puerta de enlace de VPN, puede tener algunas conexiones con NAT y otras sin NAT que funcionen conjuntamente.

¿Qué tipos de NAT se admiten en las puertas de enlace de VPN de Azure?

Solo se admiten NAT estáticos 1:1 y NAT dinámicos. No se admite NAT64.

¿Funciona NAT en puertas de enlace VPN activo-activo?

Sí. NAT funciona en puertas de enlace VPN activo-activo y en espera activo. Cada regla NAT se aplica a una sola instancia de VPN Gateway. En las puertas de enlace activas-activas, cree una regla NAT independiente para cada instancia de puerta de enlace mediante el campo "Id. de configuración de IP".

¿Funciona NAT con las conexiones BGP?

Sí, se puede usar BGP con NAT. A continuación se indican algunas consideraciones importantes:

• Seleccione Enable BGP Route Translation (Habilitar traducción de rutas BGP) en la página de configuración de reglas NAT para asegurarse de que las rutas aprendidas y las rutas anunciadas se traducen a prefijos de dirección posteriores a NAT (asignaciones externas) en función de las reglas NAT asociadas a las conexiones. Debe asegurarse de que los enrutadores BGP locales anuncien los mismos prefijos, tal y como se define en las reglas IngressSNAT.

• Si el enrutador VPN local usa una dirección normal que no es de APIPA y se intercala con el espacio de direcciones de la red virtual o con otros espacios de red locales, asegúrese de que la regla IngressSNAT traducirá la dirección IP del par BGP a una dirección única no superpuesta y colocará la dirección posterior a NAT en el campo Dirección IP del nodo del mismo nivel BGP de la puerta de enlace de red local.

• NAT no es compatible con las direcciones BGP APIPA.

¿Debo crear las reglas DNAT correspondientes para la regla SNAT?

No. Una sola regla SNAT define la traducción para ambas direcciones de una red determinada:

• Una regla IngressSNAT define la traducción de las direcciones IP de origen que llegan a la puerta de enlace de VPN de Azure desde la red local. También controla la traducción de las direcciones IP de destino que salen de la red virtual hacia la misma red local.

• Una regla EgressSNAT define la traducción de las direcciones IP de origen de la red virtual que salen de la puerta de enlace de VPN de Azure a redes locales. También controla la traducción de las direcciones IP de destino para los paquetes que llegan a la red virtual por medio de esas conexiones con la regla EgressSNAT.

• En cualquier caso, no se necesita ninguna regla DNAT.

¿Qué debo hacer si el espacio de direcciones de la puerta de enlace de red local o de red virtual tiene dos o más prefijos? ¿Puedo aplicarles NAT a todos? ¿O solo a un subconjunto?

Debe crear una regla NAT para cada prefijo que necesite en NAT, ya que cada regla NAT solo puede incluir un prefijo de dirección para NAT. Por ejemplo, si el espacio de direcciones de la puerta de enlace de red local se compone de 10.0.1.0/24 y 10.0.2.0/25, puede crear dos reglas tal y como se muestra a continuación:

• Regla IngressSNAT 1: asignar 10.0.1.0/24 a 100.0.1.0/24
• Regla IngressSNAT 2: asignar 10.0.2.0/25 a 100.0.2.0/25

Las dos reglas deben hacer coincidir las longitudes de los prefijos de dirección correspondientes. Lo mismo se aplica a las reglas EgressSNAT para un espacio de direcciones de red virtual.

Importante

Si solo vincula una regla a la conexión anterior, el otro espacio de direcciones NO se traducirá.

¿Qué intervalos IP pueden usarse para la asignación externa?

La asignación externa admite cualquier intervalo IP adecuado que desee usar. Esto incluye las direcciones IP públicas y privadas.

¿Puedo usar reglas EgressSNAT distintas para traducir el espacio de direcciones de red virtual a distintos prefijos para redes locales diferentes?

Sí, puede crear varias reglas EgressSNAT para el mismo espacio de direcciones de red virtual y aplicar dichas reglas a distintas conexiones.

¿Puedo usar la misma regla IngressSNAT en conexiones distintas?

Sí, esto suele hacerse cuando son conexiones para la misma red local a fin de proporcionar redundancia. Si las conexiones son para redes locales distintas, no se puede usar la misma regla de Ingress.

¿Necesito tanto reglas Ingress como Egress en una conexión NAT?

Necesita tanto reglas Ingress como Egress en la misma conexión cuando el espacio de direcciones de red local se superpone con el espacio de direcciones de la red virtual. Si el espacio de direcciones de la red virtual es único entre todas las redes conectadas, no se necesitará la regla EgressSNAT en esas conexiones. Puede usar las reglas Ingress para evitar la superposición de direcciones entre las redes locales.

¿Qué puedo elegir como "Id. de configuración de IP"?

El "Id. de configuración de IP" es simplemente el nombre del objeto de configuración de IP que quiere que use la regla NAT. Con esta configuración, simplemente elija qué dirección IP pública de puerta de enlace se aplica a la regla NAT. Si no ha especificado ningún nombre personalizado al momento de la creación de la puerta de enlace, la dirección IP principal de la puerta de enlace se asigna a la configuración de IP "predeterminada" y la dirección IP secundaria se asigna a la configuración de IP "activeActive".

Conectividad entre locales y máquinas virtuales

Si mi máquina virtual está en una red virtual y tengo una conexión entre locales, ¿cómo debo conectar a la máquina virtual?

Dispone de varias opciones. Si tiene el RDP habilitado en la máquina virtual, puede conectarse a ella mediante la dirección IP privada. En ese caso, debe especificar la dirección IP privada y el puerto al que desea conectarse (normalmente el 3389). Tendrá que configurar el puerto en la máquina virtual para el tráfico.

También puede conectarse a la máquina virtual mediante la dirección IP privada desde otra máquina virtual que se encuentre en la misma red virtual. Si se conecta desde una ubicación que esté fuera de la red virtual, no podrá usar RDP en la máquina virtual mediante la dirección IP privada. Por ejemplo, si tiene configurada una red virtual de punto a sitio y no establece una conexión desde su equipo, no podrá conectarse a la máquina virtual mediante la dirección IP privada.

¿Si mi máquina virtual está en una red virtual con conectividad entre locales, todo el tráfico de mi máquina virtual pasa a través de esa conexión?

No. Únicamente el tráfico que tiene como destino una IP que se encuentra en los intervalos de direcciones IP de red local de la red virtual que haya especificado pasará a través de la puerta de enlace de red virtual. El tráfico que tenga una IP de destino ubicada dentro de la red virtual permanecerá en la red virtual. El resto del tráfico se envía a través del equilibrador de carga a las redes públicas, o si se usa la tunelización forzada, se envía a través de la puerta de enlace VPN de Azure.

Cómo se solucionan los problemas de una conexión RDP a una máquina virtual

Si tiene problemas para conectarse a una máquina virtual a través de su conexión VPN, compruebe lo siguiente:

• Compruebe que la conexión VPN se ha establecido correctamente.
• Compruebe que se conecta a la dirección IP privada de la máquina virtual.
• Si puede conectarse a la máquina virtual mediante la dirección IP privada, pero no el nombre del equipo, compruebe que ha configurado el DNS correctamente. Para más información acerca de cómo funciona la resolución de nombres para las máquinas virtuales, consulte Resolución de nombres para las máquinas virtuales e instancias de rol.

Cuando se conecta de punto a sitio, compruebe los siguientes elementos adicionales:

• Use "ipconfig" para comprobar la dirección IPv4 asignada al adaptador de Ethernet en el equipo desde el que intenta conectarse. Si la dirección IP está dentro del intervalo de direcciones de la red virtual a la que se va a conectar o dentro del intervalo de direcciones de su VPNClientAddressPool, esto se conoce como un espacio de direcciones superpuesto. Cuando el espacio de direcciones se superpone de esta manera, el tráfico de red no llega a Azure, sino que se mantiene en la red local.
• Compruebe que el paquete de configuración de cliente de VPN se generó después de que se especificaran las direcciones IP del servidor DNS para la red virtual. Si actualizó las direcciones IP de servidor DNS, genere un nuevo paquete de configuración de cliente de VPN e instálelo.

Para más información acerca de la solución de problemas de una conexión RDP, consulte Solución de problemas de conexiones del Escritorio remoto a una máquina virtual de Azure.

Mantenimiento de puertas de enlace controladas por el cliente

¿Qué servicios se incluyen en el ámbito de configuración de mantenimiento de las puertas de enlace de red?

El ámbito de puertas de enlace de red incluye recursos de puerta de enlace en servicios de redes. Hay cuatro tipos de recursos en el ámbito de puertas de enlace de red:

• Puerta de enlace de red virtual en el servicio ExpressRoute.
• Puerta de enlace de red virtual en el servicio VPN Gateway.
• VPN Gateway (sitio a sitio) en el servicio Virtual WAN.
• Puerta de enlace de ExpressRoute en el servicio Virtual WAN.

¿Qué mantenimiento es compatible o no compatible con el mantenimiento controlado por el cliente?

Los servicios de Azure pasan por actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Una vez configurada una ventana de mantenimiento para los recursos, el mantenimiento del sistema operativo invitado y el servicio se realizan durante esa ventana. Las actualizaciones de host, más allá de las actualizaciones de host (TOR, Power, etc.) y las actualizaciones de seguridad críticas, no están cubiertas por el mantenimiento controlado por el cliente.

¿Puedo recibir una notificación avanzada de mantenimiento?

En este momento, no se puede habilitar la notificación avanzada para el mantenimiento de los recursos de puerta de enlace de red.

¿Puedo configurar una ventana de mantenimiento inferior a cinco horas?

Actualmente, debe configurar una ventana de cinco horas como mínimo en la zona horaria preferida.

¿Puedo configurar una ventana de mantenimiento distinta de la programación diaria?

Actualmente, debe configurar una ventana de mantenimiento diaria.

¿Hay casos en los que no pueda controlar determinadas actualizaciones?

El mantenimiento controlado por el cliente admite las actualizaciones del sistema operativo invitado y del servicio. Estas actualizaciones representan la mayoría de los elementos de mantenimiento que preocupan a los clientes. Algunos otros tipos de actualizaciones, incluidas las actualizaciones de host, están fuera del ámbito de mantenimiento controlado por el cliente.

Además, si hay un problema de seguridad de alta gravedad que pueda poner en peligro a nuestros clientes, Azure podría necesitar invalidar el control del cliente de la ventana de mantenimiento e insertar el cambio. Estas ocurre inhabitualmente en casos extremos.

¿Los recursos de configuración de mantenimiento deben estar en la misma región que el recurso de puerta de enlace?

Sí

¿Qué SKU de puerta de enlace se pueden configurar para usar el mantenimiento controlado por el cliente?

Todas las SKU de puerta de enlace (excepto la SKU básica para VPN Gateway) se pueden configurar para usar el mantenimiento controlado por el cliente.

¿Cuánto tiempo tarda la directiva de configuración de mantenimiento en ser efectiva después de asignarla al recurso de puerta de enlace?

Las puertas de enlace de red pueden tardar hasta 24 horas en seguir la programación de mantenimiento después de que la directiva de mantenimiento esté asociada al recurso de puerta de enlace.

¿Existen limitaciones en el uso del mantenimiento controlado por el cliente en función de la dirección IP pública de la SKU básica?

Sí. Los recursos de puerta de enlace que usan una dirección IP pública de SKU básica solo podrán tener actualizaciones de servicio tras la programación de mantenimiento controlada por el cliente. Para estas puertas de enlace, el mantenimiento del sistema operativo invitado no sigue la programación de mantenimiento controlada por el cliente debido a las limitaciones de la infraestructura.

¿Cómo debo planear las ventanas de mantenimiento al usar VPN y ExpressRoute en un escenario de coexistencia?

Al trabajar con VPN y ExpressRoute en un escenario de coexistencia o siempre que tenga recursos que actúen como copias de seguridad, se recomienda configurar ventanas de mantenimiento independientes. Este enfoque garantiza que el mantenimiento no afecte a los recursos de copia de seguridad al mismo tiempo.

He programado una ventana de mantenimiento para una fecha futura para uno de mis recursos. ¿Se pausarán las actividades de mantenimiento en este recurso hasta entonces?

No, las actividades de mantenimiento no se pausarán en el recurso durante el período anterior a la ventana de mantenimiento programada. Durante los días no incluidos en la programación de mantenimiento, el mantenimiento continúa como de costumbre en el recurso.

¿Cómo puedo obtener más información sobre el mantenimiento de puertas de enlace controladas por el cliente?

Para más información, consulte el artículo Mantenimiento de puerta de enlace controlada por el cliente de VPN Gateway.

Pasos siguientes

• Para más información sobre VPN Gateway, consulte Acerca de VPN Gateway.
• Para más información acerca de la configuración de VPN Gateway, consulte Acerca de la configuración de VPN Gateway.

"OpenVPN" es una marca comercial de OpenVPN Inc.