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.

¿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.
• Varios sitios: esta es una variación de una configuración de sitio a sitio que le permite conectar varios sitios locales a una red virtual. Para más información, consulte Varios sitios.
• 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.

¿Qué es una puerta de enlace basada en directivas (de enrutamiento estático)?

Las puertas de enlace basadas en directivas implementan VPN basadas en directivas. Las VPN basadas en directivas cifran y dirigen los paquetes a través de túneles de IPsec basados en las combinaciones de prefijos de dirección entre su red local y la red virtual de Azure. Normalmente, la directiva (o selector de tráfico) se define como una lista de acceso en la configuración de la VPN.

¿Qué es una puerta de enlace basada en enrutamiento (de enrutamiento dinámico)?

Las puertas de enlace basadas en enrutamiento implementan VPN basadas en enrutamiento. Las VPN basadas en enrutamiento utilizan "rutas" en la dirección IP de reenvío o en la tabla de enrutamiento para dirigir los paquetes a sus correspondientes interfaces de túnel. A continuación, las interfaces de túnel cifran o descifran los paquetes dentro y fuera de los túneles. La directiva o los selectores de tráfico para las VPN basadas en enrutamiento se configuran como conectividad de tipo cualquiera a cualquiera (o caracteres comodín).

¿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 aceptan 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).

¿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.

¿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?

Las puertas de enlace de zona y con redundancia de zona (las SKU de puerta de enlace que tienen AZ en el nombre) se basan en un recurso de IP pública de Azure de SKU estándar. 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.

En el caso de las puertas de enlace que no tengan redundancia de zona y que no sean de zona (las SKU de puerta de enlace que no tienen AZ en el nombre), no puede obtener la dirección IP de la puerta de enlace de VPN antes de crearla. Solo si elimina y vuelve a crear la puerta de enlace VPN, la dirección IP cambiará.

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

Las puertas de enlace de zona y con redundancia de zona (las SKU de puerta de enlace que tienen AZ en el nombre) se basan en un recurso de IP pública de Azure de SKU estándar. Los recursos de IP pública de SKU estándar de Azure deben usar un método de asignación estático.

En el caso de las puertas de enlace que no tengan redundancia de zona y que no sean de zona (las SKU de puerta de enlace que no tienen AZ en el nombre), solo se admite la asignación de direcciones IP dinámicas. Sin embargo, esto no significa que la dirección IP cambia después de que se ha asignado a una puerta de enlace 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 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.

Más información acerca de los tipos de puerta de enlace, los requisitos y el rendimiento

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

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, este túnel se cancelará. 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.

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 "Verificar la identidad del servidor validando el certificado" o agregue el FQDN del servidor junto con el certificado al crear un perfil de forma manual. 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.

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 entre dos redes virtuales a través de los inquilinos de Azure Active Directory?

Sí, las conexiones entre dos redes virtuales que usan puertas de enlace de VPN de Azure funcionan en los inquilinos de Azure AD.

¿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 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 niveles de las claves admitidos que pueden configurar los clientes. Es preciso seleccionar una opción en cada campo.

IPsec o IKEv2	Opciones
Cifrado IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128, DES3, DES
Integridad de IKEv2	GCMAES256, GCMAES128, SHA384, SHA256, SHA1, MD5
Grupo DH	DHGroup24, ECP384, ECP256, DHGroup14 (DHGroup2048), DHGroup2, DHGroup1, Ninguno
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	Segundos (entero; mín. 300/predeterminado 27000 segundos) KBytes (entero; mín. 1024/predeterminado 102400000 KBytes)
Selector de tráfico	UsePolicyBasedTrafficSelectors ($True/$False; default $False)

Importante

• DHGroup2048 & PFS2048 son los mismos que el grupo Diffie-Hellman 14 en IKE e IPsec PFS. Consulte Grupos Diffie-Hellman para las asignaciones completas.
• Para los algoritmos GCMAES, debe especificar el mismo algoritmo GCMAES y longitud de clave para el cifrado e integridad de IPsec.
• La vigencia de SA del modo principal de IKEv2 se fija en 28 800 segundos en las puertas de enlace de VPN de Azure.
• Las vigencias de SA de QM son parámetros opcionales. Si no se ha especificado ninguno, se usan los valores predeterminados de 27 000 segundos (7,5 h) y 102 400 000 KBytes (102 GB).
• UsePolicyBasedTrafficSelector es un parámetro de opción en la conexión. Consulte la pregunta frecuente siguiente acerca de "UsePolicyBasedTrafficSelectors".

¿Es preciso que coincidan todos los elementos de la directiva de Azure VPN Gateway con las configuraciones de mis dispositivos VPN locales?

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 IKE
• Algoritmo de integridad de IKE
• Grupo DH
• Algoritmo de cifrado IPsec
• Algoritmo de integridad de IPsec
• Grupo PFS
• Selector de tráfico (*)

Las vigencias de SA solo son especificaciones locales y no es preciso que coincidan.

Si habilita UsePolicyBasedTrafficSelectors, 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. 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 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 enumeran los grupos Diffie-Hellman compatibles para IKE (DHGroup) e IPsec (PFSGroup):

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

Para más información, consulte RFC3526 y RFC5114.

¿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. Dicho valor debe oscilar entre 9 y 3600 segundos.

¿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 más información de configuración de IPsec?

Consulte Configuración de una directiva de IPsec o IKE para las conexiones de sitio a sitio o de red virtual a red virtual.

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.

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

La puerta de enlace iniciará sesiones de emparejamiento BGP con las direcciones IP del par BGP local 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, NAT solo se admite en conexiones entre locales de IPsec.

¿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.

¿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.

¿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 APIPA (169.254.x.x) como IP del par o del altavoz BGP, use la dirección APIPA directamente en el campo Dirección IP del par BGP de la puerta de enlace de red local. 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 par BGP de la puerta de enlace de red local.

¿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 a través 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. Para las conexiones sin ninguna regla EgressSNAT,

¿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.

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 los siguientes factores:

• 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 está intentando 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.

P+F de Virtual Network

Puede ver más información de redes virtuales adicionales el documento de preguntas más frecuentes (P+F) acerca de Virtual Network.

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.