VPN Gateway

Contents
Documentación de VPN Gateway

Información general
¿Qué es VPN Gateway?
Tutoriales
Creación y administración de una instancia de VPN Gateway
Configuración de una conexión de sitio a sitio
Ejemplos
Azure PowerShell
Muestras de scripts
Creación de una puerta de enlace de VPN
Puerta de enlace de VPN + RADIUS de P2S
Puerta de enlace de VPN + Autenticación mediante certificados de P2S
Puerta de enlace de VPN + sitio a sitio
De red virtual a red virtual
Descargue la plantilla de dispositivo VPN
Conceptos
Trabajo remoto
Compatibilidad con el trabajo remoto
Uso de la VPN de Azure
Configuraciones de NVA y trabajo remoto
Acerca del diseño de VPN Gateway
Acerca de la configuración de VPN Gateway
Acerca de los dispositivos VPN
Acerca de los requisitos de cifrado
Acerca de BGP y VPN Gateway
Acerca de las conexiones de alta disponibilidad
Acerca de las conexiones de punto a sitio
Información sobre el enrutamiento de VPN de punto a sitio
Acerca de las puertas de enlace con redundancia de zona para Availability Zones
Seguridad
Línea de base de seguridad
Interoperabilidad de conectividad de back-end
Preparación y configuración de la prueba
Configuración de la prueba
Análisis del plano de control
Análisis del plano de datos
Guías paso a paso
Creación y administración de una instancia de VPN Gateway
Creación de una puerta de enlace VPN basada en ruta
Azure Portal
Azure PowerShell
Azure CLI
Comprobación de una conexión de VPN Gateway
Restablecimiento de una puerta de enlace o conexión de VPN
Eliminación de una instancia de VPN Gateway
Azure Portal
Azure PowerShell
Administración de SKU de puerta de enlace heredadas
Conexiones de sitio a sitio
Configuración de conexiones S2S
Azure Portal
Azure PowerShell
Azure CLI
Configuración de varias conexiones de sitio a sitio
Conexión a varios dispositivos VPN basados en directivas
De sitio a sitio con conexiones de ExpressRoute
Conexiones coexistentes
VPN a través de emparejamiento privado
Conexiones de red virtual a red virtual
Configuración de conexiones de red virtual a red virtual
Azure Portal
Azure PowerShell
Azure CLI
Configuración de una conexión de red virtual a red virtual entre distintos modelos
de implementación
Azure Portal
Azure PowerShell
Conexiones de punto a sitio
Autenticación de certificado de Azure
Configuración de una VPN de punto a sitio
Azure Portal
Azure PowerShell
Configuración de certificados y clientes P2S
Generación de certificados autofirmados
Azure PowerShell
Makecert
Linux
Instalación de certificados de cliente
Creación e instalación de los archivos de configuración de cliente de VPN
Autenticación RADIUS
Configuración de una VPN de punto a sitio
Creación e instalación de los archivos de configuración de cliente de VPN
Integración de la autenticación P2S VPN RADIUS con el servidor NPS
Autenticación de Azure AD
Configuración de un inquilino
Configuración de un inquilino con varias aplicaciones cliente
Configuración de Multi-Factor Authentication (MFA)
Configuración de un cliente VPN
Uso de con archivos de perfil de cliente VPN
Intune: implementación de un perfil de cliente VPN
Varios tipos de autenticación
Azure Portal
OpenVPN
Configuración del tipo de túnel de OpenVPN
Configuración de clientes de OpenVPN
Traslado al protocolo OpenVPN o IKEv2 desde SSTP
Administración de sesiones P2S
Configuración de un túnel de dispositivo VPN para los Grupos de disponibilidad
AlwaysOn
Configuración de un túnel de usuario de VPN para Grupos de disponibilidad
AlwaysOn
Anuncio de rutas personalizadas para clientes de P2S
Creación de directivas de IPsec personalizadas para P2S
Enrutamiento, BGP y emparejamiento de VNET
Configuración de BGP para una instancia de VPN Gateway
Azure Portal
Azure PowerShell
Azure CLI
Diagnóstico de BGP
Configuración de la tunelización forzada
Azure PowerShell
Azure PowerShell (clásico)
Configuración del tránsito de puerta de enlace para el emparejamiento de VNET
Modificación de una puerta de enlace de red local
Azure Portal
Azure PowerShell
Azure CLI
Configuración de dispositivos VPN
Introducción y configuración de Azure
Descarga de los scripts de configuración de dispositivos VPN
Sample: Dispositivo Cisco ASA (IKEv2/sin BGP)
Supervisión y alertas
Visualización de métricas VPN Gateway
Configuración de alertas basadas en métricas
Configuración de alertas basadas en registros de recursos
Configuración de captura de paquetes
Puertas de enlace con redundancia de zona
Creación de una puerta de enlace con redundancia de zona
Configuración de directivas de IPsec/IKE en las conexiones
Azure Portal
PowerShell
Configuración de conexiones activas-activas
PowerShell
Solución de problemas
Configuración de dispositivos de firewall o VPN sugeridos por la comunidad
Configuración y validación de las conexiones de red virtual o VPN
Validación del rendimiento de la VPN en una red virtual
Problemas de conexión de punto a sitio
Problemas de conexión de punto a sitio: cliente VPN de macOS X
Punto a sitio: autenticación de Azure AD
Problemas de conexión de sitio a sitio
La conexión de sitio a sitio se desconecta de forma intermitente
Artículos sobre el modelo de implementación clásica
Configuración de una conexión de sitio a sitio
Configuración de una conexión de punto a sitio
Configurar una conexión de red virtual a red virtual
Configuración de varias conexiones de sitio a sitio
Configuración de una instancia de VPN Gateway
Migración del modelo clásico al de Resource Manager
Referencia
Azure PowerShell
Azure PowerShell (clásico)
REST
REST (clásico)
Azure CLI
Recursos
Preguntas más frecuentes sobre VPN Gateway
Azure Roadmap
Blog
Página de preguntas y respuestas de Microsoft
Límites del servicio y la suscripción
Precios
Calculadora de precios
Contrato de nivel de servicio
Vídeos
¿Qué es VPN Gateway?
30/03/2021 • 19 minutes to read • Edit Online
VPN Gateway es un tipo específico de puerta de enlace de red virtual que se usa para enviar tráfico cifrado entre
una red virtual de Azure y una ubicación local a través de la red pública de Internet. También puede usar una
instancia de VPN Gateway para enviar tráfico cifrado entre las redes virtuales de Azure a través de la red de
Microsoft. Cada red virtual solo puede tener una instancia de VPN Gateway. Sin embargo, puede crear varias
conexiones a la misma instancia. Al crear varias conexiones a la misma instancia de VPN Gateway, todos los
túneles VPN comparten el ancho de banda disponible de la puerta de enlace.
¿Qué es una puerta de enlace de red virtual?

Una puerta de enlace de red virtual se compone de dos o más máquinas virtuales que se implementan en una
subred específica llamada subred de la puerta de enlace. Las máquinas virtuales de puerta de enlace de red
virtual contienen tablas de enrutamiento y ejecutan servicios específicos de puerta de enlace. Estas máquinas
virtuales se crean al generar la puerta de enlace de red virtual. No se pueden configurar directamente las
máquinas virtuales que forman parte de la puerta de enlace de red virtual.
Al configurar una puerta de enlace de red virtual, se configura un valor que especifica el tipo de puerta de
enlace. El tipo de puerta de enlace especifica cómo se utilizará la puerta de enlace de red virtual y las acciones
que realiza la puerta de enlace. El tipo de puerta de enlace "Vpn" especifica que el tipo de puerta de enlace de
red virtual creado es una "puerta de enlace de VPN". Esto lo distingue de una puerta de enlace de ExpressRoute,
que usa un tipo de puerta de enlace diferente. Una red virtual puede tener dos puertas de enlace de red virtual,
una puerta de enlace de VPN y una puerta de enlace de ExpressRoute. Para más información, consulte Tipos de
puerta de enlace.
La creación de una puerta de enlace de red virtual puede tardar en completarse hasta 45 minutos. Al crear una
puerta de enlace de red virtual, las máquinas virtuales de puerta de enlace se implementan en la subred de
puerta de enlace y se configuran con las opciones que especifique. Después de crear una instancia de VPN
Gateway, puede crear una conexión de túnel de VPN de IPsec o IKE entre esa instancia y otra instancia de VPN
Gateway (de red virtual a red virtual), o crear una conexión de túnel de VPN de IPsec o IKE con
implementaciones locales entre la instancia de VPN Gateway y un dispositivo VPN local (de sitio a sitio).
También puede crear una conexión VPN de punto a sitio (VPN a través de OpenVPN, IKEv2 o SSTP) que le
permite conectarse a la red virtual desde una ubicación remota como, por ejemplo, una sala de conferencias o
desde su casa.
Configuración de una instancia de VPN Gateway

Una conexión de puerta de enlace de VPN se basa en varios recursos con una configuración específica. La
mayoría de los recursos puede configurarse por separado, aunque en algunos casos es necesario seguir un
orden determinado.
Diseño
Es importante saber que hay distintas configuraciones disponibles para las conexiones de VPN Gateway. Es
preciso determinar qué configuración es la que mejor se adapta a sus necesidades. Por ejemplo, las conexiones
de punto a sitio, de sitio a sitio y de ExpressRoute o de sitio a sitio coexistentes tienen instrucciones y requisitos
de configuración diferentes. Para obtener información sobre el diseño y para ver los diagramas de topología de
conexión, consulte Diseño.
Tabla de planeación
La tabla siguiente puede ayudarle a decidir la mejor opción de conectividad para su solución.
DE P UN TO A SIT IO DE SIT IO A SIT IO EXP RESSRO UT E
Ser vicios de Azure Cloud Services y Virtual Cloud Services y Virtual Lista de servicios
compatibles Machines Machines
Anchos de banda típicos Se basa en la SKU de puerta Agregación típica de < 50 Mbps, 100 Mbps,
de enlace 1 Gbps 200 Mbps, 500 Mbps,
1 Gbps, 2 Gbps, 5 Gbps,
10 Gbps
Protocolos admitidos Protocolo de túnel de IPsec Conexión directa a través

sockets seguros (SSTP), de redes VLAN y
OpenVPN e IPsec tecnologías VPN de NSP
(MPLS, VPLS...)
Enrutamiento RouteBased (dinámico) Admitimos elementos BGP

basados en directivas
(enrutamiento estático) y
basados en enrutamiento
(VPN de enrutamiento
dinámico)
Resistencia de la activa-pasiva activa-pasiva o activa-activa activa-activa

conexión
Caso de uso típico Acceso seguro a redes Escenarios de laboratorio, Acceso a todos los servicios
virtuales de Azure para pruebas o desarrollo y de Azure (lista validada),
usuarios remotos cargas de trabajo de cargas de trabajo críticas y
producción a pequeña y empresariales, copias de
mediana escala para Cloud seguridad, macrodatos,
Services y Virtual Machines Azure como sitio de
recuperación ante desastres
Acuerdo de Nivel de Acuerdo de Nivel de Acuerdo de Nivel de Acuerdo de Nivel de

Ser vicio Servicio Servicio Servicio
Precios Precios Precios Precios
Documentación técnica Documentación de VPN Documentación de VPN Documentación de

Gateway Gateway ExpressRoute
P+F Preguntas más frecuentes Preguntas más frecuentes Preguntas frecuentes sobre
sobre VPN Gateway sobre VPN Gateway ExpressRoute
Configuración
La configuración que ha elegido para cada recurso es fundamental para crear una conexión correcta. Para más
información sobre los recursos individuales y la configuración de VPN Gateway, consulte Acerca de la
configuración de VPN Gateway. El artículo contiene información que le ayudará a entender los tipos de puerta
de enlace, de SKU de puerta de enlace, de VPN y de conexión, así como las subredes de puerta de enlace, las
puertas de enlace de red local y otras configuraciones de recursos que pueden interesarle.
Herramientas de implementación
Puede empezar a crear y configurar recursos mediante una herramienta de configuración, como el portal de
Azure. Más adelante puede decidir cambiar a otra herramienta, como PowerShell, para configurar recursos
adicionales o para modificar los existentes cuando sea aplicable. Actualmente, no se pueden configurar todos los
recursos ni establecer todas las configuraciones de recurso en Azure Portal. Las instrucciones de los artículos
para cada topología de configuración indican cuándo se necesita una herramienta de configuración específica.
SKU de puerta de enlace

Al crear una puerta de enlace de red virtual, hay que especificar la SKU de la puerta de enlace que desea usar.
Seleccione las SKU que cumplan sus requisitos en función de los tipos de cargas de trabajo, rendimientos,
características y Acuerdos de Nivel de Servicio.
Para más información acerca de las SKU de puerta de enlace, incluidas las características admitidas, los pasos
de producción, desarrollo-prueba y configuración, consulte el artículo Configuración de VPN Gateway: SKU
de puerta de enlace.
Para más información sobre las SKU heredadas, consulte Trabajo con SKU heredadas.
SKU de puerta de enlace por túnel, conexión y rendimiento
P RUEB A S
GEN ERA C I C O M PA RAT
ÓN T ÚN EL ES C O N EXIO N IVA S DE C ON
DE S2S/ EN T RE C O N EXIO N ES P 2S REN DIM IEN REDUN DA N
VP N REDES ES P 2S IK EV2/ O P E TO C IA DE
GAT EWAY SK U VIRT UA L ES SST P N VP N A GREGA DO B GP ZONA
Generació Basic Máx. 10 Máx. 128 No 100 Mbps No No

n1 compatible compatible
Generació VpnGw1 Máx. 30* Máx. 128 Máx. 250 650 MBps Compatible No
n1
Generació VpnGw2 Máx. 30* Máx. 128 Máx. 500 1 Gbps Compatible No
n1
Generació VpnGw3 Máx. 30* Máx. 128 Máx. 1000 1,25 Gbps Compatible No
n1
Generació VpnGw1A Máx. 30* Máx. 128 Máx. 250 650 MBps Compatible Sí
n1 Z
Generació VpnGw2A Máx. 30* Máx. 128 Máx. 500 1 Gbps Compatible Sí
n1 Z
Generació VpnGw3A Máx. 30* Máx. 128 Máx. 1000 1,25 Gbps Compatible Sí
n1 Z
n2
n2
n2
Generació VpnGw5 Máx. 30* Máx. 128 Máx. 10 Gbps Compatible No

n2 10000
P RUEB A S
n2 Z
n2 Z
n2 Z
Generació VpnGw5A Máx. 30* Máx. 128 Máx. 10 Gbps Compatible Sí

n2 Z 10000
(*) Use una red WAN virtual si necesita más de 30 túneles VPN S2S.
Se permite el cambio de tamaño de las SKU de VpnGw en la misma generación, excepto el cambio de
tamaño de la SKU básica. La SKU básica es una SKU heredada y tiene limitaciones de características. Para
pasar de una SKU básica a otra SKU de VpnGw, debe eliminar la instancia de VPN Gateway de la SKU
básica y crear una nueva puerta de enlace con la combinación de generación y tamaño de SKU deseada.
Estos límites de conexión son independientes. Por ejemplo, en una SKU de VpnGw1 puede tener 128
conexiones SSTP, además de 250 conexiones IKEv2.
Puede encontrar más información sobre los precios en la página de precios.
La información del SLA (contrato de nivel de servicio) puede encontrarse en la página SLA.
En un único túnel, se puede lograr un rendimiento máximo de 1 Gbps. Las pruebas comparativas de
rendimiento agregado de la tabla anterior se basan en las mediciones de varios túneles agregados a
través de una sola puerta de enlace. El banco de pruebas de rendimiento agregado para una puerta de
enlace de VPN es la combinación de S2S + P2S. Si tiene una gran cantidad de conexiones P2S,
puede afectar negativamente a una conexión S2S debido a las limitaciones del rendimiento.
Las pruebas comparativas de rendimiento agregado no es un rendimiento garantizado debido a las
condiciones del tráfico de Internet y a los comportamientos de las aplicaciones.
Para ayudar a nuestros clientes a comprender el rendimiento relativo de las SKU mediante distintos algoritmos,
usamos las herramientas iPerf y CTSTraffic disponibles públicamente para medir los rendimientos. En la tabla
siguiente se enumeran los resultados de las pruebas de rendimiento de las SKU de VpnGw de la generación 1.
Como puede ver, el mejor rendimiento se obtiene cuando usamos el algoritmo GCMAES256 para el cifrado y la
integridad IPsec. Obtuvimos un rendimiento medio al usar AES256 para el cifrado IPsec y SHA256 para la
integridad. Cuando usamos DES3 para el cifrado IPsec y SHA256 para la integridad, obtuvimos el rendimiento
más bajo.
PA Q UET ES P O R
A L GO RIT M O S REN DIM IEN TO SEGUN DO
GEN ERA C IÓ N SK U USA DO S O B SERVA DO O B SERVA DO S
Generación 1 VpnGw1 GCMAES256 650 MBps 58 000

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000
PA Q UET ES P O R
Generación 1 VpnGw2 GCMAES256 1 Gbps 90 000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000
Generación 1 VpnGw3 GCMAES256 1,25 Gbps 105 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
Generación 1 VpnGw1AZ GCMAES256 650 MBps 58 000

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000
Generación 1 VpnGw2AZ GCMAES256 1 Gbps 90 000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000
Generación 1 VpnGw3AZ GCMAES256 1,25 Gbps 105 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
Zonas de disponibilidad
Las puertas de enlace de VPN se pueden implementar en Azure Availability Zones. Esto aporta una mayor
disponibilidad, escalabilidad y resistencia a las puertas de enlace de red virtual. Implementar puertas de enlace
en Azure Availability Zones separa de forma física y lógica las puertas de enlace dentro de una región, y protege
la conectividad de red local en Azure de errores de nivel de zona. Consulte Acerca de las puertas de enlace de
red virtual con redundancia de zona en Azure Availability Zones.
Precios
Se paga por dos cosas: los costos de proceso por horas de la puerta de enlace de red virtual y la transferencia
de datos de salida de esta. Puede encontrar más información sobre los precios en la página de precios. Para los
precios de SKU de puerta de enlace heredada, consulte la página de precios de ExpressRoute y vaya a la sección
Puer tas de enlace de red vir tual .
Costos del proceso de puer ta de enlace de red vir tual
Cada puerta de enlace de red virtual tiene un costo de proceso por horas. El precio se basa en la SKU de la
puerta de enlace que especifique al crear una puerta de enlace de red virtual. El costo es para la puerta de
enlace en sí y se agrega a la transferencia de datos que pasa a través de la puerta de enlace. El costo de una
configuración activa-activa es igual que el de activa-pasiva.
Costos de la transferencia de datos
Los costos de transferencia de datos se calculan en función del tráfico de salida de la puerta de enlace de red
virtual de origen.
Si va a enviar tráfico al dispositivo VPN local, se le cobrará por la tasa de transferencia de datos de salida de
Internet.
Si va a enviar tráfico entre redes virtuales que se encuentren en diferentes regiones, el precio dependerá de
la región.
Si va a enviar tráfico solo entre redes virtuales que están en la misma región, no habrá ningún costo por
datos. El tráfico entre redes virtuales de la misma región es gratuito.
Para más información acerca de las SKU de puerta de enlace para VPN Gateway, consulte SKU de puerta de
enlace.
P+F
Para conocer las preguntas más frecuentes acerca de VPN Gateway, consulte Preguntas más frecuentes sobre
VPN Gateway.
Novedades
Suscríbase a la fuente RSS y vea las actualizaciones más recientes de las características de VPN Gateway en la
página Actualizaciones de Azure.
Pasos siguientes
Consulte las Preguntas más frecuentes sobre VPN Gateway para más información.
Consulte Límites del servicio y la suscripción.
Obtenga información sobre las demás funcionalidades de red clave de Azure.
Tutorial: Creación y administración de una puerta
de enlace de VPN mediante Azure Portal
Las puertas de enlace de VPN de Azure proporcionan conectividad entre locales entre el entorno local del cliente
y Azure. En este tutorial se tratan los elementos básicos de implementación de Azure VPN Gateway, como crear
y administrar una puerta de enlace de VPN. También puede crear una puerta de enlace con Azure PowerShell o
la CLI de Azure.
En este tutorial, aprenderá a:
Creación de una red virtual
Visualización de la dirección IP pública de la puerta de enlace
Cambio de tamaño de una puerta de enlace de VPN (cambio de tamaño de la SKU)
Restablecimiento de una instancia de VPN Gateway
En el siguiente diagrama se muestran la red virtual y la puerta de enlace de VPN creadas como parte de este
tutorial.
Requisitos previos
Una cuenta de Azure con una suscripción activa. Si no tiene ninguna, cree una gratis.

Utilice estos valores para crear una red virtual:
Grupo de recursos: TestRG1
Nombre: VNet1
Región: (EE. UU.) Este de EE. UU.
Espacio de direcciones IPv4: 10.1.0.0/16
Nombre de subred: FrontEnd
Espacio de direcciones de subred: 10.1.0.0/24
1. Inicie sesión en Azure Portal.
2. En Buscar recursos, ser vicios y documentos (G +/) , escriba red virtual.
3. Seleccione Red vir tual en los resultados de Marketplace .
4. En la página Red vir tual , seleccione Crear .
5. Una vez que haya seleccionado Crear , se abrirá la página Crear red vir tual .
6. En la pestaña Aspectos básicos , configure las opciones de configuración de la red virtual Detalles del
proyecto y Detalles de la instancia .
Al rellenar los campos, se mostrará una marca de verificación verde cuando los caracteres escritos en el
campo sean válidos. Algunos valores se rellenan automáticamente, que puede sustituir por sus propios
valores:
Suscripción : compruebe que la suscripción que aparece en la lista es la correcta. Puede cambiar las
suscripciones mediante la lista desplegable.
Grupo de recursos : seleccione uno existente o haga clic en Crear para crear un grupo de recursos
nuevo. Para más información sobre los grupos de recursos, consulte Información general de Azure
Resource Manager.
Name : escriba el nombre de la red virtual.
Región : seleccione la ubicación de la red virtual. La ubicación determina dónde van a residir los
recursos que se implementen en esta red virtual.
7. Configure los valores en la pestaña Direcciones IP . Los valores que se muestran en los ejemplos
siguientes son para fines de demostración. Ajuste estos valores según las opciones de configuración que
necesite.
Espacio de direcciones IPv4 : de manera predeterminada, se crea automáticamente un espacio de

direcciones. Puede hacer clic en el espacio de direcciones para modificarlo a fin de que refleje sus
valores. También puede agregar espacios de direcciones adicionales.
Subred : si usa el espacio de direcciones predeterminado, se crea automáticamente una subred
predeterminada. Si cambia el espacio de direcciones, debe agregar una subred. Seleccione + Agregar
una subred para abrir la ventana Agregar subred . Configure las siguientes opciones y, a
continuación, seleccione Agregar para agregar los valores:
Nombre de subred : en este ejemplo, asignamos a la subred el nombre "FrontEnd".
Rango de direcciones de subred : intervalo de direcciones para esta subred.
8. En la pestaña Seguridad , en este momento, deje los valores predeterminados:
Protección contra DDos : Básico
Firewall : Disabled
9. Seleccione Revisar y crear para validar la configuración de la red virtual.
10. Una vez validada la configuración, seleccione Crear .

En este paso, se crea la puerta de enlace para la red virtual. La creación de una puerta de enlace suele tardar 45
minutos o más, según la SKU de la puerta de enlace seleccionada.
Cree una puerta de enlace de red virtual con los siguientes valores:
Nombre: VNet1GW
Región: Este de EE. UU.
Tipo de puer ta de enlace: VPN
Tipo de VPN: basada en rutas
SKU: VpnGw1
Generación: Generación 1
Red vir tual: VNet1
Inter valo de direcciones de subred de puer ta de enlace: 10.1.255.0/27
Dirección IP pública : Crear nuevo
Dirección IP pública: VNet1GWpip
Habilitar el modo activo-activo: Disabled
Configuración de BGP: Disabled
1. En Azure Portal, en Buscar recursos, ser vicios y documentos (G+/) escriba puer ta de enlace de
red vir tual . Busque la puer ta de enlace de red vir tual en los resultados de la búsqueda y
selecciónela.
2. En la página Puer ta de enlace de red vir tual , seleccione + Agregar . Se abre la página Crear puer ta
de enlace de red vir tual .
3. En la pestaña Aspectos básicos , rellene los valores de la puerta de enlace de red virtual.
Suscripción : seleccione la suscripción que desea usar en la lista desplegable.
Grupo de recursos : esta configuración se rellena automáticamente cuando selecciona la red virtual
en esta página.
Detalles de instancia
Name : Asigne un nombre a la puerta de enlace. Asignar nombre a la puerta de enlace no es lo mismo
que asignar nombre a una subred de puerta de enlace. Este es el nombre del objeto de puerta de
enlace que va a crear.
Región : Seleccione la región en la que quiere crear este recurso. La región de la puerta de enlace
debe ser la misma que la red virtual.
Tipo de puer ta de enlace : Seleccione VPN . Las puertas de enlace VPN usan el tipo de puerta de
enlace de red virtual VPN .
Tipo de VPN : seleccione el tipo de VPN que se especifica para la configuración. La mayoría de las
configuraciones requieren un tipo de VPN basada en enrutamiento.
SKU : seleccione la SKU de puerta de enlace en la lista desplegable. Las SKU que aparecen en la lista
desplegable dependen del tipo de VPN que seleccione. Para más información acerca de las SKU de
puerta de enlace, consulte SKU de puerta de enlace.
Generación : para obtener información sobre la generación de VPN Gateway, consulte SKU de puerta
de enlace.
Red vir tual : En el menú desplegable, seleccione la red virtual a la que quiera agregar esta puerta de
enlace.
Inter valo de direcciones de subred de puer ta de enlace : Este campo solo aparece si la red
virtual no tiene una subred de puerta de enlace. Si es posible, intente que el intervalo sea /27, o
incluso mayor (/26, /25, etc.). No se recomienda crear un intervalo inferior a /28. Si ya tiene una
subred de puerta de enlace y desea ver los detalles de GatewaySubnet, vaya a la red virtual. Haga clic
en Subnets (Subredes) para ver el intervalo. Si desea cambiar el intervalo, puede eliminar y volver a
crear GatewaySubnet.
Dirección IP pública
esta configuración especifica el objeto de dirección IP pública que se asocia a la puerta de enlace de VPN.
La dirección IP pública se asigna dinámicamente a este objeto cuando se crea la puerta de enlace de VPN.
La única vez que la dirección IP pública cambia es cuando la puerta de enlace se elimina y se vuelve a
crear. No cambia cuando se cambia el tamaño, se restablece o se realizan actualizaciones u otras
operaciones de mantenimiento interno de una puerta de enlace VPN.
Dirección IP pública : Mantenga la opción Crear nueva seleccionada.
Nombre de dirección IP pública : En el cuadro de texto, escriba un nombre para la dirección IP
pública.
Asignación : VPN Gateway solo admite Dinámica.
Habilitar el modo activo/activo : Seleccione Habilitar el modo activo/activo solo si va a crear
una configuración de puerta de enlace activa/activa. En caso contrario, deje este valor Deshabilitado .
Mantenga Configurar BGP en Deshabilitado , a menos que su configuración requiera
específicamente este valor. Si necesita esta configuración, el valor predeterminado del ASN es 65515,
aunque esto se puede cambiar.
4. Seleccione Revisar y crear para ejecutar la validación.
5. Una vez superada la validación, seleccione Crear para implementar VPN Gateway.
Una puerta de enlace puede tardar hasta 45 minutos en crearse e implementarse completamente. Puede ver el
estado de implementación en la página Información general de la puerta de enlace. Una vez creada la puerta de
enlace, puede ver la dirección IP que se le ha asignado consultando la red virtual en el portal. La puerta de
enlace aparece como un dispositivo conectado.
IMPORTANT
Cuando trabaje con subredes de la puerta de enlace, evite asociar un grupo de seguridad de red (NSG) a la subred de la
puerta de enlace. La asociación de un grupo de seguridad de red a esta subred puede causar que la puerta de enlace de
la red virtual (VPN, puerta de enlace de Express Route) deje de funcionar como cabría esperar. Para más información
acerca de los grupos de seguridad de red, consulte ¿Qué es un grupo de seguridad de red?
Visualización de la dirección IP pública

Puede ver la dirección IP pública de la puerta de enlace en la página Información general de la puerta de
enlace.
Para ver más información acerca del objeto de dirección IP pública, haga clic en el vínculo del nombre/dirección
IP que hay junto a Dirección IP pública .
Cambio del tamaño de la SKU de una puerta de enlace

Hay reglas específicas relativas al cambio de tamaño de una SKU de puerta de enlace, en lugar de su cambio. En
esta sección, se cambiará el tamaño de una SKU. Para más información, consulte Configuración de una puerta
de enlace: cambio de tamaño y cambio de SKU.
1. Vaya a la página de configuración de la puerta de enlace de red virtual.
2. Seleccione la flecha de la lista desplegable.
3. Seleccione el SKU en la lista desplegable.
Restablecimiento de una puerta de enlace

1. En el portal, vaya a la puerta de enlace de red virtual que desee restablecer.
2. En la página de la puerta de enlace de red virtual, seleccione Restablecer .
3. En la página Restablecer , haga clic en Restablecer . Una vez que se emite el comando, se reiniciará
inmediatamente la instancia activa actual de Azure VPN Gateway. El restablecimiento de la puerta de
enlace provocará un vacío en la conectividad VPN y puede limitar el futuro análisis de causa raíz del
problema.
Limpieza de recursos
Si no va a seguir usando esta aplicación o si va al siguiente tutorial, siga estos pasos para eliminar estos
recursos:
1. Escriba el nombre del grupo de recursos en el cuadro Buscar de la parte superior del portal y
selecciónelo en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. En TYPE THE RESOURCE GROUP NAME (ESCRIBIR EL NOMBRE DEL GRUPO DE RECURSOS), escriba
el grupo de recursos y seleccione Delete (Eliminar).
Pasos siguientes
Una vez que tenga una puerta de enlace de VPN, puede configurar las conexiones. Los siguientes artículos le
ayudarán a crear algunas de las configuraciones más comunes:
Conexiones VPN de sitio a sitio
Conexión VPN de punto a sitio
Tutorial: Creación de una conexión de sitio a sitio
mediante Azure Portal
y Azure. En este tutorial se muestra cómo usar Azure Portal para crear una conexión de puerta de enlace VPN de
sitio a sitio desde la red local a la red virtual. También puede crear esta configuración mediante Azure
PowerShell o la CLI de Azure.

Creación de una puerta de enlace de red local
Creación de una conexión VPN
Comprobación de la conexión
Conexión a una máquina virtual
Prerrequisitos
Asegúrese de tener un dispositivo VPN compatible y alguien que pueda configurarlo. Para más información
acerca de los dispositivos VPN compatibles y su configuración, consulte Acerca de los dispositivos VPN.
Compruebe que tiene una dirección IPv4 pública externa para el dispositivo VPN.
Si no está familiarizado con los intervalos de direcciones IP ubicados en la red local, necesita trabajar con
alguien que pueda proporcionarle estos detalles. Al crear esta configuración, debe especificar los prefijos del
intervalo de direcciones IP al que Azure enrutará la ubicación local. Ninguna de las subredes de la red local
puede superponerse con las subredes de la red virtual a la que desea conectarse.

Cree una red virtual (VNet) con los siguientes valores:
Nombre: VNet1
NOTE
Cuando use una red virtual como parte de una arquitectura entre entornos, asegúrese de coordinarse con el
administrador de la red local para delimitar un intervalo de direcciones IP que pueda usar específicamente para esta red
virtual. Si existe un intervalo de direcciones duplicado en ambos lados de la conexión VPN, el tráfico se enrutará de forma
inesperada. Además, si quiere conectar esta red virtual a otra, el espacio de direcciones no puede superponerse con la
otra red virtual. Planee la configuración de red en consecuencia.

valores:
Resource Manager.
necesite.

Firewall : Disabled

Acerca de la subred de puerta de enlace
La puerta de enlace de red virtual usa una subred concreta llamada la subred de la puerta de enlace. Esta subred
forma parte del intervalo de direcciones IP de red virtual que se especifican al configurar una red virtual.
Contiene las direcciones IP que usan los recursos y servicios de puerta de enlace de la red virtual.
Al crear la subred de puerta de enlace, especifique el número de direcciones IP que contiene la subred. El
número de direcciones IP que se necesitan depende de la configuración de puerta de enlace de VPN que se
desea crear. Algunas configuraciones requieren más direcciones IP que otras. Es aconsejable crear una subred de
puerta de enlace que use /27 o /28.
Si ve un error en el que se indica que el espacio de direcciones se solapa con una subred o que la subred no se
encuentra dentro del espacio de direcciones de la red virtual, compruebe el intervalo de direcciones de la red
virtual. Es posible que no tenga suficientes direcciones IP disponibles en el intervalo de direcciones que creó
para la red virtual. Por ejemplo, si la subred predeterminada engloba todo el intervalo de direcciones, no
quedan direcciones IP para crear más subredes. Puede ajustar las subredes en el espacio de direcciones
existente para liberar direcciones IP o especificar un intervalo de direcciones adicionales y crear en él la subred
de la puerta de enlace.
Creación de la puerta de enlace
Cree una puerta de enlace de VPN con los siguientes valores:
Nombre: VNet1GW
SKU: VpnGw1
Red vir tual: VNet1
selecciónela.
en esta página.
de enlace.
enlace.
pública.
IMPORTANT

enlace.

La puerta de enlace de red local es un objeto específico que representa la ubicación local (el sitio) para fines de
enrutamiento. Asigne al sitio un nombre al que Azure pueda hacer referencia y, luego, especifique la dirección IP
del dispositivo VPN local con la que creará una conexión. Especifique también los prefijos de dirección IP que se
enrutarán a través de la puerta de enlace VPN al dispositivo VPN. Los prefijos de dirección que especifique son
los prefijos que se encuentran en la red local. Si la red local cambia o necesita cambiar la dirección IP pública del
dispositivo VPN, puede actualizar fácilmente los valores más adelante.
Cree una puerta de enlace de red local con los siguientes valores:
Nombre: Site1
Grupos de recursos: TestRG1
Ubicación: Este de EE. UU.
red local . Busque la puer ta de enlace de red local en Marketplace , en los resultados de la búsqueda
y selecciónela. Se abre la página Crear puer ta de enlace de red local .
2. En la página Crear puer ta de enlace de red local , especifique los valores de la puerta de enlace de
red local.
Nombre: especifique el nombre del objeto de puerta de enlace de red local.

Punto de conexión: Seleccione el tipo de punto de conexión para el dispositivo VPN local: dirección
IP o FQDN (nombre de dominio completo) .
Dirección IP : si tiene asignada una dirección IP pública estática de su proveedor de servicios
de Internet para el dispositivo VPN, seleccione la opción Dirección IP y rellene la dirección IP
como se indica en el ejemplo. Esta es la dirección IP pública del dispositivo VPN al que desea
que Azure VPN Gateway se conecte. Si no tiene la dirección IP en este momento, puede usar los
valores que se muestran en el ejemplo, pero deberá volver y reemplazar la dirección IP del
marcador de posición por la dirección IP pública de su dispositivo VPN. Si no lo hace, Azure no
podrá conectarse.
Nombre de dominio completo : si tiene una dirección IP pública dinámica que podría
cambiar después de un cierto período de tiempo, que normalmente determina el proveedor de
servicios de Internet, puede usar un nombre DNS constante con un servicio DNS dinámico que
apunte a la dirección IP pública actual del dispositivo VPN. Azure VPN Gateway resolverá el
nombre de dominio completo para determinar la dirección IP pública a la que se va a conectar.
Espacio de direcciones hace referencia a los intervalos de direcciones de la red que representa esta
red local. Puede agregar varios intervalos de espacios de direcciones. Asegúrese de que los intervalos
que especifique aquí no se superpongan con los de otras redes a las que quiera conectarse. Azure
enrutará el intervalo de direcciones que especifique a la dirección IP del dispositivo VPN local. Use sus
propios valores aquí, y no los mostrados en el ejemplo, si quiere conectarse a su sitio local.
Configurar BGP: usar solo al configurar BGP. En caso contrario, no seleccione esta opción.
Subscription (Suscripción): compruebe que se muestra la suscripción correcta.
Grupos de recursos: seleccione el grupo de recursos que quiere usar. Puede crear un grupo de
recursos nuevo o seleccionar uno ya creado.
Ubicación: La ubicación es la misma que Región en otros valores. seleccione la ubicación en la que
se creará este objeto. Puede seleccionar la misma ubicación en la que reside la red, pero no es
obligatorio.
NOTE
Azure VPN Gateway solo admite una dirección IPv4 para cada nombre de dominio completo. Si el nombre de
dominio se resuelve en varias direcciones IP, Azure VPN Gateway usará la primera dirección IP que devuelvan
los servidores DNS. Para eliminar la incertidumbre, se recomienda que el nombre de dominio completo siempre
se resuelva en una sola dirección IPv4. No se admite IPv6.
Azure VPN Gateway mantiene una caché DNS que se actualiza cada 5 minutos. La puerta de enlace intenta
resolver los nombres de dominio completos solo para los túneles desconectados. Al restablecer la puerta de
enlace también se desencadenará la resolución del nombre de dominio completo.
3. Cuando haya terminado de especificar los valores, seleccione el botón Crear en la parte inferior de la
página para crear la puerta de enlace de red local.
Configuración del dispositivo VPN

Las conexiones de sitio a sitio a una red local requieren un dispositivo VPN. En este paso, se configura el
dispositivo VPN. Para configurar el dispositivo VPN, necesita los valores siguientes:
Una clave compartida. Se trata de la misma clave compartida que se especifica al crear la conexión VPN de
sitio a sitio. En estos ejemplos se utiliza una clave compartida básica. Se recomienda que genere y utilice una
clave más compleja.
La dirección IP pública de la puerta de enlace de red virtual. Puede ver la dirección IP pública mediante Azure
Portal, PowerShell o la CLI. Para buscar la dirección IP pública de la puerta de enlace de VPN mediante Azure
Portal, vaya a Puer tas de enlace de red vir tual y seleccione el nombre de su puerta de enlace.
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 una introducción a la configuración de dispositivos VPN, consulte Información general sobre
configuraciones de dispositivos VPN de terceros.
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.

Creación de la conexión VPN de sitio a sitio entre la puerta de enlace de la red virtual y el dispositivo VPN local.
Cree una conexión con los valores siguientes:
Nombre de la puer ta de enlace de red local: Site1
Nombre de la conexión: VNet1toSite1
Clave compar tida: en este ejemplo, usamos abc123. Sin embargo, puede usar cualquiera compatible con el
hardware VPN. Lo importante es que los valores coincidan en ambos lados de la conexión.
1. Abra la página de la puerta de enlace de red virtual. Para desplazarse a la puerta de enlace, vaya a
Nombre de la red vir tual -> Información general -> Dispositivos conectados -> Nombre de
la puer ta de enlace , aunque hay otras formas de hacerlo.
2. En la página de la puerta de enlace, seleccione Conexiones . En la parte superior de la página
Conexiones, seleccione +Agregar para abrir la página Agregar conexión .
3. En la página Agregar conexión , configure los valores de la conexión.
Nombre: asigne un nombre a la conexión.
Tipo de conexión : Seleccione Sitio a sitio (IPSec) .
Puer ta de enlace de red vir tual: el valor es fijo porque se conecta desde esta puerta de enlace.
Puer ta de enlace de red local: Seleccione Elegir una puer ta de enlace de red local y
seleccione la puerta de enlace de red local que quiere utilizar.
Clave compar tida: este valor debe ser el mismo que el que usa para el dispositivo VPN local. En el
ejemplo se usa "abc123", pero puede (y debería) utilizar algo más complejo. Lo importante es que el
valor que especifique aquí debe ser el mismo que el que se especificó al configurar el dispositivo VPN.
Deje la casilla Usar la dirección IP privada de Azure desactivada.
Deje la casilla Habilitar BGP desactivada.
Seleccione IKEv2 .
Los restantes valores de Suscripción , Grupo de recursos y Ubicación son fijos.
4. Haga clic en Aceptar para crear la conexión. El mensaje Creando la conexión aparecerá de forma
intermitente en la pantalla.
5. La conexión se puede ver en la página Conexiones de la puerta de enlace de red virtual. El valor de
Estado pasará de Desconocido a Conectando y luego a Correcto.
Comprobación de la conexión VPN

En Azure Portal, puede ver el estado de la conexión de una instancia de VPN Gateway de Resource Manager
navegando a la conexión. Los pasos siguientes muestran una manera de navegar a su conexión y realizar las
comprobaciones necesarias.
1. En el menú de Azure Portal, seleccione Todos los recursos o busque y seleccione Todos los recursos
en cualquier página.
2. Seleccione la puerta de enlace de red virtual.
3. En la hoja de la puerta de enlace de la red virtual, haga clic en Conexiones . Puede ver el estado de cada
conexión.
4. Haga clic en el nombre de la conexión que desee comprobar para abrir Essentials . En Essentials, puede
ver más información acerca de la conexión. El valor de Estado será "Correcto" y "Conectado" cuando
haya realizado una conexión satisfactoria.

Puede conectarse a una máquina virtual que se ha implementado en la red virtual mediante la creación de una
conexión a Escritorio remoto a la máquina virtual. La mejor manera de comprobar inicialmente que puede
conectarse a la máquina virtual es hacerlo mediante su dirección IP privada, en lugar del nombre de equipo. Con
este método prueba si puede conectarse, no si la resolución de nombres está configurada correctamente.
1. Busque la dirección IP privada. Para buscar la dirección IP privada de una máquina virtual, examine sus
propiedades en Azure Portal o use PowerShell.
Azure Portal: busque la máquina virtual en Azure Portal. Vea las propiedades de la máquina
virtual. Se enumera la dirección IP privada.
PowerShell: utilice el ejemplo para ver una lista de las máquinas virtuales y las direcciones IP
privadas de los grupos de recursos. No es preciso modificar el ejemplo para usarlo.
$VMs = Get-AzVM
$Nics = Get-AzNetworkInterface | Where VirtualMachine -ne $null
foreach($Nic in $Nics)
{
$VM = $VMs | Where-Object -Property Id -eq $Nic.VirtualMachine.Id
$Prv = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAddress
$Alloc = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAllocationMethod
Write-Output "$($VM.Name): $Prv,$Alloc"
}
2. Compruebe que está conectado a su red virtual mediante la conexión VPN de punto a sitio.
3. Abra Conexión a Escritorio remoto , para lo que debe escribir "RDP" o "Conexión a Escritorio remoto"
en el cuadro de búsqueda de la barra de tareas y, después, seleccione Conexión a Escritorio remoto.
Conexión a Escritorio remoto también se puede abrir con el comando "mstsc" de PowerShell.
4. En Conexión a Escritorio remoto, escriba la dirección IP privada de la máquina virtual. Puede hacer clic en
"Mostrar opciones" para ajustar más parámetros adicionales y, después, conéctese.
Solución de problemas de una conexión
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.
Para más información acerca de las conexiones RDP, consulte Solución de problemas de conexiones del
Escritorio remoto a una máquina virtual de Azure.
Pasos opcionales
Incorporación de conexiones adicionales a la puerta de enlace
Puede agregar conexiones adicionales, siempre que ninguno de los espacios de direcciones se superpongan
entre las conexiones.
1. Para agregar otra conexión, vaya a la puerta de enlace de VPN y, luego, haga clic en Conexiones para abrir
la página Conexiones.
2. Seleccione + Agregar para agregar la conexión. Ajuste el tipo de conexión para reflejar una conexión entre
redes virtuales (si se conecta a otra puerta de enlace de red virtual), o de sitio a sitio.
3. Si se conecta de sitio a sitio y aún no ha creado una puerta de enlace de red local para el sitio al que desea
conectarse, puede crear una.
4. Especifique la clave compartida que quiera usar y, luego, seleccione Aceptar para crear la conexión.

Restablecer una puerta de enlace de VPN de Azure es útil si se pierde la conectividad VPN entre locales en uno o
varios túneles VPN de sitio a sitio. En esta situación, todos tus dispositivos VPN locales funcionan correctamente,
pero no pueden establecer túneles IPsec con las Puertas de enlace de VPN de Azure.
problema.
Consideraciones adicionales sobre la configuración
Las configuraciones S2S se pueden personalizar de varias maneras. Vea los siguientes artículos para más
información:
Para más información acerca de BGP, consulte Información general de BGP y Configuración de BGP.
Para información acerca de la tunelización forzada, consulte la Acerca de la tunelización forzada.
Para obtener información acerca de las conexiones activo/activo de alta disponibilidad, consulte Conectividad
de alta disponibilidad entre locales y de red virtual a red virtual.
Para información acerca de cómo limitar el tráfico de red a los recursos de una red virtual, vea Seguridad de
red.
Para información acerca de cómo enruta Azure el tráfico entre los recursos locales, de Internet y de Azure,
vea Enrutamiento del tráfico de redes virtuales.
recursos:
Pasos siguientes
Una vez configurada la conexión S2S, podrá agregar una conexión P2S a la misma puerta de enlace.
Ejemplos de Azure PowerShell para VPN Gateway
En la tabla siguiente se incluyen vínculos a scripts de Azure PowerShell:
SC RIP T DESC RIP C IÓ N
Creación de una puerta de enlace de VPN Permite crear una puerta de enlace de VPN basada en rutas.
Creación de una puerta de enlace de VPN y una Permite crear una puerta de enlace de VPN basada en rutas
configuración P2 (RADIUS) y una configuración P2S que usa la autenticación de nombre
de usuario y contraseña de RADIUS.
Creación de una puerta de enlace de VPN y una Permite crear una puerta de enlace de VPN basada en rutas
configuración P2S: autenticación de certificado y una configuración P2S que usa la autenticación de
certificados nativa de Azure.
Creación de una puerta de enlace de VPN y una conexión de Permite crear una puerta de enlace de VPN basada en rutas
sitio a sitio y una conexión S2S.
Creación de conexiones de red virtual a red virtual Cree conexiones de red virtual a red virtual.
Descarga de la plantilla de dispositivos VPN Descargue la plantilla de dispositivos VPN.

Creación de una instancia de VPN Gateway: script
de ejemplo de PowerShell
Este script de PowerShell crea una instancia de VPN Gateway basada en rutas.
NOTE
Este artículo se ha actualizado para usar el módulo Az de Azure PowerShell. El módulo Az de PowerShell es el módulo de
PowerShell que se recomienda para interactuar con Azure. Para empezar a trabajar con el módulo Az de PowerShell,
consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte
Migración de Azure PowerShell de AzureRM a Az.
# Declare variables
$RG = "TestRG1"
$Location = "East US"
$VNetName = "VNet1"
$FESubName = "FrontEnd"
$VNetPrefix1 = "10.1.0.0/16"
$FESubPrefix = "10.1.0.0/24"
$GWSubPrefix = "10.1.255.0/27"
$GWName = "VNet1GW"
$GWIPName = "VNet1GWIP"
# Create a resource group

New-AzResourceGroup -Name $RG -Location $Location
# Create a virtual network
$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName $RG `
-Location $Location `
-Name $VNetName `
-AddressPrefix $VNetPrefix1
# Create a subnet configuration
$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name $FESubName `
-AddressPrefix $FESubPrefix `
-VirtualNetwork $virtualNetwork
# Set the subnet configuration for the virtual network
$virtualNetwork | Set-AzVirtualNetwork
# Add a gateway subnet
$vnet = Get-AzVirtualNetwork -ResourceGroupName $RG -Name $VNetName
Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix $GWSubPrefix -VirtualNetwork $vnet
$vnet | Set-AzVirtualNetwork
# Request a public IP address
$gwpip= New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Location -AllocationMethod
Dynamic
# Create the gateway IP address configuration
$vnet = Get-AzVirtualNetwork -Name $VNetName -ResourceGroupName $RG
$subnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $subnet.Id -PublicIpAddressId
$gwpip.Id
# Create the VPN gateway
New-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG `
-Location $Location -IpConfigurations $gwipconfig -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1
Cuando ya no necesite los recursos que ha creado, use el comando Remove-AzResourceGroup para eliminar el
grupo de recursos. Se eliminarán el grupo de recursos y todos los recursos que contiene.
Remove-AzResourceGroup -Name TestRG1
Explicación del script

Este script usa los siguientes comandos para crear la implementación. Cada elemento de la tabla incluye
vínculos a la documentación específica del comando.
GET - H EL P N OTA S
Add-AzVirtualNetworkSubnetConfig Agrega una configuración de subred. Esta configuración se

utiliza con el proceso de creación de la red virtual.
Get-AzVirtualNetwork Obtiene los detalles de una red virtual.
New-AzResourceGroup Crea un grupo de recursos en el que se almacenan todos los

recursos.
New-AzVirtualNetworkSubnetConfig Crea una configuración de subred. Esta configuración se

New-AzVirtualNetwork Crea una red virtual.
New-AzPublicIpAddress Crea una dirección IP pública.
New-AzVirtualNetworkGateway Crea una puerta de enlace de VPN.
Remove-AzResourceGroup Quita un grupo de recursos y todos los recursos incluidos en

él.
Set-AzVirtualNetwork Establece la configuración de subred para la red virtual.
Pasos siguientes
Para obtener más información sobre el módulo de Azure PowerShell, consulte la documentación de Azure
PowerShell.
Creación de una instancia de VPN Gateway con
autenticación RADIUS de P2S: ejemplo de script de
PowerShell
Este script de ejemplo crea una instancia de VPN Gateway basada en rutas y agrega una configuración de punto
a sitio mediante la autenticación de nombre de usuario y contraseña de RADIUS.
NOTE
# Declare variables
$VNetName = "VNet1"
$VNetPrefix1 = "10.1.0.0/16"
$FESubPrefix = "10.1.0.0/24"
$GWSubPrefix = "10.1.255.0/27"
$VPNClientAddressPool = "172.16.201.0/24"
$RG = "TestRG1"
$GWName = "VNet1GW"
$RSAddress = "10.51.0.15"

-Name $VNetName `
-Name $FESubName `
$gwpip= New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Location `
-AllocationMethod Dynamic
$gwpip.Id
-VpnType RouteBased -GatewaySku VpnGw1 -VpnClientProtocol "IKEv2"
# Create a secure string for the RADIUS secret
$Secure_Secret=Read-Host -AsSecureString -Prompt "RadiusSecret"
# Add the VPN client address pool and the RADIUS server information
$Gateway = Get-AzVirtualNetworkGateway -ResourceGroupName $RG -Name $GWName
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway `
-VpnClientAddressPool $VPNClientAddressPool -VpnClientProtocol @( "SSTP", "IkeV2" ) `
-RadiusServerAddress $RSAddress -RadiusServerSecret $Secure_Secret


Get-AzVirtualNetworkGateway Obtiene detalles de una puerta de enlace de red virtual.
Get-AzVirtualNetworkSubnetConfig Obtiene detalles de configuración de la subred de red virtual.

recursos.

New-AzVirtualNetworkGatewayIpConfig Crea una configuración de IP de puerta de enlace.

él.
Set-AzVirtualNetworkGateway Establece la configuración de la puerta de enlace VPN.
Pasos siguientes
PowerShell.
Configuración de una VPN de punto a sitio:
autenticación de certificados: script de ejemplo de
PowerShell
Este script crea una instancia de VPN Gateway basada en rutas y agrega una configuración de punto a sitio
mediante la autenticación de certificados nativa de Azure.
NOTE
# Declare variables
$VNetName = "VNet1"
$RG = "TestRG1"
$VNetPrefix1 = "10.1.0.0/16"
$FESubPrefix = "10.1.0.0/24"
$GWSubPrefix = "10.1.255.0/27"
$GWName = "VNet1GW"

New-AzResourceGroup -Name $RG -Location EastUS
-Location EastUS `
-Name $VNetName `
-Name $FESubName `
$gwpip.Id
-VpnType RouteBased -GatewaySku VpnGw1 -VpnClientProtocol "IKEv2"
# Add the VPN client address pool
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway -VpnClientAddressPool $VPNClientAddressPool
# Create a self-signed root certificate
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `
-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
# Export the root certificate to "C:\cert\P2SRootCert.cer"
# Upload the root certificate public key information
$P2SRootCertName = "P2SRootCert.cer"
$filePathForCert = "C:\cert\P2SRootCert.cer"
$cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2($filePathForCert)
$CertBase64 = [system.convert]::ToBase64String($cert.RawData)
$p2srootcert = New-AzVpnClientRootCertificate -Name $P2SRootCertName -PublicCertData $CertBase64
Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName `
-VirtualNetworkGatewayname $GWName `
-ResourceGroupName $RG -PublicCertData $CertBase64


Add-AzVpnClientRootCertificate Carga la información de clave pública del certificado raíz en

la instancia de VPN Gateway.
Get-AzVirtualNetworkGateway Obtiene detalles de puerta de enlace de red virtual.

recursos.

New-SelfSignedCertificate Crea un certificado raíz autofirmado.

él.
Pasos siguientes
PowerShell.
Creación de una instancia de VPN Gateway y
adición de una conexión de sitio a sitio mediante
PowerShell
Este script crea una VPN Gateway basada en rutas y agrega la configuración de sitio a sitio. Para crear la
conexión, también se debe configurar el dispositivo VPN. Para obtener más información, consulte Acerca de los
dispositivos VPN y los parámetros de IPsec/IKE para conexiones de VPN Gateway de sitio a sitio.
# Declare variables
$VNetName = "VNet1"
$RG = "TestRG1"
$BESubName = "BackEnd"
$GWSubName = "GatewaySubnet"
$VNetPrefix1 = "10.1.0.0/16"
$FESubPrefix = "10.1.0.0/24"
$BESubPrefix = "10.1.1.0/24"
$GWSubPrefix = "10.1.255.0/27"
$GWName = "VNet1GW"
$GWIPconfName = "gwipconf"
$LNGName = "Site1"
-Name $VNetName `
-Name $FESubName `
Add-AzVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix -VirtualNetwork $vnet
$subnet = Get-AzVirtualNetworkSubnetConfig -Name $GWSubName -VirtualNetwork $vnet
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName -SubnetId $subnet.Id -
PublicIpAddressId $gwpip.Id
# Create the local network gateway
New-AzLocalNetworkGateway -Name $LNGName -ResourceGroupName $RG `
-Location $Location -GatewayIpAddress '23.99.221.164' -AddressPrefix @('10.101.0.0/24','10.101.1.0/24')
# Configure your on-premises VPN device
# Create the VPN connection
$gateway1 = Get-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG
$local = Get-AzLocalNetworkGateway -Name $LNGName -ResourceGroupName $RG
New-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -ResourceGroupName $RG `
-Location $Location -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -ConnectionProtocol IKEv2 -RoutingWeight 10 -SharedKey 'abc123'


Get-AzLocalNetworkGateway Obtiene detalles de puerta de enlace de red local.

recursos.

New-AzLocalNetworkGateway Crea una puerta de enlace de red local.
New-AzVirtualNetworkGatewayConnection Crea una conexión de sitio a sitio.

él.
Pasos siguientes
PowerShell.
Uso de PowerShell para configurar una conexión de
puerta de enlace de VPN de red virtual a red virtual
Este script conecta dos redes virtuales mediante el tipo de conexión de red virtual a red virtual.
NOTE
# Declare variables for VNET 1

$RG1 = "TestRG1"
$VNetName1 = "VNet1"
$FESubName1 = "FrontEnd"
$GWSubName1 = "GatewaySubnet"
$VNetPrefix11 = "10.1.0.0/16"
$FESubPrefix1 = "10.1.0.0/24"
$GWSubPrefix1 = "10.1.255.0/27"
$Location1 = "EastUS"
$GWName1 = "VNet1GW"
$GWIPName1 = "VNet1GWIP"
$GWIPconfName1 = "gwipconfig1"
$Connection12 = "VNet1toVNet2"
# Declare variables for VNET 2

$RG2 = "TestRG2"
$VNetName2 = "VNet2"
$VNetPrefix21 = "10.2.0.0/16"
$FESubPrefix2 = "10.2.0.0/24"
$GWSubPrefix2 = "10.2.255.0/27"
$Location2 = "EastUS"
$GWIPconfName2 = "gwipconfig2"
# Create first resource group

New-AzResourceGroup -Name $RG1 -Location $Location1
# Create a virtual network 1

$virtualNetwork1 = New-AzVirtualNetwork `
-ResourceGroupName $RG1 `
-Location $Location1 `
-Name $VNetName1 `

Add-AzVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1 -VirtualNetwork
$virtualNetwork1
# Set the subnet configuration for virtual network 1

$virtualNetwork1 | Set-AzVirtualNetwork
Add-AzVirtualNetworkSubnetConfig -Name $GWSubName1 -AddressPrefix $GWSubPrefix1 -VirtualNetwork
$virtualNetwork1


$gwpip1= New-AzPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 -Location $Location1 `

$vnet1 = Get-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1
$subnet1 = Get-AzVirtualNetworkSubnetConfig -Name $GWSubName1 -VirtualNetwork $vnet1
$gwipconfig1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 -SubnetId $subnet1.Id -
PublicIpAddressId $gwpip1.Id
# Create the VPN gateway (takes 20-40 minutes)

New-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 `
-Location $Location1 -IpConfigurations $gwipconfig1 -GatewayType Vpn `
# Create the second resource group

# Create a virtual network 2

$virtualNetwork2 = New-AzVirtualNetwork `
-ResourceGroupName $RG2 `
-Location $Location2 `
-Name $VNetName2 `

Add-AzVirtualNetworkSubnetConfig -Name $FESubName2 -AddressPrefix $FESubPrefix2 -VirtualNetwork
$virtualNetwork2
# Set the subnet configuration for virtual network 2


Add-AzVirtualNetworkSubnetConfig -Name $GWSubName2 -AddressPrefix $GWSubPrefix2 -VirtualNetwork
$virtualNetwork2


$gwpip2 = New-AzPublicIpAddress -Name $GWIPName2 -ResourceGroupName $RG2 -Location $Location2 `

$subnet2 = Get-AzVirtualNetworkSubnetConfig -Name $GWSubName2 -VirtualNetwork $vnet2
$gwipconfig2 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName2 -SubnetId $subnet2.Id -
PublicIpAddressId $gwpip2.Id
# Create the VPN gateway (takes 20-40 minutes)

-Location $Location2 -IpConfigurations $gwipconfig2 -GatewayType Vpn `
# Create the connections

$vnet1gw = Get-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
New-AzVirtualNetworkGatewayConnection -Name $Connection12 -ResourceGroupName $RG1 `
-VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet2gw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'
grupo de recursos. Se eliminarán los grupos de recursos y todos los recursos que contengan.



Get-AzVirtualNetwork Obtiene detalles de una red virtual.

recursos.

New-AzVirtualNetworkGatewayConnection Crea una conexión de red virtual a red virtual.

él.
Pasos siguientes
PowerShell.
Descarga de la plantilla de dispositivos VPN
mediante PowerShell
Este script descarga la plantilla de dispositivos VPN para una conexión
NOTE
# Declare variables
$RG = "TestRG1"
$GWName = "VNet1GW"
$Connection = "VNet1toSite1"
# List the available VPN device models and versions

Get-AzVirtualNetworkGatewaySupportedVpnDevice -Name $GWName -ResourceGroupName $RG
# Download the configuration template for the connection

Get-AzVirtualNetworkGatewayConnectionVpnDeviceConfigScript -Name $Connection -ResourceGroupName $RG `
-DeviceVendor Juniper -DeviceFamily Juniper_SRX_GA -FirmwareVersion Juniper_SRX_12.x_GA

Get-AzVirtualNetworkGatewaySupportedVpnDevice Muestra todos los modelos y las versiones disponibles de

dispositivo VPN.
Get- Descarga la plantilla de configuración para la conexión.

AzVirtualNetworkGatewayConnectionVpnDeviceConfigScript
Pasos siguientes
PowerShell.
Trabajo remoto con los servicios de red de Azure
NOTE
En este artículo se describe cómo usar los servicios de red de Azure, la red de Microsoft y el ecosistema de asociados de
Microsoft para trabajar de forma remota y mitigar los problemas de red que puede experimentar debido a la crisis de
COVID-19.
En este artículo se describen las opciones que están disponibles para que las organizaciones configuren el
acceso remoto para sus usuarios o complementen sus soluciones existentes con capacidad adicional durante los
períodos de máxima utilización. Los arquitectos de red se enfrentan a los siguientes desafíos:
Abordar un aumento del uso de la red.
Proporcionar conectividad segura y confiable a más empleados de su empresa y sus clientes.
Proporcionar conectividad a ubicaciones remotas en todo el mundo.
No todas las redes (por ejemplo, redes principales corporativas y WAN privadas) se congestionan por una carga
máxima de trabajo remoto. Los cuellos de botella se suelen registrar solo en redes de banda ancha domésticas y
en puertas de enlace VPN de redes locales corporativas.
Los planificadores de red pueden ayudar a simplificar los cuellos de botella y aliviar la congestión de la red
teniendo en cuenta que los distintos tipos de tráfico necesitan diferentes prioridades de tratamiento de la red y
una distribución o un redireccionamiento inteligentes de la carga. Por ejemplo, el tráfico de telemedicina en
tiempo real derivado de la interacción entre médicos y pacientes es muy importante y sensible a retrasos y
fluctuaciones. En cambio, la replicación del mismo tráfico entre los almacenamientos no es sensible a retrasos. El
tráfico anterior se debe enrutar a través de la ruta de red más óptima con una mayor calidad de servicio; sin
embargo, es aceptable enrutar el tráfico posterior a través de una ruta poco óptima.
Uso compartido de nuestros procedimientos recomendados: la red de

Azure está diseñada para la elasticidad y alta disponibilidad
Azure está diseñado para resistir cambios repentinos en el uso de los recursos y puede resultar muy útil durante
períodos de máxima utilización. Además, Microsoft mantiene y opera en una de las redes más grandes del
mundo. La red de Microsoft se ha diseñado para ofrecer una alta disponibilidad que puede resistir distintos
tipos de errores: desde el error de un único elemento de la red hasta el error de una región completa.
La red de Microsoft se ha diseñado para cumplir los requisitos y proporcionar un rendimiento óptimo de los
diferentes tipos de tráfico de red, incluido el tráfico multimedia sensible a retrasos para Skype y Teams, la red
CDN, el análisis de macrodatos en tiempo real, Azure Storage, Bing y Xbox. Para proporcionar un rendimiento
óptimo de los diferentes tipos de tráfico, la red de Microsoft atrae todo el tráfico destinado a sus recursos, o que
desea pasar por ellos, lo más cerca posible del origen del tráfico.
NOTE
El uso de las características de red de Azure que se describen a continuación utiliza el comportamiento de atracción del
tráfico de la red global de Microsoft para ofrecer una experiencia de red mejorada para el cliente. El comportamiento de
atracción del tráfico de la red de Microsoft ayuda a descargar el tráfico lo antes posible desde las redes del primer y último
kilómetro que puedan experimentar congestión durante los períodos de máxima utilización.
Permitir que los empleados trabajen de forma remota
Azure VPN Gateway admite conexiones VPN de punto a sitio (P2S) y de sitio a sitio (S2S). Con Azure VPN
Gateway, puede escalar las conexiones de los empleados para que accedan con seguridad tanto a los recursos
implementados en Azure como a los recursos locales. Para más información, vea Permitir que los usuarios
trabajen de forma remota.
Si usa el protocolo de túnel de sockets seguros (SSTP), el número de conexiones simultáneas está limitado a
128. Para obtener un mayor número de conexiones, se recomienda realizar la transición a OpenVPN o IKEv2.
Para más información, vea Transición al protocolo OpenVPN o IKEv2 desde SSTP.
Para acceder a los recursos implementados en Azure, los desarrolladores remotos pueden usar la solución
Azure Bastion, en lugar de la conexión VPN, para acceder de forma segura a shell (RDP o SSH) sin necesidad de
usar direcciones IP públicas en las máquinas virtuales a las que se accede. Para más información, vea Trabajo
remoto con Azure Bastion.
Puede usar Azure Virtual WAN para agregar una conexión VPN a gran escala, admitir conexiones universales
entre recursos en distintas ubicaciones globales locales, en diferentes redes virtuales radiales regionales, y para
optimizar la utilización de varias redes de banda ancha domésticas. Para más información, vea ¿Tiene
dificultades para trabajar desde casa? Así es cómo Azure Virtual WAN puede ayudar.
Otra forma de respaldar a los recursos remotos consiste en implementar una infraestructura de escritorio
virtual (VDI) hospedada en la red virtual de Azure, protegida con Azure Firewall. Por ejemplo, Windows Virtual
Desktop (WVD) es un servicio de virtualización de escritorio y de aplicaciones que se ejecuta en Azure. Con
Windows Virtual Desktop, puede configurar un entorno flexible y escalable en su suscripción de Azure sin
necesidad de ejecutar ningún servidor de puerta de enlace adicional. Solo es responsable de las máquinas
virtuales WVD de la red virtual. Para más información, vea Compatibilidad con trabajo remoto de Azure Firewall.
Azure también cuenta con un amplio conjunto de asociados en su ecosistema. Las aplicaciones virtuales de red
de nuestros asociados en Azure también pueden ayudar a escalar la conectividad de VPN. Para más información,
vea Consideraciones sobre la aplicación virtual de red (NVA) para el trabajo remoto.
Extensión de la conexión de los empleados para acceder a los

recursos distribuidos globalmente
Los siguientes servicios de Azure pueden ayudar a permitir que los empleados accedan a los recursos
distribuidos globalmente. Los recursos pueden estar en cualquiera de las regiones de Azure, redes locales o
incluso en otras nubes públicas o privadas.
Emparejamiento de redes vir tuales de Azure : si implementa los recursos en más de una región de
Azure o si agrega la conectividad de los empleados que trabajan de forma remota con varias redes
virtuales, puede establecer la conectividad entre varias redes virtuales de Azure mediante el
emparejamiento de redes virtuales. Para más información, consulte Emparejamiento de redes virtuales.
Solución basada en Azure VPN : para los empleados remotos conectados a Azure a través de P2S o
VPN S2S, puede habilitar el acceso a redes locales mediante la configuración de una VPN S2S entre las
redes locales y Azure VPN Gateway. Para más información, vea Creación de una conexión de sitio a sitio.
ExpressRoute : Con el emparejamiento privado de ExpressRoute, puede habilitar la conectividad privada
entre las implementaciones de Azure y la infraestructura local o la infraestructura de una instalación de
ubicación compartida. ExpressRoute, mediante el emparejamiento de Microsoft, también permite acceder
a los puntos de conexión públicos de Microsoft desde la red local. Las conexiones ExpressRoute no pasan
por la red pública de Internet. Ofrecen conectividad segura, confiabilidad y mayor rendimiento con una
latencia menor y más coherente que las conexiones a Internet típicas. Para más información, consulte
Información general sobre ExpressRoute. Recurrir al proveedor de red existente que ya forma parte de
nuestro ecosistema de asociados de ExpressRoute puede ayudar a reducir el tiempo para obtener
conexiones de ancho de banda grande a Microsoft. Con ExpressRoute Direct puede conectar directamente
su red local a la red troncal de Microsoft. ExpressRoute Direct ofrece dos opciones de velocidad de línea
diferentes de 10 Gbps dual o 100 Gbps.
Azure Vir tual WAN : Azure Virtual WAN permite una interoperabilidad directa entre las conexiones VPN
y los circuitos ExpressRoute. Como se mencionó anteriormente, Azure Virtual WAN también admite
conexiones universales entre recursos en diferentes ubicaciones globales locales, en diferentes redes
virtuales radiales regionales.
Escalado de la conectividad de los clientes a recursos front-end

En los momentos en los que más personas se conectan, muchos sitios web corporativos experimentan un
aumento del tráfico de los clientes. Azure Application Gateway puede ayudar a administrar este aumento de la
carga de trabajo front-end. Para más información, vea Soporte técnico para tráfico elevado en Application
Gateway.
Soporte técnico de Microsoft para el tráfico entre varias nubes

En el caso de las implementaciones de otras nubes públicas, Microsoft puede proporcionar conectividad global.
Azure Virtual WAN, VPN o ExpressRoute pueden servir de ayuda en este sentido. Para ampliar la conectividad de
Azure a otras nubes, puede configurar VPN S2S entre las dos nubes. También puede establecer la conectividad
desde Azure a otras nubes públicas mediante ExpressRoute. Oracle Cloud forma parte del ecosistema de
asociados de ExpressRoute. Puede configurar una interconexión directa entre Azure y Oracle Cloud
Infrastructure. La mayoría de los proveedores de servicios que forman parte del ecosistema de asociados de
ExpressRoute ofrecen también conectividad privada a otras nubes públicas. Al recurrir a estos proveedores de
servicios, puede establecer una conectividad privada entre sus implementaciones en Azure y otras nubes a
través de ExpressRoute.
Pasos siguientes
En los siguientes artículos se describe cómo se pueden usar diferentes características de red de Azure para
escalar a los usuarios para que trabajen de forma remota:
A RT ÍC ULO DESC RIP C IÓ N
Permitir que los usuarios trabajen de forma remota Revise las opciones disponibles para configurar el acceso
remoto para los usuarios o para complementar las
soluciones existentes con capacidad adicional para la
organización.
¿Tiene dificultades para trabajar desde casa? Así es cómo Use Azure Virtual WAN para abordar las necesidades de
Azure Virtual WAN puede ayudar conectividad remota de la organización.
Soporte técnico para tráfico elevado en Application Gateway Use Application Gateway con el firewall de aplicaciones web
(WAF) para una manera escalable y segura de administrar el
tráfico a las aplicaciones web.
Consideraciones sobre el trabajo remoto en la aplicación Revise la guía sobre cómo aprovechar las NVA en Azure para
virtual de red (NVA) proporcionar soluciones de acceso remoto.
Transición al protocolo OpenVPN o IKEv2 desde SSTP Supere el límite de 128 conexiones simultáneas de SSTP
mediante la transición al protocolo OpenVPN o IKEv2.
A RT ÍC ULO DESC RIP C IÓ N
Trabajo remoto con Azure Bastion Proporcione conectividad RDP/SSH segura y sin problemas a
las máquinas virtuales dentro de la red virtual de Azure,
directamente en Azure Portal, sin usar una dirección IP
pública.
Uso de Azure ExpressRoute para crear una conectividad Use ExpressRoute para la conectividad híbrida para permitir
híbrida para admitir usuarios remotos que los usuarios de la organización trabajen de forma
remota.
Compatibilidad con trabajo remoto de Azure Firewall Proteja los recursos de la red virtual de Azure mediante
Azure Firewall.
Trabajo remoto de punto a sitio de Azure VPN
Gateway
NOTE
En este artículo se describe cómo puede aprovechar Azure VPN Gateway, Azure, la red de Microsoft y el ecosistema de
asociados de Azure para trabajar de forma remota y mitigar los problemas de red que está experimentando debido a la
crisis del COVID-19.
En este artículo se describen las opciones de que disponen las organizaciones para configurar el acceso remoto
para sus usuarios o para complementar sus soluciones existentes con capacidad adicional durante la epidemia
de la COVID-19.
La solución de punto a sitio de Azure se basa en la nube y se puede aprovisionar rápidamente para satisfacer el
aumento de la demanda de usuarios para trabajar desde casa. Puede escalarse verticalmente y desactivarse de
la manera más fácil y rápida cuando ya no se necesite la mayor capacidad.
Acerca de las conexiones VPN de punto a sitio

Una conexión de puerta de enlace de VPN de punto a sitio (P2S) permite crear una conexión segura a la red
virtual desde un equipo cliente individual. Se establece una conexión de punto a sitio al iniciarla desde el equipo
cliente. Esta solución resulta útil para los teletrabajadores que quieran conectarse a redes virtuales de Azure o a
centros de datos locales desde una ubicación remota, por ejemplo, desde casa o un congreso. En este artículo se
describe cómo permitir que los usuarios trabajen de forma remota en función de varios casos.
En la tabla siguiente se muestran los sistemas operativos cliente y las opciones de autenticación que están a su
disposición. Sería útil seleccionar el método de autenticación en función del sistema operativo cliente que ya
está en uso. Por ejemplo, seleccione OpenVPN con una autenticación basada en certificados si tiene una
combinación de sistemas operativos cliente que necesitan conectarse. Tenga en cuenta también que la VPN de
punto a sitio solo se admite en puertas de enlace de VPN basadas en rutas.
Escenario 1: los usuarios solo necesitan acceder a los recursos de
Azure
En este caso, los usuarios remotos solo necesitan obtener acceso a los recursos que se encuentran en Azure.
En un nivel alto, se deben seguir estos pasos para que los usuarios puedan conectarse a los recursos de Azure
de forma segura:
1. Cree una puerta de enlace de red virtual (solo si no existe).
2. Configure una conexión VPN de punto a sitio en la puerta de enlace.
Para la autenticación de certificados, siga este vínculo.
Para OpenVPN, siga este vínculo.
Para la autenticación de Azure AD, siga este vínculo.
Para solucionar los problemas de las conexiones de punto a sitio, siga este vínculo.
3. Descargue y distribuya la configuración del cliente VPN.
4. Distribuya los certificados (si se selecciona la autenticación de certificados) a los clientes.
5. Conéctese a una VPN de Azure.
Escenario 2: los usuarios necesitan acceder a los recursos de Azure o

a recursos locales
En este caso, los usuarios remotos necesitan obtener acceso a los recursos que se encuentran en Azure y en los
centros de datos locales.
En un nivel alto, se deben seguir estos pasos para que los usuarios puedan conectarse a los recursos de Azure
de forma segura:
1. Cree una puerta de enlace de red virtual (solo si no existe).
2. Configure una conexión VPN de punto a sitio en la puerta de enlace (consulte el escenario 1).
3. Configure un túnel de sitio a sitio en la puerta de enlace de red virtual de Azure con el protocolo BGP
habilitado.
4. Configure un dispositivo local para conectarse a la puerta de enlace de red virtual de Azure.
5. Descargar el perfil de punto a sitio desde Azure Portal y distribuirlo a los clientes
Para aprender a configurar un túnel VPN de sitio a sitio, consulte este vínculo.
Preguntas más frecuentes acerca de la autenticación de certificado

nativa de Azure
¿Cuántos puntos de conexión de cliente VPN puedo tener en mi configuración 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 7 (32 bits y 64 bits)
Windows Server 2008 R2 (solo 64 bits)
Windows 8.1 (32 bits y 64 bits)
Windows Server 2012 (solo 64 bits)
Windows 10
Mac OS X versión 10.11 o versiones posteriores
Linux (StrongSwan)
iOS
NOTE
A partir del 1 de julio de 2018, se elimina la compatibilidad con TLS 1.0 y 1.1 de Azure VPN Gateway. VPN Gateway será
solo compatible con TLS 1.2. Para mantener la compatibilidad, consulte las actualizaciones para habilitar la compatibilidad
con TLS 1.2.
Además, los siguientes algoritmos heredados también pasarán a estar en desuso para TLS a partir del 1 de julio
de 2018:
RC4 (Rivest Cipher 4)
DES (Algoritmo de cifrado de datos)
3DES (Triple algoritmo de cifrado de datos)
MD5 (Código hash 5)
¿Cómo se habilita la compatibilidad con TLS 1.2 en Windows 7 y Windows 8.1?
1. Abra un símbolo del sistema con privilegios elevados. Para ello, haga clic con el botón derecho en
Símbolo del sistema y seleccione Ejecutar como administrador .
2. En el símbolo del sistema, ejecute los siguientes comandos:
reg add HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13 /v TlsVersion /t REG_DWORD /d 0xfc0

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v
DefaultSecureProtocols /t REG_DWORD /d 0xaa0
if %PROCESSOR_ARCHITECTURE% EQU AMD64 reg add
"HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" /v
3. Instale realizaron las siguientes actualizaciones:

KB3140245
KB2977292
4. Reinicie el equipo.
5. Conéctese a la VPN.
NOTE
Tendrá que establecer la clave del registro anterior si está ejecutando una versión anterior de Windows 10 (10240).
¿Puedo atravesar servidores proxy y firewalls con la funcionalidad 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 no. 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 con configuración de punto a sitio, se volverá a conectar la VPN de forma
automática?
De forma predeterminada, el equipo cliente no volverá a establecer la conexión VPN automáticamente.
¿Admite la configuración de punto a sitio la reconexión automática y el DDNS en los clientes VPN?
Las VPN de punto a sitio no admiten la reconexión automática y 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 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 al mismo tiempo?
Sí, las conexiones de punto a sitio con una puerta de enlace de red virtual implementada en una red virtual
emparejada con otras redes virtuales pueden tener acceso a otras redes virtuales emparejadas. Siempre que las
redes virtuales emparejadas usen las características UseRemoteGateway/AllowGatewayTransit, el cliente de
punto a sitio podrá conectarse con ellas. Para más información, consulte este artículo.
¿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.
¿Azure admite VPN IKEv2 con Windows?
IKEv2 se admite en Windows 10 y Server 2016. Sin embargo, para poder usar IKEv2, debe 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.
Para preparar Windows 10 o Server 2016 para IKEv2:
1. Instale la actualización.
VERSIÓ N DEL SO DAT E N ÚM ERO / VÍN C ULO
Windows Server 2016 17 de enero de 2018 KB4057142

Windows 10 Versión 1607
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.
¿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 P2S.
Ya tengo implementada una instancia de Azure VPN Gateway. ¿Puedo habilitar VPN de IKEv2 o RADIUS en
ella?
Sí, puede habilitar estas características nuevas en puertas de enlace ya implementadas mediante Powershell o
Azure Portal, siempre que la SKU de la puerta de enlace que use admita RADIUS o IKEv2. Por ejemplo, la SKU de
nivel Básico de VPN Gateway 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 ser vidor validando el cer tificado" o agregue el FQDN del
ser vidor junto con el cer tificado 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.
MakeCer t: 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.
Preguntas más frecuentes acerca de la autenticación RADIUS

Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

¿Se admite la autenticación RADIUS en todas las SKU de Azure VPN Gateway?
La autenticación RADIUS es compatible con las SKU VpnGw1, VpnGw2 y VpnGw3. 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.
¿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 solo es compatible con el protocolo OpenVPN a través de PowerShell.
Pasos siguientes
Configure a P2S connection - Azure AD authentication (Configurar una conexión P2S: autenticación
Azure AD)
Configure a P2S connection - RADIUS authentication (Configurar una conexión P2S: autenticación
RADIUS)
Configure a P2S connection - Azure native certificate authentication (Configurar una conexión P2S:
autenticación de certificados nativos de Azure)
"OpenVPN" es una marca comercial de OpenVPN Inc.
Trabajo de forma remota: Consideraciones sobre el
trabajo remoto en la aplicación virtual de red (NVA)
NOTE
En este artículo se describe cómo puede aprovechar las aplicaciones virtuales de red, Azure, la red de Microsoft y el
ecosistema de asociados de Azure para trabajar de forma remota y mitigar los problemas de red que está experimentando
debido a la crisis provocada por la COVID-19.
Algunos clientes de Azure usan aplicaciones virtuales de red (NVA) de terceros de Azure Marketplace para
proporcionar servicios críticos como VPN de punto a sitio para los empleados que trabajan desde casa durante
la epidemia de COVID-19. En este artículo se describe una orientación de alto nivel que se debe tener en cuenta
al aprovechar las NVA en Azure para proporcionar soluciones de acceso remoto.
Consideraciones sobre el rendimiento de las NVA

Todos los proveedores importantes de NVA en Azure Marketplace deben tener recomendaciones sobre el
tamaño de VM y el número de instancias que se usarán al implementar sus soluciones. Aunque casi todos los
proveedores de NVA le permitirán elegir cualquier tamaño que esté disponible para usted en una región
determinada, es muy importante que siga las recomendaciones de los proveedores con respecto a los tamaños
de instancia de VM de Azure, ya que estas recomendaciones son los tamaños de VM en los que el proveedor ha
realizado pruebas de rendimiento con Azure.
Considere lo siguiente
Capacidad y número de usuarios simultáneos : este número es especialmente importante para los
usuarios de VPN de punto a sitio, ya que cada usuario conectado creará un túnel cifrado (VPN SSL o IPSec).
Rendimiento agregado : el ancho de banda agregado que necesitará para incluir el número de usuarios
necesarios a los cuales deberá proporcionar acceso remoto.
El tamaño de VM que necesitará : siempre debe usar los tamaños de VM que recomienda el proveedor de
NVA. En el caso de una VPN de punto a sitio, si tiene muchas conexiones de usuario simultáneas, debe usar
tamaños de VM más grandes, como máquinas virtuales de las series Dv2 y DSv2. Estas máquinas virtuales
tienden a tener más CPU virtuales y pueden manejar más sesiones de VPN simultáneas. Además de tener
más núcleos virtuales, los tamaños de máquina virtual más grandes de Azure tienen más capacidad de
ancho de banda agregada que los tamaños de máquina virtual más pequeños.
Impor tante: Cada proveedor utiliza los recursos de manera diferente. Si no está claro qué tamaños
de instancia debe utilizar para dar cabida a la carga de usuarios estimada, debe ponerse en contacto
directamente con el proveedor de software y solicitarle una recomendación.
Número de instancias : si espera tener un gran número de usuarios y conexiones, existen límites con
respecto a lo que puede conseguir al escalar de manera vertical los tamaños de las instancias de NVA.
Considere la posibilidad de implementar varias instancias de VM.
VPN de IPSec frente a VPN SSL : en general, las implementaciones de VPN de IPSec funcionan mejor que
las implementaciones de VPN SSL.
Licencias : asegúrese de que las licencias de software que adquirió para la solución de NVA cubran el
crecimiento repentino que puede experimentar durante la epidemia de COVID-19. Muchos programas de
licencias de NVA limitan el número de conexiones o el ancho de banda que admite la solución.
Redes aceleradas : considere una solución de NVA que tenga compatibilidad con las redes aceleradas.
Accelerated Networking habilita la virtualización de E/S de raíz única (SR-IOV) en una máquina virtual (VM),
lo que mejora significativamente su rendimiento en la red. Este método de alto rendimiento omite el host de
la ruta de acceso de datos, lo que reduce la latencia, la inestabilidad y la utilización de la CPU para usarse con
las cargas de trabajo de red más exigentes en los tipos de máquina virtual admitidos. Las redes aceleradas
son compatibles con la mayoría de los tamaños de instancia de uso general y optimizados para procesos de
dos o más vCPU.
Supervisión de recursos
Cada solución de NVA tiene sus propias herramientas y recursos para supervisar el rendimiento de su NVA.
Consulte la documentación de los proveedores para asegurarse de entender las limitaciones de rendimiento y
de poder detectar cuándo la NVA está cerca de alcanzar su capacidad. Además, puede consultar Azure Monitor
Network Insights y ver información básica sobre el rendimiento de las aplicaciones virtuales de red como:
Uso de CPU
Red interna
Red interna
Flujos de entrada
Flujos de salida
Pasos siguientes
La mayoría de los asociados de NVA importantes han publicado guías sobre cómo escalar debido al crecimiento
inesperado y repentino durante la pandemia de COVID-19. Estos son algunos vínculos útiles a recursos de los
asociados.
Barracuda Enable Work from home while securing your data during COVID-19 (Barracuda: Permita trabajar
desde casa a la vez que protege sus datos durante la COVID-19)
Check Point protege los recursos remotos durante la crisis del coronavirus
Cisco AnyConnect Implementation and Performance/Scaling Reference for COVID-19 Preparation (Cisco:
Implementación de AnyConnect y referencia de rendimiento y escalado para la preparación ante la COVID-19)
Citrix COVID-19 Response Support Center (Citrix: Centro de apoyo a la respuesta ante la COVID-19)
F5 Guidance to Address the Dramatic Increase in Remote Workers (F5: Guía para abordar el aumento drástico
de trabajadores remotos)
Fortinet COVID-19 Updates for Customers and Partners (Fortinet: Actualizaciones sobre la COVID-19 para
clientes y asociados)
Palo Alto Networks COVID-19 Response Center (Palo Alto Networks: Centro de respuesta frente a la COVID-19)
Kemp habilita el trabajo remoto y la experiencia de la aplicación AlwaysOn para la continuidad empresarial
Diseño de VPN Gateway
Es importante saber que hay distintas configuraciones disponibles para las conexiones de VPN Gateway. Es
preciso determinar qué configuración es la que mejor se adapta a sus necesidades. En las secciones siguientes,
puede ver diagramas de topología e información de diseño sobre las siguientes conexiones de VPN Gateway.
Use los gráficos y las descripciones como ayuda para seleccionar la topología de conexión que mejor se ajuste a
sus requisitos. Los diagramas muestran las principales topologías de referencia, pero también se pueden crear
configuraciones más complejas con los diagramas como guía.
Sitio a sitio y multisitio (túnel VPN de IPsec/IKE)

De sitio a sitio
Una conexión de puerta de enlace de VPN de sitio a sitio (S2S) es una conexión a través de un túnel VPN
IPsec/IKE (IKEv1 o IKEv2). Se pueden usar conexiones S2S para las configuraciones híbridas y entre locales. Una
conexión S2S requiere un dispositivo VPN local que tenga una dirección IP pública asignada. Para más
información acerca de cómo seleccionar un dispositivo VPN, consulte la sección de preguntas frecuentes sobre
VPN Gateway para dispositivos VPN.
VPN Gateway se puede configurar en modo activo-espera mediante una dirección IP pública o en modo activo-
activo con dos direcciones IP públicas. En modo activo-espera, hay un túnel IPsec activo y el otro túnel está en
espera. En esta configuración, el tráfico fluye a través del túnel activo y, si se produce algún problema con este
túnel, el tráfico cambia al túnel en espera. Se recomienda la configuración de VPN Gateway en modo activo-
activo, porque ambos túneles de IPsec están activos simultáneamente, con datos que fluyen a través de los dos
al mismo tiempo. Una ventaja adicional del modo activo-activo es que los clientes experimentan un mayor
rendimiento.
Multisitio
Este tipo de conexión es una variación de la conexión de sitio a sitio. Puede crear más de una conexión VPN
desde la puerta de enlace de red virtual, normalmente conectándose a varios sitios locales. Cuando trabaje con
varias conexiones, debe usar una VPN de tipo RouteBased (conocida como puerta de enlace dinámica al trabajar
con redes virtuales clásicas). Como cada red virtual solo puede tener una puerta de enlace de red virtual, todas
las conexiones a través de la puerta de enlace comparten el ancho de banda disponible. Este tipo de conexión se
denomina con frecuencia, conexión "multisitio".
Modelos de implementación y métodos para conexiones de sitio a sitio y multisitio
M ÉTO DO O M O DELO DE
IM P L EM EN TA C IÓ N A Z URE P O RTA L P O W ERSH EL L C L I DE A Z URE
Resource Manager Tutorial Tutorial Tutorial

Tutorial+
Clásico Tutorial** Tutorial+ No compatible
( ** ) indica que este método contiene pasos que requieren PowerShell.

(+) indica que este artículo se escribió para conexiones multisitio.
VPN de punto a sitio

cliente. Esta solución resulta útil para los teletrabajadores que deseen conectarse a redes virtuales de Azure
desde una ubicación remota, por ejemplo, desde casa o un congreso. La conexión VPN de punto a sitio también
es una solución útil en comparación con la conexión VPN de sitio a sitio cuando solo necesitan conectarse a la
red virtual algunos clientes.
A diferencia de las conexiones S2S, las conexiones P2S no necesitan una dirección IP pública local ni dispositivos
VPN. Se pueden usar conexiones P2S con conexiones S2S a través de la misma instancia de VPN Gateway,
siempre que todos los requisitos de configuración para ambas conexiones sean compatibles. Para más
información sobre las conexiones de punto a sitio, consulte Acerca de las conexiones VPN de punto a sitio.
Métodos y modelos de implementación para P2S
Autenticación mediante cer tificados nativos de Azure
IM P L EM EN TA C IÓ N A Z URE P O RTA L P O W ERSH EL L
Resource Manager Tutorial Tutorial
Clásico Tutorial Compatible
Autenticación RADIUS
Resource Manager Compatible Tutorial
Clásico No compatible No compatible
Conexiones de red virtual a red virtual (túnel VPN de IPsec/IKE)

La conexión de una red virtual a otra es muy parecida a la conexión de una red virtual a una ubicación de un
sitio local. Ambos tipos de conectividad usan una puerta de enlace de VPN para proporcionar un túnel seguro
con IPsec/IKE. Incluso puede combinar la comunicación de red virtual a red virtual con configuraciones de
conexión multisitio. Esto permite establecer topologías de red que combinen la conectividad entre entornos con
la conectividad entre redes virtuales.
Las redes virtuales que conecta pueden:
estar en la misma región o en distintas;
pertenecer a la misma suscripción o a distintas;
usar el mismo modelo de implementación o diferentes.
Conexiones entre modelos de implementación
Actualmente, Azure tiene dos modelos de implementación: el clásico y el de Resource Manager. Si lleva un
tiempo usando Azure, es probable que tenga máquinas virtuales de Azure y roles de instancia que se ejecuten
en una red virtual clásica. Es posible que sus máquinas virtuales e instancias de roles más recientes se estén
ejecutando en una red virtual creada en Resource Manager. Puede crear una conexión entre las redes virtuales
para permitir que los recursos de una red virtual se comuniquen directamente con los recursos de otra.
Emparejamiento de VNET
Es posible que pueda usar el emparejamiento de VNET para crear la conexión, siempre que la red virtual cumpla
determinados requisitos. El emparejamiento de VNET no utiliza una puerta de enlace de red virtual. Para más
información, consulte Emparejamiento de VNET.
Modelos de implementación y métodos para conexiones de red virtual a red virtual
IM P L EM EN TA C IÓ N A Z URE P O RTA L P O W ERSH EL L C L I DE A Z URE
Clásico Tutorial* Compatible No compatible
Resource Manager Tutorial+ Tutorial Tutorial
Conexiones entre distintos Tutorial* Tutorial No compatible

modelos de implementación
(+) indica que este método de implementación solo se encuentra disponible para redes virtuales de la misma
suscripción.
( * ) indica que este método de implementación también requiere PowerShell.
ExpressRoute (conexión privada)

ExpressRoute le permite ampliar sus redes locales en la nube de Microsoft a través de una conexión privada que
facilita un proveedor de conectividad. Con ExpressRoute, se pueden establecer conexiones con servicios en la
nube de Microsoft, como Microsoft Azure, Microsoft 365 y CRM Online. La conectividad puede ser desde una
red de conectividad universal (IP VPN), una red Ethernet de punto a punto o una conexión cruzada virtual a
través de un proveedor de conectividad en una instalación de ubicación compartida.
Las conexiones ExpressRoute no pasan por la red pública de Internet. Esto permite a las conexiones de
ExpressRoute ofrecer más confiabilidad, más velocidad, menor latencia y mayor seguridad que las conexiones
normales a través de Internet.
Una conexión de ExpressRoute usa una puerta de enlace de red virtual como parte de su configuración
obligatoria. En una conexión de ExpressRoute, se configura una puerta de enlace de red virtual con el tipo de
puerta de enlace "ExpressRoute", en lugar de "Vpn". Aunque el tráfico que pasa por un circuito de ExpressRoute
no está cifrado de forma predeterminada, es posible crear una solución que le permita enviar tráfico cifrado a
través de este. Para más información sobre ExpressRoute, vea la Información técnica de ExpressRoute.
Conexiones de sitio a sitio y de ExpressRoute coexistentes

ExpressRoute es una conexión privada directa desde la WAN (no a través de Internet) a servicios Microsoft,
incluido Azure. El tráfico VPN de sitio a sitio viaja cifrado a través de la red pública de Internet. Poder configurar
las conexiones VPN de sitio a sitio y ExpressRoute para la misma red virtual tiene varias ventajas.
Puede configurar una VPN de sitio a sitio como una ruta de acceso seguro de conmutación por error para
ExpressRoute, o bien usar la VPN de sitio a sitio para conectarse a sitios que no forman parte de su red, pero
que están conectados a través de ExpressRoute. Tenga en cuenta que esta configuración requiere dos puertas de
enlace de red virtual en la misma red virtual, una con el tipo de puerta de enlace "Vpn" y otra con -el tipo de
puerta de enlace "ExpressRoute".
Coexisten diversos métodos y modelos de implementación de conexiones S2S y ExpressRoute

Resource Manager Compatible Tutorial
Clásico No admitido Tutorial
Conexiones de alta disponibilidad

Para planear y diseñar conexiones de alta disponibilidad, consulte Conexiones de alta disponibilidad.
Pasos siguientes
Consulte las Preguntas más frecuentes sobre VPN Gateway para más información.
Obtenga más información sobre la configuración de VPN Gateway.
Para obtener consideraciones sobre BGP de VPN Gateway, consulte Acerca de BGP.
Consulte Límites del servicio y la suscripción.
Obtenga información sobre las demás funcionalidades de red clave de Azure.
Acerca de la configuración de VPN Gateway
Una puerta de enlace de VPN es un tipo de puerta de enlace de red virtual que 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 a través de la red troncal de Azure.
Una conexión de puerta de enlace de VPN se basa en la configuración de varios recursos, cada uno de los cuales
contiene valores configurables. Las secciones de este artículo tratan los recursos y la configuración relacionados
con una puerta de enlace de VPN para una red virtual creada en el modelo de implementación de Resource
Manager. Puede encontrar las descripciones y los diagramas de topología de cada solución de conexión en el
artículo Acerca de VPN Gateway.
Los valores de este artículo se aplican a las puertas de enlace de VPN (puertas de enlace de red virtual que usan
-GatewayType Vpn). En este artículo no se cubren todos los tipos de puerta de enlace ni puertas de enlace con
redundancia de zona.
Para los valores que se aplican a -GatewayType "ExpressRoute", consulte Acerca de las puertas de enlace
de red virtual para ExpressRoute.
Para las puertas de enlace con redundancia de zona, consulte Acerca de VPN Gateway.
Para Virtual WAN, consulte Acerca de Virtual WAN.
Tipos de puerta de enlace

Cada red virtual solo puede tener una puerta de enlace de red de cada tipo. Al crear una puerta de enlace de red
virtual, debe asegurarse de que el tipo de puerta de enlace es el correcto para su configuración.
Los valores disponibles para -GatewayType son:
VPN
ExpressRoute
Una puerta de enlace de VPN requiere la red privada virtual -GatewayType .
Ejemplo:
New-AzVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `

-Location 'West US' -IpConfigurations $gwipconfig -GatewayType Vpn `
-VpnType RouteBased

Al crear una puerta de enlace de red virtual, debe especificar la SKU de la puerta de enlace que desea usar.
Seleccione las SKU que cumplan sus requisitos en función de los tipos de cargas de trabajo, rendimientos,
características y Acuerdos de Nivel de Servicio. En relación con las SKU de puerta de enlace de red virtual en
Azure Availability Zones, vea la información sobre las SKU de puerta de enlace de Azure Availability Zones.
SKU de puerta de enlace por túnel, conexión y rendimiento
P RUEB A S

n1
n1
n1
n1 Z
n1 Z
n1 Z
n2
n2
n2

n2 10000
n2 Z
n2 Z
n2 Z

n2 Z 10000
más bajo.
PA Q UET ES P O R

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
NOTE
Las SKU de VpnGw (VpnGw1, VpnGw1AZ, VpnGw2, VpnGw2AZ, VpnGw3, VpnGw3AZ, VpnGw4, VpnGw4AZ, VpnGw5 y
VpnGw5AZ) se admiten para el modelo de implementación de Resource Manager únicamente. Las redes virtuales clásicas
deben seguir utilizando las SKU antiguas (heredadas).
Para obtener información sobre cómo trabajar con SKU de puerta de enlace heredadas (Basic, Standard, y
HighPerformance), consulte Trabajo con SKU de puerta de enlace de red virtual (SKU antiguas).
Para las SKU de puerta de enlace de ExpressRoute, consulte Acerca de las puertas de enlace de red virtual para
ExpressRoute.
SKU de puerta de enlace por conjunto de características

Las nueva SKU de puerta de enlace de VPN simplifican los conjuntos de características que se ofrecen en las
puertas de enlace:
SK U C A RA C T ERÍST IC A S
Basic (**) VPN basada en rutas : 10 túneles para conexiones o S2S,

sin autenticación RADIUS para P2S, sin IKEv2 para P2S
VPN basada en directivas : (IKEv1): 1 túnel S2S o
conexión; sin P2S
Todas las SKU de Generation1 y Generation2, VPN basada en ruta : hasta 30 túneles (*), P2S, BGP,
excepto Basic activo-activo, directiva de IPsec/IKE personalizada,
coexistencia de VPN y ExpressRoute
(*) Se puede configurar "PolicyBasedTrafficSelectors" para conectar una instancia de VPN Gateway basada en la
ruta a varios dispositivos de firewall locales basados en directivas. Consulte Connect VPN gateways to multiple
on-premises policy-based VPN devices using PowerShell (Conexión de puertas de enlace VPN Gateway a varios
dispositivos de VPN locales basados en directivas con PowerShell) para más información.
(**) La SKU Basic se considera una SKU heredada. La SKU Basic tiene ciertas limitaciones de características. No
se puede cambiar el tamaño de una puerta de enlace que utiliza una SKU Basic a una de las SKU de puerta de
enlace nuevas, sino que debe cambiar a una SKU nueva, lo que implica eliminar y volver a crear la puerta de
enlace VPN.
SKU de puerta de enlace: producción frente a cargas de desarrollo y pruebas
Dadas las diferencias en los Acuerdos de Nivel de Servicio y los conjuntos de características, se recomiendan las
siguientes SKU para la producción, en comparación el desarrollo y las pruebas:
C A RGA DE T RA B A JO SK U
Cargas de trabajo de producción, críticas Todas las SKU de Generation1 y Generation2, excepto Basic
Desarrollo y pruebas o prueba de concepto Basic (**)
(**) La SKU Basic se considera una SKU heredada y tiene limitaciones de características. Compruebe que se
admite la característica que necesita antes de usar la SKU Basic.
Si continúa utilizando las SKU antiguas (heredadas), las recomendaciones de SKU de producción son Standard y
HighPerformance. Para obtener información e instrucciones para las SKU antiguas, consulte Trabajo con SKU de
puerta de enlace de red virtual (SKU antiguas).
Configuración de una SKU de puerta de enlace
Azure Por tal
Si usa Azure Portal para crear una puerta de enlace de red virtual de Resource Manager, puede seleccionar la
SKU de la puerta de enlace con el menú desplegable. Las opciones que se presentan corresponden con el tipo
de puerta de enlace y tipo de VPN que seleccione.
PowerShell
En el siguiente ejemplo de PowerShell se especifica -GatewaySku como VpnGw1. Al usar PowerShell para crear
una puerta de enlace, antes debe crear la configuración de IP y, después, usar una variable para hacer referencia
a ella. En este ejemplo, la variable de configuración es $gwipconfig.
New-AzVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1 `

-Location 'US East' -IpConfigurations $gwipconfig -GatewaySku VpnGw1 `
-GatewayType Vpn -VpnType RouteBased
CLI de Azure
az network vnet-gateway create --name VNet1GW --public-ip-address VNet1GWPIP --resource-group TestRG1 --vnet
VNet1 --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-wait
Cambio de tamaño o de SKU

Si tiene una puerta de enlace VPN y desea usar una SKU de puerta de enlace distinta, las opciones son o
cambiar el tamaño de la SKU de puerta de enlace o cambiar a otra SKU. Al cambiar a otra SKU de puerta de
enlace, se elimina completamente la puerta de enlace existente y se crea otra. La creación de una puerta de
enlace puede tardar hasta 45 minutos. En cambio, al cambiar el tamaño de la SKU de puerta de enlace, el tiempo
de inactividad será corto, ya que no tiene que eliminar y volver crear la puerta de enlace. Si tiene la opción de
cambiar el tamaño de la SKU de puerta de enlace, en lugar de cambiarla, aprovéchela. Sin embargo, hay reglas
en relación con el cambio de tamaño:
1. A excepción de la SKU básica, puede cambiar el tamaño de una SKU de VPN Gateway a otra SKU de VPN
Gateway dentro de la misma generación (Generation1 o Generation2). Por ejemplo, se puede cambiar el
tamaño de VpnGw1 de Generation1 a VpnGw2 de Generation1, pero no a VpnGw2 de Generation2.
2. Si trabaja con las SKU de puerta de enlace antiguas, puede cambiar el tamaño entre las SKU Básica, Estándar
y HighPerformance.
3. Sin embargo, no puede cambiar el tamaño de las SKU de Básica/Estándar/HighPerformance a las SKU de
VpnGw. En su lugar, debe cambiar a las SKU nuevas.
Cambiar el tamaño de una puerta de enlace
Azure Por tal

PowerShell
Puede usar el cmdlet de PowerShell Resize-AzVirtualNetworkGateway para actualizar o cambiar a una versión
anterior una SKU de Generation1 o Generation2 (se puede cambiar el tamaño de todas las SKU de VpnGw
excepto las SKU básicas). Si usa la SKU de puerta de enlace Basic, siga estas instrucciones para cambiar el
tamaño de la puerta de enlace.
En el siguiente ejemplo de PowerShell se muestra una SKU de puerta de enlace cuyo tamaño se ha cambiado a
VpnGw2.
$gw = Get-AzVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg

Resize-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku VpnGw2
Cambiar de una SKU anterior (heredada) anterior a una nueva

Si está trabajando con el modelo de implementación de Resource Manager, puede cambiar a las nuevas SKU de
puerta de enlace. Al cambiar de una SKU de puerta de enlace heredada a una nueva SKU, se elimina la puerta de
enlace de la red virtual existente y se crea una nueva.
Flujo de trabajo:
1. Elimine las conexiones a la puerta de enlace de la red virtual.
2. Elimine la puerta de enlace VPN Gateway antigua.
3. Cree la puerta de enlace VPN Gateway nueva.
4. Actualice los dispositivos VPN locales con la nueva dirección IP de la puerta de enlace VPN Gateway (para las
conexiones de sitio a sitio).
5. Actualice el valor de la dirección IP de puerta de enlace para las puertas de enlace de red local de red virtual
a red virtual que se conectarán a esta puerta de enlace.
6. Descargue los nuevos paquetes de configuración de VPN de cliente para los clientes de P2S que se vayan a
conectar a la red virtual a través de esta puerta de enlace VPN Gateway.
7. Vuelva a crear las conexiones a la puerta de enlace de la red virtual.
Consideraciones:
Para pasar a las nuevas SKU, la puerta de enlace de la red virtual debe estar en el modelo de implementación
de Resource Manager.
Si tiene una puerta de enlace VPN clásica, debe seguir utilizando las SKU heredadas más antiguas para esa
puerta de enlace; sin embargo, puede cambiar el tamaño entre las SKU heredadas. No se puede cambiar as
las nuevas SKU.
Tendrá un tiempo de inactividad de conectividad cuando cambie de una SKU heredada a una nueva.
Al cambiar a una nueva SKU de puerta de enlace, cambiará la dirección IP pública de la puerta de enlace de la
red virtual. Esto sucede incluso si especifica el mismo objeto de dirección IP pública que usó anteriormente.
Tipos de conexión
En el modelo de implementación de Resource Manager, cada configuración requiere un tipo de conexión de
puerta de enlace de red virtual específico. Los valores de PowerShell de Resource Manager para
-ConnectionType son:
IPsec
Vnet2Vnet
ExpressRoute
VPNClient
En el siguiente ejemplo de PowerShell, vamos a crear una conexión de S2S que requiere el tipo de conexión
IPsec.
New-AzVirtualNetworkGatewayConnection -Name localtovon -ResourceGroupName testrg `

-Location 'West US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Tipos de VPN
Al crear la puerta de enlace de red virtual para una configuración de puerta de enlace de VPN, debe especificar
un tipo de VPN. El tipo de VPN que elija dependerá de la topología de conexión que desee crear. Por ejemplo,
una conexión de P2S requiere un tipo de VPN RouteBased. Un tipo de VPN también puede depender del
hardware que se esté usando. Las configuraciones de S2S requieren un dispositivo VPN. Algunos dispositivos
VPN solo serán compatibles con un determinado tipo de VPN.
El tipo de VPN que seleccione debe cumplir todos los requisitos de conexión de la solución que desea crear. Por
ejemplo, si desea crear una conexión de puerta de enlace de VPN de S2S y una conexión de puerta de enlace de
VPN de P2S para la misma red virtual, debería usar el tipo de VPN RouteBased , dado que P2S requiere un tipo
de VPN RouteBased. También necesitaría comprobar que el dispositivo VPN admite una conexión de VPN
RouteBased.
Una vez que se ha creado una puerta de enlace de red virtual, no puede cambiar el tipo de VPN. Tendrá que
eliminar la puerta de enlace de red virtual y crear una nueva. Hay dos tipos de VPN:
PolicyBased: en el modelo de implementación clásica, las VPN basadas en directivas se llamaban
puertas de enlace de enrutamiento estático. Las VPN basadas en directivas cifran y dirigen los paquetes a
través de túneles de IPsec basados en las directivas de IPsec configuradas con las combinaciones de
prefijos de dirección entre su red local y la red virtual de Azure. La directiva (o el selector de tráfico) se
define normalmente como una lista de acceso en la configuración del dispositivo VPN. El valor de un tipo
de VPN basada en directivas es PolicyBased. Cuando use una VPN basada en directivas, tenga en cuenta
las siguientes limitaciones:
Las VPN basadas en directivas solo se utilizan en la SKU de puerta de enlace Básica. Este tipo de VPN
no es compatible con otras SKU de puerta de enlace.
Solo puede tener 1 túnel cuando se usa una VPN basada en directivas.
Las VPN basadas en directivas solo se pueden usar para las conexiones S2S, y solo para determinadas
configuraciones. La mayoría de las configuraciones de VPN Gateway requieren una VPN basada en
enrutamiento.
RouteBased: en el modelo de implementación clásica, las VPN basadas en enrutamiento se llamaban
puertas de enlace de enrutamiento dinámico. 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 el selector de tráfico para las VPN basadas en enrutamiento se configura
como una conectividad del tipo de cualquiera a cualquiera (o caracteres comodín). El valor de un tipo de
VPN basada en enrutamiento es RouteBased.
En el siguiente ejemplo de PowerShell se especifica -VpnType como RouteBased. Al crear una puerta de enlace,
debe asegurarse de que el tipo de VPN es el correcto para su configuración.
New-AzVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg `
-Location 'West US' -IpConfigurations $gwipconfig `
-GatewayType Vpn -VpnType RouteBased
Requisitos de la puerta de enlace

La tabla siguiente enumera los requisitos para las puertas de enlace VPN basadas en enrutamientos y directivas.
Esta tabla se aplica a los modelos de implementación del Administrador de recursos y clásico. Para el modelo
clásico, las puertas de enlace de VPN basadas en directivas son las mismas que las puertas de enlace estáticas y
las basadas en enrutamientos son las mismas que las dinámicas.
VP N GAT EWAY DE
VP N GAT EWAY VP N GAT EWAY VP N GAT EWAY A LTO REN DIM IEN TO
B Á SIC A B A SA DA EN B Á SIC A B A SA DA EN ESTÁ N DA R B A SA DA B A SA DA EN
DIREC T IVA S EN RUTA M IEN TO S EN EN RUTA M IEN TO S EN RUTA M IEN TO S
Conectividad de Configuración de Configuración de Configuración de Configuración de

sitio a sitio...(S2S) VPN de PolicyBased VPN de RouteBased VPN de RouteBased VPN de RouteBased
Conectividad de No compatible Compatible (puede Compatible (puede Compatible (puede

punto a sitio (P2S) coexistir con S2S) coexistir con S2S) coexistir con S2S)
Método de Clave precompartida Clave precompartida Clave precompartida Clave precompartida

autenticación para la conectividad para la conectividad para la conectividad
de S2S, Certificados de S2S, Certificados de S2S, Certificados
para la conectividad para la conectividad para la conectividad
de P2S de P2S de P2S
Número máximo 1 10 10 30
de conexiones S2S
Número máximo No compatible 128 128 128

de conexiones P2S
Compatibilidad No compatible No compatible Compatible Compatible

con enrutamiento
activo (BGP) (*)
(*) BGP no es compatible con el modelo de implementación clásica.
Subred de puerta de enlace

Antes de crear una puerta de enlace de VPN, debe crear una subred de puerta de enlace. La subred de puerta de
enlace contiene las direcciones IP que usan los servicios y las máquinas virtuales de la puerta de enlace de red
virtual. Al crear la puerta de enlace de red virtual, las máquinas virtuales de puerta de enlace se implementan en
la subred de puerta de enlace, y se configuran con las opciones de puerta de enlace de VPN necesarias. Nunca
implemente nada más (por ejemplo, máquinas virtuales adicionales) en la subred de puerta de enlace. Para que
la subred de puerta de enlace funcione correctamente, su nombre tiene que ser “GatewaySubnet2”. La
asignación del nombre "GatewaySubnet" a la subred de puerta de enlace permite a Azure saber que se trata de
la subred donde se implementarán las máquinas virtuales y los servicios de la puerta de enlace de red virtual.
NOTE
Las rutas definidas por el usuario con un destino 0.0.0.0/0 y NSG en GatewaySubnet no se admiten . Se bloqueará la
creación de puertas de enlace creadas con esta configuración. Las puertas de enlace requieren acceso a los controladores
de administración para que funcionen correctamente. Propagación de rutas BGP debe establecerse en "Habilitado" en
GatewaySubnet para garantizar la disponibilidad de la puerta de enlace. Si se establece en deshabilitado, la puerta de
enlace no funcionará.
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 a las máquinas virtuales y los servicios de puerta de
enlace. Algunas configuraciones requieren más direcciones IP que otras.
Cuando planee el tamaño de la subred de puerta de enlace, consulte la documentación de la configuración que
piensa crear. Por ejemplo, la configuración de coexistencia de ExpressRoute/VPN Gateway requiere una subred
de puerta de enlace mayor que la mayoría de las restantes. Debe asegurarse también de que la subred de
puerta de enlace contenga suficientes direcciones IP para acomodar posibles configuraciones adicionales.
Aunque es posible crear una subred de puerta de enlace solo de /29, se recomienda que sea de /27, o incluso
mayor, (/27, /26, etc.), siempre que se disponga de espacio para hacerlo, ya que puede albergar más
configuraciones.
En el ejemplo de PowerShell de Resource Manager siguiente, se muestra una subred de puerta de enlace con el
nombre GatewaySubnet. Puede ver que la notación CIDR especifica /27, que permite suficientes direcciones IP
para la mayoría de las configuraciones que existen.
Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.0.3.0/27
IMPORTANT
Puertas de enlace de red local

Una puerta de enlace de red local es diferente a una puerta de enlace de red virtual. Al crear una configuración
de puerta de enlace de VPN, la puerta de enlace de red local suele representar su red local y el dispositivo VPN
correspondiente. En el modelo de implementación clásica, la puerta de enlace de red local se conoce como un
sitio local.
Asigne un nombre a la puerta de enlace de red local, así como la dirección IP pública o el nombre de dominio
completo del dispositivo VPN local, y especificar los prefijos de dirección que se encuentran en la ubicación
local. Azure examina los prefijos de dirección de destino para el tráfico de red, consulta la configuración que
especificó para la puerta de enlace de red local y enruta los paquetes según corresponda. Si usa el Protocolo de
puerta de enlace de borde (BGP) en el dispositivo VPN, deberá proporcionar la dirección IP del par BGP del
dispositivo VPN y el número de sistema autónomo (ASN) de la red local. También debe especificar puertas de
enlace de red local para configuraciones de red virtual a red virtual local que usan una conexión de puerta de
enlace de VPN.
En el ejemplo siguiente de PowerShell, se crea una nueva puerta de enlace de red local:
New-AzLocalNetworkGateway -Name LocalSite -ResourceGroupName testrg `
-Location 'West US' -GatewayIpAddress '23.99.221.164' -AddressPrefix '10.5.51.0/24'
A veces es necesario modificar la configuración de la puerta de enlace de red local. Por ejemplo, al agregar o
modificar el intervalo de direcciones, o si cambia la dirección IP del dispositivo VPN. Vea Modificación de la
configuración de la puerta de enlace de red local mediante PowerShell.
API de REST, cmdlets de PowerShell y CLI

Para más información sobre los recursos técnicos y los requisitos de sintaxis específicos para usar las API de
REST y los cmdlets de PowerShell para configuraciones de VPN Gateway, consulte las páginas siguientes:
C L Á SIC O RESO URC E M A N A GER
PowerShell PowerShell
REST API REST API
No compatible CLI de Azure
Pasos siguientes
Para más información sobre las configuraciones de conexión disponibles, vea About VPN Gateway (Acerca de
VPN Gateway).
Acerca de los dispositivos VPN y los parámetros de
IPsec/IKE para conexiones de VPN Gateway de sitio
a sitio
Para configurar una conexión VPN entre locales de sitio a sitio (S2S) mediante una puerta de enlace de VPN se
requiere un dispositivo VPN. Las conexiones de sitio a sitio pueden usarse para crear una solución híbrida o
siempre que desee conexiones seguras entre su red local y la red virtual. Este artículo incluye la lista de
dispositivos VPN validados y una lista de parámetros IPsec/IKE para las puertas de enlace de VPN.
IMPORTANT
Si tiene problemas de conectividad entre los dispositivos VPN locales y las puertas de enlace de VPN, consulte Problemas
conocidos de compatibilidad de dispositivos.
Elementos que hay que tener en cuenta para consultar las tablas:
Ha habido un cambio terminológico en las puertas de enlace de VPN de Azure. Solo han cambiado los
nombres. No hay ningún cambio de funcionalidad.
Enrutamiento estático = PolicyBased
Enrutamiento dinámico = RouteBased
Las especificaciones de VPN Gateway HighPerformance y VPN Gateway RouteBased son las mismas, a
menos que se indique lo contrario. Por ejemplo, los dispositivos VPN validados que son compatibles con las
puertas de enlace de VPN RouteBased también son compatibles con las puertas de enlace de VPN
HighPerformance.
Dispositivos VPN validados y guías de configuración de dispositivos

En colaboración con proveedores de dispositivos, hemos validado un conjunto de dispositivos VPN estándar.
Todos los dispositivos de las familias de dispositivos en la lista siguiente deben trabajar con puertas de enlace
de VPN. Consulte la información acerca de la configuración de VPN Gateway para entender el tipo de VPN
utilizado (PolicyBased o RouteBased) para la solución VPN Gateway que desea configurar.
Con el fin de configurar el dispositivo VPN, consulte los vínculos correspondientes a la familia de dispositivos
apropiada. Los vínculos a las instrucciones de configuración se proporcionan dentro de lo posible. Para obtener
soporte para los dispositivos VPN, póngase en contacto con el fabricante.
IN ST RUC C IO N ES DE IN ST RUC C IO N ES DE
FA M IL IA DE VERSIÓ N M ÍN IM A DE C O N F IGURA C IÓ N C O N F IGURA C IÓ N
P RO VEEDO R DISP O SIT IVO S SIST EM A O P ERAT IVO P O L IC Y B A SED RO UT EB A SED
A10 Networks, Inc. Thunder CFW ACOS 4.1.1 No compatible Guía de

configuración
Allied Telesis Enrutadores VPN de Serie AR 5.4.7+ Guía de Guía de

la serie AR configuración configuración
Arista Enrutador CloudEOS vEOS 4.24.0FX (no probado) Guía de

configuración
Barracuda Networks, Barracuda CloudGen PolicyBased: 5.4.3 Guía de Guía de

Inc. Firewall RouteBased: 6.2.0 configuración configuración
Punto de Puerta de enlace de R80.10 Guía de Guía de

comprobación seguridad configuración configuración
Cisco ASA 8.3 Compatible Guía de

8.4+ (IKEv2*) configuración*
Cisco ASR PolicyBased: IOS 15.1 Compatible Compatible

RouteBased: IOS 15.2
Cisco CSR RouteBased: IOS-XE (no probado) Script de

16.10 configuración
Cisco ISR PolicyBased: IOS 15.0 Compatible Compatible

RouteBased*: IOS
15.1
Cisco Meraki (MX) MX v15.12 No compatible Guía de

configuración
Cisco vEdge (SO Viptela) 18.4.0 (modo No compatible Configuración

Activo/Pasivo) manual
(activa/pasiva)
19.2 (modo
Activo/Pasivo) Configuración de
Cloud Onramp
(activa/activa)
Citrix NetScaler MPX, SDX, 10.1 y superior Guía de No compatible

VPX configuración
F5 Serie BIG-IP 12.0 Guía de Guía de

configuración configuración
Fortinet FortiGate FortiOS 5.6 (no probado) Guía de

configuración
Hillstone Networks Next-Gen Firewalls 5.5R7 (no probado) Guía de

(NGFW) configuración
Internet Initiative Serie SEIL SEIL/X 4.60 Guía de No compatible

Japan (IIJ) SEIL/B1 4.60 configuración
SEIL/x86 3.20
Juniper SRX PolicyBased: JunOS Compatible Script de

10.2 configuración
Routebased: JunOS
11.4
Juniper Serie J PolicyBased: JunOS Compatible Script de

10.4r9 configuración
RouteBased: JunOS
11.4
Juniper ISG ScreenOS 6.3 Compatible Script de

configuración
Juniper SSG ScreenOS 6.2 Compatible Script de

configuración
Juniper MX JunOS 12.x Compatible Script de

configuración
Microsoft Servicio de acceso Windows Server No compatible Compatible

remoto y 2012
enrutamiento
Open Systems AG Mission Control N/D Guía de No compatible

Security Gateway configuración
Palo Alto Networks Todos los dispositivos PAN-OS Compatible Guía de

que ejecutan PAN-OS PolicyBased: 6.1.5 o configuración
posterior
RouteBased: 7.1.4
Sentrium VyOS VyOS 1.2.2 (no probado) Guía de

(desarrollador) configuración
ShareTech UTM de próxima 9.0.1.3 No compatible Guía de

generación (serie NU) configuración
SonicWall Serie TZ, serie NSA SonicOS 5.8.x No compatible Guía de

Serie SuperMassive SonicOS 5.9.x configuración
Serie E-Class NSA SonicOS 6.x
Sophos Firewall de última XG v17 (no probado) Guía de

generación XG configuración
Guía de
configuración: varios
SA
Synology MR2200ac SRM1.1.5/VpnPlusSer (no probado) Guía de

RT2600ac ver-1.2.0 configuración
RT1900ac
Ubiquiti EdgeRouter EdgeOS v1.10 (no probado) BGP a través de

IKEv2/IPsec
VTI a través de
IKEv2/IPsec
Ultra 3E-636L3 5.2.0.T3, (no probado) Guía de

compilación 13 configuración
WatchGuard All Fireware XTM Guía de Guía de

PolicyBased: v11.11.x configuración configuración
RouteBased: v11.12.x
Zyxel Serie ZyWALL USG ZLD v4.32+ (no probado) VTI a través de
Serie ZyWALL ATP IKEv2/IPsec
Serie ZyWALL VPN
BGP a través de
IKEv2/IPsec
NOTE
(*) Las versiones de Cisco ASA 8.4 y posteriores incorporan compatibilidad con IKEv2, puede conectarse a la puerta de
enlace de VPN de Azure mediante la directiva personalizada de IPsec/IKE con la opción "UsePolicyBasedTrafficSelectors".
Puede consultar este artículo de procedimientos.
(**) Los enrutadores de la serie ISR 7200 solo admiten VPN basadas en directivas.
Descarga de los scripts de configuración de dispositivos VPN desde

Azure
Para determinados dispositivos, puede descargar los scripts de configuración directamente desde Azure. Para
más información y las instrucciones de descarga, consulte Descarga de scripts de configuración de dispositivos
VPN para conexiones VPN S2S.
Dispositivos con scripts de configuración disponibles
P RO VEEDO R FA M IL IA DE DISP O SIT IVO S VERSIÓ N DE F IRM WA RE
Cisco ISR IOS 15.1 (versión preliminar)
Cisco ASA ASA (*) RouteBased (IKEv2: sin BGP)

para versión de ASA anterior a 9.8
Cisco ASA ASA RouteBased (IKEv2: sin BGP) para

versión de ASA superior a 9.8
Juniper SRX_GA 12.x
Juniper SSG_GA ScreenOS 6.2.x
Juniper JSeries_GA JunOS 12.x
Juniper SRX JunOS 12.x RouteBased BGP
Ubiquiti EdgeRouter EdgeOS v1.10x RouteBased VTI
Ubiquiti EdgeRouter EdgeOS v1.10x RouteBased BGP

NOTE
(*) Obligatorio: NarrowAzureTrafficSelectors (habilitar la opción UsePolicyBasedTrafficSelectors) y CustomAzurePolicies
(IKE/IPsec)
Dispositivos VPN no validados

Si el dispositivo no aparece en la tabla de dispositivos VPN validados, es posible que todavía funcione con una
conexión de sitio a sitio. Póngase en contacto con el fabricante del dispositivo para obtener instrucciones
adicionales de soporte técnico y configuración.
Edición de ejemplos de configuración de dispositivos

Después de descargar el ejemplo de configuración del dispositivo VPN proporcionado, deberá reemplazar
algunos de los valores para reflejar la configuración de su entorno.
Para editar una muestra:
1. Abra el ejemplo con el Bloc de notas.
2. Busque y reemplace todas las cadenas de <texto> por los valores que pertenezcan al entorno. Asegúrese de
incluir < y >. Cuando se especifica un nombre, el nombre que seleccione debe ser único. Si un comando no
funciona, consulte la documentación del fabricante del dispositivo.
T EXTO DE E JEM P LO C A M B IA R A
<RP_OnPremisesNetwork> Nombre elegido para este objeto. Ejemplo: miRedLocal
<RP_AzureNetwork> Nombre elegido para este objeto. Ejemplo: miRedAzure
<RP_AccessList> Nombre elegido para este objeto. Ejemplo:

miListaAccesoAzure
<RP_IPSecTransformSet> Nombre elegido para este objeto. Ejemplo:

miConjuntoTransIPSec
<RP_IPSecCryptoMap> Nombre elegido para este objeto. Ejemplo:

miAsignCifradoIPSec
<SP_AzureNetworkIpRange> Especifique el rango. Ejemplo: 192.168.0.0
<SP_AzureNetworkSubnetMask> Especifique la máscara de subred. Ejemplo: 255.255.0.0
<SP_OnPremisesNetworkIpRange> Especifique el rango local. Ejemplo: 10.2.1.0
<SP_OnPremisesNetworkSubnetMask> Especifique la máscara de subred local. Ejemplo:

255.255.255.0
<SP_AzureGatewayIpAddress> Esta información es específica de la red virtual y se encuentra

en el Portal de administración como Dirección IP de
puer ta de enlace .
<SP_PresharedKey> Esta información es específica de la red virtual y se encuentra

en el Portal de administración, en Administrar clave.
Parámetros de IPsec/IKE predeterminados
Las tablas siguientes contienen las combinaciones de algoritmos y parámetros que usan las puertas de enlace
de VPN de Azure en la configuración predeterminada (Directivas predeterminadas ). Para puertas de enlace
de VPN basadas en enrutamiento creadas mediante el modelo de implementación de Azure Resource
Management, puede especificar una directiva personalizada en cada conexión individual. Consulte
Configuración de directiva IPsec/IKE para obtener instrucciones detalladas.
Además, debe fijar el MSS de TCP en 1350 . O, si los dispositivos VPN no admiten la fijación de MSS, también
puede establecer el MTU en la interfaz de túnel en 1400 bytes.
En las tablas siguientes:
SA = Asociación de seguridad
La fase 1 de IKE también se denomina "Modo principal"
La fase 2 de IKE también se denomina "Modo rápido"
Parámetros de la fase 1 de IKE (Modo principal)
P RO P IEDA D P O L IC Y B A SED RO UT EB A SED
Versión de IKE IKEv1 IKEv1 e IKEv2
Grupo Diffie-Hellman Grupo 2 (1024 bits) Grupo 2 (1024 bits)
Método de autenticación Clave previamente compartida Clave previamente compartida
Algoritmos de cifrado y hash 1. AES256, SHA256 1. AES256, SHA1

2. AES256, SHA1 2. AES256, SHA256
3. AES128, SHA1 3. AES128, SHA1
4. 3DES, SHA1 4. AES128, SHA256
5. 3DES, SHA1
6. 3DES, SHA256
Vigencia de SA 28.800 segundos 28.800 segundos
Parámetros de la fase 2 de IKE (modo rápido )

P RO P IEDA D P O L IC Y B A SED RO UT EB A SED
Versión de IKE IKEv1 IKEv1 e IKEv2
Algoritmos de cifrado y hash 1. AES256, SHA256 Ofertas de SA de QM del tipo

2. AES256, SHA1 routebased
3. AES128, SHA1
4. 3DES, SHA1
Vigencia de SA (tiempo) 3.600 segundos 27 000 segundos
Vigencia de SA (bytes) 102.400.000 KB 102.400.000 KB
Confidencialidad directa perfecta (PFS) No Ofertas de SA de QM del tipo

routebased
Dead Peer Detection (DPD) No compatible Compatible

Ofertas de asociación de seguridad de IPsec (SA de modo rápido de IKE) de VPN del tipo routebased
En la tabla siguiente se enumeran las ofertas de SA de IPsec (modo rápido de IKE). Las ofertas se enumeran en
el orden de preferencia en el que se presentan o se aceptan.
Puerta de enlace de Azure como iniciador
- C IF RA DO A UT EN T IC A C IÓ N GRUP O P F S
1 GCM AES256 GCM (AES256) None
2 AES256 SHA1 None
3 3DES SHA1 None
4 AES256 SHA256 None
5 AES128 SHA1 None
6 3DES SHA256 None
Puerta de enlace de Azure como respondedor
1 GCM AES256 GCM (AES256) None
2 AES256 SHA1 None
3 3DES SHA1 None
5 AES128 SHA1 None
6 3DES SHA256 None
7 DES SHA1 None
8 AES256 SHA1 1
9 AES256 SHA1 2
10 AES256 SHA1 14
11 AES128 SHA1 1
12 AES128 SHA1 2
13 AES128 SHA1 14
14 3DES SHA1 1
15 3DES SHA1 2
16 3DES SHA256 2
17 AES256 SHA256 1
18 AES256 SHA256 2
19 AES256 SHA256 14
20 AES256 SHA1 24
21 AES256 SHA256 24
23 AES128 SHA256 1
24 AES128 SHA256 2
25 AES128 SHA256 14
26 3DES SHA1 14
Puede especificar el cifrado IPsec ESP NULL con puertas de enlace de VPN RouteBased y HighPerformance. El
cifrado basado en null no proporciona protección de datos en tránsito, solo se debe usar al máximo
rendimiento y es necesaria la mínima latencia. Los clientes pueden elegir usarlo en escenarios de
comunicación entre redes virtuales o cuando se aplique el cifrado en otra parte de la solución.
Para conectividad entre locales a través de Internet, use la configuración de la puerta de enlace de VPN de
Azure predeterminada con los algoritmos de cifrado y hash de las tablas anteriores para garantizar la
seguridad de su comunicación crítica.
Problemas conocidos de compatibilidad de dispositivos

IMPORTANT
Estos son los problemas conocidos de compatibilidad entre dispositivos VPN de terceros y puertas de enlace de VPN de
Azure. El equipo de Azure está trabajando activamente con los proveedores para solucionar los problemas enumerados
aquí. Una vez que se resuelvan, esta página se actualizará con la información más reciente. Consúltela periódicamente.
16 de febrero de 2017
Dispositivos de Palo Alto Networks con una versión anterior a la 7.1.4 para VPN basada en rutas de
Azure: si usa dispositivos VPN de Palo Alto Networks con una versión de PAN-OS anterior a la 7.1.4 y
experimenta problemas de conectividad a las puertas de enlace de VPN basadas en rutas de Azure, realice los
siguientes pasos:
1. Compruebe la versión de firmware del dispositivo de Palo Alto Networks. Si su versión de PAN-OS es
anterior a la 7.1.4, actualice a esta versión.
2. En el dispositivo de Palo Alto Networks, cambie la duración de la fase 2 SA (o SA de modo rápido) a 28 800
segundos (8 horas) al conectarse a la puerta de enlace de VPN de Azure.
3. Si sigue experimentando problemas de conectividad, presente una solicitud de soporte técnico desde Azure
Portal.
Acerca de los requisitos criptográficos y las puertas
de enlace de VPN de Azure
En este artículo se explica cómo configurar puertas de enlace de VPN de Azure para satisfacer los requisitos
criptográficos para los túneles de VPN de sitio a sitio entre entornos y las conexiones entre redes virtuales
dentro de Azure.
Acerca de IKEv1 e IKEv2 para conexiones VPN de Azure

Tradicionalmente permitíamos conexiones IKEv1 solo para SKU básicas y conexiones IKEv2 para todas las SKU
de VPN Gateway que no fueran SKU básicas. Las SKU básicas solo permiten 1 conexión y, junto con otras
limitaciones, como el rendimiento, los clientes que usaban dispositivos heredados que solo admiten protocolos
IKEv1 tenían una experiencia limitada. Con el fin de mejorar la experiencia de los clientes que usan protocolos
IKEv1, ahora se permiten conexiones IKEv1 para todas las SKU de VPN Gateway, excepto SKU de nivel Básico.
Consulte SKU de VPN Gateway para más información.
Cuando las conexiones IKEv1 e IKEv2 se aplican a la misma instancia de VPN Gateway, el tránsito entre estas dos
conexiones se habilita automáticamente.
Acerca de los parámetros de la directiva de IPsec e IKE para puertas

de enlace de VPN de Azure
El protocolo IPsec e IKE estándar admite una gran variedad de algoritmos criptográficos en diversas
combinaciones. Si no solicita una combinación específica de algoritmos y parámetros criptográficos, las
instancias de Azure VPN Gateway usan un conjunto de propuestas predeterminadas. Los conjuntos de directivas
predeterminados se eligieron para maximizar la interoperabilidad con una amplia gama de dispositivos VPN de
terceros en las configuraciones predeterminadas. Como resultado, las directivas y el número de propuestas no
pueden cubrir todas las posibles combinaciones de algoritmos criptográficos disponibles y puntos fuertes clave.
Directiva predeterminada
La directiva predeterminada establecida para Azure VPN Gateway se muestra en el artículo: Acerca de los
dispositivos VPN y los parámetros de IPsec/IKE para conexiones de VPN Gateway de sitio a sitio.
Requisitos criptográficos
Para las comunicaciones que requieren determinados algoritmos o parámetros criptográficos, normalmente
debido a requisitos de seguridad o de conformidad, ahora puede configurar las instancias de Azure VPN
Gateway para usar una directiva personalizada de IPsec o IKE con determinados algoritmos criptográficos y
severidades de clave, en lugar de conjuntos de directivas predeterminadas de Azure.
Por ejemplo, las directivas del modo principal de IKEv2 para las instancias de Azure VPN Gateway usan solo el
Grupo Diffie-Hellman 2 (1024 bits), mientras que es posible que necesite especificar grupos más sólidos para su
uso en IKE, por ejemplo, el Grupo 14 (2048 bits), el Grupo 24 (grupo de MODP de 2048 bits) o ECP (grupos de
curva elíptica) de 256 o 384 bits (Grupo 19 y Grupo 20, respectivamente). También se aplican requisitos
similares a las directivas de modo rápido de IPsec.
Directiva personalizada de IPsec o IKE con puertas de enlace de VPN

de Azure
Ahora las puertas de enlace de VPN de Azure admiten directivas de IPsec o IKE personalizadas y por conexión.
Para una conexión entre sitios o entre redes virtuales puede elegir una combinación específica de algoritmos
criptográficos para IPsec e IKE con el nivel de clave deseado, como se muestra en el ejemplo siguiente:
Puede crear una directiva de IPsec o IKE y aplicarla a una conexión nueva o existente.
Flujo de trabajo
1. Cree las redes virtuales, las puertas de enlace de VPN o las puertas de enlace de red local para su topología
de conectividad, como se describe en otros documentos y procedimientos.
2. Cree una directiva IPsec/IKE.
3. Puede aplicar la directiva cuando se crea una conexión de S2S o entre redes virtuales
4. Si ya se ha creado la conexión, puede aplicar la directiva a una conexión existente o actualizarla.
P+F sobre directivas 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?
Solo se puede especificar 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.
IP SEC O IK EV2 O P C IO N ES
Cifrado IKEv2 AES256, AES192, AES128, DES3, DES
Integridad de IKEv2 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)
IMPORTANT
DHGroup2048 y 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, 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):
GRUP O DIF F IE- H EL L M A N GRUP O DH GRUP O P F S LO N GIT UD DE C L AVE
1 DHGroup1 PFS1 MODP de 768 bits

DHGroup2048
19 ECP256 ECP256 ECP de 256 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 es compatible con esta operación.
¿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.
¿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.
Pasos siguientes
Consulte Configure IPsec/IKE policy (Configuración de la directiva de IPsec o IKE) para obtener instrucciones
paso a paso acerca de cómo configurar directivas personalizadas de IPsec o IKE en una conexión.
Consulte también Conexión de varios dispositivos VPN basados en directivas para obtener más información
sobre la opción UsePolicyBasedTrafficSelectors.
Acerca de BGP con Azure VPN Gateway
En este artículo se proporciona información general de compatibilidad de BGP (Protocolo de puerta de enlace
de borde) en Azure VPN Gateway.
BGP es el protocolo de enrutamiento estándar usado habitualmente en Internet para intercambiar información
de enrutamiento y disponibilidad entre dos o más redes. Cuando se utiliza en el contexto de Azure Virtual
Network, BGP permite que instancias de Azure VPN Gateway y los dispositivos VPN locales, denominados
vecinos o pares BGP, intercambien "rutas" que comunicarán a ambas puertas de enlace la disponibilidad y la
posibilidad de que dichos prefijos pasen a través de las puertas de enlace o los enrutadores implicados. BGP
también puede permitir el enrutamiento del tránsito entre varias redes mediante la propagación de las rutas
que una puerta de enlace de BGP aprende de un par BGP a todos los demás pares BGP.
¿Por qué usar BGP?

BGP es una característica opcional que puede utilizar con puertas de enlace de VPN basadas en enrutamiento de
Azure. También debe asegurarse de que los dispositivos VPN locales admiten BGP antes de habilitar la
característica. Puede seguir usando las puertas de enlace de VPN de Azure y los dispositivos VPN locales sin
BGP. Es el equivalente a utilizar rutas estáticas (sin BGP) frente a usar el enrutamiento dinámico con BGP entre
sus redes y Azure.
Hay varias ventajas y nuevas funcionalidades con BGP:
Uso de actualizaciones de prefijo flexible y automáticas
Con BGP, solo necesita declarar un prefijo mínimo para un par BGP específico a través del túnel VPN S2S de
IPsec. Puede ser tan pequeño como un prefijo de host (/32) de la dirección IP del par BGP del dispositivo VPN
local. Puede controlar que prefijos de red local desea anunciar a Azure para permitir el acceso de Azure Virtual
Network.
También puede anunciar prefijos mayores que pueden incluir algunos de los prefijos de dirección de red virtual,
como un espacio de direcciones IP privado grande (por ejemplo, 10.0.0.0/8). Tenga en cuenta que los prefijos no
pueden ser idénticos a uno de sus prefijos de red virtual. Se rechazarán dichas rutas idénticas a sus prefijos de
red virtual.
Uso de varios túneles entre una red virtual y un sitio local con la conmutación por error automática basada en
BGP
Puede establecer varias conexiones entre la red virtual de Azure y los dispositivos VPN locales en la misma
ubicación. Esta funcionalidad proporciona varios túneles (rutas) entre las dos redes en una configuración activa-
activa. Si uno de los túneles está desconectado, se retiran las rutas correspondientes a través de BGP y el tráfico
se cambiará automáticamente a los túneles restantes.
El siguiente diagrama muestra un ejemplo sencillo de esta configuración de alta disponibilidad:
Uso del enrutamiento de tránsito entre las redes locales y varias redes virtuales de Azure
BGP permite que varias puertas de enlace obtengan y propaguen los prefijos de diferentes redes, si están
directa o indirectamente conectadas. Esto puede permitir el enrutamiento de tránsito con instancias de Azure
VPN Gateway entre sitios locales o en varias instancias de Azure Virtual Network.
El siguiente diagrama muestra un ejemplo de una topología de múltiples saltos con varias rutas que pueden
enrutar el tráfico entre las dos redes locales a través de las puertas de enlace de VPN de Azure en las redes de
Microsoft:
Preguntas más frecuentes de BGP

¿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-AzVir tualNetworkGateway y busque la propiedad bgpPeeringAddress . En Azure Portal, en la
página Configuración de puer ta 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 dirección IP de BGP de
APIPA de Azure adicional en la puerta de enlace de VPN de Azure. Azure VPN Gateway selecciona la dirección
de APIPA que se va 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 dirección IP de APIPA BGP en una puerta
de enlace de VPN de Azure, como se describe en el artículo sobre la configuración del protocolo de puerta de
enlace de borde. Especifique esta dirección 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?
IMPORTANT
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. Tendrá 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.
Pasos siguientes
Consulte Cómo configurar BGP en puertas de enlace de VPN de Azure mediante Azure Resource Manager y
PowerShell para conocer los pasos necesarios para configurar BGP en las conexiones entre sistemas locales y de
red virtual a red virtual.
Conectividad de alta disponibilidad entre locales y
de red virtual a red virtual
En este artículo se proporciona información general sobre las opciones de configuración de alta disponibilidad
para la conectividad entre locales y de red virtual a red virtual con instancias de Azure VPN Gateway.
Acerca de la redundancia de Azure VPN Gateway

Cada instancia de Azure VPN Gateway consta de dos instancias en una configuración activa-en espera. Con
cualquier mantenimiento planeado o interrupción imprevista que suceda en la instancia activa, la instancia en
modo de espera se hace cargo automáticamente (conmutación por error) y reanuda las conexiones de VPN S2S
o de red virtual a red virtual. El cambio causará una breve interrupción. Para el mantenimiento planeado, la
conectividad se debería restaurar en un plazo de 10 a 15 segundos. Para problemas no planeados, la
recuperación de la conexión llevará más tiempo, aproximadamente entre un minuto a uno y medio, en el peor
de los casos. Para las conexiones de cliente VPN P2S a la puerta de enlace, se desconectarán las conexiones P2S
y los usuarios deberán volver a conectarse desde los equipos cliente.
Conectividad entre entornos locales de alta disponibilidad

Para proporcionar mejor disponibilidad para las conexiones entre locales, hay un par de opciones disponibles:
Varios dispositivos VPN locales
Azure VPN Gateway activa-activa
Combinación de ambos
Varios dispositivos VPN locales
Puede usar varios dispositivos VPN desde la red local para conectarse a su instancia de Azure VPN Gateway,
como se muestra en el diagrama siguiente:
Esta configuración proporciona varios túneles activos desde la propia instancia de Azure VPN Gateway hacia los
dispositivos locales en la misma ubicación. Existen algunos requisitos y restricciones:
1. Debe crear varias conexiones de VPN S2S desde los dispositivos VPN a Azure. Cuando conecta varios
dispositivos VPN desde la misma red local a Azure, necesita crear una puerta de enlace de red local para
cada dispositivo VPN y una conexión desde su instancia de Azure VPN Gateway a cada puerta de enlace de
red local.
2. Las puertas de enlace de red locales correspondientes a sus dispositivos VPN deben tener direcciones IP
públicas únicas en la propiedad "GatewayIpAddress".
3. Se necesita BGP para esta configuración. Cada puerta de enlace de red local que representa un dispositivo
VPN debe tener una dirección IP de par BGP única especificada en la propiedad "BgpPeerIpAddress".
4. Los campos de la propiedad AddressPrefix en cada puerta de enlace de red local no deben superponerse.
Debe especificar la propiedad "BgpPeerIpAddress" en formato CIDR /32 en el campo AddressPrefix, por
ejemplo, 10.200.200.254/32.
5. Debería usar BGP para anunciar los mismos prefijos que los de la red local a su instancia de Azure VPN
Gateway y el tráfico se reenviará a través de estos túneles simultáneamente.
6. Debe usar el enrutamiento multidireccional de igual costo (ECMP).
7. Cada conexión cuenta para el número máximo de túneles para su instancia de Azure VPN Gateway, 10 para
las SKU Básica y Estándar, y 30 para la SKU HighPerformance.
En esta configuración, Azure VPN Gateway sigue en modo activo-en espera, por lo que se producirán el mismo
comportamiento de conmutación por error y una breve interrupción, como se ha descrito antes. Sin embargo,
esta configuración protege contra errores o interrupciones en la red local y los dispositivos VPN.
Azure VPN Gateway activa-activa
Ahora puede crear una instancia de Azure VPN Gateway en una configuración activa-activa, donde ambas
instancias de las máquinas virtuales de la puerta de enlace establecerán túneles VPN S2S al dispositivo VPN
local, como se muestra en el diagrama siguiente:
En esta configuración, cada instancia de puerta de enlace de Azure tendrá una dirección IP pública única y cada
una establecerá un túnel VPN S2S IPsec/IKE al dispositivo VPN local especificado en la conexión y la puerta de
enlace de red local. Tenga en cuenta que los túneles VPN son realmente parte de la misma conexión. Todavía
necesitará configurar el dispositivo VPN local para que acepte o establezca dos túneles VPN S2S a esas dos
direcciones IP públicas de la instancia de Azure VPN Gateway.
Dado que las instancias de puerta de enlace de Azure están en una configuración activa-activa, el tráfico desde
su instancia de Azure Virtual Network hasta su red local se enrutará a través de ambos túneles
simultáneamente, aunque el dispositivo VPN local pueda favorecer un túnel sobre el otro. Aun así, tenga en
cuenta que el mismo flujo TCP o UDP atravesará siempre el mismo túnel o ruta, a menos que se produzca un
evento de mantenimiento en una de las instancias.
Cuando se produce un mantenimiento planeado o un evento imprevisto en una instancia de puerta de enlace,
se desconectará el túnel IPsec desde esa instancia hacia el dispositivo VPN local. Las rutas correspondientes en
los dispositivos VPN se deben eliminar o retirar automáticamente para que el tráfico cambie al otro túnel IPsec
activo. En el lado de Azure, el cambio se realizará automáticamente de la instancia afectada a la activa.
Redundancia doble: puertas de enlace de VPN activas-activas para redes locales y Azure
La opción más confiable es combinar las puertas de enlace activas-activas tanto en su red como en Azure, como
se muestra en el diagrama siguiente.
Aquí se crea y configura la instancia de Azure VPN Gateway con una configuración activa-activa, y se crean dos
puertas de enlace de red locales y dos conexiones para los dos dispositivos VPN locales como se describió
antes. El resultado es una conectividad de malla completa con 4 túneles IPsec entre su instancia de Azure Virtual
Network y la red local.
Todas las puertas de enlace y los túneles están activos desde el lado de Azure, por lo que el tráfico se reparte
entre los 4 túneles simultáneamente, aunque cada flujo TCP o UDP seguirá de nuevo el mismo túnel o ruta
desde el lado de Azure. Aunque al repartir el tráfico podría notar un rendimiento algo mejor en los túneles IPsec,
el objetivo principal de esta configuración es la alta disponibilidad. Además, dada la naturaleza estadística de
este método, es difícil proporcionar la medida en que las diferentes situaciones de tráfico de aplicaciones
afectarán al rendimiento agregado.
Esta topología requerirá dos puertas de enlace de red locales y dos conexiones para admitir el par de
dispositivos VPN locales; también se necesita BGP para permitir las dos conexiones a la misma red local. Estos
requisitos son iguales que los anteriores.
Conectividad de alta disponibilidad de red virtual a red virtual a través

de instancias de Azure VPN Gateway
También se puede aplicar la misma configuración activa-activa a las conexiones de red virtual a red virtual de
Azure. Puede crear instancias de Azure VPN Gateway activa-activa para ambas redes virtuales y conectarlas
entre sí para formar la misma conectividad de malla completa con 4 túneles entre las dos redes virtuales, como
se muestra en el diagrama siguiente:
Esto garantiza que siempre haya un par de túneles entre las dos redes virtuales para cualquier evento de
mantenimiento planeado, por lo que se proporciona una disponibilidad aún mejor. A pesar de que la misma
topología para conectividad entre locales requiere dos conexiones, la topología de red virtual a red virtual
mostrada antes solo necesitará una conexión para cada puerta de enlace. Además, BGP es opcional, a menos
que sea necesario enrutar el tránsito por la conexión de red virtual a red virtual.
Pasos siguientes
Consulte Configuración activa-activa de puertas de enlace de VPN para conexiones entre locales y de red virtual
a red virtual para ver los pasos para configurar de modo activo-activo conexiones entre locales y de red virtual a
red virtual.
Acerca de las conexiones VPN de punto a sitio
cliente. Esta solución resulta útil para los teletrabajadores que deseen conectarse a redes virtuales de Azure
desde una ubicación remota, por ejemplo, desde casa o un congreso. La conexión VPN de punto a sitio también
es una solución útil en comparación con la conexión VPN de sitio a sitio cuando solo necesitan conectarse a la
red virtual algunos clientes. Este artículo se aplica al modelo de implementación de Resource Manager.
¿Qué protocolo utiliza P2S?

La conexión VPN de punto a sitio usa uno de los siguientes protocolos:
Protocolo OpenVPN® , un protocolo VPN basado en SSL/TLS. Una solución de VPN basada en TLS
puede penetrar firewalls, puesto que la mayoría de ellos abre el puerto TCP 443 saliente, que usa TLS.
OpenVPN puede utilizarse para la conexión desde dispositivos Android, iOS (11.0 y versiones
posteriores), Windows, Linux y Mac (OSX 10.13 y versiones posteriores).
El protocolo de túnel de sockets seguro (SSTP), que es un protocolo VPN propio basado en TLS. Una
solución de VPN basada en TLS puede penetrar firewalls, puesto que la mayoría de ellos abre el puerto
TCP 443 saliente, que usa TLS. El protocolo SSTP solo se admite en dispositivos Windows. Azure es
compatible con todas las versiones de Windows que tienen SSTP (Windows 7 y versiones posteriores).
La conexión VPN IKEv2, una solución de VPN con protocolo de seguridad de Internet basada en
estándares. La conexión VPN IKEv2 puede utilizarse para la conexión desde dispositivos Mac (versión de
OSX 10.11 y versiones posteriores).
NOTE
IKEv2 y OpenVPN para P2S están disponibles para el modelo de implementación de Resource Manager. No están
disponibles para el modelo de implementación clásico.
¿Cómo se autentican los clientes VPN de punto a sitio?

Para que Azure acepte una conexión VPN de punto a sitio, el usuario primero debe autenticarse. Azure ofrece
dos mecanismos para autenticar los usuarios que se conectan.
Autenticación con certificados nativos de Azure
Con la autenticación con certificados nativos de Azure, para autenticar el usuario que se conecta, se usa un
certificado de cliente presente en el dispositivo. Los certificados de cliente se generan a partir de un certificado
raíz de confianza y se instalan en cada equipo cliente. Puede, o bien, usar un certificado raíz generado mediante
una solución empresarial, o bien, generar un certificado autofirmado.
La validación del certificado de cliente se realiza mediante la puerta de enlace de VPN durante el
establecimiento de la conexión VPN P2S. El certificado raíz es necesario para la validación y se debe cargar en
Azure.
Autenticación mediante Azure Active Directory de forma nativa
La autenticación mediante Azure AD permite a los usuarios conectarse a Azure con sus credenciales de
Azure Active Directory. La autenticación de Azure AD nativa solo se admite para el protocolo OpenVPN y
Windows 10, y requiere el uso del Cliente VPN de Azure.
Con la autenticación de Azure AD nativa, puede aprovechar el acceso condicional de Azure AD, así como las
características de Multi-Factor Authentication (MFA) para VPN.
En un nivel alto, para configurar la autenticación de Azure AD es preciso seguir estos pasos:
1. Configurar un inquilino de Azure AD
2. Habilitar la autenticación de Azure AD en la puerta de enlace
3. Descargar y configurar el Cliente VPN de Azure
Autenticación mediante el servidor de dominio de Active Directory (AD)
La autenticación de dominio de AD permite a los usuarios conectarse a Azure con sus credenciales de dominio
de la organización. Requiere un servidor RADIUS que se integre con el servidor de AD. Las organizaciones
también pueden aprovechar las implementaciones existentes de RADIUS. El servidor RADIUS puede
implementarse de forma local o en la red virtual de Azure. Durante la autenticación, la puerta de enlace de VPN
de Azure actúa como acceso directo y reenvía los mensajes de autenticación entre el servidor RADIUS y el
dispositivo que se conecta. Por lo tanto, la disponibilidad de la puerta de enlace del servidor RADIUS es
importante. Si el servidor RADIUS está presente de forma local, se necesita una conexión VPN S2S de Azure en
el sitio local para la disponibilidad. El servidor RADIUS también se integra con los servicios de certificados de
AD. Esto le permite usar el servidor RADIUS y la implementación de certificados de empresa para la
autenticación de certificados de P2S como alternativa a la autenticación de certificados de Azure. La ventaja es
que no es necesario cargar certificados raíz y revocados en Azure.
Los servidores RADIUS también se integran con otros sistemas de identidad externos. Esto abre una gran
cantidad de opciones de autenticación para VPN P2S, incluidas las opciones de multifactor.
¿Cuáles son los requisitos de configuración del cliente?

NOTE
Para los clientes de Windows, debe tener derechos de administrador en el dispositivo de cliente para poder iniciar la
conexión VPN desde el dispositivo cliente en Azure.
Los usuarios utilizan los clientes VPN nativos en los dispositivos Windows y Mac para P2S. Azure proporciona
un archivo zip de configuración de cliente VPN con la configuración que necesitan estos clientes nativos para
conectarse a Azure.
Para los dispositivos Windows, la configuración de cliente VPN consta de un paquete de instalación que los
usuarios instalan en sus dispositivos.
Para los dispositivos Mac, consta del archivo mobileconfig que los usuarios instalan en sus dispositivos.
El archivo zip también proporciona los valores de algunas de las opciones de configuración importantes del
lado de Azure que puede usar para crear su propio perfil para estos dispositivos. Algunos de los valores
incluyen la dirección de puerta de enlace de VPN, los tipos de túnel configurados, las rutas y el certificado raíz
para la validación de la puerta de enlace.
NOTE
solo compatible con TLS 1.2. Esto solo afecta a las conexiones de punto a a sitio, las conexiones de sitio a sitio no se verán
afectadas. Si usa TLS para VPN de punto a sitio en clientes de Windows 10, no necesita hacer nada. Si usa TLS para
conexiones de punto a sitio en clientes de Windows 7 y Windows 8, consulte las preguntas más frecuentes sobre VPN
Gateway para obtener instrucciones de actualización.
¿Qué SKU de puerta de enlace admite VPN de P2S?

P RUEB A S

n1
n1
n1
n1 Z
n1 Z
n1 Z
n2
n2
P RUEB A S
n2

n2 10000
n2 Z
n2 Z
n2 Z

n2 Z 10000
más bajo.
PA Q UET ES P O R

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
Para obtener recomendaciones de la SKU de puerta de enlace, consulte Acerca de la configuración de VPN
Gateway.
NOTE
La SKU básica no admite la autenticación de IKEv2 o RADIUS.
¿Qué directivas IPsec/IKE se configuran en las puertas de enlace de

VPN de P2S?
IKEv2
C IF RA DO IN T EGRIDA D P RF GRUP O DH
GCM_AES256 GCM_AES256 SHA384 GROUP_24
GCM_AES256 GCM_AES256 SHA384 GROUP_ECP384

AES256 SHA384 SHA384 GROUP_24
AES256 SHA384 SHA384 GROUP_ECP384
IPsec
C IF RA DO IN T EGRIDA D GRUP O P F S
GCM_AES256 GCM_AES256 GROUP_NONE
GCM_AES256 GCM_AES256 GROUP_24
GCM_AES256 GCM_AES256 GROUP_ECP384
AES256 SHA256 GROUP_NONE
AES256 SHA256 GROUP_24
AES256 SHA256 GROUP_ECP384
¿Qué directivas TLS se configuran en las puertas de enlace de VPN

para P2S?
TLS
DIREC T IVA S
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
¿Cómo se puede configurar una conexión de P2S?

En una configuración de P2S es necesario realizar unos pocos pasos específicos. En los siguientes artículos
encontrará los pasos necesarios para realizar una configuración de P2S, así como vínculos para configurar los
dispositivos de cliente VPN:
RADIUS)
Configuración de OpenVPN
Procedimiento para quitar la configuración de una conexión P2S
Para conocer los pasos, consulte las preguntas más frecuentes a continuación.
Preguntas más frecuentes acerca de la autenticación de certificado

nativa de Azure
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

No.
OpenSSL:
Preguntas más frecuentes acerca de la autenticación RADIUS
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

Sí, se admiten.
Pasos siguientes
RADIUS)
Información sobre el enrutamiento de VPN de
punto a sitio
Este artículo lo ayudará a comprender el comportamiento del enrutamiento de VPN de punto a sitio de Azure. El
comportamiento del enrutamiento de VPN de punto a sitio depende del SO cliente, el protocolo que se usa para
la conexión de VPN y cómo las redes virtuales se conectan entre sí.
Actualmente, Azure admite dos protocolos para el acceso remoto, IKEv2 y SSTP. El protocolo IKEv2 es compatible
con muchos sistemas operativos cliente, como Windows, Linux, macOS, iOS y Android. El protocolo SSTP solo es
compatible con Windows. Si realiza un cambio en la topología de la red y tiene clientes VPN de Windows, el
paquete de cliente VPN para clientes de Windows se debe descargar e instalar nuevamente para que los
cambios se apliquen en el cliente.
NOTE
Este artículo solo se aplica al protocolo IKEv2.
Acerca de los diagramas

Hay varios diagramas distintos en este artículo. Cada sección muestra una configuración o topología distinta. En
este artículo, las conexiones de sitio a sitio (S2S) y las conexiones de red virtual a red virtual funcionan del
mismo modo, debido a que ambas son túneles IPsec. Todas las puertas de enlace de VPN se basan en rutas.
Una red virtual aislada

La conexión de puerta de enlace de VPN de punto a sitio en este ejemplo es para una red virtual que no está
conectada ni emparejada con ninguna otra red virtual (VNet1). En este ejemplo, los clientes pueden acceder a
VNet1.
Espacio de direcciones
VNet1: 10.1.0.0/16
Rutas agregadas
Rutas agregadas a clientes Windows: 10.1.0.0/16, 192.168.0.0/24
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 192.168.0.0/24
Acceso
Los clientes Windows pueden acceder a VNet1
Los clientes no Windows pueden acceder a VNet1
Varias redes virtuales emparejadas

En este ejemplo, la conexión de puerta de enlace de VPN de punto a sitio es para VNet1. VNet1 está emparejada
con VNet2. VNet 2 está emparejada con VNet3. VNet1 está emparejada con VNet4. No hay emparejamiento
directo entre VNet1 y VNet3. VNet1 tiene habilitado "Permitir tránsito de puerta de enlace" y VNet2 y VNet4
tienen "Usar puertas de enlace remotas".
Los clientes que usan Windows pueden acceder directamente a redes virtuales emparejadas, pero el cliente VPN
se debe descargar de nuevo si se hace algún cambio en el emparejamiento de VNet o en la topología de red. Los
clientes no Windows pueden acceder directamente a las redes virtuales emparejadas. El acceso no es transitivo
y está limitado solo a las redes virtuales emparejadas directamente.
Espacio de direcciones:
VNet1: 10.1.0.0/16
VNet2: 10.2.0.0/16
VNet3: 10.3.0.0/16
VNet4: 10.4.0.0/16
Rutas agregadas
Rutas agregadas a clientes Windows: 10.1.0.0/16, 10.2.0.0/16, 10.4.0.0/16, 192.168.0.0/24
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.2.0.0/16, 10.4.0.0/16, 192.168.0.0/24
Acceso
Los clientes Windows pueden acceder a VNet1, VNet2 y VNet4, pero el cliente de VPN se debe descargar
de nuevo para que cualquier cambio en la topología surta efecto.
Los clientes no Windows pueden acceder a VNet1, VNet2 y VNet4.
Varias redes virtuales conectadas mediante VPN de sitio a sitio

En este ejemplo, la conexión de puerta de enlace de VPN de punto a sitio es para VNet1. VNet1 se conecta a
VNet2 mediante una conexión VPN de sitio a sitio. VNet2 se conecta a VNet3 mediante una conexión VPN de
sitio a sitio. No hay emparejamiento directo ni conexión VPN de sitio a sitio entre VNet1 y VNet3. Las
conexiones de sitio a sitio no ejecutan BGP para el enrutamiento.
Los clientes que usan Windows o cualquier otro SO compatible solo pueden acceder a VNet1. Para acceder a
otras redes virtuales, se debe usar BGP.
VNet1: 10.1.0.0/16
VNet2: 10.2.0.0/16
VNet3: 10.3.0.0/16
Rutas agregadas
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.2.0.0/16, 192.168.0.0/24
Acceso
Los clientes Windows solo pueden acceder a VNet1
Los clientes no Windows solo pueden acceder a VNet1
Varias redes virtuales conectadas mediante VPN de sitio a sitio (BGP)

sitio a sitio. No hay emparejamiento directo ni conexión VPN de sitio a sitio entre VNet1 y VNet3. Las
conexiones de sitio a sitio ejecutan BGP para el enrutamiento.
Los clientes que usan Windows o cualquier otro SO compatible pueden acceder a todas las redes virtuales que
están conectadas mediante una conexión VPN de sitio a sitio, pero las rutas a las redes virtuales conectadas se
deben agregar manualmente a los clientes Windows.
VNet1: 10.1.0.0/16
VNet2: 10.2.0.0/16
VNet3: 10.3.0.0/16
Rutas agregadas
Rutas agregadas a clientes Windows: 10.1.0.0/16
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 192.168.0.0/24
Acceso
Los clientes Windows pueden acceder a VNet1, VNet2 y VNet3, pero las rutas a VNet2 y VNet3 se
deberán agregar manualmente.
Los clientes no Windows pueden acceder a VNet1, VNet2 y VNet3.
Una red virtual y una sucursal

En este ejemplo, la conexión de puerta de enlace de VPN de punto a sitio es para VNet1. VNet1 no está
conectada ni emparejada con ninguna otra red virtual, pero sí está conectada a un sitio local a través de una
conexión VPN de sitio a sitio que no ejecuta BGP.
Los clientes Windows y no Windows solo pueden acceder a VNet1.
VNet1: 10.1.0.0/16
Site1: 10.101.0.0/16
Rutas agregadas
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 192.168.0.0/24
Acceso
Una red virtual y una sucursal (BGP)

En este ejemplo, la conexión de puerta de enlace de VPN de punto a sitio es para VNet1. VNet1 no está
conectada ni emparejada con ninguna otra red virtual, pero sí está conectada a un sitio local (Site1) a través de
una conexión VPN de sitio a sitio que ejecuta BGP.
Los clientes Windows pueden acceder a la red virtual y a la sucursal (Site1), pero las rutas a Site1 se deben
agregar manualmente al cliente. Los clientes no Windows pueden acceder a la red virtual, así como a la sucursal
local.
VNet1: 10.1.0.0/16
Site1: 10.101.0.0/16
Rutas agregadas
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.101.0.0/16, 192.168.0.0/24
Acceso
Los clientes Windows pueden acceder a VNet1 y a Site1, pero las rutas a Site1 se deberán agregar
manualmente.
Los clientes no Windows pueden acceder a VNet1 y Site1.
Varias redes virtual conectadas mediante sitio a sitio y una sucursal

sitio a sitio. No hay emparejamiento directo ni túnel VPN de sitio a sitio entre las redes VNet1 y VNet3. VNet3 se
conecta a una sucursal (Site1) mediante una conexión VPN de sitio a sitio. Las conexiones VPN no ejecutan BGP.
Todo los clientes pueden acceder solo a VNet1.
VNet1: 10.1.0.0/16
VNet2: 10.2.0.0/16
VNet3: 10.3.0.0/16
Site1: 10.101.0.0/16
Rutas agregadas
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 10.101.0.0/16,
192.168.0.0/24
Acceso
Varias redes virtual conectadas mediante sitio a sitio y una sucursal

(BGP)
sitio a sitio. No hay emparejamiento directo ni túnel VPN de sitio a sitio entre las redes VNet1 y VNet3. VNet3 se
conecta a una sucursal (Site1) mediante una conexión VPN de sitio a sitio. Las conexiones VPN ejecutan BGP.
Los clientes que usan Windows pueden acceder a las redes virtuales y los sitios que están conectados mediante
una conexión VPN de sitio a sitio, pero las rutas a VNet2, VNet3 y Site1 se deben agregar manualmente al
cliente. Los clientes no Windows pueden acceder a las redes virtuales y los sitios que están conectados mediante
una conexión VPN de sitio a sitio sin intervención manual de ningún tipo. El acceso es transitivo y los clientes
pueden acceder a los recursos de todas las redes virtuales y sitios (locales) conectados.
VNet1: 10.1.0.0/16
VNet2: 10.2.0.0/16
VNet3: 10.3.0.0/16
Site1: 10.101.0.0/16
Rutas agregadas
Rutas agregadas a clientes no Windows: 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16, 10.101.0.0/16,
192.168.0.0/24
Acceso
Los clientes Windows pueden acceder a VNet1, VNet2, VNet3 y Site1, pero las rutas a VNet2, VNet3 y
Site1 se deben agregar manualmente al cliente.
Los clientes no Windows pueden acceder a VNet1, VNet2, VNet3 y Site1.
Pasos siguientes
Consulte el artículo sobre la creación de una VPN de punto a sitio con Azure Portal para empezar a crear la VPN
de punto a sitio.
Acerca de las puertas de enlace de red virtual con
redundancia de zona en Azure Availability Zones
Puede implementar puertas de enlace de VPN Gateway y ExpressRoute en Azure Availability Zones. Esto aporta
una mayor disponibilidad, escalabilidad y resistencia a las puertas de enlace de red virtual. Implementar puertas
de enlace en Azure Availability Zones separa de forma física y lógica las puertas de enlace dentro de una región,
y protege la conectividad de red local en Azure de errores de nivel de zona.
Para implementar automáticamente las puertas de enlace de red virtual en distintas zonas de disponibilidad,
puede usar puertas de enlace de red virtual con redundancia de zona. Las puertas de enlace con redundancia de
zona permiten aprovechar la resistencia de zona para tener acceso a los servicios de Azure críticos para la
misión y escalables.
Puertas de enlace zonales

Para implementar puertas de enlace en una zona específica, puede usar puertas de enlace zonales. Al
implementar una puerta de enlace zonal, todas las instancias de la puerta de enlace se implementan en la
misma zona de disponibilidad.
Las puertas de enlace zonales y con redundancia de zona están disponibles como nuevas SKU de puerta de
enlace. Hemos agregado nuevas SKU de puerta de enlace de red virtual en las regiones de Azure AZ. Estas SKU
son similares a las SKU correspondientes existentes para ExpressRoute y VPN Gateway, salvo que son
específicas para puertas de enlace zonales y con redundancia de zona. Puede identificar estas SKU mediante
"AZ" en el nombre de la SKU.
Para obtener información sobre las SKU de puerta de enlace, consulte SKU de puerta de enlace de VPN y SKU de
puerta de enlace de ExpressRoute.
SKU de IP pública
Las puertas de enlace con redundancia de zona y las puertas de enlace zonales se basan en el recurso de IP
pública de Azure SKU Estándar. La configuración del recurso de IP pública de Azure determina si la puerta de
enlace que se implementa tiene redundancia de zona o es zonal. Si crea un recurso de IP pública con una SKU
Básica, la puerta de enlace no tendrá redundancia de zona y los recursos de puerta de enlace serán regionales.
Cuando se crea una dirección IP pública con la SKU de IP pública Estándar sin especificar una zona, el
comportamiento es diferente según si la puerta de enlace es una puerta de enlace de VPN o una puerta de
enlace de ExpressRoute.
En el caso de las puertas de enlace de VPN, las dos instancias de la puerta de enlace se implementarán en
dos de estas tres zonas para proporcionar redundancia de zona.
En el caso de las puertas de enlace de ExpressRoute, como puede haber más de dos instancias, la puerta de
enlace puede abarcar las tres zonas.
Puertas de enlace zonales
Cuando se crea una dirección IP pública con la SKU de IP pública Estándar y se especifica la zona (1, 2 o 3),
todas las instancias de la puerta de enlace se implementarán en la misma zona.
Puertas de enlace regionales
Cuando se crea una dirección IP pública con la SKU de IP pública Básica , la puerta de enlace se implementa
como una puerta de enlace regional y no se agrega redundancia de zona a la puerta de enlace.
P+F
¿Qué cambiará cuando proceda a implementar estas SKU nuevas?
Desde su perspectiva, puede implementar puertas de enlace con redundancia de zona. Esto significa que todas
las instancias de las puertas de enlace se implementarán en distintas zonas de disponibilidad de Azure, y cada
zona de disponibilidad es un dominio de error y actualización diferente. Por ello, las puertas de enlace son más
confiables, disponibles y resistentes a los errores de la zona.
¿Puedo usar Azure Portal?
Sí, puede usar Azure Portal para implementar las nuevas SKU. Sin embargo, verá estas nuevas SKU solo en las
regiones de Azure que tengan Azure Availability Zones.
¿Qué regiones están disponibles para usar las nuevas SKU?
Las nuevas SKU están disponibles en las regiones de Azure que tienen Azure Availability Zones: las regiones
Centro de EE. UU., Centro de Francia, Norte de Europa, Oeste de Europa, Oeste de EE. UU. 2, Este de EE. UU., Este
de EE. UU. 2, Sudeste de Asia, Este de Japón y Sur de Reino Unido. En el futuro, las puertas de enlace con
redundancia de zona estarán disponibles en otras regiones públicas de Azure.
¿Puedo convertir/migrar/actualizar mis puertas de enlace de red virtual existentes en puertas de enlace
zonales o con redundancia de zona?
Actualmente no se permite migrar las puertas de enlace de red virtual existentes a puertas de enlace zonales o
con redundancia de zona. Sin embargo, puede eliminar la puerta de enlace existente y volver a crear una puerta
de enlace zonal o con redundancia de zona.
¿Puedo implementar puertas de enlace de VPN y ExpressRoute en la misma red virtual?
Se admite la coexistencia de puertas de enlace de VPN y ExpressRoute en la misma red virtual. Sin embargo, le
recomendamos que reserve un intervalo de direcciones IP /27 para la subred de puerta de enlace.
Pasos siguientes
Crear una puerta de enlace de red virtual con redundancia de zona
Línea de base de seguridad de Azure para VPN
Gateway
Esta línea de base de seguridad aplica las instrucciones de Azure Security Benchmark, versión 1.0 a VPN
Gateway. Azure Security Benchmark proporciona recomendaciones sobre cómo puede proteger sus soluciones
de nube en Azure. El contenido se agrupa por medio de los controles de seguridad definidos por Azure
Security Benchmark y las directrices relacionadas aplicables a VPN Gateway. Se han excluido los controles no
aplicables a VPN Gateway.
Para ver cómo VPN Gateway se asigna por completo a Azure Security Benchmark, consulte el archivo de
asignación de base de referencia de seguridad de VPN Gateway completo.
Seguridad de las redes

Para obtener más información, consulte Azure Security Benchmark: Seguridad de redes.
1.1: Protección de los recursos de Azure dentro de las redes virtuales
Guía : cuando trabaje con subredes de VPN Gateway, evite asociar un grupo de seguridad de red (NSG) a la
subred de la puerta de enlace. La asociación de un grupo de seguridad de red a esta subred puede causar que la
puerta de enlace de VPN deje de funcionar como cabría esperar. Sin embargo, habilite grupos de seguridad de
red para otras subredes que no sean de VPN Gateway de su instancia de Virtual Network.
Creación de un NSG con una configuración de seguridad
Creación de una instancia de VPN Gateway basada en rutas mediante Azure Portal
Super visión de Azure Security Center : Sí
Responsabilidad : Customer
1.2: Supervisión y registro de la configuración y el tráfico de redes virtuales, subredes e interfaces de red
Guía : Use Azure Security Center y siga las recomendaciones de protección de redes para ayudar a proteger sus
recursos de red en Azure.
Descripción de la seguridad de red proporcionada por Azure Security Center
1.5: Registro de los paquetes de red
Guía : habilite la captura de paquetes de VPN Gateway en la puerta de enlace o en una conexión específica
según sus requisitos.
Configuración de captura de paquetes para VPN Gateways
Super visión de Azure Security Center : no disponible actualmente
1.9: Mantenga las configuraciones de seguridad estándar para dispositivos de red
Guía : Defina e implemente configuraciones de seguridad estándar para los recursos de red con Azure Policy.
También puede usar Azure Blueprints para simplificar las implementaciones de Azure a gran escala mediante el
empaquetado de artefactos de entorno clave, como plantillas de Azure Resource Manager, asignaciones de
RBAC de Azure y asignaciones de Azure Policy, en una única definición de un plano técnico. Puede aplicar el
plano técnico a nuevas suscripciones o a suscripciones ya existentes y ajustar el control y la administración a
través del control de versiones.
Configuración y administración de Azure Policy
Ejemplos de Azure Policy para redes
Creación de un plano técnico de Azure
Super visión de Azure Security Center : No aplicable
1.11: Use herramientas automatizadas para supervisar las configuraciones de recursos de red y detectar
cambios
Guía : use el registro de actividad de Azure para supervisar las configuraciones de recursos y detectar cambios
en los recursos de redes virtuales. Cree alertas en Azure Monitor que se desencadenarán cuando se produzcan
cambios en los recursos críticos relacionados con su instancia de VPN Gateway.
Visualización y recuperación de eventos del registro de actividad de Azure
Creación de alertas en Azure Monitor
Registro y supervisión
Para obtener más información, consulte Azure Security Benchmark: registro y supervisión.
2.2: Configuración de la administración central de registros de seguridad
Guía : ingiera registros de actividad y diagnóstico a través de Azure Monitor para agregar datos de seguridad
generados por recursos de red como sus recursos de VPN Gateway. Use Azure Monitor para realizar consultas y
análisis de los datos de registro, y utilice cuentas de Azure Storage para el almacenamiento de archivos a largo
plazo de estos registros.
Como alternativa, puede habilitar e incorporar datos en Azure Sentinel o en una herramienta SIEM de terceros.
Configuración de alertas de eventos de registro de diagnóstico de VPN Gateway
Incorporación de Azure Sentinel
Recopilación de registros y métricas de plataforma con Azure Monitor
Introducción a Azure Monitor e integración con herramienta SIEM de terceros
2.3: Habilitación del registro de auditoría para recursos de Azure
Guía : habilite Configuración de diagnóstico en los recursos de VPN Gateway para poder acceder a los registros
de auditoría, seguridad y diagnóstico. Los registros de actividad, que están disponibles automáticamente,
incluyen el origen del evento, la fecha, el usuario, la marca de tiempo, las direcciones de origen y de destino, y
otros elementos útiles.
Recopilación de registros y métricas de plataforma con Azure Monitor
Descripción del registro y de los distintos tipos de registro de Azure
2.5: Configuración de la retención del almacenamiento de registros de seguridad
Guía : En Azure Monitor, establezca el período de retención del área de trabajo de Log Analytics de acuerdo con
la normativa de cumplimiento de su organización. Use cuentas de Azure Storage para el almacenamiento de
archivos y a largo plazo.
Cambio del período de retención de datos en Log Analytics
Configuración de la directiva de retención para los registros de la cuenta de Azure Storage
2.6: Supervisión y revisión de registros
Guía : Analice y supervise los registros en busca de comportamientos anómalos y revise los resultados con
regularidad. Use Azure Monitor y un área de trabajo de Log Analytics para revisar los registros y realizar
consultas en los datos de dichos registros.
También puede habilitar e incorporar datos en Azure Sentinel o en una herramienta SIEM de terceros.
Introducción a las consultas de Log Analytics
Procedimiento para realizar consultas personalizadas en Azure Monitor
2.7: Habilitación de alertas para actividades anómalas
Instrucciones : Use Azure Security Center con el área de trabajo de Log Analytics para la supervisión y alertas
sobre actividades anómalas que se encuentran en los registros y eventos de seguridad.
Como alternativa, puede habilitar e incorporar datos en Azure Sentinel.
Administración de alertas de seguridad en Azure Security Center
Alertas sobre datos de registro de Log Analytics
2.9: Habilitación del registro de consultas DNS
Guía : implemente una solución de terceros de Azure Marketplace para solucionar el registro DNS según los
requisitos de su organización.
Control de identidades y acceso

Para obtener más información, consulte Azure Security Benchmark: Identidad y control de acceso.
3.1: Mantenga un inventario de cuentas administrativas
Guía : El control de acceso basado en roles de Azure (RBAC de Azure) permite administrar el acceso a los
recursos de Azure a través de las asignaciones de roles. Puede asignar estos roles a usuarios, grupos de
entidades de servicio e identidades administradas. Hay roles integrados predefinidos para determinados
recursos, y estos roles se pueden inventariar o consultar mediante herramientas como la CLI de Azure,
Azure PowerShell o el Azure Portal.
Obtención de un rol de directorio en Azure AD con PowerShell
Obtención de los miembros de un rol de directorio en Azure AD con PowerShell
3.3: Use cuentas administrativas dedicadas
Guía : Cree procedimientos operativos estándar en torno al uso de cuentas administrativas dedicadas.
También puede habilitar el acceso Just-in-Time mediante Azure AD Privileged Identity Management y Azure
Resource Manager.
Más información acerca de Privileged Identity Management
3.4: Uso del inicio de sesión único (SSO ) de Azure Active Directory
Instrucciones : Siempre que sea posible, use el SSO de Azure Active Directory en lugar de configurar
credenciales independientes individuales por servicio. Use las recomendaciones de identidades y acceso de
Azure Security Center.
Descripción del SSO con Azure AD
3.5: Uso de la autenticación multifactor para todo el acceso basado en Azure Active Directory
Instrucciones : Habilite la MFA de Azure AD y siga las recomendaciones de administración de identidades y
acceso de Azure Security Center.
Procedimiento para habilitar la MFA en Azure
Supervisión de la identidad y el acceso en Azure Security Center
3.6: Uso de estaciones de trabajo seguras y administradas por Azure para realizar tareas administrativas
Instrucciones : use una estación de trabajo segura y administrada por Azure (también conocida como una
estación de trabajo de acceso con privilegios o PAW) para las tareas administrativas que requieren privilegios
elevados.
Descripción de las estaciones de trabajo seguras administradas por Azure
Cómo habilitar MFA de Azure AD
3.7: Registro y alerta de actividades sospechosas desde cuentas administrativas
Guía : use la característica de supervisión y los informes de seguridad de Azure Active Directory para detectar
cuando se producen actividades sospechosas o no seguras en el entorno. Use Azure Security Center para
supervisar la actividad de identidad y acceso.
Procedimiento para identificar usuarios de Azure AD marcados por una actividad de riesgo
Supervisión de la actividad de identidad y acceso de los usuarios en Azure Security Center
3.8: Administre los recursos de Azure solo desde ubicaciones aprobadas
Guía : use ubicaciones con nombre de Azure AD para permitir el acceso solo desde agrupaciones lógicas
específicas de intervalos de direcciones IP o países o regiones.
Configuración de ubicaciones con nombre de Azure AD
3.9: Uso de Azure Active Directory
Instrucciones : Use Azure Active Directory (AD) como sistema central de autenticación y autorización. Azure AD
protege los datos mediante un cifrado seguro para los datos en reposo y en tránsito. Azure AD también cifra con
sal, convierte en hash y almacena de forma segura las credenciales de los usuarios.
Procedimiento para crear y configurar una instancia de Azure AD
3.10: Revise y concilie regularmente el acceso de los usuarios
Instrucciones : Azure Active Directory (Azure AD) proporciona registros para ayudar a descubrir cuentas
obsoletas. Además, use las revisiones de acceso e identidades de Azure AD para administrar de forma eficiente
las pertenencias a grupos, el acceso a las aplicaciones empresariales y las asignaciones de roles. El acceso de los
usuarios se puede revisar de forma periódica para asegurarse de que solo las personas adecuadas tengan
acceso continuado.
Descripción de los informes de Azure AD
Procedimiento para usar las revisiones de acceso e identidades de Azure AD
3.11: Supervisión de los intentos de acceso a credenciales desactivadas
Guía : tiene acceso a los orígenes de registro de eventos de actividad de inicio de sesión, auditoría y riesgo de
Azure AD, que permiten la integración con cualquier herramienta SIEM o de supervisión.
Para simplificar este proceso, cree una configuración de diagnóstico para las cuentas de usuario de Azure AD y
envíe los registros de auditoría y los registros de inicio de sesión a un área de trabajo de Log Analytics. Puede
configurar las alertas deseadas en el área de trabajo de Log Analytics.
Integración de los registros de actividad de Azure en Azure Monitor
3.12: Alerte de las desviaciones de comportamiento en los inicios de sesión de las cuentas
Guía : use las características de Azure Active Directory Identity Protection para configurar las respuestas
automatizadas a las acciones sospechosas detectadas relacionadas con las identidades de los usuarios. También
puede hacer que Azure Sentinel ingiera los datos para investigarlos más.
Visualización de los inicios de sesión de riesgo de Azure AD
Configuración y habilitación de las directivas de riesgo de protección de identidad
Protección de los datos

Para obtener más información, consulte Azure Security Benchmark: Protección de datos.
4.2: Aislamiento de los sistemas que almacenan o procesan información confidencial
Guía : las instancias de VPN Gateway son instancias de VM dedicadas para cada red virtual de cliente.
Implemente el aislamiento mediante redes virtuales, suscripciones y grupos de administración independientes
para dominios de seguridad individuales, como el tipo de entorno y el nivel de confidencialidad de los datos.
Puede restringir el nivel de acceso a los recursos de Azure que necesitan sus aplicaciones y entornos
empresariales. Puede controlar el acceso a los recursos de Azure mediante el control de acceso basado en rol de
Azure (Azure RBAC).
Creación de suscripciones adicionales de Azure
Creación de grupos de administración
Creación y uso de etiquetas
4.3: Supervisión y bloqueo de una transferencia no autorizada de información confidencial
Guía : Use una solución de terceros de Azure Marketplace en los perímetros de la red para supervisar la
transferencia no autorizada de información confidencial y bloquear dichas transferencias al tiempo que alerta a
los profesionales de seguridad de la información.
En el caso de la plataforma subyacente administrada por Microsoft, Microsoft trata todo el contenido de los
clientes como confidencial y protege a los clientes contra la pérdida y exposición de los datos. Para garantizar la
seguridad de los datos de los clientes dentro de Azure, Microsoft ha implementado y mantiene un conjunto de
controles y funcionalidades eficaces de protección de datos.
Descripción de la protección de datos de los clientes en Azure
4.4: Cifrado de toda la información confidencial en tránsito
Guía : paquetes de clientes cifrados de instancias de VPN Gateway entre las instancias de Azure VPN Gateway y
los clientes de VPN (P2S) o los dispositivos de VPN (S2S) locales de los clientes. Las instancias de Azure VPN
Gateway también admiten el cifrado entre redes virtuales.
Siga las recomendaciones de Azure Security Center para el cifrado en reposo y el cifrado en tránsito, para los
recursos aplicables de la red virtual.
Acerca de los tipos de VPN
Acerca de los dispositivos VPN y los parámetros de IPsec/IKE para conexiones de VPN Gateway de sitio a
sitio
Acerca de los requisitos criptográficos y las puertas de enlace de VPN de Azure
Configurar una directiva de IPsec o IKE para conexiones VPN de sitio a sitio o de red virtual a red virtual
Descripción del cifrado en tránsito con Azure
Responsabilidad : Compartido
4.5: Uso de una herramienta de detección activa para identificar datos confidenciales
Guía : use una herramienta de detección activa de terceros para identificar toda la información confidencial
almacenada, procesada o transmitida por los sistemas tecnológicos, incluidos los del ubicación local o los que se
encuentran en un proveedor de servicios remoto, y actualizar el inventario de información confidencial de la
organización.
4.6: Uso de RBAC de Azure para controlar el acceso a los recursos
Guía : Use el control de acceso basado en rol de Azure (Azure RBAC) para controlar el acceso a los datos y
recursos; si no, use métodos de control de acceso específicos del servicio. Elija roles integrados como
Propietario, Colaborador o Colaborador de red y asigne el rol al ámbito adecuado. Asigne permisos específicos
para un subconjunto de funcionalidades de red virtual creando un rol personalizado y asignando a este los
permisos específicos necesarios para redes virtuales, subredes, instancias de VPN Gateway, interfaces de red,
grupos de seguridad de red y tablas de rutas.
Configuración de Azure RBAC
Planear redes virtuales
4.9: Registro y alerta de cambios en los recursos críticos de Azure
Guía : configure las alertas de Azure Monitor a fin de desencadenar los registros de actividad de Azure para
cuando se produzcan cambios en recursos de Azure críticos como las instancias de VPN Gateway.
Configuración de alertas en métricas de VPN Gateway
Configuración de alertas de eventos de registro de diagnóstico de VPN Gateway
Creación de alertas para los eventos del registro de actividad de Azure
Administración de vulnerabilidades
Para obtener más información, consulte Azure Security Benchmark: Administración de vulnerabilidades.
5.5: Use un proceso de clasificación de riesgos para priorizar la corrección de las vulnerabilidades detectadas
Instrucciones : Use un programa de puntuación de riesgos común (por ejemplo, Common Vulnerability Scoring
System) o la clasificación de riesgos predeterminada proporcionada por su herramienta de análisis de terceros.
Publicación de NIST: sistema de puntuación común de vulnerabilidades
Inventario y administración de recursos

Para obtener más información, consulte Azure Security Benchmark: Administración de recursos y del inventario.
6.1: Uso de la solución de detección de recursos automatizada
Guía : use Azure Resource Graph para consultar y detectar todos los recursos relacionados con sus instancias de
VPN Gateway dentro de las suscripciones. Asegúrese de que tiene los permisos adecuados (lectura) en el
inquilino y de que puede enumerar todos los recursos de las suscripciones. Además, también puede usar la CLI
de Azure para enumerar los recursos de VPN Gateway.
Creación de consultas con Azure Graph
CLI de Azure para VPN Gateway
Visualización de las suscripciones de Azure
Descripción de Azure RBAC
6.2: Mantenimiento de metadatos de recursos
Guía : aplique etiquetas a los recursos de Azure Gateway para organizarlos de forma lógica según una
taxonomía definida.
6.3: Eliminación de recursos de Azure no autorizados
Guía : use el etiquetado, los grupos de administración y las suscripciones independientes, si procede, para
organizar y realizar un seguimiento de los recursos de VPN Gateway. Concilie el inventario periódicamente y
asegúrese de que los recursos no autorizados se eliminan de la suscripción de manera oportuna.
Creación de suscripciones adicionales de Azure
Creación de grupos de administración
6.4: Definición y mantenimiento de un inventario de los recursos de Azure aprobados
Guía : Cree un inventario de los recursos de Azure aprobados y el software aprobado para los recursos de
proceso según las necesidades de la organización.
6.5: Supervisión de recursos de Azure no aprobados
Guía : use Azure Policy para aplicar restricciones en el tipo de recursos que se pueden crear en las suscripciones
del cliente con las siguientes definiciones de directiva integradas:
Tipos de recursos no permitidos
Tipos de recursos permitidos
Además, use Azure Resource Graph para consultar y detectar recursos en las suscripciones.
Creación de consultas con Azure Graph
Integraciones de ejemplo de Azure Policy para la red virtual
6.7: Eliminación de aplicaciones de software y recursos de Azure no aprobadas
Guía : los clientes pueden evitar el uso o la creación de recursos asignando definiciones de Azure Policy de
acuerdo con los requisitos de seguridad de la organización. Sin embargo, debe implementar su propio proceso
para quitar recursos no aprobados o no autorizados.
6.9: Uso exclusivo de servicios de Azure aprobados
Guía : use Azure Policy para establecer restricciones sobre el tipo de recursos que se pueden crear en las
suscripciones con las siguientes definiciones de directiva integradas:
Tipos de recursos no permitidos
Tipos de recursos permitidos
Denegación de un tipo de recurso específico con Azure Policy
6.11: Limitación de la capacidad de los usuarios para interactuar con Azure Resource Manager
Guía : Use el acceso condicional de Azure AD para limitar la capacidad de los usuarios de interactuar con Azure
Resource Manager mediante la configuración de la opción "Bloquear acceso" en la aplicación "Administración de
Microsoft Azure".
Configuración del acceso condicional para bloquear el acceso a Azure Resource Manager
Configuración segura
Para obtener más información, consulte Azure Security Benchmark: Configuración segura.
7.1: Establezca configuraciones seguras para todos los recursos de Azure
Guía : use alias de Azure Policy para crear directivas personalizadas con el fin de auditar o aplicar la
configuración de los recursos de red de Azure, incluyendo VPN Gateway. También puede usar definiciones de
Azure Policy integradas.
Azure Resource Manager tiene la capacidad de exportar la plantilla en notación de objetos JavaScript (JSON),
que se debe revisar para asegurarse de que las configuraciones cumplan o superen los requisitos de seguridad
de la organización.
También puede usar las recomendaciones de Azure Security Center como línea de base de configuración segura
para los recursos de Azure.
Visualización de los alias de Azure Policy disponibles
Tutorial: Creación y administración de directivas para aplicar el cumplimiento
Exportación de uno y varios recursos a una plantilla en Azure Portal
Guía de referencia sobre las recomendaciones de seguridad
7.3: Mantenga configuraciones de recursos de Azure seguras
Guía : use las plantillas de Azure Resource Manager y las asignaciones de Azure Policy para configurar de forma
segura los recursos de Azure asociados a VPN Gateway y recursos relacionados. Las plantillas de Azure
Resource Manager son archivos basados en JSON que se usan para implementar la máquina virtual junto con
los recursos de Azure, y las plantillas personalizadas deberán mantenerse. Microsoft realiza el mantenimiento en
las plantillas base. Utilice los modos [deny] y [deploy if not exist] de Azure Policy para aplicar una configuración
segura en los recursos de Azure.
Información sobre la creación de plantillas de Azure Resource Manager
Descripción de los efectos de Azure Policy
Ejemplos de plantilla de Azure Resource Manager para una red virtual
7.5: Almacene de forma segura la configuración de los recursos de Azure
Guía : Use Azure DevOps para almacenar y administrar de forma segura el código, como definiciones de Azure
Policy personalizadas, plantillas de Azure Resource Manager y scripts de Desired State Configuration. Para
acceder a los recursos que administra en Azure DevOps, puede conceder o denegar permisos a usuarios
específicos, grupos de seguridad integrados o grupos definidos en Azure Active Directory (Azure AD) si se
integran con Azure DevOps, o Active Directory si se integran con TFS.
Almacenamiento de código en Azure DevOps
Acerca de los permisos y los grupos en Azure DevOps
7.7: Implementación de herramientas de administración de configuración para recursos de Azure
Guía : defina e implemente configuraciones de seguridad estándar para los recursos de Azure con Azure Policy.
Use alias de Azure Policy para crear directivas personalizadas con el fin de auditar o aplicar las configuraciones
de los recursos de Azure. También puede usar definiciones de directivas integradas relacionadas con recursos
concretos. Además, puede usar Azure Automation para implementar los cambios de configuración.
Uso de alias
7.9: Implementación de la supervisión de la configuración automatizada para los recursos de Azure
Guía : asigne definiciones de Azure Policy para medir las configuraciones de recursos relacionadas con los
recursos de VPN Gateway. Use la información de Azure Policy para auditar configuraciones de recursos y alertar
sobre cambios de configuración críticos.
7.11: Administre los secretos de Azure de forma segura
Guía : el servicio VPN Gateway almacena internamente y transmite claves precompartidas y certificados del
cliente cifrados. Los clientes deben proteger las claves precompartidas o los certificados en sus propios
sistemas.
7.12: Administre las identidades de forma segura y automática
Guía : VPN de punto a sitio de Azure admite tres métodos de autenticación:
Basada en certificados.
RADIUS
Azure Active Directory (Azure AD)
Se recomienda Azure AD porque le permite aprovechar las identidades administradas.
Configuración de un inquilino
Configuración de un inquilino con varias aplicaciones cliente
Configuración de Multi-Factor Authentication
Configuración de un cliente VPN
Configuración de las identidades administradas
7.13: Elimine la exposición de credenciales no intencionada
Instrucciones : Implemente el escáner de credenciales para identificar las credenciales en el código. El escáner
de credenciales también fomenta el traslado de credenciales detectadas a ubicaciones más seguras, como Azure
Key Vault.
Configuración del escáner de credenciales
Recuperación de datos
Para más información, consulte Azure Security Benchmark: recuperación de datos.
9.1: Garantía de copias de seguridad automáticas periódicas
Guía : use Azure Resource Manager para implementar recursos de VPN Gateway. Azure Resource Manager
proporciona la capacidad de exportar plantillas, que se pueden usar como copias de seguridad para restaurar
los recursos de VPN Gateway. Use Azure Automation para llamar a la API de exportación de plantillas de Azure
Resource Manager de forma periódica.
Introducción sobre Azure Resource Manager
Ejemplos de plantilla de Azure Resource Manager para una red virtual
Grupos de recursos: Exportar plantilla
Introducción a Azure Automation
9.2: Copias de seguridad completas del sistema y copia de seguridad de las claves administradas por el
cliente
Guía : use Azure Resource Manager para implementar recursos de VPN Gateway. Azure Resource Manager
proporciona la capacidad de exportar plantillas, que se pueden usar como copias de seguridad para restaurar
VPN Gateway y los recursos relacionados. Use Azure Automation para llamar a la API de exportación de
plantillas de Azure Resource Manager de forma periódica.
Exportación de uno y varios recursos a una plantilla en Azure Portal
Grupos de recursos: Exportar plantilla
Introducción a Azure Automation
9.3: Validación de todas las copias de seguridad, incluidas las claves administradas por el cliente
Guía : en caso necesario, asegúrese de poder realizar periódicamente la implementación de plantillas de Azure
Resource Manager de forma habitual en una suscripción aislada.
Implementación de recursos con Azure Portal y plantillas de Resource Manager
Restauración de las claves del almacén de claves en Azure
9.4: Garantía de la protección de las copias de seguridad y las claves administradas por el cliente
Guía : Use Azure DevOps para almacenar y administrar de forma segura el código, como definiciones de Azure
Policy personalizadas y plantillas de Azure Resource Manager. Para proteger los recursos que administra en
Azure DevOps, puede conceder o denegar permisos a usuarios específicos, grupos de seguridad integrados o
grupos definidos en Azure Active Directory (Azure AD) si se integran con Azure DevOps.
Almacenamiento de código en Azure DevOps
Acerca de los permisos y los grupos en Azure DevOps
Eliminación temporal de blobs de Azure Storage
Respuesta a los incidentes

Para obtener más información, consulte Azure Security Benchmark: Respuesta a los incidentes.
10.1: Creación de una guía de respuesta ante incidentes
Guía : desarrolle una guía de respuesta a incidentes para su organización. Asegúrese de que haya planes de
respuesta a incidentes escritos que definan todos los roles del personal, así como las fases de administración y
gestión de los incidentes, desde la detección hasta la revisión posterior a la incidencia.
Guía para crear su propio proceso de respuesta a incidentes de seguridad
Anatomía de un incidente del Centro de respuestas de seguridad de Microsoft
Uso de la guía de control de incidentes de seguridad de equipos de NIST para la creación de su propio
plan de respuesta a incidentes
10.2: Creación de un procedimiento de priorización y puntuación de incidentes
Instrucciones : Azure Security Center asigna una gravedad a cada alerta para ayudarle a priorizar aquellas que
se deben investigar en primer lugar. La gravedad se basa en la confianza que tiene Security Center en la
búsqueda o en el análisis utilizados para emitir la alerta, así como en el nivel de confianza de que ha habido un
intento malintencionado detrás de la actividad que ha provocado la alerta.
Adicionalmente, marque las suscripciones con etiquetas y cree un sistema de nomenclatura para identificar y
clasificar los recursos de Azure, especialmente los que procesan datos confidenciales. Es su responsabilidad
asignar prioridades a la corrección de las alertas en función de la importancia de los recursos y el entorno de
Azure donde se produjo el incidente.
Alertas de seguridad en el Centro de seguridad de Azure
Uso de etiquetas para organizar los recursos de Azure
10.3: Prueba de los procedimientos de respuesta de seguridad
Instrucciones : Realice ejercicios para probar las funcionalidades de respuesta a los incidentes de los sistemas
periódicamente; así, ayudará a proteger los recursos de Azure. Identifique puntos débiles y brechas y después
revise el plan de respuesta según sea necesario.
Publicación de NIST: Guía para probar, entrenar y ejecutar programas para planes y funcionalidades de TI
10.4: Provisión de detalles de contacto de incidentes de seguridad y configuración de notificaciones de alerta
para incidentes de seguridad
Instrucciones : La información de contacto del incidente de seguridad la utilizará Microsoft para ponerse en
contacto con usted si Microsoft Security Response Center (MSRC) detecta que un tercero no autorizado o ilegal
ha accedido a los datos. Revise los incidentes después del hecho para asegurarse de que se resuelven los
problemas.
Establecimiento del contacto de seguridad de Azure Security Center
10.5: Incorporación de alertas de seguridad en el sistema de respuesta a incidentes
Instrucciones : exporte las alertas y recomendaciones de Azure Security Center y mediante la característica de
exportación continua para ayudar a identificar riesgos en los recursos de Azure. La exportación continua
permite exportar alertas y recomendaciones de forma manual o continua. Puede usar el conector de datos de
Azure Security Center para enviar las alertas a Azure Sentinel.
Configuración de la exportación continua
Transmisión de alertas a Azure Sentinel
10.6: Automatización de la respuesta a las alertas de seguridad
Guía : use la característica de automatización de flujos de trabajo de Azure Security Center para desencadenar
automáticamente las alertas y recomendaciones de seguridad con el fin de proteger los recursos de Azure.
Configuración de la automatización de flujos de trabajo en Security Center
Pruebas de penetración y ejercicios del equipo rojo

Para obtener más información, consulte Azure Security Benchmark: Pruebas de penetración y ejercicios del
equipo rojo.
11.1: Realice pruebas de penetración periódicas de los recursos de Azure y asegúrese de corregir todos los
resultados de seguridad críticos
Guía : Siga las reglas de compromiso de la prueba de penetración de Microsoft Cloud para asegurarse de que
las pruebas de penetración no infrinjan las directivas de Microsoft. Use la estrategia de Microsoft y la ejecución
de las pruebas de penetración del equipo rojo y sitios activos en la infraestructura de nube, los servicios y las
aplicaciones administradas por Microsoft.
Reglas de interacción de las pruebas de penetración
Equipo rojo de Microsoft Cloud
Pasos siguientes
Consulte la prueba comparativa de seguridad de Azure.
Obtenga más información sobre las líneas de base de seguridad de Azure.
Interoperabilidad en Azure: Prueba de
configuración
En este artículo se describe una configuración de prueba que permite analizar cómo los servicios de redes de
Azure interactúan en el nivel del plano de control y en el nivel del plano de datos. Echemos un vistazo a los
componentes de red de Azure:
Azure ExpressRoute : use el emparejamiento privado de Azure ExpressRoute para conectar directamente
espacios IP privados de la red local a las implementaciones de la red virtual de Azure. ExpressRoute puede
ayudarle a lograr un ancho de banda mayor y una conexión privada. Muchos asociados de ExpressRoute
ofrecen conectividad de ExpressRoute con contratos de nivel de servicio. Para más información acerca de
ExpressRoute y su configuración, consulte Información general sobre ExpressRoute.
VPN de sitio a sitio : puede usar Azure VPN Gateway como una VPN de sitio a sitio para conectar de forma
segura una red local a Azure a través de Internet o ExpressRoute. Para más información acerca de cómo
configurar una VPN de sitio a sitio para conectarse a Azure, consulte Configurar VPN Gateway.
Emparejamiento de VNET : use el emparejamiento de red virtual (VNet) para establecer conectividad entre
las redes virtuales de Azure Virtual Network. Para más información sobre el emparejamiento de VNET,
consulte el tutorial acerca del emparejamiento de redes virtuales.
Prueba de configuración
En la siguiente ilustración se muestra la configuración de prueba:
La pieza central de la configuración de prueba es la red virtual del concentrador en la región 1 de Azure. La red
virtual del concentrador se conecta a otras redes de las siguientes maneras:
La red virtual del concentrador se conecta a la red virtual de radio mediante el uso del emparejamiento de
redes virtuales. La red virtual de radio tiene acceso remoto a las dos puertas de enlace de la red virtual del
concentrador.
La red virtual del concentrador está conectada a la red virtual de sucursal mediante una VPN de sitio a sitio.
La conectividad usa EBGP para intercambiar las rutas.
La red virtual del concentrador se conecta a la red local Ubicación 1 mediante el uso del emparejamiento
privado de ExpressRoute1 como la ruta de acceso principal. Asimismo, usa la conectividad VPN de sitio a sitio
como ruta de acceso de respaldo. En el resto de este artículo, se hará referencia a este circuito de
ExpressRoute como ExpressRoute 1. De forma predeterminada, los circuitos de ExpressRoute proporcionan
conectividad redundante para alta disponibilidad. En ExpressRoute1, la subinterfaz del enrutador perimetral
del cliente (CE) secundario que accede al Microsoft Enterprise Edge Router (MSEE) secundario está
deshabilitada. Esto se indica mediante una línea de color rojo sobre la flecha de doble línea en el diagrama
anterior.
La red virtual del concentrador se conecta a la red local Ubicación 2 mediante el uso de otro emparejamiento
privado de ExpressRoute. En el resto de este artículo, se hará referencia a este segundo circuito de
ExpressRoute como ExpressRoute 2.
ExpressRoute1 también conecta la red virtual del concentrador y la red local Ubicación 1 a una red virtual
remota en la región 2 de Azure.
Uso simultáneo de ExpressRoute y la conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute
Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft con ExpressRoute para
intercambiar datos de forma privada entre la red local y las redes virtuales de Azure. Esta configuración le
asegura un intercambio de datos con confidencialidad, autenticidad, integridad y antirreproducción. Para más
información acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con emparejamiento de
Microsoft de ExpressRoute, consulte Configuración de una VPN de sitio a sitio a través del emparejamiento de
Microsoft de ExpressRoute.
La limitación principal de la configuración de una VPN de sitio a sitio que use el emparejamiento de Microsoft es
el rendimiento. El rendimiento a través del túnel IPsec está limitado por la capacidad de la puerta de enlace de
VPN. El rendimiento de la puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso
del túnel IPsec para el tráfico de seguridad alta y con emparejamiento privado para el tráfico restante ayuda a
optimizar el uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta disponibilidad. Puede configurar la
conectividad de ExpressRoute con redundancia geográfica en diferentes regiones de Azure. Además, como se ha
demostrado en la configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a sitio
para crear una ruta de acceso de conmutación por error para la conectividad de ExpressRoute. Cuando se
anuncian los mismos prefijos a través de ExpressRoute y VPN de sitio a sitio, Azure da prioridad a ExpressRoute.
Para evitar el enrutamiento asimétrico entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local
también debe tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a sitio.
Para más información acerca de cómo configurar conexiones coexistentes de ExpressRoute y una VPN de sitio a
sitio, consulte el artículo sobre la coexistencia de conexiones de ExpressRoute y de sitio a sitio.
Ampliación de la conectividad de back-end a redes virtuales de radio

y ubicaciones de sucursal
Conectividad de red virtual de radio mediante el emparejamiento de redes virtuales
La arquitectura de red virtual de tipo hub-and-spoke se usa ampliamente. El centro de conectividad es una red
virtual de Azure que actúa como punto central de conectividad entre las redes virtuales de radio y la red local.
Los radios son redes virtuales que se emparejan con el centro de conectividad y sirven para aislar las cargas de
trabajo. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de ExpressRoute
o VPN. Para más información acerca de la arquitectura, consulte Implementación de una topología de red en
estrella tipo hub-and-spoke en Azure.
En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de radio pueden usar las
puertas de enlace del centro de conectividad (tanto de VPN como de ExpressRoute) para comunicarse con las
redes remotas.
Conectividad de red virtual de sucursal mediante VPN de sitio a sitio
Es posible que quiera redes virtuales en rama, que están en regiones diferentes, y redes locales para
comunicarse entre sí a través de una red virtual de centro de conectividad. La solución de Azure nativa para esta
configuración es la conectividad VPN de sitio a sitio mediante una VPN. Una alternativa es usar una aplicación
virtual de red (NVA) para el enrutamiento en el centro de conectividad.
Para más información, consulte ¿Qué es VPN Gateway? e Implementación de aplicaciones virtuales de red de
alta disponibilidad.
Pasos siguientes
Obtenga información acerca de los detalles de configuración de la topología de prueba.
Más información acerca del análisis del plano de control de la configuración de prueba y de las vistas de otras
redes virtuales y VLAN de la topología.
Obtenga información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
características de supervisión de red de Azure.
Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:
Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de ExpressRoute.
Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de ExpressRoute.
Los límites de escala de ExpressRoute.
Interoperabilidad de las características de
conectividad del back-end de Azure: Detalles de
configuración de prueba
En este artículo se describen los detalles de la configuración de la prueba. La configuración de prueba ayuda a
analizar cómo los servicios de redes de Azure interactúan en el nivel del plano de control y en el nivel del plano
de datos.
Conectividad de red virtual de radio mediante el emparejamiento de

redes virtuales
En la siguiente ilustración se muestran los detalles del emparejamiento de redes virtuales de Azure de una red
virtual de radio. Para información sobre cómo configurar el emparejamiento entre dos redes virtuales, consulte
el artículo sobre la administración del emparejamiento de redes virtuales. Si quiere que la red virtual de radio
use las puertas de enlace conectadas a la red virtual del centro de conectividad, seleccione Usar puer tas de
enlace remotas .
En la siguiente ilustración se muestran los detalles del emparejamiento de redes virtuales del centro de
conectividad. Si quiere que la red virtual del centro permita que la red virtual de radio use las puertas de enlace
del centro, seleccione Allow gateway transit (Permitir tránsito de puerta de enlace).
Conectividad de red virtual de sucursal mediante una VPN de sitio a
sitio
Configure la conectividad VPN de sitio a sitio entre las redes virtuales del centro de conectividad y de sucursal
mediante las puertas de enlace VPN de Azure VPN Gateway. De forma predeterminada, las puertas de enlace
VPN y de Azure ExpressRoute usan el número de sistema autónomo (ASN) privado 65515 . Este valor de ASN se
puede cambiar en VPN Gateway. En la configuración de prueba, el valor ASN de la puerta de enlace VPN de red
virtual de sucursal se cambia a 65516 para habilitar el enrutamiento EBGP entre el centro de conectividad y la
red virtual de sucursal.
Conectividad local de la ubicación 1 con ExpressRoute y VPN de sitio
a sitio
Detalles de configuración de la ubicación 1 (ExpressRoute )
En la siguiente ilustración se muestra la configuración del circuito ExpressRoute en la región 1 de Azure hacia los
enrutadores del lado del cliente (CE) locales de la ubicación 1:
En la siguiente ilustración se muestra la configuración de conexión entre el circuito ExpressRoute 1 y el centro de

conectividad:
En la siguiente lista se muestra la configuración del enrutador del lado del cliente principal para la conectividad
de emparejamiento privado de ExpressRoute. (En esta configuración de prueba se utilizan enrutadores Cisco
ASR1000 en el lado del cliente). Cuando los circuitos de VPN de sitio a sitio y ExpressRoute se configuran en
paralelo para conectar una red local con Azure, Azure da prioridad al circuito de ExpressRoute de forma
predeterminada. Para evitar el enrutamiento asimétrico, la red local también debe dar prioridad a la
conectividad de ExpressRoute sobre VPN de sitio a sitio. La siguiente configuración establece prioridades
mediante el atributo BGP local-preference :
interface TenGigabitEthernet0/0/0.300
description Customer 30 private peering to Azure
encapsulation dot1Q 30 second-dot1q 300
ip vrf forwarding 30
ip address 192.168.30.17 255.255.255.252
!
interface TenGigabitEthernet1/0/0.30
description Customer 30 to south bound LAN switch
encapsulation dot1Q 30
ip address 192.168.30.0 255.255.255.254
ip ospf network point-to-point
!
router ospf 30 vrf 30
router-id 10.2.30.253
redistribute bgp 65021 subnets route-map BGP2OSPF
network 192.168.30.0 0.0.0.1 area 0.0.0.0
default-information originate always
default-metric 10
!
router bgp 65021
!
address-family ipv4 vrf 30
network 10.2.30.0 mask 255.255.255.128
neighbor 192.168.30.18 remote-as 12076
neighbor 192.168.30.18 activate
neighbor 192.168.30.18 next-hop-self
neighbor 192.168.30.18 soft-reconfiguration inbound
neighbor 192.168.30.18 route-map prefer-ER-over-VPN in
neighbor 192.168.30.18 prefix-list Cust30_to_Private out
exit-address-family
!
route-map prefer-ER-over-VPN permit 10
set local-preference 200
!
ip prefix-list Cust30_to_Private seq 10 permit 10.2.30.0/25
!
Detalles de configuración de VPN de sitio a sitio

En la siguiente lista se muestra la configuración del enrutador del lado del cliente principal para la conectividad
VPN de sitio a sitio:
crypto ikev2 proposal Cust30-azure-proposal

encryption aes-cbc-256 aes-cbc-128 3des
integrity sha1
group 2
!
crypto ikev2 policy Cust30-azure-policy
match address local 66.198.12.106
proposal Cust30-azure-proposal
!
crypto ikev2 keyring Cust30-azure-keyring
peer azure
address 52.168.162.84
pre-shared-key local IamSecure123
pre-shared-key remote IamSecure123
!
crypto ikev2 profile Cust30-azure-profile
match identity remote address 52.168.162.84 255.255.255.255
identity local address 66.198.12.106
authentication local pre-share
authentication remote pre-share
keyring local Cust30-azure-keyring
!
crypto ipsec transform-set Cust30-azure-ipsec-proposal-set esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile Cust30-azure-ipsec-profile
set transform-set Cust30-azure-ipsec-proposal-set
set ikev2-profile Cust30-azure-profile
!
interface Loopback30
ip address 66.198.12.106 255.255.255.255
!
interface Tunnel30
ip address 10.2.30.125 255.255.255.255
tunnel source Loopback30
tunnel mode ipsec ipv4
tunnel destination 52.168.162.84
tunnel protection ipsec profile Cust30-azure-ipsec-profile
!
router bgp 65021
!
address-family ipv4 vrf 30
network 10.2.30.0 mask 255.255.255.128
neighbor 10.10.30.254 remote-as 65515
neighbor 10.10.30.254 ebgp-multihop 5
neighbor 10.10.30.254 update-source Tunnel30
neighbor 10.10.30.254 activate
neighbor 10.10.30.254 soft-reconfiguration inbound
exit-address-family
!
ip route vrf 30 10.10.30.254 255.255.255.255 Tunnel30
Conectividad local de la ubicación 2 con ExpressRoute

Un segundo circuito de ExpressRoute, más próximo a la ubicación 2 local, conecta la ubicación 2 local al centro
de conectividad. En la siguiente ilustración se muestra la segunda configuración de ExpressRoute:
En la siguiente ilustración se muestra la configuración de la conexión entre el segundo circuito de ExpressRoute
y el centro de conectividad:
ExpressRoute 1 conecta el centro de conectividad y la ubicación 1 local con una red virtual remota de otra
región de Azure:


redes remotas.
Pasos siguientes
Más información acerca del análisis del plano de control de la configuración de prueba y de las vistas de otras
redes virtuales y VLAN de la topología.
Más información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
Interoperabilidad en Azure: Análisis del plano de
control
En este artículo se describe el análisis del plano de control de la configuración de la prueba. También puede
revisar la configuración de la prueba y el análisis del plano de control de la configuración de la prueba.
En esencia, el análisis del plano de control examina las rutas que se intercambian entre las redes dentro de una
topología. El análisis del plano de control puede ayudar a entender la forma en la que cada red ve la topología.
Perspectiva de red virtual de tipo hub-and-spoke

En la siguiente ilustración se muestra la red desde la perspectiva de un centro de conectividad y una red virtual
de radio (resaltada en azul). En la ilustración también se muestra el número de sistema autónomo (ASN) de las
redes y rutas que se intercambian entre las distintas redes:
Tenga en cuenta que el ASN de la puerta de enlace de Azure ExpressRoute de la red virtual difiere del de los
enrutadores de Microsoft Enterprise Edge (MSEE). Generalmente, la puerta de enlace de ExpressRoute usa un
ASN privado (con valor 65515 ) y los MSEE, uno público (12076 ). Al configurar el emparejamiento de
ExpressRoute, como MSEE es del mismo nivel, se usa 12076 como ASN del mismo nivel. Del lado de Azure,
MSEE establece emparejamiento de BGP externo con la puerta de enlace de ExpressRoute. El emparejamiento
BGP externo dual que el MSEE establece para cada emparejamiento de ExpressRoute es transparente en el nivel
del plano de control. Por tanto, al visualizar una tabla de enrutamiento de ExpressRoute, se ve el valor de ASN de
la puerta de enlace de ExpressRoute de la red virtual para los prefijos de esta.
En la siguiente ilustración se muestra una tabla de enrutamiento de ExpressRoute de ejemplo:
En Azure, el valor de ASN solo es significativo para el emparejamiento. De forma predeterminada, el valor de
ASN de la puerta de enlace tanto de ExpressRoute como de VPN en Azure VPN Gateway es 65515 .
Perspectiva de la ubicación 1 local y de la red virtual remota a través

de ExpressRoute 1
Tanto la ubicación 1 local como la red virtual remota están conectadas al centro de conectividad a través de
ExpressRoute 1. Comparten la misma perspectiva de la topología, como se muestra en el siguiente diagrama:
Perspectiva de la ubicación 1 local y de la red virtual remota a través

de ExpressRoute 1
Tanto la ubicación 1 local como la red virtual de la rama están conectadas a una puerta de enlace de centro de
conectividad a través de una VPN de sitio a sitio. Comparten la misma perspectiva de la topología, como se
muestra en el siguiente diagrama:
Perspectiva de la ubicación 2 local
La ubicación 2 local está conectada al centro de conectividad a través del emparejamiento privado de
ExpressRoute 2:


redes remotas.
Pasos siguientes
Más información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
Interoperabilidad en Azure: Análisis del plano de
datos
En este artículo se describe el análisis del plano de datos de la configuración de prueba. También puede revisar
la configuración de la prueba y el análisis del plano de datos de la configuración de prueba.
En el análisis del plano de datos se examina la ruta de acceso de los paquetes que se desplazan desde una red
local (LAN o red virtual) a otra dentro de una topología. Es posible que la ruta de acceso de datos entre dos
redes locales no sea necesariamente simétrica. Por tanto, en este artículo se va a analizar la ruta de reenvío
desde una red local a otra de forma independiente a la ruta de acceso inversa.
Ruta de acceso de datos desde el centro de conectividad

Ruta a la red virtual de radio
El emparejamiento de redes virtuales emula la funcionalidad de puente de red entre las dos redes virtuales
emparejadas. A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina
virtual de la red virtual de radio:
C:\Users\rb>tracert 10.11.30.4
Tracing route to 10.11.30.4 over a maximum of 30 hops
1 2 ms 1 ms 1 ms 10.11.30.4
Trace complete.
En la siguiente ilustración se muestra la vista de conexión gráfica del centro de conectividad y la red virtual de
radio desde la perspectiva de Azure Network Watcher:
Ruta de acceso a la red virtual de sucursal

A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina virtual de la
red virtual de sucursal:
1 1 ms 1 ms 1 ms 10.10.30.142
2 * * * Request timed out.
3 2 ms 2 ms 2 ms 10.11.30.68
Trace complete.
En este comando traceroute, el primer salto es la puerta de enlace de VPN en la instancia de Azure VPN
Gateway del centro de conectividad. El segundo salto es la puerta de enlace de VPN de la red virtual de sucursal.
La dirección IP de la puerta de enlace de VPN de la red virtual de sucursal no se anuncia en el centro de
conectividad. El tercer salto es la máquina virtual de la red virtual de sucursal.
En la siguiente ilustración se muestra la vista de conexión gráfica del centro de conectividad y la red virtual de
sucursal desde la perspectiva de Network Watcher:
Para la misma conexión, en la siguiente ilustración se muestra la vista de cuadrícula de Network Watcher:
Ruta de acceso a la ubicación 1 local

ubicación 1 local:
1 2 ms 2 ms 2 ms 10.10.30.132
4 2 ms 2 ms 2 ms 10.2.30.10
Trace complete.
En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de Azure
ExpressRoute a un enrutador de Microsoft Enterprise Edge (MSEE). El segundo y tercer salto son las direcciones
IP del enrutador del lado del cliente y la LAN de la ubicación 1 local. Estas direcciones IP no se anuncian en el
centro de conectividad. El cuarto salto es la máquina virtual de la ubicación 1 local.
ubicación 2 local:
1 76 ms 75 ms 75 ms 10.10.30.134
4 75 ms 75 ms 75 ms 10.1.31.10
Trace complete.
En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de
ExpressRoute a un enrutador MSEE. El segundo y tercer salto son las direcciones IP del enrutador del lado del
cliente y la LAN de la ubicación 2 local. Estas direcciones IP no se anuncian en el centro de conectividad. El
cuarto salto es la máquina virtual de la ubicación 2 local.
Ruta de acceso a la red virtual remota
red virtual remota:
1 2 ms 2 ms 2 ms 10.10.30.132
3 69 ms 68 ms 69 ms 10.17.30.4
Trace complete.
ExpressRoute a un enrutador MSEE. El segundo salto es la dirección IP de la puerta de enlace de la red virtual
remota. El intervalo IP del segundo salto no se anuncia en el centro de conectividad. El tercer salto es la máquina
virtual de la red virtual remota.
Ruta de acceso de datos de la red virtual de radio

La red virtual de radio comparte la vista de red del centro de conectividad. Mediante el emparejamiento de
redes virtuales, la red virtual de radio usa la conectividad de puerta de enlace remota del centro de conectividad
como si estuviera conectada directamente a la red virtual de radio.
Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual del
centro de conectividad:
1 <1 ms <1 ms <1 ms 10.10.30.4
Trace complete.

A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual de la red
virtual de sucursal:
1 1 ms <1 ms <1 ms 10.10.30.142

3 3 ms 2 ms 2 ms 10.11.30.68
Trace complete.
En este comando traceroute, el primer salto es la puerta de enlace de VPN del centro de conectividad. El
segundo salto es la puerta de enlace de VPN de la red virtual de sucursal. La dirección IP de la puerta de enlace
de VPN de la red virtual de sucursal no se anuncia en el centro de conectividad ni en la red virtual de radio. El
tercer salto es la máquina virtual de la red virtual de sucursal.
A continuación se muestra la salida de traceroute desde la red virtual de radio a una máquina virtual de la
ubicación 1 local:
1 24 ms 2 ms 3 ms 10.10.30.132
4 3 ms 2 ms 2 ms 10.2.30.10
Trace complete.
ExpressRoute del centro de conectividad a un enrutador MSEE. El segundo y tercer salto son las direcciones IP
del enrutador del lado del cliente y la LAN de la ubicación 1 local. Estas direcciones IP no se anuncian en el
centro de conectividad ni en la red virtual de radio. El cuarto salto es la máquina virtual de la ubicación 1 local.
ubicación 2 local:
1 76 ms 75 ms 76 ms 10.10.30.134
4 75 ms 75 ms 75 ms 10.1.31.10
Trace complete.
ExpressRoute del centro de conectividad a un enrutador MSEE. El segundo y tercer salto son las direcciones IP
del enrutador del lado del cliente y la LAN de la ubicación 2 local. Estas direcciones IP no se anuncian en el
centro de conectividad ni en la red virtual de radio. El cuarto salto es la máquina virtual de la ubicación 2 local.
A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual de la red
virtual remota:
1 2 ms 1 ms 1 ms 10.10.30.133
3 71 ms 70 ms 70 ms 10.17.30.4
Trace complete.
ExpressRoute del centro de conectividad a un enrutador MSEE. El segundo salto es la dirección IP de la puerta de
enlace de la red virtual remota. El intervalo IP del segundo salto no se anuncia en el centro de conectividad ni en
la red virtual de radio. El tercer salto es la máquina virtual de la red virtual remota.
Ruta de acceso de datos desde la red virtual de sucursal

A continuación se muestra la salida de traceroute desde la red virtual de sucursal a una máquina virtual del
centro de conectividad:
C:\Windows\system32>tracert 10.10.30.4
1 <1 ms <1 ms <1 ms 10.11.30.100

3 4 ms 3 ms 3 ms 10.10.30.4
Trace complete.
En este comando traceroute, el primer salto es la puerta de enlace de VPN de la red virtual de sucursal. El
segundo salto es la puerta de enlace de VPN del centro de conectividad. La dirección IP de la puerta de enlace
de VPN de centro de conectividad no se anuncia en la red virtual remota. El tercer salto es la máquina virtual del
centro de conectividad.
A continuación se muestra la salida de traceroute desde una red virtual de sucursal a una máquina virtual de la
red virtual de radio:
1 1 ms <1 ms 1 ms 10.11.30.100
3 4 ms 3 ms 2 ms 10.11.30.4
Trace complete.
de VPN de centro de conectividad no se anuncia en la red virtual remota. El tercer salto es la máquina virtual de
la red virtual de radio.
ubicación 1 local:
1 1 ms <1 ms <1 ms 10.11.30.100

3 3 ms 2 ms 2 ms 10.2.30.125
5 3 ms 3 ms 3 ms 10.2.30.10
Trace complete.
de VPN de centro de conectividad no se anuncia en la red virtual remota. El tercer salto es el punto de
terminación de túnel VPN en el enrutador CE principal. El cuarto salto es una dirección IP interna de la ubicación
1 local. Esta dirección IP de LAN no se anuncia fuera del enrutador del lado del cliente. El quinto salto es la
máquina virtual de destino de la ubicación 1 local.
Ruta de acceso a la ubicación 2 local y a la red virtual remota
Como se explicó al hablar del análisis del plano de control, la red virtual de sucursal no tiene visibilidad de la
ubicación 2 local ni de la red virtual remota según la configuración de red. Los siguientes resultados de ping lo
confirman:
C:\Users\rb>ping 10.1.31.10
Pinging 10.1.31.10 with 32 bytes of data:
Request timed out.

...
Request timed out.
Ping statistics for 10.1.31.10:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Request timed out.

...
Request timed out.

Ruta de acceso de datos desde la ubicación 1 local

A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual del centro de
conectividad:
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 2 ms 2 ms 2 ms 10.10.30.4
Trace complete.
En el comando traceroute, los dos primeros saltos forman parte de la red local. El tercer salto es la interfaz MSEE
principal que se expone al enrutador del lado del cliente. El cuarto salto es la puerta de enlace de ExpressRoute
del centro de conectividad. El intervalo IP de la puerta de enlace de ExpressRoute del centro de conectividad no
se anuncia en la red local. El quinto salto es la máquina virtual de destino.
Network Watcher solo proporciona una vista centrada en Azure. Para una perspectiva local se usa Azure
Network Performance Monitor. Network Performance Monitor proporciona agentes que se pueden instalar en
servidores de redes fuera de Azure para el análisis de la ruta de acceso de datos.
En la siguiente ilustración se muestra la vista de topología de la conectividad de la máquina virtual de la
ubicación 1 local con la máquina virtual del centro de conectividad mediante ExpressRoute:
Como se comentó anteriormente, en la configuración de prueba se usa VPN de sitio a sitio como conectividad
de copia de seguridad para ExpressRoute entre la ubicación 1 local y el centro de conectividad. Para probar la
ruta de acceso de datos de copia de seguridad se va a inducir un error de vinculación de ExpressRoute entre el
enrutador CE principal de la ubicación 1 local y el MSEE correspondiente. Para inducir un error de vinculación de
ExpressRoute, apague la interfaz del lado del cliente que se expone al MSEE:
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 3 ms 2 ms 3 ms 10.10.30.4
Trace complete.
En la siguiente ilustración se muestra la vista de topología de la conectividad de la máquina virtual en la

ubicación 1 local con la máquina virtual con el centro de conectividad mediante la conectividad VPN de sitio a
sitio cuando la de ExpressRoute está inactiva:
A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual de la red
virtual de radio:
Volvamos a la conectividad de ExpressRoute principal para realizar el análisis de la ruta de datos hacia la red
virtual de radio:
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 3 ms 2 ms 2 ms 10.11.30.4
Trace complete.
Recuperemos la conectividad de ExpressRoute 1 principal para el resto del análisis de la ruta acceso de datos.
virtual de sucursal:
1 <1 ms <1 ms <1 ms 10.2.30.3

2 <1 ms <1 ms <1 ms 192.168.30.0
3 3 ms 2 ms 2 ms 10.11.30.68
Trace complete.

Como se explicó en el análisis del plano de control, la ubicación 1 local no tiene visibilidad de la ubicación 2 local
según la configuración de red. Los siguientes resultados de ping lo confirman:
Request timed out.

...
Request timed out.

virtual remota:
1 <1 ms <1 ms <1 ms 10.2.30.3

2 2 ms 5 ms 7 ms 192.168.30.0
3 <1 ms <1 ms <1 ms 192.168.30.18
5 69 ms 70 ms 69 ms 10.17.30.4
Trace complete.
Ruta de acceso de datos desde la ubicación 2 local

A continuación se muestra la salida de traceroute desde la ubicación 2 local a una máquina virtual del centro de
conectividad:
1 <1 ms <1 ms <1 ms 10.1.31.3

2 <1 ms <1 ms <1 ms 192.168.31.4
3 <1 ms <1 ms <1 ms 192.168.31.22
5 75 ms 74 ms 74 ms 10.10.30.4
Trace complete.

virtual de radio:

1 <1 ms <1 ms 1 ms 10.1.31.3
2 <1 ms <1 ms <1 ms 192.168.31.0
3 <1 ms <1 ms <1 ms 192.168.31.18
5 75 ms 74 ms 74 ms 10.11.30.4
Trace complete.
Ruta de acceso a la red virtual de sucursal, la ubicación 1 local y la red virtual remota
Como se explicó en el análisis del plano de control, la ubicación 1 local no tiene visibilidad de la red virtual de
sucursal, la ubicación 1 local y la red virtual remota según la configuración de red.
Ruta de acceso de datos desde la red virtual remota

A continuación se muestra la salida de traceroute desde la red virtual remota a una máquina virtual del centro
de conectividad:
1 65 ms 65 ms 65 ms 10.17.30.36
3 69 ms 68 ms 68 ms 10.10.30.4
Trace complete.

A continuación se muestra la salida de traceroute desde una red virtual remota a una máquina virtual de la red
virtual de radio:
1 67 ms 67 ms 67 ms 10.17.30.36
3 71 ms 69 ms 69 ms 10.11.30.4
Trace complete.
Ruta de acceso a la red virtual de sucursal y la ubicación 2 local

Como se explicó en el análisis del plano de control, la red virtual remota no tiene visibilidad de la red virtual de
sucursal ni de la ubicación 2 local según la configuración de red.
A continuación se muestra la salida de traceroute desde la red virtual remota a una máquina virtual de la
ubicación 1 local:
1 67 ms 67 ms 67 ms 10.17.30.36
4 69 ms 69 ms 69 ms 10.2.30.10
Trace complete.


redes remotas.
Pasos siguientes
Tutorial: Creación y administración de una puerta
de enlace de VPN mediante Azure Portal
y Azure. En este tutorial se tratan los elementos básicos de implementación de Azure VPN Gateway, como crear
y administrar una puerta de enlace de VPN. También puede crear una puerta de enlace con Azure PowerShell o
la CLI de Azure.
Visualización de la dirección IP pública de la puerta de enlace
Cambio de tamaño de una puerta de enlace de VPN (cambio de tamaño de la SKU)
En el siguiente diagrama se muestran la red virtual y la puerta de enlace de VPN creadas como parte de este
tutorial.
Requisitos previos

Utilice estos valores para crear una red virtual:
Nombre: VNet1
valores:
Resource Manager.
necesite.

Firewall : Disabled

Cree una puerta de enlace de red virtual con los siguientes valores:
Nombre: VNet1GW
SKU: VpnGw1
Red vir tual: VNet1
selecciónela.
en esta página.
de enlace.
enlace.
pública.
IMPORTANT

enlace.


problema.
recursos:
Pasos siguientes
Una vez que tenga una puerta de enlace de VPN, puede configurar las conexiones. Los siguientes artículos le
ayudarán a crear algunas de las configuraciones más comunes:
Conexiones VPN de sitio a sitio
Creación de una instancia de VPN Gateway basada
en rutas mediante PowerShell
En este artículo se explica cómo crear rápidamente una instancia de Azure VPN Gateway basada en rutas
mediante PowerShell. Una instancia de VPN Gateway se usa al crear una conexión VPN a la red local. También
puede utilizar una instancia de VPN Gateway para conectar redes virtuales.
Antes de empezar
Los pasos que se describen en este artículo crearán una red virtual, una subred, una subred de puerta de enlace
y una instancia de VPN Gateway basada en rutas (puerta de enlace de red virtual). Una vez completada la
creación de la puerta de enlace, puede crear las conexiones. Estos pasos requieren una suscripción a Azure. Si no
tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Trabajo con Azure PowerShell
En este artículo se usan cmdlets de PowerShell. Para ejecutar los cmdlets, puede usar Azure Cloud Shell. Azure
Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las
herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código. También
puede ir a https://shell.azure.com/powershell para iniciar Cloud Shell en una pestaña independiente del
explorador. Seleccione Copiar para copiar los bloques de código, péguelos en Cloud Shell y, luego, presione
Entrar para ejecutarlos.
También puede instalar y ejecutar los cmdlets de Azure PowerShell localmente en el equipo. Los cmdlets de
PowerShell se actualizan con frecuencia. Si no ha instalado la versión más reciente, los valores especificados en
las instrucciones pueden dar lugar a errores. Para buscar las versiones de Azure PowerShell instaladas en el
equipo, use el cmdlet Get-Module -ListAvailable Az . Para instalar la actualización, vea Instalación del módulo de
Azure PowerShell.
Crear un grupo de recursos

Cree un grupo de recursos de Azure con New-AzResourceGroup. Un grupo de recursos es un contenedor lógico
en el que se implementan y se administran los recursos de Azure. Cree un grupo de recursos. Si ejecuta
PowerShell de manera local, abra la consola de PowerShell con privilegios elevados y conéctese a Azure con el
comando Connect-AzAccount .
New-AzResourceGroup -Name TestRG1 -Location EastUS

Cree una red virtual con New-AzVirtualNetwork. En el siguiente ejemplo se crea una red virtual denominada
VNet1 en la ubicación EastUS :
-ResourceGroupName TestRG1 `
-Location EastUS `
-Name VNet1 `
-AddressPrefix 10.1.0.0/16
Cree una configuración de subred mediante el cmdlet New-AzVirtualNetworkSubnetConfig.
-Name Frontend `
-AddressPrefix 10.1.0.0/24 `
Establezca la configuración de la subred para la red virtual mediante el cmdlet Set-AzVirtualNetwork.
Incorporación de una subred de puerta de enlace

La subred de puerta de enlace contiene las direcciones IP reservadas que usan los servicios de puerta de enlace
de la red virtual. Utilice los siguientes ejemplos para agregar una subred de puerta de enlace:
Establezca una variable para la red virtual.
$vnet = Get-AzVirtualNetwork -ResourceGroupName TestRG1 -Name VNet1
Cree la subred de puerta de enlace mediante el cmdlet Add-AzVirtualNetworkSubnetConfig.
Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.1.255.0/27 -VirtualNetwork $vnet
Establezca la configuración de la subred para la red virtual mediante el cmdlet Set-AzVirtualNetwork.
Solicitud de una dirección IP pública

Una instancia de VPN Gateway debe tener una dirección IP pública asignada de forma dinámica. Cuando crea
una conexión a una instancia de VPN Gateway, esta es la dirección IP que especifica. Utilice el siguiente ejemplo
para solicitar una dirección IP pública:
$gwpip= New-AzPublicIpAddress -Name VNet1GWIP -ResourceGroupName TestRG1 -Location 'East US' -

AllocationMethod Dynamic
Creación de la configuración de direcciones IP de la puerta de enlace

La configuración de puerta de enlace define la subred y la dirección IP pública. Use el ejemplo siguiente para
crear la configuración de la puerta de enlace:
$vnet = Get-AzVirtualNetwork -Name VNet1 -ResourceGroupName TestRG1
$gwpip.Id
Creación de la puerta de enlace de VPN

Una instancia de VPN Gateway puede tardar 45 minutos o más en crearse. Una vez completada la puerta de
enlace, puede crear una conexión entre su red virtual y otra red virtual. O bien, cree una conexión entre su red
virtual y una ubicación local. Cree una puerta de enlace de VPN mediante el cmdlet New-
AzVirtualNetworkGateway.

-Location 'East US' -IpConfigurations $gwipconfig -GatewayType Vpn `
Visualización de VPN Gateway

Puede ver la instancia de VPN Gateway mediante el cmdlet Get-AzVirtualNetworkGateway.
Get-AzVirtualNetworkGateway -Name Vnet1GW -ResourceGroup TestRG1
El resultado será similar al siguiente ejemplo:

Name :VNet1GW
ResourceGroupName :TestRG1
Location :eastus
Id :/subscriptions/<subscription ID>/resourceGroups/TestRG1/provide
rs/Microsoft.Network/virtualNetworkGateways/VNet1GW
Etag : W/"0952d-9da8-4d7d-a8ed-28c8ca0413"
ResourceGuid : dc6ce1de-2c4494-9d0b-20b03ac595
ProvisioningState : Succeeded
Tags :
IpConfigurations : [
{
"PrivateIpAllocationMethod": "Dynamic",
"Subnet": {
"Id": "/subscriptions/<subscription ID>/resourceGroups/Te
stRG1/providers/Microsoft.Network/virtualNetworks/VNet1/subnets/GatewaySubnet"
},
"PublicIpAddress": {
"Id": "/subscriptions/<subscription ID>/resourceGroups/Te
stRG1/providers/Microsoft.Network/publicIPAddresses/VNet1GWIP"
},
"Name": "default",
"Etag": "W/\"0952d-9da8-4d7d-a8ed-28c8ca0413\"",
"Id": "/subscriptions/<subscription ID>/resourceGroups/Test
RG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW/ipConfigurations/de
fault"
}
]
GatewayType : Vpn
VpnType : RouteBased
EnableBgp : False
ActiveActive : False
GatewayDefaultSite : null
Sku : {
"Capacity": 2,
"Name": "VpnGw1",
"Tier": "VpnGw1"
}
VpnClientConfiguration : null
BgpSettings : {

Para ver la dirección IP pública de su instancia de VPN Gateway, utilice el cmdlet Get-AzPublicIpAddress.
Get-AzPublicIpAddress -Name VNet1GWIP -ResourceGroupName TestRG1
En la respuesta de ejemplo, el valor de IpAddress es la dirección IP pública.

Name :VNet1GWIP
ResourceGroupName :TestRG1
Location :eastus
Id :/subscriptions/<subscription ID>/resourceGroups/TestRG1/provi
ders/Microsoft.Network/publicIPAddresses/VNet1GWIP
Etag : W/"5001666a-bc2a-484b-bcf5-ad488dabd8ca"
ResourceGuid : 3c7c481e-9828-4dae-abdc-f95b383
Tags :
PublicIpAllocationMethod : Dynamic
IpAddress : 13.90.153.3
PublicIpAddressVersion : IPv4
IdleTimeoutInMinutes : 4
IpConfiguration : {
"Id": "/subscriptions/<subscription ID>/resourceGroups/Test
RG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW/ipConfigurations/
default"
}
DnsSettings : null
Zones : {}
Sku : {
"Name": "Basic"
}
IpTags : {}
Pasos siguientes
Una vez creada la puerta de enlace, puede crear una conexión entre su red virtual y otra red virtual. O bien, cree
una conexión entre su red virtual y una ubicación local.
Creación de una conexión de sitio a sitio
Creación de una conexión de punto a sitio
Creación de una conexión a otra red virtual

Creación de una instancia de VPN Gateway basada
en rutas mediante la CLI
En este artículo se explica cómo crear rápidamente una instancia de Azure VPN Gateway basada en rutas
mediante la CLI de Azure. Una instancia de VPN Gateway se usa al crear una conexión VPN a la red local.
También puede utilizar una instancia de VPN Gateway para conectar redes virtuales.
Los pasos que se describen en este artículo crearán una red virtual, una subred, una subred de puerta de enlace
y una instancia de VPN Gateway basada en rutas (puerta de enlace de red virtual). Una puerta de enlace de red
virtual puede tardar 45 minutos o más en crearse. Una vez completada la creación de la puerta de enlace, puede
crear las conexiones. Estos pasos requieren una suscripción a Azure.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Requisitos previos
Use el entorno de Bash en Azure Cloud Shell.
Si lo prefiere, instale la CLI de Azure para ejecutar sus comandos de referencia.

Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los
pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras
opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.
Cuando se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para más
información sobre las extensiones, consulte Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están
instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.
En este artículo se necesita la versión 2.0.4 de la CLI de Azure, o cualquier versión posterior. Si usa Azure
Cloud Shell, ya está instalada la versión más reciente.
Crear un grupo de recursos

Cree un grupo de recursos con el comando az group create. Un grupo de recursos es un contenedor lógico en el
que se implementan y se administran los recursos de Azure.
az group create --name TestRG1 --location eastus

Cree una red virtual con el comando az network vnet create. En el siguiente ejemplo se crea una red virtual
denominada VNet1 en la ubicación EastUS :
az network vnet create \
-n VNet1 \
-g TestRG1 \
-l eastus \
--address-prefix 10.1.0.0/16 \
--subnet-name Frontend \
--subnet-prefix 10.1.0.0/24
Incorporación de una subred de puerta de enlace

de la red virtual. Utilice los siguientes ejemplos para agregar una subred de puerta de enlace:
az network vnet subnet create \

--vnet-name VNet1 \
-n GatewaySubnet \
-g TestRG1 \
--address-prefix 10.1.255.0/27
Solicitud de una dirección IP pública

Una instancia de VPN Gateway debe tener una dirección IP pública asignada de forma dinámica. La dirección IP
pública se asignará a la instancia de VPN Gateway creada para la red virtual. Utilice el siguiente ejemplo para
solicitar una dirección IP pública:
az network public-ip create \

-n VNet1GWIP \
-g TestRG1 \
--allocation-method Dynamic

Cree la puerta de enlace VPN con el comando az network vnet-gateway create.
Si este comando se ejecuta con el parámetro --no-wait , no se verán los comentarios o resultados. Este
parámetro --no-wait permite que la puerta de enlace se cree en segundo plano. No significa que la puerta de
enlace de VPN se cree de inmediato.
az network vnet-gateway create \

-n VNet1GW \
-l eastus \
--public-ip-address VNet1GWIP \
-g TestRG1 \
--vnet VNet1 \
--gateway-type Vpn \
--sku VpnGw1 \
--vpn-type RouteBased \
--no-wait
Una instancia de VPN Gateway puede tardar 45 minutos o más en crearse.
Visualización de VPN Gateway

az network vnet-gateway show \
-n VNet1GW \
-g TestRG1
La respuesta será similar a la siguiente:
{
"activeActive": false,
"bgpSettings": null,
"enableBgp": false,
"etag": "W/\"6c61f8cb-d90f-4796-8697\"",
"gatewayDefaultSite": null,
"gatewayType": "Vpn",
"id": "/subscriptions/<subscription
ID>/resourceGroups/TestRG11/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW",
"ipConfigurations": [
{
"etag": "W/\"6c61f8cb-d90f-4796-8697\"",
ID>/resourceGroups/TestRG11/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW/ipConfigurations/vnet
GatewayConfig0",
"name": "vnetGatewayConfig0",
"privateIpAllocationMethod": "Dynamic",
"provisioningState": "Updating",
"publicIpAddress": {
ID>/resourceGroups/TestRG11/providers/Microsoft.Network/publicIPAddresses/VNet1GWIP",
"resourceGroup": "TestRG1"
},
"resourceGroup": "TestRG1",
"subnet": {
ID>/resourceGroups/TestRG11/providers/Microsoft.Network/virtualNetworks/VNet1/subnets/GatewaySubnet",
"resourceGroup": "TestRG1"
}
}
],
"location": "eastus",
"name": "VNet1GW",
"provisioningState": "Updating",
"resourceGroup": "TestRG1",
"resourceGuid": "69c269e3-622c-4123-9231",
"sku": {
"capacity": 2,
"name": "VpnGw1",
"tier": "VpnGw1"
},
"tags": null,
"type": "Microsoft.Network/virtualNetworkGateways",
"vpnClientConfiguration": null,
"vpnType": "RouteBased"
}

Para ver la dirección IP pública asignada a la puerta de enlace, use el ejemplo siguiente:
az network public-ip show \

--name VNet1GWIP \
--resource-group TestRG11
El valor asociado al campo ipAddress es la dirección IP pública de la puerta de enlace de VPN.

Respuesta de ejemplo:
{
"dnsSettings": null,
"etag": "W/\"a12d4d03-b27a-46cc-b222-8d9364b8166a\"",
ID>/resourceGroups/TestRG1/providers/Microsoft.Network/publicIPAddresses/VNet1GWIP",
"idleTimeoutInMinutes": 4,
"ipAddress": "13.90.195.184",
"ipConfiguration": {
"etag": null,
ID>/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW/ipConfigurations/vnetG
atewayConfig0",
Cuando ya no necesite los recursos que ha creado, use az group delete para eliminar el grupo de recursos. Se
eliminarán el grupo de recursos y todos los recursos que contiene.
az group delete --name TestRG1 --yes
Pasos siguientes
Una vez creada la puerta de enlace, puede crear una conexión entre su red virtual y otra red virtual. O bien, cree
una conexión entre su red virtual y una ubicación local.
Creación de una conexión de sitio a sitio
Creación de una conexión de punto a sitio
Creación de una conexión a otra red virtual

Verificación de una conexión de VPN Gateway
En este artículo se muestra cómo comprobar una conexión de puerta de enlace de VPN para los modelos de
implementación clásico y de Resource Manager.
Portal de Azure
1. En Azure Portal, haga clic en Todos los recursos y navegue a la puerta de enlace de la red virtual.
conexión.
3. Haga clic en el nombre de la conexión que desee comprobar. En Essentials , puede ver más información
acerca de la conexión. Los valores del campo Estado serán "Correcto" y "Conectado" cuando haya
realizado una conexión correcta.
PowerShell
Para comprobar el modelo de implementación de Resource Manager usado en una conexión de puerta de
enlace de VPN con PowerShell, instale la versión más reciente de los cmdlets de PowerShell de Azure Resource
Manager.
Puede comprobar que la conexión se realizó correctamente mediante el uso del cmdlet "Get-
AzVirtualNetworkGatewayConnection", con o sin "-Debug".
1. Puede usar el siguiente ejemplo de cmdlet, configurando los valores para que coincidan con los tuyos.
Cuando se le pida, seleccione "A" para ejecutar "todo". En el ejemplo, "-Name" hace referencia al nombre
de la conexión que desea probar.
Get-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -ResourceGroupName TestRG1
2. Cuando el cmdlet haya finalizado, consulte los valores. En el ejemplo siguiente, el estado de conexión
aparece como "Conectado" y pueden verse los bytes de entrada y salida.
"connectionStatus": "Connected",
"ingressBytesTransferred": 33509044,
"egressBytesTransferred": 4142431
Azure CLI
Para comprobar el modelo de implementación de Resource Manager usado en una conexión de puerta de
enlace de VPN con la CLI de Azure, instale la versión más reciente de los comandos de CLI (2.0 o posterior).
Puede comprobar que la conexión se realizó correctamente mediante el comando az network vpn-connection
show. En el ejemplo, "--name" hace referencia al nombre de la conexión que desea probar. Mientras la conexión
aún se está estableciendo, su estado de conexión muestra "Conectando". Una vez establecida la conexión, el
estado cambia a "Conectado".
az network vpn-connection show --name VNet1toSite2 --resource-group TestRG1
Azure Portal (clásico)

En Azure Portal, puede ver el estado de la conexión de una instancia de VPN Gateway de la red virtual clásica
1. En Azure Portal, haga clic en Todos los recursos y navegue a la red virtual clásica (VNet).
2. En la página de la red virtual, seleccione el tipo de conexión que desea ver. Por ejemplo, Conexiones de
sitio a sitio .
3. En la página Conexiones de sitio a sitio , en Nombre , seleccione la conexión de sitio que desea ver.
4. En la página Propiedades , vea la información acerca de la conexión.
PowerShell (clásico)
Para comprobar el modelo de implementación clásico usado en la conexión de puerta de enlace de VPN con
PowerShell, instale las versiones más reciente de los cmdlets de Azure PowerShell. Asegúrese de descargar e
instalar el módulo de Service Management. Use "Add-AzureAccount" para iniciar sesión en el modelo de
implementación clásica.
Puede comprobar que la conexión se realizó correctamente mediante el cmdlet "Get-AzureVNetConnection".
1. Puede usar el siguiente ejemplo de cmdlet, configurando los valores para que coincidan con los tuyos. Si
el nombre de la red virtual contiene espacios, debe estar entre comillas.
Get-AzureVNetConnection "Group ClassicRG TestVNet1"
2. Cuando el cmdlet haya finalizado, consulte los valores. En el ejemplo siguiente, en ConnectivityState
aparece "Connected" y se pueden ver los bytes de entrada y salida.
ConnectivityState : Connected
EgressBytesTransferred : 181664
IngressBytesTransferred : 182080
LastConnectionEstablished : 10/19/22020 12:40:54 AM
LastEventID : 24401
LastEventMessage : The connectivity state for the local network site 'F7F7BFC7_SiteVNet4'
changed from Connecting to
Connected.
LastEventTimeStamp : 10/19/2020 12:40:54 AM
LocalNetworkSiteName : F7F7BFC7_SiteVNet4
Pasos siguientes
Puede agregar máquinas virtuales a las redes virtuales. Consulte Creación de una máquina virtual que
ejecuta Windows en el Portal de Azure para ver los pasos.
Restablecimiento de una puerta de enlace o
conexión de VPN
El restablecimiento de una puerta de enlace de VPN de Azure o de una conexión de VPN es útil si se pierde la
conectividad de VPN entre entornos locales en uno o varios túneles VPN de sitio a sitio. En esta situación, todos
tus dispositivos VPN locales funcionan correctamente, pero no pueden establecer túneles IPsec con las Puertas
de enlace de VPN de Azure. Este artículo le ayuda a restablecer una puerta de enlace de VPN o una conexión de
puerta de enlace.
Qué ocurre durante un restablecimiento

Restablecimiento de puerta de enlace
Una puerta de enlace de VPN se compone de dos instancias de VM que se ejecutan en una configuración de
modo de espera activo. Al restablecer la puerta de enlace, reinicia la puerta de enlace y después vuelve a aplicar
las configuraciones entre locales. La puerta de enlace conserva la dirección IP pública que ya tiene. Esto significa
que no tendrás que actualizar la configuración del enrutador VPN con una nueva dirección IP pública de Puerta
de enlace de VPN de Azure.
Una vez que se emite el comando para restablecer la puerta de enlace, se reiniciará inmediatamente la instancia
activa actual de la puerta de enlace de VPN de Azure. Habrá un breve intervalo durante la conmutación por
error de la instancia activa (que se está reiniciando) a la instancia en modo de espera. El intervalo debe ser
inferior a un minuto.
Si la conexión no se restaura después del primer reinicio, vuelve a ejecutar el mismo comando para reiniciar la
segunda instancia de VM (la nueva puerta de enlace activa). Si se solicitan los dos reinicios consecutivamente,
habrá un período un poco más largo durante el que se estén reiniciando ambas instancias de máquina virtual
(activa y en espera). Esto causará una interrupción mayor en la conectividad de VPN, de 30 a 45 minutos, para
que las máquinas virtuales completen los reinicios.
Después de dos reinicios, si sigue teniendo problemas de conectividad entre locales, abra una incidencia de
soporte técnico en Azure Portal.
Restablecimiento de la conexión
Cuando decide restablecer una conexión, la puerta de enlace no se reinicia. Solo se restablece y restaura la
conexión seleccionada.
Restablecimiento de una conexión

Puede restablecer fácilmente una conexión mediante Azure Portal.
1. Navegue a la Conexión que quiera restablecer. Puede encontrar el recurso de conexión si lo busca en
Todos los recursos , o bien si navega hasta "Nombre de la puer ta de enlace" -> Conexiones ->
"Nombre de la conexión" .
2. En la página Conexión , seleccione Restablecer en el menú de la izquierda.
3. En la página Restablecer , haga clic en Restablecer para restablecer la conexión.
Antes de restablecer la puerta de enlace, compruebe los elementos clave que se enumeran a continuación para
todos los túneles VPN de sitio a sitio (S2S) de IPsec. Cualquier incoherencia que haya en los elementos
provocará la desconexión de los túneles VPN de S2S. Comprobar y corregir la configuración de la puerta de
enlace local y de Azure VPN Gateway le evitará reinicios e interrupciones innecesarios para las demás
conexiones en funcionamiento de las puertas de enlace.
Compruebe los elementos siguientes antes de restablecer la puerta de enlace:
Las direcciones IP de Internet (VIP) tanto de la puerta de enlace VPN de Azure como de la puerta de enlace
VPN local están configuradas correctamente en Azure así como en las directivas VPN locales.
La clave previamente compartida tiene que ser la misma en las Puertas de enlace VPN de Azure y en las
locales.
Si aplica la configuración específica de IPsec/IKE, como el cifrado, los algoritmos hash y PFS (confidencialidad
directa total), asegúrese de que tanto las puertas de enlace de VPN de Azure como las locales tengan la
misma configuración.
Azure Portal
Puede restablecer una puerta de enlace de VPN de Resource Manager mediante Azure Portal. Si desea
restablecer una puerta de enlace clásica, consulte los pasos de PowerShell para el modelo de implementación
clásico.
problema.
PowerShell
Modelo de implementación del Administrador de recursos
NOTE
El cmdlet para restablecer una puerta de enlace es Reset-AzVir tualNetworkGateway . Antes de realizar un
restablecimiento, asegúrese de disponer de la versión más reciente de los cmdlets Az de PowerShell. En el
ejemplo siguiente, se restablece una puerta de enlace de red virtual denominada VNet1GW en el grupo de
recursos TestRG1:
$gw = Get-AzVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1

Reset-AzVirtualNetworkGateway -VirtualNetworkGateway $gw
Resultado:
Cuando reciba un resultado devuelto, se puede suponer que la puerta de enlace se restableció correctamente.
Sin embargo, no hay nada en el resultado devuelto que indique explícitamente que el restablecimiento se realizó
correctamente. Si desea examinar detenidamente el historial para ver exactamente cuándo se produjo el
restablecimiento de la puerta de enlace, puede ver esa información en Azure Portal. En el portal, vaya a
"NombreDePuer taDeEnlace" -> Resource Health .
Modelo de implementación clásica
El cmdlet para restablecer una puerta de enlace es Reset-AzureVNetGateway . Los cmdlets de Azure
PowerShell para la administración de servicios deben instalarse localmente en el escritorio. No se puede usar
Azure Cloud Shell. Antes de realizar el restablecimiento, asegúrese de disponer de la versión más reciente de los
cmdlets de PowerShell de Service Management (SM). Cuando use este comando, asegúrese de que está usando
el nombre completo de la red virtual. Las redes virtuales clásicas que se crearon con el portal tienen un nombre
largo que es necesario para PowerShell. Puede ver el nombre largo mediante "Get-AzureVNetConfig -
ExportToFile C:\Myfoldername\NetworkConfig.xml".
En el ejemplo siguiente se restablece la puerta de enlace de una red virtual denominada "Group TestRG1
TestVNet1" (que se muestra simplemente como "TestVNet1" en el portal):
Reset-AzureVNetGateway –VnetName 'Group TestRG1 TestVNet1'
Resultado:
Error :
HttpStatusCode : OK
Id : f1600632-c819-4b2f-ac0e-f4126bec1ff8
Status : Successful
RequestId : 9ca273de2c4d01e986480ce1ffa4d6d9
StatusCode : OK
Azure CLI
Para restablecer la puerta de enlace, use el comando az network vnet-gateway reset. En el ejemplo siguiente, se
restablece una puerta de enlace de red virtual denominada VNet5GW en el grupo de recursos TestRG5:
az network vnet-gateway reset -n VNet5GW -g TestRG5
Resultado:
Cuando reciba un resultado devuelto, se puede suponer que la puerta de enlace se restableció correctamente.
Sin embargo, no hay nada en el resultado devuelto que indique explícitamente que el restablecimiento se realizó
correctamente. Si desea examinar detenidamente el historial para ver exactamente cuándo se produjo el
restablecimiento de la puerta de enlace, puede ver esa información en Azure Portal. En el portal, vaya a
"NombreDePuer taDeEnlace" -> Resource Health .
Eliminación de una puerta de enlace de red virtual
mediante el portal
Este artículo lo ayuda a eliminar una puerta de enlace de red virtual. Hay un par de enfoques que puede adoptar
cuando desee eliminar una puerta de enlace correspondiente a una configuración de puerta de enlace VPN.
Si quiere eliminar todo el contenido y volver a empezar, como en el caso de un entorno de prueba, puede
eliminar el grupo de recursos. Cuando se elimina un grupo de recursos, se quitan todos los recursos de
él. Este método solo se recomienda si no desea conservar los recursos del grupo en cuestión. Con este
enfoque no podrá eliminar de forma selectiva solo unos pocos recursos.
Si desea mantener algunos de los recursos en el grupo de recursos, será algo más complicado eliminar
una puerta de enlace de red virtual. Antes de poder eliminar la puerta de enlace de red virtual, primero
debe quitar todos los recursos que dependen de la puerta de enlace. Los pasos que seguirá dependerán
del tipo de conexiones que creó y de los recursos dependientes de cada conexión.
IMPORTANT
Los pasos descritos en este artículo se aplican al modelo de implementación de Resource Manager. Para eliminar una
puerta de enlace VPN implementada mediante el modelo de implementación clásica, use los pasos que aparecen en el
artículo sobre la eliminación clásica de una puerta de enlace.

Para eliminar una puerta de enlace de red virtual, primero debe eliminar cada recurso que pertenece a la puerta
de enlace de red virtual. Los recursos deben eliminarse en un orden determinado debido a las dependencias.
Paso 1: Navegación a la puerta de enlace de red virtual
1. En Azure Portal, vaya a Todos los recursos .
2. Para abrir la página de la puerta de enlace de red virtual, vaya a la puerta de enlace de red virtual que quiere
eliminar y haga clic para seleccionarla.
Paso 2: Eliminación de conexiones
1. En la página de la puerta de enlace de red virtual, haga clic en Conexiones para ver todas las conexiones a
la puerta de enlace.
2. Haga clic en los puntos suspensivos "..." en la fila del nombre de la conexión y seleccione Eliminar en la lista
desplegable.
3. Haga clic en Sí para confirmar que quiere eliminar la conexión. Si tiene varias conexiones, elimine cada
conexión.
Paso 3: Eliminación de la puerta de enlace de red virtual
Tenga en cuenta que si tiene una configuración P2S en esta red virtual además de la configuración S2S, al
eliminar la puerta de enlace de la red virtual se desconectarán automáticamente todos los clientes P2S sin
previo aviso.
1. En la página de la puerta de enlace de la red virtual, haga clic en Introducción .
2. En la página Información general , haga clic en Eliminar para eliminar la puerta de enlace.
En este punto, se elimina la puerta de enlace de red virtual.
Para eliminar recursos adicionales
Los pasos siguientes lo ayudan a eliminar todos los recursos que ya no se usan.
Para eliminar la puerta de enlace de red local
1. En Todos los recursos , busque las puertas de enlace de red local asociadas a cada conexión.
2. En la hoja Información general de la puerta de enlace de red local, haga clic en Eliminar .
Para eliminar el recurso de dirección IP pública para la puerta de enlace
1. En Todos los recursos , busque el recurso de dirección IP pública que se asoció a la puerta de enlace. Si la
puerta de enlace de red virtual era activa-activa, verá dos direcciones IP públicas.
2. En la página Introducción general de la dirección IP pública, haga clic en Eliminar y después en Sí para
confirmar.
Para eliminar la subred de la puerta de enlace
1. En Todos los recursos , busque la red virtual.
2. En la hoja Subredes , haga clic en el elemento GatewaySubnet y después en Eliminar .
3. Haga clic en Sí para confirmar que desea eliminar la subred de la puerta de enlace.
Eliminación de una puerta de enlace VPN mediante la eliminación del

grupo de recursos
Si no desea mantener ninguno de los recursos del grupo, sino que desea empezar de nuevo, puede eliminar
dicho grupo al completo. Se trata de una forma rápida de quitarlos todos. Los siguientes pasos se aplican solo al
modelo de implementación de Resource Manager.
1. En Todos los recursos , busque el grupo de recursos y haga clic para abrir la hoja.
2. Haga clic en Eliminar . En la hoja Eliminar, revise los recursos afectados. Asegúrese de que desea eliminar
todos estos recursos. Si no es así, siga los pasos de Eliminación de una puerta de enlace VPN en la parte
superior de este artículo.
3. Para continuar, escriba el nombre del grupo de recursos que quiere eliminar y, después, haga clic en
Eliminar .
mediante PowerShell
Hay un par de enfoques que puede adoptar cuando desee eliminar una puerta de enlace de red virtual
correspondiente a una configuración de puerta de enlace VPN.
Si quiere eliminar todo el contenido y volver a empezar, como en el caso de un entorno de prueba, puede
eliminar el grupo de recursos. Cuando se elimina un grupo de recursos, se quitan todos los recursos de
él. Este método solo se recomienda si no desea conservar los recursos del grupo en cuestión. Con este
enfoque no podrá eliminar de forma selectiva solo unos pocos recursos.
Si desea mantener algunos de los recursos en el grupo de recursos, será algo más complicado eliminar
una puerta de enlace de red virtual. Antes de poder eliminar la puerta de enlace de red virtual, primero
debe quitar todos los recursos que dependen de la puerta de enlace. Los pasos que seguirá dependerán
del tipo de conexiones que creó y de los recursos dependientes de cada conexión.
Antes de comenzar
1. Descargue la versión más reciente de los cmdlets de PowerShell de Azure Resource Manager.
Descargue e instale la versión más reciente de los cmdlets de PowerShell de Azure Resource Manager. Consulte
Cómo instalar y configurar Azure PowerShell para obtener más información sobre cómo instalar y configurar
los cmdlets de PowerShell.
2. Conéctese a su cuenta de Azure.
Abre la consola de PowerShell y conéctate a tu cuenta. Use el siguiente ejemplo para conectarse:
Connect-AzAccount
Compruebe las suscripciones para la cuenta.
Get-AzSubscription
Si tiene varias suscripciones, seleccione la que quera usar.
Select-AzSubscription -SubscriptionName "Replace_with_your_subscription_name"
Eliminación de una VPN de sitio a sitio

Para eliminar una puerta de enlace de red virtual correspondiente a una configuración de S2S, primero debe
eliminar cada recurso que pertenece a la puerta de enlace de red virtual. Los recursos deben eliminarse en un
orden determinado debido a las dependencias. Cuando se trabaja con los ejemplos siguientes, deben
especificarse algunos de los valores, mientras que otros son un resultado de salida. Los siguientes valores
específicos de los ejemplos se utilizan para fines de demostración:
Nombre de la red virtual: VNet1
Nombre del grupo de recursos: RG1
Nombre de la puerta de enlace de red virtual: GW1
Los siguientes pasos se aplican al modelo de implementación de Resource Manager.
1. Obtenga la puerta de enlace de red virtual que quiera eliminar.
$GW=get-Azvirtualnetworkgateway -Name "GW1" -ResourceGroupName "RG1"
2. Compruebe si la puerta de enlace de red virtual tiene todas las conexiones.
get-Azvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object {$_.VirtualNetworkGateway1.Id

-eq $GW.Id}
$Conns=get-Azvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object
{$_.VirtualNetworkGateway1.Id -eq $GW.Id}
3. Elimine todas las conexiones.

Se le pedirá que confirme la eliminación de cada una de las conexiones.
$Conns | ForEach-Object {Remove-AzVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName

$_.ResourceGroupName}
4. Elimine la puerta de enlace de red virtual.

Se le pedirá que confirme la eliminación de la puerta de enlace. Si tiene una configuración P2S en esta red
virtual además de la configuración S2S, eliminando la puerta de enlace de red virtual se desconectarán
automáticamente todos los clientes P2S sin previo aviso.
Remove-AzVirtualNetworkGateway -Name "GW1" -ResourceGroupName "RG1"
En este momento, la puerta de enlace de virtual se ha eliminado. Puede usar los pasos siguientes para eliminar
los recursos que ya no se usan.
5. Elimine las puertas de enlace de red locales.
Obtenga la lista de las puertas de enlace de red locales correspondientes.
$LNG=Get-AzLocalNetworkGateway -ResourceGroupName "RG1" | where-object {$_.Id -In

$Conns.LocalNetworkGateway2.Id}
Elimine las puertas de enlace de red locales. Se le pedirá que confirme la eliminación de cada una de las puertas
de enlace de red locales.
$LNG | ForEach-Object {Remove-AzLocalNetworkGateway -Name $_.Name -ResourceGroupName $_.ResourceGroupName}
6. Elimine los recursos de dirección IP pública.

Obtenga las configuraciones de direcciones IP de la puerta de enlace de red virtual.
$GWIpConfigs = $Gateway.IpConfigurations
Obtenga la lista de recursos de direcciones IP públicas que se usan para esta puerta de enlace de red virtual. Si
la puerta de enlace de red virtual era activa-activa, verá dos direcciones IP públicas.
$PubIP=Get-AzPublicIpAddress | where-object {$_.Id -In $GWIpConfigs.PublicIpAddress.Id}

Elimine los recursos de IP pública.
$PubIP | foreach-object {remove-AzpublicIpAddress -Name $_.Name -ResourceGroupName "RG1"}
7. Elimine la subred de puerta de enlace y establezca la configuración.
$GWSub = Get-AzVirtualNetwork -ResourceGroupName "RG1" -Name "VNet1" | Remove-AzVirtualNetworkSubnetConfig -

Name "GatewaySubnet"
Set-AzVirtualNetwork -VirtualNetwork $GWSub
Eliminación de una puerta de enlace VPN de red virtual a red virtual

Para eliminar una puerta de enlace de red virtual correspondiente a una configuración de V2V, primero debe
2. Compruebe si la puerta de enlace de red virtual tiene todas las conexiones.

-eq $GW.Id}
Puede haber otra conexión a la puerta de enlace de red virtual que forman parte de otro grupo de recursos.
Busque conexiones adicionales en cada grupo de recursos extra. En este ejemplo, vamos a comprobar las
conexiones desde RG2. Ejecute este comando en cada grupo de recursos que tenga que puede estar conectado a
la puerta de enlace de red virtual.

-eq $GW.Id}
3. Obtenga la lista de conexiones en ambas direcciones.

Como se trata de una configuración de red virtual a red virtual, necesita la lista de conexiones en ambas
direcciones.
$ConnsL=get-Azvirtualnetworkgatewayconnection -ResourceGroupName "RG1" | where-object

En este ejemplo, vamos a comprobar las conexiones desde RG2. Ejecute este comando en cada grupo de
recursos que tenga que puede estar conectado a la puerta de enlace de red virtual.
$ConnsR=get-Azvirtualnetworkgatewayconnection -ResourceGroupName "<NameOfResourceGroup2>" | where-object
4. Elimine todas las conexiones.

Se le pedirá que confirme la eliminación de cada una de las conexiones.
$ConnsL | ForEach-Object {Remove-AzVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName

$ConnsR | ForEach-Object {Remove-AzVirtualNetworkGatewayConnection -Name $_.name -ResourceGroupName

Se le pedirá que confirme la eliminación de la puerta de enlace de red virtual. Si tiene una configuración P2S en
esta red virtual además de la configuración V2V, eliminando la puerta de enlace de red virtual se desconectarán
automáticamente todos los clientes P2S sin previo aviso.
Obtenga la lista de recursos de direcciones IP públicas que se usan para esta puerta de enlace de red virtual. Si
la puerta de enlace de red virtual era activa-activa, verá dos direcciones IP públicas.
Elimine los recursos de IP pública. Se le pedirá que confirme la eliminación de la dirección IP pública.
$PubIP | foreach-object {remove-AzpublicIpAddress -Name $_.Name -ResourceGroupName "<NameOfResourceGroup1>"}

Eliminación de una puerta de enlace VPN de sitio a sitio

Para eliminar una puerta de enlace de red virtual correspondiente a una configuración de P2S, primero debe
NOTE
Cuando se elimina la puerta de enlace VPN, se desconectarán todos los clientes conectados de la red virtual sin previo
aviso.

Se le pedirá que confirme la eliminación de la puerta de enlace de red virtual.
Obtenga la lista de direcciones IP públicas que se usan para esta puerta de enlace de red virtual. Si la puerta de
enlace de red virtual era activa-activa, verá dos direcciones IP públicas.
Elimine las direcciones IP públicas. Se le pedirá que confirme la eliminación de la dirección IP pública.
$PubIP | foreach-object {remove-AzpublicIpAddress -Name $_.Name -ResourceGroupName "<NameOfResourceGroup1>"}

Eliminación de una puerta de enlace VPN mediante la eliminación del

grupo de recursos
Si no desea mantener ninguno de los recursos del grupo, sino que desea empezar de nuevo, puede eliminar
dicho grupo al completo. Se trata de una forma rápida de quitarlos todos. Los siguientes pasos se aplican solo al
modelo de implementación de Resource Manager.
1. Obtenga una lista de todos los grupos de recursos de la suscripción:
Get-AzResourceGroup
2. Localice el grupo de recursos que desea eliminar.

Localice el grupo de recursos que quiera eliminar y vea la lista de recursos de dicho grupo. En el ejemplo, el
nombre del grupo de recursos es RG 1. Modifique el ejemplo para recuperar una lista de todos los recursos.
Find-AzResource -ResourceGroupNameContains RG1
3. Compruebe los recursos de la lista.

Cuando se devuelve la lista, revísela para comprobar que desea eliminar todos los recursos del grupo de
recursos, así como dicho grupo. Si desea mantener algunos de los recursos del grupo de recursos, utilice los
pasos de las secciones anteriores de este artículo para eliminar la puerta de enlace.
4. Elimine el grupo de recursos y los recursos.
Para eliminar el grupo de recursos y todos los recursos de este, modifique el ejemplo y ejecútelo.
Remove-AzResourceGroup -Name RG1
5. Compruebe el estado.
Azure tarda unos minutos en eliminar todos los recursos. Puede comprobar el estado de su grupo de recursos
con este cmdlet.
Get-AzResourceGroup -ResourceGroupName RG1
El resultado que se devuelve se muestra "Correcto".
ResourceGroupName : RG1
Location : eastus
Trabajo con SKU de puerta de enlace de red virtual
(SKU antiguas)
Este artículo contiene información sobre las SKU de puerta de enlace de red virtual heredadas (antiguas). Las
SKU heredadas siguen funcionando en ambos modelos de implementación para las puertas de enlace de VPN
ya creadas. Las puertas de enlace de VPN clásicas siguen usando las SKU heredadas para puertas de enlace
existentes y para nuevas puertas de enlace. Al crear nuevas puertas de enlace de VPN de Resource Manager, use
las nuevas SKU de puerta de enlace. Para más información sobre las nuevas SKU, vea Acerca de VPN Gateway.

Las SKU de puertas de enlace de VPN heredadas (antiguas) son:
Predeterminado (básico)
Estándar
HighPerformance
La VPN Gateway no utiliza la SKU de puerta de enlace de UltraPerformance. Para obtener información acerca de
la SKU de UltraPerformance, consulte la documentación de ExpressRoute.
Cuando trabaje con las SKU heredadas, tenga en cuenta lo siguiente:
Si desea utilizar un tipo de VPN PolicyBased, debe utilizar la SKU de nivel Básico. Las VPN PolicyBased (que
anteriormente se denominaba enrutamiento estático) no se admiten en otra SKU.
BGP no es compatible con la SKU de nivel Básico.
Las configuraciones de la coexistencia de ExpressRoute-VPN Gateway no se admiten en la SKU de nivel
Básico.
Las conexiones de VPN Gateway S2S activo/activo solo pueden configurarse en la SKU HighPerformance.
Puede ver los precios de las puertas de enlace heredadas en la sección Puer tas de enlace de Vir tual
Network de la página Precios de ExpressRoute.
Rendimiento agregado estimado por SKU

En la tabla siguiente se muestran los tipos de puerta de enlace y el rendimiento agregado estimado por SKU de
puerta de enlace. Esta tabla se aplica a los modelos de implementación tanto clásico como Resource Manager.
Los precios difieren entre las SKU de puerta de enlace. Para obtener más información, vea Precios de VPN
Gateway.
Tenga en cuenta que la SKU de la puerta de enlace de UltraPerformance no se representa en esta tabla. Para
obtener información acerca de la SKU de UltraPerformance, consulte la documentación de ExpressRoute.
REN DIM IEN TO DE VP N GAT EWAY Y

REN DIM IEN TO DE T ÚN EL ES IP SEC M Á X. P UERTA DE EN L A C E EXP RESSRO UT E
VP N GAT EWAY ( 1) DE VP N GAT EWAY ( 2) DE EXP RESSRO UT E C O EXIST EN
SKU básica (3)(5) 100 Mbps 10 500 Mbps (6) No

(6)
REN DIM IEN TO DE VP N GAT EWAY Y
REN DIM IEN TO DE T ÚN EL ES IP SEC M Á X. P UERTA DE EN L A C E EXP RESSRO UT E
VP N GAT EWAY ( 1) DE VP N GAT EWAY ( 2) DE EXP RESSRO UT E C O EXIST EN
SKU estándar (4) 100 Mbps 10 1000 Mbps Sí

(5)
SKU de alto 200 Mbps 30 2000 Mbps Sí

rendimiento (4)
(1) El rendimiento de la VPN es una estimación aproximada basada en las medidas entre redes virtuales en la
misma región de Azure. No es un rendimiento garantizado para las conexiones entre locales a través de Internet.
Es el valor máximo posible del rendimiento.
(2) El número de túneles hace referencia a VPN basadas en enrutamiento. Una VPN basada en directivas solo
puede admitir un túnel VPN de sitio a sitio.
(3) BGP no es compatible con la SKU básica.
(4) Las VPN basadas en directivas no son compatibles con esta SKU. Solo son compatibles con la SKU básica.
(5) Esta SKU no admite conexiones de VPN Gateway S2S activo/activo. Activo/activo solo es compatible con la
SKU HighPerformance.
(6) La SKU de nivel Básico está obsoleta para su uso con ExpressRoute.
Configuraciones admitidas por el tipo de VPN y SKU

La tabla siguiente enumera los requisitos para las puertas de enlace VPN basadas en enrutamientos y directivas.
Esta tabla se aplica a los modelos de implementación del Administrador de recursos y clásico. Para el modelo
clásico, las puertas de enlace de VPN basadas en directivas son las mismas que las puertas de enlace estáticas y
las basadas en enrutamientos son las mismas que las dinámicas.
VP N GAT EWAY DE
Conectividad de Configuración de Configuración de Configuración de Configuración de

sitio a sitio...(S2S) VPN de PolicyBased VPN de RouteBased VPN de RouteBased VPN de RouteBased
Conectividad de No compatible Compatible (puede Compatible (puede Compatible (puede

punto a sitio (P2S) coexistir con S2S) coexistir con S2S) coexistir con S2S)
Método de Clave precompartida Clave precompartida Clave precompartida Clave precompartida

autenticación para la conectividad para la conectividad para la conectividad
de S2S, Certificados de S2S, Certificados de S2S, Certificados
para la conectividad para la conectividad para la conectividad
de P2S de P2S de P2S
Número máximo 1 10 10 30
de conexiones S2S
Número máximo No compatible 128 128 128

de conexiones P2S
VP N GAT EWAY DE
Compatibilidad No compatible No compatible Compatible Compatible

con enrutamiento
activo (BGP)
Cambio del tamaño de una puerta de enlace

Puede cambiar el tamaño de la puerta de enlace a una SKU de puerta de enlace dentro de la misma familia de la
SKU. Por ejemplo, si tiene una SKU Estándar, puede cambiar a una SKU HighPerformance. Sin embargo, no se
puede cambiar el tamaño de las puertas de enlace de VPN entre las familias de SKU antiguas y las nuevas. Por
ejemplo, no se puede pasar de una SKU Estándar a una SKU VpnGw2, o de una SKU Básica a VpnGw1.
Resource Manager
Para cambiar el tamaño de una puerta de enlace para el modelo de implementación de Resource Manager
mediante PowerShell, use el siguiente comando:
$gw = Get-AzVirtualNetworkGateway -Name vnetgw1 -ResourceGroupName testrg

Resize-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -GatewaySku HighPerformance
También puede cambiar el tamaño de una puerta de enlace en Azure Portal.

Clásico
Para cambiar el tamaño de una puerta de enlace al modelo de implementación clásica, debe usar los cmdlets de
PowerShell de administración de servicios. Use el comando siguiente:
Resize-AzureVirtualNetworkGateway -GatewayId <Gateway ID> -GatewaySKU HighPerformance
Cambio a las nuevas SKU de puerta de enlace

Si está trabajando con el modelo de implementación de Resource Manager, puede cambiar a las nuevas SKU de
puerta de enlace. Al cambiar de una SKU de puerta de enlace heredada a una nueva SKU, se elimina la puerta de
enlace de la red virtual existente y se crea una nueva.
Flujo de trabajo:
1. Elimine las conexiones a la puerta de enlace de la red virtual.
2. Elimine la puerta de enlace VPN Gateway antigua.
3. Cree la puerta de enlace VPN Gateway nueva.
4. Actualice los dispositivos VPN locales con la nueva dirección IP de la puerta de enlace VPN Gateway (para las
conexiones de sitio a sitio).
5. Actualice el valor de la dirección IP de puerta de enlace para las puertas de enlace de red local de red virtual
a red virtual que se conectarán a esta puerta de enlace.
6. Descargue los nuevos paquetes de configuración de VPN de cliente para los clientes de P2S que se vayan a
conectar a la red virtual a través de esta puerta de enlace VPN Gateway.
7. Vuelva a crear las conexiones a la puerta de enlace de la red virtual.
Consideraciones:
Para pasar a las nuevas SKU, la puerta de enlace de la red virtual debe estar en el modelo de implementación
de Resource Manager.
Si tiene una puerta de enlace VPN clásica, debe seguir utilizando las SKU heredadas más antiguas para esa
puerta de enlace; sin embargo, puede cambiar el tamaño entre las SKU heredadas. No se puede cambiar as
las nuevas SKU.
Tendrá un tiempo de inactividad de conectividad cuando cambie de una SKU heredada a una nueva.
Al cambiar a una nueva SKU de puerta de enlace, cambiará la dirección IP pública de la puerta de enlace de la
red virtual. Esto sucede incluso si especifica el mismo objeto de dirección IP pública que usó anteriormente.
Pasos siguientes
Para más información acerca de las nuevas SKU de puerta de enlace, consulte SKU de puerta de enlace.
Para más información sobre los valores de configuración, vea Acerca de la configuración de VPN Gateway.
Tutorial: Creación de una conexión de sitio a sitio
y Azure. En este tutorial se muestra cómo usar Azure Portal para crear una conexión de puerta de enlace VPN de
sitio a sitio desde la red local a la red virtual. También puede crear esta configuración mediante Azure
PowerShell o la CLI de Azure.

Prerrequisitos

Cree una red virtual (VNet) con los siguientes valores:
Nombre: VNet1
NOTE

valores:
Resource Manager.
necesite.

Firewall : Disabled

Creación de la puerta de enlace
Cree una puerta de enlace de VPN con los siguientes valores:
Nombre: VNet1GW
SKU: VpnGw1
Red vir tual: VNet1
selecciónela.
en esta página.
de enlace.
enlace.
pública.
IMPORTANT

enlace.

La puerta de enlace de red local es un objeto específico que representa la ubicación local (el sitio) para fines de
enrutamiento. Asigne al sitio un nombre al que Azure pueda hacer referencia y, luego, especifique la dirección IP
del dispositivo VPN local con la que creará una conexión. Especifique también los prefijos de dirección IP que se
enrutarán a través de la puerta de enlace VPN al dispositivo VPN. Los prefijos de dirección que especifique son
los prefijos que se encuentran en la red local. Si la red local cambia o necesita cambiar la dirección IP pública del
dispositivo VPN, puede actualizar fácilmente los valores más adelante.
Cree una puerta de enlace de red local con los siguientes valores:
Nombre: Site1
red local . Busque la puer ta de enlace de red local en Marketplace , en los resultados de la búsqueda
y selecciónela. Se abre la página Crear puer ta de enlace de red local .
red local.

podrá conectarse.
Nombre de dominio completo : si tiene una dirección IP pública dinámica que podría
cambiar después de un cierto período de tiempo, que normalmente determina el proveedor de
servicios de Internet, puede usar un nombre DNS constante con un servicio DNS dinámico que
apunte a la dirección IP pública actual del dispositivo VPN. Azure VPN Gateway resolverá el
nombre de dominio completo para determinar la dirección IP pública a la que se va a conectar.
obligatorio.
NOTE
Azure VPN Gateway solo admite una dirección IPv4 para cada nombre de dominio completo. Si el nombre de
dominio se resuelve en varias direcciones IP, Azure VPN Gateway usará la primera dirección IP que devuelvan
los servidores DNS. Para eliminar la incertidumbre, se recomienda que el nombre de dominio completo siempre
se resuelva en una sola dirección IPv4. No se admite IPv6.
Azure VPN Gateway mantiene una caché DNS que se actualiza cada 5 minutos. La puerta de enlace intenta
resolver los nombres de dominio completos solo para los túneles desconectados. Al restablecer la puerta de
enlace también se desencadenará la resolución del nombre de dominio completo.

Portal, PowerShell o la CLI. Para buscar la dirección IP pública de la puerta de enlace de VPN mediante Azure
Portal, vaya a Puer tas de enlace de red vir tual y seleccione el nombre de su puerta de enlace.
S2S.
Para ver una introducción a la configuración de dispositivos VPN, consulte Información general sobre
configuraciones de dispositivos VPN de terceros.

Cree una conexión con los valores siguientes:
Nombre de la puer ta de enlace de red local: Site1
Nombre de la conexión: VNet1toSite1
Clave compar tida: en este ejemplo, usamos abc123. Sin embargo, puede usar cualquiera compatible con el
hardware VPN. Lo importante es que los valores coincidan en ambos lados de la conexión.
1. Abra la página de la puerta de enlace de red virtual. Para desplazarse a la puerta de enlace, vaya a
Nombre de la red vir tual -> Información general -> Dispositivos conectados -> Nombre de
la puer ta de enlace , aunque hay otras formas de hacerlo.
2. En la página de la puerta de enlace, seleccione Conexiones . En la parte superior de la página
Conexiones, seleccione +Agregar para abrir la página Agregar conexión .
3. En la página Agregar conexión , configure los valores de la conexión.
Nombre: asigne un nombre a la conexión.
Tipo de conexión : Seleccione Sitio a sitio (IPSec) .
Puer ta de enlace de red vir tual: el valor es fijo porque se conecta desde esta puerta de enlace.
Puer ta de enlace de red local: Seleccione Elegir una puer ta de enlace de red local y
seleccione la puerta de enlace de red local que quiere utilizar.
Clave compar tida: este valor debe ser el mismo que el que usa para el dispositivo VPN local. En el
ejemplo se usa "abc123", pero puede (y debería) utilizar algo más complejo. Lo importante es que el
valor que especifique aquí debe ser el mismo que el que se especificó al configurar el dispositivo VPN.
Deje la casilla Usar la dirección IP privada de Azure desactivada.
Deje la casilla Habilitar BGP desactivada.
Seleccione IKEv2 .
Los restantes valores de Suscripción , Grupo de recursos y Ubicación son fijos.
4. Haga clic en Aceptar para crear la conexión. El mensaje Creando la conexión aparecerá de forma
intermitente en la pantalla.
5. La conexión se puede ver en la página Conexiones de la puerta de enlace de red virtual. El valor de
Estado pasará de Desconocido a Conectando y luego a Correcto.

conexión.

$VMs = Get-AzVM
{
}
Pasos opcionales
Incorporación de conexiones adicionales a la puerta de enlace
Puede agregar conexiones adicionales, siempre que ninguno de los espacios de direcciones se superpongan
entre las conexiones.
1. Para agregar otra conexión, vaya a la puerta de enlace de VPN y, luego, haga clic en Conexiones para abrir
la página Conexiones.
2. Seleccione + Agregar para agregar la conexión. Ajuste el tipo de conexión para reflejar una conexión entre
redes virtuales (si se conecta a otra puerta de enlace de red virtual), o de sitio a sitio.
3. Si se conecta de sitio a sitio y aún no ha creado una puerta de enlace de red local para el sitio al que desea
conectarse, puede crear una.
4. Especifique la clave compartida que quiera usar y, luego, seleccione Aceptar para crear la conexión.

pero no pueden establecer túneles IPsec con las Puertas de enlace de VPN de Azure.
problema.
Consideraciones adicionales sobre la configuración
Las configuraciones S2S se pueden personalizar de varias maneras. Vea los siguientes artículos para más
información:
Para información acerca de la tunelización forzada, consulte la Acerca de la tunelización forzada.
Para información acerca de cómo limitar el tráfico de red a los recursos de una red virtual, vea Seguridad de
red.
recursos:
Pasos siguientes
Una vez configurada la conexión S2S, podrá agregar una conexión P2S a la misma puerta de enlace.
Creación de una red virtual con una conexión VPN
de sitio a sitio mediante PowerShell
Este artículo muestra cómo usar PowerShell para crear una conexión de puerta de enlace VPN de sitio a sitio
desde la red local a la red virtual. Los pasos descritos en este artículo se aplican al modelo de implementación
de Resource Manager. También se puede crear esta configuración con una herramienta o modelo de
implementación distintos, mediante la selección de una opción diferente en la lista siguiente:
Se utiliza una conexión de puerta de enlace VPN de sitio a sitio para conectar su red local a una red virtual de
Azure a través de un túnel VPN de IPsec/IKE (IKEv1 o IKEv2). Este tipo de conexión requiere un dispositivo VPN
local que tenga una dirección IP pública asignada. Para más información acerca de las puertas de enlace VPN,
consulte Acerca de VPN Gateway.
Antes de empezar
Antes de comenzar con la configuración, compruebe que se cumplen los criterios siguientes:
Azure PowerShell
Azure PowerShell.
Valores del ejemplo
Los ejemplos de este artículo utilizan los valores siguientes. Puede usar estos valores para crear un entorno de
prueba o hacer referencia a ellos para comprender mejor los ejemplos de este artículo.
#Example values
VnetName = VNet1
ResourceGroup = TestRG1
Location = East US
AddressSpace = 10.1.0.0/16
SubnetName = Frontend
Subnet = 10.1.0.0/24
GatewaySubnet = 10.1.255.0/27
LocalNetworkGatewayName = Site1
LNG Public IP = <On-premises VPN device IP address>
Local Address Prefixes = 10.101.0.0/24, 10.101.1.0/24
Gateway Name = VNet1GW
PublicIP = VNet1GWPIP
Gateway IP Config = gwipconfig1
VPNType = RouteBased
GatewayType = Vpn
ConnectionName = VNet1toSite1
1. Creación de una red virtual y una puerta de enlace

Si no tiene una red virtual, créela. Al crear una red virtual, compruebe que los espacios de direcciones
especificados no se superponen con los espacios de direcciones que existen en la red local.
NOTE
Para que esta red virtual se conecte a una ubicación local, debe coordinarse con el administrador de la red local para
delimitar un intervalo de direcciones IP que pueda usar específicamente para esta red virtual. Si existe un intervalo de
direcciones duplicado en ambos lados de la conexión VPN, el tráfico no se enrutará como cabría esperar. Además, si desea
conectar esta red virtual a otra red virtual, el espacio de direcciones no se puede superponer con otra red virtual. Por
consiguiente, tenga cuidado al planear la configuración de red.

Contiene las direcciones IP que usan los recursos y servicios de puerta de enlace de la red virtual. La subred
debe llamarse "GatewaySubnet" para que Azure implemente los recursos de la puerta de enlace. No se puede
especificar otra subred en la que implementar los recursos de la puerta de enlace. Si no dispone de una subred
llamada "GatewaySubnet", al crear la puerta de enlace de VPN, se producirá un error.
IMPORTANT
Creación de una red virtual y una puerta de enlace

Este ejemplo crea una red virtual y una subred de la puerta de enlace. Si ya tiene una red virtual que necesite
agregar a una subred de puerta de enlace, consulte Para agregar una subred de puerta de enlace a una red
virtual que ya ha creado.
Cree un grupo de recursos:
New-AzResourceGroup -Name TestRG1 -Location 'East US'
Cree la red virtual.

1. Establezca las variables.
$subnet1 = New-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.1.255.0/27

$subnet2 = New-AzVirtualNetworkSubnetConfig -Name 'Frontend' -AddressPrefix 10.1.0.0/24
2. Cree la red virtual.
New-AzVirtualNetwork -Name VNet1 -ResourceGroupName TestRG1 `

-Location 'East US' -AddressPrefix 10.1.0.0/16 -Subnet $subnet1, $subnet2
Para agregar una subred de puerta de enlace a una red virtual que ya ha creado
Use los pasos de esta sección si ya tiene una red virtual, aunque deberá agregar una subred de puerta de enlace.
$vnet = Get-AzVirtualNetwork -ResourceGroupName TestRG1 -Name VNet1
2. Cree la subred de la puerta de enlace.
Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.1.255.0/27 -VirtualNetwork

$vnet
3. Establezca la configuración.
Set-AzVirtualNetwork -VirtualNetwork $vnet
2.
Creación de la puerta de enlace de red local
La puerta de enlace de red local (LNG) suele hacer referencia a la ubicación local. No es lo mismo que una
puerta de enlace de red. Asigne al sitio un nombre al que Azure pueda hacer referencia y, luego, especifique la
dirección IP del dispositivo VPN local con la que creará una conexión. Especifique también los prefijos de
dirección IP que se enrutarán a través de la puerta de enlace VPN al dispositivo VPN. Los prefijos de dirección
que especifique son los prefijos que se encuentran en la red local. Puede actualizar fácilmente estos prefijos si
cambia su red local.
Use los valores siguientes:
GatewayIPAddress es la dirección IP del dispositivo VPN local.
AddressPrefix es el espacio de direcciones local.
Para agregar una puerta de enlace de red local con un único prefijo de dirección:
New-AzLocalNetworkGateway -Name Site1 -ResourceGroupName TestRG1 `

-Location 'East US' -GatewayIpAddress '23.99.221.164' -AddressPrefix '10.101.0.0/24'
Para agregar una puerta de enlace de red local con varios prefijos de dirección:
New-AzLocalNetworkGateway -Name Site1 -ResourceGroupName TestRG1 `

-Location 'East US' -GatewayIpAddress '23.99.221.164' -AddressPrefix @('10.101.0.0/24','10.101.1.0/24')
Para modificar los prefijos de dirección IP de su puerta de enlace de red local:

A veces los prefijos de la puerta de enlace de red local cambian. Los pasos necesarios para modificar los prefijos
de las direcciones IP dependen de si creó una conexión de puerta de enlace de VPN. Consulte la sección Para
modificar los prefijos de dirección IP de una puerta de enlace de red local de este artículo.
3. Solicite una dirección IP pública

Una puerta de enlace VPN debe tener una dirección IP pública. Primero se solicita el recurso de la dirección IP y,
después, se hace referencia a él al crear la puerta de enlace de red virtual. La dirección IP se asigna
dinámicamente al recurso cuando se crea la puerta de enlace VPN.
Actualmente, VPN Gateway solo admite la asignación de direcciones IP públicas dinámicas. No se puede solicitar
una asignación de direcciones IP públicas estáticas. Sin embargo, esto no significa que la dirección IP vaya a
cambiar una vez que se haya asignado a una puerta de enlace VPN. La única vez que la dirección IP pública
cambia es cuando la puerta de enlace se elimina y se vuelve a crear. No cambia cuando se cambia el tamaño, se
restablece o se realizan actualizaciones u otras operaciones de mantenimiento interno de una puerta de enlace
VPN.
Solicite una dirección IP pública que se asignará a la puerta de enlace VPN de la red virtual.
$gwpip= New-AzPublicIpAddress -Name VNet1GWPIP -ResourceGroupName TestRG1 -Location 'East US' -

4. Creación de la configuración de direccionamiento IP de la puerta

de enlace
La configuración de puerta de enlace define la subred ("GatewaySubnet") y la dirección IP pública que se van a
usar. Use el ejemplo siguiente para crear la configuración de la puerta de enlace:
$vnet = Get-AzVirtualNetwork -Name VNet1 -ResourceGroupName TestRG1
$gwpip.Id
5. Creación de la puerta de enlace VPN

Cree la puerta de enlace VPN de la red virtual.
El valor -GatewayType para una configuración de sitio a sitio es Vpn. El tipo de puerta de enlace siempre es
específico de la configuración que se va a implementar. Por ejemplo, otras configuraciones de puerta de
enlace pueden requerir GatewayType ExpressRoute.
El valor de -VpnType puede ser RouteBased (la llamada puerta de enlace dinámica en algunos documentos) o
PolicyBased (la llamada puerta de enlace estática en algunos documentos). Para más información sobre los
tipos de Puertas de enlace de VPN, consulte Información acerca de VPN Gateway.
Seleccione la SKU de la puerta de enlace que desea utilizar. Hay limitaciones de configuración para
determinadas SKU. Consulte SKU de puertas de enlace para más información. Si se produce un error al crear
la puerta de enlace VPN con respecto a - GatewaySku, compruebe que tiene instalada la versión más reciente
de los cmdlets de PowerShell.

-Location 'East US' -IpConfigurations $gwipconfig -GatewayType Vpn `
Después de ejecutar este comando, la configuración de la puerta de enlace puede tardar hasta 45 minutos en
completarse.
6. Configurar el dispositivo VPN

dispositivo VPN. Para configurar el dispositivo VPN, necesita los elementos siguientes:
Una clave compartida. Se trata de la misma clave compartida que se especifica al crear la conexión VPN
de sitio a sitio. En estos ejemplos se utiliza una clave compartida básica. Se recomienda que genere y
utilice una clave más compleja.
La dirección IP pública de la puerta de enlace de red virtual. Puede ver la dirección IP pública mediante
Azure Portal, PowerShell o la CLI. Para buscar la dirección IP pública de la puerta de enlace de red virtual
con PowerShell, utilice el siguiente ejemplo. En este ejemplo, VNet1GWPIP es el nombre del recurso de
dirección IP pública que creó en un paso anterior.
Get-AzPublicIpAddress -Name VNet1GWPIP -ResourceGroupName TestRG1

S2S.
Para ver información general sobre la configuración de dispositivos VPN, consulte Introducción a la
configuración de dispositivos VPN.
7. Creación de la conexión VPN

Ahora va a crear la conexión VPN de sitio a sitio entre la puerta de enlace de red virtual y el dispositivo VPN.
Asegúrese de reemplazar los valores por los suyos. La clave compartida debe coincidir con el valor usado para
la configuración del dispositivo VPN. Tenga en cuenta que el valor de '-ConnectionType' para la configuración
sitio a sitio es IPsec .
$gateway1 = Get-AzVirtualNetworkGateway -Name VNet1GW -ResourceGroupName TestRG1

$local = Get-AzLocalNetworkGateway -Name Site1 -ResourceGroupName TestRG1
2. Cree la conexión.
New-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -ResourceGroupName TestRG1 `

-Location 'East US' -VirtualNetworkGateway1 $gateway1 -LocalNetworkGateway2 $local `
-ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Pasado un momento, se establecerá la conexión.
8. Comprobación de la conexión VPN

Hay varias maneras diferentes de comprobar la conexión VPN.

$VMs = Get-AzVM
{
}
Para modificar los prefijos de dirección IP de una puerta de enlace de

red local
Si cambian los prefijos de las direcciones IP que desea enrutar a una ubicación local, puede modificar la puerta
de enlace de red local. Al usar estos ejemplos, modifique los valores para que coincidan con su entorno.
Para agregar prefijos de dirección adicionales:
1. Establezca la variable para LocalNetworkGateway.
2. Modifique los prefijos.
Set-AzLocalNetworkGateway -LocalNetworkGateway $local `

-AddressPrefix @('10.101.0.0/24','10.101.1.0/24','10.101.2.0/24')
Para quitar prefijos de dirección:

Omita los prefijos que ya no necesite. En este ejemplo, ya no necesitamos el prefijo 10.101.2.0/24 (del ejemplo
anterior), por lo que se actualiza la puerta de enlace de la red local, sin incluir ese prefijo.
2. Establezca la puerta de enlace con los prefijos actualizados.

-AddressPrefix @('10.101.0.0/24','10.101.1.0/24')
Para modificar la dirección IP de una puerta de enlace de red local

Si el dispositivo VPN al que desea conectarse ha cambiado su dirección IP pública, debe modificar la puerta de
enlace de red local para reflejar ese cambio. Al modificar este valor, también puede modificar al mismo tiempo
los prefijos de dirección. Asegúrese de usar el nombre existente de la puerta de enlace de la red local para
sobrescribir la configuración actual. Si usa otro nombre, creará una nueva puerta de enlace de red local, en lugar
de sobrescribir la existente.
New-AzLocalNetworkGateway -Name Site1 `
-Location "East US" -AddressPrefix @('10.101.0.0/24','10.101.1.0/24') `
-GatewayIpAddress "5.4.3.2" -ResourceGroupName TestRG1
Para eliminar una conexión de puerta de enlace

Si no conoce el nombre de la conexión, puede encontrarlo mediante el cmdlet "Get-
AzVirtualNetworkGatewayConnection".
Remove-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 `

-ResourceGroupName TestRG1
Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Consulte Virtual
Machines para más información.
Para obtener información acerca de cómo crear una conexión VPN de sitio a sitio mediante una plantilla de
Azure Resource Manager, consulte Create a Site-to-Site VPN Connection (Creación de una conexión VPN de
sitio a sitio).
Para obtener información acerca de cómo crear una conexión VPN entre redes virtuales mediante una
plantilla de Azure Resource Manager, consulte Deploy HBase geo replication (Implementación de replicación
geográfica de HBase).
Creación de una red virtual con una conexión VPN
de sitio a sitio mediante la CLI
Este artículo muestra cómo utilizar la CLI de Azure para crear una conexión de puerta de enlace VPN de sitio a
sitio desde la red local a la red virtual. Los pasos descritos en este artículo se aplican al modelo de
implementación de Resource Manager. También se puede crear esta configuración con una herramienta o
modelo de implementación distintos, mediante la selección de una opción diferente en la lista siguiente:
Antes de empezar
Use el entorno de Bash en Azure Cloud Shell.
Si lo prefiere, instale la CLI de Azure para ejecutar sus comandos de referencia.

Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los
pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras
opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.
Cuando se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para más
información sobre las extensiones, consulte Uso de extensiones con la CLI de Azure.
Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están
instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.
En este artículo se necesita la versión 2.0 o posterior de la CLI de Azure. Si usa Azure Cloud Shell, ya está
instalada la versión más reciente.
Valores del ejemplo
Puede usar los siguientes valores para crear un entorno de prueba o hacer referencia a ellos para comprender
mejor los ejemplos de este artículo:
#Example values
VnetName = TestVNet1
ResourceGroup = TestRG1
Location = eastus
AddressSpace = 10.11.0.0/16
SubnetName = Subnet1
Subnet = 10.11.0.0/24
LocalNetworkGatewayName = Site2
LNG Public IP = <VPN device IP address>
LocalAddrPrefix1 = 10.0.0.0/24
LocalAddrPrefix2 = 20.0.0.0/24
GatewayName = VNet1GW
PublicIP = VNet1GWIP
VPNType = RouteBased
GatewayType = Vpn
ConnectionName = VNet1toSite2
1. su suscripción
Si decide ejecutar la CLI de forma local, conéctese a su suscripción. Si está usando Azure Cloud Shell en el
explorador, no necesita conectarse a su suscripción. Se conectará automáticamente en Azure Cloud Shell. Sin
embargo, es posible que quiera comprobar si está usando la suscripción correcta después de conectarse.
Inicie sesión en la suscripción de Azure con el comando az login y siga las instrucciones que aparecen en
pantalla. Para más información sobre el inicio de sesión, consulte Introducción a la CLI de Azure.
az login
Si tiene más de una suscripción de Azure, enumere las suscripciones de la cuenta.
az account list --all
Especifique la suscripción que desea usar.
az account set --subscription <replace_with_your_subscription_id>
2. Crear un grupo de recursos

En el ejemplo siguiente se crea un grupo de recursos con el nombre 'TestRG1' en la ubicación 'eastus'. Si ya
tiene un grupo de recursos en la región que desea crear la red virtual, puede utilizarlo.
az group create --name TestRG1 --location eastus
3. Creación de una red virtual

Si aún no tiene una red virtual, créela con el comando az network vnet create. Al crear una red virtual,
compruebe que los espacios de direcciones especificados no se superponen con los espacios de direcciones que
existen en la red local.
NOTE
Para que esta red virtual se conecte a una ubicación local, debe coordinarse con el administrador de la red local para
delimitar un intervalo de direcciones IP que pueda usar específicamente para esta red virtual. Si existe un intervalo de
direcciones duplicado en ambos lados de la conexión VPN, el tráfico no se enrutará como cabría esperar. Además, si desea
conectar esta red virtual a otra red virtual, el espacio de direcciones no se puede superponer con otra red virtual. Por
consiguiente, tenga cuidado al planear la configuración de red.
El siguiente ejemplo crea una red virtual denominada 'TestVNet1' y una subred llamada 'Subnet1'.
az network vnet create --name TestVNet1 --resource-group TestRG1 --address-prefix 10.11.0.0/16 --location
eastus --subnet-name Subnet1 --subnet-prefix 10.11.0.0/24
4.
Creación de la subred de la puerta de enlace
Contiene las direcciones IP que usan los recursos y servicios de puerta de enlace de la red virtual. La subred
debe llamarse "GatewaySubnet" para que Azure implemente los recursos de la puerta de enlace. No se puede
especificar otra subred en la que implementar los recursos de la puerta de enlace. Si no dispone de una subred
llamada "GatewaySubnet", al crear la puerta de enlace de VPN, se producirá un error.
Use el comando az network vnet subnet create para la subred de la puerta de enlace.
az network vnet subnet create --address-prefix 10.11.255.0/27 --name GatewaySubnet --resource-group TestRG1
--vnet-name TestVNet1
IMPORTANT
5. Creación de la puerta de enlace de red local
La puerta de enlace de red local suele hacer referencia a la ubicación local. Asigne al sitio un nombre al que
Azure pueda hacer referencia y, luego, especifique la dirección IP del dispositivo VPN local con la que creará una
conexión. Especifique también los prefijos de dirección IP que se enrutarán a través de la puerta de enlace VPN
al dispositivo VPN. Los prefijos de dirección que especifique son los prefijos que se encuentran en la red local.
Puede actualizar fácilmente estos prefijos si cambia su red local.
--gateway-ip-address es la dirección IP del dispositivo VPN local.
--local-address-prefixes son los espacios de direcciones locales.
Use el comando az network local-gateway create para agregar una puerta de enlace de red local con varios
prefijos de direcciones:
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 --resource-group TestRG1 --

local-address-prefixes 10.0.0.0/24 20.0.0.0/24
6. Solicite una dirección IP pública

Una puerta de enlace VPN debe tener una dirección IP pública. Primero se solicita el recurso de la dirección IP y,
después, se hace referencia a él al crear la puerta de enlace de red virtual. La dirección IP se asigna
dinámicamente al recurso cuando se crea la puerta de enlace VPN. Actualmente, VPN Gateway solo admite la
asignación de direcciones IP públicas dinámicas. No se puede solicitar una asignación de direcciones IP públicas
estáticas. 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 la dirección IP pública cambia es cuando la puerta de enlace se elimina y se
vuelve a crear. No cambia cuando se cambia el tamaño, se restablece o se realizan actualizaciones u otras
Use el comando az network public-ip create para solicitar una dirección IP pública dinámica.
az network public-ip create --name VNet1GWIP --resource-group TestRG1 --allocation-method Dynamic

Cree la puerta de enlace VPN de la red virtual. Crear una puerta de enlace VPN puede tardar 45 minutos o más
en completarse.
El valor ---gateway-type para una configuración de sitio a sitio es Vpn. El tipo de puerta de enlace siempre es
específico de la configuración que se va a implementar. Para más información, consulte Tipos de puerta de
enlace.
El valor de --vpn-type puede ser RouteBased (denominada puerta de enlace dinámica en algunos
documentos) o PolicyBased (denominada puerta de enlace estática en algunos documentos). La
configuración es específica según los requisitos del dispositivo al que se va a conectar. Para más información
sobre los tipos de puertas de enlace de VPN, consulte Acerca de la información de VPN Gateway.
Seleccione la SKU de la puerta de enlace que desea utilizar. Hay limitaciones de configuración para
determinadas SKU. Consulte SKU de puertas de enlace para más información.
Cree la puerta de enlace VPN con el comando az network vnet-gateway create. Si este comando se ejecuta con
el parámetro '--no-wait', no se verán los comentarios o resultados. Este parámetro permite que la puerta de
enlace se cree en segundo plano. Tarda aproximadamente 45 minutos en crear una puerta de enlace.
az network vnet-gateway create --name VNet1GW --public-ip-address VNet1GWIP --resource-group TestRG1 --vnet
TestVNet1 --gateway-type Vpn --vpn-type RouteBased --sku VpnGw1 --no-wait
8. Configurar el dispositivo VPN

dispositivo VPN. Al configurar el dispositivo VPN, necesita lo siguiente:
Una clave compartida. Se trata de la misma clave compartida que se especifica al crear la conexión VPN
de sitio a sitio. En estos ejemplos se utiliza una clave compartida básica. Se recomienda que genere y
utilice una clave más compleja.
La dirección IP pública de la puerta de enlace de red virtual. Puede ver la dirección IP pública mediante
Azure Portal, PowerShell o la CLI. Para buscar la dirección IP pública de la puerta de enlace de red virtual,
use el comando az network public-ip list. Para facilitar la lectura, la salida muestra la lista de direcciones
IP públicas en formato de tabla.
az network public-ip list --resource-group TestRG1 --output table

S2S.
9. Creación de la conexión VPN

Preste especial atención al valor de la clave compartida, que debe coincidir con el valor de la clave compartida
configurada para el dispositivo VPN.
Cree la conexión mediante el comando az network vpn-connection create.
az network vpn-connection create --name VNet1toSite2 --resource-group TestRG1 --vnet-gateway1 VNet1GW -l

eastus --shared-key abc123 --local-gateway2 Site2
Pasado un momento, se establecerá la conexión.
10. Comprobación de la conexión VPN

Si desea usar otro método para comprobar la conexión, consulte Comprobación de una conexión de VPN
Gateway.

$VMs = Get-AzVM
{
}
Tareas comunes
Esta sección contiene comandos comunes que son útiles al trabajar con configuraciones de sitio a sitio. Para
obtener la lista completa de los comandos de red de la CLI, consulte Azure CLI - Networking (CLI de Azure -
Redes).
Para ver las puertas de enlace de la red local
Para ver una lista de las puertas de enlace de red local, use el comando az network local-gateway list.
az network local-gateway list --resource-group TestRG1
Para modificar los prefijos de dirección IP de la puerta de enlace de red local (sin conexión de puerta de
enlace )
Si no dispone de una conexión de puerta de enlace y desea agregar o quitar prefijos de direcciones IP, utilice el
mismo comando que se usa para crear la puerta de enlace de red local, az network local-gateway create. Este
comando también se puede usar para actualizar la dirección IP de la puerta de enlace del dispositivo VPN. Para
sobrescribir la configuración actual, utilice el nombre existente de la puerta de enlace de red local. Si usa otro
nombre, creará una nueva puerta de enlace de red local, en lugar de sobrescribir la existente.
Cada vez que se realiza un cambio, debe especificarse toda la lista de prefijos, no solo los prefijos que se desea
cambiar. Especifique solo los prefijos que desea conservar. En este caso, 10.0.0.0/24 y 20.0.0.0/24
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 -g TestRG1 --local-address-

prefixes 10.0.0.0/24 20.0.0.0/24
Para modificar los prefijos de dirección IP de la puerta de enlace de red local (conexión de puerta de enlace
existente )
Si tiene una conexión de puerta de enlace y desea agregar o quitar prefijos de direcciones IP, estos se pueden
actualizar mediante az network local-gateway update. Esto tendrá como resultado un tiempo de inactividad para
la conexión VPN. Al modificar los prefijos de direcciones IP, no preciso eliminar la puerta de enlace VPN.
cambiar. En este ejemplo, 10.0.0.0/24 y 20.0.0.0/24 ya están presentes. Agregamos los prefijos 30.0.0.0/24 y
40.0.0.0/24, y especificamos los cuatro prefijos al actualizar.
az network local-gateway update --local-address-prefixes 10.0.0.0/24 20.0.0.0/24 30.0.0.0/24 40.0.0.0/24 --

name VNet1toSite2 -g TestRG1
Para modificar la puerta de enlace de red local "gatewayIpAddress"

enlace de red local para reflejar ese cambio. La dirección IP de puerta de enlace se puede cambiar sin quitar una
conexión de puerta de enlace VPN existente (si tiene una). Para modificar la dirección IP de puerta de enlace,
reemplace los valores "Site2" y "TestRG1" por los suyos propios mediante el comando az network local-gateway
update.
az network local-gateway update --gateway-ip-address 23.99.222.170 --name Site2 --resource-group TestRG1
Compruebe que la dirección IP sea correcta en la salida:
"gatewayIpAddress": "23.99.222.170",
Para comprobar los valores de la clave compartida

Compruebe que el valor de la clave compartida es el mismo valor que utilizó para la configuración del
dispositivo VPN. Si no es así, ejecute de nuevo la conexión con el valor del dispositivo, o actualice el dispositivo
con el valor devuelto. Los valores deben coincidir. Para ver la clave compartida, use az network vpn-connection-
list.
az network vpn-connection shared-key show --connection-name VNet1toSite2 --resource-group TestRG1
Para ver la dirección IP pública de la puerta de enlace de VPN

Para buscar la dirección IP pública de la puerta de enlace de red virtual, use el comando az network public-ip list.
Para facilitar la lectura, la salida de este ejemplo tiene el formato preciso para mostrar la lista de direcciones IP
públicas en formato de tabla.
az network public-ip list --resource-group TestRG1 --output table
Pasos siguientes
Para más información acerca de la tunelización forzada, consulte la información acerca de la tunelización
forzada.
Para obtener una lista de comandos de red de la CLI de Azure, consulte Networking - az network (Redes: az
network).
Para obtener información acerca de cómo crear una conexión VPN de sitio a sitio mediante una plantilla de
Azure Resource Manager, consulte Create a Site-to-Site VPN Connection (Creación de una conexión VPN de
sitio a sitio).
Para obtener información acerca de cómo crear una conexión VPN entre redes virtuales mediante una
plantilla de Azure Resource Manager, consulte Deploy HBase geo replication (Implementación de replicación
geográfica de HBase).
Adición de conexiones S2S adicionales a una red
virtual: Azure portal
Los pasos de este artículo le ayudan a agregar conexiones de sitio a sitio (S2S) adicionales a VPN Gateway con
una conexión existente. Esta arquitectura se denomina con frecuencia configuración "multisitio". Puede agregar
una conexión S2S a una red virtual que ya tiene una conexión S2S, una conexión de punto a sitio o una conexión
entre dos redes virtuales. Existen algunas limitaciones al agregar conexiones. Vea la sección Requisitos previos
de este artículo para comprobarlas antes de iniciar la configuración.
Este artículo se aplica a redes virtuales de Resource Manager que tienen una puerta de enlace de VPN
RouteBased. Estos pasos no se aplican a las nuevas configuraciones de conexión coexistentes de
ExpressRoute/de sitio a sitio. Sin embargo, si solo va a agregar una nueva conexión VPN a una configuración
coexistente, puede seguir estos pasos. Consulte conexiones coexistentes de ExpressRoute/S2S para obtener
información sobre las conexiones coexistentes.
Requisitos previos
Compruebe los siguientes aspectos:
No va a configurar una configuración de ExpressRoute y VPN Gateway coexistente nueva.
Tiene una red virtual que se ha creado con el modelo de implementación de Resource Manager con una
conexión existente.
La puerta de enlace de red virtual para su red virtual es RouteBased. Si tiene una VPN Gateway PolicyBased,
necesita eliminar la puerta de enlace de red virtual y crear una VPN Gateway nueva como RouteBased.
Ninguno de los intervalos de direcciones se superpone con ninguna de las redes virtuales a la que se está
conectando esta red virtual.
Tiene un dispositivo VPN compatible y alguien que pueda configurarlo. Consulte Acerca de los dispositivos
VPN para conexiones de red virtual de sitio a sitio. Si no conoce la configuración de su dispositivo VPN o los
intervalos de direcciones IP ubicados en la configuración de la red local, necesita trabajar con alguien que
pueda proporcionarle estos detalles.
Tiene una dirección IP pública externa para el dispositivo VPN.
Configuración de una conexión

1. Desde un explorador, vaya Azure Portal y, si fuera necesario, inicie sesión con su cuenta de Azure.
2. Seleccione Todos los recursos , localice su puer ta de enlace de red vir tual en la lista de recursos y
selecciónela.
3. En la página Puer ta de enlace de red vir tual , seleccione Conexiones .
4. En la página Conexiones , seleccione + Agregar .
5. De este modo se abrirá la página Agregar conexión .
6. En la página Agregar conexión , rellene los campos siguientes:
Nombre: el nombre que quiere darle al sitio para el que está creando la conexión.
Tipo de conexión : seleccione De sitio a sitio (IPsec) .
Adición de una puerta de enlace de red local
1. En el campo Puer ta de enlace de red local , seleccione Elegir una puer ta de enlace de red local _.
Se abre la página _ Elegir puer ta de enlace de red local .
2. Seleccione + Crear nueva para abrir la página Crear puer ta de enlace de red local .
3. En la página Crear puer ta de enlace de red local , rellene los campos siguientes:
Nombre: el nombre que quiere darle al recurso de puerta de enlace de red local.
Punto de conexión: Dirección IP pública del dispositivo VPN del sitio al que quiere conectarse o
FQDN del punto de conexión.
Espacio de direcciones: el espacio de direcciones al que quiere que se enrute el nuevo sitio de red
local.
4. Seleccione Aceptar en la página Crear puer ta de enlace de red local para guardar los cambios.
Adición de la clave compartida

1. Después de crear la puerta de enlace de red local, vuelva a la página Agregar conexión .
2. Rellene los demás campos. En Clave compar tida (PSK) , puede obtener la clave compartida de su
dispositivo VPN o crear una aquí y, después, configurar su dispositivo VPN para que use la misma clave
compartida. Lo importante es que las claves sean exactamente iguales.
Creación de la conexión
1. En la parte inferior de la página, seleccione Aceptar para crear la conexión. La conexión empieza a crearse
inmediatamente.
2. Una vez completada la conexión, puede verla y comprobarla.
Visualización y comprobación de la conexión VPN

conexión.
Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Para más información,
consulte las rutas de aprendizaje de las máquinas virtuales.
Conexión de puertas de enlace Azure VPN Gateway
a varios dispositivos VPN locales basados en
directivas con PowerShell
Este artículo le ayuda a configurar una puerta de enlace de VPN basada en rutas de Azure para conectarse a
varios dispositivos VPN locales basados en directivas al aprovechar las directivas IPsec/IKE personalizadas en las
conexiones VPN de sitio a sitio.
Acerca de las puertas de enlace de VPN basadas en directivas y en

rutas
Los dispositivos VPN basados en directivas se diferencian frente a los basados en rutas en la forma en la que se
establecen los selectores de tráfico IPsec en una conexión:
Los dispositivos VPN basados en directivas usan las combinaciones de prefijos de ambas redes para
definir la forma en la que se cifra/descifra el tráfico a través de túneles IPsec. Normalmente se basa en
dispositivos de firewall que realizan el filtrado de paquetes. El cifrado y descifrado de túneles IPsec se
agregan al motor de procesamiento y al filtrado de paquetes.
Los dispositivos VPN basados en rutas usan selectores de tráfico universales (caracteres comodín) y
permiten a las tablas de reenvío/enrutamiento dirigir el tráfico a distintos túneles IPsec. Normalmente se
basa en plataformas de enrutador donde cada túnel IPsec se modela como una interfaz de red o VTI (interfaz
de túnel virtual).
Los diagramas siguientes resaltan los dos modelos:
Ejemplo de VPN basada en directivas
Ejemplo de VPN basada en rutas

Compatibilidad de Azure con VPN basada en directivas
Actualmente, Azure admite los dos modos de puertas de enlace de VPN: puertas de enlace de VPN basadas en
directivas y puertas de enlace de VPN basadas en rutas. Se crean en distintas plataformas internas, lo que da
lugar a diferentes especificaciones:
VP N GAT EWAY VP N GAT EWAY VP N GAT EWAY

C AT EGO RY P O L IC Y B A SED RO UT EB A SED RO UT EB A SED
SKU de puer ta de Básica Básico VpnGw1, VpnGw2,

enlace de Azure VpnGw3, VpnGw4, VpnGw5
Versión de IKE IKEv1 IKEv2 IKEv1 e IKEv2
Máx. de conexiones de 1 10 30
sitio a sitio
Con la directiva IPsec/IKE personalizada, ahora puede configurar puertas de enlace Azure VPN Gateway basadas
en rutas para usar selectores de tráfico basados en prefijo con la opción "PolicyBasedTrafficSelectors " para
conectarse a dispositivos VPN locales basados en directivas. Esta capacidad le permite conectarse desde una red
virtual de Azure y una puerta de enlace Azure VPN Gateway a varios dispositivos VPN/firewall locales basados
en directivas y quitar el límite de conexión único de las actuales puertas de enlace Azure VPN Gateway basadas
en directivas.
IMPORTANT
1. Para habilitar esta conectividad, los dispositivos VPN locales basados en directivas deben admitir IKEv2 para
conectarse a las puertas de enlace Azure VPN Gateway basadas en rutas. Compruebe las especificaciones del
dispositivo VPN.
2. Las redes locales que se conectan a través de dispositivos VPN basados en directivas con este mecanismo solo pueden
conectarse a la red virtual de Azure; no se permite el tránsito a otras redes locales o redes vir tuales a
través de la misma puer ta de enlace de VPN de Azure .
3. La opción de configuración forma parte de la directiva de conexión IPsec/IKE personalizada. Si habilita la opción de
selector de tráfico basado en directivas, debe especificar la directiva completa (vigencias de SA, puntos clave,
algoritmos de integridad y cifrado IPsec/IKE).
El diagrama siguiente muestra por qué el enrutamiento del tránsito a través de la puerta de enlace de VPN de
Azure no funciona con la opción basada en directivas:
Como se muestra en el diagrama, la puerta de enlace de VPN de Azure tiene selectores de tráfico desde la red
virtual a cada prefijo de red local, pero no a los prefijos de conexión cruzada. Por ejemplo, los sitios 2, 3 y 4
locales pueden comunicarse con VNet1, pero no se pueden conectar entre sí a través de la puerta de enlace de
VPN de Azure. El diagrama muestra los selectores de tráfico de conexión cruzada que no están disponibles en la
puerta de enlace Azure VPN Gateway en esta configuración.
Flujo de trabajo
Las instrucciones de este artículo siguen el mismo ejemplo de Configurar una directiva de IPsec o IKE para
conexiones VPN de sitio a sitio o de red virtual a red virtual para establecer una conexión VPN de sitio a sitio. Se
muestra en el diagrama siguiente:
El flujo de trabajo para habilitar esta conectividad:

1. Cree la red virtual, la puerta de enlace de red privada virtual y la puerta de enlace de red local para la
conexión entre locales.
2. Cree una directiva IPsec o IKE.
3. Aplique la directiva cuando cree una conexión de sitio a sitio o de red virtual a red virtual, y habilite los
selectores de tráfico basados en directivas en la conexión.
4. Si ya se ha creado la conexión, puede aplicar la directiva a una conexión existente o actualizarla.
Antes de empezar
Compruebe que tiene una suscripción a Azure. Si todavía no la tiene, puede activar sus ventajas como
suscriptor de MSDN o registrarse para obtener una cuenta gratuita.
En este artículo se usan cmdlets de PowerShell. Para ejecutar los cmdlets, puede usar Azure Cloud Shell.
Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este artículo.
Tiene las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
Para abrir Cloud Shell, seleccione Pruébelo en la esquina superior derecha de un bloque de código.
También puede ir a https://shell.azure.com/powershell para iniciar Cloud Shell en una pestaña
independiente del explorador. Seleccione Copiar para copiar los bloques de código, péguelos en Cloud
Shell y, luego, presione Entrar para ejecutarlos.
También puede instalar y ejecutar los cmdlets de Azure PowerShell localmente en el equipo. Los cmdlets
de PowerShell se actualizan con frecuencia. Si no ha instalado la versión más reciente, los valores
especificados en las instrucciones pueden dar lugar a errores. Para buscar las versiones de Azure
PowerShell instaladas en el equipo, use el cmdlet Get-Module -ListAvailable Az . Para instalar la
actualización, vea Instalación del módulo de Azure PowerShell.
Habilitación de selectores de tráfico basados en directivas

En esta sección se muestra cómo habilitar los selectores de tráfico basados en directivas en una conexión.
Asegúrese de haber completado la parte 3 del artículo de configuración de una directiva IPsec o IKE. En los
pasos de este artículo se usan los mismos parámetros.
Paso 1: crear la red virtual, la puerta de enlace de VPN y la puerta de enlace de red local
Conexión a la suscripción y declaración de variables
1. Si ejecuta PowerShell localmente en el equipo, inicie sesión con el cmdlet Connect-AzAccount. O bien, si
lo prefiere, abra Azure Cloud Shell en el explorador.
2. Declare las variables. Para este ejercicio, usamos las siguientes variables:
$Sub1 = "<YourSubscriptionName>"
$RG1 = "TestPolicyRG1"
$Location1 = "East US 2"
$VNetName1 = "TestVNet1"
$BESubName1 = "Backend"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$DNS1 = "8.8.8.8"
$GW1IPName1 = "VNet1GWIP1"
$GW1IPconf1 = "gw1ipconf1"
$Connection16 = "VNet1toSite6"
$LNGName6 = "Site6"
$LNGPrefix61 = "10.61.0.0/16"
$LNGPrefix62 = "10.62.0.0/16"
$LNGIP6 = "131.107.72.22"
Creación de la red virtual, la puerta de enlace de VPN y la puerta de enlace de red local
1. Cree un grupo de recursos.
2. Use el ejemplo siguiente para crear la red virtual TestVNet1, con tres subredes y la puerta de enlace de
VPN. Si desea reemplazar los valores, es importante que siempre asigne el nombre GatewaySubnet a la
subred de la puerta de enlace. Si usa otro, se produce un error al crear la puerta de enlace.
$fesub1 = New-AzVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1
$besub1 = New-AzVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1
$gwsub1 = New-AzVirtualNetworkSubnetConfig -Name $GWSubName1 -AddressPrefix $GWSubPrefix1
New-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 -Location $Location1 -AddressPrefix

$VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1
$gw1pip1 = New-AzPublicIpAddress -Name $GW1IPName1 -ResourceGroupName $RG1 -Location $Location1 -

$subnet1 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
$gw1ipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GW1IPconf1 -Subnet $subnet1 -PublicIpAddress
$gw1pip1
New-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 -Location $Location1 -

IpConfigurations $gw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance
New-AzLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1 -Location $Location1 -

GatewayIpAddress $LNGIP6 -AddressPrefix $LNGPrefix61,$LNGPrefix62
Paso 2: Creación de una conexión VPN de sitio a sitio con una directiva IPsec o IKE
1. Cree una directiva IPsec o IKE.
IMPORTANT
Debe crear una directiva IPsec/IKE para habilitar la opción "UsePolicyBasedTrafficSelectors" en la conexión.
El ejemplo siguiente crea una directiva IPsec/IKE con estos algoritmos y parámetros:
IKEv2: AES256, SHA384 y DHGroup24
IPsec: AES256, SHA256, sin PFS, 14 400 segundos de vigencia de SA y 102 400 000 KB
$ipsecpolicy6 = New-AzIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup DHGroup24 -

IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 14400 -
SADataSizeKilobytes 102400000
2. Cree la conexión VPN de sitio a sitio con los selectores de tráfico basados en directivas y la directiva IPsec
o IKE, y aplique la directiva IPsec o IKE creada en el paso anterior. Tenga en cuenta el parámetro adicional
"-UsePolicyBasedTrafficSelectors $True", que habilita los selectores de tráfico basados en directivas en la
conexión.

$lng6 = Get-AzLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1
New-AzVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1 -

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng6 -Location $Location1 -ConnectionType
IPsec -UsePolicyBasedTrafficSelectors $True -IpsecPolicies $ipsecpolicy6 -SharedKey 'AzureA1b2C3'
3. Después de completar los pasos, la conexión VPN de sitio a sitio usará la directiva IPsec/IKE definida y
habilitará los selectores de tráfico basados en directivas en la conexión. Puede repetir los mismos pasos
para agregar más conexiones a los dispositivos VPN locales adicionales basados en directivas desde la
misma puerta de enlace Azure VPN Gateway.
Para actualizar los selectores de tráfico basados en directivas

En esta sección se muestra cómo actualizar la opción de selectores de tráfico basados en directivas para una
conexión VPN de sitio a sitio existente.
1. Obtenga el recurso de conexión.
$connection6 = Get-AzVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName $RG1
2. Consulte la opción de selectores de tráfico basados en directivas. La siguiente línea muestra si se usan los
selectores de tráfico basados en directivas para la conexión:
$connection6.UsePolicyBasedTrafficSelectors
Si la línea devuelve "True ", los selectores de tráfico basados en directivas están configurados en la
conexión; en caso contrario, devuelve "False ".
3. Una vez que obtenga el recurso de conexión, puede habilitar o deshabilitar los selectores de tráfico
basados en directivas en una conexión.
Para habilitar
En el ejemplo siguiente se habilita la opción de selectores de tráfico basados en directivas y se deja
sin modificar la directiva IPsec/IKE:
$connection6 = Get-AzVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName
$RG1
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -

UsePolicyBasedTrafficSelectors $True
Para deshabilitar
En el ejemplo siguiente se deshabilita la opción de selectores de tráfico basados en directivas, pero
se deja sin modificar la directiva IPsec/IKE:
$connection6 = Get-AzVirtualNetworkGatewayConnection -Name $Connection16 -ResourceGroupName
$RG1
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -

UsePolicyBasedTrafficSelectors $False
Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Consulte Creación de
una máquina virtual que ejecuta Windows en el Portal de Azure para ver los pasos.
Consulte también Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet connections (Configuración de la
directiva IPsec/IKE para conexiones VPN de sitio a sitio o de red virtual a red virtual) para obtener más
información sobre las directivas IPsec/IKE personalizadas.
Configuración de conexiones ExpressRoute y de
sitio a sitio coexistentes con PowerShell
En este artículo se le ayuda a configurar conexiones ExpressRoute y VPN de sitio a sitio que coexisten. Tener la
posibilidad de configurar VPN de sitio a sitio y ExpressRoute tiene varias ventajas. Puede configurar una VPN de
sitio a sitio como una ruta de acceso seguro de conmutación por error para ExpressRoute, o bien usar las VPN
de sitio a sitio para conectarse a sitios que no están conectados mediante ExpressRoute. En este artículo
trataremos los pasos para configurar ambos escenarios. Este artículo se aplica al modelo de implementación de
Resource Manager.
La configuración de las conexiones coexistentes de VPN de sitio a sitio y ExpressRoute tiene varias ventajas:
Puede configurar una VPN de sitio a sitio como una ruta de conmutación por error segura para
ExpressRoute.
Si lo desea, también puede usar redes VPN de sitio a sitio para conectarse a los sitios que no están
conectados mediante ExpressRoute.
En este artículo, se explican los pasos para configurar ambos escenarios. Este artículo se aplica al modelo de
implementación de Resource Manager y utiliza PowerShell. También puede configurar estos escenarios con
Azure Portal, aunque la documentación aún no está disponible. Puede configurar cualquier puerta de enlace en
primer lugar. Normalmente, no se incurrirá en ningún tiempo de inactividad cuando se agrega una nueva puerta
de enlace o una conexión de puerta de enlace.
NOTE
Si desea crear una VPN de sitio a sitio a través de un circuito de ExpressRoute, consulte este artículo.
Límites y limitaciones
No se admite el enrutamiento transitorio. No se puede realizar un enrutamiento (a través de Azure)
entre una red local conectada a través de una VPN sitio a sitio y una red local conectada a través de
ExpressRoute.
No se admite la puer ta de enlace de la SKU de nivel Básico. Debe utilizar una puerta de enlace de la
SKU que no sea de nivel Básico tanto para la puerta de enlace de ExpressRoute como para la VPN Gateway.
Solo se admite la VPN Gateway basada en rutas. Debe usar una VPN Gateway basada en rutas.
También puede usar una VPN Gateway basada en rutas con una conexión VPN configurada para "selectores
de tráfico basados en directivas", tal y como se describe en Conexión a varios dispositivos VPN basados en
directivas.
Se debe configurar una ruta estática para VPN Gateway. Si la red local está conectada tanto a
ExpressRoute como a una VPN de sitio a sitio, debe tener configurada una ruta estática en la red local para
enrutar la conexión VPN de sitio a sitio a la red pública de Internet.
VPN Gateway se configura de manera predeterminada en ASN 65515 si no se especifica. Azure
VPN Gateway admite el protocolo de enrutamiento de BGP. Para especificar el ASN (número AS) de la red
virtual, agregue el modificador - Asn. Si no se especifica este parámetro, el número AS predeterminado es
65515. Puede usar cualquier ASN para la configuración, pero si selecciona un valor distinto de 65515, debe
restablecer la puerta de enlace para que la configuración surta efecto.
La subred de la puer ta de enlace debe ser /27 o un prefijo más cor to , (como /26, /25). De lo
contrario, recibirá un mensaje de error al agregar la puerta de enlace de red virtual de ExpressRoute.
Diseños de configuración
Configuración de una VPN de sitio a sitio como una ruta de acceso de conmutación por error para
ExpressRoute
Puede configurar una conexión VPN de sitio a sitio como una copia de seguridad para ExpressRoute. Esta
conexión se aplica únicamente a las redes virtuales vinculadas a la ruta de acceso de emparejamiento privado
de Azure. No hay ninguna solución de conmutación por error basada en VPN para servicios que sea accesible
mediante el emparejamiento de Microsoft Azure. El circuito ExpressRoute siempre es el vínculo principal. Los
datos fluyen a través de la ruta de acceso de la VPN de sitio a sitio solo si se produce un error en el circuito
ExpressRoute. Para evitar el enrutamiento asimétrico, la configuración de red local también debería preferir el
circuito ExpressRoute a través de la VPN de sitio a sitio. Si prefiere utilizar la ruta de ExpressRoute, dé mayor
preferencia local a las rutas que reciben ExpressRoute.
NOTE
Si bien se prefiere el circuito ExpressRoute a la VPN de sitio a sitio cuando ambas rutas son las mismas, Azure utilizará la
coincidencia de prefijo más larga para elegir la ruta hacia el destino del paquete.
Configuración de una VPN de sitio a sitio para conectarse a sitios no conectados mediante ExpressRoute
Puede configurar la red para sitios que se conectan directamente a Azure mediante una VPN de sitio a sitio y
otros que se conectan a través de ExpressRoute.
NOTE
No se puede configurar una red virtual como un enrutador de tránsito.
Selección de los pasos a seguir

Hay dos conjuntos diferentes de procedimientos que puede elegir. El procedimiento de configuración que
seleccione depende de si ya tiene una red virtual existente a la que quiere conectarse o si desea crear una nueva.
No tengo una red virtual y necesito crear una.
Si aún no tiene una red virtual, este procedimiento le guía en la creación de una nueva red virtual
mediante el modelo de implementación de Resource Manager y la creación de nuevas conexiones VPN
de sitio a sitio y ExpressRoute. Para configurar una red virtual, siga los pasos que se describen en
Creación de una nueva red virtual y conexiones coexistentes.
Ya tengo una red virtual del modelo de implementación de Resource Manager.
Puede que ya tenga una red virtual con una conexión VPN de sitio a sitio o una conexión ExpressRoute
existentes. En este escenario, si la máscara de subred de la puerta de enlace es /28, o menor (/28, /29,
etc.), tendrá que eliminar la puerta de enlace existente. La sección Configuración de conexiones
coexistentes para una red virtual existente le guía en la eliminación de la puerta de enlace y la creación de
nuevas conexiones VPN de sitio a sitio y ExpressRoute.
Si elimina y crea de nuevo la puerta de enlace, se producirá un tiempo de inactividad en las conexiones
entre locales. Sin embargo, si las máquinas virtuales y los servicios están configurados para ello, podrán
seguir comunicándose con el exterior a través del equilibrador de carga mientras configura la puerta de
enlace.
Antes de empezar
En los pasos y ejemplos de este artículo se usan módulos de Az de Azure PowerShell. Para instalar módulos de
Az localmente en el equipo, consulte Instalación de Azure PowerShell. Para obtener más información sobre el
nuevo módulo Az, consulte Presentación del nuevo módulo Az de Azure PowerShell. Los cmdlets de PowerShell
se actualizan con frecuencia. Si no está ejecutando la última versión, los valores especificados en las
instrucciones pueden dar lugar a errores. Para buscar las versiones instaladas de PowerShell en el sistema, use
el cmdlet Get-Module -ListAvailable Az .
Puede usar Azure Cloud Shell para ejecutar la mayoría de los cmdlets de PowerShell y comandos de la CLI, en
lugar de instalar Azure PowerShell o la CLI de forma local. Azure Cloud Shell es un shell interactivo gratuito que
tiene herramientas comunes de Azure preinstaladas y se configura para usar con la cuenta. Para ejecutar
cualquier código contenido en este artículo en Azure Cloud Shell, abra una sesión de Cloud Shell, utilice el botón
Copiar en un bloque de código para copiar el código y péguelo en la sesión de Cloud Shell con
Ctrl+Mayús+V en Windows y Linux, o Cmd+Mayús+V en macOS. El texto pegado no se ejecuta
automáticamente, así que presione Entrar para ejecutarlo.
Hay unas cuantas maneras de iniciar Cloud Shell:
O P C IÓ N VÍN C ULO
Haga clic en Probarlo en la esquina superior derecha de un

bloque de código.
Abra Cloud Shell en el explorador.

O P C IÓ N VÍN C ULO
Haga clic en el botón Cloud Shell en el menú de la parte

superior derecha de Azure Portal.
Creación de una nueva red virtual y conexiones coexistentes

Este procedimiento le guía en la creación de una red virtual y conexiones de sitio a sitio y ExpressRoute que
coexisten. Los cmdlets que se usan en esta configuración pueden ser ligeramente diferentes de aquellos con los
que podría estar familiarizado. Asegúrese de usar los cmdlets especificados en estas instrucciones.
1. Inicie sesión y seleccione su suscripción.
Si está usando Azure Cloud Shell, iniciará sesión automáticamente en su cuenta de Azure después de
hacer clic en "Probar". Para iniciar sesión de forma local, abra la consola de PowerShell con privilegios
elevados y ejecute el cmdlet para conectarse.
Connect-AzAccount
Si tiene más de una suscripción, obtenga una lista de las suscripciones de Azure.
Get-AzSubscription
Select-AzSubscription -SubscriptionName "Name of subscription"
2. Configure las variables.
$location = "Central US"

$resgrp = New-AzResourceGroup -Name "ErVpnCoex" -Location $location
$VNetASN = 65515
3. Cree una red virtual, incluida la subred de la puerta de enlace. Para más información acerca de cómo
crear una red virtual en Azure, consulte Create a virtual network (Creación de una red virtual). Para más
información acerca de cómo crear subredes, consulte Incorporación de una subred
IMPORTANT
La subred de puerta de enlace debe ser /27 o un prefijo más corto (por ejemplo, /26 o /25).
Cree una nueva red virtual.
$vnet = New-AzVirtualNetwork -Name "CoexVnet" -ResourceGroupName $resgrp.ResourceGroupName -Location

$location -AddressPrefix "10.200.0.0/16"
Agregue subredes.
Add-AzVirtualNetworkSubnetConfig -Name "App" -VirtualNetwork $vnet -AddressPrefix "10.200.1.0/24"
Add-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet -AddressPrefix
"10.200.255.0/24"
Guarde la configuración de red virtual.
$vnet = Set-AzVirtualNetwork -VirtualNetwork $vnet
4. A continuación, cree la puerta de enlace de la VPN de sitio a sitio. Para más información sobre la
configuración de VPN Gateway, consulte Creación de una red virtual con una conexión de sitio a sitio
mediante PowerShell. GatewaySku solamente es compatible con las puertas de enlace de VPN VpnGw1,
VpnGw2, VpnGw3, Standard y HighPerformance. Las configuraciones de la coexistencia de ExpressRoute-
VPN Gateway no se admiten en la SKU de nivel Básico. El valor de VpnType debe ser RouteBased.
$gwSubnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet

$gwIP = New-AzPublicIpAddress -Name "VPNGatewayIP" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -AllocationMethod Dynamic
$gwConfig = New-AzVirtualNetworkGatewayIpConfig -Name "VPNGatewayIpConfig" -SubnetId $gwSubnet.Id -
PublicIpAddressId $gwIP.Id
New-AzVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName $resgrp.ResourceGroupName -Location
$location -IpConfigurations $gwConfig -GatewayType "Vpn" -VpnType "RouteBased" -GatewaySku "VpnGw1"
Azure VPN Gateway admite el protocolo de enrutamiento de BGP. Para especificar el ASN (número AS) de
la red virtual, agregue el modificador - Asn al siguiente comando. Si no se especifica ese parámetro, el
valor predeterminado del número AS será 65515.
$azureVpn = New-AzVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName -Location $location -IpConfigurations $gwConfig -GatewayType "Vpn" -VpnType
"RouteBased" -GatewaySku "VpnGw1" -Asn $VNetASN
Puede buscar el IP de emparejamiento BGP y el número de AS que Azure usa para VPN Gateway en
$azureVpn.BgpSettings.BgpPeeringAddress y $azureVpn.BgpSettings.Asn de BGP. Para más información,
consulte Configuración de BGP para Azure VPN Gateway.
5. Cree una entidad de puerta de enlace de VPN de sitio local. Este comando no configura la puerta de
enlace de VPN local. En su lugar, permite proporcionar la configuración de puerta de enlace local, como la
dirección IP pública y el espacio de direcciones local, para que la puerta de enlace de VPN de Azure pueda
conectarse a ella.
Si el dispositivo VPN local solo admite enrutamiento estático, las rutas estáticas se pueden configurar
como se indica a continuación:
$MyLocalNetworkAddress = @("10.100.0.0/16","10.101.0.0/16","10.102.0.0/16")
$localVpn = New-AzLocalNetworkGateway -Name "LocalVPNGateway" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -GatewayIpAddress *<Public IP>* -AddressPrefix
$MyLocalNetworkAddress
Si el dispositivo VPN local admite el BGP y desea habilitar el enrutamiento dinámico, es preciso que
conozca la IP de emparejamiento BGP y el número de AS que usa el dispositivo VPN local.
$localVPNPublicIP = "<Public IP>"
$localBGPPeeringIP = "<Private IP for the BGP session>"
$localBGPASN = "<ASN>"
$localAddressPrefix = $localBGPPeeringIP + "/32"
$localVpn = New-AzLocalNetworkGateway -Name "LocalVPNGateway" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -GatewayIpAddress $localVPNPublicIP -AddressPrefix
$localAddressPrefix -BgpPeeringAddress $localBGPPeeringIP -Asn $localBGPASN
6. Configure el dispositivo VPN local para que se conecte a la nueva puerta de enlace de VPN de Azure. Para
obtener más información sobre la configuración del dispositivo VPN, vea Configuración de dispositivos
VPN.
7. Vincule la puerta de enlace de VPN sitio a sitio en Azure a la puerta de enlace local.
$azureVpn = Get-AzVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName
New-AzVirtualNetworkGatewayConnection -Name "VPNConnection" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -VirtualNetworkGateway1 $azureVpn -LocalNetworkGateway2
$localVpn -ConnectionType IPsec -SharedKey <yourkey>
8. Si está conectado a un circuito ExpressRoute existente, omita los pasos 8 y 9 y pase directamente al paso
10. Configure los circuitos ExpressRoute. Para más información acerca de cómo configurar los circuitos
ExpressRoute, consulte Creación de un circuito ExpressRoute.
9. Configure el emparejamiento privado de Azure a través del circuito ExpressRoute. Para más información
acerca de cómo configurar el emparejamiento privado de Azure a través del circuito ExpressRoute,
consulte Configuración del emparejamiento.
10. Cree una puerta de enlace de ExpressRoute. Para más información sobre la configuración de la puerta de
enlace de ExpressRoute, consulte Adición de una puerta de enlace de VPN a una red virtual de Resource
Manager para una configuración de ExpressRoute. El valor de GatewaySKU debe ser Standard,
HighPerformance o UltraPerformance.

$gwIP = New-AzPublicIpAddress -Name "ERGatewayIP" -ResourceGroupName $resgrp.ResourceGroupName -
$gwConfig = New-AzVirtualNetworkGatewayIpConfig -Name "ERGatewayIpConfig" -SubnetId $gwSubnet.Id -
$gw = New-AzVirtualNetworkGateway -Name "ERGateway" -ResourceGroupName $resgrp.ResourceGroupName -
Location $location -IpConfigurations $gwConfig -GatewayType "ExpressRoute" -GatewaySku Standard
11. Vincule la puerta de enlace de ExpressRoute al circuito ExpressRoute. Una vez completado este paso, se
ha establecido la conexión entre su red local y Azure a través de ExpressRoute. Para más información
sobre la operación de vinculación, consulte Vinculación de redes virtuales a circuitos ExpressRoute.
$ckt = Get-AzExpressRouteCircuit -Name "YourCircuit" -ResourceGroupName "YourCircuitResourceGroup"

New-AzVirtualNetworkGatewayConnection -Name "ERConnection" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -VirtualNetworkGateway1 $gw -PeerId $ckt.Id -
ConnectionType ExpressRoute
Para configurar conexiones coexistentes para una red virtual ya

existente
Si tiene una red virtual con una sola una puerta de enlace de red virtual (por ejemplo, una puerta de enlace de
VPN de sitio a sitio) y desea agregar una segunda puerta de enlace de otro tipo (por ejemplo, una puerta de
enlace de ExpressRoute), compruebe el tamaño de la subred de la puerta de enlace. Si la subred de la puerta de
enlace es/27, o mayor, puede omitir los pasos siguientes y seguir los de la sección anterior para agregar una
puerta de enlace VPN de sitio a sitio o una puerta de enlace de ExpressRoute. Si la subred de la puerta de enlace
es /28 o /29, primero debe eliminar la puerta de enlace de red virtual y aumentar el tamaño de la subred de la
puerta de enlace. Los pasos de esta sección le muestran cómo hacerlo.
Los cmdlets que se usan en esta configuración pueden ser ligeramente diferentes de aquellos con los que
podría estar familiarizado. Asegúrese de usar los cmdlets especificados en estas instrucciones.
1. Elimine la puerta de enlace de la VPN de ExpressRoute o de sitio a sitio.
Remove-AzVirtualNetworkGateway -Name <yourgatewayname> -ResourceGroupName <yourresourcegroup>
2. Elimine la subred de puerta de enlace.
$vnet = Get-AzVirtualNetwork -Name <yourvnetname> -ResourceGroupName <yourresourcegroup> Remove-

AzVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork $vnet
3. Agregue una subred de puerta de enlace que sea /27 o superior.
NOTE
Si no tiene suficientes direcciones IP en la red virtual para aumentar el tamaño de la subred de puerta de enlace,
debe agregar más espacio de direcciones IP.
$vnet = Get-AzVirtualNetwork -Name <yourvnetname> -ResourceGroupName <yourresourcegroup>

Add-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet -AddressPrefix
"10.200.255.0/24"
Guarde la configuración de red virtual.
$vnet = Set-AzVirtualNetwork -VirtualNetwork $vnet
4. Ya tiene una red virtual sin puertas de enlace. Para crear nuevas puertas de enlace y configurar las
conexiones, utilice los siguientes ejemplos:
Establezca las variables.

$gwIP = New-AzPublicIpAddress -Name "ERGatewayIP" -ResourceGroupName $resgrp.ResourceGroupName -
$gwConfig = New-AzVirtualNetworkGatewayIpConfig -Name "ERGatewayIpConfig" -SubnetId $gwSubnet.Id -
Cree la puerta de enlace.
$gw = New-AzVirtualNetworkGateway -Name <yourgatewayname> -ResourceGroupName <yourresourcegroup> -

Location <yourlocation> -IpConfigurations $gwConfig -GatewayType "ExpressRoute" -GatewaySku Standard
Cree la conexión.
$ckt = Get-AzExpressRouteCircuit -Name "YourCircuit" -ResourceGroupName "YourCircuitResourceGroup"
New-AzVirtualNetworkGatewayConnection -Name "ERConnection" -ResourceGroupName
$resgrp.ResourceGroupName -Location $location -VirtualNetworkGateway1 $gw -PeerId $ckt.Id -
ConnectionType ExpressRoute
Incorporación de la configuración de punto a sitio a la puerta de

enlace de VPN
Para agregar una configuración de punto a sitio a la puerta de enlace de VPN en una configuración de
coexistencia, puede seguir los pasos que se indican a continuación. Para cargar el certificado raíz VPN, debe
instalar PowerShell localmente en el equipo, o utilizar Azure Portal.
1. Agregue el grupo de direcciones de clientes de VPN.
$azureVpn = Get-AzVirtualNetworkGateway -Name "VPNGateway" -ResourceGroupName

$resgrp.ResourceGroupName
Set-AzVirtualNetworkGatewayVpnClientConfig -VirtualNetworkGateway $azureVpn -VpnClientAddressPool
"10.251.251.0/24"
2. En Azure, cargue el certificado raíz de VPN de la puerta de enlace de VPN. En este ejemplo, se supone que
el certificado raíz se almacena en la máquina local donde se ejecutan los siguientes cmdlets de
PowerShell y que el usuario está ejecutando PowerShell localmente. También puede cargar el certificado
con Azure Portal.
$p2sCertFullName = "RootErVpnCoexP2S.cer"
$p2sCertMatchName = "RootErVpnCoexP2S"
$p2sCertToUpload=get-childitem Cert:\CurrentUser\My | Where-Object {$_.Subject -match
$p2sCertMatchName}
if ($p2sCertToUpload.count -eq 1){write-host "cert found"} else {write-host "cert not found" exit}
$p2sCertData = [System.Convert]::ToBase64String($p2sCertToUpload.RawData)
Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $p2sCertFullName -
VirtualNetworkGatewayname $azureVpn.Name -ResourceGroupName $resgrp.ResourceGroupName -PublicCertData
$p2sCertData
Para más información sobre la VPN de punto a sitio, consulte Configuración de una conexión punto a sitio a una
red virtual mediante PowerShell.
Pasos siguientes
Para obtener más información acerca de ExpressRoute, consulte P+F de ExpressRoute.
Configuración de una conexión VPN de sitio a sitio
a través del emparejamiento privado de
ExpressRoute
Puede configurar una VPN de sitio a sitio para una puerta de enlace de red virtual a través de un
emparejamiento privado de ExpressRoute con una dirección IP de RFC 1918. Esta configuración proporciona las
siguientes ventajas:
El tráfico a través del emparejamiento privado está cifrado.
Los usuarios de punto a sitio que se conectan a una puerta de enlace de red virtual pueden usar
ExpressRoute (a través del túnel de sitio a sitio) para acceder a los recursos locales.
NOTE
Esta característica solo se admite en puertas de enlace con redundancia de zona. Por ejemplo, VpnGw1AZ, VpnGw2AZ,
etc.
Para realizar esta configuración, compruebe que cumple los siguientes requisitos previos:
Tiene un circuito ExpressRoute en funcionamiento que está vinculado a la red virtual donde se ha creado
(o creará) la puerta de enlace de VPN.
Puede conectarse a los recursos mediante la dirección IP de RFC1918 (privada) a través del circuito
ExpressRoute.
Enrutamiento
En la Figura 1 se muestra un ejemplo de conectividad de VPN a través del emparejamiento privado de
ExpressRoute. En este ejemplo, puede ver una red dentro de la red local conectada a la puerta de enlace de VPN
del centro de conectividad de Azure a través del emparejamiento privado de ExpressRoute. Un aspecto
importante de esta configuración es el enrutamiento entre las redes locales y Azure a través de las rutas de
acceso de ExpressRoute y VPN.
En la Ilustración 1
El establecimiento de la conectividad es una tarea sencilla:

1. Establezca la conectividad de ExpressRoute con un circuito ExpressRoute y emparejamiento privado.
2. Establezca la conectividad VPN mediante los pasos de este artículo.
Tráfico desde redes locales a Azure
Para el tráfico que procede de redes locales y se dirige a Azure, los prefijos de Azure se anuncian a través del
BGP de emparejamiento privado de ExpressRoute y el BGP de VPN. El resultado son dos rutas de red (rutas de
acceso) hacia Azure desde las redes locales:
• Una ruta de red a través de la ruta de acceso protegida por IPsec.
• Otra ruta de red directamente a través de ExpressRoute sin protección de IPsec.
Para aplicar el cifrado a la comunicación, debe asegurarse de que para la red conectada a VPN de la Figura 1 se
prefieran las rutas de Azure a través de la puerta de enlace de VPN local en vez de la ruta de acceso directa de
ExpressRoute.
Tráfico desde Azure a las redes locales
El mismo requisito se aplica al tráfico de Azure a las redes locales. Para asegurarse de que la ruta de acceso de
IPsec se elige antes que la ruta de acceso directa de ExpressRoute (sin IPsec), tiene dos opciones:
• Anuncie prefijos más específicos en la sesión BGP de VPN para la red conectada a VPN . Puede
anunciar un rango mayor que abarque la red conectada a VPN a través del emparejamiento privado de
ExpressRoute y, después, rangos más específicos en la sesión del protocolo de puerta de enlace de borde de
VPN. Por ejemplo, anuncie 10.0.0.0/16 a través de ExpressRoute y 10.0.1.0/24 a través de VPN.
• Anuncie prefijos disjuntos para VPN y ExpressRoute . Si los rangos de redes conectadas a VPN no están
unidos a otras redes conectadas de ExpressRoute, puede anunciar los prefijos en las sesiones de los protocolos
de puerta de enlace de borde de ExpressRoute y VPN, respectivamente. Por ejemplo, anuncie 10.0.0.0/24 a
través de ExpressRoute y 10.0.1.0/24 a través de VPN.
En ambos ejemplos, Azure enviará tráfico a 10.0.1.0/24 a través de la conexión VPN en lugar de hacerlo
directamente a través de ExpressRoute sin protección VPN.
WARNING
Si anuncia los mismos prefijos a través de las conexiones de ExpressRoute y VPN, Azure usará la ruta de acceso de
ExpressRoute directamente sin protección de VPN.
Pasos del portal

1. Configure una conexión de sitio a sitio. Para conocer los pasos, consulte el artículo Configuración de sitio
a sitio. Asegúrese de elegir una SKU de puerta de enlace con redundancia de zona como puerta de
enlace.
Las SKU con redundancia de zona tienen "AZ" al final. Por ejemplo, VpnGw1AZ . Las puertas de enlace
con redundancia de zona solo están disponibles en las regiones donde está disponible el servicio de zona
de disponibilidad. Para información sobre las regiones en las que se admiten zonas de disponibilidad,
consulte Regiones que admiten zonas de disponibilidad.
2. Habilite las direcciones IP privadas de la puerta de enlace. Seleccione Configuración y, luego, establezca
Gateway Private IPs (Direcciones IP privadas de puerta de enlace) en Habilitado . Haga clic en
Guardar para guardar los cambios.
3. En la página Información general , seleccione Ver más para ver la dirección IP privada. Anote esta
información, ya que la usará más adelante en los pasos de configuración.
4. Para habilitar Usar la dirección IP privada de Azure en la conexión, seleccione Configuración .

Establezca Usar la dirección IP privada de Azure en Habilitado y, luego. seleccione Guardar .
5. En el firewall, haga ping a la dirección IP privada que anotó en el paso 3. La dirección IP privada debe ser
accesible a través del emparejamiento privado de ExpressRoute.
6. Use esta dirección IP privada como dirección IP remota en el firewall local para establecer el túnel de sitio
a sitio a través del emparejamiento privado de ExpressRoute.
pasos de PowerShell
1. Configure una conexión de sitio a sitio. Para conocer los pasos, consulte el artículo Configuración de una
VPN de sitio a sitio. Asegúrese de elegir una SKU de puerta de enlace con redundancia de zona como
puerta de enlace. Las SKU con redundancia de zona tienen "AZ" al final. Por ejemplo, VpnGw1AZ.
2. Establezca la marca para usar la dirección IP privada en la puerta de enlace con los siguientes comandos
de PowerShell:
$Gateway = Get-AzVirtualNetworkGateway -Name <name of gateway> -ResourceGroup <name of resource

group>
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway -EnablePrivateIpAddress $true
Verá una dirección IP pública y una privada. Anote la dirección IP que se muestra en la sección
"TunnelIpAddresses" de la salida. Usará esta información en un paso posterior.
3. Establezca la conexión para que use la dirección IP privada con el siguiente comando de PowerShell:
$Connection = get-AzVirtualNetworkGatewayConnection -Name <name of the connection> -ResourceGroupName

<name of resource group>
Set-AzVirtualNetworkGatewayConnection --VirtualNetworkGatewayConnection $Connection -

UseLocalAzureIpAddress $true
4. En el firewall, haga ping a la dirección IP privada que anotó en el paso 2. Debe ser accesible a través del
emparejamiento privado de ExpressRoute.
5. Use esta dirección IP privada como dirección IP remota en el firewall local para establecer el túnel de sitio
a sitio a través del emparejamiento privado de ExpressRoute.
Pasos siguientes
Para más información sobre VPN Gateway, consulte ¿Qué es VPN Gateway?
Configuración de una conexión de VPN Gateway de
red virtual a red virtual mediante Azure Portal
Este artículo le ayuda a conectarse a redes virtuales mediante el tipo de conexión de red virtual a red virtual. Las
redes virtuales pueden estar en distintas regiones y provenir de distintas suscripciones. Al conectar redes
virtuales provenientes de distintas suscripciones, no es necesario que las suscripciones estén asociadas con el
mismo inquilino de Active Directory.
Los pasos descritos en este artículo se aplican al modelo de implementación de Azure Resource Manager y
utilizan Azure Portal. Puede crear esta configuración con un modelo o una herramienta de implementación
diferente a través de las opciones que se describen en estos artículos:
Acerca de la conexión de redes virtuales

En las secciones siguientes se describen las distintas formas de conectar redes virtuales.
Configurar una conexión de red virtual a red virtual es una forma sencilla de conectar redes virtuales. Cuando
conecta una red virtual a otra mediante el tipo de conexión entre redes virtuales (VNet2VNet) es parecida a la
creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de conectividad usan una
puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y funcionan de la misma forma
en lo relativo a la comunicación. Sin embargo, la manera en que se configura la puerta de enlace de red local es
distinta.
Cuando se crea una conexión de red virtual a red virtual, el espacio de direcciones de la puerta de enlace de red
local se crea y rellena automáticamente. Si actualiza el espacio de direcciones de una de las redes virtuales, la
otra enruta automáticamente al espacio de direcciones actualizado. Por lo general, es más rápido y sencillo crear
una conexión de red virtual a red virtual que una conexión de sitio a sitio.
De sitio a sitio (IPsec)
Si trabaja con una configuración de red complicada, puede que, en su lugar, prefiera conectar las redes virtuales
mediante una conexión de sitio a sitio. Cuando se siguen las instrucciones para la conexión IPsec de sitio a sitio,
las puertas de enlace de red locales se crean y se configuran manualmente. La puerta de enlace de red local de
cada red virtual trata a la otra red virtual como un sitio local. Estos pasos le permiten especificar espacios de
direcciones adicionales para que la puerta de enlace de red local enrute el tráfico. Si el espacio de direcciones de
una red virtual cambia, debe actualizar automáticamente la puerta de enlace de red local correspondiente.
También puede conectar las redes virtuales a través del emparejamiento de redes virtuales. El emparejamiento
de VNET no utiliza una puerta de enlace de VPN y tiene distintas restricciones. Además, los precios del
emparejamiento de VNET se calculan de forma diferente que los precios de VPN Gateway entre redes virtuales.
Para más información, consulte Emparejamiento de VNET.
¿Por qué crear una conexión de red virtual a red virtual?

Puede que desee conectar redes virtuales con una conexión entre redes virtuales por las siguientes razones:
Presencia geográfica y redundancia geográfica entre regiones
Puede configurar su propia replicación geográfica o sincronización con conectividad segura sin recurrir a los
puntos de conexión a Internet.
Con Azure Traffic Manager y Azure Load Balancer, puede configurar cargas de trabajo de alta disponibilidad
con redundancia geográfica en varias regiones de Azure. Por ejemplo, puede configurar grupos de
disponibilidad AlwaysOn de SQL Server en varias regiones de Azure.
Aplicaciones regionales de niveles múltiples con aislamiento o límites administrativos
Dentro de la misma región, se pueden configurar aplicaciones de niveles múltiples con varias redes virtuales
conectadas entre sí debido a requisitos de aislamiento o administrativos.
Se puede combinar la comunicación entre redes virtuales con configuraciones de varios sitios. Estas
configuraciones permiten establecer topologías de red que combinan la conectividad entre entornos locales con
la conectividad entre redes virtuales, como se muestra en el diagrama siguiente:
En este artículo se muestra cómo conectar redes virtuales mediante el tipo de conexión de red virtual a red
virtual. Cuando sigue estos pasos como ejercicio, puede usar estos valores de configuración de ejemplo. En el
ejemplo, las redes virtuales se encuentran en la misma suscripción, pero en distintos grupos de recursos. Si las
redes virtuales se encuentran en distintas suscripciones, no se puede crear la conexión en el portal. En su lugar,
use PowerShell o la CLI. Para más información sobre las conexiones de red virtual a red virtual, consulte las
preguntas más frecuentes sobre red virtual a red virtual.
Configuración de ejemplo
Valores de VNet1:
Configuración de la red vir tual
Name : VNet1
Espacio de direcciones : 10.1.0.0/16
Suscripción : Seleccione la suscripción que quiere usar.
Grupo de recursos : TestRG1
Ubicación : Este de EE. UU.
Subred
Name : FrontEnd
Inter valo de direcciones : 10.1.0.0/24
Configuración de puer ta de enlace de red vir tual
Name : VNet1GW
Grupo de recursos : Este de EE. UU.
Generación : Generación 1
Tipo de puer ta de enlace : Seleccione VPN .
Tipo de VPN : Seleccione Basada en rutas * .
SKU : VpnGw1
Red vir tual : VNet1
Inter valo de direcciones de subred de puer ta de enlace : 10.1.255.0/27
Nombre de dirección IP pública : VNet1GWpip
Connection
Name : VNet1toVNet4
Clave compar tida : Puede crear usted mismo la clave compartida. Cuando crea la conexión entre las
redes virtuales, los valores deben coincidir. Para este ejercicio, use abc123.
Valores de VNet4:
Configuración de la red vir tual
Name : VNet4
Suscripción : Seleccione la suscripción que quiere usar.
Grupo de recursos : TestRG4
Ubicación : Oeste de EE. UU.
Subred
Name : FrontEnd
Inter valo de direcciones : 10.41.0.0/24
Configuración de puer ta de enlace de red vir tual
Name : VNet4GW
Grupo de recursos : Oeste de EE. UU.
Generación : Generación 1
Tipo de puer ta de enlace : Seleccione VPN .
Tipo de VPN : seleccione Basada en rutas .
SKU : VpnGw1
Red vir tual : VNet4
Inter valo de direcciones de subred de puer ta de enlace : 10.41.255.0/27
Nombre de dirección IP pública : VNet4GWpip
Connection
Name : VNet4toVNet1
Clave compar tida : Puede crear usted mismo la clave compartida. Cuando crea la conexión entre las
redes virtuales, los valores deben coincidir. Para este ejercicio, use abc123.
Creación y configuración de VNet1
Si ya dispone de una red virtual, compruebe que la configuración sea compatible con el diseño de la puerta de
enlace de VPN. Preste especial atención a las subredes que se pueden superponer con otras redes. La conexión
no funcionará correctamente si tiene subredes superpuestas.
NOTE


valores:
Resource Manager.
necesite.
Firewall : Disabled
Creación de la puerta de enlace de VNet1

minutos o más, según la SKU de la puerta de enlace seleccionada. Si va a crear esta configuración como
ejercicio, consulte la configuración de ejemplo.
Creación de una puerta de enlace de red virtual
selecciónela.
en esta página.
de enlace.
enlace.
pública.
IMPORTANT
Creación y configuración de VNet4
Después de configurar VNet1, cree VNet4 y la puerta de enlace de VNet4 repitiendo los pasos anteriores, pero
reemplazando los valores por los de VNet4. No es preciso esperar a que la puerta de enlace de red virtual de
VNet1 haya terminado de crearse para configurar VNet4. Si usa sus propios valores, asegúrese de que los
espacios de direcciones no se superponen con las redes virtuales a las que quiere conectarse.
Configuración de la conexión de puerta de enlace de VNet1

Cuando se hayan completado las puertas de enlace de red virtual de VNet1 y VNet4, puede crear las conexiones
de dichas puertas de enlace. En esta sección, se crea una conexión de VNet1 a VNet4. Estos pasos solo funcionan
para las redes virtuales en la misma suscripción. Si las redes virtuales se encuentran en distintas suscripciones,
debe usar PowerShell para realizar la conexión. Sin embargo, si las redes virtuales se encuentran en distintos
grupos de recursos de la misma suscripción, puede conectarlas mediante el portal.
1. En Azure Portal, seleccione Todos los recursos , escriba puerta de enlace de red virtual en el cuadro de
búsqueda y vaya a la puerta de enlace de su red virtual. Por ejemplo, VNet1GW . Seleccione la puerta de
enlace para abrir la página Puer ta de enlace de red vir tual .
2. En la página de la puerta de enlace, vaya a Configuración-> Conexiones . A continuación, seleccione +
Agregar .
3. Se abrirá la página Agregar conexión .

En la página Agregar conexión , rellene los valores de la conexión:
Name : Escriba un nombre para la conexión. Por ejemplo, VNet1toVNet4.
Tipo de conexión : Seleccione De red vir tual a red vir tual en la lista desplegable.
Primera puer ta de enlace de red vir tual : Este valor de campo se rellena automáticamente
porque esta conexión se crea desde la puerta de enlace de red virtual especificada.
Segunda puer ta de enlace de red vir tual : Este campo es la puerta de enlace de la red virtual
con la que quiere crear una conexión. Seleccione Elegir otra puer ta de enlace de red vir tual
para abrir la página Elegir puer ta de enlace de red vir tual .
Fíjese en las puertas de enlace de red virtual que se enumeran en esta página. Observe que
solo se muestran las que se encuentran en su suscripción. Si quiere conectarse a una puerta
de enlace de red virtual que no está en su suscripción, use PowerShell.
Seleccione la puerta de enlace de red virtual con la que quiere conectarse.
Clave compar tida (PSK) : En este campo, escriba una clave compartida para la conexión. Dicha
clave puede generarla o crearla manualmente. En una conexión de sitio a sitio, la clave que usa es
la misma del dispositivo local y de la conexión de puerta de enlace de red virtual. Aquí el concepto
es similar, salvo en que en lugar de conectarse a un dispositivo VPN, la conexión se establece con
otra puerta de enlace de red virtual.
4. Seleccione Aceptar para guardar los cambios.
Configuración de la conexión de puerta de enlace de VNet4

A continuación, cree una conexión de VNet4 a VNet1. En el portal, busque la puerta de enlace de red virtual
asociada a VNet4. Siga los pasos de la sección anterior, reemplazando los valores para crear una conexión de
VNet4 a VNet1. Asegúrese de que utiliza la misma clave compartida.
Comprobación de las conexiones

1. Busque la puerta de enlace de red virtual en Azure Portal.
2. En la página Puer ta de enlace de red vir tual , seleccione Conexiones para ver la página Conexiones
de la puerta de enlace de red virtual. Una vez que se establece la conexión, verá que los valores de
Estado cambian a Conectado .
3. En la columna Nombre , seleccione una de las conexiones para ver más información. Cuando se inicia el
flujo de datos, aparecerán los valores para Datos de entrada y Datos de salida .
Incorporación de conexiones adicionales

Si quiere agregar más conexiones, vaya a la puerta de enlace de red virtual desde la que quiere crear la
conexión y, luego, seleccione Conexiones . Puede crear otra conexión entre redes virtual o bien crear una
conexión de IPsec de sitio a sitio en una ubicación local. Asegúrese de ajustar el Tipo de conexión para
coincidir con el tipo de conexión que desea crear. Antes de crear más conexiones, compruebe que el espacio de
direcciones de la red virtual no se superponga con ninguno de los espacios de direcciones con los que quiere
conectarse. Para saber qué pasos son necesarios para crear una conexión de sitio a sitio, consulte Creación de
una conexión de sitio a sitio.
P+F sobre conexiones de red virtual a red virtual

Vea los detalles de preguntas más frecuentes para más información acerca de las conexiones de red virtual a red
virtual.
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
(AAD)?
Sí, las conexiones entre dos redes virtuales que usan puertas de enlace de VPN de Azure funcionan en los
inquilinos de AAD.
¿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?
Pasos siguientes
Para información sobre cómo limitar el tráfico de red a los recursos de una red virtual, consulte
Seguridad de red.
Configuración de una conexión de VPN Gateway de
red virtual a red virtual mediante PowerShell
redes virtuales pueden estar en la misma región o en distintas, así como pertenecer a una única suscripción o a
varias. Al conectar redes virtuales de distintas suscripciones, estas no necesitan estar asociadas con el mismo
inquilino de Active Directory.
Los pasos descritos en este artículo se aplican al modelo de implementación de Resource Manager y utilizan
PowerShell. También se puede crear esta configuración con una herramienta o modelo de implementación
distintos, mediante la selección de una opción diferente en la lista siguiente:

Hay varias formas de conectar redes virtuales. Las siguientes secciones describen distintas formas de conectar
redes virtuales.
La configuración de una conexión entre redes virtuales es una buena manera de conectar redes virtuales
fácilmente. La conexión de una red virtual a otra mediante el tipo de conexión entre redes virtuales (VNet2VNet)
es parecida a la creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de
conectividad usan una puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y los dos
funcionan de la misma forma en lo relativo a la comunicación. La diferencia entre ambos tipos de conexión
radica en la manera en que se configura la puerta de enlace de red local. Al crear una conexión entre redes
virtuales, no se ve el espacio de direcciones de la puerta de enlace de red local. Se crea y rellena
automáticamente. Si actualiza el espacio de direcciones de una de las redes virtuales, la otra sabe
automáticamente cómo realizar el enrutamiento al espacio de direcciones actualizado. La creación de una
conexión entre redes virtuales suele ser más rápida y sencilla que la creación de una conexión de sitio a sitio
entre redes virtuales.
De sitio a sitio (IPsec)
Si puntualmente trabaja con una configuración de red complicada, puede que prefiera conectar sus redes
virtuales mediante los pasos que se indican en Creación de una red virtual con una conexión VPN de sitio a sitio
mediante PowerShell, en lugar de las instrucciones para la conexión entre redes virtuales. Cuando se usan las
instrucciones para la conexión de sitio a sitio, las puertas de enlace de red locales se crean y se configuran
manualmente. La puerta de enlace de red local de cada red virtual trata a la otra red virtual como un sitio local.
De esta forma, puede especificar más espacio de direcciones para la puerta de enlace de red local a fin de
enrutar el tráfico. Si el espacio de direcciones de una red virtual cambia, es preciso que actualice la puerta de
enlace de red local correspondiente para reflejar dicho cambio. No se actualiza automáticamente.
Puede que desee considerar conectar sus redes virtuales mediante el emparejamiento de VNET. El
emparejamiento de VNET no utiliza una puerta de enlace de VPN y tiene distintas restricciones. Además, los
precios del emparejamiento de VNET se calculan de forma diferente que los precios de VPN Gateway entre
redes virtuales. Para más información, consulte Emparejamiento de VNET.

Puede configurar su propia replicación geográfica o sincronización con conectividad segura sin
recurrir a los puntos de conexión a Internet.
Con el Equilibrador de carga y el Administrador de tráfico de Azure, puede configurar cargas de
trabajo de alta disponibilidad con redundancia geográfica en varias regiones de Azure. Por ejemplo,
puede configurar AlwaysOn de SQL con grupos de disponibilidad distribuidos en varias regiones de
Azure.
Aplicaciones regionales de niveles múltiples con aislamiento o un límite administrativo
Dentro de la misma región, se pueden configurar aplicaciones de niveles múltiples con varias redes
virtuales conectadas entre sí para cumplir requisitos administrativos o de aislamiento.
Se puede combinar la comunicación entre redes virtuales con configuraciones de varios sitios. Esto permite
establecer topologías de red que combinen la conectividad entre entornos con la conectividad entre redes
virtuales.
¿Qué instrucciones para la conexión entre redes virtuales debo

seguir?
En este artículo, verá dos conjuntos de pasos diferentes. Un conjunto de pasos para las redes virtuales que
residen en la misma suscripción y otro para las redes virtuales que residen en suscripciones diferentes. La
principal diferencia entre ambos conjuntos es que debe utilizar sesiones de PowerShell independientes al
configurar las conexiones de redes virtuales que residen en distintas suscripciones.
Para este ejercicio, puede combinar las configuraciones, o bien elegir con la que desea trabajar. Todas las
configuraciones utilizan el tipo de conexión entre redes virtuales. Flujos de tráfico de red entre las redes
virtuales que están directamente conectados entre sí. En este ejercicio, el tráfico de TestVNet4 no se enruta a
TestVNet5.
Redes virtuales que residen en la misma suscripción: En los pasos para esta configuración se utilizan
TestVNet1 y TestVNet4.
Redes virtuales que residen en distintas suscripciones: En los pasos para esta configuración se utilizan
TestVNet1 y TestVNet5.
Conexión de redes virtuales que están en la misma suscripción

Antes de empezar
NOTE
Dado que se tarda hasta 45 minutos en crear una puerta de enlace, el tiempo de Azure Cloud Shell
expirara periódicamente durante este ejercicio. Para reiniciar Cloud Shell, haga clic en la esquina superior
izquierda del terminal. No olvide volver a declarar las variables cuando se reinicie el terminal.
Si prefiere instalar la versión más reciente del módulo Azure PowerShell localmente, consulte el artículo
de Instalación y configuración de Azure PowerShell.
Paso 1: Planeamiento de los intervalos de direcciones IP
En los pasos siguientes, se crean dos redes virtuales junto con sus subredes de puerta de enlace y
configuraciones correspondientes. Luego, se crea una conexión VPN entre las dos redes virtuales. Es importante
planear los intervalos de direcciones IP para la configuración de red. Tenga en cuenta que hay que asegurarse de
que ninguno de los intervalos de VNet o intervalos de red local se solapen. En estos ejemplos, no se incluye
ningún servidor DNS. Si desea disponer de resolución de nombres en las redes virtuales, consulte Resolución de
nombres.
En los ejemplos usamos los siguientes valores:
Valores para TestVNet1:
Nombre de la red virtual: TestVNet1
TestVNet1: 10.11.0.0/16 y 10.12.0.0/16
front-end: 10.11.0.0/24
BackEnd: 10.12.0.0/24
GatewaySubnet: 10.12.255.0/27
GatewayName: VNet1GW
Public IP: VNet1GWIP
VPNType: RouteBased
Connection(1to4): VNet1toVNet4
Connection(1to5): VNet1toVNet5 (para redes virtuales de suscripciones distintas)
ConnectionType: VNet2VNet
TestVNet2: 10.41.0.0/16 y 10.42.0.0/16
front-end: 10.41.0.0/24
BackEnd: 10.42.0.0/24
Ubicación: Oeste de EE. UU.
VPNType: RouteBased
Conexión: VNet4toVNet1
Paso 2: Creación y configuración de TestVNet1
1. Compruebe la configuración de la suscripción.
Si ejecuta Azure PowerShell localmente en el equipo, conéctese a la cuenta. Si usa Azure Cloud Shell, se
conectará automáticamente.
Connect-AzAccount
Get-AzSubscription
Select-AzSubscription -SubscriptionName nameofsubscription
2. Declare las variables. En este ejemplo se declaran las variables con los valores para este ejercicio. En la
mayoría de los casos, deberá reemplazar los valores por los suyos propios. No obstante, puede usar estas
variables si está practicando los pasos para familiarizarse con este tipo de configuración. Si es necesario,
modifique las variables y después cópielas y péguelas en la consola de PowerShell.
$RG1 = "TestRG1"
$Location1 = "East US"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$GWIPconfName1 = "gwipconf1"
4. Cree las configuraciones de subred para TestVNet1. En este ejemplo se crea una red virtual denominada
TestVNet1 y tres subredes llamadas: GatewaySubnet, FrontEnd y Backend. Al reemplazar valores, es
importante que siempre asigne el nombre GatewaySubnet a la subred de la puerta de enlace. Si usa otro,
se produce un error al crear la puerta de enlace. Por esta razón, no se asigna a través de la variable
siguiente.
El siguiente ejemplo usa las variables que estableció anteriormente. En este ejemplo, la subred de la
puerta de enlace está usando un /27. Aunque es posible crear una subred de puerta de enlace tan
pequeña como /29, se recomienda que cree una subred mayor que incluya más direcciones
seleccionando al menos /28 o /27. Esto permitirá suficientes direcciones para dar cabida a posibles
configuraciones adicionales que desee en el futuro.

$gwsub1 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix $GWSubPrefix1
5. Cree TestVNet1.
New-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1
6. Solicite que se asigne una dirección IP pública a la puerta de enlace que creará para la red virtual.
Observe que AllocationMethod es dinámico. No puede especificar la dirección IP que desea usar. Se
asigna dinámicamente a la puerta de enlace.
$gwpip1 = New-AzPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 `

-Location $Location1 -AllocationMethod Dynamic
7. Establezca la configuración de la puerta de enlace. La configuración de puerta de enlace define la subred

y la dirección IP pública. Use el ejemplo para crear la configuración de la puerta de enlace.

$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 `
-Subnet $subnet1 -PublicIpAddress $gwpip1
8. Cree la puerta de enlace para TestVNet1. En este paso, creará la puerta de enlace de red virtual para
TestVNet1. Las configuraciones VNet a VNet requieren un VpnType RouteBased. La creación de una
puerta de enlace suele tardar 45 minutos o más, según la SKU de la puerta de enlace seleccionada.

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
Cuando termine con los comandos, esta puerta de enlace tardará hasta 45 minutos en crearse. Si usa Azure
Cloud Shell, puede reiniciar la sesión; para ello, haga clic en la esquina superior izquierda del terminal de Cloud
Shell y configure TestVNet4. No es necesario esperar hasta que se complete la puerta de enlace de TestVNet1.
Una vez que haya configurado TestVNet1, cree TestVNet4. Siga los pasos a continuación y reemplace los valores
por los suyos propios cuando sea necesario.
1. Conéctese y declare las variables. Asegúrese de reemplazar los valores por los que desea usar para su
configuración.
$RG4 = "TestRG4"
$Location4 = "West US"
$VnetName4 = "TestVNet4"
$VnetPrefix41 = "10.41.0.0/16"
$VnetPrefix42 = "10.42.0.0/16"
$FESubPrefix4 = "10.41.0.0/24"
$BESubPrefix4 = "10.42.0.0/24"
$GWSubPrefix4 = "10.42.255.0/27"
3. Cree las configuraciones de subred para TestVNet4.

$gwsub4 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix $GWSubPrefix4
4. Cree TestVNet4.
New-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4 `

-Location $Location4 -AddressPrefix $VnetPrefix41,$VnetPrefix42 -Subnet $fesub4,$besub4,$gwsub4
5. Pida una dirección IP pública.

6. Establezca la configuración de la puerta de enlace.
$vnet4 = Get-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4

$gwipconf4 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName4 -Subnet $subnet4 -
PublicIpAddress $gwpip4
7. Creación de la puerta de enlace de TestVNet4. La creación de una puerta de enlace suele tardar 45

-Location $Location4 -IpConfigurations $gwipconf4 -GatewayType Vpn `
Paso 4: Creación de las conexiones

Espere hasta que se hayan completado ambas puertas de enlace. Reinicie la sesión de Azure Cloud Shell, y copie
y pegue las variables del principio del paso 2 y el paso 3 en la consola para volver a declarar los valores.
1. Obtenga ambas puertas de enlace de red virtual.
2. Cree la conexión de TestVNet1 a TestVNet4. En este paso, creará la conexión de TestVNet1 a TestVNet4.
Verá una clave compartida a la que se hace referencia en los ejemplos. Puede utilizar sus propios valores
para la clave compartida. Lo importante es que la clave compartida coincida en ambas conexiones. Se
tardará unos momentos en terminar de crear la conexión.

3. Cree la conexión de TestVNet4 a TestVNet1. Este paso es similar al anterior, salvo en que se crea la
conexión de TestVNet4 a TestVNet1. Asegúrese de que coincidan las claves compartidas. Después de unos
minutos, se habrá establecido la conexión.

4. Compruebe la conexión. Consulte la sección Comprobación de la conexión.
Conexión de redes virtuales que están en suscripciones diferentes

En este escenario, se conectan TestVNet1 y TestVNet5. TestVNet1 y TestVNet5 residen en suscripciones
diferentes. Las suscripciones no necesitan estar asociadas con el mismo inquilino de Active Directory.
La diferencia entre estos pasos y el conjunto anterior es que parte de los pasos de configuración se deben
realizar en una sesión de PowerShell distinta en el contexto de la segunda suscripción. Especialmente cuando las
dos suscripciones pertenecen a distintas organizaciones.
Debido al cambio de contexto de la suscripción en este ejercicio, al llegar al paso 8 le resultará más fácil usar
PowerShell localmente en el equipo, en lugar de utilizar Azure Cloud Shell.
Tiene que completar el paso 1 y el paso 2 de la sección anterior para crear y configurar TestVNet1 y VPN
Gateway para TestVNet1. Para esta configuración, no se necesita crear TestVNet4 de la sección anterior, aunque,
si la creó, no entrará en conflicto con estos pasos. Cuando haya completado el paso 1 y el 2, continúe con el
paso 6 para crear TestVNet5.
Paso 6: Comprobación de los intervalos de direcciones IP
Es importante asegurarse de que el espacio de direcciones IP de la red virtual nueva, TestVNet5, no se solape
con ninguno de los intervalos de red virtual o de puerta de enlace de red local. En este ejemplo, las redes
virtuales pueden pertenecer a distintas organizaciones. En este ejercicio, use los siguientes valores para
TestVNet5:
Ubicación: Japón Oriental
TestVNet5: 10.51.0.0/16 y 10.52.0.0/16
front-end: 10.51.0.0/24
BackEnd: 10.52.0.0/24
GatewaySubnet: 10.52.255.0.0/27
VPNType: RouteBased
Este paso debe realizarse en el contexto de la nueva suscripción. Es posible que esta parte la realice el
administrador de otra organización que posea la suscripción.
1. Declare las variables. Asegúrese de reemplazar los valores por los que desea usar para su configuración.
$Sub5 = "Replace_With_the_New_Subscription_Name"
$RG5 = "TestRG5"
$Location5 = "Japan East"
$VnetName5 = "TestVNet5"
$VnetPrefix51 = "10.51.0.0/16"
$VnetPrefix52 = "10.52.0.0/16"
$FESubPrefix5 = "10.51.0.0/24"
$BESubPrefix5 = "10.52.0.0/24"
$GWSubPrefix5 = "10.52.255.0/27"
2. Conéctese con la suscripción 5. Abre la consola de PowerShell y conéctate a tu cuenta. Use el siguiente
ejemplo para ayudarle a conectarse:
Connect-AzAccount
Get-AzSubscription
Select-AzSubscription -SubscriptionName $Sub5
3. Cree un nuevo grupo de recursos.
4. Cree las configuraciones de subred para TestVNet5.

5. Cree TestVNet5.
New-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5 -Location $Location5 `

-AddressPrefix $VnetPrefix51,$VnetPrefix52 -Subnet $fesub5,$besub5,$gwsub5

7. Establezca la configuración de la puerta de enlace.
$vnet5 = Get-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5

$gwipconf5 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName5 -Subnet $subnet5 -
8. Cree la puerta de enlace de TestVNet5.
New-AzVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5 -Location $Location5 `

-IpConfigurations $gwipconf5 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

En este ejemplo, como las puertas de enlace están en suscripciones diferentes, hemos dividido el paso en dos
sesiones de PowerShell marcadas como [Suscripción 1] y [Suscripción 5].
1. [Suscripción 1] Obtenga la puerta de enlace de red virtual para la suscripción 1. Inicie sesión y
conéctese a la Suscripción 1 antes de ejecutar el siguiente ejemplo:
Copie la salida de los siguientes elementos y envíesela al administrador de la suscripción 5 por correo
electrónico u otro método.
$vnet1gw.Name
$vnet1gw.Id
Estos dos elementos tendrán valores similares a la salida de ejemplo siguiente:
PS D:\> $vnet1gw.Name
VNet1GW
PS D:\> $vnet1gw.Id
/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroupsTestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
2. [Suscripción 5] Obtenga la puerta de enlace de red virtual para la suscripción 5. Inicie sesión y
conéctese a la Suscripción 5 antes de ejecutar el siguiente ejemplo:
Copie la salida de los siguientes elementos y envíesela al administrador de la suscripción 1 por correo
electrónico u otro método.
$vnet5gw.Name
$vnet5gw.Id
Estos dos elementos tendrán valores similares a la salida de ejemplo siguiente:
PS C:\> $vnet5gw.Name
VNet5GW
PS C:\> $vnet5gw.Id
/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW
3. [Suscripción 1] Cree la conexión entre TestVNet1 y TestVNet5. En este paso, creará la conexión de
TestVNet1 a TestVNet5. La diferencia en este caso es que no se puede obtener $vnet5gw directamente
porque está en una suscripción diferente. Debe crear un nuevo objeto de PowerShell con los valores que
se le hayan proporcionado para la suscripción 1 en los pasos anteriores. Use el ejemplo siguiente.
Reemplace el nombre (Name), el identificador (ID) y la clave compartida por sus propios valores. Lo
importante es que la clave compartida coincida en ambas conexiones. Se tardará unos momentos en
terminar de crear la conexión.
Conéctese a Suscripción 1 antes de ejecutar el ejemplo siguiente:
$vnet5gw = New-Object -TypeName Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway

$vnet5gw.Name = "VNet5GW"
$vnet5gw.Id = "/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW"
VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet5gw -Location $Location1 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'
4. [Suscripción 5] Cree la conexión entre TestVNet5 y TestVNet1. Este paso es similar al anterior, salvo en
que se crea la conexión de TestVNet5 a TestVNet1. Aquí también se aplica el mismo proceso de creación
de un objeto de PowerShell basándose en los valores obtenidos de la suscripción 1. En este paso,
asegúrese de que las claves compartidas coincidan.
Conéctese a Suscripción 5 antes de ejecutar el ejemplo siguiente:
$vnet1gw = New-Object -TypeName Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway

$vnet1gw.Name = "VNet1GW"
$vnet1gw.Id = "/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW "
VirtualNetworkGateway1 $vnet5gw -VirtualNetworkGateway2 $vnet1gw -Location $Location5 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'
Comprobación de una conexión

IMPORTANT

virtuales.
(AAD)?
inquilinos de AAD.
No.
Azure?
estos escenarios.
PolicyBased?
dinámico).
Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Consulte la
documentación sobre máquinas virtuales para más información.
Configuración de una conexión de puerta de enlace
de VPN de red virtual a red virtual mediante la CLI
de Azure
redes virtuales pueden estar en la misma región o en distintas, así como pertenecer a una única suscripción o a
varias. Al conectar redes virtuales de distintas suscripciones, estas no necesitan estar asociadas con el mismo
inquilino de Active Directory.
Los pasos descritos en este artículo se aplican al modelo de implementación de Resource Manager y usan la CLI
de Azure. También se puede crear esta configuración con una herramienta o modelo de implementación
distintos, mediante la selección de una opción diferente en la lista siguiente:

Hay varias formas de conectar redes virtuales. Las siguientes secciones describen distintas formas de conectar
redes virtuales.
La configuración de una conexión entre redes virtuales es una buena manera de conectar redes virtuales
fácilmente. La conexión de una red virtual a otra mediante el tipo de conexión entre redes virtuales es parecida a
la creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de conectividad usan una
puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y los dos funcionan de la misma
forma en lo relativo a la comunicación. La diferencia entre ambos tipos de conexión radica en la manera en que
se configura la puerta de enlace de red local. Al crear una conexión entre redes virtuales, no se ve el espacio de
direcciones de la puerta de enlace de red local. Se crea y rellena automáticamente. Si actualiza el espacio de
direcciones de una de las redes virtuales, la otra sabe automáticamente cómo realizar el enrutamiento al espacio
de direcciones actualizado. La creación de una conexión entre redes virtuales suele ser más rápida y sencilla que
la creación de una conexión de sitio a sitio entre redes virtuales.
Conexión de redes virtuales mediante los pasos de sitio a sitio (IPsec)
Si puntualmente trabaja con una configuración de red complicada, puede que prefiera conectar sus redes
virtuales mediante los pasos que se indican en Creación de una red virtual con una conexión VPN de sitio a sitio
mediante PowerShell, en lugar de los pasos entre redes virtuales. Cuando se usan las instrucciones para la
conexión de sitio a sitio, las puertas de enlace de red locales se crean y se configuran manualmente. La puerta
de enlace de red local de cada red virtual trata a la otra red virtual como un sitio local. De esta forma, puede
especificar más espacio de direcciones para la puerta de enlace de red local a fin de enrutar el tráfico. Si el
espacio de direcciones de una red virtual cambia, es preciso que actualice manualmente la puerta de enlace de
red local correspondiente para reflejar dicho cambio. No se actualiza automáticamente.
Puede que desee considerar conectar sus redes virtuales mediante el emparejamiento de VNET. El
emparejamiento de VNET no utiliza una puerta de enlace de VPN y tiene distintas restricciones. Además, los
precios del emparejamiento de VNET se calculan de forma diferente que los precios de VPN Gateway entre
redes virtuales. Para más información, consulte Emparejamiento de VNET.

Con el Equilibrador de carga y el Administrador de tráfico de Azure, puede configurar cargas de
trabajo de alta disponibilidad con redundancia geográfica en varias regiones de Azure. Por ejemplo,
puede configurar AlwaysOn de SQL con grupos de disponibilidad distribuidos en varias regiones de
Azure.
Aplicaciones regionales de niveles múltiples con aislamiento o un límite administrativo
Dentro de la misma región, se pueden configurar aplicaciones de niveles múltiples con varias redes
virtuales conectadas entre sí para cumplir requisitos administrativos o de aislamiento.
Se puede combinar la comunicación entre redes virtuales con configuraciones de varios sitios. Esto permite
establecer topologías de red que combinen la conectividad entre entornos con la conectividad entre redes
virtuales.
¿Qué instrucciones para la conexión entre redes virtuales debo

seguir?
En este artículo, verá dos conjuntos de pasos diferentes de la conexión entre redes virtuales. Un conjunto de
pasos para las redes virtuales que residen en la misma suscripción y otro para las redes virtuales que residen en
suscripciones diferentes.
Para este ejercicio, puede combinar las configuraciones, o bien elegir con la que desea trabajar. Todas las
configuraciones utilizan el tipo de conexión entre redes virtuales. Flujos de tráfico de red entre las redes
virtuales que están directamente conectados entre sí. En este ejercicio, el tráfico de TestVNet4 no se enruta a
TestVNet5.
Redes virtuales que residen en la misma suscripción: los pasos de esta configuración utilizan TestVNet1 y
TestVNet4.
Redes virtuales que residen en distintas suscripciones: los pasos de esta configuración utilizan TestVNet1
y TestVNet5.
Conexión de redes virtuales que están en la misma suscripción

Antes de empezar
Antes de empezar, instale la versión más reciente de los comandos de la CLI (2.0 o posteriores). Para obtener
más información sobre la instalación de los comandos de la CLI, consulte Instalación de la CLI de Azure.
Planeamiento de los intervalos de direcciones IP
En los pasos siguientes, se crean dos redes virtuales junto con sus subredes de puerta de enlace y
configuraciones correspondientes. Luego, se crea una conexión VPN entre las dos redes virtuales. Es importante
planear los intervalos de direcciones IP para la configuración de red. Tenga en cuenta que hay que asegurarse de
que ninguno de los intervalos de VNet o intervalos de red local se solapen. En estos ejemplos, no se incluye
ningún servidor DNS. Si desea disponer de resolución de nombres en las redes virtuales, consulte Resolución de
nombres.
En los ejemplos usamos los siguientes valores:
TestVNet1: 10.11.0.0/16 y 10.12.0.0/16
front-end: 10.11.0.0/24
BackEnd: 10.12.0.0/24
VPNType: RouteBased
Connection(1to4): VNet1toVNet4
Connection(1to5): VNet1toVNet5 (para redes virtuales de suscripciones distintas)
TestVNet2: 10.41.0.0/16 y 10.42.0.0/16
front-end: 10.41.0.0/24
BackEnd: 10.42.0.0/24
VPNType: RouteBased
Paso 1: Conexión a la suscripción
1. Inicie sesión en la suscripción de Azure con el comando az login y siga las instrucciones que aparecen en
az login
2. Si tiene más de una suscripción de Azure, enumere las suscripciones de la cuenta.
3. Especifique la suscripción que desea usar.


az group create -n TestRG1 -l eastus
2. Cree TestVNet1 y las subredes para TestVNet1. En este ejemplo se crea una red virtual denominada
TestVNet1 y una subred llamada FrontEnd.
az network vnet create -n TestVNet1 -g TestRG1 --address-prefix 10.11.0.0/16 -l eastus --subnet-name

FrontEnd --subnet-prefix 10.11.0.0/24
3. Cree otro espacio de direcciones para la subred de back-end. Tenga en cuenta que, en este paso, se
especifican tanto el espacio de direcciones que se creó antes como el adicional que se va a agregar. Esto
se debe a que el comando az network vnet update sobrescribe la configuración anterior. Asegúrese de
especificar todos los prefijos de direcciones cuando use este comando.
az network vnet update -n TestVNet1 --address-prefixes 10.11.0.0/16 10.12.0.0/16 -g TestRG1
4. Cree la subred de back-end.
az network vnet subnet create --vnet-name TestVNet1 -n BackEnd -g TestRG1 --address-prefix

10.12.0.0/24
5. Cree la subred de la puerta de enlace. Asegúrese de que la subred de puerta de enlace se llame
"GatewaySubnet". Este nombre es obligatorio. En este ejemplo, la subred de la puerta de enlace está
usando un /27. Aunque es posible crear una subred de puerta de enlace tan pequeña como /29, se
recomienda que cree una subred mayor que incluya más direcciones seleccionando al menos /28 o /27.
Esto permitirá suficientes direcciones para dar cabida a posibles configuraciones adicionales que desee
en el futuro.
az network vnet subnet create --vnet-name TestVNet1 -n GatewaySubnet -g TestRG1 --address-prefix

10.12.255.0/27
6. Solicite que se asigne una dirección IP pública a la puerta de enlace que creará para la red virtual.
Observe que AllocationMethod es dinámico. No puede especificar la dirección IP que desea usar. Se
asigna dinámicamente a la puerta de enlace.
az network public-ip create -n VNet1GWIP -g TestRG1 --allocation-method Dynamic
7. Cree la puerta de enlace de red virtual para TestVNet1. Las configuraciones VNet a VNet requieren un
VpnType RouteBased. Si este comando se ejecuta con el parámetro '--no-wait', no se verán los
comentarios o resultados. El parámetro "--no-wait" permite que la puerta de enlace se cree en segundo
plano. No significa que se termine de crear la puerta de enlace de VPN de inmediato. Se suelen tardar 45
minutos o más en crear una puerta de enlace, según la SKU de puerta de enlace que se use.
az network vnet-gateway create -n VNet1GW -l eastus --public-ip-address VNet1GWIP -g TestRG1 --vnet
TestVNet1 --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased --no-wait

az group create -n TestRG4 -l westus
2. Cree TestVNet4.
az network vnet create -n TestVNet4 -g TestRG4 --address-prefix 10.41.0.0/16 -l westus --subnet-name

3. Cree subredes adicionales para TestVNet4.

10.42.0.0/24
4. Cree la subred de la puerta de enlace.

10.42.255.0/27
5. Solicite una dirección IP pública.
6. Cree la puerta de enlace de la red virtual TestVNet4.
az network vnet-gateway create -n VNet4GW -l westus --public-ip-address VNet4GWIP -g TestRG4 --vnet

TestVNet4 --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased --no-wait

Ahora tiene dos redes virtuales con puertas de enlace de VPN. El siguiente paso consiste en crear conexiones de
puerta de enlace de VPN entre las puertas de enlace de red virtual. Si usó los ejemplos anteriores, las puertas de
enlace de red virtual se encuentran en grupos de recursos distintos. Cuando las puertas de enlace están en
grupos de recursos distintos, debe identificar y especificar los identificadores de recursos para cada puerta de
enlace al establecer una conexión. Si sus redes virtuales están en el mismo grupo de recursos, puede usar el
segundo conjunto de instrucciones porque no es necesario especificar los identificadores de recursos.
Para conectar redes virtuales que residen en grupos de recursos distintos
1. Obtenga el id. de recurso de VNet1GW de la salida del comando siguiente:
az network vnet-gateway show -n VNet1GW -g TestRG1
En la salida, busque la línea "id:". Los valores entrecomillados se necesitan para crear la conexión en la
sección siguiente. Copie estos valores en un editor de texto, como el Bloc de notas, para que pueda
pegarlos fácilmente al crear la conexión.
Salida de ejemplo:
"bgpSettings": {
"asn": 65515,
"bgpPeeringAddress": "10.12.255.30",
"peerWeight": 0
},
"enableBgp": false,
"etag": "W/\"ecb42bc5-c176-44e1-802f-b0ce2962ac04\"",
"id": "/subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW",
"ipConfigurations":
Copie los valores después de "id": dentro de las comillas.
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW"
2. Obtenga el id. de recurso de VNet4GW y copie los valores en un editor de texto.
3. Cree la conexión de TestVNet1 a TestVNet4. En este paso, creará la conexión de TestVNet1 a TestVNet4. Se
hace referencia a una clave compartida en los ejemplos. Puede utilizar sus propios valores para la clave
compartida. Lo importante es que la clave compartida coincida en ambas conexiones. Se tardará unos
momentos en terminar de crear la conexión.
az network vpn-connection create -n VNet1ToVNet4 -g TestRG1 --vnet-gateway1 /subscriptions/d6ff83d6-

713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW -l
eastus --shared-key "aabbcc" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG4/providers/Microsoft.Network/virtualNetworkGateways/VNet4GW
conexión de TestVNet4 a TestVNet1. Asegúrese de que coincidan las claves compartidas. Se tarda unos
minutos en establecer la conexión.

713d-41f6-a025-
westus --shared-key "aabbcc" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1G
5. Compruebe las conexiones. Consulte Comprobación de las conexiones.

Para conectar redes virtuales que residen en el mismo grupo de recursos
1. Cree la conexión de TestVNet1 a TestVNet4. En este paso, creará la conexión de TestVNet1 a TestVNet4.
Tenga en cuenta que los grupos de recursos son iguales en los ejemplos. También verá una clave
compartida a la que se hace referencia en los ejemplos. Puede usar sus propios valores para la clave
compartida, pero esta debe coincidir en ambas conexiones. Se tardará unos momentos en terminar de
crear la conexión.
az network vpn-connection create -n VNet1ToVNet4 -g TestRG1 --vnet-gateway1 VNet1GW -l eastus --
shared-key "eeffgg" --vnet-gateway2 VNet4GW
conexión de TestVNet4 a TestVNet1. Asegúrese de que coincidan las claves compartidas. Se tarda unos
minutos en establecer la conexión.
az network vpn-connection create -n VNet4ToVNet1 -g TestRG1 --vnet-gateway1 VNet4GW -l eastus --

shared-key "eeffgg" --vnet-gateway2 VNet1GW
3. Compruebe las conexiones. Consulte Comprobación de las conexiones.
Conexión de redes virtuales que están en suscripciones diferentes

En este escenario, se conectan TestVNet1 y TestVNet5. Las redes virtuales residen en suscripciones distintas. Las
suscripciones no necesitan estar asociadas con el mismo inquilino de Active Directory. Los pasos para esta
configuración permiten agregar una conexión de red virtual a red virtual adicional para poder conectar
TestVNet1 a TestVNet5.
Estas instrucciones son una continuación de los pasos descritos en las secciones anteriores. Tiene que completar
el paso 1 y el paso 2 para crear y configurar TestVNet1 y VPN Gateway para TestVNet1. Para esta configuración,
no se necesita crear TestVNet4 de la sección anterior, aunque, si la creó, no entrará en conflicto con estos pasos.
Cuando haya completado el paso 1 y el 2, continúe con el paso 6 (a continuación).
Paso 6: Comprobación de los intervalos de direcciones IP
Cuando cree conexiones adicionales, es importante asegurarse de que el espacio de direcciones IP de la red
virtual nueva no se solape con ninguno de los demás intervalos de redes virtuales o de puertas de enlace de red
local. En este ejercicio, use los siguientes valores para TestVNet5:
Ubicación: Japón Oriental
TestVNet5: 10.51.0.0/16 y 10.52.0.0/16
front-end: 10.51.0.0/24
BackEnd: 10.52.0.0/24
GatewaySubnet: 10.52.255.0.0/27
VPNType: RouteBased
Este paso debe realizarse en el contexto de la nueva suscripción, Suscripción 5. Es posible que esta parte la
realice el administrador de otra organización que posea la suscripción. Para cambiar entre suscripciones, use
az account list --all para obtener una lista de las suscripciones disponibles para su cuenta y después use
az account set --subscription <subscriptionID> para cambiar a la suscripción que desea usar.
1. Asegúrese de que está conectados a Suscripción 5 y cree un grupo de recursos.

az group create -n TestRG5 -l japaneast
2. Cree TestVNet5.
az network vnet create -n TestVNet5 -g TestRG5 --address-prefix 10.51.0.0/16 -l japaneast --subnet-

name FrontEnd --subnet-prefix 10.51.0.0/24
3. Agregue subredes.

10.52.0.0/24
4. Agregue la subred de puerta de enlace.

10.52.255.0/27
6. Creación de la puerta de enlace de TestVNet5
az network vnet-gateway create -n VNet5GW -l japaneast --public-ip-address VNet5GWIP -g TestRG5 --

vnet TestVNet5 --gateway-type Vpn --sku VpnGw1 --vpn-type RouteBased --no-wait

Este paso se divide en dos sesiones de la CLI marcadas como [Suscripción 1] y [Suscripción 5] , ya que las
puertas de enlace están en suscripciones diferentes. Para cambiar entre suscripciones, use
az account list --all para obtener una lista de las suscripciones disponibles para su cuenta y después use
az account set --subscription <subscriptionID> para cambiar a la suscripción que desea usar.
1. [Suscripción 1] Inicie sesión y conéctese a Suscripción 1. Ejecute el siguiente comando para obtener el
nombre y el identificador de la puerta de enlace de la salida:
Copie la salida para "id:". Envíe el identificador y el nombre de la puerta de enlace de red virtual
(VNet1GW) al administrador de Suscripción 5 por correo electrónico u otro método.
Salida de ejemplo:
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW"
2. [Suscripción 5] Inicie sesión y conéctese a Suscripción 5. Ejecute el siguiente comando para obtener el
nombre y el identificador de la puerta de enlace de la salida:
Copie la salida para "id:". Envíe el identificador y el nombre de la puerta de enlace de red virtual
(VNet5GW) al administrador de Suscripción 1 por correo electrónico u otro método.
3. [Suscripción 1] En este paso, va a crear la conexión de TestVNet1 a TestVNet5. Puede usar sus propios
valores para la clave compartida, pero esta debe coincidir en ambas conexiones. Se tardará unos
momentos en terminar de crear la conexión. Asegúrese de conectarse a la suscripción 1.

713d-41f6-a025-
eastus --shared-key "eeffgg" --vnet-gateway2 /subscriptions/e7e33b39-fe28-4822-b65c-
a4db8bbff7cb/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW
4. [Suscripción 5] Este paso es similar al anterior, salvo en que se crea la conexión de TestVNet5 a
TestVNet1. Asegúrese de que las claves compartidas coincidan y que se conecta a Suscripción 5.
az network vpn-connection create -n VNet5ToVNet1 -g TestRG5 --vnet-gateway1 /subscriptions/e7e33b39-

fe28-4822-b65c-
a4db8bbff7cb/resourceGroups/TestRG5/providers/Microsoft.Network/virtualNetworkGateways/VNet5GW -l
japaneast --shared-key "eeffgg" --vnet-gateway2 /subscriptions/d6ff83d6-713d-41f6-a025-
5eb76334fda9/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
Comprobación de las conexiones

IMPORTANT

virtuales.
(AAD)?
inquilinos de AAD.
No.
Azure?
estos escenarios.
PolicyBased?
dinámico).
Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Para más
información, consulte la documentación sobre máquinas virtuales.
Conexión de redes virtuales a partir de diferentes
modelos de implementación con el portal
Este artículo muestra cómo conectar redes virtuales clásicas a redes virtuales de Resource Manager para
permitir que los recursos que se encuentran en modelos de implementación independientes se comuniquen
entre sí. En los pasos de este artículo se usa fundamentalmente Azure Portal, pero también se puede crear esta
configuración con PowerShell si se selecciona el artículo en esta lista.
La conexión de una red virtual clásica a una red virtual de Resource Manager es similar a la conexión de una red
virtual a una ubicación de sitio local. Ambos tipos de conectividad usan una puerta de enlace de VPN para
proporcionar un túnel seguro con IPsec/IKE. Puede crear una conexión entre redes virtuales que estén en
diferentes suscripciones y en diferentes regiones. También puede conectar redes virtuales que tengan ya
conexiones a redes locales, siempre que la puerta de enlace con la que se hayan configurado sea dinámica o
basada en ruta. Para más información acerca de las conexiones de red virtual a red virtual, consulte P+F sobre
conexiones de red virtual a red virtual al final de este artículo.
Si aún no tiene una puerta de enlace de red virtual y no desea crear una, considere la posibilidad de conectar
sus redes virtuales mediante Emparejamiento de VNET. El emparejamiento de VNET no usa VPN Gateway. Para
más información, consulte Emparejamiento de VNET.
Antes de empezar
En estos pasos se presume que ya se crearon ambas redes virtuales. Si usa este artículo como ejercicio y no
tiene redes virtuales, los pasos incluyen vínculos que le ayudarán a crearlas.
Compruebe que los intervalos de direcciones de las redes virtuales no se superponen entre sí ni con alguno
de los intervalos de otras conexiones con las que puedan estar conectadas las puertas de enlace.
Instale los cmdlets de PowerShell más recientes para Resource Manager y Service Management (clásico). En
este artículo se usan Azure Portal y PowerShell. PowerShell es necesario para crear la conexión desde la red
virtual clásica a la red virtual de Resource Manager. Para obtener más información, consulte Instalación y
configuración de Azure PowerShell.
Puede usar estos valores para crear un entorno de prueba o hacer referencia a ellos para comprender mejor los
ejemplos de este artículo.
Red vir tual clásica
Nombre de red virtual = ClassicVNet
Espacio de direcciones = 10.0.0.0/24
Nombre de subred = Subnet-1
Intervalo de direcciones de subred = 10.0.0.0/27
Suscripción = la suscripción que desea usar
Grupo de recursos = ClassicRG
Ubicación = Oeste de EE. UU.
Sitio local = RMVNetLocal
Red vir tual de Resource Manager
Nombre de red virtual = RMVNet
Grupo de recursos = GR1
Ubicación = Este de EE. UU.
Intervalo de direcciones = 192.168.1.0/24
Subred de la puerta de enlace = 192.168.0.0/26
Nombre de la puerta de enlace de red virtual = PuertaDeEnlaceRM
Tipo de puerta de enlace = VPN
Tipo de VPN = basada en enrutamiento
SKU = VpnGw1
Red virtual = RMVNet
(asocie la puerta de enlace de VPN a esta red virtual) Configuración de la primera dirección IP = rmgwpip
(dirección IP pública de la puerta de enlace) Puerta de enlace de red local = ClassicVNetLocal
Nombre de conexión = RMtoClassic
Información general sobre la conexión
Para esta configuración se crea una conexión de puerta de enlace VPN a través de un túnel VPN de IPsec/IKE
entre las redes virtuales. Asegúrese de que ninguno de los intervalos de red virtual se superponga con otro o
con cualquiera de las redes locales a las que se conectan.
En la tabla siguiente se muestra un ejemplo de cómo se definen los sitios locales y las redes virtuales de
ejemplo:
SE C O N EC TA A UN SIT IO DE
VIRT UA L N ET W O RK ESPA C IO DE DIREC C IO N ES REGIO N RED LO C A L
ClassicVNet (10.0.0.0/24) Oeste de EE. UU. RMVNetLocal

(192.168.0.0/16)
RMVNet (192.168.0.0/16) Este de EE. UU. ClassicVNetLocal

(10.0.0.0/24)
Sección 1: Configuración de la red virtual clásica

En esta sección se crea la red virtual clásica, la red local (sitio local) y la puerta de enlace de red virtual. Las
capturas de pantalla se proporcionan a modo de ejemplo. Asegúrese de reemplazar los valores por los suyos o
use los valores de ejemplo.
1.
Creación de una red virtual clásica
Si no tiene una red virtual clásica y lleva a cabo estos pasos como ejercicio, puede crear una red virtual según
este artículo y los valores de configuración de ejemplo indicados anteriormente.
Si ya tiene una red virtual con una puerta de enlace VPN, compruebe que la puerta de enlace sea dinámica. Si es
estática, primero debe eliminar la puerta de enlace de VPN antes de pasar a configurar el sitio local.
1. Abra Azure Portal e inicie sesión con su cuenta de Azure.
2. Haga clic en + Crear un recurso para abrir la página "Nuevo".
3. En el campo "Buscar en el Marketplace", escriba "Virtual Network". Si en su lugar, selecciona Redes -> Virtual
Network, no obtendrá la opción para crear una red virtual clásica.
4. En la lista de resultados, busque "Virtual Network" y haga clic en esa opción para abrir la página Virtual
Network.
5. En la página de red virtual, seleccione "Clásica" para crear una red virtual clásica. Si aquí usa el valor
predeterminado, generará en su lugar una red virtual de Resource Manager.
2.
Configuración del sitio local
1. Vaya a Todos los recursos y ubique ClassicVNet en la lista.
2. Haga clic en Puer ta de enlace en la sección Configuración del menú y, a continuación, haga clic en el
banner para crear una puerta de enlace.

3. En la página Nueva conexión de VPN , en la opción Tipo de conexión , seleccione De sitio a sitio .
4. En Sitio local , haga clic en Configurar los valores obligatorios . Con esto se abre la página Sitio local .
5. En la página Sitio Local , cree un nombre para hacer referencia a la red virtual de Resource Manager. Por
ejemplo, "RMVNetLocal".
6. Si la puerta de enlace VPN para la red virtual de Resource Manager ya tiene una dirección IP pública, use el
valor para el campo Dirección IP de la VPN Gateway . Si lleva a cabo estos pasos como ejercicio o todavía
no tiene una puerta de enlace de red virtual para la red virtual de Resource Manager, puede inventar una
dirección IP de marcador de posición. Asegúrese de que la dirección IP de marcador de posición utiliza un
formato válido. Más adelante, reemplaza la dirección IP de marcador de posición por la dirección IP pública
de la puerta de enlace de red virtual de Resource Manager.
7. Para Client Address Space (Espacio de direcciones de clientes), use los valores de los espacios de
direcciones IP de red virtual para la red virtual de Resource Manager. Este valor se usa para especificar los
espacios de direcciones a fin de enrutar a la red virtual de Resource Manager. En el ejemplo usamos
192.168.0.0/16, el intervalo de direcciones de RMVNet.
8. Haga clic en Aceptar para guardar los valores y volver a la página Nueva conexión de VPN .
3. Creación de la puerta de enlace de red virtual
1. En la página Nueva conexión VPN , active la casilla Crear puer ta de enlace inmediatamente .
2. Haga clic en Configuración de puer ta de enlace opcional para abrir la página Configuración de
puer ta de enlace .
3. Haga clic en Subred: configurar los valores obligatorios para abrir la página Agregar subred . El
nombre ya está configurado con valor requerido: GatewaySubnet .
4. Inter valo de direcciones hace referencia al intervalo para la subred de puerta de enlace. Si bien puede
crear una subred de puerta de enlace con un intervalo de direcciones de /29 (3 direcciones), se
recomienda crear una subred de puerta de enlace que incluya más direcciones IP. Esto permitirá
configuraciones futuras que puedan requerir más direcciones IP disponibles. Si es posible, utilice /27 o
/28. Si usa estos pasos como ejercicio, puede hacer referencia a los valores de ejemplo. En este ejemplo
se usa "10.0.0.32/28". Haga clic en Aceptar para crear la subred de puerta de enlace.
5. En la página Configuración de puer ta de enlace , la opción Tamaño hace referencia a la SKU de la
puerta de enlace. Seleccione la SKU de puerta de enlace para la puerta de enlace VPN.
6. Compruebe que el Tipo de enrutamiento sea Dinámico y haga clic en Aceptar para volver a la página
Nueva conexión de VPN .
7. En la página Nueva conexión de VPN , haga clic en Aceptar para empezar a crear la puerta de enlace
de VPN. Una puerta de enlace VPN puede tardar hasta 45 minutos en completarse.
4. Copia de la dirección IP pública de la puerta de enlace de la red virtual
Una vez que se haya creado la puerta de enlace de la red virtual, puede ver la dirección IP de la puerta de enlace.
1. Desplácese a la red virtual clásica y haga clic en Información general .
2. Haga clic en Conexiones de VPN para abrir la página de conexiones. En la página de conexiones de VPN,
puede ver la dirección IP pública. Se trata de la dirección IP pública asignada a la puerta de enlace de red
virtual. Anote la dirección IP. Se usa en pasos posteriores al trabajar con las opciones de configuración de
puerta de enlace de red local de Resource Manager.
3. Puede ver el estado de las conexiones de puerta de enlace. Observe que el sitio de red local que creó aparece
como "Conectando". El estado cambiará una vez creadas las conexiones. Puede cerrar esta página cuando
termine de ver el estado.
Sección 2: Configuración de redes virtuales de Resource Manager

En esta sección se crea la puerta de enlace de red virtual y la puerta de enlace de red local para la red de
Resource Manager. Las capturas de pantalla se proporcionan a modo de ejemplo. Asegúrese de reemplazar los
valores por los suyos o use los valores de ejemplo.
1. Creación de una red virtual
Valores de ejemplo:
Nombre de red virtual = RMVNet
Intervalo de direcciones = 192.168.1.0/24
Si no tiene una red virtual de Resource Manager y va a ejecutar estos pasos como ejercicio, cree una red virtual
con los pasos que se indican en Creación de una red virtual y use los valores de ejemplo.
2. Creación de una puerta de enlace de red virtual
Valores de ejemplo:
Tipo de puerta de enlace = VPN
Tipo de VPN = basada en enrutamiento
SKU = VpnGw1
Red virtual = RMVNet
Configuración de primera dirección IP = rmgwpip
selecciónela.
Detalles del proyecto
en esta página.
Name : Asigne un nombre a la puerta de enlace. Asignar nombre a la puerta de enlace no es lo
mismo que asignar nombre a una subred de puerta de enlace. Este es el nombre del objeto de puerta
de enlace que va a crear.
de enlace.
enlace.
pública.
5. Una vez superada la validación, seleccione Crear para implementar VPN Gateway. Una puerta de enlace
puede tardar hasta 45 minutos en crearse e implementarse completamente. Puede ver el estado de
implementación en la página Información general de la puerta de enlace.
Una vez creada la puerta de enlace, puede ver la dirección IP que se le ha asignado consultando la red virtual en
el portal. La puerta de enlace aparece como un dispositivo conectado.
IMPORTANT
3. Creación de una puerta de enlace de red local

Valores de ejemplo: Puerta de enlace de red local = ClassicVNetLocal
DIREC C IÓ N IP
ESPA C IO DE SE C O N EC TA A UN P ÚB L IC A DE P UERTA
VIRT UA L N ET W O RK DIREC C IO N ES REGIO N SIT IO DE RED LO C A L DE EN L A C E
ClassicVNet (10.0.0.0/24) Oeste de EE. UU. RMVNetLocal La dirección IP

(192.168.0.0/16) pública que se asigna
a la puerta de enlace
ClassicVNet
RMVNet (192.168.0.0/16) Este de EE. UU. ClassicVNetLocal La dirección IP

(10.0.0.0/24) pública que se asigna
a la puerta de enlace
RMVNet.
La puerta de enlace de red local especifica el intervalo de direcciones y la dirección IP pública asociados a la red
virtual clásica y su puerta de enlace de red virtual. Si lleva a cabo estos pasos como un ejercicio, consulte los
valores de ejemplo.
red local . Busque la puer ta de enlace de red local en Marketplace en los resultados de la búsqueda
y selecciónela. Se abre la página para crear la puer ta de enlace de red local .
red local.
podrá conectarse.
obligatorio.
Sección 3: modificación de la configuración del sitio local de la red

virtual clásica
En esta sección se reemplaza la dirección IP de marcador de posición que usó al especificar la configuración del
sitio local con la dirección IP de puerta de enlace VPN de Resource Manager. Esta sección utiliza los cmdlets de
PowerShell (SM) clásicos.
1. En Azure Portal, vaya a la red virtual clásica.
2. En la página de la red virtual, haga clic en Información general .
3. En la sección Conexiones VPN , haga clic en el nombre del sitio local en el gráfico.
4. En la página Conexiones de VPN de sitio a sitio , haga clic en el nombre del sitio.
5. En la página de conexión del sitio local, haga clic en el nombre del sitio local para abrir la página Sitio
local .
6. En la página Sitio local , reemplace la dirección IP de la puer ta de enlace de VPN por la dirección IP
de la puerta de enlace de Resource Manager.
7. Haga clic en Aceptar para actualizar la dirección IP.
Sección 4: Creación de conexión de red virtual de Resource Manager

a red virtual clásica
En estos pasos se configura la conexión desde la red virtual de Resource Manager a la red virtual clásica con
Azure Portal.
1. En Todos los recursos , ubique la puerta de enlace de red local. En el ejemplo, la puerta de enlace de red
local es ClassicVNetLocal .
2. Haga clic en Configuración y compruebe que el valor de dirección IP es la puerta de enlace VPN para la red
virtual clásica. Actualice si es necesario y, luego, haga clic en Guardar . Cierre la página.
3. En Todos los recursos , haga clic en la puerta de enlace de red local.
4. Haga clic en Conexiones para abrir la página Conexiones.
5. En la página Conexiones , haga clic en + para agregar una conexión.
6. En la página Agregar conexión , asigne un nombre a la conexión. Por ejemplo, "RMtoClassic".
7. En esta página ya está seleccionada la opción De sitio a sitio .
8. Seleccione la puerta de enlace de red virtual que desea asociar con este sitio.
9. Cree una clave compar tida . Esta clave se usa también en la conexión que crea desde la red virtual clásica a
la red virtual de Resource Manager. Puede generar la clave o inventar una. En el ejemplo usamos "abc123",
pero puede (y debe) usar un valor más complejo.
10. Haga clic en Aceptar para crear la conexión.
Sección 5: Creación de conexión de red virtual clásica a red virtual de

Resource Manager
En estos pasos se configura la conexión desde la red virtual clásica a la red virtual de Resource Manager. Estos
pasos requieren PowerShell. Esta conexión no se puede crear en el portal. Asegúrese de que ha descargado e
instalado los cmdlets de PowerShell tanto del modelo clásico (SM) como del modelo de Resource Manager
(RM).
1. Conexión a la cuenta de Azure
Abra la consola de PowerShell con derechos elevados e inicie sesión en la cuenta de Azure. Después de iniciar la
sesión, se descarga la configuración de la cuenta para que esté disponible para Azure PowerShell. El siguiente
cmdlet pide las credenciales de inicio de sesión de la cuenta de Azure para el modelo de implementación de
Resource Manager:
Connect-AzAccount
Obtenga una lista de las suscripciones de Azure.
Get-AzSubscription
A continuación, inicie sesión para usar los cmdlets de PowerShell clásicos (administración de servicios). Para
agregar su cuenta de Azure del modelo de implementación clásica, use el siguiente comando:
Add-AzureAccount
Obtenga una lista de las suscripciones. Este paso puede ser necesario al agregar los cmdlets de Service
Management, dependiendo de su módulo de Azure.
Get-AzureSubscription
Select-AzureSubscription -SubscriptionName "Name of subscription"
2. Visualización de los valores de archivo de configuración de red

Cuando crea una red virtual en Azure Portal, el nombre completo que Azure usa no aparece en Azure Portal. Por
ejemplo, una red virtual que parece llamarse "ClassicVNet" en Azure Portal puede que tenga un nombre mucho
más largo en el archivo de configuración de la red. El nombre podría ser similar al siguiente: "Group ClassicRG
ClassicVNet". En estos pasos se descarga el archivo de configuración de red y se ven los valores.
Cree un directorio en el equipo y, a continuación, exporte el archivo de configuración de red al directorio. En este
ejemplo, se exporta el archivo de configuración de red a C:\AzureNet.
Get-AzureVNetConfig -ExportToFile C:\AzureNet\NetworkConfig.xml
Abra el archivo con un editor de texto y consulte el nombre de la red virtual clásica. Use los nombres que
aparecen en el archivo de configuración de red cuando ejecute los cmdlets de PowerShell.
Los nombres de las redes virtuales aparecen como Vir tualNetworkSite name =
Los nombres de los sitios aparecen como LocalNetworkSite name=
3. Creación de la conexión
Establezca la clave compartida y cree la conexión desde la red virtual clásica a la red virtual de Resource
Manager. No se puede establecer la clave compartida mediante el portal. Asegúrese de ejecutar estos pasos
mientras la sesión esté iniciada con la versión clásica de los cmdlets de PowerShell. Para ello, use Add-
AzureAccount . De lo contrario, no podrá establecer '-AzureVNetGatewayKey'.
En este ejemplo, -VNetName es el nombre de la red virtual clásica tal como se encuentra en el archivo de
configuración de red.
-LocalNetworkSiteName es el nombre que especificó para el sitio local, según se encontró en el archivo
de configuración de red.
-SharedKey es un valor que se puede generar y especificar. En este ejemplo, hemos utilizado abc123 pero
puede generar algo más complejo. Lo importante es que el valor que especifique aquí debe ser el mismo que
el que se especificó al crear la conexión entre la red virtual de Resource Manager y la red virtual clásica.
Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" `

-LocalNetworkSiteName "172B9E16_RMVNetLocal" -SharedKey abc123
Sección 6: Comprobación de las conexiones

Puede comprobar las conexiones mediante Azure Portal o PowerShell. Al comprobar, es posible que necesite
esperar un minuto o dos mientras se crea la conexión. Cuando una conexión se realiza correctamente, el estado
de conectividad cambia de "Conectando" a "Conectado".
Comprobación de la conexión de la red virtual clásica a la red virtual de Resource Manager
sitio a sitio .
Comprobación de la conexión de la red virtual de Resource Manager a la red virtual clásica
conexión.

virtuales.
(AAD)?
inquilinos de AAD.
No.
Azure?
estos escenarios.
PolicyBased?
dinámico).
Conexión de redes virtuales a partir de diferentes
modelos de implementación con PowerShell
Este artículo muestra cómo conectar redes virtuales clásicas a redes virtuales de Resource Manager para
permitir que los recursos que se encuentran en modelos de implementación independientes se comuniquen
entre sí. En los pasos de este artículo se usa fundamentalmente PowerShell, pero también se puede crear esta
configuración con Azure Portal si se selecciona el artículo en esta lista.
La conexión de una red virtual clásica a una red virtual de Resource Manager es similar a la conexión de una red
virtual a una ubicación de sitio local. Ambos tipos de conectividad usan una puerta de enlace de VPN para
proporcionar un túnel seguro con IPsec/IKE. Puede crear una conexión entre redes virtuales que estén en
diferentes suscripciones y en diferentes regiones. También puede conectar redes virtuales que tengan ya
conexiones a redes locales, siempre que la puerta de enlace con la que se hayan configurado sea dinámica o
basada en ruta. Para más información acerca de las conexiones de red virtual a red virtual, consulte P+F sobre
conexiones de red virtual a red virtual al final de este artículo.
Si aún no tiene una puerta de enlace de red virtual y no desea crear una, considere la posibilidad de conectar
sus redes virtuales mediante Emparejamiento de VNET. El emparejamiento de VNET no usa VPN Gateway. Para
más información, consulte Emparejamiento de VNET.
Antes de empezar
Los siguientes pasos le guiarán a través de los valores necesarios para configurar una puerta de enlace
dinámica o basada en ruta para cada red virtual y crear una conexión VPN entre las puertas de enlace. Esta
configuración no admite puertas de enlace estáticas o basadas en directivas.
Requisitos previos
Se han creado ambas redes virtuales. Si tiene que crear una red virtual del administrador de recursos,
consulte Creación de un grupo de recursos y una red virtual. Para crear una red virtual clásica, consulte
Create a classic VNet (Creación de una red virtual clásica).
Los intervalos de direcciones de las redes virtuales no se superponen entre sí ni con alguno de los intervalos
de otras conexiones con las que puedan estar conectadas las puertas de enlace.
Tiene instalados los últimos cmdlets de PowerShell. Para obtener más información, vea Instalación y
configuración de Azure PowerShell . Asegúrese de instalar los cmdlets tanto de Service Management (SM)
como de Resource Manager (RM).
Puede usar estos valores para crear un entorno de prueba o hacer referencia a ellos para comprender mejor los
ejemplos de este artículo.
Configuración de redes vir tuales clásicas
Nombre de la red virtual = RedVClásica
Ubicación = Oeste de EE. UU.
Espacios de direcciones de red virtual = 10.0.0.0/24
Subred-1 = 10.0.0.0/27
Subred de la puerta de enlace= 10.0.0.32/29
Nombre de la red local = RedLocalRMV
Tipo de puerta de enlace = EnrutamientoDinámico
Configuración de redes vir tuales de Resource Manager
Nombre de red virtual = RedRMV
Espacios de direcciones IP de red virtual = 192.168.0.0/16
Subred-1 = 192.168.1.0/24
Nombre IP público de puerta de enlace = pepip
Puerta de enlace de red local = LocalRedVClásica
Configuración de direccionamiento IP de puerta de enlace = configpeip
Sección 1: configuración de la red virtual clásica

1. Descarga del archivo de configuración de red
1. Inicie sesión en su cuenta de Azure en la consola de PowerShell con derechos elevados. El siguiente
cmdlet pide las credenciales de inicio de sesión de la cuenta de Azure. Después de iniciar la sesión, se
descarga la configuración de la cuenta a fin de ponerla a disposición para Azure PowerShell. Los cmdlets
clásicos de Azure PowerShell para Service Management (SM) clásicos se usan en esta sección.
Add-AzureAccount
Obtenga la suscripción a Azure.
Si tiene varias suscripciones, seleccione la que quiera usar.
Select-AzureSubscription -SubscriptionName "Name of subscription"
2. Exporte el archivo de configuración de red de Azure mediante la ejecución del comando siguiente. Puede
cambiar la ubicación del archivo que se va a exportar a una ubicación diferente si es necesario.
3. Abra el archivo .xml que ha descargado para editarlo. Para obtener un ejemplo del archivo de
configuración de red, consulte Esquema de configuración de red virtual.
2. Comprobación de la subred de puerta de enlace
En el elemento Vir tualNetworkSites , agregue una subred de puerta de enlace a la red virtual si no hay ya una
creada. Al trabajar con el archivo de configuración de red, la puerta de enlace DEBE tener el nombre
"GatewaySubnet" o Azure no podrá reconocerla y utilizarla como subred de puerta de enlace.
IMPORTANT
Ejemplo :
<VirtualNetworkSites>
<VirtualNetworkSite name="ClassicVNet" Location="West US">
<AddressSpace>
<AddressPrefix>10.0.0.0/24</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="Subnet-1">
</Subnet>
<Subnet name="GatewaySubnet">
</Subnet>
</Subnets>
</VirtualNetworkSite>
</VirtualNetworkSites>
3. Incorporación del sitio de red local

El sitio de red local que agregue representa la red virtual de RM a la que desea conectarse. Agregue un
elemento LocalNetworkSites al archivo si aún no existe. En este punto de la configuración, el valor de
VPNGatewayAddress puede ser cualquier dirección IP pública válida ya que todavía no se ha creado la puerta de
enlace para la red virtual de Resource Manager. Una vez creada la puerta de enlace, esta dirección IP de
marcador de posición se reemplaza por la dirección IP pública correcta que se ha asignado a la puerta de enlace
de RM.
<LocalNetworkSites>
<LocalNetworkSite name="RMVNetLocal">
<AddressSpace>
</AddressSpace>
<VPNGatewayAddress>13.68.210.16</VPNGatewayAddress>
</LocalNetworkSite>
</LocalNetworkSites>
4. Asociación de la red virtual con el sitio de red local

En esta sección, se especifica el sitio de red local con la que se desea conectar la red virtual. En este caso, es la
red virtual de Resource Manager a la que se ha hecho referencia anteriormente. Asegúrese de que los nombres
coincidan. En este paso no se crea una puerta de enlace. Se especifica la red local con la que se conectará la
puerta de enlace.
<Gateway>
<ConnectionsToLocalNetwork>
<LocalNetworkSiteRef name="RMVNetLocal">
<Connection type="IPsec" />
</LocalNetworkSiteRef>
</ConnectionsToLocalNetwork>
</Gateway>
5. Guardado del archivo y carga

Ejecute el comando siguiente para guardar el archivo e importarlo a Azure. Asegúrese de cambiar la ruta de
acceso según sea necesario para su entorno.
Set-AzureVNetConfig -ConfigurationPath C:\AzureNet\NetworkConfig.xml
Verá un resultado similar que muestra que la importación se realizó correctamente.

OperationDescription OperationId OperationStatus
-------------------- ----------- ---------------
Set-AzureVNetConfig e0ee6e66-9167-cfa7-a746-7casb9 Succeeded
6. Creación de la puerta de enlace

Antes de ejecutar este ejemplo, consulte el archivo de configuración de red que ha descargado para consultar
los nombres exactos que Azure espera ver. El archivo de configuración de red contiene los valores para las redes
virtuales clásicas. A veces se cambian los nombres de los sitios de las redes virtuales clásicas en el archivo de
configuración de red al crear la configuración de la red virtual clásica en Azure Portal debido a las diferencias en
los modelos de implementación. Por ejemplo, si ha utilizado Azure Portal para crear una red virtual clásica
llamada 'Classic VNet' y la ha creado en un grupo de recursos llamado 'ClassicRG', el nombre que se encuentra
en el archivo de configuración de red se convierte en 'Group ClassicRG Classic VNet'. Al especificar el nombre
de una red virtual que contiene espacios, utilice comillas alrededor del valor.
Para crear una puerta de enlace de enrutamiento dinámico, utilice el siguiente ejemplo:
New-AzureVNetGateway -VNetName ClassicVNet -GatewayType DynamicRouting
Puede comprobar el estado de la puerta de enlace usando el cmdlet Get-AzureVNetGateway .
Sección 2: Configuración de la puerta de enlace de la red virtual de

RM
Para los requisitos previos, se supone que ya ha creado una red virtual de RM. En este paso, creará una puerta
de enlace de VPN para la red virtual de RM. No empiece con los pasos hasta que haya recuperado la dirección IP
pública de la puerta de enlace de la red virtual clásica.
1. Inicie sesión en su cuenta de Azure en la consola de PowerShell. El siguiente cmdlet pide las credenciales
de inicio de sesión de la cuenta de Azure. Después de iniciar la sesión, se descarga la configuración de la
cuenta para que esté disponible para Azure PowerShell. Asimismo, tiene la opción de usar la característica
"Pruébelo" para iniciar Azure Cloud Shell en el explorador.
Si usa Azure Cloud Shell, omita el siguiente cmdlet:
Connect-AzAccount
Para comprobar que está usando la suscripción correcta, ejecute el siguiente cmdlet:
Get-AzSubscription
2. Cree una puerta de enlace de red local. En una red virtual, la puerta de enlace de red local suele hacer
referencia a la ubicación local. En este caso, la puerta de enlace de red local hace referencia a la red
virtual clásica. Asígnele un nombre que sirva de referencia a Azure y especifique también el prefijo de
espacio de direcciones. Azure usa el prefijo de dirección IP que especifique para identificar qué tráfico
enviar a la ubicación local. Si necesita ajustar la información aquí posteriormente, antes de crear la puerta
de enlace, puede modificar los valores y volver a ejecutar el ejemplo.
-Name es el nombre de referencia que quiere asignar a la puerta de enlace de la red local.
-AddressPrefix es el espacio de direcciones para la red virtual clásica.
-GatewayIpAddress es la dirección IP pública de la puerta de enlace de la red virtual clásica. Asegúrese
de cambiar el texto de ejemplo "n.n.n.n" para que refleje la dirección IP correcta.
New-AzLocalNetworkGateway -Name ClassicVNetLocal `

-Location "West US" -AddressPrefix "10.0.0.0/24" `
-GatewayIpAddress "n.n.n.n" -ResourceGroupName RG1
3. Solicite que se asigne una dirección IP pública a la puerta de enlace de la red virtual para Azure Resource
Manager. No puede especificar la dirección IP que desea usar. La dirección IP se asigna dinámicamente a
la puerta de enlace de red virtual. Sin embargo, esto no significa que la dirección IP vaya a cambiar. La
única vez que cambia la dirección IP de la puerta de enlace virtual es cuando se elimina y se vuelve a
crear la puerta de enlace. No cambiará al modificar el tamaño, restablecer o realizar otro tipo de
mantenimiento interno o actualizaciones de la puerta de enlace.
En este paso, también se establece una variable que se utilizará en un paso posterior.
$ipaddress = New-AzPublicIpAddress -Name gwpip `

-ResourceGroupName RG1 -Location 'EastUS' `
4. Compruebe que la red virtual tenga una subred de puerta de enlace. Si no existe ninguna subred de
puerta de enlace, agregue una. Asegúrese de que la subred de puerta de enlace tenga el nombre
GatewaySubnet.
5. Recupere la subred usada para la puerta de enlace mediante la ejecución del comando siguiente. En este
paso, también se establece una variable que se utilizará en el paso siguiente.
-Name es el nombre de la red virtual de Resource Manager.
-ResourceGroupName es el grupo de recursos con el que está asociado la red virtual. La subred de
puerta de enlace debe existir para esta red virtual y su nombre tiene que ser GatewaySubnet para que
funcione correctamente.
$subnet = Get-AzVirtualNetworkSubnetConfig -Name GatewaySubnet `

-VirtualNetwork (Get-AzVirtualNetwork -Name RMVNet -ResourceGroupName RG1)
6. Cree la configuración de direccionamiento IP de la puerta de enlace. La configuración de puerta de enlace

define la subred y la dirección IP pública. Use el ejemplo siguiente para crear la configuración de la
puerta de enlace.
En este paso, debe pasarse la propiedad de Id de la subred y los objetos de la dirección IP
respectivamente a los parámetros -SubnetId y -PublicIpAddressId . No puede usar una cadena
sencilla. Estas variables se establecen en el paso para solicitar una dirección IP pública y el paso para
recuperar la subred.
$gwipconfig = New-AzVirtualNetworkGatewayIpConfig `
-Name gwipconfig -SubnetId $subnet.id `
-PublicIpAddressId $ipaddress.id
7. Cree la puerta de enlace de la red virtual de Resource Manager mediante la ejecución del comando
siguiente. -VpnType debe ser RouteBased. La puerta de enlace puede tardar hasta 45 o más minutos en
crearse.
New-AzVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1 `
-Location "EastUS" -GatewaySKU Standard -GatewayType Vpn `
-IpConfigurations $gwipconfig `
-EnableBgp $false -VpnType RouteBased
8. Copie la dirección IP pública una vez creada la instancia de VPN Gateway. Utilícela cuando configure la
red local para la red virtual implementada con el modelo clásico. Puede utilizar el siguiente cmdlet para
recuperar la dirección IP pública. La dirección IP pública aparece devuelta como IpAddress.
Get-AzPublicIpAddress -Name gwpip -ResourceGroupName RG1
Sección 3: modificación de la configuración del sitio local de la red

virtual clásica
En esta sección trabajará con la red virtual clásica. Reemplace la dirección IP de marcador de posición que ha
utilizado al especificar la configuración del sitio local que se usará para conectarse a la puerta de enlace de la
red virtual de Resource Manager. Puesto que está trabajando con la red virtual clásica, use la instancia de
PowerShell que tiene instalada de forma local en el equipo y no la opción Pruébelo de Azure Cloud Shell.
1. Exporte un archivo de configuración de red.
2. Con un editor de texto, modifique el valor de VPNGatewayAddress. Reemplace la dirección IP de

marcador de posición por la dirección IP pública de la puerta de enlace de la red virtual de Resource
Manager.
3. Importe el archivo de configuración de red modificado a Azure.
Sección 4: Creación de una conexión entre las puertas de enlace

La creación de una conexión entre las puertas de enlace requiere PowerShell. Debe agregar su cuenta de Azure
para usar la versión clásica de los cmdlets de PowerShell. Para ello, use Add-AzureAccount .
1. En la consola de PowerShell, establezca la clave compartida. Antes de ejecutar los cmdlets, consulte el
archivo de configuración de red que ha descargado para consultar los nombres exactos que Azure espera
ver. Al especificar el nombre de una red virtual que contiene espacios, utilice comillas simples alrededor
del valor.
En el ejemplo siguiente, -VNetName es el nombre de la red virtual clásica y -LocalNetworkSiteName

es el nombre especificado para el sitio de la red local. -SharedKey es un valor que se puede generar y
especificar. En este ejemplo, hemos utilizado 'abc123' pero puede generar y usar algo más complejo. Lo
importante es que el valor que especifique aquí debe ser el mismo que el que va a especificar en el paso
siguiente, cuando cree la conexión. El valor devuelto para este ejemplo muestra Estado: Correcto .
Set-AzureVNetGatewayKey -VNetName ClassicVNet `
-LocalNetworkSiteName RMVNetLocal -SharedKey abc123
2. Ejecute los comandos siguientes para crear la conexión de VPN:

Establezca las variables.
$vnet01gateway = Get-AzLocalNetworkGateway -Name ClassicVNetLocal -ResourceGroupName RG1

$vnet02gateway = Get-AzVirtualNetworkGateway -Name RMGateway -ResourceGroupName RG1
Cree la conexión. Tenga en cuenta que -ConnectionType es IPsec y no Vnet2Vnet.
New-AzVirtualNetworkGatewayConnection -Name RM-Classic -ResourceGroupName RG1 `

-Location "East US" -VirtualNetworkGateway1 `
$vnet02gateway -LocalNetworkGateway2 `
$vnet01gateway -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Sección 5: Comprobación de las conexiones

Comprobación de la conexión de la red virtual clásica a la red virtual de Resource Manager
PowerShell
Puede comprobar que la conexión se realizó correctamente mediante el cmdlet "Get-AzureVNetConnection".
1. Puede usar el siguiente ejemplo de cmdlet, configurando los valores para que coincidan con los tuyos. Si
el nombre de la red virtual contiene espacios, debe estar entre comillas.
Get-AzureVNetConnection "Group ClassicRG TestVNet1"
2. Cuando el cmdlet haya finalizado, consulte los valores. En el ejemplo siguiente, en ConnectivityState
aparece "Connected" y se pueden ver los bytes de entrada y salida.
LastConnectionEstablished : 10/19/22020 12:40:54 AM
LastEventID : 24401
LastEventMessage : The connectivity state for the local network site 'F7F7BFC7_SiteVNet4'
changed from Connecting to
Connected.
LastEventTimeStamp : 10/19/2020 12:40:54 AM
LocalNetworkSiteName : F7F7BFC7_SiteVNet4
Azure Portal
sitio a sitio .

Comprobación de la conexión de la red virtual de Resource Manager a la red virtual clásica
PowerShell
Azure Portal
conexión.

virtuales.
(AAD)?
inquilinos de AAD.
No.
Azure?
estos escenarios.
PolicyBased?
dinámico).
Configure una conexión VPN de punto a sitio a una
red virtual mediante la autenticación nativa de los
certificados de Azure: Portal de Azure
Este artículo le ayudará con la conexión segura de clientes que ejecutan Windows, Linux o macOS a una red
virtual de Azure. Las conexiones VPN de punto a sitio son útiles cuando desea conectarse a la red virtual desde
una ubicación remota, como desde casa o desde una conferencia. También puede usar P2S en lugar de una VPN
de sitio a sitio cuando son pocos los clientes que necesitan conectarse a una red virtual. Las conexiones de
punto a sitio no requieren un dispositivo VPN ni una dirección IP de acceso público. P2S crea la conexión VPN
sobre SSTP (Protocolo de túnel de sockets seguros) o IKEv2. Para más información sobre las conexiones VPN de
punto a sitio, consulte Acerca de las conexiones VPN de punto a sitio.
Para más información sobre las conexiones VPN de punto a sitio, consulte Acerca de las conexiones VPN de
punto a sitio. Para crear esta configuración mediante Azure PowerShell, consulte Configuración de una conexión
VPN de punto a sitio con Azure PowerShell.
Las conexiones con autenticación mediante certificado de Azure nativas de punto a sitio usan los siguientes
elementos, que se configuran en este ejercicio:
Una puerta de enlace de VPN RouteBased.
La clave pública (archivo .cer) de un certificado raíz, que se carga en Azure. Una vez cargado el certificado, se
considera un certificado de confianza y se usa para la autenticación.
Un certificado de cliente que se genera a partir del certificado raíz. El certificado de cliente se instalará en
todos los equipos cliente que se conecten a la red virtual. Este certificado se usa para la autenticación de
cliente.
Configuración de cliente de VPN. El cliente VPN se configura mediante los archivos de configuración de
cliente de VPN. Estos archivos contienen la información necesaria para que el cliente se conecte a la red
virtual. Los archivos configuran el cliente VPN existente que es nativo en el sistema operativo. Cada cliente
que se conecta debe configurarse con los valores de los archivos de configuración.
Requisitos previos
Compruebe que tiene una suscripción a Azure. Si todavía no la tiene, puede activar sus ventajas como suscriptor
de MSDN o registrarse para obtener una cuenta gratuita.
Valores del ejemplo
Nombre de la red vir tual: VNet1
En este ejemplo, se utiliza solo un espacio de direcciones. Puede tener más de un espacio de direcciones para
la red virtual.
Inter valo de direcciones de subred: 10.1.0.0/24
Subscription (Suscripción): si tiene más de una suscripción, compruebe que usa la correcta.
Nombre de la puer ta de enlace de red vir tual: VNet1GW
Nombre de dirección IP pública: VNet1GWpip
Tipo de conexión : De punto a sitio
Grupo de direcciones de clientes: 172.16.201.0/24
Los clientes de VPN que se conectan a la red virtual mediante esta conexión de punto a sitio reciben una
dirección IP del grupo de clientes.
Virtual Network
En esta sección, creará una red virtual.
NOTE

valores:
Resource Manager.
necesite.

Firewall : Disabled
Puerta de enlace de red virtual

NOTE
La SKU de puerta de enlace de nivel Básico no admite la autenticación de IKEv2 o RADIUS. Si planea que clientes Mac se
conecten a la red virtual, no use la SKU de nivel Básico.
selecciónela.
en esta página.
de enlace.
enlace.
pública.
Generación de certificados
Azure usa certificados para autenticar a los clientes para conectarse a una red virtual a través de una conexión
VPN de punto a sitio. Una vez que obtenga el certificado raíz, cargue la información de clave pública en Azure.
En ese momento, Azure considera que el certificado raíz es "de confianza" para conectarse de P2S a la red
virtual. También genere certificados de cliente desde el certificado raíz de confianza y, a continuación, vuelva a
instalarlos en cada equipo cliente. El certificado de cliente se utiliza para autenticar al cliente cuando se inicia
una conexión con la red virtual.
Generación de un certificado raíz
Obtenga el archivo .cer del certificado raíz. Puede usar un certificado raíz generado mediante una solución
empresarial (opción recomendada) o generar un certificado autofirmado. Después de crear el certificado raíz,
exporte los datos (no la clave privada) del certificado público como un archivo .cer con codificación Base64
X.509. Este archivo se carga más adelante en Azure.
Cer tificado de empresa: Si usa una solución empresarial, puede utilizar la cadena de certificados
existente. Obtenga el archivo .cer para el certificado raíz que desee usar.
Cer tificado raíz autofirmado : Si no usa una solución de certificado de empresa, cree un certificado
raíz autofirmado. En caso contrario, los certificados que cree no serán compatibles con las conexiones de
P2S y los clientes recibirán un error de conexión al intentar conectarse. Puede usar Azure PowerShell,
MakeCert o bien OpenSSL. Los pasos descritos en los artículos siguientes describen cómo generar un
certificado raíz autofirmado compatible:
Instrucciones para Windows 10 y PowerShell: estas instrucciones requieren Windows 10 y PowerShell
para generar certificados. Los certificados de cliente que se generan desde el certificado raíz pueden
instalarse en cualquier cliente P2S compatible.
Instrucciones para MakeCert: use MakeCert para generar certificados si no tiene acceso a un equipo
con Windows 10. Aunque MakeCert está en desuso, todavía puede usarlo para generar certificados.
Los certificados de cliente que se generan desde el certificado raíz pueden instalarse en cualquier
cliente P2S compatible.
Instrucciones para Linux.
Generación de certificados de cliente
Cada equipo cliente que se conecta a una red virtual con una conexión de punto a sitio debe tener instalado un
certificado de cliente. Se genera desde el certificado raíz y se instala en cada equipo cliente. Si no instala ningún
certificado de cliente válido, la autenticación no podrá realizarse cuando el cliente trate de conectarse a la red
virtual.
Puede generar un certificado único para cada cliente o puede usar el mismo para varios clientes. La ventaja de
generar certificados de cliente únicos es la capacidad de revocar un solo certificado. De lo contrario, si varios
clientes usan el mismo certificado de cliente para autenticarse y este se revoca, deberá generar e instalar nuevos
certificados para cada cliente que use dicho certificado.
Para generar certificados de cliente, use los métodos siguientes:
Cer tificado de empresa:
Si usa una solución de certificación de empresa, genere un certificado de cliente con el formato de
valor de nombre común [email protected]. Use este formato en lugar de domain
name\username.
Asegúrese de que el certificado de cliente se base en la plantilla de certificado de usuario que
tenga Autenticación de cliente como primer elemento de la lista de usuarios. Para comprobar el
certificado, haga doble clic en él y vea Uso mejorado de clave en la pestaña Detalles .
Cer tificado raíz autofirmado : siga los pasos de alguno de los siguientes artículos de certificados de
P2S para que los certificados de cliente que cree sean compatibles con las conexiones de P2S.
Si genera un certificado de cliente desde un certificado raíz autofirmado, este se instala automáticamente
en el equipo que utilizó para generarlo. Si desea instalar un certificado de cliente en otro equipo cliente,
expórtelo como un archivo .pfx junto con toda la cadena de certificados. De esta forma, creará un archivo
.pfx que contiene la información del certificado raíz necesaria para que el cliente se autentique.
Los pasos de estos artículos generan un certificado de cliente compatible que puede, posteriormente,
exportar y distribuir.
Instrucciones para Windows 10 y PowerShell: estas instrucciones requieren Windows 10 y
PowerShell para generar certificados. Los certificados generados pueden instalarse en cualquier
Instrucciones para MakeCert: use MakeCert si no tiene acceso a un equipo Windows 10 para
generar certificados. Aunque MakeCert está en desuso, todavía puede usarlo para generar
certificados. Puede instalar los certificados generados en cualquier cliente P2S compatible.
Grupo de direcciones de clientes

El grupo de direcciones de cliente es un intervalo de direcciones IP privadas que usted especifica. Los clientes
que se conectan de forma dinámica a través de una VPN de punto a sitio reciben una dirección IP de este
intervalo. Use un intervalo de direcciones IP privadas que no se superponga a la ubicación local desde la que se
va a conectar ni a la red virtual a la que desea conectarse. Si configura varios protocolos y SSTP es uno de ellos,
el grupo de direcciones configurado se divide equitativamente entre los protocolos configurados.
1. Una vez creada la puerta de enlace de red virtual, navegue hasta la sección Valores de la página de la
puerta de enlace de red virtual. En Configuración , seleccione Configuración de punto a sitio .
Seleccione Configure now (Configurar ahora) para abrir la página de configuración.
2. En la página Configuración de punto a sitio , en el cuadro Grupo de direcciones , agregue el
intervalo de direcciones IP privadas que quiere usar. Los clientes VPN reciben de forma dinámica una
dirección IP del intervalo que especifique. La máscara de subred mínima es de 29 bits para la
configuración activa/pasiva, y de 28 bits para la configuración activa/activa.
3. Continúe con la sección siguiente para configurar los tipos de autenticación y de túnel.
Tipos de autenticación y de túnel

En esta sección, configurará el tipo de autenticación y el tipo de túnel. En la página Configuración de punto a
sitio , si no ve Tipo de túnel o Tipo de autenticación , significa que la puerta de enlace usa la SKU básica. La
SKU básica no admite la autenticación de IKEv2 o RADIUS. Si quiere usar esta configuración, debe eliminar y
volver a crear la puerta de enlace con una SKU de puerta de enlace diferente.
Tipo de túnel
En la página Configuración de punto a sitio , seleccione el tipo de túnel. Las opciones de túnel son OpenVPN,
SSTP y IKEv2.
El cliente Strongswan de Linux y Android, y el cliente VPN IKEv2 nativo de iOS y OSX solo utilizarán el túnel
IKEv2 para conectarse.
Los clientes Windows prueban primero el túnel IKEv2 y, si no se conecta, recurren a SSTP.
Puede usar el cliente OpenVPN para conectarse con el tipo de túnel OpenVPN.
Tipo de autenticación
En Tipo de autenticación , seleccione Cer tificado de Azure .
Datos del certificado raíz
En esta sección, cargará los datos del certificado raíz público en Azure. Una vez que se han cargado los datos de
certificado público, Azure puede usarlos para autenticar a los clientes que tienen instalado un certificado de
cliente generado a partir del certificado raíz de confianza.
1. Los certificados se agregan en la página Configuración de punto a sitio de la sección Cer tificado
raíz .
2. Asegúrese de exportar el certificado raíz como archivo X.509 codificado base 64 (.cer). Debe exportar el
certificado en este formato para poder abrirlo con un editor de texto.
3. Abra el certificado con un editor de texto como Bloc de notas. Al copiar los datos del certificado,
asegúrese de copiar el texto como una línea continua sin retornos de carro ni avances de línea. Es posible
que para ver los retornos de carro y los avances de línea deba cambiar la vista del editor de texto de
forma que se muestren los símbolos y todos los caracteres. Copie solo la siguiente sección como una
línea continua:
4. Pegue los datos del certificado en la sección Public Cer tificate Data (Datos de certificado público). En
Nombre asigne un nombre al certificado y, luego, seleccione Guardar . Puede agregar hasta 20
certificados raíz de confianza.
5. Seleccione Guardar en la parte superior de la página para guardar todos los valores de configuración.
Certificado de cliente
Si desea crear una conexión P2S desde un equipo cliente distinto del que usó para generar los certificados de
cliente, debe instalar un certificado de cliente. Al instalar un certificado de cliente, necesita la contraseña que se
creó cuando se exportó el certificado de cliente.
Asegúrese de que se exportó el certificado de cliente como un .pfx junto con la cadena de certificados completa
(que es el valor predeterminado). En caso contrario, la información del certificado raíz no está presente en el
equipo cliente y el cliente no podrá realizar la autenticación correctamente.
Para obtener los pasos de instalación, consulte Instalación de un certificado de cliente.
Paquete de configuración de cliente VPN

Los clientes VPN deben configurarse con las opciones de configuración de cliente. El paquete de configuración
de cliente VPN contiene archivos con los valores para configurar clientes VPN con el fin de conectarse a una red
virtual a través de una conexión P2S.
Para conocer los pasos para generar e instalar archivos de configuración de cliente VPN, consulte Creación e
instalación de archivos de configuración de cliente VPN para configuraciones P2S de autenticación nativa con
certificados de Azure.
Conexión con Azure

Para conectarse desde un cliente VPN en Windows
NOTE
Debe tener derechos de administrador en el equipo cliente de Windows desde el que se va a conectar.
1. Para conectarse a su red virtual, en el equipo cliente, vaya a la configuración de VPN y localice la conexión
VPN que creó. Tiene el mismo nombre que su red virtual. Seleccione Conectar . Es posible que aparezca
un mensaje emergente que haga referencia al uso del certificado. Seleccione Continuar para usar
privilegios elevados.
2. En la página de estado Conexión , seleccione Conectar para iniciar la conexión. Si ve una pantalla para
Seleccionar cer tificado , compruebe que el certificado de cliente que se muestra es el que desea
utilizar para conectarse. Si no es así, use la flecha de lista desplegable para seleccionar el certificado
correcto y, luego, seleccione Aceptar .
3. Se ha establecido la conexión.
Si tiene problemas para conectarse, compruebe los siguientes elementos:

Si ha exportado un certificado de cliente con el Asistente para expor tar cer tificados , asegúrese de
haberlo exportado como un archivo .pfx y de haber seleccionado Incluir todos los cer tificados en la
ruta de cer tificación (si es posible) . Si lo exporta con este valor, también se exporta la información
del certificado raíz. Una vez instalado el certificado en el equipo cliente, también se instala el certificado
raíz del archivo .pfx. Para verificar que el certificado raíz está instalado, abra Administrar cer tificados
de usuario y seleccione Entidades de cer tificación raíz de confianza \Cer tificados . Verifique que
el certificado raíz está presente, ya que es necesario para que la autenticación funcione.
Si usó un certificado emitido por una solución de CA empresarial y no puede autenticarse, verifique el
orden de autenticación en el certificado de cliente. Compruebe el orden de la lista de autenticación; para
ello, haga doble clic en el certificado de cliente, seleccione la pestaña Detalles y, después, seleccione Uso
mejorado de clave . Asegúrese de que Autenticación de cliente sea el primer elemento de la lista. Si no
es así, emita un certificado de cliente basado en la plantilla Usuario que tenga Autenticación de cliente
como primer elemento de la lista.
Para información adicional de solución de problemas de P2S, consulte Solución de problemas de
conexiones P2S.
Para conectarse desde un cliente VPN en Mac
En el cuadro de diálogo Red, localice el perfil de cliente que quiere usar, especifique la configuración de
VpnSettings.xml y, después, haga clic en Conectar .
Para obtener instrucciones detalladas al respecto, consulte Instalación: Mac (OS X). Si tiene problemas para
conectarse, compruebe que la puerta de enlace de red virtual no está usando una SKU de nivel Básico. La SKU
de nivel Básico no es compatible con los clientes Mac.
Para comprobar la conexión

Estas instrucciones se aplican a los clientes Windows.
1. Para comprobar que la conexión VPN está activa, abra un símbolo del sistema con privilegios elevados y
ejecute ipconfig/all.
2. Vea los resultados. Observe que la dirección IP que recibió es una de las direcciones dentro del grupo de
direcciones de cliente de VPN punto a sitio que especificó en la configuración. Los resultados son
similares a los del ejemplo siguiente:
PPP adapter VNet1:

Connection-specific DNS Suffix .:
Description.....................: VNet1
Physical Address................:
DHCP Enabled....................: No
Autoconfiguration Enabled.......: Yes
IPv4 Address....................: 172.16.201.3(Preferred)
Subnet Mask.....................: 255.255.255.255
Default Gateway.................:
NetBIOS over Tcpip..............: Enabled

$VMs = Get-AzVM
{
}
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.
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.
Para agregar o quitar certificados raíz de confianza

Puede agregar y quitar certificados raíz de confianza de Azure. Al quitar un certificado raíz, los clientes que
tienen un certificado generado a partir de dicha raíz no podrán autenticarse y, por tanto, no podrán conectarse.
Si desea que un cliente se autentique y se conecte, es preciso que instale un nuevo certificado de cliente
generado a partir de un certificado raíz que sea de confianza (se cargue) en Azure.
Para agregar un certificado raíz de confianza
Puede agregar hasta 20 archivos .cer de certificado raíz de confianza a Azure. Para ver instrucciones, consulte la
sección Carga del archivo .cer del certificado raíz de este artículo.
Eliminación de un certificado raíz de confianza
1. Para quitar un certificado raíz de confianza, vaya a la página Configuración de punto a sitio para la
puerta de enlace de red virtual.
2. En la sección Cer tificado raíz de la página, busque el certificado que desea quitar.
3. Seleccione los puntos suspensivos junto al certificado y, luego, "Quitar".
Para revocar un certificado de cliente

Puede revocar certificados de cliente. La lista de revocación de certificados permite denegar de forma selectiva
la conectividad de punto a sitio basada en certificados de cliente individuales. Esto difiere de la forma en que se
quita un certificado raíz de confianza. Si quita de Azure un archivo .cer de certificado raíz de confianza, se revoca
el acceso para todos los certificados de cliente generados y firmados con el certificado raíz revocado. Al
revocarse un certificado de cliente, en lugar del certificado raíz, se permite que el resto de los certificados que se
generaron a partir del certificado raíz sigan usándose para la autenticación.
Lo más habitual es usar el certificado raíz para administrar el acceso a nivel de equipo u organización, mientras
que los certificados de cliente revocados se usan para un control de acceso específico para usuarios
individuales.
Revocar un certificado de cliente
Puede revocar un certificado de cliente si agrega la huella digital a la lista de revocación.
1. Recupere la huella digital del certificado de cliente. Para más información, consulte Cómo recuperar la huella
digital de un certificado.
2. Copie la información en un editor de texto y quite todos los espacios de forma que sea una sola cadena
continua.
3. Vaya a la página Configuración de punto a sitio de la puerta de enlace de red virtual. Se trata de la
misma hoja que utilizó para cargar un certificado raíz de confianza.
4. En la sección Cer tificados revocados , especifique un nombre descriptivo para el certificado (no es
necesario que sea el CN del certificado).
5. Copie y pegue la cadena de huella digital en el campo Huella digital .
6. Se valida la huella digital y se agrega automáticamente a la lista de revocación. Aparece un mensaje en la
pantalla que indica que se está actualizando la lista.
7. Una vez finalizada la actualización, el certificado no se puede usar para conectarse. Los clientes que intenten
conectarse con este certificado reciben un mensaje que indica que el certificado ya no es válido.
Preguntas más frecuentes sobre la conexión de punto a sitio

Esta sección contiene información sobre las preguntas frecuentes relacionadas con las configuraciones de punto
a sitio. También puede ver las preguntas frecuentes sobre VPN Gateway para información adicional sobre VPN
Gateway.
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

No.
OpenSSL:
Pasos siguientes
Machines para más información. Para más información acerca de las redes y las máquinas virtuales, consulte
Información general sobre las redes de máquina virtual con Linux y Azure.
Para obtener información sobre solución de problemas de P2S, vea Solución de problemas: conexión de punto a
sitio de Azure.
Configure una conexión VPN de punto a sitio a una
red virtual mediante la autenticación nativa de los
certificados de Azure: PowerShell
sobre SSTP (Protocolo de túnel de sockets seguros) o IKEv2.
punto a sitio. Para crear esta configuración mediante Azure Portal, consulte Configuración de una conexión VPN
de punto a sitio con Azure Portal.
Las conexiones con autenticación mediante certificado de Azure nativas de punto a sitio usan los siguientes
elementos, que se configuran en este ejercicio:
La clave pública (archivo .cer) de un certificado raíz, que se carga en Azure. Una vez cargado el certificado, se
considera un certificado de confianza y se usa para la autenticación.
Un certificado de cliente que se genera a partir del certificado raíz. El certificado de cliente se instalará en
todos los equipos cliente que se conecten a la red virtual. Este certificado se usa para la autenticación de
cliente.
Configuración de cliente de VPN. El cliente VPN se configura mediante los archivos de configuración de
cliente de VPN. Estos archivos contienen la información necesaria para que el cliente se conecte a la red
virtual. Los archivos configuran el cliente VPN existente que es nativo en el sistema operativo. Cada cliente
que se conecta debe configurarse con los valores de los archivos de configuración.
Requisitos previos
Azure PowerShell
IMPORTANT
Para muchos de los pasos descritos en este artículo puede usar Azure Cloud Shell. Sin embargo, no puede usar Cloud
Shell para generar certificados. Además, para cargar la clave pública del certificado raíz, debe usar Azure PowerShell
localmente o Azure Portal.
Azure PowerShell.
1. Iniciar sesión
Si PowerShell se ejecuta localmente, abra la consola de PowerShell con privilegios elevados y conéctese a su
cuenta de Azure. El cmdlet Connect-AzAccount le pide las credenciales. Después de la autenticación, descarga la
configuración de la cuenta para que esté disponible en Azure PowerShell.
Si usa Azure Cloud Shell, en lugar de ejecutar PowerShell localmente, observará que no es preciso ejecutar
Connect-AzAccount. Azure Cloud Shell se conecta a su cuenta de Azure automáticamente después de
seleccionar Probar .
1. Si ejecuta PowerShell localmente, inicie sesión.
Connect-AzAccount
2. Si tiene más de una suscripción, obtenga una lista de las suscripciones de Azure.
Get-AzSubscription
2. Declaración de variables
Usamos variables en este artículo para que pueda cambiar fácilmente los valores que se aplican a su propio
entorno sin tener que cambiar los ejemplos. Declare las variables que desea utilizar. Puede usar el ejemplo
siguiente sustituyendo los valores por los suyos propios cuando sea necesario. Si cierra la sesión de
PowerShell/Cloud Shell en cualquier momento durante el ejercicio, copie y pegue los valores de nuevo para
volver a declarar las variables.
$VNetName = "VNet1"
$VNetPrefix = "10.1.0.0/16"
$FESubPrefix = "10.1.0.0/24"
$GWSubPrefix = "10.1.255.0/27"
$RG = "TestRG1"
$Location = "EastUS"
$GWName = "VNet1GW"
$GWIPName = "VNet1GWpip"
$DNS = "10.2.1.4"
3. Configuración de una red virtual

2. Cree las configuraciones de subred para la red virtual con los nombres FrontEnd y GatewaySubnet. Estos
prefijos deben formar parte del espacio de direcciones de la red virtual que declaró anteriormente.
$fesub = New-AzVirtualNetworkSubnetConfig -Name $FESubName -AddressPrefix $FESubPrefix

$gwsub = New-AzVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix
3. Creación de la red virtual.

En este ejemplo, el parámetro del servidor -DnsServer es opcional. La especificación de un valor no crea
un servidor DNS nuevo. La dirección IP del servidor DNS que especifique debe ser un servidor DNS que
pueda resolver los nombres de los recursos a los que se conecta desde la red virtual. En este ejemplo, se
usa una dirección IP privada, pero es probable que no sea la dirección IP del servidor DNS. Asegúrese de
utilizar sus propios valores. El valor especificado lo utilizan los recursos que se implementan en la red
virtual, no la conexión de punto a sitio ni el cliente VPN.
New-AzVirtualNetwork `
-Name $VNetName `
-AddressPrefix $VNetPrefix `
-Subnet $fesub, $gwsub `
-DnsServer $DNS
4. Especifique las variables de la red virtual que creó.

$subnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
5. Una puerta de enlace VPN debe tener una dirección IP pública. Primero se solicita el recurso de la
dirección IP y, después, se hace referencia a él al crear la puerta de enlace de red virtual. La dirección IP se
asigna dinámicamente al recurso cuando se crea la puerta de enlace VPN. Actualmente, VPN Gateway
solo admite la asignación de direcciones IP públicas dinámicas. No se puede solicitar una asignación de
direcciones IP públicas estáticas. Sin embargo, esto no significa que la dirección IP cambie después de
que se haya asignado a la puerta de enlace VPN. La única vez que la dirección IP pública cambia es
cuando la puerta de enlace se elimina y se vuelve a crear. No cambia cuando se cambia el tamaño, se
restablece o se realizan actualizaciones u otras operaciones de mantenimiento interno de una puerta de
enlace VPN.
Solicite una dirección IP pública asignada de forma dinámica.
$pip = New-AzPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Location -

$ipconf = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $subnet -PublicIpAddress
$pip

En este paso, configurará y creará la puerta de enlace de red virtual para la red virtual.
El valor de -GatewayType debe ser Vpn y el valor de -VpnType debe ser RouteBased .
-VpnClientProtocol se utiliza para especificar los tipos de túneles que desea habilitar. Las opciones de túnel
son OpenVPN, SSTP y IKEv2 . Puede habilitar una de ellas o cualquier combinación admitida. Si desea
habilitar varios tipos, especifique los nombres separados por una coma. OpenVPN y SSTP no se pueden
habilitar juntas. El cliente strongSwan de Linux y Android y el cliente VPN IKEv2 nativo de iOS y OSX solo
utilizarán el túnel IKEv2 para conectarse. Los clientes Windows prueban primero el túnel IKEv2 y, si no se
conecta, recurren a SSTP. Puede usar el cliente OpenVPN para conectarse al tipo de túnel OpenVPN.
La SKU "básica" de la puerta de enlace de red virtual no admite la autenticación de IKEv2, OpenVPN o
RADIUS. Si planea que clientes Mac se conecten a su red virtual, no use la SKU de nivel Básico.
Una puerta de enlace de VPN puede tardar hasta 45 minutos en completarse, según la SKU de puerta de
enlace que seleccione. Este ejemplo utiliza IKEv2.
1. Configure y cree la puerta de enlace de red virtual para la red virtual. La puerta de enlace tarda
aproximadamente 45 minutos en crearse.

-Location $Location -IpConfigurations $ipconf -GatewayType Vpn `
-VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw1 -VpnClientProtocol "IKEv2"
2. Una vez creada la puerta de enlace, puede verla mediante el ejemplo siguiente. Si cerró PowerShell o
agotó el tiempo de espera mientras se creaba la puerta de enlace, puede declarar las variables de nuevo.
Get-AzVirtualNetworkGateway -Name $GWName -ResourceGroup $RG
5. Adición del grupo de direcciones de clientes de VPN

Cuando acabe de crear la puerta de enlace VPN, puede agregar el grupo de direcciones de cliente VPN. El grupo
de direcciones del cliente de VPN es el intervalo del que los clientes de VPN reciben una dirección IP al
conectarse. Use un intervalo de direcciones IP privadas que no se superponga a la ubicación local desde la que
se va a conectar ni a la red virtual a la que desea conectarse.
En este ejemplo, el grupo de direcciones del cliente de VPN se declara como variable en el paso anterior.
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway -VpnClientAddressPool $VPNClientAddressPool
6. Generación de certificados
IMPORTANT
No se pueden generar certificados con Azure Cloud Shell. Debe usar uno de los métodos descritos en esta sección. Si
desea usar PowerShell, debe instalarlo de forma local.
Azure usa los certificados para autenticar a los clientes de VPN para las VPN de punto a sitio. Cargue la
información de clave pública del certificado raíz en Azure. La clave pública se considerará "de confianza". Deben
generarse certificados de cliente a partir del certificado raíz de confianza e instalarse en cada equipo cliente en
el almacén de certificados Certificados - Usuario actual/Personal. El certificado se utiliza para autenticar al
cliente cuando inicia una conexión con la red virtual.
Si usa certificados autofirmados, se deben crear con parámetros específicos. Puede crear un certificado
autofirmado con las instrucciones para PowerShell y Windows 10, o bien, si no tiene Windows 10, puede usar
MakeCert. Es importante que siga los pasos de las instrucciones al generar certificados raíz autofirmados y
certificados de cliente. En caso contrario, los certificados que genere no serán compatibles con las conexiones
P2S y recibirá un error de conexión.
Certificado raíz
1. Obtenga el archivo .cer del certificado raíz. Puede usar un certificado raíz generado mediante una
solución empresarial (opción recomendada) o generar un certificado autofirmado. Después de crear el
certificado raíz, exporte los datos (no la clave privada) del certificado público como un archivo .cer con
codificación Base64 X.509. Este archivo se carga más adelante en Azure.
Cer tificado de empresa: Si usa una solución empresarial, puede utilizar la cadena de
certificados existente. Obtenga el archivo .cer para el certificado raíz que desee usar.
Cer tificado raíz autofirmado : Si no usa una solución de certificado de empresa, cree un
certificado raíz autofirmado. En caso contrario, los certificados que cree no serán compatibles con
las conexiones de P2S y los clientes recibirán un error de conexión al intentar conectarse. Puede
usar Azure PowerShell, MakeCert o bien OpenSSL. Los pasos descritos en los artículos siguientes
describen cómo generar un certificado raíz autofirmado compatible:
PowerShell para generar certificados. Los certificados de cliente que se generan desde el
certificado raíz pueden instalarse en cualquier cliente P2S compatible.
Instrucciones para MakeCert: use MakeCert para generar certificados si no tiene acceso a un
equipo con Windows 10. Aunque MakeCert está en desuso, todavía puede usarlo para generar
certificados. Los certificados de cliente que se generan desde el certificado raíz pueden
2. Después de crear el certificado raíz, exporte los datos (no la clave privada) del certificado público como
un archivo .cer X.509 con codificación en Base64.
Certificado de cliente
1. Cada equipo cliente que se conecta a una red virtual con una conexión de punto a sitio debe tener
instalado un certificado de cliente. Se genera desde el certificado raíz y se instala en cada equipo cliente.
Si no instala ningún certificado de cliente válido, la autenticación no podrá realizarse cuando el cliente
trate de conectarse a la red virtual.
Puede generar un certificado único para cada cliente o puede usar el mismo para varios clientes. La
ventaja de generar certificados de cliente únicos es la capacidad de revocar un solo certificado. De lo
contrario, si varios clientes usan el mismo certificado de cliente para autenticarse y este se revoca, deberá
generar e instalar nuevos certificados para cada cliente que use dicho certificado.
Si usa una solución de certificación de empresa, genere un certificado de cliente con el
formato de valor de nombre común [email protected]. Use este formato en lugar de
domain name\username.
Asegúrese de que el certificado de cliente se base en la plantilla de certificado de usuario
que tenga Autenticación de cliente como primer elemento de la lista de usuarios. Para
comprobar el certificado, haga doble clic en él y vea Uso mejorado de clave en la
pestaña Detalles .
Cer tificado raíz autofirmado : siga los pasos de alguno de los siguientes artículos de
certificados de P2S para que los certificados de cliente que cree sean compatibles con las
conexiones de P2S.
Si genera un certificado de cliente desde un certificado raíz autofirmado, este se instala
automáticamente en el equipo que utilizó para generarlo. Si desea instalar un certificado de cliente
en otro equipo cliente, expórtelo como un archivo .pfx junto con toda la cadena de certificados. De
esta forma, creará un archivo .pfx que contiene la información del certificado raíz necesaria para
que el cliente se autentique.
Los pasos de estos artículos generan un certificado de cliente compatible que puede,
posteriormente, exportar y distribuir.
PowerShell para generar certificados. Los certificados generados pueden instalarse en
cualquier cliente P2S compatible.
Instrucciones para MakeCert: use MakeCert si no tiene acceso a un equipo Windows 10
para generar certificados. Aunque MakeCert está en desuso, todavía puede usarlo para
generar certificados. Puede instalar los certificados generados en cualquier cliente P2S
compatible.
2. Después de crear el certificado de cliente, expórtelo. El certificado de cliente se distribuirá a los equipos
cliente que se conectarán.
7. Cargue la información de clave pública del certificado raíz

Compruebe que ha terminado de crear la puerta de enlace VPN. Una vez terminado, puede cargar el archivo .cer
(que contiene la información de clave pública) para un certificado raíz de confianza en Azure. Una vez que se ha
cargado un archivo .cer, Azure puede usarlo para autenticar a los clientes que tienen instalado un certificado de
cliente generado a partir del certificado raíz de confianza. Más adelante, puede cargar más archivos de
certificado raíz de confianza, hasta un total de 20, si es necesario.
NOTE
No se puede cargar el archivo .cer mediante Azure Cloud Shell. Puede usar PowerShell localmente en el equipo o seguir los
pasos de Azure Portal.
1. Declare la variable del nombre del certificado, pero reemplace el valor por el suyo propio.
$P2SRootCertName = "P2SRootCert.cer"
2. Reemplace la ruta de acceso del archivo por la del suyo y ejecute los cmdlets.
$filePathForCert = "C:\cert\P2SRootCert.cer"
$CertBase64 = [system.convert]::ToBase64String($cert.RawData)
3. Cargue la información de clave pública en Azure. Una vez que se carga la información del certificado,
Azure considera que se trata de un certificado raíz de confianza. Al realizar la carga, asegúrese de que
está ejecutando PowerShell localmente en el equipo o, en su lugar, puede seguir los pasos de Azure
Portal. No se puede realizar la carga mediante Azure Cloud Shell.
Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -

VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG1" -PublicCertData $CertBase64
8. Instalación de un certificado de cliente exportado

Los siguientes pasos le ayudarán a completar la instalación en un cliente Windows. Para obtener más
información, consulte Instalación de un certificado de cliente.
1. Busque el archivo .pfx y cópielo en el equipo cliente. En el equipo cliente, haga doble clic en el archivo .pfx
para instalarlo. Deje Ubicación del almacén como Usuario actual y seleccione Siguiente .
2. En la página File to impor t (Archivo para importar), no haga ningún cambio. Seleccione Siguiente .
3. En la página Protección de clave privada , escriba la contraseña del certificado o compruebe que la
entidad de seguridad sea correcta y seleccione Siguiente .
4. En la página Almacén de cer tificados , deje la ubicación predeterminada y seleccione Siguiente .
5. Seleccione Finalizar . En la adver tencia de seguridad para la instalación de certificados, seleccione Sí .
Puede seleccionar con total tranquilidad el valor "Sí" en esta advertencia de seguridad, ya que ha generado el
certificado.
6. El certificado se importó correctamente.
Asegúrese de que se exportó el certificado de cliente como un .pfx junto con la cadena de certificados completa
(que es el valor predeterminado). En caso contrario, la información del certificado raíz no está presente en el
equipo cliente y el cliente no podrá realizar la autenticación correctamente.
9. Configuración del cliente VPN

En esta sección, configurará el cliente nativo para que el equipo se conecte a la puerta de enlace de red virtual.
Por ejemplo, al ir a la configuración de VPN en el equipo Windows, puede agregar conexiones VPN. Una
conexión de punto a sitio requiere opciones de configuración específicas. Estos pasos le ayudarán a crear un
paquete con la configuración específica que el cliente VPN nativo necesita para conectarse a la red virtual a
través de una conexión de punto a sitio.
Puede usar los siguientes ejemplos rápidos para generar e instalar el paquete de configuración del cliente. Para
obtener más información sobre el contenido del paquete y otras instrucciones sobre cómo generar e instalar
archivos de configuración de cliente de VPN, consulte Creación e instalación de archivos de configuración de
cliente VPN.
Si necesita volver a declarar las variables, puede encontrarlas aquí.
Para generar archivos de configuración
$profile=New-AzVpnClientConfiguration -ResourceGroupName $RG -Name $GWName -AuthenticationMethod "EapTls"
$profile.VPNProfileSASUrl
Para instalar el paquete de configuración del cliente

Puede utilizar el mismo paquete de configuración de cliente VPN en todos los equipos cliente Windows, siempre
que la versión coincida con la arquitectura del cliente. Para la lista de sistemas operativos de cliente compatibles,
consulte la sección de punto a sitio de las preguntas más frecuentes sobre la puerta de enlace de VPN.
NOTE
Debe tener derechos de administrador en el equipo cliente de Windows desde el que desea conectarse.
Use estos pasos para configurar al cliente VPN de Windows nativo para la autenticación mediante certificado:
1. Seleccione los archivos de configuración de cliente VPN que correspondan a la arquitectura del equipo
Windows. Si la arquitectura de procesador es de 64 bits, elija el paquete del instalador
"VpnClientSetupAmd64". En caso de que sea de 32 bits, elija el paquete del instalador "VpnClientSetupX86".
2. Haga doble clic en el paquete para instalarlo. Si ve una ventana emergente de SmartScreen, haga clic en Más
información y en Ejecutar de todas formas .
3. En el equipo cliente, vaya a Configuración de red y haga clic en VPN . La conexión VPN muestra el nombre
de la red virtual a la que se conecta.
4. Antes de intentar conectarse, compruebe que ha instalado un certificado de cliente en el equipo cliente. Es
necesario un certificado de cliente para la autenticación al usar el tipo de autenticación de certificados nativo
de Azure.
10. Conexión con Azure

Cliente de VPN de Windows
NOTE
Debe tener derechos de administrador en el equipo cliente de Windows desde el que se va a conectar.
1. Para conectarse a su red virtual, en el equipo cliente, vaya a la configuración de VPN y localice la conexión
VPN que creó. Tiene el mismo nombre que su red virtual. Seleccione Conectar . Es posible que aparezca
un mensaje emergente que haga referencia al uso del certificado. Seleccione Continuar para usar
privilegios elevados.
2. En la página de estado Conexión , seleccione Conectar para iniciar la conexión. Si ve una pantalla para
Seleccionar cer tificado , compruebe que el certificado de cliente que se muestra es el que desea
utilizar para conectarse. Si no es así, use la flecha de lista desplegable para seleccionar el certificado
correcto y, luego, seleccione Aceptar .

conexiones P2S.
Cliente de VPN de Mac
En el cuadro de diálogo Red, localice el perfil de cliente que desea utilizar y, después, haga clic en Conectar . Para
obtener instrucciones detalladas al respecto, consulte Instalación: Mac (OS X). Si tiene problemas para
conectarse, compruebe que la puerta de enlace de red virtual no está usando una SKU de nivel Básico. La SKU
de nivel Básico no es compatible con los clientes Mac.
Para comprobar una conexión
PPP adapter VNet1:

DHCP Enabled....................: No
Subnet Mask.....................: 255.255.255.255

$VMs = Get-AzVM
{
}
Adición o eliminación de un certificado raíz

cuentan con un certificado generado a partir del certificado raíz no pueden autenticarse y no podrán conectarse.
Si desea que un cliente se autentique y se conecte, es preciso que instale un nuevo certificado de cliente
generado a partir de un certificado raíz que sea de confianza (se cargue) en Azure. Estos pasos requieren los
cmdlets de Azure PowerShell instalados localmente en el equipo (no Azure Cloud Shell). También puede usar
Azure Portal para agregar certificados raíz.
Para agregar :
Puede agregar hasta 20 archivos .cer de certificado raíz a Azure. Los pasos siguientes lo ayudan a agregar un
certificado raíz.
1. Preparar el archivo .cer que desea cargar:
$filePathForCert = "C:\cert\P2SRootCert3.cer"
$CertBase64_3 = [system.convert]::ToBase64String($cert.RawData)
2. Cargar el archivo. Solo puede cargar un archivo a la vez.
Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -

VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG1" -PublicCertData $CertBase64_3
3. Para comprobar que se ha cargado el archivo de certificado:
Get-AzVpnClientRootCertificate -ResourceGroupName "TestRG1" `

-VirtualNetworkGatewayName "VNet1GW"
Para quitar :
1. Declare las variables. Modifique las variables del ejemplo para que coincidan con el certificado que desea
quitar.
$GWName = "Name_of_virtual_network_gateway"
$RG = "Name_of_resource_group"
$P2SRootCertName2 = "ARMP2SRootCert2.cer"
$MyP2SCertPubKeyBase64_2 =
"MIIC/zCCAeugAwIBAgIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDU15UDJTUm9vdENlcnQwHhcNMTUx
MjE5MDI1MTIxWhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw1NeVAyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AM
IIBCgKCAQEAyjIXoWy8xE/GF1OSIvUaA0bxBjZ1PJfcXkMWsHPzvhWc2esOKrVQtgFgDz4ggAnOUFEkFaszjiHdnXv3mjzE2SpmAV
IZPf2/yPWqkoHwkmrp6BpOvNVOpKxaGPOuK8+dql1xcL0eCkt69g4lxy0FGRFkBcSIgVTViS9wjuuS7LPo5+OXgyFkAY3pSDiMzQC
kRGNFgw5WGMHRDAiruDQF1ciLNojAQCsDdLnI3pDYsvRW73HZEhmOqRRnJQe6VekvBYKLvnKaxUTKhFIYwuymHBB96nMFdRUKCZIi
WRIy8Hc8+sQEsAML2EItAjQv4+fqgYiFdSWqnQCPf/7IZbotgQIDAQABo00wSzBJBgNVHQEEQjBAgBAkuVrWvFsCJAdK5pb/eoCNo
RowGDEWMBQGA1UEAxMNTXlQMlNSb290Q2VydIIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAA4IBAQA223veAZEIar9N12ubNH
2+HwZASNzDVNqspkPKD97TXfKHlPlIcS43TaYkTz38eVrwI6E0yDk4jAuPaKnPuPYFRj9w540SvY6PdOUwDoEqpIcAVp+b4VYwxPL
6oyEQ8wnOYuoAK1hhh20lCbo8h9mMy9ofU+RP6HJ7lTqupLfXdID/XevI8tW6Dm+C/wCeV3EmIlO9KUoblD/e24zlo3YzOtbyXwTI
h34T0fO/zQvUuBqZMcIPfM1cDvqcqiEFLWvWKoAnxbzckye2uk1gHO52d8AVL3mGiX8wBJkjc/pMdxrEvvCzJkltBmqxTM6XjDJAL
uVh16qFlqgTWCIcb7ju"
2. Quite el certificado.
Remove-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -

VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -PublicCertData $MyP2SCertPubKeyBase64_2
3. Use el siguiente ejemplo para comprobar que el certificado se quitó correctamente.
Get-AzVpnClientRootCertificate -ResourceGroupName "TestRG1" `

-VirtualNetworkGatewayName "VNet1GW"
Para revocar o restablecer un certificado de cliente

Puede revocar certificados de cliente. La lista de revocación de certificados permite denegar de forma selectiva
la conectividad de punto a sitio basada en certificados de cliente individuales. Esto difiere de la forma en que se
quita un certificado raíz de confianza. Si quita de Azure un archivo .cer de certificado raíz de confianza, se revoca
el acceso para todos los certificados de cliente generados y firmados con el certificado raíz revocado. Al
revocarse un certificado de cliente, en lugar del certificado raíz, se permite que el resto de los certificados que se
generaron a partir del certificado raíz sigan usándose para la autenticación.
individuales.
Para revocar :
1. Recupere la huella digital del certificado de cliente. Para más información, consulte Cómo recuperar la
huella digital de un certificado.
2. Copie la información en un editor de texto y quite todos los espacios de forma que sea una sola cadena
continua. Esta cadena se declara como variable en el paso siguiente.
3. Declare las variables. Asegúrese de declarar la huella digital que recuperó en el paso anterior.
$RevokedClientCert1 = "NameofCertificate"
$RevokedThumbprint1 = "51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
4. Agregue la huella digital a la lista de certificados revocados. Cuando haya agregado la huella digital,
aparece un aviso que le indica que la acción se ha completado "correctamente".
Add-AzVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `

-VirtualNetworkGatewayName $GWName -ResourceGroupName $RG `
-Thumbprint $RevokedThumbprint1
5. Compruebe que la huella digital se agregó a la lista de revocación de certificados.
Get-AzVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
6. Una vez agregada la huella digital, el certificado ya no podrá utilizarse para conectarse. Los clientes que
intenten conectarse con este certificado reciben un mensaje que indica que el certificado ya no es válido.
Para restablecer :
Puede restablecer un certificado de cliente quitando la huella digital de la lista de certificados de cliente
revocados.
1. Declare las variables. Asegúrese de que declara la huella digital correcta para el certificado que desea
restablecer.
$RevokedClientCert1 = "NameofCertificate"
$RevokedThumbprint1 = "51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
2. Quite la huella digital del certificado de la lista de revocación de certificados.
Remove-AzVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `

-VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -Thumbprint $RevokedThumbprint1
3. Compruebe si la huella digital se quita de la lista revocada.

Get-AzVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG

Para obtener información adicional de punto a sitio, consulte las preguntas frecuentes de punto a sitio de VPN
Gateway.
Pasos siguientes
Para información de solución de problemas de P2S, consulte el artículo de solución de problemas de conexión
de punto a sitio de Azure.
Generación y exportación de certificados para
conexiones de punto a sitio con PowerShell
Las conexiones de punto a sitio utilizan certificados para realizar la autenticación. En este artículo, se muestra
cómo crear un certificado raíz autofirmado y generar certificados de cliente usando PowerShell en Windows 10
o Windows Server 2016. Si busca otras instrucciones de certificado, vea los artículos sobre certificados con
Linux o certificados con MakeCert.
Debe realizar los pasos de este artículo en un equipo que ejecute Windows 10 o Windows Server 2016. Los
cmdlets de PowerShell que se usan para generar certificados forman parte del sistema operativo y no funcionan
en otras versiones de Windows. El equipo con Windows 10 o Windows Server 2016 solo es necesario para
generar los certificados. Una vez que se generan los certificados, puede cargarlos o instalarlos en cualquier
sistema operativo cliente compatible.
Si no tiene acceso a un equipo con Windows 10 o Windows Server 2016, puede usar MakeCert para generar
certificados. Los certificados que genera mediante cualquiera de estos métodos pueden instalarse en cualquier
sistema operativo cliente compatible.
Creación de un certificado raíz autofirmado

Use el cmdlet New-SelfSignedCertificate para crear un certificado raíz autofirmado. Para obtener información
adicional sobre los parámetros, consulte New-SelfSignedCertificate.
1. En un equipo con Windows 10 o Windows Server 2016, abra una consola de Windows PowerShell con
privilegios elevados. Estos ejemplos no funcionan en Azure Cloud Shell "Try It". Debe ejecutar estos
ejemplos localmente.
2. Utilice el ejemplo siguiente para crear el certificado raíz autofirmado. En el ejemplo siguiente se crea un
certificado raíz firmado automáticamente con el nombre "P2SRootCert" que se instala automáticamente
en "Certificates-Current User\Personal\Certificates". Puede ver el certificado si abre certmgr.msc, o bien
Administrar certificados de usuario.
Utilice el cmdlet Connect-AzAccount para iniciar sesión. Luego, ejecute el siguiente ejemplo con las
modificaciones necesarias.
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject "CN=P2SRootCert" -KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
3. Deje abierta la consola de PowerShell y continúe con los pasos siguientes para generar un certificado de
cliente.
Generación de un certificado de cliente

certificado de cliente. Puede generarlo desde un certificado raíz autofirmado y, luego, exportar e instalar el
certificado de cliente. Si no está instalado el certificado de cliente, se produce un error de autenticación.
Los pasos siguientes lo llevan por el proceso de generación de un certificado de cliente a partir de un certificado
autofirmado. Puede generar varios certificados de cliente desde el mismo certificado raíz. Al generar
certificados de cliente mediante los pasos siguientes, el certificado de cliente se instala automáticamente en el
equipo que se usó para generar el certificado. Si desea instalar un certificado de cliente en otro equipo cliente,
puede exportar el certificado.
Los ejemplos usan el cmdlet New-SelfSignedCertificate para generar un certificado de cliente que expira en un
año. Para obtener información adicional sobre los parámetros (por ejemplo, cómo establecer un valor de
expiración diferente para el certificado de cliente), consulte New-SelfSignedCertificate.
Ejemplo 1: sesión de consola de PowerShell aún abierta
Use este ejemplo si no ha cerrado la consola de PowerShell después de crear el certificado raíz autofirmado.
Este ejemplo continúa desde la sección anterior y usa la variable "$cert" declarada. Si cerró la consola de
PowerShell después de crear el certificado raíz autofirmado o va a crear más certificados de cliente en una
nueva sesión de consola de PowerShell, siga los pasos del Ejemplo 2.
Modifique y ejecute el ejemplo para generar un certificado de cliente. Si ejecuta el ejemplo siguiente sin
modificación alguna, el resultado es un certificado de cliente con el nombre "P2SChildCert". Si quiere agregar
algo más al nombre del certificado secundario, modifique el valor CN. No cambie el valor de TextExtension
cuando ejecute este ejemplo. El certificado de cliente que genera se instala automáticamente en la ruta del
equipo "Certificates - Current User\Personal\Certificates".
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `

-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Ejemplo 2: nueva sesión de consola de PowerShell

Si va a crear más certificados de cliente, o bien no está usando la misma sesión de PowerShell que empleó para
crear el certificado raíz autofirmado, siga estos pasos:
1. Identifique el certificado raíz autofirmado que se instaló en el equipo. Este cmdlet devuelve una lista de
certificados que están instalados en el equipo.
Get-ChildItem -Path "Cert:\CurrentUser\My"
2. Busque el nombre del firmante de la lista devuelta y, luego, copie la huella digital que se encuentra junto
a él en un archivo de texto. En el ejemplo siguiente, hay dos certificados. El nombre CN es el nombre del
certificado raíz autofirmado a partir del que va a generar un certificado secundario. En este caso,
"P2SRootCert".
Thumbprint Subject
AED812AD883826FF76B4D1D5A77B3C08EFA79F3F CN=P2SChildCert4
7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655 CN=P2SRootCert
3. Declare una variable para el certificado raíz con la huella digital del paso anterior. Reemplace la huella
digital con la del certificado raíz a partir del que va a generar un certificado secundario.
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\THUMBPRINT"
Por ejemplo, al usar la huella digital de P2SRootCert del paso anterior, la variable tendrá el aspecto
similar al siguiente:
$cert = Get-ChildItem -Path "Cert:\CurrentUser\My\7181AA8C1B4D34EEDB2F3D3BEC5839F3FE52D655"
4. Modifique y ejecute el ejemplo para generar un certificado de cliente. Si ejecuta el ejemplo siguiente sin
modificación alguna, el resultado es un certificado de cliente con el nombre "P2SChildCert". Si quiere
agregar algo más al nombre del certificado secundario, modifique el valor CN. No cambie el valor de
TextExtension cuando ejecute este ejemplo. El certificado de cliente que genera se instala
automáticamente en la ruta del equipo "Certificates - Current User\Personal\Certificates".
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `

-Subject "CN=P2SChildCert" -KeyExportPolicy Exportable `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Exportación de la clave pública del certificado raíz (.cer)

Después de crear un certificado raíz autofirmado, exporte el archivo .cer de clave pública de certificado de raíz
(no la clave privada). Este archivo se cargará más adelante en Azure. Los pasos siguientes le ayudan a exportar
el archivo .cer para el certificado raíz autofirmado:
1. Para obtener un archivo .cer del certificado, abra Administrar cer tificados de usuario . Busque el
certificado raíz autofirmado; normalmente se encuentra en Certificados - Usuario
actual\Personal\Certificados y haga clic en el botón derecho. Haga clic en Todas las tareas y, luego, en
Expor tar . Se abre el Asistente para expor tar cer tificados . Si no encuentra el certificado en Usuario
actual\Personal\Certificados, puede que haya abierto de forma accidental "Certificados – equipo Local",
en lugar de "Certificados - Usuario actual"). Si desea abrir el Administrador de certificados en el ámbito
del usuario actual mediante PowerShell, escriba certmgr en la ventana de la consola.
2. En el asistente, haga clic en Siguiente .

3. Seleccione No expor tar la clave privada y, después, haga clic en Siguiente .
4. En la página Formato de archivo de expor tación , seleccione X.509 codificado base 64 (.CER) y,
luego, haga clic en Siguiente .
5. En Archivo que se va a expor tar , haga clic en Examinar para ir a la ubicación a la que desea exportar
el certificado. En Nombre de archivo , asígnele un nombre al archivo de certificado. A continuación,
haga clic en Siguiente .
6. Haga clic en Finalizar para exportar el certificado.

7. El certificado se exportó correctamente.
8. El certificado exportado tiene un aspecto similar al siguiente:
9. Si abre el certificado exportado mediante el Bloc de notas, verá algo parecido a este ejemplo. La sección
en azul contiene la información que se carga en Azure. Si abre el certificado con el Bloc de notas y no se
parece a este, normalmente eso significa que no lo exportó mediante el formato X.509 codificado base
64 (. CER). Además, si desea utilizar un editor de texto diferente, debe comprender que algunos editores
pueden introducir formatos no deseados en segundo plano. Esto puede crear problemas al cargar el texto
de este certificado en Azure.
Exportación del certificado raíz autofirmado y clave privada para almacenarlo (opcional)
Puede que desee exportar el certificado autofirmado y almacenarlo de manera segura como copia de seguridad.
Si es necesario, más adelante puede instalarlo en otro equipo y generar más certificados de cliente. Para
exportar el certificado raíz autofirmado como archivo .pfx, seleccione el certificado raíz y use los mismos pasos
descritos en Exportación de un certificado de cliente.
Exportación del certificado de cliente

Al generar un certificado de cliente, se instala automáticamente en el equipo que usó para generarlo. Si desea
instalar el certificado de cliente en otro equipo cliente, debe exportar el certificado de cliente que ha generado.
1. Para exportar un certificado de cliente, abra Administrar cer tificados de usuario . De forma
predeterminada, los certificados de cliente que ha generado se encuentran en "Certificates - Current
User\Personal\Certificates". Haga clic con el botón derecho en el certificado de cliente que desee exportar
y haga clic en Todas las tareas y en Expor tar para abrir el Asistente para expor tar cer tificados .
2. En Asistente para exportar certificados, haga clic en Siguiente para continuar.
3. Seleccione Expor tar la clave privada y, después, haga clic en Siguiente .
4. En la página Formato de archivo de expor tación , deje seleccionados los valores predeterminados.
Asegúrese de que Incluir todos los cer tificados en la ruta de cer tificación si es posible esté
seleccionada. Esta opción también exporta la información del certificado raíz que se requiere para una
autenticación correcta del cliente. Sin ella, se produce un error de autenticación del cliente porque este no
tiene el certificado raíz de confianza. A continuación, haga clic en Siguiente .
5. En la página Seguridad , debe proteger la clave privada. Si decide usar una contraseña, asegúrese de
anotarla o de recordar la contraseña que estableció para este certificado. A continuación, haga clic en
Siguiente .
Instalación de un certificado de cliente exportado

Cada cliente que se conecta a la red virtual a través de una conexión de punto a sitio requiere que haya un
certificado de cliente instalado localmente.
Para instalar un certificado de cliente, consulte cómo instalar un certificado de cliente para conexiones de punto
a sitio.
Pasos siguientes
Continúe con la configuración de punto a sitio.
Para conocer los pasos del modelo de implementación de Resource Manager , consulte cómo configurar
una conexión de punto a sitio mediante la autenticación de certificados de Azure nativa.
Para ver los pasos del modelo de implementación clásica , consulte el artículo Configuración de una
conexión VPN de punto a sitio a una red virtual mediante el Portal clásico.
Generación y exportación de certificados para
conexiones de punto a sitio con MakeCert
cómo crear un certificado raíz autofirmado y generar certificados de cliente con MakeCert. Si busca otras
instrucciones de certificado, vea Certificates - PowerShell (Certificados: PowerShell) o Certificates - Linux
(Certificados: Linux).
Aunque se recomienda utilizar los pasos de Windows 10 PowerShell para crear los certificados, proporcionamos
estas instrucciones de MakeCert como un método opcional. Los certificados que genera mediante cualquiera de
estos métodos pueden instalarse en cualquier sistema operativo cliente compatible. Sin embargo, MakeCert
tiene la siguiente limitación:
Makecert está en desuso. Esto significa que se puede quitar esta herramienta en cualquier momento. Los
certificados ya generados con MakeCert no se verán afectados si MakeCert ya no está disponible. MakeCert
solo se utiliza para generar los certificados, no como un mecanismo de validación.
Creación de un certificado raíz autofirmado

Los siguientes pasos le mostrarán cómo crear un certificado autofirmado mediante MakeCert. Estos pasos no
son específicos del modelo de implementación. Son válidos para el Administrador de recursos y la versión
clásica.
1. Descargue e instale MakeCert.
2. Después de la instalación, la utilidad makecert.exe se encuentra normalmente en esta ruta de acceso:
"C:\Archivos de programa (x86)\Windows Kits\10\bin<arch>". Sin embargo, es posible que se haya
instalado en otra ubicación. Abra un símbolo del sistema como administrador y navegue hasta la
ubicación de la utilidad MakeCert. Puede usar el siguiente ejemplo y ajustar la ubicación adecuada:
cd C:\Program Files (x86)\Windows Kits\10\bin\x64
3. Después, cree e instale un certificado en el almacén de certificados personal de su equipo. En el ejemplo

siguiente se crea un archivo .cer correspondiente que se carga en Azure al configurar P2S. Reemplace
P2SRootCert y P2SRootCert.cer por el nombre que quiera usar para el certificado. El certificado se
encuentra en los certificados, en "Usuario actual\Personal\Certificados".
makecert -sky exchange -r -n "CN=P2SRootCert" -pe -a sha256 -len 2048 -ss My
Exportación de la clave pública (.cer)

Después de crear un certificado raíz autofirmado, exporte el archivo .cer de clave pública de certificado de raíz
(no la clave privada). Este archivo se cargará más adelante en Azure. Los pasos siguientes le ayudan a exportar
el archivo .cer para el certificado raíz autofirmado:
1. Para obtener un archivo .cer del certificado, abra Administrar cer tificados de usuario . Busque el
certificado raíz autofirmado; normalmente se encuentra en Certificados - Usuario
actual\Personal\Certificados y haga clic en el botón derecho. Haga clic en Todas las tareas y, luego, en
Expor tar . Se abre el Asistente para expor tar cer tificados . Si no encuentra el certificado en Usuario
actual\Personal\Certificados, puede que haya abierto de forma accidental "Certificados – equipo Local",
en lugar de "Certificados - Usuario actual"). Si desea abrir el Administrador de certificados en el ámbito
del usuario actual mediante PowerShell, escriba certmgr en la ventana de la consola.
2. En el asistente, haga clic en Siguiente .
3. Seleccione No expor tar la clave privada y, después, haga clic en Siguiente .

4. En la página Formato de archivo de expor tación , seleccione X.509 codificado base 64 (.CER) y,
luego, haga clic en Siguiente .
7. El certificado se exportó correctamente.
8. El certificado exportado tiene un aspecto similar al siguiente:

9. Si abre el certificado exportado mediante el Bloc de notas, verá algo parecido a este ejemplo. La sección
en azul contiene la información que se carga en Azure. Si abre el certificado con el Bloc de notas y no se
parece a este, normalmente eso significa que no lo exportó mediante el formato X.509 codificado base
64 (. CER). Además, si desea utilizar un editor de texto diferente, debe comprender que algunos editores
pueden introducir formatos no deseados en segundo plano. Esto puede crear problemas al cargar el texto
de este certificado en Azure.
El archivo exported.cer debe cargarse en Azure. Para ver las instrucciones, consulte Configuración de una
conexión de punto a sitio. Para agregar un certificado raíz de confianza adicional, vea esta sección del artículo.
Exportación del certificado autofirmado y clave privada para almacenarlo (opcional)
Puede que desee exportar el certificado autofirmado y almacenarlo de manera segura. Si es necesario, más
adelante puede instalarlo en otro equipo y generar más certificados de cliente o exportar otro archivo .cer. Para
exportar el certificado raíz autofirmado como archivo .pfx, seleccione el certificado raíz y use los mismos pasos
descritos en Exportación de un certificado de cliente.
Creación e instalación de certificados de cliente

No instale el certificado autofirmado directamente en el equipo cliente. Debe generar un certificado de cliente a
partir del certificado autofirmado. Luego, el certificado de cliente se exporta e instala en el equipo cliente. Los
siguientes pasos no son específicos del modelo de implementación. Son válidos para el Administrador de
recursos y la versión clásica.
certificado de cliente. Puede generarlo desde un certificado raíz autofirmado y, luego, exportar e instalar el
certificado de cliente. Si no está instalado el certificado de cliente, se produce un error de autenticación.
Los pasos siguientes lo llevan por el proceso de generación de un certificado de cliente a partir de un certificado
autofirmado. Puede generar varios certificados de cliente desde el mismo certificado raíz. Al generar
certificados de cliente mediante los pasos siguientes, el certificado de cliente se instala automáticamente en el
equipo que se usó para generar el certificado. Si desea instalar un certificado de cliente en otro equipo cliente,
puede exportar el certificado.
1. En el mismo equipo que usó para crear el certificado autofirmado, abra un símbolo del sistema como
administrador.
2. Modifique y ejecute el ejemplo para generar un certificado de cliente.
Cambie "P2SRootCert" por el nombre del certificado raíz autofirmado desde el que genera el
certificado de cliente. Asegúrese de que esté usando el nombre del certificado raíz, que será el valor
de CN= que especificó cuando creó el certificado raíz autofirmado.
Cambie P2SChildCert por el nombre con el cual desea generar un certificado de cliente.
Si ejecuta el mismo ejemplo sin modificarlo, el resultado es un certificado de cliente denominado
P2SChildcert en el almacén de certificados personal que se generó a partir del certificado raíz
P2SRootCert.
makecert.exe -n "CN=P2SChildCert" -pe -sky exchange -m 96 -ss My -in "P2SRootCert" -is my -a sha256
Exportación de un certificado de cliente

Al generar un certificado de cliente, se instala automáticamente en el equipo que usó para generarlo. Si desea
instalar el certificado de cliente en otro equipo cliente, debe exportar el certificado de cliente que ha generado.
1. Para exportar un certificado de cliente, abra Administrar cer tificados de usuario . De forma
predeterminada, los certificados de cliente que ha generado se encuentran en "Certificates - Current
User\Personal\Certificates". Haga clic con el botón derecho en el certificado de cliente que desee exportar
y haga clic en Todas las tareas y en Expor tar para abrir el Asistente para expor tar cer tificados .
2. En Asistente para exportar certificados, haga clic en Siguiente para continuar.

3. Seleccione Expor tar la clave privada y, después, haga clic en Siguiente .
4. En la página Formato de archivo de expor tación , deje seleccionados los valores predeterminados.
Asegúrese de que Incluir todos los cer tificados en la ruta de cer tificación si es posible esté
seleccionada. Esta opción también exporta la información del certificado raíz que se requiere para una
autenticación correcta del cliente. Sin ella, se produce un error de autenticación del cliente porque este no
tiene el certificado raíz de confianza. A continuación, haga clic en Siguiente .
5. En la página Seguridad , debe proteger la clave privada. Si decide usar una contraseña, asegúrese de
anotarla o de recordar la contraseña que estableció para este certificado. A continuación, haga clic en
Siguiente .
Instalación de un certificado de cliente exportado

Para instalar un certificado de cliente, consulte Instalación de un certificado de cliente.
Pasos siguientes
Continúe con la configuración de punto a sitio.
Para conocer los pasos del modelo de implementación de Resource Manager , consulte cómo configurar
una conexión de punto a sitio mediante la autenticación de certificados de Azure nativa.
Para ver los pasos del modelo de implementación clásica , consulte el artículo Configuración de una
conexión VPN de punto a sitio a una red virtual mediante el Portal clásico.
sitio de Azure.
Generación y exportación de certificados
cómo crear un certificado raíz autofirmado y generar certificados de cliente con la CLI de Linux y strongSwan. Si
busca otras instrucciones de certificado, vea los artículos sobre Powershell o MakeCert. Para obtener
información sobre cómo instalar strongSwan mediante la GUI en lugar de la CLI, vea los pasos descritos en el
artículo Configuración del cliente.
Instalación de strongSwan
La siguiente configuración se usó para los pasos siguientes:
Equipo: Ubuntu Server 18.04
Dependencias: strongSwan
Ejecute los comandos siguientes para instalar la configuración necesaria de strongSwan:
sudo apt install strongswan
sudo apt install strongswan-pki
sudo apt install libstrongswan-extra-plugins
Use el siguiente comando para instalar la interfaz de la línea de comandos de Azure:
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
Instrucciones adicionales sobre cómo instalar la CLI de Azure
Generación y exportación de certificados

Genere el certificado de entidad de certificación.
ipsec pki --gen --outform pem > caKey.pem

ipsec pki --self --in caKey.pem --dn "CN=VPN CA" --ca --outform pem > caCert.pem
Imprima el certificado de entidad de certificación en formato base64. Es el formato compatible con Azure.
Cargue este certificado en Azure como parte de los pasos de configuración de P2S.
openssl x509 -in caCert.pem -outform der | base64 -w0 ; echo
Genere el certificado de usuario.

export PASSWORD="password"
export USERNAME="client"
ipsec pki --gen --outform pem > "${USERNAME}Key.pem"

ipsec pki --pub --in "${USERNAME}Key.pem" | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn
"CN=${USERNAME}" --san "${USERNAME}" --flag clientAuth --outform pem > "${USERNAME}Cert.pem"
Genere un paquete p12 que contengan el certificado de usuario. Este conjunto de productos se usará en los
pasos siguientes cuando se trabaje con los archivos de configuración de cliente.
openssl pkcs12 -in "${USERNAME}Cert.pem" -inkey "${USERNAME}Key.pem" -certfile caCert.pem -export -out
"${USERNAME}.p12" -password "pass:${PASSWORD}"
Pasos siguientes
Continúe con la configuración de punto a sitio para crear e instalar archivos de configuración de cliente de VPN.
Instalación de un certificado de cliente para
conexiones de punto a sitio con autenticación de
certificados
Todos los clientes que se conectan a una red virtual mediante la autenticación de certificados de Azure de
conexiones de punto a sitio requieren un certificado de cliente. Este artículo le ayuda a instalar un certificado de
cliente que se usa para la autenticación cuando se conecta a una red virtual mediante una conexión de punto a
sitio.
Adquisición de un certificado de cliente

Independientemente del sistema operativo cliente al que quiera conectarse, debe tener siempre un certificado
de cliente. Puede generar un certificado de cliente desde un certificado raíz que se ha generado mediante una
solución de una entidad de certificación empresarial o desde un certificado raíz autofirmado. Vea las
instrucciones de PowerShell, MakeCert o Linux para saber los pasos para generar un certificado de cliente.
Windows
1. Busque el archivo .pfx y cópielo en el equipo cliente. En el equipo cliente, haga doble clic en el archivo .pfx
para instalarlo. Deje Ubicación del almacén como Usuario actual y seleccione Siguiente .
2. En la página File to impor t (Archivo para importar), no haga ningún cambio. Seleccione Siguiente .
3. En la página Protección de clave privada , escriba la contraseña del certificado o compruebe que la
entidad de seguridad sea correcta y seleccione Siguiente .
4. En la página Almacén de cer tificados , deje la ubicación predeterminada y seleccione Siguiente .
5. Seleccione Finalizar . En la adver tencia de seguridad para la instalación de certificados, seleccione Sí .
Puede seleccionar con total tranquilidad el valor "Sí" en esta advertencia de seguridad, ya que ha generado el
certificado.
6. El certificado se importó correctamente.
Mac
NOTE
Los clientes VPN de Mac son compatibles únicamente con el modelo de implementación de Resource Manager. No son
compatibles con el modelo de implementación clásica.
Al instalar un certificado de cliente, necesita la contraseña que se creó cuando se exportó el certificado de
cliente.
1. Busque el archivo de certificado .pfx y cópielo en el equipo Mac. Puede obtener el certificado para el
equipo Mac de varias maneras, por ejemplo, puede enviar por correo electrónico el archivo de certificado.
2. Después de copiar el certificado al equipo Mac, haga doble clic en el certificado para abrir el cuadro
Agregar cer tificados y haga clic en Agregar para comenzar la instalación.
3. Escriba la contraseña que creó cuando se exportó el certificado de cliente. La contraseña protege la clave
privada del certificado. Haga clic en Aceptar para completar la instalación.
Linux
El certificado de cliente de Linux se instala en el cliente como parte de la configuración del cliente. Vea Client
configuration - Linux (Configuración de cliente: Linux) para obtener instrucciones.
Pasos siguientes
Continúe con los pasos de configuración de punto a sitio en Creación e instalación de los archivos de
configuración de cliente de VPN.
Creación e instalación de archivos de configuración
de cliente VPN para configuraciones de punto a
sitio con autenticación con certificados nativos de
Azure
Los archivos de configuración de cliente VPN están contenidos en un archivo zip. Estos archivos proporcionan la
configuración necesaria para que un cliente VPN nativo de Windows, Mac IKEv2 o Linux se conecte a una red
virtual mediante una conexión de punto a sitio que use la autenticación con certificados de Azure nativa.
Los archivos de configuración de cliente son específicos de la configuración de VPN para la red virtual. Si
después de generar el perfil de configuración de cliente VPN hay algún cambio en la configuración de VPN de
punto a sitio, como el tipo de protocolo de VPN o de autenticación, debe generar archivos de configuración de
cliente VPN nuevos en los dispositivos de los usuarios.
Para más información sobre las conexiones de punto a sitio, consulte Acerca de las conexiones VPN de punto
a sitio.
Para obtener instrucciones OpenVPN, consulte Configuración de OpenVPN para la puerta de enlace de VPN
de punto a sitio de Azure (versión preliminar) y Configuración de los clientes OpenVPN.
IMPORTANT
Generación de los archivos de configuración de cliente VPN

Antes de comenzar, asegúrese de que todos los usuarios que se vayan a conectar tienen un certificado válido
instalado en el dispositivo del usuario. Para más información acerca de cómo instalar un certificado de cliente,
consulte el artículo sobre la instalación de certificados de cliente.
Para generar archivos de configuración de cliente, puede usar PowerShell o Azure Portal. Cualquiera de los
métodos devuelve el mismo archivo ZIP. Descomprima el archivo para ver las siguientes carpetas:
WindowsAmd64 y WindowsX86 , que contienen los paquetes del instalador de Windows de 32 y 64 bits,
respectivamente. El paquete del instalador WindowsAmd64 es para todos los clientes de Windows de 64
bits, no solo de AMD.
La carpeta Genérico contiene información general que usará para crear su propia configuración de cliente
VPN, La carpeta Genérico se proporciona si se ha configurado la opción IKEv2 o SSTP + IKEv2 en la puerta de
enlace. Si solo se ha configurado SSTP, la carpeta Genérico no aparece.
Generación de archivos mediante Azure Portal
1. En Azure Portal, navegue a la puerta de enlace de red virtual correspondiente a la red virtual a la que
desea conectarse.
2. En la página de la puerta de enlace de red virtual, seleccione Configuración de punto a sitio .
3. En la parte superior de la página Configuración de punto a sitio, haga clic en Descargar cliente VPN . La
generación del paquete de configuración del cliente tarda unos minutos.
4. El explorador indica que hay disponible un archivo ZIP de configuración del cliente. Tiene el mismo
nombre que su puerta de enlace. Descomprima el archivo para ver las carpetas.
Generación de archivos mediante PowerShell
1. Al generar archivos de configuración de cliente VPN, el valor de "-AuthenticationMethod" es "EapTIs".
Genere los archivos de configuración de cliente VPN con el comando siguiente:
$profile=New-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" -

AuthenticationMethod "EapTls"
2. Copie la dirección URL en el explorador para descargar el archivo ZIP y, luego, descomprima el archivo
para ver las carpetas.
Windows
que la versión coincida con la arquitectura del cliente. Para la lista de sistemas operativos de cliente compatibles,
consulte la sección de punto a sitio de las preguntas más frecuentes sobre la puerta de enlace de VPN.
NOTE
Debe tener derechos de administrador en el equipo cliente de Windows desde el que desea conectarse.
"VpnClientSetupAmd64". En caso de que sea de 32 bits, elija el paquete del instalador "VpnClientSetupX86".
2. Haga doble clic en el paquete para instalarlo. Si ve una ventana emergente de SmartScreen, haga clic en Más
información y en Ejecutar de todas formas .
3. En el equipo cliente, vaya a Configuración de red y haga clic en VPN . La conexión VPN muestra el nombre
4. Antes de intentar conectarse, compruebe que ha instalado un certificado de cliente en el equipo cliente. Es
necesario un certificado de cliente para la autenticación al usar el tipo de autenticación de certificados nativo
de Azure.
Mac (OS X)
Tendrá que configurar manualmente el cliente de VPN nativo IKEv2 en cada equipo Mac que se conecte a Azure.
Azure no proporciona el archivo mobileconfig para realizar la autenticación de certificados nativa de Azure. La
carpeta Generic contiene toda la información que necesita para la configuración. Si no ve la carpeta Genérico
en la descarga, es posible que IKEv2 no se haya seleccionado como tipo de túnel. Tenga en cuenta que la SKU de
nivel Básico de VPN Gateway no admite IKEv2. Una vez que se seleccione IKEv2, vuelva a generar el archivo ZIP
para recuperar la carpeta Genérico.
que son los archivos siguientes:
VpnSettings.xml , con configuración importante, como el tipo de túnel y la dirección del servidor.
VpnSer verRoot.cer , con el certificado raíz necesario para validar la puerta de enlace de VPN de Azure
durante la instalación de la conexión de punto a sitio.
Siga los pasos siguientes para configurar el cliente de VPN nativo en equipos Mac para realizar una
autenticación mediante certificado. Deberá completar estos pasos en cada equipo Mac que se conecte a Azure:
1. Importe el certificado raíz VpnSer verRoot en Mac. Para ello, sobreescriba el archivo en Mac y haga
doble clic en él. Seleccione Agregar para importarlo.
NOTE
Al hacer doble clic en el certificado, es posible que no se muestre el cuadro de diálogo Agregar , pero el certificado
se instalará en la tienda correcta. Puede buscar el certificado en la cadena de claves de inicio de sesión en la
categoría de certificados.
2. Compruebe que ha instalado un certificado de cliente emitido por el certificado raíz que cargó en Azure
cuando estableció la configuración de P2S. Es diferente al VPNServerRoot que instaló en el paso anterior.
Se necesita y se usa un certificado de cliente para la autenticación. Para más información acerca de cómo
generar certificados, consulte Generación de certificados. Para obtener información acerca de cómo
instalar un certificado de cliente, consulte Instalación de certificados de cliente.
3. Abra el cuadro de diálogo Red en Preferencias de red y seleccione "+" para crear un nuevo perfil de
conexión de cliente VPN para establecer una conexión de punto a sitio a la red virtual de Azure.
El valor de Interfaz es "VPN" y el de Tipo de VPN es "IKEv2". Especifique un nombre para el perfil en el
campo Nombre del ser vicio y seleccione Crear para crear el perfil de conexión de cliente VPN.
4. En la carpeta Genérico , en el archivo VpnSettings.xml , copie el valor de la etiqueta VpnSer ver . Pegue
este valor en los campos Dirección del ser vidor e Id. remoto del perfil.
5. Seleccione Configuración de autenticación y Cer tificado . Para Catalina , seleccione Ninguno y

luego Cer tificado .
Para Catalina, seleccione Ninguno y luego Cer tificado . Seleccione el certificado correcto:
6. Haga clic en Seleccionar... para elegir el certificado de cliente que quiere usar en la autenticación. Este es
el certificado que instaló en el paso 2.
7. En Choose An Identity (Elegir una identidad) se muestra una lista de certificados para elegir. Seleccione
el certificado adecuado y luego Continuar .
8. En el campo Id. local , especifique el nombre del certificado (del paso 6). En este ejemplo, es
ikev2Client.com . A continuación, seleccione Aplicar para guardar los cambios.
9. En el cuadro de diálogo Red , seleccione Aplicar para guardar los cambios. A continuación, seleccione
Conectar para iniciar la conexión de punto a sitio a la red virtual de Azure.
Linux (GUI de StrongSwan)



Si aún no ha generado certificados, siga estos pasos:


Instalación y configuración
Las siguientes instrucciones se crearon en Ubuntu 18.0.4. Ubuntu 16.0.10 no admite la GUI de strongSwan. Si
desea usar Ubuntu 16.0.10, deberá usar la línea de comandos. Los ejemplos siguientes pueden no coincidir con
las pantallas que ve, en función de la versión de Linux y strongSwan que tenga.
1. Abra la herramienta Terminal para instalar strongSwan y su Network Manager (Administrador de red)
ejecutando el comando del ejemplo.
sudo apt install network-manager-strongswan
2. Seleccione Configuración y, a continuación, seleccione Red . Seleccione el botón + para crear una
conexión.
3. Seleccione IPsec/IKEv2 (strongSwan) en el menú y haga doble clic.
4. En la página Add VPN (Agregar VPN), agregue un nombre para la conexión VPN.
5. Abra el archivo VpnSettings.xml de la carpeta Generic (Genérico) que está incluida en los archivos de
configuración de cliente descargados. Busque la etiqueta denominada VpnSer ver y copie el nombre, que
comienza con "azuregateway" y termina con ".cloudapp.net".
6. Pegue este nombre en el campo Address (Dirección) de la nueva conexión VPN de la sección Gateway
(Puerta de enlace). Luego, seleccione el icono de carpeta al final del campo Cer tificate (Certificado), vaya
a la carpeta Generic (Genérico) y seleccione el archivo VpnSer verRoot .
7. En la sección Client (Cliente) de la conexión, para Authentication (Autenticación), seleccione
Cer tificate/private key (Certificado/clave privada). En Cer tificate (Certificado) y Private key (Clave
privada), elija el certificado y la clave privada que se crearon anteriormente. En Options (Opciones),
seleccione Request an inner IP address (Solicitar una dirección IP interna). Después, seleccione
Agregar .
8. Ajuste la conexión en Activado .

Linux (CLI de StrongSwan)

Si aún no ha generado certificados, siga estos pasos:

Instalar y configurar
1. Descargue el paquete de VPNClient desde Azure Portal.
2. Extrae el archivo.
3. Desde la carpeta Generic , copie o mueva VpnSer verRoot.cer a /etc/ipsec.d/cacer ts .
4. Copie o mueva cp client.p12 a /etc/ipsec.d/private/ . Este archivo es un certificado de cliente para la
puerta de enlace de VPN.
5. Abra el archivo VpnSettings.xml y copie el valor <VpnServer> . Usará este valor en el paso siguiente.
6. Ajuste los valores en el ejemplo siguiente y después agregue el ejemplo a la configuración de
/etc/ipsec.conf .
conn azure
keyexchange=ikev2
type=tunnel
leftfirewall=yes
left=%any
leftauth=eap-tls
leftid=%client # use the DNS alternative name prefixed with the %
right= Enter the VPN Server value here# Azure VPN gateway address
rightid=% # Enter the VPN Server value here# Azure VPN gateway FQDN with %
rightsubnet=0.0.0.0/0
leftsourceip=%config
auto=add
7. Agregue los siguientes valores a /etc/ipsec.secrets .
: P12 client.p12 'password' # key filename inside /etc/ipsec.d/private directory

8. Ejecute los comandos siguientes:
# ipsec restart
# ipsec up azure
Pasos siguientes
Vuelva al artículo original desde el que estaba trabajando y, después, complete la configuración de punto a sitio.
Pasos de configuración de PowerShell.
Pasos de configuración de Azure Portal.
Configuración de una conexión de punto a sitio a
una red virtual con autenticación RADIUS:
PowerShell
Este artículo muestra cómo crear una red virtual con conexión de punto a sitio que usa la autenticación RADIUS.
Esta configuración solo está disponible para el modelo de implementación de Resource Manager.
Una puerta de enlace de VPN de punto a sitio (P2S) permite crear una conexión segura a la red virtual desde un
equipo cliente individual. Las conexiones VPN de punto a sitio resultan útiles cuando quiere conectarse a la red
virtual desde una ubicación remota; por ejemplo, cuando realiza teletrabajo desde casa o desde una conferencia.
Una VPN P2S también es una solución útil en lugar de una VPN de sitio a sitio cuando hay solo unos pocos
clientes que necesitan conectarse a una red virtual.
Una conexión VPN de punto a sitio se inicia desde dispositivos Windows y Mac. Al conectarse, los clientes
pueden usar los siguientes métodos de autenticación:
Servidor RADIUS
Autenticación mediante certificados nativos de puerta de enlace de VPN
Autenticación nativa de Azure Active Directory (solo Windows 10)
Este artículo le ayuda a establecer una configuración de punto a sitio con autenticación mediante el servidor
RADIUS. Si desea una autenticación mediante certificados generados y una autenticación mediante certificados
nativos de puerta de enlace de VPN en su lugar, consulte el artículo Configure una conexión VPN de punto a
sitio a una red virtual mediante la autenticación nativa de los certificados de Azure: PowerShell o Creación de un
inquilino de Azure Active Directory para conexiones del protocolo P2S OpenVPN para la autenticación de Azure
Active Directory.
Las conexiones de punto a sitio no requieren un dispositivo VPN ni una dirección IP de acceso público. P2S crea
la conexión VPN sobre SSTP (Protocolo de túnel de sockets seguros), OpenVPN o IKEv2.
SSTP es un túnel VPN basado en TLS que solo se admite en plataformas de cliente Windows. Puede
traspasar firewalls, por lo que resulta ideal para conectarse a Azure desde cualquier lugar. En el lado
servidor, se admiten las versiones 1.0, 1.1 y 1.2 de SSTP. El cliente decide qué versión va a usar. Para
Windows 8.1 y versiones posteriores, SSTP usa 1.2 de forma predeterminada.
Protocolo OpenVPN®, un protocolo VPN basado en SSL/TLS. Una solución de VPN basada en TLS
puede penetrar firewalls, puesto que la mayoría de ellos abre el puerto TCP 443 saliente, que usa TLS.
Las conexiones P2S requieren lo siguiente:
Un servidor RADIUS para controlar la autenticación de los usuarios. El servidor RADIUS puede
implementarse de forma local o en la red virtual de Azure. También puede configurar dos servidores RADIUS
para la alta disponibilidad.
Un paquete de configuración de cliente VPN para los dispositivos Windows que se conectarán a la red
virtual. Un paquete de configuración de cliente VPN proporciona la configuración necesaria para que un
cliente de VPN realice una conexión de punto a sitio.
Acerca de la autenticación de dominio de Active Directory (AD) para

VPN de punto a sitio
La autenticación de dominio de AD permite a los usuarios iniciar sesión en Azure con sus credenciales de
dominio de la organización. Requiere un servidor RADIUS que se integre con el servidor de AD. Las
organizaciones también pueden aprovechar las implementaciones existentes de RADIUS.
El servidor RADIUS puede ser local o encontrarse en la red virtual de Azure. Durante la autenticación, la puerta
de enlace de VPN actúa como acceso directo y reenvía los mensajes de autenticación entre el servidor RADIUS y
el dispositivo que se conecta. Es importante que la puerta de enlace de VPN se pueda comunicar con el servidor
RADIUS. Si el servidor RADIUS es local, se necesita una conexión VPN de sitio a sitio de Azure al sitio local.
Además de con Active Directory, los servidores RADIUS también se integran con otros sistemas de identidad
externos. Esto abre una gran cantidad de opciones de autenticación para VPN de punto a sitio, incluidas las
opciones multifactor. Compruebe la documentación del proveedor del servidor RADIUS para obtener la lista de
sistemas de identidad con los que se integra.
IMPORTANT
Para un servidor RADIUS local solo se puede usar una conexión VPN de sitio a sitio. No se puede usar una conexión
ExpressRoute.
Antes de comenzar
Azure PowerShell.
Valores del ejemplo
Puede usar los valores del ejemplo para crear un entorno de prueba o hacer referencia a ellos para comprender
mejor los ejemplos de este artículo. Puede utilizar los pasos como un tutorial y utilizar los valores sin cambiarlos
o modificarlos para reflejar su entorno.
Nombre: VNet1
Espacio de direcciones: 192.168.0.0/16 y 10.254.0.0/16
En este ejemplo, se utiliza más de un espacio de direcciones para ilustrar que esta configuración funciona con
varios. Sin embargo, para esta configuración no se necesitan varios espacios de direcciones.
Nombre de subred: BackEnd
Nombre de subred: GatewaySubnet
El nombre de subred GatewaySubnet es obligatorio para que VPN Gateway funcione.
Inter valo de direcciones de GatewaySubnet: 192.168.200.0/24
Grupo de direcciones de clientes de VPN: 172.16.201.0/24
dirección IP del grupo de clientes de VPN.
Grupo de recursos: TestRG
Ser vidor DNS: dirección IP del servidor DNS que desea usar para la resolución de nombres en la red
virtual (opcional).
Nombre de puer ta de enlace: Vnet1GW
Nombre IP pública: VNet1GWPIP
VpnType: RouteBased
1. Establecimiento de las variables

Declare las variables que desea utilizar. Use el ejemplo siguiente y sustituya los valores por los suyos propios
cuando sea necesario. Si cierra la sesión de PowerShell/Cloud Shell en cualquier momento durante el ejercicio,
copie y pegue los valores de nuevo para volver a declarar las variables.
$VNetName = "VNet1"
$BESubName = "Backend"
$VNetPrefix1 = "192.168.0.0/16"
$VNetPrefix2 = "10.254.0.0/16"
$FESubPrefix = "192.168.1.0/24"
$BESubPrefix = "10.254.1.0/24"
$GWSubPrefix = "192.168.200.0/26"
$RG = "TestRG"
$GWName = "VNet1GW"
$GWIPName = "VNet1GWPIP"
2.
Creación del grupo de recursos, la red virtual y la dirección IP pública
Los pasos siguientes sirven para crear un grupo de recursos y una red virtual en el grupo de recursos con tres
subredes. Al reemplazar valores, es importante que siempre asigne el nombre "GatewaySubnet" a la subred de
la puerta de enlace. Si usa otro, se produce un error al crear la puerta de enlace.
New-AzResourceGroup -Name "TestRG" -Location "East US"
2. Cree las configuraciones de subred para la red virtual con los nombres FrontEnd, BackEnd y
GatewaySubnet. Estos prefijos deben formar parte del espacio de direcciones de la red virtual que
declaró anteriormente.
$fesub = New-AzVirtualNetworkSubnetConfig -Name "FrontEnd" -AddressPrefix "192.168.1.0/24"

$besub = New-AzVirtualNetworkSubnetConfig -Name "Backend" -AddressPrefix "10.254.1.0/24"
$gwsub = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix "192.168.200.0/24"
3. Creación de la red virtual.

En este ejemplo, el parámetro del servidor -DnsServer es opcional. La especificación de un valor no crea
un servidor DNS nuevo. La dirección IP del servidor DNS que especifique debe ser un servidor DNS que
pueda resolver los nombres de los recursos a los que se conecta desde la red virtual. En este ejemplo, se
usa una dirección IP privada, pero es probable que no sea la dirección IP del servidor DNS. Asegúrese de
utilizar sus propios valores. El valor especificado lo utilizan los recursos que se implementan en la red
virtual, no la conexión de punto a sitio.
New-AzVirtualNetwork -Name "VNet1" -ResourceGroupName "TestRG" -Location "East US" -AddressPrefix
"192.168.0.0/16","10.254.0.0/16" -Subnet $fesub, $besub, $gwsub -DnsServer 10.2.1.3
4. Una puerta de enlace VPN debe tener una dirección IP pública. Primero se solicita el recurso de la
dirección IP y, después, se hace referencia a él al crear la puerta de enlace de red virtual. La dirección IP se
asigna dinámicamente al recurso cuando se crea la puerta de enlace VPN. Actualmente, VPN Gateway
solo admite la asignación de direcciones IP públicas dinámicas. No se puede solicitar una asignación de
direcciones IP públicas estáticas. 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 la dirección IP pública cambia es
cuando la puerta de enlace se elimina y se vuelve a crear. No cambia cuando se cambia el tamaño, se
restablece o se realizan actualizaciones u otras operaciones de mantenimiento interno de una puerta de
enlace VPN.
Especifique las variables para solicitar una dirección IP pública asignada de forma dinámica.
$vnet = Get-AzVirtualNetwork -Name "VNet1" -ResourceGroupName "TestRG"

$subnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
$pip = New-AzPublicIpAddress -Name "VNet1GWPIP" -ResourceGroupName "TestRG" -Location "East US" -
$ipconf = New-AzVirtualNetworkGatewayIpConfig -Name "gwipconf" -Subnet $subnet -PublicIpAddress $pip
3.
Configuración del servidor RADIUS
Antes de crear y configurar la puerta de enlace de red virtual, el servidor RADIUS debe configurarse
correctamente para la autenticación.
1. Si no tiene un servidor RADIUS implementado, implemente uno. Para los pasos de implementación, consulte
la guía de instalación que proporciona el proveedor de RADIUS.
2. Configure la puerta de enlace de VPN como cliente RADIUS en RADIUS. Al agregar a este cliente RADIUS,
especifique la red virtual GatewaySubnet que ha creado.
3. Una vez configurado el servidor RADIUS, obtenga su dirección IP y el secreto compartido que deben usar los
clientes RADIUS para comunicarse con él. Si el servidor RADIUS está en la red virtual de Azure, use la
dirección IP de entidad de certificación de la máquina virtual del servidor RADIUS.
El artículo Servidor de directivas de redes (NPS) proporciona instrucciones acerca de cómo configurar un
servidor Windows RADIUS (NPS) para la autenticación de dominio de AD.
4.
Configure y cree la puerta de enlace de VPN para la red virtual.
-GatewayType debe ser "Vpn" y -VpnType, "RouteBased".
Una puerta de enlace de VPN puede tardar hasta 45 minutos en completarse, según la SKU de puerta de
enlace que seleccione.

-Location $Location -IpConfigurations $ipconf -GatewayType Vpn `
-VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw1
5.
Incorporación del servidor RADIUS y el grupo de direcciones de
cliente
El valor de -RadiusServer se puede especificar por nombre o por dirección IP. Si se especifica el nombre y el
servidor es local, quizá la puerta de enlace de VPN no pueda resolver el nombre. Si es el caso, lo mejor es
especificar la dirección IP del servidor.
El valor de -RadiusSecret debe coincidir con la configuración del servidor RADIUS.
-VpnClientAddressPool es el intervalo del que reciben una dirección IP los clientes al conectarse a la VPN.
Use un intervalo de direcciones IP privadas que no se superponga a la ubicación local desde la que se va a
conectar ni a la red virtual a la que desea conectarse. Asegúrese de que tiene configurado un grupo de
direcciones lo suficientemente grande.
1. Cree una cadena segura para el secreto de RADIUS.
$Secure_Secret=Read-Host -AsSecureString -Prompt "RadiusSecret"
2. Deberá escribir el secreto de RADIUS. Los caracteres que especifique no se mostrarán, sino que se
reemplazarán por el carácter "*".
RadiusSecret:***
3. Agregue el grupo de direcciones de cliente VPN y la información del servidor RADIUS.

Para configuraciones SSTP:

-VpnClientAddressPool "172.16.201.0/24" -VpnClientProtocol "SSTP" `
-RadiusServerAddress "10.51.0.15" -RadiusServerSecret $Secure_Secret
Para configuraciones OpenVPN®:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $Gateway -VpnClientRootCertificates @()
-VpnClientAddressPool "172.16.201.0/24" -VpnClientProtocol "OpenVPN" `
Para configuraciones IKEv2:

-VpnClientAddressPool "172.16.201.0/24" -VpnClientProtocol "IKEv2" `
Para SSTP + IKEv2

-VpnClientAddressPool "172.16.201.0/24" -VpnClientProtocol @( "SSTP", "IkeV2" ) `
Para especificar dos servidores RADIUS use la siguiente sintaxis. Modifique el valor de -
VpnClientProtocol según sea necesario.
$radiusServer1 = New-AzRadiusServer -RadiusServerAddress 10.1.0.15 -RadiusServerSecret $radiuspd -

RadiusServerScore 30
$radiusServer2 = New-AzRadiusServer -RadiusServerAddress 10.1.0.16 -RadiusServerSecret $radiuspd -
RadiusServerScore 1
$radiusServers = @( $radiusServer1, $radiusServer2 )
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $actual -VpnClientAddressPool 201.169.0.0/16 -

VpnClientProtocol "IkeV2" -RadiusServerList $radiusServers
6.
Descarga del paquete de configuración de cliente VPN y
configuración del cliente VPN
La configuración del cliente VPN permite que los dispositivos se conecten a una red virtual mediante una
conexión de punto a sitio. Para generar un paquete de configuración de cliente VPN y configurar el cliente de
VPN, consulte Create a VPN Client Configuration for RADIUS authentication (Creación de la configuración de
cliente de VPN para la autenticación RADIUS).
7. Conexión con Azure

Para conectarse desde un cliente VPN en Windows
1. Para conectarse a su red virtual, en el equipo cliente, vaya a las conexiones VPN y ubique la que creó.
Tiene el mismo nombre que su red virtual. Escriba sus credenciales de dominio y haga clic en "Conectar".
Aparece un mensaje emergente que solicita derechos elevados. Haga clic en Aceptar y escriba las
credenciales.
Conexión desde un cliente VPN en Mac
En el cuadro de diálogo Red, localice el perfil de cliente que desea utilizar y, después, haga clic en Conectar .
Para comprobar la conexión

PPP adapter VNet1:

DHCP Enabled....................: No
Subnet Mask.....................: 255.255.255.255
Para solucionar problemas de conexión de P2S, vea Solución de problemas: conexión de punto a sitio de Azure.

$VMs = Get-AzVM
{
}
P+F
Estas preguntas más frecuentes se aplican a la conexión de punto a sitio con autenticación RADIUS
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

Sí, se admiten.
Pasos siguientes
Creación e instalación de archivos de configuración
de cliente VPN para la autenticación P2S RADIUS
Para conectarse de punto a sitio (P2S) a una red virtual, debe configurar el dispositivo cliente desde el que se va
a conectar. Puede crear conexiones VPN de punto a sitio desde dispositivos cliente de Windows, OS X y Linux.
Con la autenticación RADIUS existen varias opciones de autenticación, por ejemplo, la autenticación con nombre
de usuario y contraseña y mediante certificados. La configuración de cliente VPN es diferente para cada tipo de
autenticación. Para configurar el cliente VPN, use los archivos de configuración de cliente que contienen la
configuración necesaria. En este artículo se ayuda a crear e instalar la configuración de cliente VPN para el tipo
de autenticación RADIUS que se quiere usar.
IMPORTANT
El flujo de trabajo de configuración de la autenticación P2S RADIUS es el siguiente:

1. Configure la puerta de enlace de VPN de Azure para la conectividad P2S.
2. Configure el servidor RADIUS para la autenticación.
3. Obtenga la configuración de cliente VPN correspondiente a la opción de autenticación que
prefiera y úsela para configurar el cliente VPN (este artículo).
4. Complete la configuración de P2S y conéctese.
IMPORTANT
Si después de generar el perfil de configuración de cliente VPN hay algún cambio en la configuración de VPN de punto a
sitio, como el tipo de protocolo de VPN o el tipo de autenticación, debe generar e instalar una nueva configuración de
cliente VPN en los dispositivos de los usuarios.
Para usar las secciones de este artículo, decida primero el tipo de autenticación que quiere usar: nombre de
usuario y contraseña, certificado o de otro tipo. En cada sección hay pasos para Windows, OS X y Linux (pasos
limitados disponibles en este momento).
Autenticación con nombre de usuario y contraseña

Puede configurar la autenticación con nombre de usuario y contraseña para usar Active Directory o no usarlo.
Asegúrese de que todos los usuarios que se conectan tengan credenciales de nombre de usuario y contraseña
que se puedan autenticar mediante RADIUS.
Al configurar la autenticación de nombre de usuario y contraseña, solo se puede crear una configuración para el
protocolo de autenticación de nombre de usuario y contraseña EAP-MSCHAPv2. En los comandos,
-AuthenticationMethod es EapMSChapv2 .
1. Generación de archivos de configuración de cliente VPN
Puede generar los archivos de configuración del cliente VPN a través de Azure Portal o de Azure PowerShell.
Portal de Azure
1. Navegue a la puerta de enlace de red virtual.
2. Haga clic en Configuración de punto a sitio .
3. Haga clic en Descargar cliente VPN .
4. Seleccione el cliente y rellene toda la información que se pide.
5. Haga clic en Descargar para generar el archivo ZIP.
6. Se descargará el archivo ZIP, normalmente en la carpeta Descargas.
Azure PowerShell
Genere archivos de configuración de cliente VPN para usar con la autenticación de nombre de usuario y
contraseña. Genere los archivos de configuración de cliente VPN con el comando siguiente:
New-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" -AuthenticationMethod "EapMSChapv2"
La ejecución del comando devuelve un vínculo. Copie y pegue el vínculo en un explorador web para descargar
VpnClientConfiguration.zip . Descomprima el archivo para ver las siguientes carpetas:
WindowsAmd64 y WindowsX86 : Estas carpetas contienen los paquetes del instalador de Windows de 64
y 32 bits, respectivamente.
Genérico : esta carpeta contiene información general que se usa para crear su propia configuración de
cliente VPN. Esta carpeta no es necesaria para las configuraciones de autenticación con nombre de usuario y
contraseña.
Mac : si configuró IKEv2 al crear la puerta de enlace de red virtual, verá una carpeta llamada Mac con un
archivo mobileconfig . Use este archivo para configurar clientes Mac.
Si ya ha creado los archivos de configuración del cliente, puede recuperarlos con el cmdlet
Get-AzVpnClientConfiguration . Pero si realiza cambios en la configuración de VPN de punto a sitio, como el tipo
de protocolo de VPN o el tipo de autenticación, la configuración no se actualiza automáticamente. Deberá
ejecutar el cmdlet New-AzVpnClientConfiguration para crear otra descarga de configuración.
Para recuperar los archivos de configuración de cliente generados anteriormente, use el comando siguiente:
Get-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW"
2. Configuración de clientes VPN

Puede configurar los clientes VPN siguientes:
Windows
Mac (OS X)
Linux con strongSwan
Configuración de un cliente VPN en Windows
que la versión coincida con la arquitectura del cliente. Para la lista de sistemas operativos cliente compatibles,
consulte las preguntas frecuentes.
VpnClientSetupAmd64 . En caso de que sea de 32 bits, elija el paquete del instalador VpnClientSetupX86 .
2. Haga doble clic en el paquete para instalarlo. Si ve una ventana emergente SmartScreen, seleccione Más
información > Ejecutar de todas formas .
3. En el equipo cliente, vaya a Configuración de red y seleccione VPN . La conexión VPN muestra el nombre
Configuración de un cliente VPN en Mac (OSX)
1. Seleccione el archivo VpnClientSetup mobileconfig y envíelo a cada uno de los usuarios. Para ello,
puede usar el correo electrónico u otro método.
2. Busque el archivo mobileconfig en el equipo Mac.
3. Paso opcional: si desea especificar un DNS personalizado, agregue las líneas siguientes al archivo
mobileconfig :
<key>DNS</key>
<dict>
<key>ServerAddresses</key>
<array>
<string>10.0.0.132</string>
</array>
<key>SupplementalMatchDomains</key>
<array>
<string>TestDomain.com</string>
</array>
</dict>
4. Haga doble clic en el perfil para instalarlo y seleccione Continuar . El nombre del perfil es el mismo que
el de la red virtual.
5. Seleccione Continuar para confiar en el emisor del perfil y proseguir con la instalación.
6. Durante la instalación del perfil, tendrá la opción de especificar el nombre de usuario y la contraseña para
la autenticación de VPN. No es obligatorio especificar esta información. Si lo hace, esta se guarda y se usa
automáticamente al iniciar una conexión. Seleccione Instalar para continuar.
7. Para instalar el perfil en el equipo, escriba un nombre de usuario y una contraseña para los privilegios
necesarios. Seleccione Aceptar .
8. Una vez instalado, el perfil es visible en el cuadro de diálogo Perfiles . Este cuadro de diálogo también se
puede abrir más adelante desde Preferencias del sistema .
9. Para acceder a la conexión VPN, abra el cuadro de diálogo Red en Preferencias del sistema .
10. La conexión VPN se muestra como IkeV2-VPN . El nombre se puede cambiar mediante la actualización
del archivo mobileconfig .
11. Seleccione Configuración de autenticación . Seleccione el nombre de usuario de la lista desplegable

y escriba las credenciales. Si escribió las credenciales anteriormente, el nombre de usuario se elige
automáticamente de la lista y se rellena previamente, junto con la contraseña. Seleccione Aceptar para
guardar la configuración.
12. De nuevo en el cuadro de diálogo Red , seleccione Aplicar para guardar los cambios. Para iniciar la
conexión, seleccione Conectar .
Configuración de un cliente VPN en Linux mediante strongSwan
Las siguientes instrucciones se crearon mediante strongSwan 5.5.1 en Ubuntu 17.0.4. Las pantallas reales
pueden variar en función de la versión de Linux y strongSwan.
1. Abra la herramienta Terminal para instalar strongSwan y su Network Manager (Administrador de red)
ejecutando el comando del ejemplo. Si recibe un error relacionado con libcharon-extra-plugins ,
reemplácelo por strongswan-plugin-eap-mschapv2 .
sudo apt-get install strongswan libcharon-extra-plugins moreutils iptables-persistent network-

manager-strongswan
2. Seleccione el icono Network Manager (Administrador de red) (flecha arriba/flecha abajo) y seleccione
Edit Connections (Editar conexiones).
3. Seleccione el botón Add (Agregar) para crear una conexión.
4. Seleccione IPsec/IKEv2 (strongswan) en el menú desplegable y seleccione Create (Crear). Puede

cambiar el nombre de la conexión en este paso.
5. Abra el archivo VpnSettings.xml de la carpeta Generic (Genérico) de los archivos de configuración de
cliente descargados. Busque la etiqueta denominada VpnServer y copie el nombre que empieza por
azuregateway y termina por .cloudapp.net .
6. Pegue este nombre en el campo Address (Dirección) de la nueva conexión VPN de la sección Gateway
(Puerta de enlace). Luego, seleccione el icono de carpeta al final del campo Cer tificate (Certificado), vaya
a la carpeta Generic (Genérico) y seleccione el archivo VpnSer verRoot .
7. En la sección Client (Cliente) de la conexión, seleccione EAP de Autentication (Autenticación) y escriba
el nombre de usuario y la contraseña. Es posible que tenga que seleccionar el icono de bloqueo de la
derecha para guardar esta información. Después, seleccione Guardar .
8. Seleccione el icono Network Manager (Administrador de red) (flecha arriba/flecha abajo) y mantenga
el puntero sobre VPN Connections (Conexiones VPN). Verá la conexión VPN que ha creado. Para iniciar
la conexión, selecciónela.
Autenticación de certificados
Puede crear archivos de configuración de cliente VPN para la autenticación de certificados RADIUS con el
protocolo EAP-TLS. Normalmente, para autenticar a un usuario en una VPN se usa un certificado emitido por la
empresa. Asegúrese de que todos los usuarios que se conectan tengan instalado un certificado en el dispositivo
y de que el servidor RADIUS pueda validarlo.
NOTE
En los comandos, -AuthenticationMethod es EapTls . Durante la autenticación de certificado, el cliente valida el
servidor RADIUS mediante la validación de su certificado. -RadiusRootCert es el archivo .cer que contiene el
certificado raíz para validar el servidor RADIUS.
Cada dispositivo de cliente VPN requiere tener instalado un certificado de cliente. En ocasiones, un dispositivo
Windows tiene varios certificados de cliente. Como consecuencia, durante la autenticación puede aparecer un
cuadro de diálogo emergente que muestra todos los certificados. El usuario debe elegir el certificado que quiere
usar. Se puede filtrar el certificado correcto mediante la especificación del certificado raíz al que se debe
encadenar el certificado de cliente.
-ClientRootCert es el archivo .cer que contiene el certificado raíz. Es un parámetro opcional. Si el dispositivo
desde el que desea conectarse tiene solo un certificado cliente, no es necesario especificar este parámetro.
1. Generación de archivos de configuración de cliente VPN
Genere archivos de configuración de cliente VPN para usar con la autenticación de certificado. Genere los
archivos de configuración de cliente VPN con el comando siguiente:
New-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" -AuthenticationMethod "EapTls" -

RadiusRootCert <full path name of .cer file containing the RADIUS root> -ClientRootCert <full path name of
.cer file containing the client root> | fl
La ejecución del comando devuelve un vínculo. Copie y pegue el vínculo en un explorador web para descargar el
archivo VpnClientConfiguration.zip. Descomprima el archivo para ver las siguientes carpetas:
WindowsAmd64 y WindowsX86 : Estas carpetas contienen los paquetes del instalador de Windows de 64
y 32 bits, respectivamente.
GenericDevice : esta carpeta contiene información general que se usa para crear su propia configuración de
cliente VPN.
Si ya ha creado los archivos de configuración del cliente, puede recuperarlos con el cmdlet
Get-AzVpnClientConfiguration . Pero si realiza cambios en la configuración de VPN de punto a sitio, como el tipo
de protocolo de VPN o el tipo de autenticación, la configuración no se actualiza automáticamente. Deberá
ejecutar el cmdlet New-AzVpnClientConfiguration para crear otra descarga de configuración.
Para recuperar los archivos de configuración de cliente generados anteriormente, use el comando siguiente:
Get-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" | fl
2. Configuración de clientes VPN

Puede configurar los clientes VPN siguientes:
Windows
Mac (OS X)
Linux (compatible, aún no hay ningún artículo con los pasos)
Configuración de un cliente VPN en Windows
1. Seleccione un paquete de configuración e instálelo en el dispositivo cliente. Si la arquitectura de procesador
es de 64 bits, elija el paquete del instalador VpnClientSetupAmd64 . En caso de que sea de 32 bits, elija el
paquete del instalador VpnClientSetupX86 . Si ve una ventana emergente SmartScreen, seleccione Más
información > Ejecutar de todas formas . También puede guardar el paquete para instalarlo en otros
equipos cliente.
2. Cada equipo cliente debe tener un certificado de cliente para la autenticación. Instale el certificado de cliente.
Para información sobre los certificados de cliente, consulte el artículo sobre los certificados de cliente para
conexiones de punto a sitio. Para instalar un certificado que se ha generado, vea Instalación de un certificado
de cliente para conexiones de punto a sitio con autenticación de certificados de Azure.
3. En el equipo cliente, vaya a Configuración de red y seleccione VPN . La conexión VPN muestra el nombre
Configuración de un cliente VPN en Mac (OSX)
Debe crear un perfil independiente para cada dispositivo Mac que se conecte a la red virtual de Azure. El motivo
es que estos dispositivos requieren que se especifique el certificado de usuario para la autenticación en el perfil.
La carpeta Generic contiene toda la información necesaria para crear un perfil:
VpnSettings.xml contiene valores de configuración importantes, como el tipo de túnel y la dirección de
servidor.
VpnSer verRoot.cer contiene el certificado raíz necesario para validar la puerta de enlace de VPN durante la
configuración de la conexión de punto a sitio.
RadiusSer verRoot.cer contiene el certificado raíz necesario para validar el servidor RADIUS durante la
autenticación.
Siga los pasos a continuación para configurar el cliente VPN nativo en equipos Mac para la autenticación con
certificado:
1. Importe los certificados raíz VpnSer verRoot y RadiusSer verRoot en el equipo Mac. Copie los archivos
en el equipo Mac, haga doble clic en ellos y seleccione Agregar .
2. Cada equipo cliente debe tener un certificado de cliente para la autenticación. Instale el certificado de
cliente en el dispositivo cliente.
3. En Preferencias de red , abra el cuadro de diálogo Red . Seleccione + para crear un nuevo perfil de
conexión de cliente VPN para una conexión de punto a sitio a la red virtual de Azure.
El valor de Interfaz es VPN y el de Tipo de VPN es IKEv2 . Especifique un nombre para el perfil en el
cuadro Nombre del ser vicio y seleccione Crear para crear el perfil de conexión de cliente VPN.
4. En la carpeta Genérico , en el archivo VpnSettings.xml , copie el valor de la etiqueta VpnSer ver . Pegue
este valor en los cuadros Dirección del ser vidor e Id. remoto del perfil. Deje en blanco el cuadro Id.
local .
5. Seleccione Configuración de autenticación y Cer tificado .

6. Haga clic en Seleccionar para elegir el certificado que quiere usar en la autenticación.
7. En Choose An Identity (Elegir una identidad) se muestra una lista de certificados para elegir. Seleccione
el certificado adecuado y Continuar .
8. En el cuadro Id. local , especifique el nombre del certificado (del paso 6). En este ejemplo, es
ikev2Client.com . A continuación, seleccione el botón Aplicar para guardar los cambios.
9. En el cuadro de diálogo Red , seleccione Aplicar para guardar los cambios. A continuación, seleccione
Conectar para iniciar la conexión de punto a sitio a la red virtual de Azure.
Trabajar con otros tipos de autenticación o protocolos

Para usar un tipo de autenticación diferente (por ejemplo, OTP) o un protocolo de autenticación diferente (como
PEAP-MSCHAPv2, en lugar de EAP-MSCHAPv2), debe crear su propio perfil de configuración de cliente VPN.
Para crear el perfil, necesita información como la dirección IP de puerta de enlace de red virtual, el tipo de túnel
y las rutas de túnel dividido. Para obtener esta información, siga estos pasos:
1. Use el cmdlet Get-AzVpnClientConfiguration para generar la configuración de cliente VPN para
EapMSChapv2.
2. Descomprima el archivo VpnClientConfiguration.zip y busque la carpeta GenericDevice . Ignore las
carpetas que contienen los instaladores de Windows para arquitecturas de 64 y 32 bits.
3. La carpeta GenericDevice contiene un archivo XML llamado VpnSettings . Este archivo contiene toda la
información necesaria:
VpnSer ver : nombre de dominio completo de la instancia de Azure VPN Gateway. Es la dirección a la
que se conecta el cliente.
VpnType : tipo de túnel para la conexión.
Rutas : rutas que debe configurar en el perfil para que solo el tráfico enlazado de la red virtual de
Azure se envíe a través del túnel de punto a sitio.
La carpeta GenericDevice también contiene un archivo .cer denominado VpnSer verRoot . Este archivo
contiene el certificado raíz necesario para validar la instancia de Azure VPN Gateway durante la
configuración de la conexión de punto a sitio. Instale el certificado en todos los dispositivos que se van a
conectar a la red virtual de Azure.
Pasos siguientes
Vuelva al artículo para completar la configuración de la conexión de punto a sitio.
Para obtener información acerca de cómo solucionar problemas de P2S, consulte Solución de problemas:
conexión de punto a sitio de Azure.
Autenticación RADIUS de Azure VPN Gateway de
integración con el servidor NPS para Multi-Factor
Authentication
En el artículo se describe cómo integrar Servidor de directivas de redes (NPS) con la autenticación RADIUS de
Azure VPN Gateway a fin de ofrecer Multi-Factor Authentication (MFA) a las conexiones VPN de punto a sitio.
Requisito previo
Para habilitar MFA, los usuarios deben estar en Azure Active Directory (Azure AD), que debe sincronizarse desde
el entorno local o de nube. Además, el usuario ya debe haber completado el proceso de inscripción automática
para MFA. Para obtener más información, consulte Configuración de mi cuenta para la comprobación en dos
pasos
Pasos detallados
Paso 1: Creación de una puerta de enlace de red virtual
2. En la red virtual que hospedará la puerta de enlace de red virtual, seleccione Subredes y, a continuación,
Subred de puer ta de enlace para crear una subred.
3. Cree una puerta de enlace de red virtual especificando la siguiente configuración:

Tipo de puer ta de enlace : seleccione VPN .
Tipo de VPN : seleccione Basada en rutas .
SKU : seleccione un tipo de SKU basada en sus requisitos.
Red vir tual : seleccione la red virtual en la que creó la subred de puerta de enlace.
Paso 2: Configuración del NPS para Azure AD MFA
1. En el servidor NPS, instale la extensión de NPS para Azure AD MFA.
2. Abra la consola de NPS, haga clic con el botón derecho en Clientes RADIUS y seleccione Nuevo . Cree
el cliente RADIUS especificando la siguiente configuración:
Nombre descriptivo : escriba cualquier nombre.
Dirección (IP o DNS) : escriba la subred de puerta de enlace que creó en el Paso 1.
Secreto compar tido : escriba cualquier clave secreta y recuérdela para su uso posterior.
3. En la pestaña Avanzado , establezca el nombre del proveedor en RADIUS estándar y asegúrese de que
la casilla Opciones adicionales no está activada.
4. Vaya a Directivas > Directivas de red , haga doble clic en la directiva Conexiones al ser vidor de
enrutamiento y acceso remoto de Microsoft , seleccione Conceder acceso y, a continuación, haga
clic en Aceptar .
Paso 3: Configuración de la puerta de enlace de red virtual
2. Abra la puerta de enlace de red virtual que creó. Asegúrese de que el tipo de puerta de enlace se
establece en VPN y de que el tipo de VPN está basado en rutas .
3. Haga clic en Configuración de punto a sitio > Configurar ahora y, a continuación, especifique la
siguiente configuración:
Grupo de direcciones : escriba la subred de puerta de enlace que creó en el paso 1.
Tipo de autenticación : seleccione Autenticación RADIUS .
Dirección IP del ser vidor : escriba la dirección IP del servidor NPS.
Pasos siguientes
Azure AD Multi-Factor Authentication
Integración de la infraestructura existente de NPS con Azure AD Multi-Factor Authentication
Creación de un inquilino de Azure Active Directory
para conexiones del protocolo P2S OpenVPN
Al conectarse a la red virtual, puede usar la autenticación basada en certificados o la autenticación RADIUS. Sin
embargo, cuando use el protocolo de VPN abierto, también puede usar la autenticación de Azure Active
Directory. Este artículo le ayuda a configurar un inquilino de Azure AD para la autenticación de P2S VPN abierta.
NOTE
La autenticación de Azure AD solo se admite para las conexiones de protocolo de OpenVPN®.
Para la autenticación de Azure AD se requiere el cliente VPN de Azure, que solo está disponible para Windows 10.
1. Comprobación del inquilino de Azure AD

Compruebe que tiene un inquilino de Azure AD. Si no tiene ningún inquilino de Azure AD, para crearlo siga los
pasos del artículo Creación de un nuevo inquilino:
Nombre organizativo
Nombre de dominio inicial
2. Crear usuario de inquilino Azure AD

El inquilino de Azure AD necesita las siguientes cuentas: una cuenta de administrador global y una cuenta de
usuario maestro. La cuenta de usuario principal se usa como cuenta de inserción maestra (cuenta de servicio). Al
crear una cuenta de usuario de inquilino Azure AD, ajuste el rol de directorio para el tipo de usuario que desea
crear.
Siga los pasos descritos en Incorporación o eliminación de usuarios mediante Azure Active Directory para crear
al menos dos usuarios para el inquilino de Azure AD. Asegúrese de cambiar el rol de directorio para crear los
tipos de cuenta:
Administrador global
Usuario
3. Habilitación de la autenticación de Azure AD

1. Busque el ID. de directorio del directorio que desea utilizar para la autenticación. Aparece en la sección de
propiedades de la página Active Directory.
2. Copie el ID. del directorio.

3. Inicie sesión en el Azure Portal como un usuario al que se le ha asignado el rol de administrador
global .
4. Después, ceda el consentimiento del administrador. Copie y pegue la dirección URL que pertenece a la
ubicación de implementación en la barra de direcciones del explorador:
Público
https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-
cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
Azure Government
https://login.microsoftonline.us/common/oauth2/authorize?client_id=51bb15d4-3a4f-4ebf-9dca-
40096fe32426&response_type=code&redirect_uri=https://portal.azure.us&nonce=1234&prompt=admin_consent
Microsoft Cloud Germany
https://login-us.microsoftonline.de/common/oauth2/authorize?client_id=538ee9e6-310a-468d-afef-
ea97365856a9&response_type=code&redirect_uri=https://portal.microsoftazure.de&nonce=1234&prompt=admin
_consent
Azure China 21Vianet
https://login.chinacloudapi.cn/common/oauth2/authorize?client_id=49f817b6-84ae-4cc0-928c-
73f27289b3aa&response_type=code&redirect_uri=https://portal.azure.cn&nonce=1234&prompt=admin_consent
NOTE
Si utiliza una cuenta de administrador global que no sea nativa del inquilino de Azure AD para dar su
consentimiento, reemplace "common" por el identificador de directorio de Azure AD en la dirección URL. Es posible
que también tenga que reemplazar "common" por el identificador de directorio en algunos otros casos.
5. Seleccione la cuenta del Administrador global si se le solicita.
6. Seleccione Aceptar cuando se le solicite.

7. En el Azure AD, en Aplicaciones empresariales , verá la VPN de Azure en la lista.
8. Si no dispone de un entorno de punto a sitio funcionando, siga las instrucciones para crear uno. Consulte
Creación de una VPN de punto a sitio para crear una puerta de enlace de VPN de punto a sitio.
IMPORTANT
La SKU de nivel Básico no es compatible con OpenVPN.
9. Habilite la autenticación de Azure AD en la puerta de enlace de VPN. Para ello, navegue hasta
Configuración de punto a sitio y seleccione OpenVPN (SSL) como Tipo de túnel . Seleccione
Azure Active Director y como Tipo de autenticación y, después, rellene la información de la sección
Azure Active Director y .
Inquilino: valor de TenantID del inquilino de Azure AD
https://login.microsoftonline.com/{AzureAD TenantID}/
Audiencia: valor de ApplicationID de la aplicación empresarial de Azure AD "Azure VPN"

{AppID of the "Azure VPN" AD Enterprise app}
Emisor : dirección URL del servicio de token seguro https://sts.windows.net/{AzureAD TenantID}/

NOTE
Asegúrese de incluir la barra diagonal al final del valor AadIssuerUri . De lo contrario, se puede producir un error
en la conexión.
10. Para crear y descargar el perfil, haga clic en el vínculo Descargar cliente VPN .
11. Extraiga el archivo zip descargado.
12. Busque la carpeta "AzureVPN" descomprimida.
13. Anote la ubicación del archivo "azurevpnconfig. xml". Azurevpnconfig. xml contiene la configuración de la
conexión VPN y se puede importar directamente en la aplicación del cliente VPN Azure. También puede
distribuir este archivo a todos los usuarios que necesiten conectarse a través del correo electrónico u
otros medios. El usuario necesitará credenciales de Azure AD válidas para conectarse correctamente.
Pasos siguientes
Cree y configure un perfil de cliente VPN. Consulte Configurar un cliente VPN para conexiones P2S VPN.
Creación de un inquilino de Active Directory (AD)
para conexiones del protocolo P2S OpenVPN
Al conectarse a la red virtual, puede usar la autenticación basada en certificados o la autenticación RADIUS. Sin
embargo, cuando use el protocolo de VPN abierto, también puede usar la autenticación de Azure Active
Directory. Si quiere que un conjunto de usuarios diferente pueda conectarse a diferentes puertas de enlace de
VPN, puede registrar varias aplicaciones en AD y vincularlas a diferentes puertas de enlace de VPN. Este artículo
le ayuda a configurar un inquilino de Azure AD para la autenticación de OpenVPN de P2S y a crear y registrar
varias aplicaciones en Azure AD a fin de permitir un acceso distinto a los diferentes usuarios y grupos.
NOTE
1. Cree un inquilino Azure AD

Cree un inquilino de Azure AD con los pasos del artículo Crear un nuevo inquilino:
Nombre organizativo
Nombre de dominio inicial
Ejemplo:
2. Creación de usuarios inquilinos

En este paso, creará dos usuarios inquilinos de Azure AD: una cuenta de administrador global y una cuenta de
usuario principal. La cuenta de usuario principal se usa como cuenta de inserción maestra (cuenta de servicio).
Al crear una cuenta de usuario de inquilino Azure AD, ajuste el rol de directorio para el tipo de usuario que
desea crear. Siga los pasos descritos en este artículo para crear al menos dos usuarios para su inquilino de
Azure AD. Asegúrese de cambiar el rol de directorio para crear los tipos de cuenta:
Administrador global
Usuario
3. Registro del cliente VPN

Registre el cliente VPN en el inquilino de Azure AD.
1. Busque el ID. de directorio del directorio que desea utilizar para la autenticación. Aparece en la sección
propiedades de la página Active Directory.
2. Copie el ID. del directorio.

3. Inicie sesión en el Azure Portal como un usuario al que se le ha asignado el rol de administrador
global .
4. Después, ceda el consentimiento del administrador. Copie y pegue la dirección URL que pertenece a la
ubicación de implementación en la barra de direcciones del explorador:
Público
https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-
cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
Azure Government
https://login.microsoftonline.us/common/oauth2/authorize?client_id=51bb15d4-3a4f-4ebf-9dca-
40096fe32426&response_type=code&redirect_uri=https://portal.azure.us&nonce=1234&prompt=admin_consent
Microsoft Cloud Germany

https://login-us.microsoftonline.de/common/oauth2/authorize?client_id=538ee9e6-310a-468d-afef-
ea97365856a9&response_type=code&redirect_uri=https://portal.microsoftazure.de&nonce=1234&prompt=admin
_consent
Azure China 21Vianet
https://https://login.chinacloudapi.cn/common/oauth2/authorize?client_id=49f817b6-84ae-4cc0-928c-
73f27289b3aa&response_type=code&redirect_uri=https://portal.azure.cn&nonce=1234&prompt=admin_consent
NOTE
Si utiliza una cuenta de administrador global que no sea nativa del inquilino de Azure AD para dar su consentimiento,
reemplace "common" por el identificador de directorio de Azure AD en la dirección URL. Es posible que también tenga que
reemplazar "common" por el identificador de directorio en algunos otros casos.
5. Seleccione la cuenta del Administrador global si se le solicita.
6. Seleccione Aceptar cuando se le solicite.

7. En Azure AD, en Aplicaciones empresariales , verá la VPN de Azure en la lista.
4. Registro de aplicaciones adicionales

En este paso, debe registrar aplicaciones adicionales para varios usuarios y grupos.
1. En Azure Active Directory, haga clic en Registros de aplicaciones y en + Nuevo registro .
2. En la página Registrar una aplicación , escriba el nombre . Seleccione los tipos de cuenta
compatibles que quiera y, luego, haga clic en Registrarse .
3. Una vez que se haya registrado la nueva aplicación, haga clic en Exponer una API en la hoja de la
aplicación.
4. Haga clic en + Agregar un ámbito .
5. Deje el valor URI de id. de la aplicación predeterminado. Haga clic en Guardar y continuar .
6. Rellene los campos obligatorios y asegúrese de que la opción Estado está habilitada . Haga clic en
Agregar ámbito .
7. Haga clic en Exponer una API y, a continuación, + Agregar una aplicación cliente . En Id. de cliente ,
escriba los valores siguientes en función de la nube:
Escriba 41b23e61-6c1e-4545-B367-cd054e0ed4b4 para Azure público .
Escriba 51bb15d4-3a4f-4ebf-9dca-40096fe32426 para Azure Government .
Escriba 538ee9e6-310a-468d-afef-ea97365856a9 para Azure Alemania .
Escriba 49f817b6-84ae-4cc0-928c-73f27289b3aa para Azure China 21Vianet .
8. Haga clic en Agregar aplicación .
9. En la página Introducción , copie el identificador de aplicación (cliente) . Necesitará esta información
para configurar las puertas de enlace de VPN.
10. Repita los pasos de esta sección (Registro de aplicaciones adicionales) para crear tantas aplicaciones
como sea necesario para su requisito de seguridad. Cada aplicación se asociará a una puerta de enlace de
VPN y puede tener un conjunto diferente de usuarios. Solo se puede asociar una aplicación a una puerta
de enlace.
5. Asignar usuarios a aplicaciones

Asigne los usuarios a las aplicaciones.
1. En Azure AD -> Aplicaciones empresariales , seleccione la aplicación recién registrada y haga clic en
Propiedades . Asegúrese de que la opción ¿Asignación de usuarios? esté establecida en Sí . Haga clic
en Save (Guardar).
2. En la página de la aplicación, haga clic en Usuarios y grupos y, después, en +Agregar usuario .

3. En Agregar asignación , haga clic en Usuarios y grupos . Seleccione los usuarios que quiere que
puedan tener acceso a esta aplicación de VPN. Haga clic en Seleccionar .
6. Habilitación de la autenticación en la puerta de enlace

En este paso, habilitará la autenticación de Azure AD en la puerta de enlace VPN.
1. Habilite la autenticación de Azure AD en la puerta de enlace de VPN. Para ello, navegue hasta
Configuración de punto a sitio y seleccione OpenVPN (SSL) como Tipo de túnel . Seleccione
Azure Active Director y como Tipo de autenticación , a continuación, rellene la información de la
sección Azure Active Director y .
NOTE
No use el identificador de la aplicación del cliente VPN de Azure: Concederá acceso a todos los usuarios a la puerta
de enlace VPN. Use el identificador de las aplicaciones que registró.
2. Para crear y descargar el perfil, haga clic en el vínculo Descargar cliente VPN .
3. Extraiga el archivo zip descargado.
4. Busque la carpeta "AzureVPN" descomprimida.
5. Anote la ubicación del archivo "azurevpnconfig. xml". Azurevpnconfig. xml contiene la configuración de la
conexión VPN y se puede importar directamente en la aplicación del cliente VPN Azure. También puede
distribuir este archivo a todos los usuarios que necesiten conectarse a través del correo electrónico u
otros medios. El usuario necesitará credenciales de Azure AD válidas para conectarse correctamente.
Pasos siguientes
Para conectarse a la red virtual, debe crear y configurar un perfil de cliente de VPN. Consulte Configurar un
cliente VPN para conexiones P2S VPN.
Habilitación de Azure AD Multi-Factor
Authentication (MFA) para usuarios de VPN
Si quiere que se solicite a los usuarios un segundo factor de autenticación antes de conceder acceso, puede
configurar Azure AD Multi-Factor Authentication (MFA). Puede configurar MFA por usuario o bien aprovechar
MFA a través del acceso condicional.
MFA por usuario puede habilitarse sin ningún costo adicional. Al habilitar MFA por usuario, se le solicitará al
usuario un segundo factor de autenticación en todas las aplicaciones vinculadas al inquilino de Azure AD.
Consulte la Opción 1 para ver los pasos.
El acceso condicional permite un control más específico sobre cómo se debe promover un segundo factor.
Puede permitir la asignación de MFA únicamente a VPN, así como excluir otras aplicaciones vinculadas al
inquilino de Azure AD. Consulte la Opción 2 para ver los pasos.
Habilitar la autenticación
1. Vaya a Azure Active Director y -> Aplicaciones empresariales -> Todas las aplicaciones .
2. En la página Aplicaciones empresariales - Todas las aplicaciones , seleccione VPN de Azure .
Configuración de las opciones de inicio de sesión

En la página VPN de Azure - Propiedades , configure las opciones de inicio de sesión.
1. En ¿Habilitado para que los usuarios inicien sesión? , seleccione Sí . Esta configuración permite que
todos los usuarios del inquilino de AD se conecten correctamente a la VPN.
2. En Asignación de usuarios necesaria , seleccione Sí si quiere limitar el inicio de sesión solo a los
usuarios que tienen permisos para la VPN de Azure.
3. Guarde los cambios.
Opción 1: Acceso por usuario
Abrir la página de MFA
2. Vaya a Azure Active Director y -> Todos los usuarios .
3. Seleccione Multi-Factor Authentication para abrir la página de la autenticación multifactor.
Seleccionar usuarios
1. En la página de la autenticación multifactor , seleccione los usuarios para los que quiera habilitar MFA.
2. Seleccione Habilitar .
Opción 2: Acceso condicional

El acceso condicional permite un control de acceso específico por aplicación. Para usar el acceso condicional,
debe tener licencias de Azure AD Premium 1 o superior aplicadas a los usuarios que estarán sujetos a las reglas
de acceso condicional.
1. Vaya a la página Aplicaciones empresariales: Todas las aplicaciones y haga clic en Azure VPN .
Haga clic en Acceso condicional .
Haga clic en Nueva directiva para que se abra el panel Nuevo .
2. En el panel Nuevo , vaya a Asignaciones > Usuarios y grupos . En Usuarios y grupos pestaña
Incluir :
Haga clic en Seleccionar usuarios y grupos .
Active la casilla Usuarios y grupos .
Haga clic en Seleccionar para seleccionar un grupo o un conjunto de usuarios que se verán afectado
por MFA.
Haga clic en Done (Listo).
3. En el panel Nuevo , vaya al panel Controles de acceso > Conceder :
Haga clic en Conceder acceso .
Haga clic en Requerir autenticación multifactor .
Haga clic en Requerir todos los controles seleccionados .
Haga clic en Seleccionar .
4. En la sección Habilitar directiva :
Seleccione Activado .
Haga clic en Crear .
Pasos siguientes
Para conectarse a la red virtual, debe crear y configurar un perfil de cliente VPN. Consulte Configurar un cliente
VPN para conexiones P2S VPN.
Autenticación de Azure Active Directory:
Configuración de un cliente VPN para conexiones
P2S de protocolo OpenVPN
Este artículo le ayuda a configurar un cliente VPN para conectarse a una red virtual mediante una VPN de punto
a sitio y la autenticación Azure Active Directory. Antes de poder conectarse y autenticarse con Azure AD, primero
debe configurar el inquilino de Azure AD. Para más información, consulte Configurar un inquilino de Azure AD.
NOTE
Trabajar con perfiles de cliente

Para conectarse, tiene que descargar el cliente VPN de Azure y configurar un perfil de cliente VPN en todos los
equipos que quieran conectarse a la red virtual. Puede crear un perfil de cliente en un equipo, exportarlo y,
después, importarlo en otros equipos.
Para descargar el cliente VPN de Azure
Use este vínculo para descargar el cliente VPN de Azure. Asegúrese de que el cliente VPN de Azure tenga
permiso para ejecutarse en segundo plano. Para comprobar o habilitar el permiso, siga los pasos a continuación:
1. Vaya a Inicio y, después, seleccione Configuración > Privacidad > Aplicaciones en segundo plano.
2. En Aplicaciones en segundo plano, asegúrese de que la opción Permitir que las aplicaciones se ejecuten
en segundo plano esté activada.
3. En Elegir qué aplicaciones se pueden ejecutar en segundo plano, cambie la configuración del cliente VPN de
Azure a Activado .
Para crear un perfil de cliente basado en certificados
Cuando trabaje con un perfil basado en certificados, asegúrese de que los certificados adecuados están
instalados en el equipo cliente. Para más información acerca de los certificados, consulte Instalar certificados de
cliente.
Para crear un perfil de cliente RADIUS
NOTE
El secreto de servidor se puede exportar en el perfil de cliente de P2S VPN. Aquí encontrará instrucciones sobre cómo
exportar un perfil de cliente.
Para exportar y distribuir un perfil de cliente

Una vez que tenga un perfil de trabajo y necesite distribuirlo a otros usuarios, puede exportarlo mediante los
siguientes pasos:
1. Resalte el perfil de cliente de VPN que quiere exportar, seleccione el ... y,luego, seleccione Expor tar .
2. Seleccione la ubicación en la que desea guardar este perfil, deje el nombre de archivo tal cual y, a
continuación, seleccione Guardar para guardar el archivo xml.
Para importar un perfil de cliente
1. En la página, seleccione Impor tar .
2. Busque el archivo xml de perfil y selecciónelo. Con el archivo seleccionado, seleccione Abrir .
3. Especifique el nombre del perfil y seleccione Guardar .

4. Seleccione Conectar para conectarse a la VPN.
5. Una vez conectado, el icono se volverá verde y dirá Conectado .

Para eliminar un perfil de cliente
1. Seleccione los puntos suspensivos junto al perfil de cliente que desea eliminar. Después, seleccione
Quitar .
2. Seleccione Quitar para eliminar.

Crear una conexión
1. En la página, seleccione + , después + Agregar .
2. Rellene la información de conexión. Si no está seguro de los valores, póngase en contacto con el
administrador. Después de rellenar los valores, seleccione Guardar .
3. Seleccione Conectar para conectarse a la VPN.
4. Seleccione las credenciales adecuadas y, después, seleccione Continuar .
5. Una vez que se haya conectado correctamente, el icono se volverá verde y dirá Conectado .
Para conectarse automáticamente
Estos pasos le ayudarán a configurar la conexión para que se conecte automáticamente con Always-on.
1. En la página principal del cliente VPN, seleccione Configuración de VPN .
2. Seleccione Sí en el cuadro de diálogo cambiar aplicaciones.

3. Asegúrese de que la conexión que quiere establecer no está conectada y, luego, resalte el perfil y active la
casilla Conectar automáticamente .
4. Seleccione Conectar para iniciar la conexión VPN.

Diagnóstico de problemas de conexión
1. Para diagnosticar problemas de conexión, puede usar la herramienta Diagnosticar . Seleccione el ... junto
a la conexión VPN que quiere diagnosticar para que se muestre el menú. Después, seleccione
Diagnosticar .
2. En la página Propiedades de conexión , seleccione Ejecutar diagnóstico .

3. Inicie sesión con sus credenciales.
4. Ver los resultados del diagnóstico.

Preguntas más frecuentes
¿El modo FIPS de Windows es compatible con Cliente VPN de Azure?
Sí, con la revisión KB4577063.
¿Cómo agrego sufijos DNS al cliente VPN?
Puede modificar el archivo XML de perfil descargado y agregar las etiquetas <dnssuffixes><dnssufix>
</dnssufix></dnssuffixes> .
<azvpnprofile>
<clientconfig>
<dnssuffixes>
<dnssuffix>.mycorp.com</dnssuffix>
<dnssuffix>.xyz.com</dnssuffix>
<dnssuffix>.etc.net</dnssuffix>
</dnssuffixes>
</clientconfig>
</azvpnprofile>
¿Cómo agrego servidores DNS personalizados al cliente VPN?

Puede modificar el archivo XML de perfil descargado y agregar las etiquetas <dnsser vers><dnsser ver>
</dnsser ver></dnsser vers> .
<azvpnprofile>
<clientconfig>
<dnsservers>
<dnsserver>x.x.x.x</dnsserver>
<dnsserver>y.y.y.y</dnsserver>
</dnsservers>
</clientconfig>
</azvpnprofile>
NOTE
El cliente OpenVPN de Azure AD usa las entradas de la Tabla de directivas de resolución de nombres (NRPT) de DNS, lo
que significa que los servidores DNS no se mostrarán en la salida de ipconfig /all . Para confirmar la configuración de
DNS en uso, consulte Get-DnsClientNrptPolicy en PowerShell.
¿Cómo agrego rutas personalizadas al cliente VPN?

Puede modificar el archivo XML de perfil descargado y agregar las etiquetas <includeroutes><route>
<destination><mask> </destination></mask></route></includeroutes>
<azvpnprofile>
<clientconfig>
<includeroutes>
<route>
<destination>x.x.x.x</destination><mask>24</mask>
</route>
</includeroutes>
</clientconfig>
</azvpnprofile>
¿Cómo bloqueo (excluyo ) las rutas del cliente VPN?

Puede modificar el archivo XML de perfil descargado y agregar las etiquetas <excluderoutes><route>
<destination><mask> </destination></mask></route></excluderoutes>
<azvpnprofile>
<clientconfig>
<excluderoutes>
<route>
<destination>x.x.x.x</destination><mask>24</mask>
</route>
</excluderoutes>
</clientconfig>
</azvpnprofile>
¿Se puede importar el perfil desde un símbolo de la línea de comandos?

Para importar el perfil desde un símbolo de la línea de comandos, coloque el archivo azurevpnconfig. XML
descargado en la carpeta %userprofile%\AppData\Local\Packages\Microsoft.
AzureVpn_8wekyb3d8bbwe \LocalState y ejecute el siguiente comando:
azurevpn -i azurevpnconfig.xml
para forzar la importación, use también el modificador -f
Pasos siguientes
Para más información, consulte crear un inquilino de Azure Active Directory para conexiones VPN abiertas de
P2S que usan Autenticación de Azure AD.
Uso de archivos de perfil de cliente VPN de punto a
sitio
Los archivos de perfil contienen información necesaria para configurar una conexión VPN. Este artículo le
ayudará a obtener y comprender la información necesaria para un perfil de cliente de VPN.
Generación y descarga de perfiles

Para generar archivos de configuración de cliente, puede usar PowerShell o Azure Portal. Cualquiera de los
métodos devuelve el mismo archivo ZIP.
Portal
1. En Azure Portal, navegue a la puerta de enlace de red virtual correspondiente a la red virtual a la que desea
conectarse.
2. En la página de la puerta de enlace de red virtual, seleccione Configuración de punto a sitio .
3. En la parte superior de la página Configuración de punto a sitio, haga clic en Descargar cliente VPN . La
generación del paquete de configuración del cliente tarda unos minutos.
4. El explorador indica que hay disponible un archivo ZIP de configuración del cliente. Tiene el mismo nombre
que su puerta de enlace. Descomprima el archivo para ver las carpetas.
PowerShell
Para generar mediante PowerShell, puede usar el ejemplo siguiente:
1. Al generar archivos de configuración de cliente VPN, el valor de "-AuthenticationMethod" es "EapTIs".
Genere los archivos de configuración de cliente VPN con el comando siguiente:
$profile=New-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" -

AuthenticationMethod "EapTls"
2. Copie la dirección URL en el explorador para descargar el archivo ZIP y, luego, descomprima el archivo
para ver las carpetas.
Extraiga el archivo ZIP

Extraiga el archivo ZIP. El archivo contiene las siguientes carpetas:
AzureVPN
Genérico
OpenVPN (si ha habilitado la configuración de autenticación de OpenVPN y cer tificado de Azure
en la puerta de enlace). Seleccione el artículo adecuado correspondiente a su configuración para crear un
inquilino.
VPN Gateway: creación de un inquilino.
Virtual WAN: creación de un inquilino.
Recuperar información
En la carpeta AzureVPN , desplácese hasta el archivo azurevpnconfig.xml y ábralo con el Bloc de notas. Tome
nota del texto entre las etiquetas siguientes.
<audience> </audience>
<issuer> </issuer>
<tennant> </tennant>
<fqdn> </fqdn>
<serversecret> </serversecret>
Detalles de perfil
Cuando agregue una conexión, use la información que recopiló en el paso anterior para la página de detalles del
perfil. Los campos corresponden con la siguiente información:
Audiencia: Identifica el recurso de destinatario al que está destinado el token.
Emisor : identifica el servicio de token de seguridad (STS) que emitió el token, así como el inquilino de
Azure AD.
Inquilino: Contiene un identificador único e inmutable del inquilino de directorio que emitió el token.
FQDN: nombre de dominio completo (FQDN) en Azure VPN Gateway.
Ser verSecret: la clave previamente compartida de VPN Gateway.
Contenido de la carpeta
La carpeta genérica contiene el certificado de servidor público y el archivo VpnSettings.xml. El archivo
VpnSettings.xml contiene la información necesaria para configurar un cliente genérico.
El archivo zip descargado también puede contener carpetas WindowsAmd64 y WindowsX86 . Estas
carpetas contienen el instalador de SSTP y IKEv2 para clientes de Windows. Necesita derechos de
administrador en el cliente para instalarlos.
La carpeta OpenVPN contiene el perfil de ovpn que debe modificarse para incluir la clave y el certificado.
Para más información, consulte Configurar clientes de OpenVPN para Azure VPN Gateway. Si se selecciona la
autenticación de Azure AD en la puerta de enlace de la VPN, esta carpeta no estará presente en el archivo zip.
En su lugar, vaya a la carpeta AzureVPN y busque azurevpnconfig. xml.
Pasos siguientes
Para más información sobre la ubicación de punto a sitio, consulte Sobre ubicación de punto a sitio.
Creación de perfiles personalizados de Intune para
implementar perfiles de cliente VPN
Puede implementar perfiles para clientes VPN de Azure (Windows 10) mediante Microsoft Intune. Este artículo
le ayuda a crear un perfil de Intune mediante una configuración personalizada.
Requisitos previos
Los dispositivos ya están inscritos con MDM de Intune.
El cliente VPN de Azure para Windows 10 ya está implementado en el equipo cliente.
Solo se admite la versión 19H2 o posterior de Windows.
Modificación de XML
En los pasos siguientes, usamos un XML de ejemplo con un perfil OMA-URI personalizado para Intune con la
siguiente configuración:
Conexión automática activada
Detección de redes de confianza habilitada.
Para ver otras opciones compatibles, consulte el artículo sobre CSP de VPNv2.
1. Descargue el perfil de VPN del Azure Portal y extraiga el archivo azurevpnconfig.xml del paquete.
2. Copie y pegue el texto siguiente en un nuevo archivo de editor de texto.
<VPNProfile>

<RememberCredentials>true</RememberCredentials>
<AlwaysOn>true</AlwaysOn>
<TrustedNetworkDetection>contoso.com,test.corp.contoso.com</TrustedNetworkDetection>
<DeviceTunnel>false</DeviceTunnel>
<RegisterDNS>false</RegisterDNS>
<PluginProfile>
<ServerUrlList>azuregateway-7cee0077-d553-4323-87df-069c331f58cb-
053dd0f6af02.vpn.azure.com</ServerUrlList>
<CustomConfiguration>
</CustomConfiguration>
<PluginPackageFamilyName>Microsoft.AzureVpn_8wekyb3d8bbwe</PluginPackageFamilyName>
</PluginProfile>
</VPNProfile>
3. Modifique la entrada entre <ServerUrlList> y </ServerUrlList> con la entrada del perfil descargado
(azurevpnconfig.xml). Cambie el FQDN "TrustedNetworkDetection" para que se ajuste a su entorno.
4. Abra el perfil descargado de Azure (azurevpnconfig.xml) y copie todo el contenido en el Portapapeles;
para ello, resalte el texto y presione (Ctrl) + C.
5. Pegue el texto copiado del paso anterior en el archivo que creó en el paso 2 entre las etiquetas
<CustomConfiguration> </CustomConfiguration> . Guarde el archivo con la extensión xml.
6. Anote el valor de las etiquetas <name> </name> . Se trata del nombre del perfil. Necesitará este nombre al
crear el perfil en Intune. Cierre el archivo y recuerde la ubicación en la que se guarda.
Creación del perfil de Intune

En esta sección, creará un perfil de Microsoft Intune con una configuración personalizada.
1. Inicie sesión en Intune y navegue a Dispositivos-> Perfiles de configuración . Seleccione + Crear
perfil .
2. En Plataforma , seleccione Windows 10 y versiones posteriores . Como Perfil , seleccione

Personalizado . Seleccione Crear .
3. Asigne un nombre y una descripción al perfil y, luego, seleccione Siguiente .
4. En la pestaña Opciones de configuración , seleccione Agregar .
Nombre: escriba un nombre para la configuración.
Descripción: descripción opcional.
OMA-URI: ./User/Vendor/MSFT/VPNv2/<name of your connection>/ProfileXML (esta información se
puede encontrar en el archivo azurevpnconfig.xml de la etiqueta ).
Tipo de datos: string (archivo XML).
Seleccione el icono de carpeta y elija el archivo que guardó en el paso 6 de los pasos de XML. Seleccione
Agregar .
5. Seleccione Next (Siguiente).
6. En Asignaciones , seleccione el grupo en el que quiere insertar la configuración. Después, seleccione
Siguiente .
7. Las reglas de aplicabilidad son opcionales. Defina las reglas si es necesario y luego seleccione Siguiente .
8. En la página Revisar y crear , seleccione Crear .
9. El perfil personalizado ya se ha creado. Para conocer los pasos de Microsoft Intune para implementar este
perfil, consulte Asignación de perfiles de usuario y de dispositivo.
Pasos siguientes
Para más información sobre la ubicación de punto a sitio, consulte Sobre ubicación de punto a sitio.
Configuración de una conexión VPN de punto a
sitio a una red virtual mediante varios tipos de
autenticación: Azure Portal
sobre SSTP (Protocolo de túnel de sockets seguros) o IKEv2. Para más información sobre las conexiones VPN de
punto a sitio, consulte Acerca de las conexiones VPN de punto a sitio.
punto a sitio. Para crear esta configuración mediante Azure PowerShell, consulte Configuración de una conexión
VPN de punto a sitio con Azure PowerShell.
Requisitos previos
Solo se admiten varios tipos de autenticación en la misma puerta de enlace de VPN con el tipo de túnel
OpenVPN.
Valores del ejemplo
la red virtual.
Nombre de la puer ta de enlace de red vir tual: VNet1GW
Nombre de dirección IP pública: VNet1GWpip
Tipo de conexión : De punto a sitio
Grupo de direcciones de clientes: 172.16.201.0/24
dirección IP del grupo de clientes.

Antes de empezar, compruebe que tiene una suscripción a Azure. Si todavía no la tiene, puede activar sus
ventajas como suscriptor de MSDN o registrarse para obtener una cuenta gratuita.
NOTE


valores:
Resource Manager.
necesite.

Firewall : Disabled
Puerta de enlace de red virtual

NOTE
La SKU de puerta de enlace básica no admite el tipo de túnel OpenVPN.
selecciónela.
en esta página.
de enlace.
enlace.
pública.
Grupo de direcciones de clientes

El grupo de direcciones de cliente es un intervalo de direcciones IP privadas que usted especifica. Los clientes
que se conectan de forma dinámica a través de una VPN de punto a sitio reciben una dirección IP de este
intervalo. Use un intervalo de direcciones IP privadas que no se superponga a la ubicación local desde la que se
va a conectar ni a la red virtual a la que desea conectarse. Si configura varios protocolos y SSTP es uno de ellos,
el grupo de direcciones configurado se divide equitativamente entre los protocolos configurados.
1. Una vez creada la puerta de enlace de red virtual, navegue hasta la sección Valores de la página de la
puerta de enlace de red virtual. En Configuración , seleccione Configuración de punto a sitio .
Seleccione Configure now (Configurar ahora) para abrir la página de configuración.
2. En la página Configuración de punto a sitio , puede configurar diversas opciones. En el cuadro Grupo
de direcciones , agregue el intervalo de direcciones IP privadas que quiere usar. Los clientes VPN
reciben de forma dinámica una dirección IP del intervalo que especifique. La máscara de subred mínima
es de 29 bits para la configuración activa/pasiva, y de 28 bits para la configuración activa/activa.
3. Continúe con la sección siguiente para configurar los tipos de autenticación y de túnel.
Tipos de autenticación y de túnel

En esta sección, configurará el tipo de autenticación y el tipo de túnel. En la página Configuración de punto a
sitio , si no ve Tipo de túnel o Tipo de autenticación , significa que la puerta de enlace usa la SKU básica. La
SKU básica no admite la autenticación de IKEv2 o RADIUS. Si quiere usar esta configuración, debe eliminar y
volver a crear la puerta de enlace con una SKU de puerta de enlace diferente.
Tipo de túnel
En la página Configuración de punto a sitio , seleccione OpenVPN (SSL) como tipo de túnel.
Tipo de autenticación
En Tipo de autenticación , seleccione los tipos que quiera. Las opciones son:
Certificado de Azure
RADIUS
Azure Active Directory
En función de los tipos de autenticación seleccionados, verá distintos campos de configuración que tendrán que
rellenarse. Rellene la información necesaria y seleccione Guardar en la parte superior de la página para guardar
todas las opciones de configuración.
Para obtener más información sobre el tipo de autenticación, consulte:
Certificado de Azure
RADIUS
Azure Active Directory
Paquete de configuración de cliente VPN

Los clientes VPN deben configurarse con las opciones de configuración de cliente. El paquete de configuración
de cliente VPN contiene archivos con los valores para configurar clientes VPN con el fin de conectarse a una red
virtual a través de una conexión P2S.
Para obtener instrucciones sobre cómo generar e instalar archivos de configuración de un cliente VPN, use el
artículo relativo a su configuración:
Creación e instalación de archivos de configuración del cliente VPN para configuraciones de punto a sitio con
autenticación con certificados nativos de Azure.
Autenticación de Azure Active Directory: Configuración de un cliente VPN para conexiones P2S de protocolo
OpenVPN.

Esta sección contiene información sobre las preguntas frecuentes relacionadas con las configuraciones de punto
a sitio. También puede ver las preguntas frecuentes sobre VPN Gateway para información adicional sobre VPN
Gateway.
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

No.
OpenSSL:
Pasos siguientes
sitio de Azure.
Configurar OpenVPN para VPN Gateway de punto
a sitio de Azure
En este artículo le ayudamos a configurar el protocolo OpenVPN® en Azure VPN Gateway. Puede usar las
instrucciones del portal o de PowerShell.
Prerrequisitos
Se supone que ya tiene un entorno de trabajo punto a sitio. Si no es así, cree uno con uno de los métodos
siguientes.
Portal: Creación de VPN de punto a sitio
PowerShell: Creación de VPN de punto a sitio
Compruebe que la puerta de enlace de VPN no use la SKU de nivel Básico. La SKU de nivel Básico no es
compatible con OpenVPN.
Portal
1. En el portal, vaya a Puer ta de enlace de red vir tual -> Configuración de punto a sitio .
2. En Tipo de túnel , seleccione OpenVPN (SSL) en la lista desplegable.
3. Guarde los cambios y continúe con los pasos siguientes .
Habilite OpenVPN en la puerta de enlace mediante PowerShell.

1. Habilite OpenVPN en la puerta de enlace mediante el ejemplo siguiente:
$gw = Get-AzVirtualNetworkGateway -ResourceGroupName $rgname -name $name

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -VpnClientProtocol OpenVPN
2. Continúe con los pasos siguientes .

Pasos siguientes
Para configurar clientes para OpenVPN, consulte Configuración de clientes de OpenVPN.
Configuración de los clientes OpenVPN de Azure
VPN Gateway
Este artículo le ayuda a configurar clientes del protocolo ®OpenVPN .
Antes de empezar
Compruebe que ha completado los pasos para configurar OpenVPN para VPN Gateway. Para obtener más
información, consulte Configuración de los clientes OpenVPN de Azure VPN Gateway.
Clientes Windows
1. Descargue e instale el cliente OpenVPN (versión 2.4 o superior) desde el sitio web de OpenVPN oficial.
2. Descargue el perfil de VPN para la puerta de enlace. Esto puede hacerse desde la pestaña de
configuración de punto a sitio de Azure Portal o mediante "New-AzVpnClientConfiguration" en
PowerShell.
3. Descomprima el perfil. A continuación, abra el archivo de configuración vpnconfig.ovpn desde la carpeta
OpenVPN del Bloc de notas.
4. Exporte el certificado de cliente de punto a sitio que ha creado y cargado en la configuración de P2S en la
puerta de enlace. Utilice los vínculos de los artículos siguientes:
Instrucciones de VPN Gateway
Instrucciones de Virtual WAN
5. Extraiga la clave privada y la huella digital de base64 del archivo .pfx. Hay varias formas de hacerlo. Una
de ellas es usar OpenSSL en su máquina. El archivo profileinfo.txt contiene la clave privada y la huella
digital de la entidad de certificación y el certificado de cliente. Asegúrese de usar la huella digital del
certificado de cliente.
openssl pkcs12 -in "filename.pfx" -nodes -out "profileinfo.txt"
6. Abra profileinfo.txt en el Bloc de notas. Para obtener la huella digital del certificado (secundario) de
cliente, seleccione el texto (incluido y entre) "---BEGIN CERTIFICATE---" y "---END CERTIFICATE---" para el
certificado secundario y cópielo. Puede identificar el certificado secundario si examina la línea subject=/.
7. Cambie al archivo vpnconfig.ovpn que abrió en el Bloc de notas en el paso 3. Busque la sección que se
muestra a continuación y reemplace todo lo que hay entre "cert" y "/cert".
# P2S client certificate

# please fill this field with a PEM formatted cert
<cert>
$CLIENTCERTIFICATE
</cert>
8. Abra el archivo profileinfo.txt en el Bloc de notas. Para obtener la clave privada, seleccione el texto
(incluido y entre) "-----BEGIN PRIVATE KEY-----" y "-----END PRIVATE KEY-----" y cópielo.
9. Vuelva al archivo vpnconfig.ovpn en el Bloc de notas y busque esta sección. Pegue la clave privada y
reemplace todo lo que hay entre "key" y "/key".
# P2S client root certificate private key

# please fill this field with a PEM formatted key
<key>
$PRIVATEKEY
</key>
10. No cambie los demás campos. Use los datos de la configuración de entrada del cliente para conectarse a
la VPN.
11. Copie el archivo vpnconfig.ovpn en la carpeta C:\Program Files\OpenVPN\config.
12. Haga clic con el botón derecho en l icono de OpenVPN en la bandeja del sistema y, después, haga clic en
Conectar.
Clientes Mac
1. Descargue e instale un cliente OpenVPN, como TunnelBlick.
PowerShell.
3. Descomprima el perfil. Abra el archivo de configuración vpnconfig.ovpn desde la carpeta OpenVPN en un
editor de texto.
4. Rellene la sección de certificado cliente de P2S con la clave pública del certificado cliente de P2S en
Base64. En un certificado con formato PEM, puede abrir el archivo .cer y copiar la clave de base64 entre
los encabezados del certificado. Use los vínculos de los artículos siguientes para obtener información
acerca de cómo exportar un certificado para obtener la clave pública codificada:
5. Rellene la sección de la clave privada con la clave privada del certificado cliente de P2S en Base64.
Consulte Exportación de la clave privada en el sitio de OpenVPN para obtener información sobre cómo
extraer una clave privada.
la VPN.
7. Haga doble clic en el archivo de perfil para crear el perfil en Tunnelblick.
8. Inicie Tunnelblick desde la carpeta de aplicaciones.
9. Haga clic en el icono de Tunneblick en la bandeja del sistema y seleccione Conectar.
IMPORTANT
Solo iOS 11.0 y MacOS 10.13 (y sus respectivas versiones posteriores) son compatibles con el protocolo OpenVPN.
Clientes iOS
1. Instale el cliente de OpenVPN (versión 2,4 o posterior) desde App Store.
PowerShell.
3. Descomprima el perfil. Abra el archivo de configuración vpnconfig.ovpn desde la carpeta OpenVPN en un
editor de texto.
4. Rellene la sección de certificado cliente de P2S con la clave pública del certificado cliente de P2S en
Base64. En un certificado con formato PEM, puede abrir el archivo .cer y copiar la clave de base64 entre
los encabezados del certificado. Use los vínculos de los artículos siguientes para obtener información
acerca de cómo exportar un certificado para obtener la clave pública codificada:
5. Rellene la sección de la clave privada con la clave privada del certificado cliente de P2S en Base64.
Consulte Exportación de la clave privada en el sitio de OpenVPN para obtener información sobre cómo
extraer una clave privada.
6. No cambie los demás campos.
7. Envíe por correo electrónico el archivo de perfil (.ovpn) a su cuenta de correo electrónico configurada en
la aplicación de correo en su iPhone.
8. Abra el correo electrónico en la aplicación de correo del iPhone y pulse en el archivo adjunto.
9. Pulse en More (Más) si no ve la opción Copy to OpenVPN (Copiar a OpenVPN).
10. Pulse en Copiar a OpenVPN .
11. Pulse en ADD en la página Impor t Profile (Importar perfil).
12. Pulse en ADD en la página Impor ted Profile (Perfil importado).
13. Inicie la aplicación OpenVPN y deslice el conmutador de la página Profiles (Perfiles) a la derecha para
conectar.
Clientes Linux
1. Abra una nueva sesión de terminal. Para abrir una nueva sesión, presione "CTRL + ALT + T" al mismo
tiempo.
2. Escriba el siguiente comando para instalar los componentes necesarios:
sudo apt-get install openvpn

sudo apt-get -y install network-manager-openvpn
sudo service network-manager restart
3. Descargue el perfil de VPN para la puerta de enlace. Esto se puede hacer desde la pestaña de
configuración de punto a sitio en Azure Portal.
4. Exporte el certificado de cliente P2P que ha creado y cargado en la configuración de P2S en la puerta de
enlace. Utilice los vínculos de los artículos siguientes:
5. Extraiga la clave privada y la huella digital de base64 del archivo .pfx. Hay varias formas de hacerlo. Una
de ellas es usar OpenSSL en su equipo.
openssl pkcs12 -in "filename.pfx" -nodes -out "profileinfo.txt"
El archivo profileinfo.txt contendrá la clave privada y la huella digital de la entidad de certificación y el

certificado de cliente. Asegúrese de usar la huella digital del certificado de cliente.
6. Abra profileinfo.txt en un editor de texto. Para obtener la huella digital del certificado (secundario) de
cliente, seleccione el texto (incluido y entre) "---BEGIN CERTIFICATE---" y "---END CERTIFICATE---" para el
certificado secundario y cópielo. Puede identificar el certificado secundario si examina la línea subject=/.
7. Abra el archivo vpnconfig.ovpn y busque la sección que se muestra a continuación. Reemplace todo lo
que aparece entre "cert" y "/cert".
# P2S client certificate

# please fill this field with a PEM formatted cert
<cert>
$CLIENTCERTIFICATE
</cert>
8. Abra el archivo profileinfo.txt en un editor de texto. Para obtener la clave privada, seleccione el texto
incluido y entre "-----BEGIN PRIVATE KEY-----" y "-----END PRIVATE KEY-----" y cópielo.
9. Abra el archivo vpnconfig.ovpn en un editor de texto y busque esta sección. Pegue la clave privada y
reemplace todo lo que hay entre "key" y "/key".
# P2S client root certificate private key

# please fill this field with a PEM formatted key
<key>
$PRIVATEKEY
</key>
la VPN.
11. Para conectarse mediante la línea de comandos, escriba el siguiente comando:
sudo openvpn --config <name and path of your VPN profile file>&
12. Para conectarse mediante la GUI, vaya a la configuración del sistema.

13. Haga clic en + para agregar una nueva conexión VPN.
14. En Agregar VPN , seleccione Impor tar desde archivo... .
15. Vaya al archivo de perfil y haga doble clic o seleccione Abrir .
16. Haga clic en Agregar en la ventana Agregar VPN .
17. Puede conectarse mediante la activación de VPN en la página Configuración de red o en el icono de
red de la bandeja del sistema.
Pasos siguientes
Si quiere que los clientes VPN tengan acceso a recursos de otra red virtual, siga las instrucciones del artículo De
red virtual a red virtual para configurar una conexión de red virtual a red virtual. Asegúrese de habilitar BGP en
las puertas de enlace y las conexiones; en caso contrario, el tráfico no fluirá.
Transición al protocolo OpenVPN o IKEv2 desde
SSTP
cliente. Este artículo se aplica al modelo de implementación del Administrador de recursos y en él se habla de
distintas formas de superar el límite de 128 conexiones simultáneas de SSTP mediante la transición al protocolo
OpenVPN o IKEv2.
¿Qué protocolo utiliza P2S?

La conexión VPN de punto a sitio usa uno de los siguientes protocolos:
Protocolo OpenVPN® , un protocolo VPN basado en SSL/TLS. Una solución de VPN basada en SSL
puede penetrar firewalls, puesto que la mayoría de ellos abre el puerto TCP 443 saliente, que utiliza SSL.
El protocolo de túnel de sockets seguro (SSTP) , que es un protocolo VPN propio basado en SSL.
Una solución de VPN basada en SSL puede penetrar firewalls, puesto que la mayoría de ellos abre el
puerto TCP 443 saliente, que utiliza SSL. El protocolo SSTP solo se admite en dispositivos Windows.
Azure es compatible con todas las versiones de Windows que tienen SSTP (Windows 7 y versiones
posteriores). SSTP admite como máximo 128 conexiones simultáneas, con independencia de la
SKU de puer ta de enlace .
NOTE
IKEv2 y OpenVPN para P2S están disponibles para el modelo de implementación de Resource Manager. No están
disponibles para el modelo de implementación clásico. La SKU de puerta de enlace básica no es compatible con los
protocolos IKEv2 ni OpenVPN. Si usa la SKU básica, tendrá que eliminar y volver a crear una SKU de producción para la
Migración de SSTP a IKEv2 o a OpenVPN

Puede haber casos en los que quiera admitir más de 128 conexiones P2S simultáneas con una puerta de enlace
VPN pero que usen SSTP. En tal caso, deberá pasarse al protocolo OpenVPN o IKEv2.
Opción 1: agregar IKEv2 además de SSTP en la puerta de enlace
Esta es la opción más sencilla. SSTP e IKEv2 pueden coexistir en la misma puerta de enlace y proporcionan un
mayor número de conexiones simultáneas. Puede habilitar IKEv2 en la puerta de enlace existente y volver a
descargar el cliente.
El hecho de agregar IKEv2 a una puerta de enlace VPN de SSTP existente no afectará a los clientes existentes y
podrá configurarlos para usar IKEv2 en lotes pequeños o simplemente configurar los clientes nuevos para que
usen IKEv2. Si un cliente de Windows está configurado para SSTP e IKEv2, intentará conectarse primero con
IKEV2 y, si no lo consigue, usará SSTP.
IKEv2 usa puer tos UDP no estándar, por lo que deberá asegurarse de que estos puer tos no estén
bloqueados en el firewall del usuario. Los puer tos en uso son el UDP 500 y el 4500.
Para agregar IKEv2 a una puerta de enlace existente, solo tiene que ir a la pestaña "Configuración de punto a
sitio" en la puerta de enlace de red virtual del portal y seleccionar IKEv2 y SSTP (SSL) en el cuadro
desplegable.
Opción 2: quitar SSTP y habilitar OpenVPN en la puerta de enlace

Dado que SSTP y OpenVPN son protocolos basados en TLS, no pueden coexistir en la misma puerta de enlace.
Si opta por pasarse de SSTP a OpenVPN, tendrá que deshabilitar SSTP y habilitar OpenVPN en la puerta de
enlace. Esta operación hará que los clientes existentes pierdan la conectividad a la puerta de enlace VPN hasta
que se haya configurado el perfil nuevo en el cliente.
Si quiere, puede habilitar OpenVPN junto con IKEv2. OpenVPN está basado en TLS y usa el puerto TCP 443
estándar. Para cambiar a OpenVPN, vaya a la pestaña "Configuración de punto a sitio" de la puerta de enlace de
red virtual del portal y seleccione OpenVPN (SSL) o IKEv2 y OpenVPN (SSL) en el cuadro desplegable.
Una vez configurada la puerta de enlace, los clientes existentes no podrán conectarse hasta que haya
implementado y configurado los clientes de OpenVPN.
Si usa Windows 10, también puede usar el cliente VPN de Azure para Windows
Preguntas más frecuentes

¿Cuáles son los requisitos de configuración del cliente?
NOTE
Para los clientes de Windows, debe tener derechos de administrador en el dispositivo de cliente para poder iniciar la
conexión VPN desde el dispositivo cliente en Azure.
Los usuarios utilizan los clientes VPN nativos en los dispositivos Windows y Mac para P2S. Azure proporciona
un archivo zip de configuración de cliente VPN con la configuración que necesitan estos clientes nativos para
conectarse a Azure.
Para los dispositivos Windows, la configuración de cliente VPN consta de un paquete de instalación que los
usuarios instalan en sus dispositivos.
Para los dispositivos Mac, consta del archivo mobileconfig que los usuarios instalan en sus dispositivos.
El archivo zip también proporciona los valores de algunas de las opciones de configuración importantes del
lado de Azure que puede usar para crear su propio perfil para estos dispositivos. Algunos de los valores
incluyen la dirección de puerta de enlace de VPN, los tipos de túnel configurados, las rutas y el certificado raíz
para la validación de la puerta de enlace.
NOTE
¿Qué SKU de puerta de enlace admite VPN de P2S?
P RUEB A S

n1
n1
n1
n1 Z
n1 Z
n1 Z
n2
n2
n2

n2 10000
n2 Z
n2 Z
P RUEB A S
n2 Z

n2 Z 10000
más bajo.
PA Q UET ES P O R

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
PA Q UET ES P O R

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
Para obtener recomendaciones de la SKU de puerta de enlace, consulte Acerca de la configuración de VPN
Gateway.
NOTE
La SKU básica no admite la autenticación de IKEv2 o RADIUS.
¿Qué directivas IPsec/IKE se configuran en las puertas de enlace de VPN de P2S?

IKEv2

IPsec
C IF RA DO IN T EGRIDA D GRUP O P F S
GCM_AES256 GCM_AES256 GROUP_NONE
¿Qué directivas TLS se configuran en las puertas de enlace de VPN para P2S?
TLS
DIREC T IVA S
DIREC T IVA S
¿Cómo se puede configurar una conexión de P2S?

En una configuración de P2S es necesario realizar unos pocos pasos específicos. En los siguientes artículos
encontrará los pasos necesarios para realizar una configuración de P2S, así como vínculos para configurar los
dispositivos de cliente VPN:
RADIUS)
Configuración de OpenVPN
Pasos siguientes
RADIUS)
Administración de sesiones de VPN de punto a sitio
Las puertas de enlace de red virtual de Azure proporcionan una manera fácil de ver y desconectar las sesiones
actuales de VPN de punto a sitio. Este artículo le ayuda a ver y desconectar las sesiones actuales.
NOTE
El estado de la sesión se actualiza cada cinco minutos. No lo hace inmediatamente.
Portal
Para ver y desconectar una sesión en el portal:
1. Vaya a la puerta de enlace de VPN.
2. En la sección Super visión , seleccione Point-to-site Sessions (Sesiones de punto a sitio).
3. Puede ver todas las sesiones actuales en el panel de la ventana.

4. Seleccione "..." en la sesión que quiera desconectar y, luego, elija Desconectar .
PowerShell
Para ver y desconectar una sesión mediante PowerShell:
1. Ejecute el siguiente comando de PowerShell para mostrar las sesiones activas:
Get-AzVirtualNetworkGatewayVpnClientConnectionHealth -VirtualNetworkGatewayName <name of the gateway>

-ResourceGroupName <name of the resource group>
2. Copie el valor de VpnConnectionId de la sesión que quiere desconectar.

3. Para desconectar la sesión, ejecute el siguiente comando:
Disconnect-AzVirtualNetworkGatewayVpnConnection -VirtualNetworkGatewayName <name of the gateway> -

ResourceGroupName <name of the resource group> -VpnConnectionId <VpnConnectionId of the session>
Pasos siguientes
Para más información sobre las conexiones de punto a sitio, consulte Acerca de las conexiones VPN de punto a
sitio.
Configuración de un túnel de dispositivo VPN para
los Grupos de disponibilidad AlwaysOn
Always On es una nueva característica del cliente VPN de Windows 10 que ofrece la posibilidad de mantener
una conexión VPN. Con Always On, el perfil activo de VPN se puede conectar automáticamente y permanecer
conectado según los desencadenadores como, por ejemplo, en los inicios de sesión de los usuarios, los cambios
en el estado de la red o la activación de la pantalla del dispositivo.
Las puertas de enlace pueden utilizarse con Windows 10 Always On para establecer túneles de usuario
persistentes, así como túneles de dispositivo dirigidos a Azure.
Las conexiones VPN de Always On incluyen uno de estos dos tipos de túneles:
Túnel de dispositivo : se conecta a los servidores VPN especificados antes de que los usuarios inicien
sesión en el dispositivo. Los túneles de dispositivo se utilizan en escenarios de conectividad previos al
inicio de sesión y para administrar dispositivos.
Túnel de usuario : solo se conecta después de que los usuarios inicien sesión en el dispositivo. Mediante
los túneles de usuario puede acceder a los recursos de la organización utilizando servidores VPN.
Los túneles de dispositivo y los de usuario funcionan de forma independiente a los perfiles VPN. Pueden
conectarse al mismo tiempo y utilizar diferentes métodos de autenticación u otras opciones de configuración de
VPN en función de las necesidades.
Configuración de la puerta de enlace

Configure la puerta de enlace de VPN para usar IKEv2 y la autenticación basada en certificados mediante el
artículo sobre la configuración de una conexión VPN de punto a sitio.
Configuración del túnel de dispositivo

Para poder establecer correctamente un túnel de dispositivo, deben cumplirse los siguientes requisitos:
El dispositivo debe ser un equipo unido a un dominio que ejecute la versión 1809 u otra posterior de
Windows 10 Enterprise o Education.
El túnel solamente puede configurarse en la solución VPN integrada en Windows y debe establecerse
utilizando IKEv2 con la autenticación de certificados de equipo.
Solo se puede configurar un túnel de dispositivo en cada dispositivo.
1. Instale certificados de cliente en el cliente de Windows 10, tal y como se muestra en este artículo sobre el
cliente VPN de punto a sitio. El certificado debe estar en el almacén del equipo local.
2. Cree un perfil de VPN y configurar el túnel de dispositivo en el contexto de la cuenta de sistema local
mediante estas instrucciones.
Ejemplo de configuración de túnel de dispositivo
Una vez que haya configurado la puerta de enlace de red virtual e instalado el certificado de cliente en el
almacén del equipo local del cliente de Windows 10, use los ejemplos siguientes para configurar un túnel de
dispositivo de cliente.
1. Copie el texto siguiente y guárdelo como *devicecer t.ps1 .
Param(
[string]$xmlFilePath,
[string]$ProfileName
)
$a = Test-Path $xmlFilePath
echo $a
$ProfileXML = Get-Content $xmlFilePath
echo $XML
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$Version = 201606090004
$ProfileXML = $ProfileXML -replace '<', '<'

$ProfileXML = $ProfileXML -replace '>', '>'
$ProfileXML = $ProfileXML -replace '"', '"'
$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
$session = New-CimSession
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI",
'String', 'Key')
$newInstance.CimInstanceProperties.Add($property)
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID",
"$ProfileNameEscaped", 'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML",
'String', 'Property')
$session.CreateInstance($namespaceName, $newInstance)
$Message = "Created $ProfileName profile."
Write-Host "$Message"
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
exit
}
$Message = "Complete."
2. Copie el texto siguiente y guárdelo como VPNProfile.xml en la misma carpeta que _*devicecert.ps1**.
Modifique el texto siguiente para adaptarlo a su entorno.
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers> <= Can be found in the VpnSettings.xml in
the downloaded profile zip file
<Address>192.168.3.5</Address> <= IP of resource in the vnet or the vnet address space
<VPNProfile>
<NativeProfile>
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<MachineMethod>Certificate</MachineMethod>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>

<Route>
<Address>192.168.3.5</Address>
<PrefixSize>32</PrefixSize>
</Route>
<Route>
</Route>


<DeviceTunnel>true</DeviceTunnel>

<RegisterDNS>true</RegisterDNS>
</VPNProfile>
3. Descargue PsExec de Sysinternals y extraiga los archivos en C:\PSTools .

4. En un símbolo del sistema de CMD con privilegios de administrador, inicie PowerShell ejecutando:
PsExec.exe Powershell for 32-bit Windows

PsExec64.exe Powershell for 64-bit Windows
5. En PowerShell, vaya la carpeta donde se encuentra devicecer t.ps1 y VPNProfile.xml y ejecute el

siguiente comando:
.\devicecert.ps1 .\VPNProfile.xml MachineCertTest

6. Ejecute rasphone .
7. Busque la entrada MachineCer tTest y haga clic en Conectar .
8. Si la conexión se realiza correctamente, reinicie el equipo. El túnel se conectará automáticamente.
Eliminación de un perfil
Para quitar el perfil, ejecute el siguiente comando:
Pasos siguientes
Para solucionar problemas, consulte Problemas de conexión de punto a sitio de Azure.
Configuración de un túnel de usuario de VPN para
Grupos de disponibilidad AlwaysOn
Always On es una nueva característica del cliente VPN de Windows 10 que ofrece la posibilidad de mantener
una conexión VPN. Con Always On, el perfil activo de VPN se puede conectar automáticamente y permanecer
conectado según los desencadenadores como, por ejemplo, en los inicios de sesión de los usuarios, los cambios
en el estado de la red o la activación de la pantalla del dispositivo.
Las puertas de enlace pueden utilizarse con Windows 10 Always On para establecer túneles de usuario
persistentes, así como túneles de dispositivo dirigidos a Azure.
Las conexiones VPN de Always On incluyen uno de estos dos tipos de túneles:
Túnel de dispositivo : se conecta a los servidores VPN especificados antes de que los usuarios inicien
sesión en el dispositivo. Los túneles de dispositivo se utilizan en escenarios de conectividad previos al
inicio de sesión y para administrar dispositivos.
Túnel de usuario : solo se conecta después de que los usuarios inicien sesión en el dispositivo. Mediante
los túneles de usuario puede acceder a los recursos de la organización utilizando servidores VPN.
Los túneles de dispositivo y los de usuario funcionan de forma independiente a los perfiles VPN. Pueden
conectarse al mismo tiempo y utilizar diferentes métodos de autenticación u otras opciones de configuración de
VPN en función de las necesidades.
Configuración de la puerta de enlace

Use las instrucciones del artículo Configuración de una conexión VPN de punto a sitio para configurar la puerta
de enlace de VPN para que use IKEv2 y la autenticación basada en certificados.
Configuración de un túnel de usuario

1. Instale certificados de cliente en el cliente de Windows 10, tal y como se muestra en este artículo sobre
los clientes VPN de punto a sitio. El certificado debe estar en el almacén del usuario actual.
2. Configure el cliente VPN de Always On mediante PowerShell, Configuration Manager o Intune siguiendo
las instrucciones de Configuración de conexiones VPN de Always On en el cliente de Windows 10.
Ejemplo de configuración para el túnel de usuario
Una vez que haya configurado la puerta de enlace de red virtual e instalado el certificado de cliente en el
almacén de la máquina local del cliente de Windows 10, use los ejemplos siguientes para configurar un túnel de
dispositivo de cliente:
1. Copie el texto siguiente y guárdelo como usercert.ps1:
Param(
[string]$xmlFilePath,
[string]$ProfileName
)
$a = Test-Path $xmlFilePath
echo $a
$ProfileXML = Get-Content $xmlFilePath
echo $XML
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$Version = 201606090004
$ProfileXML = $ProfileXML -replace '<', '<'

$ProfileXML = $ProfileXML -replace '>', '>'
$ProfileXML = $ProfileXML -replace '"', '"'
$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"
$session = New-CimSession
try
{
$newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI",
'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID",
"$ProfileNameEscaped", 'String', 'Key')
$property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML",
'String', 'Property')
$session.CreateInstance($namespaceName, $newInstance)
$Message = "Created $ProfileName profile."
}
catch [Exception]
{
$Message = "Unable to create $ProfileName profile: $_"
exit
}
$Message = "Complete."
2. Copie el texto siguiente y guárdelo como VPNProfile.xml en la misma carpeta que usercert.ps1.
Modifique el texto siguiente para adaptarlo a su entorno:
<Servers>azuregateway-1234-56-78dc.cloudapp.net</Servers> <= Can be found in the VpnSettings.xml in
the downloaded profile zip file
<PrefixSize>32</PrefixSize> <= Subnet mask
<VPNProfile>
<NativeProfile>
<Servers>azuregateway-b115055e-0882-49bc-a9b9-7de45cba12c0-8e6946892333.vpn.azure.com</Servers>
<NativeProtocolType>IKEv2</NativeProtocolType>
<Authentication>
<UserMethod>Eap</UserMethod>
<Eap>
<Configuration>
<EapHostConfig xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><EapMethod><Type
xmlns="http://www.microsoft.com/provisioning/EapCommon">13</Type><VendorId
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorId><VendorType
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</VendorType><AuthorId
xmlns="http://www.microsoft.com/provisioning/EapCommon">0</AuthorId></EapMethod><Config
xmlns="http://www.microsoft.com/provisioning/EapHostConfig"><Eap
xmlns="http://www.microsoft.com/provisioning/BaseEapConnectionPropertiesV1"><Type>13</Type><EapType
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV1"><CredentialsSource>
<CertificateStore><SimpleCertSelection>true</SimpleCertSelection></CertificateStore>
</CredentialsSource><ServerValidation>
<DisableUserPromptForServerValidation>false</DisableUserPromptForServerValidation><ServerNames>
</ServerNames></ServerValidation><DifferentUsername>false</DifferentUsername><PerformServerValidation
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</PerformServerValida
tion><AcceptServerName
xmlns="http://www.microsoft.com/provisioning/EapTlsConnectionPropertiesV2">false</AcceptServerName>
</EapType></Eap></Config></EapHostConfig>
</Configuration>
</Eap>
</Authentication>
<RoutingPolicyType>SplitTunnel</RoutingPolicyType>

<Route>
</Route>
<Route>
</Route>

<TrafficFilter>
<RemoteAddressRanges>192.168.3.4, 192.168.3.5</RemoteAddressRanges>
</TrafficFilter>

<RememberCredentials>true</RememberCredentials>

<RegisterDNS>true</RegisterDNS>
</VPNProfile>
3. Ejecute PowerShell como administrador.

4. En PowerShell, vaya la carpeta donde se encuentra usercert.ps1 y VPNProfile.xml y ejecute el siguiente
comando:
C:\> .\usercert.ps1 .\VPNProfile.xml UserTest

5. En Configuración de VPN , busque la entrada UserTest y, a continuación, seleccione Conectar .
6. Si la conexión se realiza correctamente, habrá configurado correctamente un túnel de usuario de Always
On.
Eliminación de un perfil
Para quitar un perfil, use estos pasos:
1. Ejecute el siguiente comando:
C:\> Remove-VpnConnection UserTest
2. Desconecte la conexión y desactive la opción Conectar automáticamente .
Pasos siguientes
Para solucionar los problemas de conexión que puedan producirse, consulte Problemas de conexión de punto a
sitio de Azure.
Anuncio de rutas personalizadas para clientes VPN
de conexión de punto a sitio
Es posible que quiera anunciar rutas personalizadas a todos sus clientes VPN de punto a sitio. Por ejemplo,
cuando tiene puntos de conexión de almacenamiento habilitados en su red virtual y quiere que los usuarios
remotos puedan tener acceso a estas cuentas de almacenamiento a través de la conexión VPN. Puede anunciar
la dirección IP del punto de conexión de almacenamiento a todos sus usuarios remotos de modo que el tráfico a
la cuenta de almacenamiento pase por el túnel VPN y no por la red pública de Internet.
Para anunciar rutas personalizadas

Para anunciar rutas personalizadas, use Set-AzVirtualNetworkGateway cmdlet . En el siguiente ejemplo se le
muestra cómo anunciar la dirección IP para las tablas de cuentas de almacenamiento de Contoso.
1. Haga ping en contoso.table.core.windows.net y tenga en cuenta la dirección IP. Por ejemplo:
C:\>ping contoso.table.core.windows.net
Pinging table.by4prdstr05a.store.core.windows.net [13.88.144.250] with 32 bytes of data:
2. Ejecute los comandos de PowerShell siguientes:
$gw = Get-AzVirtualNetworkGateway -Name <name of gateway> -ResourceGroupName <name of resource group>

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -CustomRoute 13.88.144.250/32
3. Para agregar varias rutas personalizadas, use una coma y espacios para separar las direcciones. Por
ejemplo:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -CustomRoute x.x.x.x/xx , y.y.y.y/yy
Para ver rutas personalizadas

Use el siguiente ejemplo para ver rutas personalizadas:

$gw.CustomRoutes | Format-List
Para eliminar rutas personalizadas

Use el siguiente ejemplo para eliminar rutas personalizadas:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -CustomRoute @0
Pasos siguientes
Para obtener información de enrutamiento de conexión de punto a sitio adicional, consulte Acerca del
enrutamiento de punto a sitio.
Creación y configuración de directivas IPsec
personalizadas para punto a sitio (versión
preliminar)
Si su entorno requiere una directiva IPsec personalizada para el cifrado, puede configurar fácilmente un objeto
de directiva con los valores necesarios. Este artículo le ayuda a crear un objeto de directiva personalizado y, a
continuación, a configurarlo mediante PowerShell.
Antes de empezar
Requisitos previos
Compruebe que el entorno cumpla los siguientes requisitos previos:
Ya tiene configurada una VPN de punto a sitio que funciona. Si no es así, configure una con los pasos del
artículo Creación de una VPN de punto a sitio con PowerShell o Azure Portal.
1. Configuración de variables
Declare las variables que desea utilizar. Use el ejemplo siguiente y reemplace los valores por los suyos propios
simplemente copie y pegue los valores de nuevo para volver a declarar las variables.
$RG = "TestRG"
$GWName = "VNet1GW"
2. Creación de un objeto de directiva

Cree un objeto de directiva IPsec personalizada. Puede ajustar los valores para que cumplan los criterios que
necesite.
$vpnclientipsecpolicy = New-AzVpnClientIpsecPolicy -IpsecEncryption AES256 -IpsecIntegrity SHA256 -

SALifeTime 86471 -SADataSize 429496 -IkeEncryption AES256 -IkeIntegrity SHA384 -DhGroup DHGroup2 -PfsGroup
PFS2
3. Actualización de la puerta de enlace y establecimiento de la

directiva
En este paso, actualice la puerta de enlace de VPN P2S existente y establezca la directiva IPsec.
$gateway = Get-AzVirtualNetworkGateway -ResourceGroupName $RG -name $GWName

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gateway -VpnClientIpsecPolicy $vpnclientipsecpolicy
Pasos siguientes
Para más información sobre las configuraciones P2S, consulte Acerca de las conexiones VPN de punto a sitio.
Configuración de BGP en instancias de Azure VPN
Gateway
Este artículo le guiará por los pasos para habilitar BGP en una conexión de VPN de sitio a sitio (S2S) entre
locales y una conexión de red virtual a red virtual mediante Azure Portal.
Información acerca de BGP

de enrutamiento y disponibilidad entre dos o más redes. BGP permite que instancias de Azure VPN Gateway y
los dispositivos VPN locales, denominados vecinos o pares BGP, intercambien "rutas" que comunicarán a ambas
puertas de enlace la disponibilidad y la posibilidad de que dichos prefijos pasen a través de las puertas de
enlace o los enrutadores implicados. BGP también puede permitir el enrutamiento del tránsito entre varias redes
mediante la propagación de las rutas que una puerta de enlace de BGP aprende de un par BGP a todos los
demás pares BGP.
Para obtener más información sobre las ventajas de BGP y conocer los requisitos técnicos y las consideraciones
sobre el uso de BGP, consulte Información general de BGP con Azure VPN Gateway.
Introducción
Cada parte de este artículo le ayuda a constituir un bloque de creación básico para habilitar BGP en la
conectividad de red. Si completa las tres partes, podrá crear la topología tal como se muestra en el diagrama 1.
Diagrama 1
Puede combinar estos elementos juntos para crear una red de tránsito más compleja y de saltos múltiples que
satisfaga sus necesidades.
Requisitos previos
Parte 1: Configuración de BGP en la puerta de enlace de red virtual

En esta sección, creará y configurará una red virtual, creará y configurará una puerta de enlace de red virtual
con parámetros BGP, y obtendrá la dirección IP del par BGP de Azure. El diagrama 2 muestra los parámetros de
configuración que se deben usar al trabajar con los pasos de esta sección.
Diagrama 2
1. Creación y configuración de TestVNet1
En este paso, creará y configurará TestVNet1. Use los pasos del tutorial de creación de una puerta de enlace para
crear y configurar la red virtual de Azure y VPN Gateway. Use la configuración de referencia en las siguientes
capturas de pantalla.
Red virtual:
Subredes:
2. Creación de VPN Gateway para TestVNet1 con parámetros BGP

En este paso, creará una instancia de VPN Gateway con los parámetros BGP correspondientes.
1. En Azure Portal, vaya al recurso de puer ta de enlace de red vir tual de Marketplace y seleccione
Crear .
2. Rellene los parámetros como se muestra a continuación:
3. En la sección Configuración de BGP de la página, establezca la siguiente configuración:
Seleccione Configuración de BGP - Habilitada para mostrar la sección de configuración de

BGP.
Rellene el ASN (número de sistema autónomo).
El campo de dirección IP de BGP APIPA de Azure es opcional. Si sus dispositivos VPN locales
usan la dirección APIPA para BGP, debe seleccionar una dirección en el intervalo de direcciones
APIPA reservado de Azure para VPN, que se sitúa entre 169.254.21.0 y 169.254.22.255 . En este
ejemplo se usa 169.254.21.11.
Si crea una instancia de VPN Gateway activo-activo, en la sección de BGP se mostrará una
segunda dirección IP de BGP APIPA de Azure personalizada . Especifique una dirección
diferente del intervalo de APIPA permitido (169.254.21.0 a 169.254.22.255 ).
IMPORTANT
De forma predeterminada, Azure asigna una dirección IP privada desde el intervalo del prefijo
GatewaySubnet automáticamente como dirección IP de BGP de Azure en la instancia de Azure VPN
Gateway. La dirección de BGP APIPA de Azure es necesaria cuando los dispositivos VPN locales usan una
dirección APIPA (169.254.0.1 a 169.254.255.254) como dirección IP de BGP. Azure VPN Gateway elegirá la
dirección APIPA personalizada si el recurso de puerta de enlace de red local correspondiente (red local)
tiene una dirección APIPA como dirección IP del par BGP. Si la puerta de enlace de red local usa una
dirección IP normal (no APIPA), Azure VPN Gateway revertirá a la dirección IP privada del intervalo
GatewaySubnet.
Las direcciones de BGP APIPA no deben superponerse entre los dispositivos VPN locales y todas las
instancias de Azure VPN Gateway conectadas.
4. Seleccione Revisar y crear para ejecutar la validación. Una vez superada la validación, seleccione Crear
para implementar VPN Gateway. Una puerta de enlace puede tardar hasta 45 minutos en crearse e
implementarse completamente. Puede ver el estado de implementación en la página Información general
3. Obtenga las direcciones IP del par BGP de Azure
Una vez creada la puerta de enlace, puede obtener las direcciones IP del par BGP en la puerta de enlace de VPN
de Azure. Estas direcciones son necesarias para configurar los dispositivos VPN locales para establecer sesiones
de BGP con la puerta de enlace de VPN de Azure.
1. Vaya al recurso de puerta de enlace de red virtual y seleccione la página Configuración para ver la
información de configuración de BGP como se muestra en la siguiente captura de pantalla. En esta
página, puede ver toda la información de configuración de BGP en la instancia de Azure VPN Gateway:
ASN, una dirección IP pública y las direcciones IP del par BGP correspondientes en Azure
(predeterminadas y APIPA).
2. En la página Configuración , puede realizar los siguientes cambios de configuración:
Puede actualizar el ASN o la dirección IP de BGP APIPA si es necesario.
Si tiene una instancia de VPN Gateway activo-activo, se mostrará en esta página la dirección IP
pública, la predeterminada y direcciones IP de BGP APIPA de la segunda instancia de Azure VPN
Gateway.
3. Si realizó algún cambio, seleccione Guardar para confirmar los cambios en la instancia de Azure VPN
Gateway.
Parte 2: Configuración de BGP en conexiones S2S entre locales

Para establecer una conexión entre locales, debe crear una puerta de enlace de red local para representar el
dispositivo VPN local y una conexión para conectarse a la instancia de VPN Gateway con la puerta de enlace de
red local como se explica en Creación de una conexión de sitio a sitio. En este artículo se incluyen las
propiedades adicionales necesarias para especificar los parámetros de configuración de BGP.
Diagrama 3
1. Configuración de BGP en la puerta de enlace de red local

En este paso, configurará BGP en la puerta de enlace de red local. Use la siguiente captura de pantalla como
ejemplo. En la captura de pantalla se muestra la puerta de enlace de red local (Site5) con los parámetros
especificados en el diagrama 3.
Consideraciones importantes sobre la configuración
El ASN y la dirección IP del par BGP deben coincidir con la configuración del enrutador VPN local.
Puede dejar el especio de direcciones vacío solo si usa BGP para conectarse a esta red. Azure VPN
Gateway agregará de forma interna una ruta de la dirección IP del par BGP al túnel IPsec correspondiente. Si
NO usa BGP entre la instancia de Azure VPN Gateway y esta red en particular, debe proporcionar una lista
de prefijos de dirección válidos para el espacio de direcciones .
Opcionalmente, puede usar una dirección IP APIPA (169.254.x.x) como dirección IP del par BGP local si es
necesario. Sin embargo, también tendrá que especificar una dirección IP APIPA como se ha descrito
anteriormente en este artículo para la instancia de Azure VPN Gateway; de lo contrario, la sesión de BGP no
podrá establecerse para esta conexión.
Puede especificar la información de configuración de BGP durante la creación de la puerta de enlace de red
local, o bien puede agregar o cambiar la configuración de BGP en la página Configuración del recurso de
puerta de enlace de red local.
Ejemplo
En este ejemplo de usa una dirección APIPA (169.254.100.1) como dirección IP del par BGP local:
2. Configuración de una conexión S2S con BGP habilitado

En este paso, creará una nueva conexión con BGP habilitado. Si ya tiene una conexión y desea habilitar BGP en
ella, puede actualizar una conexión existente.
Para crear una conexión con BGP habilitado
Para crear una nueva conexión con BGP habilitado, en la página Agregar conexión , rellene los valores y, a
continuación, active la opción Habilitar BGP para habilitar BGP en esta conexión. Seleccione Aceptar para
crear la conexión.
Para actualizar una conexión existente

Si desea cambiar la opción de BGP en una conexión, vaya a la página Configuración del recurso de conexión y,
a continuación, alterne la opción de BGP como se resalta en el siguiente ejemplo. Para guardar los cambios,
seleccione Guardar .
Parte 3: Configuración de BGP en conexiones de red virtual a red
virtual
Los pasos para habilitar o deshabilitar BGP en una conexión de red virtual a red virtual son los mismos que los
pasos de sitio a sitio de la parte 2. Puede habilitar BGP al crear la conexión o actualizar la configuración en una
conexión de red virtual a red virtual existente.
NOTE
Una conexión de red virtual a red virtual sin BGP limitará la comunicación solo a las dos redes virtuales conectadas.
Habilite BGP para permitir la funcionalidad de enrutamiento a otras conexiones de sitio a sitio o de red virtual a red virtual
de estas dos redes virtuales.
Para dar contexto, en referencia al diagrama 4 , si BGP fuera a deshabilitarse entre TestVNet2 y TestVNet1,
TestVNet2 no aprendería las rutas para la red local, Site5, y, por tanto, no podría comunicarse con el Site5. Una
vez que habilite BGP, como se muestra en el diagrama 4, las tres redes podrán comunicarse a través de las
conexiones de IPsec y de red virtual a red virtual.
Diagrama 4
Pasos siguientes
Configuración de BGP para Azure VPN Gateway
con PowerShell
Este artículo le guiará por los pasos para habilitar BGP en una conexión de VPN de sitio a sitio (S2S) entre
locales y una conexión de red virtual a red virtual mediante el modelo de implementación de Resource Manager
y PowerShell.

de enrutamiento y disponibilidad entre dos o más redes. BGP permite que las puertas de enlace de VPN de
Azure y los dispositivos VPN locales, denominados vecinos o pares BGP, intercambien "rutas" que comunicarán a
ambas puertas de enlace la disponibilidad y la posibilidad de que dichos prefijos pasen a través de las puertas
de enlace o los enrutadores implicados. BGP también puede permitir el enrutamiento del tránsito entre varias
redes mediante la propagación de las rutas que una puerta de enlace de BGP aprende de un par BGP a todos los
demás pares BGP.
Para obtener más información sobre las ventajas de BGP, así como entender los requisitos técnicos y las
consideraciones sobre el uso de BGP, consulte Información general de BGP con Azure VPN Gateway.
Introducción a BGP en puertas de enlace de VPN de Azure

Este artículo lo guiará a través de los pasos necesarios para realizar las tareas siguientes:
Parte 1: Habilitar BGP en la puerta de enlace de VPN de Azure
Parte 2: Establecer una conexión entre locales con BGP
Parte 3: Establecer una conexión de red virtual a red virtual con BGP
Cada parte de las instrucciones constituye un bloque de creación básico para habilitar BGP en la conectividad de
red. Si completa las tres partes, podrá crear la topología tal como se muestra en el diagrama siguiente:
Puede combinar estos elementos juntos para crear una red de tránsito más compleja y de saltos múltiples que
satisfaga sus necesidades.
Parte 1: Configurar BGP en Azure VPN Gateway

Los siguientes pasos de configuración permiten establecer los parámetros BGP de Azure VPN Gateway como se
Antes de empezar
Instale los cmdlets de PowerShell de Azure Resource Manager. Consulte Instalación y configuración de Azure
PowerShell para más información sobre cómo instalar los cmdlets de PowerShell.
Paso 1: Creación y configuración de VNet1
1. Declaración de las variables
Para este ejercicio, se empieza por declarar las variables. En este ejemplo se declaran las variables con los
valores para este ejercicio. Asegúrese de reemplazar los valores por los suyos propios cuando realice la
configuración para el entorno de producción. Puede usar estas variables si está practicando los pasos para
familiarizarse con este tipo de configuración. Modifique las variables y después copie y pegue todo en la consola
de PowerShell.
$Sub1 = "Replace_With_Your_Subscription_Name"
$RG1 = "TestBGPRG1"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$VNet1ASN = 65010
$DNS1 = "8.8.8.8"
2. Conexión a su suscripción y creación de un nuevo grupo de recursos

Para usar los cmdlets de Resource Manager, asegúrese de cambiar al modo de PowerShell. Para obtener más
información, consulte Uso de Windows PowerShell con el Administrador de recursos.
Abre la consola de PowerShell y conéctate a tu cuenta. Use el siguiente ejemplo para ayudarle a conectarse:
Connect-AzAccount
3. Creación de TestVNet1
En el siguiente ejemplo se crea una red virtual denominada "TestVNet1" y tres subredes: GatewaySubnet,
FrontEnd y Backend. Al reemplazar valores, es importante que siempre asigne el nombre GatewaySubnet a la
subred de la puerta de enlace. Si usa otro, se produce un error al crear la puerta de enlace.

Paso 2: Creación de la puerta de enlace de VPN para TestVNet1 con parámetros BGP
1. Cree las configuraciones de IP y de subred
Solicite que se asigne una dirección IP pública a la puerta de enlace que creará para la red virtual. También
definirá las configuraciones de subred y de IP necesarias.
$gwpip1 = New-AzPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 -Location $Location1 -


$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 -Subnet $subnet1 -PublicIpAddress
$gwpip1
2. Cree la puerta de enlace de VPN con el número de AS

Cree la puerta de enlace de red virtual para TestVNet1. BGP requiere una VPN Gateway basada en una ruta y
también el parámetro de suma, - Asn, con el fin de establecer el ASN (número de AS) para TestVNet1. Si no
establece el parámetro ASN, se asignará ASN 65515. Se tardan unos 30 minutos o algo más en crear una puerta
de enlace.
New-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 -Location $Location1 -IpConfigurations

$gwipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -Asn $VNet1ASN
3. Obtenga la dirección IP del par BGP de Azure

Una vez creada la puerta de enlace, debe obtener la dirección IP del par BGP en Azure VPN Gateway. Esta
dirección es necesaria para configurar la instancia de Azure VPN Gateway como par BGP para los dispositivos
de VPN local.

$vnet1gw.BgpSettingsText
El último comando mostrará las configuraciones de BGP correspondientes en Azure VPN Gateway; por ejemplo:
$vnet1gw.BgpSettingsText
{
"Asn": 65010,
"BgpPeeringAddress": "10.12.255.30",
"PeerWeight": 0
}
Una vez creada la puerta de enlace, puede usar esta puerta de enlace para establecer conexión entre locales o
conexión de red virtual a red virtual con BGP. Las siguientes secciones lo guiarán por los pasos necesarios para
completar el ejercicio.
Parte 2: Establecer una conexión entre locales con BGP

dispositivo VPN local y una conexión para conectarse a VPN Gateway con la puerta de enlace de red local.
Aunque hay artículos que lo guiarán a través de estos pasos, este contiene las propiedades adicionales
necesarias para especificar los parámetros de configuración de BGP.
Antes de continuar, asegúrese de que ha completado la parte 1 de este ejercicio.

Paso 1: Cree y configure la puerta de enlace de red local
Este ejercicio es continuación del paso de creación de la configuración mostrada en el diagrama. Asegúrese de
reemplazar los valores por los que desea usar para su configuración.
$RG5 = "TestBGPRG5"
$LNGName5 = "Site5"
$LNGPrefix50 = "10.52.255.254/32"
$LNGIP5 = "Your_VPN_Device_IP"
$LNGASN5 = 65050
$BGPPeerIP5 = "10.52.255.254"
Un par de cosas a tener en cuenta con respecto a los parámetros de la puerta de enlace de red local:
La puerta de enlace de red local puede estar en la misma ubicación y grupo de recursos que la puerta de
enlace de VPN o en otros distintos. Este ejemplo los muestra en distintos grupos de recursos en diferentes
ubicaciones.
El prefijo que debe declarar para la puerta de enlace de red local es la dirección del host de la dirección IP del
par BGP en el dispositivo VPN. En este caso, es un prefijo /32 de "10.52.255.254/32".
Como recordatorio, debe usar diferentes ASN de BGP entre las redes locales y la red virtual de Azure. Si son
iguales, tiene que cambiar el ASN de la red virtual si el dispositivo VPN local ya utiliza el ASN para
emparejarse con otros vecinos de BGP.
Antes de continuar, asegúrese de que sigue conectado a la suscripción 1.
2. Cree las puertas de enlace de red local para Site5
Asegúrese de crear el grupo de recursos si no está ya creado, antes de crear la puerta de enlace de red local.
Observe los dos parámetros adicionales de la puerta de enlace de red local: Asn y BgpPeerAddress.
New-AzLocalNetworkGateway -Name $LNGName5 -ResourceGroupName $RG5 -Location $Location5 -GatewayIpAddress

$LNGIP5 -AddressPrefix $LNGPrefix50 -Asn $LNGASN5 -BgpPeeringAddress $BGPPeerIP5
Paso 2: Conecte la puerta de enlace de red virtual y la puerta de enlace de red local
1. Obtenga las dos puertas de enlace

$lng5gw = Get-AzLocalNetworkGateway -Name $LNGName5 -ResourceGroupName $RG5
2. Cree la conexión de TestVNet1 a Site5

En este paso, creará la conexión de TestVNet1 a Site5. Debe especificar "-EnableBGP True" para habilitar BGP
para esta conexión. Como se explicó anteriormente, es posible tener conexiones BGP y no BGP para la misma
instancia de Azure VPN Gateway. A menos que BGP esté habilitado en la propiedad de conexión, Azure no
habilitará BGP para esta conexión, aunque los parámetros BGP ya estén configurados en ambas puertas de
enlace.
New-AzVirtualNetworkGatewayConnection -Name $Connection15 -ResourceGroupName $RG1 -VirtualNetworkGateway1

$vnet1gw -LocalNetworkGateway2 $lng5gw -Location $Location1 -ConnectionType IPsec -SharedKey 'AzureA1b2C3' -
EnableBGP $True
En el ejemplo siguiente se enumeran los parámetros que deberá especificar en la sección de configuración de
BGP en el dispositivo VPN local para este ejercicio:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.254
- Prefixes to announce : (for example) 10.51.0.0/16 and 10.52.0.0/16
- Azure VNet ASN : 65010
- Azure VNet BGP IP : 10.12.255.30
- Static route : Add a route for 10.12.255.30/32, with nexthop being the VPN tunnel interface on
your device
- eBGP Multihop : Ensure the "multihop" option for eBGP is enabled on your device if needed
La conexión se establece después de unos minutos y se iniciará la sesión de emparejamiento BGP una vez
establecida la conexión IPsec.
Parte 3: Establecer una conexión de red virtual a red virtual con BGP
En esta sección se agrega una conexión de red virtual a red virtual con BGP, tal como se muestra en el diagrama
siguiente:
Las siguientes instrucciones son continuación de los pasos anteriores. Debe completar la Parte 1 para crear y
configurar TestVNet1 y VPN Gateway con BGP.
Paso 1: cree TestVNet2 y la puerta de enlace de VPN
con ninguno de sus intervalos de red virtual.
En este ejemplo, las redes virtuales pertenecen a la misma suscripción. Se pueden configurar conexiones de red
virtual a red virtual entre distintas suscripciones. Para obtener más información, consulte Configuración de una
conexión de red virtual a red virtual. Asegúrese de agregar "-EnableBgp True" al crear las conexiones para
habilitar BGP.
Asegúrese de reemplazar los valores por los que desea usar para su configuración.
$RG2 = "TestBGPRG2"
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$VNet2ASN = 65020
$DNS2 = "8.8.8.8"
2. Cree TestVNet2 en el nuevo grupo de recursos


3. Cree la puerta de enlace de VPN para TestVNet2 con parámetros BGP

Solicite que se asigne una dirección IP pública a la puerta de enlace que creará para la red virtual y defina las
configuraciones de IP y subred requeridas.


$gwpip2
Cree la puerta de enlace de VPN con el número de AS. Debe reemplazar el valor predeterminado del ASN en
Azure VPN Gateway. Los ASN para las redes virtuales conectadas deben ser diferentes para habilitar el
enrutamiento de tránsito y de BGP.

Paso 2: Conecte las puertas de enlace de TestVNet1 y TestVNet2

En este ejemplo, ambas puertas de enlace están en la misma suscripción. Puede completar este paso en la
misma sesión de PowerShell.
1. Obtenga ambas puertas de enlace
Asegúrese de iniciar sesión y conectarse a la suscripción 1.
2. Cree ambas conexiones

En este paso, creará la conexión de TestVNet1 a TestVNet2 y viceversa.

$vnet1gw -VirtualNetworkGateway2 $vnet2gw -Location $Location1 -ConnectionType Vnet2Vnet -SharedKey
'AzureA1b2C3' -EnableBgp $True

IMPORTANT
Asegúrese de habilitar BGP para AMBAS conexiones.
Después de completar estos pasos, se establece la conexión después de unos minutos. La sesión de
emparejamiento BGP funcionará una vez completada la conexión de red virtual a red virtual.
Si ha completado las tres partes de este ejercicio, habrá establecido la siguiente topología de red:
Pasos siguientes
Configuración de BGP en Azure VPN Gateway con
la CLI
Este artículo le ayudará a habilitar BGP en una conexión de VPN de sitio a sitio (S2S) entre locales y una
conexión de red virtual a red virtual (es decir, una conexión entre redes virtuales) mediante el modelo de
implementación de Azure Resource Manager y la CLI de Azure.

de enrutamiento y disponibilidad entre dos o más redes. BGP permite a Azure VPN Gateway y a los dispositivos
locales de VPN, denominados vecinos o pares BGP, intercambiar rutas. Las rutas informan a ambas puertas de
enlace sobre la disponibilidad y accesibilidad de los prefijos para pasar por las puertas de enlace o los
enrutadores pertinentes. BGP también permite el enrutamiento del tráfico entre varias redes mediante la
propagación de las rutas de aprendizaje de la puerta de enlace de BGP desde un par BGP a todos los demás
pares BGP.
Para obtener más información sobre las ventajas de BGP y conocer los requisitos técnicos y las consideraciones
sobre el uso de BGP, consulte Información general de BGP con Azure VPN Gateway.
Este artículo resulta útil para las siguientes tareas:
Habilitar BGP para VPN Gateway (obligatorio)
Después, puede completar cualquiera de las siguientes secciones, o ambas:
Establecer una conexión entre locales con BGP
Establecer una conexión de red virtual a red virtual con BGP
Cada una de estas tres secciones constituye un bloque de creación básico para habilitar BGP en la conectividad
de red. Si completa las tres secciones, podrá crear la topología tal como se muestra en el diagrama siguiente:
Puede combinar estas secciones para crear una red de tránsito más compleja y de saltos múltiples que satisfaga
sus necesidades.
Habilitar BGP para VPN Gateway

Esta sección es necesaria antes de realizar alguno de los pasos de las otras dos secciones de configuración. Los
siguientes pasos de configuración permiten establecer los parámetros BGP de Azure VPN Gateway como se
Antes de empezar
Instale la versión más reciente de los comandos de la CLI (2.0 o posteriores). Para más información acerca de la
instalación de los comandos de la CLI, consulte Instalación de la CLI de Azure y Introducción a la CLI de Azure.
1. su suscripción
az login
2. Crear un grupo de recursos

En el ejemplo siguiente se crea un grupo de recursos con el nombre "TestRG1" en la ubicación "eastus". Si ya
tiene un grupo de recursos en la región en la que desea crear la red virtual, puede utilizar ese.
az group create --name TestBGPRG1 --location eastus
El siguiente ejemplo crea una red virtual denominada TestVNet1 y tres subredes: GatewaySubnet, FrontEnd y
BackEnd. Al reemplazar valores, es importante que siempre asigne el nombre "GatewaySubnet" a la subred de la
puerta de enlace. Si usa otro, se produce un error al crear la puerta de enlace.
El primer comando crea el espacio de direcciones de front-end y la subred de front-end. El segundo comando
crea otro espacio de direcciones para la subred de back-end. Los comandos terceros y cuarto crean la subred
Backend y GatewaySubnet.
az network vnet create -n TestVNet1 -g TestBGPRG1 --address-prefix 10.11.0.0/16 -l eastus --subnet-name

az network vnet update -n TestVNet1 --address-prefixes 10.11.0.0/16 10.12.0.0/16 -g TestBGPRG1
az network vnet subnet create --vnet-name TestVNet1 -n BackEnd -g TestBGPRG1 --address-prefix 10.12.0.0/24
az network vnet subnet create --vnet-name TestVNet1 -n GatewaySubnet -g TestBGPRG1 --address-prefix

10.12.255.0/27
Paso 2: Creación de VPN Gateway para TestVNet1 con parámetros BGP
1. Crear la dirección IP pública
Pida una dirección IP pública. La dirección IP pública se asignará a la instancia de VPN Gateway creada para la
red virtual.
az network public-ip create -n GWPubIP -g TestBGPRG1 --allocation-method Dynamic

Cree la puerta de enlace de red virtual para TestVNet1. BGP requiere una instancia de VPN Gateway basada en
rutas. También necesita el parámetro adicional -Asn para establecer el número de sistema autónomo (ASN)
para TestVNet1. Se tardan unos 45 minutos o algo más en crear una puerta de enlace.
Si este comando se ejecuta con el parámetro --no-wait , no se verán los comentarios o resultados. Este
parámetro --no-wait permite que la puerta de enlace se cree en segundo plano. No significa que la puerta de
enlace de VPN se cree de inmediato.
az network vnet-gateway create -n VNet1GW -l eastus --public-ip-address GWPubIP -g TestBGPRG1 --vnet

TestVNet1 --gateway-type Vpn --sku HighPerformance --vpn-type RouteBased --asn 65010 --no-wait
3. Obtención de la dirección IP del par BGP de Azure

Después de crear la puerta de enlace, debe obtener la dirección IP del par BGP en Azure VPN Gateway. Esta
dirección es necesaria para configurar VPN Gateway como par BGP para los dispositivos de VPN local.
Ejecute el comando siguiente y consulte la sección de bgpSettings en la parte superior de la salida:
az network vnet-gateway list -g TestBGPRG1
"bgpSettings": {
"asn": 65010,
"peerWeight": 0
}
Después de crear la puerta de enlace, puede usarla para establecer una conexión entre locales o una conexión
de red virtual a red virtual con BGP.
Establecer una conexión entre locales con BGP

dispositivo VPN local. A continuación, conecte Azure VPN Gateway con la puerta de enlace de red local. Aunque
estos pasos son similares a la creación de otras conexiones, incluyen propiedades adicionales para especificar
los parámetros de configuración de BGP.

Este ejercicio es continuación del paso de creación de la configuración mostrada en el diagrama. Asegúrese de
reemplazar los valores por los que desea usar para su configuración. Cuando trabaje con puertas de enlace de
red local, tenga en cuenta los siguientes aspectos:
enlace de VPN o en una ubicación y grupo de recurso distintos. Este ejemplo los muestra las puertas de
enlace en distintos grupos de recursos en diferentes ubicaciones.
El prefijo mínimo que debe declarar para la puerta de enlace de red local es la dirección del host de la
dirección IP del par BGP en el dispositivo VPN. En este caso, es un prefijo /32 de 10.51.255.254/32.
iguales, debe cambiar el ASN de la red virtual si los dispositivos VPN locales ya utilizan el ASN para estar al
mismo nivel que otros vecinos BGP.
Antes de continuar, asegúrese de haber completado la sección Habilitar BGP para VPN Gateway de este ejercicio
y de que aún está conectado a la suscripción 1. Tenga en cuenta que, en este ejemplo, se crea un grupo de
recursos. Además, observe los dos parámetros adicionales para la puerta de enlace de red local: Asn y
BgpPeerAddress .
az group create -n TestBGPRG5 -l eastus2
az network local-gateway create --gateway-ip-address 23.99.221.164 -n Site5 -g TestBGPRG5 --local-address-

prefixes 10.51.255.254/32 --asn 65050 --bgp-peering-address 10.51.255.254
En este paso, creará la conexión de TestVNet1 a Site5. Debe especificar el parámetro --enable-bgp para habilitar
BGP para esta conexión.
En este ejemplo, la puerta de enlace de red virtual y la puerta de enlace de red local están en distintos grupos de
recursos. Cuando las puertas de enlace están en distintos grupos de recursos, debe especificar el identificador
de recurso completo de las dos puertas de enlace para establecer una conexión entre las redes virtuales.
1. Obtención del id. de recurso de VNet1GW
Use la salida del siguiente comando para obtener el id. de recurso de VNet1GW:
az network vnet-gateway show -n VNet1GW -g TestBGPRG1
En la salida, busque la línea "id": . Necesita los valores entrecomillados para crear la conexión en la sección
siguiente.
Salida de ejemplo:
{
"bgpSettings": {
"asn": 65010,
"peerWeight": 0
},
"enableBgp": true,
"etag": "W/\"<your etag number>\"",
ID>/resourceGroups/TestBGPRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW",
Copie estos valores después de "id": en un editor de texto, como el Bloc de notas, para que pueda pegarlos
fácilmente al crear la conexión.
ID>/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW"
2. Obtención del id. de recurso de Site5

Use el siguiente comando para obtener el id. de recurso de Site5 de la salida:
az network local-gateway show -n Site5 -g TestBGPRG5
3. Creación de la conexión de TestVNet1 a Site5

En este paso, creará la conexión de TestVNet1 a Site5. Como se explicó anteriormente, es posible tener
conexiones BGP y no BGP para la misma instancia de Azure VPN Gateway. A menos que BGP esté habilitado en
la propiedad de conexión, Azure no habilitará BGP para esta conexión, aunque los parámetros BGP ya estén
configurados en ambas puertas de enlace. Reemplace los identificadores de suscripción por los suyos propios.
az network vpn-connection create -n VNet1ToSite5 -g TestBGPRG1 --vnet-gateway1 /subscriptions/<subscription

ID>/resourceGroups/TestBGPRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW --enable-bgp -l
eastus --shared-key "abc123" --local-gateway2 /subscriptions/<subscription
ID>/resourceGroups/TestBGPRG5/providers/Microsoft.Network/localNetworkGateways/Site5 --no-wait
Para este ejercicio, en el ejemplo siguiente se enumeran los parámetros que deberá especificar en la sección de
configuración de BGP en el dispositivo VPN local:
Site5 ASN : 65050

Site5 BGP IP : 10.52.255.254
Prefixes to announce : (for example) 10.51.0.0/16 and 10.52.0.0/16
Azure VNet ASN : 65010
Azure VNet BGP IP : 10.12.255.30
Static route : Add a route for 10.12.255.30/32, with nexthop being the VPN tunnel interface on your
device
eBGP Multihop : Ensure the "multihop" option for eBGP is enabled on your device if needed
Después de unos minutos, la conexión debería haberse establecido. Se inicia la sesión de emparejamiento de
BGP después de establecer la conexión IPsec.
Establecer una conexión de red virtual a red virtual con BGP

En esta sección se agrega una conexión de red virtual a red virtual con BGP, tal como se muestra en el diagrama
siguiente:
Las siguientes instrucciones son la continuación de los pasos de las secciones previas. Debe completar la sección
Habilitar BGP para VPN Gateway para crear y configurar TestVNet1 y VPN Gateway con BGP.
Paso 1: Cree TestVNet2 y VPN Gateway
En este ejemplo, las redes virtuales pertenecen a la misma suscripción. Se pueden configurar conexiones de red
virtual a red virtual entre distintas suscripciones. Para más información, vea Configuración de una conexión de
red virtual a red virtual. Asegúrese de agregar -EnableBgp $True al crear las conexiones para habilitar BGP.
1. Creación de un nuevo grupo de recursos
az group create -n TestBGPRG2 -l westus

El primer comando crea el espacio de direcciones de front-end y la subred de front-end. El segundo comando
crea otro espacio de direcciones para la subred de back-end. Los comandos terceros y cuarto crean la subred
Backend y GatewaySubnet.
az network vnet create -n TestVNet2 -g TestBGPRG2 --address-prefix 10.21.0.0/16 -l westus --subnet-name

az network vnet update -n TestVNet2 --address-prefixes 10.21.0.0/16 10.22.0.0/16 -g TestBGPRG2
az network vnet subnet create --vnet-name TestVNet2 -n BackEnd -g TestBGPRG2 --address-prefix 10.22.0.0/24
az network vnet subnet create --vnet-name TestVNet2 -n GatewaySubnet -g TestBGPRG2 --address-prefix

10.22.255.0/27
3. Crear la dirección IP pública

Pida una dirección IP pública. La dirección IP pública se asignará a la instancia de VPN Gateway creada para la
red virtual.
az network public-ip create -n GWPubIP2 -g TestBGPRG2 --allocation-method Dynamic

Cree la puerta de enlace de red virtual para TestVNet2. Debe reemplazar el valor predeterminado del ASN en
Azure VPN Gateway. Los ASN para las redes virtuales conectadas deben ser diferentes para habilitar el
enrutamiento de tránsito y de BGP.
az network vnet-gateway create -n VNet2GW -l westus --public-ip-address GWPubIP2 -g TestBGPRG2 --vnet

TestVNet2 --gateway-type Vpn --sku Standard --vpn-type RouteBased --asn 65020 --no-wait

En este paso, creará la conexión de TestVNet1 a Site5. Debe especificar el parámetro --enable-bgp para habilitar
BGP para esta conexión.
En el ejemplo siguiente, la puerta de enlace de red virtual y la puerta de enlace de red local están en distintos
grupos de recursos. Cuando las puertas de enlace están en distintos grupos de recursos, debe especificar el
identificador de recurso completo de las dos puertas de enlace para establecer una conexión entre las redes
virtuales.
Obtenga el id. de recurso de VNet1GW de la salida del comando siguiente:

Obtenga el id. de recurso de VNet2GW de la salida del comando siguiente:
3. Crear las conexiones

Cree la conexión de TestVNet1 a TestVNet2 y viceversa. Reemplace los identificadores de suscripción por los
suyos propios.
az network vpn-connection create -n VNet1ToVNet2 -g TestBGPRG1 --vnet-gateway1 /subscriptions/<subscription

eastus --shared-key "efg456" --vnet-gateway2 /subscriptions/<subscription
ID>/resourceGroups/TestBGPRG2/providers/Microsoft.Network/virtualNetworkGateways/VNet2GW
az network vpn-connection create -n VNet2ToVNet1 -g TestBGPRG2 --vnet-gateway1 /subscriptions/<subscription

westus --shared-key "efg456" --vnet-gateway2 /subscriptions/<subscription
ID>/resourceGroups/TestBGPRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW
IMPORTANT
Habilite BGP para ambas conexiones.
Después de completar estos pasos, se establecerá la conexión en cuestión de minutos. La sesión de

emparejamiento BGP funcionará después de completar la conexión de red virtual a red virtual.
Pasos siguientes
Después de completar la conexión, puede agregar máquinas virtuales a las redes virtuales. Consulte Creación de
Visualización de las métricas y el estado de BGP
Puede ver las métricas y el estado de BGP mediante Azure Portal o Azure PowerShell.
Azure Portal
En Azure Portal, puede ver los pares BGP, las rutas aprendidas y las rutas anunciadas. También puede descargar
archivos .csv que contengan estos datos.
1. En Azure Portal, vaya a su puerta de enlace de red.
2. En Super visión , seleccione Pares BGP para abrir la página de pares BGP.
Rutas aprendidas
1. Puede ver hasta 50 rutas aprendidas en el portal.
2. También puede descargar el archivo de rutas aprendidas. Si tiene más de 50 rutas aprendidas, la única
manera de verlas todas es mediante la descarga y visualización del archivo .csv. Para descargarlo,
seleccione Download learned routes (descargar rutas aprendidas).
3. A continuación, vea el archivo.

Rutas anunciadas
1. Para ver las rutas anunciadas, seleccione ... al final de la red que quiera ver y, a continuación, haga clic en
View adver tised routes (ver rutas anunciadas).
2. En la página Rutas anunciadas al par , puede ver hasta 50 rutas anunciadas.
3. También puede descargar el archivo de rutas anunciadas. Si tiene más de 50 rutas anunciadas, la única
manera de verlas todas es mediante la descarga y visualización del archivo .csv. Para descargarlo,
seleccione Download adver tised routes (descargar rutas anunciadas).
Pares BGP
1. Puede ver hasta 50 pares BGP en el portal.
2. También puede descargar el archivo de pares BGP. Si tiene más de 50 pares BGP, la única manera de
verlas todas es mediante la descarga y visualización del archivo .csv. Para descargarlo, seleccione
Download BGP peers (descargar pares BGP) en la página del portal.

PowerShell
Use Get-AzVir tualNetworkGatewayBGPPeerStatus para ver todos los pares BGP y su estado.
Azure PowerShell.
Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName resourceGroup -VirtualNetworkGatewayName
gatewayName
Asn : 65515
ConnectedDuration : 9.01:04:53.5768637
LocalAddress : 10.1.0.254
MessagesReceived : 14893
MessagesSent : 14900
Neighbor : 10.0.0.254
RoutesReceived : 1
State : Connected
Use Get-AzVir tualNetworkGatewayLearnedRoute para ver todas las rutas que la puerta de enlace aprendió
a través de BGP.
Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName resourceGroup -VirtualNetworkGatewayname

gatewayName
AsPath :
Network : 10.1.0.0/16
NextHop :
Origin : Network
SourcePeer : 10.1.0.254
Weight : 32768
AsPath :
Network : 10.0.0.254/32
NextHop :
Origin : Network
Weight : 32768
AsPath : 65515
Network : 10.0.0.0/16
NextHop : 10.0.0.254
Origin : EBgp
Weight : 32768
Use Get-AzVir tualNetworkGatewayAdver tisedRoute para ver todas las rutas que la puerta de enlace está
anunciando a sus pares a través de BGP.
Get-AzVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName gatewayName -ResourceGroupName

resourceGroupName -Peer 10.0.0.254
Pasos siguientes
Para más información acerca de BGP, consulte Configuración de BGP para Azure VPN Gateway.
La tunelización forzada permite redirigir o forzar todo el tráfico vinculado a Internet de vuelta a su ubicación
local a través de un túnel VPN de sitio a sitio con fines de inspección y auditoría. Se trata de un requisito de
seguridad crítico en la mayoría de las directivas de las empresas de TI. Si no configura la tunelización forzada, el
tráfico de Internet desde las máquinas virtuales de Azure siempre va desde la infraestructura de red de Azure
directamente a Internet, sin la opción que permite inspeccionarlo o auditarlo. Un acceso no autorizado a Internet
puede provocar la divulgación de información u otros tipos de infracciones de seguridad.
La tunelización forzada puede configurarse mediante Azure PowerShell. No se puede configurar con Azure
Portal. Este artículo ayuda a configurar la tunelización forzada en las redes virtuales creadas mediante el modelo
de implementación de Resource Manager. Si quiere configurar la tunelización forzada en el modelo de
implementación clásico, vea Tunelización forzada: clásica.
Información acerca de la tunelización forzada

El siguiente diagrama ilustra cómo funciona la tunelización forzada.
En este ejemplo, la subred de front-end no usa tunelización forzada. Las cargas de trabajo de la subred Frontend
pueden continuar para aceptar y responder a las solicitudes de los clientes directamente desde Internet. Las
subredes Mid-tier y Backend usan la tunelización forzada. Las conexiones salientes desde estas dos subredes a
Internet se fuerzan o redirigen a un sitio local a través de uno de los túneles VPN de sitio a sitio (S2S).
Esto permite restringir e inspeccionar el acceso a Internet desde sus máquinas virtuales o servicios en la nube
en Azure, al tiempo que continúa posibilitando la arquitectura de varios niveles de servicio necesaria. Si no hay
ninguna carga de trabajo a través de Internet en las redes virtuales, también tiene la opción de aplicar la
tunelización forzada a redes virtuales completas.
Requisitos y consideraciones
La tunelización forzada en Azure se configura mediante rutas personalizadas definidas por el usuario de redes
virtuales. La redirección del tráfico a un sitio local se expresa como una ruta predeterminada a la puerta de
enlace de VPN de Azure. Para obtener más información sobre las redes virtuales y las rutas definidas por el
usuario, vea Rutas personalizadas definidas por el usuario.
Cada subred de la red virtual tiene una tabla de enrutamiento del sistema integrada. La tabla de
enrutamiento del sistema tiene los siguientes tres grupos de rutas:
Rutas de redes vir tuales locales: directamente a las máquinas virtuales de destino en la misma
red virtual.
Rutas locales: a Azure VPN Gateway.
Ruta predeterminada : directamente a Internet. Los paquetes destinados a las direcciones IP
privadas que no están cubiertos por las dos rutas anteriores se anularán.
Este procedimiento usa las rutas definidas por el usuario para crear una tabla de enrutamiento para
agregar una ruta predeterminada y, a continuación, asociar la tabla de enrutamiento a las subredes de la
red virtual para habilitar la tunelización forzada en esas subredes.
La tunelización forzada debe asociarse a una red virtual que tenga una puerta de enlace de VPN basada
en rutas. Deberá establecer un "sitio predeterminado" entre los sitios locales entre entornos conectados a
la red virtual. Además, el dispositivo VPN local debe configurarse con 0.0.0.0/0 como selectores de
tráfico.
La tunelización forzada ExpressRoute no se configura mediante este mecanismo, sino que se habilita
mediante el anuncio de una ruta predeterminada a través de las sesiones de emparejamiento BGP de
ExpressRoute. Para obtener más información, consulte la documentación de ExpressRoute.
Cuando se implementan la instancia de VPN Gateway y la puerta de enlace de ExpressRoute en la misma
red virtual, ya no se necesitan rutas definidas por el usuario (UDR), ya que la puerta de enlace de
ExpressRoute anunciará la configuración del "sitio predeterminado" en la red virtual.
Información general sobre la configuración

El procedimiento siguiente lo ayudará a crear un grupo de recursos y una red virtual. Después, creará una
puerta de enlace de VPN y configurará la tunelización forzada. En el procedimiento, la red virtual 'MultiTier-
VNet' tiene tres subredes: 'Frontend', 'Midtier' y 'Backend' con cuatro conexiones entre entornos:
'DefaultSiteHQ' y tres 'ramas'.
Los pasos del procedimiento establecerán 'DefaultSiteHQ' como la conexión de sitio predeterminada para la
tunelización forzada y configurarán las subredes 'Midtier' y 'Backend' para que usen dicha tunelización.
Antes de empezar
Instale la versión más reciente de los cmdlets de PowerShell de Azure Resource Manager. Consulte Cómo
instalar y configurar Azure PowerShell para obtener más información sobre cómo instalar los cmdlets de
PowerShell.
IMPORTANT
Es necesario instalar la versión más reciente de los cmdlets de PowerShell. En caso contrario, puede recibir errores de
validación al ejecutar algunos de los cmdlets.
Para iniciar sesión

Si PowerShell se ejecuta localmente, abra la consola de PowerShell con privilegios elevados y conéctese a su
cuenta de Azure. El cmdlet Connect-AzAccount le pide las credenciales. Después de la autenticación, descarga la
configuración de la cuenta para que esté disponible en Azure PowerShell.
Si usa Azure Cloud Shell, en lugar de ejecutar PowerShell localmente, observará que no es preciso ejecutar
Connect-AzAccount. Azure Cloud Shell se conecta a su cuenta de Azure automáticamente después de
seleccionar Probar .
1. Si ejecuta PowerShell localmente, inicie sesión.
Connect-AzAccount
2. Si tiene más de una suscripción, obtenga una lista de las suscripciones de Azure.
Get-AzSubscription

NOTE
Puede que vea advertencias que indican que "el tipo de objeto de salida de este cmdlet se va a modificar en una versión
futura". Este es el comportamiento esperado y puede ignorar estas advertencias.
New-AzResourceGroup -Name 'ForcedTunneling' -Location 'North Europe'
2. Cree una red virtual y especifique las subredes.
$s1 = New-AzVirtualNetworkSubnetConfig -Name "Frontend" -AddressPrefix "10.1.0.0/24"

$s2 = New-AzVirtualNetworkSubnetConfig -Name "Midtier" -AddressPrefix "10.1.1.0/24"
$s3 = New-AzVirtualNetworkSubnetConfig -Name "Backend" -AddressPrefix "10.1.2.0/24"
$s4 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix "10.1.200.0/28"
$vnet = New-AzVirtualNetwork -Name "MultiTier-VNet" -Location "North Europe" -ResourceGroupName
"ForcedTunneling" -AddressPrefix "10.1.0.0/16" -Subnet $s1,$s2,$s3,$s4
3. Cree las puertas de enlace de red local.
$lng1 = New-AzLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling" -

Location "North Europe" -GatewayIpAddress "111.111.111.111" -AddressPrefix "192.168.1.0/24"
$lng2 = New-AzLocalNetworkGateway -Name "Branch1" -ResourceGroupName "ForcedTunneling" -Location
"North Europe" -GatewayIpAddress "111.111.111.112" -AddressPrefix "192.168.2.0/24"
4. Cree la tabla de enrutamiento y la regla de enrutamiento.

New-AzRouteTable –Name "MyRouteTable" -ResourceGroupName "ForcedTunneling" –Location "North Europe"
$rt = Get-AzRouteTable –Name "MyRouteTable" -ResourceGroupName "ForcedTunneling"
Add-AzRouteConfig -Name "DefaultRoute" -AddressPrefix "0.0.0.0/0" -NextHopType VirtualNetworkGateway
-RouteTable $rt
Set-AzRouteTable -RouteTable $rt
5. Asocie la tabla de enrutamiento creada anteriormente a las subredes Midtier y Back-end.
$vnet = Get-AzVirtualNetwork -Name "MultiTier-Vnet" -ResourceGroupName "ForcedTunneling"

Set-AzVirtualNetworkSubnetConfig -Name "MidTier" -VirtualNetwork $vnet -AddressPrefix "10.1.1.0/24" -
RouteTable $rt
Set-AzVirtualNetworkSubnetConfig -Name "Backend" -VirtualNetwork $vnet -AddressPrefix "10.1.2.0/24" -
RouteTable $rt
Set-AzVirtualNetwork -VirtualNetwork $vnet
6. Cree la puerta de enlace de red virtual. Este paso tarda algún tiempo en completarse, a veces 45 minutos
o más, dado que va a crear y configurar la puerta de enlace. Si ve errores ValidateSet relacionados con el
valor de GatewaySku, compruebe que tiene instalada la versión más reciente de los cmdlets de
PowerShell. La versión más reciente de los cmdlets de PowerShell contiene los nuevos valores validados
para las SKU más recientes de la puerta de enlace.
$pip = New-AzPublicIpAddress -Name "GatewayIP" -ResourceGroupName "ForcedTunneling" -Location "North

Europe" -AllocationMethod Dynamic
$gwsubnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
$ipconfig = New-AzVirtualNetworkGatewayIpConfig -Name "gwIpConfig" -SubnetId $gwsubnet.Id -
PublicIpAddressId $pip.Id
New-AzVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling" -Location "North
Europe" -IpConfigurations $ipconfig -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -
EnableBgp $false
7. Asigne un sitio predeterminado a la puerta de enlace de red virtual. -GatewayDefaultSite es el

parámetro de cmdlet que permite que funcione la configuración de enrutamiento forzado, así que tenga
cuidado al configurar este valor correctamente.
$LocalGateway = Get-AzLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling"

$VirtualGateway = Get-AzVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling"
Set-AzVirtualNetworkGatewayDefaultSite -GatewayDefaultSite $LocalGateway -VirtualNetworkGateway
$VirtualGateway
8. Establezca las conexiones VPN de sitio a sitio.

$gateway = Get-AzVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName "ForcedTunneling"
$lng1 = Get-AzLocalNetworkGateway -Name "DefaultSiteHQ" -ResourceGroupName "ForcedTunneling"
$lng2 = Get-AzLocalNetworkGateway -Name "Branch1" -ResourceGroupName "ForcedTunneling"
New-AzVirtualNetworkGatewayConnection -Name "Connection1" -ResourceGroupName "ForcedTunneling" -

Location "North Europe" -VirtualNetworkGateway1 $gateway -LocalNetworkGateway2 $lng1 -ConnectionType
IPsec -SharedKey "preSharedKey"
Get-AzVirtualNetworkGatewayConnection -Name "Connection1" -ResourceGroupName "ForcedTunneling"

Configuración de la tunelización forzada mediante
el modelo de implementación clásica
seguridad crítico en la mayoría de las directivas de las empresas de TI. Sin la tunelización forzada, el tráfico
vinculado a Internet desde las máquinas virtuales en Azure siempre irá desde la infraestructura de red de Azure
directamente a Internet, sin la opción que permite inspeccionar o auditar el tráfico. Un acceso no autorizado a
Internet puede provocar la divulgación de información u otros tipos de infracciones de seguridad.
Azure actualmente funciona con dos modelos de implementación: el de Resource Manager y el clásico. Los dos
modelos no son totalmente compatibles entre sí. Antes de empezar, es preciso saber el modelo en que se desea
trabajar. Para obtener información sobre los modelos de implementación, consulte Modelos de implementación
de Azure. Si es la primera vez que usa Azure, se recomienda usar el modelo de implementación de Resource
Manager.
Este artículo le guiará a través del proceso de configuración de la tunelización forzada para redes virtuales
creadas mediante el modelo de implementación clásica. La tunelización forzada puede configurarse mediante el
uso de PowerShell, no a través del portal. Si quiere configurar la tunelización forzada para el modelo de
implementación de Resource Manager, seleccione el artículo de Resource Manager de la siguiente lista
desplegable:
La tunelización forzada en Azure se configura a través de rutas definidas por el usuario (UDR) de redes virtuales.
La redirección del tráfico a un sitio local se expresa como una ruta predeterminada a la puerta de enlace de VPN
de Azure. La sección siguiente muestra la limitación actual de la tabla de enrutamiento y las rutas de una
instancia de Azure Virtual Network:
red virtual.
Ruta predeterminada: directamente a Internet. Los paquetes destinados a las direcciones IP
Con la liberación de las rutas definidas por el usuario, puede crear una tabla de enrutamiento para
agregar una ruta predeterminada y, después, asociar la tabla de enrutamiento a las subredes de la red
virtual para habilitar la tunelización forzada en esas subredes.
Deberá establecer un "sitio predeterminado" entre los sitios locales entre entornos conectados a la red
virtual.
La tunelización forzada debe asociarse a una red virtual que tiene una puerta de enlace de VPN de
enrutamiento dinámico (no una puerta de enlace estática).
ExpressRoute. Para más información, consulte ¿Qué es ExpressRoute?

En el ejemplo siguiente, la subred Frontend no usa la tunelización forzada. Las cargas de trabajo de la subred
Frontend pueden continuar para aceptar y responder a las solicitudes de los clientes directamente desde
Internet. Las subredes Mid-tier y Backend usan la tunelización forzada. Las conexiones salientes desde estas dos
subredes a Internet se fuerzan o redirigen a un sitio local a través de uno de los túneles VPN de sitio a sitio.
en Azure, al tiempo que continúa posibilitando la arquitectura de varios niveles de servicio necesaria. También
tiene la opción de aplicar la tunelización forzada a redes virtuales completas si no hay ninguna carga de trabajo
a través de Internet en las redes virtuales.
Requisitos previos
Antes de comenzar con la configuración, verifique que dispone de los elementos siguientes:
Suscripción a Azure. Si todavía no la tiene, puede activar sus ventajas como suscriptor de MSDN o registrarse
para obtener una cuenta gratuita.
Una red virtual configurada.
Cuando se trabaja con el modelo de implementación clásica, no se puede usar Azure Cloud Shell. En su lugar,
debe instalar la versión más reciente de los cmdlets de PowerShell para Azure Service Management (SM) en
el equipo. Estos cmdlets son diferentes de los de AzureRM o Az. Para instalar los cmdlets de SM, consulte
Instalación de cmdlets de Service Management. Para más información sobre Azure PowerShell en general,
consulte la documentación de Azure PowerShell.

El siguiente procedimiento lo ayudará a especificar la tunelización forzada en una red virtual. Los pasos de
configuración corresponden al archivo de configuración de red virtual. En este ejemplo, la red virtual "MultiTier-
VNet" tiene tres subredes: las subredes "Frontend", "Midtier" y "Backend", con cuatro conexiones entre locales:
"DefaultSiteHQ" y tres ramas.
<VirtualNetworkSite name="MultiTier-VNet" Location="North Europe">
<AddressSpace>
</AddressSpace>
<Subnets>
<Subnet name="Frontend">
</Subnet>
<Subnet name="Midtier">
</Subnet>
<Subnet name="Backend">
</Subnet>
</Subnet>
</Subnets>
<Gateway>
<LocalNetworkSiteRef name="DefaultSiteHQ">
<LocalNetworkSiteRef name="Branch1">
</Gateway>
Los siguientes pasos establecerán "DefaultSiteHQ" como la conexión de sitio predeterminada para la
tunelización forzada y configurarán las subredes Midtier y Backend para que usen dicha tunelización.
1. Abra la consola de PowerShell con privilegios elevados. Conéctese a su cuenta mediante el ejemplo
siguiente:
Add-AzureAccount
2. Cree una tabla de enrutamiento. Use el siguiente cmdlet para crear la tabla de enrutamiento.
New-AzureRouteTable –Name "MyRouteTable" –Label "Routing Table for Forced Tunneling" –Location "North
Europe"
3. Agregue una ruta predeterminada a la tabla de enrutamiento.

El siguiente ejemplo agrega una ruta predeterminada a la tabla de enrutamiento que creó en el paso 1.
Tenga en cuenta que la única ruta admitida es el prefijo de destino de 0.0.0.0/0 para el próximo salto
VPNGateway.
Get-AzureRouteTable -Name "MyRouteTable" | Set-AzureRoute –RouteTable "MyRouteTable" –RouteName

"DefaultRoute" –AddressPrefix "0.0.0.0/0" –NextHopType VPNGateway
4. Asocie la tabla de enrutamiento a las subredes.

Una vez creada una tabla de enrutamiento y agregada una ruta, use el ejemplo siguiente para agregar o
asociar la tabla de enrutamiento a una subred de la red virtual. Los siguientes ejemplos agregan la tabla
de enrutamiento MyRouteTable a las subredes Midtier y Backend de VNet MultiTier-VNet.
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Midtier" -RouteTableName

"MyRouteTable"
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Backend" -RouteTableName
"MyRouteTable"
5. Asigne un sitio predeterminado para la tunelización forzada.

En el paso anterior, los scripts del cmdlet de ejemplo crean la tabla de enrutamiento y la tabla de
enrutamiento asociada a dos de las subredes de la red virtual. El paso restante consiste en seleccionar un
sitio local entre las conexiones de varios sitios de la red virtual como el sitio predeterminado o túnel.
$DefaultSite = @("DefaultSiteHQ")
Set-AzureVNetGatewayDefaultSite –VNetName "MultiTier-VNet" –DefaultSite "DefaultSiteHQ"
Cmdlets de PowerShell adicionales

Para eliminar una tabla de enrutamiento
Remove-AzureRouteTable -Name <routeTableName>
Para mostrar una tabla de enrutamiento
Get-AzureRouteTable [-Name <routeTableName> [-DetailLevel <detailLevel>]]
Para eliminar una ruta de una tabla de enrutamiento
Remove-AzureRouteTable –Name <routeTableName>
Para quitar una ruta de una subred
Remove-AzureSubnetRouteTable –VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
Para mostrar la tabla de enrutamiento asociada a una subred
Get-AzureSubnetRouteTable -VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
Para quitar un sitio predeterminado de una puerta de enlace de VPN de VNet
Remove-AzureVnetGatewayDefaultSite -VNetName <virtualNetworkName>

Configuración del tránsito de la puerta de enlace de
VPN para el emparejamiento de red virtual
Este artículo le ayuda a configurar el tránsito de la puerta de enlace para el emparejamiento de red virtual. El
emparejamiento de red virtual conecta perfectamente dos redes virtuales de Azure, combinando las dos redes
virtuales en una sola para favorecer la conectividad. El tránsito de puerta de enlace es una propiedad del
emparejamiento que permite que una red virtual utilice la puerta de enlace de VPN en la red virtual emparejada
para la conectividad entre locales o entre redes virtuales. El siguiente diagrama muestra cómo funciona el
tránsito de la puerta de enlace con el emparejamiento de red virtual.
En el diagrama, el tránsito de la puerta de enlace permite que las redes virtuales emparejadas usen Azure VPN
Gateway en Hub-RM. La conectividad disponible en la puerta de enlace de VPN, que incluye las conexiones S2S,
P2S y entre redes virtuales, se aplica a las tres redes virtuales. La opción de tránsito está disponible para el
emparejamiento entre modelos de implementación iguales o diferentes. Si está configurando el tránsito entre
distintos modelos de implementación, la red virtual del centro y la puerta de enlace de red virtual deben estar
en el modelo de implementación de Resource Manager, no en el modelo de implementación clásica.
En la arquitectura de red del tipo hub-and-spoke, el tránsito de la puerta de enlace permite que las redes
virtuales de radio compartan la puerta de enlace de VPN en el concentrador, en lugar de implementar puertas
de enlace de VPN en todas las redes virtuales de radio. Las rutas a las redes virtuales conectadas a la puerta de
enlace o a las redes locales se propagarán a las tablas de enrutamiento de las redes virtuales emparejadas
mediante el tránsito de la puerta de enlace. Puede deshabilitar la propagación automática de rutas de la puerta
de enlace de VPN. Cree una tabla de enrutamiento con la opción "Deshabilitar la propagación de rutas
BGP " y asóciela con las subredes para evitar la distribución de rutas en dichas subredes. Para más información,
consulte Tabla de enrutamiento de redes virtuales.
En este artículo, hay dos escenarios:
Mismo modelo de implementación : ambas redes virtuales se crean en el modelo de implementación de
Resource Manager.
Diferentes modelos de implementación : la red virtual de radio se crea en el modelo de implementación
clásica y la red virtual de centro y la puerta de enlace se encuentran en el modelo de implementación de
Resource Manager.
NOTE
Si realiza un cambio en la topología de la red y tiene clientes VPN de Windows, el paquete de cliente VPN para clientes de
Windows se debe descargar e instalar nuevamente para que los cambios se apliquen en el cliente.
Requisitos previos
Antes de comenzar, compruebe que dispone de las siguientes redes virtuales y permisos:
Redes virtuales
VN ET M O DELO DE IM P L EM EN TA C IÓ N P UERTA DE EN L A C E DE RED VIRT UA L
Hub-RM Resource Manager Sí
Spoke-RM Resource Manager No
Spoke-Classic Clásico No
Permisos
Las cuentas que use para crear un emparejamiento de redes virtuales deben tener los rol o permisos necesarios.
En el ejemplo siguiente, si fuera a emparejar dos redes virtuales llamadas Hub-RM y Spoke-Classic , la cuenta
debería tener los siguientes roles o permisos mínimos para cada red virtual:
M O DELO DE
VN ET IM P L EM EN TA C IÓ N RO L E P ERM ISO S
Hub-RM Resource Manager Colaborador de la red Microsoft.Network/virtualN

etworks/virtualNetworkPeer
ings/write
Clásico Colaborador de la red N/D

clásica
Spoke-Classic Resource Manager Colaborador de la red Microsoft.Network/virtualN

etworks/peer
Clásico Colaborador de la red Microsoft.ClassicNetwork/vi

clásica rtualNetworks/peer
Obtenga más información sobre los roles integrados y la asignación de permisos específicos a roles
personalizados (solo Resource Manager).
Mismo modelo de implementación

En este escenario, las redes virtuales están ambas en el modelo de implementación de Resource Manager. Use
los pasos siguientes para crear o actualizar los emparejamientos de red virtual para habilitar el tránsito de
puerta de enlace.
Para agregar un emparejamiento y habilitar el tránsito:
1. En Azure Portal, cree o actualice el emparejamiento de red virtual de Hub-RM. Vaya a la red virtual Hub-
RM . Seleccione Emparejamientos y, después, + Agregar para abrir Agregar emparejamiento .
2. En la página Agregar emparejamiento , configure los valores de This vir tual network (Esta red
virtual).
Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo. Ejemplo:
HubRMToSpokeRM
Tráfico hacia la red virtual remota: Permitir
Tráfico reenviado desde la red virtual remota: Permitir
Puerta de enlace de red virtual: Use this vir tual network's gateway (Usar la puerta de enlace
de esta red virtual)
3. En la misma página, continúe con la configuración de los valores de la red vir tual remota .
Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo. Ejemplo:
SpokeRMtoHubRM
Modelo de implementación: Resource Manager
Red virtual: Spoke-RM
Puerta de enlace de red virtual: Use the remote vir tual network's gateway (Usar la puerta de
enlace de esta red virtual)
4. Seleccione Agregar para crear el emparejamiento.
5. Compruebe que el estado de emparejamiento sea Conectado en ambas redes virtuales.
Para modificar un emparejamiento existente para el tránsito:
Si ya se ha creado el emparejamiento, puede modificarlo para el tránsito.
1. Vaya a la red virtual. Seleccione Emparejamientos y elija el emparejamiento que quiere modificar.
2. Actualice el emparejamiento de red virtual.
Tráfico reenviado a la red virtual; Permitir
Puerta de enlace de red virtual: Use remote vir tual network's gateway (Usar la puerta de
enlace de esta red virtual)
3. Guarde la configuración de emparejamiento.
Ejemplo de PowerShell
También puede usar PowerShell para crear o actualizar el emparejamiento con el ejemplo anterior. Reemplace
las variables por los nombres de las redes virtuales y los grupos de recursos.
$SpokeRG = "SpokeRG1"
$SpokeRM = "Spoke-RM"
$HubRG = "HubRG1"
$HubRM = "Hub-RM"
$spokermvnet = Get-AzVirtualNetwork -Name $SpokeRM -ResourceGroup $SpokeRG

$hubrmvnet = Get-AzVirtualNetwork -Name $HubRM -ResourceGroup $HubRG
Add-AzVirtualNetworkPeering `
-Name SpokeRMtoHubRM `
-VirtualNetwork $spokermvnet `
-RemoteVirtualNetworkId $hubrmvnet.Id `
-UseRemoteGateways
-Name HubRMToSpokeRM `
-VirtualNetwork $hubrmvnet `
-RemoteVirtualNetworkId $spokermvnet.Id `
-AllowGatewayTransit
Diferentes modelos de implementación

En esta configuración, la red virtual de radio Spoke-Classic está en el modelo de implementación clásica y la
red virtual de centro Hub-RM está en el modelo de implementación de Resource Manager. Al configurar el
tránsito entre los modelos de implementación, la puerta de enlace de red virtual debe estar configurada para la
red virtual de Resource Manager, no la red virtual clásica.
Con esta configuración, solo tiene que configurar la red virtual Hub-RM . No es necesario configurar nada en la
red virtual Spoke-Classic .
1. En Azure Portal, vaya a la red virtual Hub-RM , seleccione Emparejamientos y, luego, elija + Agregar .
2. En la página Agregar emparejamiento , configure los siguientes valores:
Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo. Ejemplo: HubRMToClassic
Puerta de enlace de red virtual: Use this vir tual network's gateway (Usar la puerta de enlace
de esta red virtual)
Red virtual remota: Clásico
3. Compruebe que la suscripción es correcta y, a continuación, seleccione la red virtual en la lista
desplegable.
4. Seleccione Agregar para agregar el emparejamiento.
5. Compruebe que el estado de emparejamiento sea Conectado en la red virtual Hub-RM.
Con esta configuración, no es necesario configurar nada en la red virtual Spoke-Classic . Una vez que el estado
muestra Conectado , la red virtual de radio puede usar la conectividad a través de la puerta de enlace de VPN
en la red virtual de centro.
Ejemplo de PowerShell
También puede usar PowerShell para crear o actualizar el emparejamiento con el ejemplo anterior. Reemplace
las variables y el identificador de la suscripción por los valores de la red virtual y de los grupos de recursos, así
como de la suscripción. Basta con crear un emparejamiento de red virtual en la red virtual del concentrador.
$HubRG = "HubRG1"
$HubRM = "Hub-RM"
$hubrmvnet = Get-AzVirtualNetwork -Name $HubRM -ResourceGroup $HubRG
-Name HubRMToClassic `
-VirtualNetwork $hubrmvnet `
-RemoteVirtualNetworkId "/subscriptions/<subscription Id>/resourceGroups/Default-
Networking/providers/Microsoft.ClassicNetwork/virtualNetworks/Spoke-Classic" `
-AllowGatewayTransit
Pasos siguientes
Obtenga más información acerca de las restricciones y comportamientos importantes del emparejamiento
de redes virtuales, así como la configuración del emparejamiento de redes virtuales antes de crear uno para
usarlo en un entorno de producción.
Aprenda a crear una topología del tipo hub-and-spoke con emparejamiento de redes virtuales y tránsito de
la puerta de enlace.
Creación de un emparejamiento de red virtual con el mismo modelo de implementación.
Creación de un emparejamiento de red virtual con distintos modelos de implementación.
Modificación de la configuración de la puerta de
enlace de red local mediante Azure Portal
A veces, cambia la configuración de la puerta de enlace de red local AddressPrefix o GatewayIPAddress. Este
artículo muestra cómo modificar la configuración de puerta de enlace de red local. También puede modificar
estas configuraciones mediante un método diferente, si selecciona una opción diferente de la lista siguiente:
Configuración de la puerta de enlace de red local

La siguiente captura de pantalla muestra la página Configuración de un recurso de puerta de enlace de red
local mediante el punto de conexión de dirección IP pública:
Esta es la página de configuración con un punto de conexión de FQDN:

Para modificar la dirección IP o el nombre de dominio completo de la
puerta de enlace
NOTE
No se puede cambiar una puerta de enlace de red local entre el punto de conexión de FQDN y el punto de conexión de
dirección IP. Debe eliminar todas las conexiones asociadas a esta puerta de enlace de red local, crear una nueva con el
nuevo punto de conexión (dirección IP o FQDN) y, a continuación, volver a crear las conexiones.
Si el dispositivo VPN al que desea conectarse ha cambiado su dirección IP pública, siga estos pasos para
modificar la puerta de enlace de red local:
1. En el recurso Puerta de enlace de red local, en la sección Configuración , seleccione Configuración .
2. En el cuadro Dirección IP , modifique la dirección IP.
3. Haga clic en Save (Guardar) para guardar la configuración.
Si el dispositivo VPN al que desea conectarse ha cambiado su FQDN (nombre de dominio completo), siga estos
pasos para modificar la puerta de enlace de red local:
2. En el cuadro FQDN , modifique el nombre de dominio.
3. Haga clic en Save (Guardar) para guardar la configuración.
Procedimiento para modificar los prefijos de direcciones IP

2. Agregue el espacio de direcciones IP en el cuadro Agregar otro intervalo de direcciones.
3. Haga clic en Guardar para guardar la configuración.
2. Seleccione "..." en la línea que contiene el prefijo que desea quitar.
3. Seleccione Quitar .
Para modificar la configuración de BGP

Para agregar o actualizar la configuración de BGP:
2. Seleccione "Configurar BGP" para mostrar o actualizar las configuraciones de BGP para esta puerta de
enlace de red local.
3. Agregue o actualice el número de sistema autónomo o la dirección IP del par BGP en los campos
correspondientes.
Para quitar la configuración de BGP:
2. Anule la selección de la opción "Configurar BGP" para quitar el ASN de BGP existente y la dirección IP del
par BGP.
Pasos siguientes
Puede comprobar la conexión de la puerta de enlace. Consulte Comprobación de una conexión de puerta de
enlace.
enlace de red local mediante PowerShell
A veces, cambia la configuración de la puerta de enlace de red local AddressPrefix o GatewayIPAddress. Este
artículo muestra cómo modificar la configuración de puerta de enlace de red local. También puede modificar
estas configuraciones mediante un método diferente, si selecciona una opción diferente de la lista siguiente:
Antes de empezar
Instale la versión más reciente de los cmdlets de PowerShell de Azure Resource Manager. Consulte Cómo
instalar y configurar Azure PowerShell para obtener más información sobre cómo instalar los cmdlets de
PowerShell.
Modificación de los prefijos de direcciones IP

2. Modifique los prefijos.

-AddressPrefix @('10.101.0.0/24','10.101.1.0/24','10.101.2.0/24')

Omita los prefijos que ya no necesite. En este ejemplo, ya no necesitamos el prefijo 10.101.2.0/24 (del ejemplo
anterior), por lo que se actualiza la puerta de enlace de la red local, sin incluir ese prefijo.
2. Establezca la puerta de enlace con los prefijos actualizados.

-AddressPrefix @('10.101.0.0/24','10.101.1.0/24')
Modificación de la dirección IP de la puerta de enlace

enlace de red local para reflejar ese cambio. Al modificar este valor, también puede modificar al mismo tiempo
los prefijos de dirección. Asegúrese de usar el nombre existente de la puerta de enlace de la red local para
sobrescribir la configuración actual. Si usa otro nombre, creará una nueva puerta de enlace de red local, en lugar
de sobrescribir la existente.
New-AzLocalNetworkGateway -Name Site1 `
-Location "East US" -AddressPrefix @('10.101.0.0/24','10.101.1.0/24') `
-GatewayIpAddress "5.4.3.2" -ResourceGroupName TestRG1
Pasos siguientes
enlace.
enlace de red local mediante la CLI de Azure
A veces, cambia la configuración Prefijo de dirección o Dirección IP de la puerta de enlace de la puerta de enlace
de red local. Este artículo muestra cómo modificar la configuración de puerta de enlace de red local. También
puede modificar estas configuraciones mediante un método diferente, si selecciona una opción diferente de la
lista siguiente:
Antes de empezar
Instale la versión más reciente de los comandos de la CLI (2.0 o posteriores). Para obtener más información
sobre la instalación de los comandos de la CLI, consulte Instalación de la CLI de Azure.
az login
Modificación de los prefijos de direcciones IP

Para modificar los prefijos de dirección IP de la puerta de enlace de red local (sin conexión de puerta de
enlace )
Si no dispone de una conexión de puerta de enlace y desea agregar o quitar prefijos de direcciones IP, utilice el
mismo comando que se usa para crear la puerta de enlace de red local, az network local-gateway create. Este
comando también se puede usar para actualizar la dirección IP de la puerta de enlace del dispositivo VPN. Para
sobrescribir la configuración actual, utilice el nombre existente de la puerta de enlace de red local. Si usa otro
nombre, creará una nueva puerta de enlace de red local, en lugar de sobrescribir la existente.
cambiar. Especifique solo los prefijos que desea conservar. En este caso, 10.0.0.0/24 y 20.0.0.0/24
az network local-gateway create --gateway-ip-address 23.99.221.164 --name Site2 -g TestRG1 --local-address-

prefixes 10.0.0.0/24 20.0.0.0/24
Para modificar los prefijos de dirección IP de la puerta de enlace de red local (conexión de puerta de enlace
existente )
Si tiene una conexión de puerta de enlace y desea agregar o quitar prefijos de direcciones IP, estos se pueden
actualizar mediante az network local-gateway update. Esto tendrá como resultado un tiempo de inactividad para
la conexión VPN. Al modificar los prefijos de direcciones IP, no preciso eliminar la puerta de enlace VPN.
cambiar. En este ejemplo, 10.0.0.0/24 y 20.0.0.0/24 ya están presentes. Agregamos los prefijos 30.0.0.0/24 y
40.0.0.0/24, y especificamos los cuatro prefijos al actualizar.
az network local-gateway update --local-address-prefixes 10.0.0.0/24 20.0.0.0/24 30.0.0.0/24 40.0.0.0/24 --

name VNet1toSite2 -g TestRG1
Modificación de la dirección IP de la puerta de enlace

Para modificar la puerta de enlace de red local "gatewayIpAddress"
enlace de red local para reflejar ese cambio. La dirección IP de puerta de enlace se puede cambiar sin quitar una
conexión de puerta de enlace VPN existente (si tiene una). Para modificar la dirección IP de puerta de enlace,
reemplace los valores "Site2" y "TestRG1" por los suyos propios mediante el comando az network local-gateway
update.
az network local-gateway update --gateway-ip-address 23.99.222.170 --name Site2 --resource-group TestRG1
Compruebe que la dirección IP sea correcta en la salida:
"gatewayIpAddress": "23.99.222.170",
Pasos siguientes
enlace.
Información general sobre las configuraciones de
dispositivo VPN asociado
Este artículo proporciona información general sobre configuraciones de dispositivos VPN locales para
conectarse a puertas de enlace de VPN de Azure. Se usará una red virtual de Azure de ejemplo y la
configuración de la puerta de enlace de VPN para conectarse a distintos dispositivos VPN locales usando los
mismos parámetros.
Requisitos de los dispositivos

Las puertas de enlace de VPN de Azure usan los conjuntos de protocolos IPsec o IKE estándar para túneles VPN
de sitio a sitio (S2S). Consulte Acerca de los dispositivos VPN para obtener una lista de los parámetros IPsec o
IKE y los algoritmos criptográficos para las puertas de enlace de VPN de Azure. También puede especificar los
algoritmos exactos y los niveles de clave para una conexión específica, como se describe en Acerca de los
requisitos criptográficos.
Un solo túnel VPN

La primera configuración del ejemplo consta de un solo túnel VPN S2S entre una puerta de enlace de VPN de
Azure y el dispositivo VPN local. Opcionalmente puede configurar Border Gateway Protocol (BGP) a través del
túnel VPN.
Para obtener instrucciones paso a paso para configurar un túnel VPN único, consulte la configuración de una
conexión de sitio a sitio. Las siguientes secciones especifican los parámetros de conexión para la configuración
de ejemplo y proporcionarán un script de PowerShell para ayudarle a empezar a trabajar.
Parámetros de conexión
Esta sección enumera los parámetros para los ejemplos que se describen en las secciones anteriores.
PA RÁ M ET RO VA LO R
Prefijos de direcciones de red virtual 10.11.0.0/16

10.12.0.0/16
Dirección IP de la puerta de enlace de VPN de Azure Dirección IP de Azure VPN Gateway
Prefijos de direcciones locales 10.51.0.0/16

10.52.0.0/16
Dirección IP del dispositivo VPN local Dirección IP del dispositivo VPN local
*Red Virtual BGP ASN 65010
*Dirección IP del par BGP de Azure 10.12.255.30
*ASN de BGP local 65050
*Dirección IP del par BGP local 10.52.255.254
* Parámetro opcional solo para BGP.

Script de PowerShell de ejemplo
En esta sección se proporciona un script de ejemplo para ayudarle a comenzar. Para instrucciones detalladas
consulte Creación de una red virtual con una conexión VPN S2S de sitio a sitio mediante PowerShell.
# Declare your variables
$Sub1 = "Replace_With_Your_Subscription_Name"
$RG1 = "TestRG1"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$VNet1ASN = 65010
$DNS1 = "8.8.8.8"
$LNGName5 = "Site5"
$LNGPrefix50 = "10.52.255.254/32"
$LNGPrefix51 = "10.51.0.0/16"
$LNGPrefix52 = "10.52.0.0/16"
$LNGIP5 = "Your_VPN_Device_IP"
$LNGASN5 = 65050
$BGPPeerIP5 = "10.52.255.254"
# Connect to your subscription and create a new resource group
Connect-AzAccount
# Create virtual network
$fesub1 = New-AzVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1 $besub1 = New-

AzVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1

# Create VPN gateway

$gwpip1

# Create local network gateway

$LNGIP5 -AddressPrefix $LNGPrefix51,$LNGPrefix52 -Asn $LNGASN5 -BgpPeeringAddress $BGPPeerIP5
# Create the S2S VPN connection


EnableBGP $False
(Opcional) Usar directivas personalizadas de IPsec/IKE con UsePolicyBasedTrafficSelectors

Si los dispositivos VPN no admiten selectores de tráfico universales, tales como configuraciones basadas en
enrutamiento o en VTI, cree una directiva personalizada de IPsec/IKE con la opción
UsePolicyBasedTrafficSelectors.
IMPORTANT
Tiene que crear una directiva IPsec/IKE para habilitar la opción UsePolicyBasedTrafficSelectors en la conexión.
El script de ejemplo siguiente crea una directiva de IPsec o IKE con los algoritmos y parámetros siguientes:
IPsec: AES256, SHA1, PFS24, vigencia de SA 7,200 segundos y 20.480.000 KB (20 GB)
El script aplica la directiva IPsec/IKE y habilita la opción UsePolicyBasedTrafficSelectors en la conexión.

IpsecEncryption AES256 -IpsecIntegrity SHA1 -PfsGroup PFS24 -SALifeTimeSeconds 7200 -SADataSizeKilobytes
20480000


EnableBGP $False -IpsecPolicies $ipsecpolicy5 -UsePolicyBasedTrafficSelectors $True
(Opcional) Usar BGP en una conexión VPN S2S

Al crear la conexión VPN S2S, también tiene la opción de usar BGP para la puerta de enlace VPN. Este enfoque
tiene dos diferencias:
Los prefijos de dirección local pueden ser una dirección de host único. La dirección IP del par BGP local se
especifica como sigue:
New-AzLocalNetworkGateway -Name $LNGName5 -ResourceGroupName $RG1 -Location $Location1 -

GatewayIpAddress $LNGIP5 -AddressPrefix $LNGPrefix50 -Asn $LNGASN5 -BgpPeeringAddress $BGPPeerIP5
Al crear la conexión, tiene que establecer la opción - EnableBGP en $True:

VirtualNetworkGateway1 $vnet1gw -LocalNetworkGateway2 $lng5gw -Location $Location1 -ConnectionType
IPsec -SharedKey 'AzureA1b2C3' -EnableBGP $True
Pasos siguientes
Consulte Configuración activo-activo de puertas de enlace de VPN para conexiones entre locales y de red virtual
a red virtual para ver las instrucciones paso a paso para configurar puertas de enlace VPN activo-activo.
Descarga de scripts de configuración de dispositivos
VPN para conexiones VPN S2S
Este artículo lo guiará a la hora de descargar scripts de configuración de dispositivos VPN para conexiones VPN
S2S con Azure VPN Gateway usando Azure Resource Manager. En el siguiente diagrama se muestra el proceso
de forma resumida.
Los siguientes dispositivos tienen scripts disponibles:
P RO VEEDO R FA M IL IA DE DISP O SIT IVO S VERSIÓ N DE F IRM WA RE
Cisco ISR IOS 15.1 (versión preliminar)
Cisco ASA ASA (*) RouteBased (IKEv2: sin BGP)

para versión de ASA anterior a 9.8
Cisco ASA ASA RouteBased (IKEv2: sin BGP) para

versión de ASA superior a 9.8
Juniper SRX_GA 12.x
Juniper SSG_GA ScreenOS 6.2.x
Juniper JSeries_GA JunOS 12.x
Juniper SRX JunOS 12.x RouteBased BGP
Ubiquiti EdgeRouter EdgeOS v1.10x RouteBased VTI
Ubiquiti EdgeRouter EdgeOS v1.10x RouteBased BGP

NOTE
(*) Obligatorio: NarrowAzureTrafficSelectors (habilitar la opción UsePolicyBasedTrafficSelectors) y CustomAzurePolicies
(IKE/IPsec)
Acerca de los scripts de configuración de dispositivos VPN

Una conexión VPN entre locales consta de una puerta de enlace de VPN de Azure, un dispositivo VPN local y un
túnel VPN S2S de IPsec que conecta los dos. El flujo de trabajo típico incluye los siguientes pasos:
1. Crear y configurar una puerta de enlace VPN de Azure (puerta de enlace de red virtual)
2. Creación y configuración de una puerta de enlace de red local de Azure que representa la red local y el
dispositivo VPN
3. Crear y configurar una conexión VPN de Azure entre la puerta de enlace de VPN de Azure y la puerta de
enlace de red local
4. Configurar el dispositivo VPN local representado por la puerta de enlace de red local para establecer el túnel
VPN S2S real con la puerta de enlace de VPN de Azure
Puede completar los pasos del 1 al 3 con Azure Portal, PowerShell o la CLI. El último paso implica configurar los
dispositivos VPN locales fuera de Azure. Esta característica permite descargar un script de configuración para el
dispositivo VPN con los valores correspondientes de la puerta de enlace VPN de Azure, la red virtual, los prefijos
de direcciones de red local, ñas propiedades de conexión VPN, etc., ya rellenos. Puede usar el script como punto
de partida, o bien aplicar el script directamente en los dispositivos VPN local a través de la consola de
configuración.
IMPORTANT
La sintaxis de cada script de configuración de dispositivos VPN es diferente y depende en gran medida de los modelos
y las versiones de firmware. Preste especial atención a la información de la versión y el modelo del dispositivo con las
plantillas disponibles.
Algunos valores de parámetro deben ser únicos en el dispositivo y no se pueden determinar sin tener acceso al
dispositivo. Los scripts de configuración generados por Azure rellenan previamente estos valores, pero debe
asegurarse de que los valores proporcionados sean válidos en el dispositivo. Por ejemplo:
Números de interfaces
Números de listas de control de acceso
Números o nombres de directivas, etc.
Busque la palabra clave "REPL ACE " incrustada en el script para buscar los parámetros que debe comprobar antes de
aplicar el script.
Algunas plantillas incluyen una sección "CLEANUP " que puede aplicar para eliminar las configuraciones. Las secciones
de limpieza están comentadas de forma predeterminada.
Descarga del script de configuración de Azure Portal

Cree una puerta de enlace de VPN de Azure, una puerta de enlace de red local y un recurso de conexión que
conecte los dos. Este asistente lo guiará a través de los pasos siguientes:
Creación de una conexión de sitio a sitio mediante Azure Portal
Una vez creado el recurso de conexión, siga estas instrucciones para descargar los scripts de configuración de
dispositivos VPN:
1. Desde un explorador, vaya a Azure Portal y, si fuera necesario, inicie sesión con su cuenta de Azure.
2. Vaya al recurso de conexión que creó. Puede ver la lista de todos los recursos de conexión haciendo clic
en "Todos los servicios" y, luego en "REDES" y "Conexiones".
3. Haga clic en la conexión que quiere configurar.
4. Haga clic en el vínculo "Descargar configuración" resaltado en rojo en la página Información general
sobre la conexión; se abrirá la página "Descargar configuración".
5. Seleccione la versión del firmware y la familia de modelos del dispositivo VPN; luego, haga clic en el
botón "Descargar configuración".
6. Se le pedirá que guarde el script descargado (un archivo de texto) desde el explorador.
7. Una vez descargado el script de configuración, ábralo con un editor de texto y busque la palabra clave
"REPLACE" para identificar y examinar los parámetros que puede que necesiten reemplazarse.
Descarga del script de configuración con Azure PowerShell

También puede descargar el script de configuración con Azure PowerShell, tal como se muestra en el ejemplo
siguiente:
$RG = "TestRG1"
$GWName = "VNet1GW"
$Connection = "VNet1toSite1"
# List the available VPN device models and versions

Get-AzVirtualNetworkGatewaySupportedVpnDevice -Name $GWName -ResourceGroupName $RG
# Download the configuration script for the connection

Get-AzVirtualNetworkGatewayConnectionVpnDeviceConfigScript -Name $Connection -ResourceGroupName $RG -
DeviceVendor Juniper -DeviceFamily Juniper_SRX_GA -FirmwareVersion Juniper_SRX_12.x_GA
Aplicación del script de configuración al dispositivo VPN

Después de haber descargado y validado el script de configuración, el siguiente paso es aplicar el script en el
dispositivo VPN. El procedimiento real varía en función de las marcas y los modelos de dispositivos VPN.
Consulte los manuales de uso o las páginas de instrucciones de sus dispositivos VPN.
Pasos siguientes
Continúe configurado la conexión de sitio a sitio.
Ejemplo de configuración: dispositivo Cisco ASA
(IKEv2/no BGP)
En este artículo se proporciona un ejemplo de configuración para conectar dispositivos Cisco Adaptive Security
Appliance (ASA) a puertas de enlace de VPN de Azure. El ejemplo se aplica a dispositivos Cisco ASA que
ejecutan IKEv2 sin Border Gateway Protocol (BGP).
Detalles del dispositivo

Proveedor del dispositivo: Cisco
Modelo del dispositivo: ASA
Versión de destino: 8.4 y posteriores
Modelo probado: ASA 5505
Versión probada: 9.2
Versión de IKE: IKEv2
BGP: No
Tipo de Azure VPN Gateway VPN Gateway basada en rutas
NOTE
La configuración de ejemplo conecta un dispositivo Cisco ASA a una puerta de enlace de VPN basada en rutas de
Azure. La conexión usa una directiva de IPsec/IKE personalizada con la opción UsePolicyBasedTrafficSelectors , como se
describe en este artículo.
El ejemplo requiere que los dispositivos ASA usen la directiva IKEv2 con configuraciones basadas en listas de acceso, no
basadas en VTI. Consulte las especificaciones del proveedor de dispositivos VPN para comprobar que los dispositivos VPN
locales admiten la directiva IKEv2.
Requisitos del dispositivo VPN

Las puertas de enlace de VPN de Azure usan los conjuntos de protocolos IPsec o IKE estándar para establecer
túneles VPN de sitio a sitio (S2S). Consulte Acerca de los dispositivos VPN para obtener los parámetros
detallados del protocolo IPsec o IKE y los algoritmos criptográficos predeterminados para las puertas de enlace
de VPN de Azure.
NOTE
También puede especificar una combinación exacta de algoritmos criptográficos y niveles de clave para una conexión
específica, como se describe en Acerca de los requisitos criptográficos. Si especifica una combinación específica de
algoritmos y niveles de clave, asegúrese de que usa las especificaciones correspondientes en los dispositivos VPN.
Un solo túnel VPN

Esta configuración consta de un solo túnel VPN S2S entre una puerta de enlace de VPN de Azure y el dispositivo
VPN local. Opcionalmente puede configurar BGP a través del túnel VPN.
Para obtener instrucciones paso a paso sobre cómo crear las configuraciones de Azure consulte la configuración
de túnel VPN único.
Información de puerta de enlace de VPN y de red virtual
En esta sección se muestran los parámetros de este ejemplo.
Prefijos de direcciones de red virtual 10.11.0.0/16

10.12.0.0/16
Dirección IP de la puerta de enlace de VPN de Azure Azure_Gateway_Public_IP
Prefijos de direcciones locales 10.51.0.0/16

10.52.0.0/16
Dirección IP del dispositivo VPN local OnPrem_Device_Public_IP
*Red Virtual BGP ASN 65010
*Dirección IP del par BGP de Azure 10.12.255.30
*ASN de BGP local 65050
*Dirección IP del par BGP local 10.52.255.254
* Parámetro opcional solo para BGP.

Parámetros y directivas de IPsec o IKE
En la tabla siguiente se enumeran los algoritmos y parámetros de IPsec o IKE que se usan en el ejemplo.
Consulte las especificaciones del dispositivo VPN para asegurarse de que todos los algoritmos enumerados
anteriormente son compatibles con los modelos de dispositivo VPN y las versiones de firmware.
IP SEC O IK EV2 VA LO R
Cifrado IKEv2 AES256
Integridad de IKEv2 SHA384
Grupo DH DHGroup24
*Cifrado IPsec AES256
*Integridad de IPsec SHA1

IP SEC O IK EV2 VA LO R
Grupo PFS PFS24
Vigencia de SA QM 7.200 segundos
Selector de tráfico UsePolicyBasedTrafficSelectors $True
Clave previamente compartida PreSharedKey
*En algunos dispositivos, la integridad de IPsec tiene que ser un valor null cuando el algoritmo de cifrado de
IPsec es AES-GCM.
Compatibilidad con dispositivos ASA
La compatibilidad con IKEv2 requiere la versión 8.4 y versiones posteriores de ASA.
La compatibilidad con grupos DH y PFS por encima del Grupo 5, requiere la versión ASA 9.x.
La compatibilidad para cifrado IPsec con AES-GCM e integridad de IPsec con SHA-256, SHA-384 y SHA-
512, requiere la versión ASA 9.x. Este requisito de compatibilidad se aplica a los dispositivos ASA más
nuevos. En el modelo de la publicación, los modelos 5505, 5510, 5520, 5540, 5550 y 5580 de ASA no
admiten estos algoritmos. Consulte las especificaciones del dispositivo VPN para asegurarse de que
todos los algoritmos enumerados anteriormente son compatibles con los modelos de dispositivo VPN y
las versiones de firmware.
Ejemplo de configuración de dispositivo
El script proporciona un ejemplo que se basa en la configuración y los parámetros que se describen en las
secciones anteriores. La configuración del túnel VPN de S2S consta de las siguientes partes:
1. Interfaces y rutas
2. Listas de acceso
3. Directiva y parámetros de IKE (fase 1 o modo principal)
4. Directiva y parámetros de IPsec (fase 2 o modo rápido)
5. Otros parámetros, tales como bloqueo MSS de TCP
IMPORTANT
Realice los pasos siguientes antes de usar el script de ejemplo. Reemplace los valores de marcador de posición en el script
con los ajustes de dispositivo para la configuración.
Especifique la configuración de interfaz para interfaces internas y externas.

Identifique las rutas para las redes internas o privadas, y públicas o externas.
Asegúrese de que todos los nombres y números de directiva son únicos en el dispositivo.
Asegúrese de que el dispositivo admite algoritmos criptográficos.
Reemplace los siguiente valores de marcador de posición con valores reales para la configuración:
Nombre de la interfaz externa: outside
Azure_Gateway_Public_IP
OnPrem_Device_Public_IP
IKE: Pre_Shared_Key
Nombres de la red virtual y la puerta de enlace de red local: VNetName y LNGName
Prefijos de direcciones de red de la red virtual y local
Máscaras de red correctas
Script de ejemplo
! Sample ASA configuration for connecting to Azure VPN gateway

!
! Tested hardware: ASA 5505
! Tested version: ASA version 9.2(4)
!
! Replace the following place holders with your actual values:
! - Interface names - default are "outside" and "inside"
! - <Azure_Gateway_Public_IP>
! - <OnPrem_Device_Public_IP>
! - <Pre_Shared_Key>
! - <VNetName>*
! - <LNGName>* ==> LocalNetworkGateway - the Azure resource that represents the
! on-premises network, specifies network prefixes, device public IP, BGP info, etc.
! - <PrivateIPAddress> ==> Replace it with a private IP address if applicable
! - <Netmask> ==> Replace it with appropriate netmasks
! - <Nexthop> ==> Replace it with the actual nexthop IP address
!
! (*) Must be unique names in the device configuration
!
! ==> Interface & route configurations
!
! > <OnPrem_Device_Public_IP> address on the outside interface or vlan
! > <PrivateIPAddress> on the inside interface or vlan; e.g., 10.51.0.1/24
! > Route to connect to <Azure_Gateway_Public_IP> address
!
! > Example:
!
! interface Ethernet0/0
! switchport access vlan 2
! exit
!
! interface vlan 1
! nameif inside
! security-level 100
! ip address <PrivateIPAddress> <Netmask>
! exit
!
! interface vlan 2
! nameif outside
! security-level 0
! ip address <OnPrem_Device_Public_IP> <Netmask>
! exit
!
! route outside 0.0.0.0 0.0.0.0 <NextHop IP> 1
!
! ==> Access lists
!
! > Most firewall devices deny all traffic by default. Create access lists to
! (1) Allow S2S VPN tunnels between the ASA and the Azure gateway public IP address
! (2) Construct traffic selectors as part of IPsec policy or proposal
!
access-list outside_access_in extended permit ip host <Azure_Gateway_Public_IP> host
<OnPrem_Device_Public_IP>
!
! > Object group that consists of all VNet prefixes (e.g., 10.11.0.0/16 &
! 10.12.0.0/16)
!
object-group network Azure-<VNetName>
description Azure virtual network <VNetName> prefixes
network-object 10.11.0.0 255.255.0.0
network-object 10.12.0.0 255.255.0.0
exit
!
! > Object group that corresponding to the <LNGName> prefixes.
! E.g., 10.51.0.0/16 and 10.52.0.0/16. Note that LNG = "local network gateway".
! E.g., 10.51.0.0/16 and 10.52.0.0/16. Note that LNG = "local network gateway".
! In Azure network resource, a local network gateway defines the on-premises
! network properties (address prefixes, VPN device IP, BGP ASN, etc.)
!
object-group network <LNGName>
description On-Premises network <LNGName> prefixes
network-object 10.51.0.0 255.255.0.0
network-object 10.52.0.0 255.255.0.0
exit
!
! > Specify the access-list between the Azure VNet and your on-premises network.
! This access list defines the IPsec SA traffic selectors.
!
access-list Azure-<VNetName>-acl extended permit ip object-group <LNGName> object-group Azure-<VNetName>
!
! > No NAT required between the on-premises network and Azure VNet
!
nat (inside,outside) source static <LNGName> <LNGName> destination static Azure-<VNetName> Azure-<VNetName>
!
! ==> IKEv2 configuration
!
! > General IKEv2 configuration - enable IKEv2 for VPN
!
group-policy DfltGrpPolicy attributes
vpn-tunnel-protocol ikev1 ikev2
exit
!
crypto isakmp identity address
crypto ikev2 enable outside
!
! > Define IKEv2 Phase 1/Main Mode policy
! - Make sure the policy number is not used
! - integrity and prf must be the same
! - DH group 14 and above require ASA version 9.x.
!
crypto ikev2 policy 1
encryption aes-256
integrity sha384
prf sha384
group 24
lifetime seconds 86400
exit
!
! > Set connection type and pre-shared key
!
tunnel-group <Azure_Gateway_Public_IP> type ipsec-l2l
tunnel-group <Azure_Gateway_Public_IP> ipsec-attributes
ikev2 remote-authentication pre-shared-key <Pre_Shared_Key>
ikev2 local-authentication pre-shared-key <Pre_Shared_Key>
exit
!
! ==> IPsec configuration
!
! > IKEv2 Phase 2/Quick Mode proposal
! - AES-GCM and SHA-2 requires ASA version 9.x on newer ASA models. ASA
! 5505, 5510, 5520, 5540, 5550, 5580 are not supported.
! - ESP integrity must be null if AES-GCM is configured as ESP encryption
!
crypto ipsec ikev2 ipsec-proposal AES-256
protocol esp encryption aes-256
protocol esp integrity sha-1
exit
!
! > Set access list & traffic selectors, PFS, IPsec proposal, SA lifetime
! - This sample uses "Azure-<VNetName>-map" as the crypto map name
! - ASA supports only one crypto map per interface, if you already have
! an existing crypto map assigned to your outside interface, you must use
! the same crypto map name, but with a different sequence number for
! this policy
! - "match address" policy uses the access-list "Azure-<VNetName>-acl" defined
! previously
! - "ipsec-proposal" uses the proposal "AES-256" defined previously
! - PFS groups 14 and beyond requires ASA version 9.x.
!
crypto map Azure-<VNetName>-map 1 match address Azure-<VNetName>-acl
crypto map Azure-<VNetName>-map 1 set pfs group24
crypto map Azure-<VNetName>-map 1 set peer <Azure_Gateway_Public_IP>
crypto map Azure-<VNetName>-map 1 set ikev2 ipsec-proposal AES-256
crypto map Azure-<VNetName>-map 1 set security-association lifetime seconds 7200
crypto map Azure-<VNetName>-map interface outside
!
! ==> Set TCP MSS to 1350
!
sysopt connection tcpmss 1350
!
Comandos de depuración simples

Use los siguientes comandos de ASA para fines de depuración:
Mostrar la asociación de seguridad (SA) de IPsec o IKE:
show crypto ipsec sa

show crypto ikev2 sa
Entrar en modo de depuración:
debug crypto ikev2 platform <level>

debug crypto ikev2 protocol <level>
Los comandos debug pueden generar resultados significativos en la consola.

Mostrar las configuraciones actuales en el dispositivo:
show run
Usar subcomandos show para enumerar partes de la configuración del dispositivo, por ejemplo:
show run crypto

show run access-list
show run tunnel-group
Pasos siguientes
Para configurar activo-activo entre entornos y las conexiones de red virtual a red virtual, consulte Configuración
de conexiones VPN activo-activo con puertas de enlace VPN.
Visualización de métricas de VPN Gateway
Puede supervisar puertas de enlace de VPN de Azure mediante Azure Monitor. En este artículo se describen las
métricas que están disponibles en el portal. Las métricas son ligeras y pueden admitir escenarios casi en tiempo
real, lo que las hace útiles para alertas y detección rápida de problemas.
M ÉT RIC A UN IDA D GRA N UL A RIDA D DESC RIP C IÓ N
AverageBandwidth Bytes por segundo 5 minutos Promedio de uso de ancho

de banda combinado de
todas las conexiones de
sitio a sitio en la puerta de
enlace.
P2SBandwidth Bytes por segundo 1 minuto. Promedio de uso de ancho

punto a sitio en la puerta
de enlace.
P2SConnectionCount Count 1 minuto. Recuento de las conexiones

de punto a sitio en la
puerta de enlace.
TunnelAverageBandwidt Bytes por segundo 5 minutos Promedio de utilización del

h ancho de banda de los
túneles creados en la
puerta de enlace.
TunnelEgressBytes Bytes 5 minutos Tráfico saliente en los

puerta de enlace.
TunnelEgressPackets Count 5 minutos Recuento de los paquetes

salientes en los túneles
creados en la puerta de
enlace.
TunnelEgressPacketDrop Count 5 minutos Recuento de los paquetes

TSMismatch salientes eliminados de los
túneles por un error de
coincidencia del selector de
tráfico.
TunnelIngressBytes Bytes 5 minutos Tráfico entrante en los

puerta de enlace.
TunnelIngressPackets Count 5 minutos Recuento de los paquetes

entrantes en los túneles
enlace.
TunnelIngressPacketDro Count 5 minutos Recuento de los paquetes

pTSMismatch entrantes eliminados de los
tráfico.
Los siguientes pasos le ayudarán a ubicar y ver las métricas:

1. En el portal, vaya al recurso de puerta de enlace de red virtual.
2. Seleccione Información general para ver las métricas de total de entrada y salida del túnel.
3. Para ver cualquiera de las otras métricas indicadas anteriormente: Haga clic en la sección Métricas en el
recurso de puerta de enlace de red virtual y seleccione la métrica en la lista desplegable.
Pasos siguientes
Para configurar alertas en las métricas de túnel, vea Configuración de alertas en métricas de VPN Gateway.
Para configurar alertas en los registros de recursos de túnel, consulte Configuración de alertas en los registros
de diagnóstico de VPN Gateway.
Configuración de alertas en métricas de VPN
Gateway
Este artículo le ayuda a configurar alertas en métricas de Azure VPN Gateway. Azure Monitor proporciona la
capacidad de configurar alertas para los recursos de Azure. Puede configurar alertas para las puertas de enlace
de red virtual del tipo "VPN".
AverageBandwidth Bytes por segundo 5 minutos Promedio de uso de ancho

sitio a sitio en la puerta de
enlace.
P2SBandwidth Bytes por segundo 1 minuto. Promedio de uso de ancho

punto a sitio en la puerta
de enlace.
P2SConnectionCount Count 1 minuto. Recuento de las conexiones

de punto a sitio en la
puerta de enlace.
TunnelAverageBandwidt Bytes por segundo 5 minutos Promedio de utilización del

h ancho de banda de los
puerta de enlace.
TunnelEgressBytes Bytes 5 minutos Tráfico saliente en los

puerta de enlace.
TunnelEgressPackets Count 5 minutos Recuento de los paquetes

salientes en los túneles
enlace.
TunnelEgressPacketDrop Count 5 minutos Recuento de los paquetes

TSMismatch salientes eliminados de los
tráfico.
TunnelIngressBytes Bytes 5 minutos Tráfico entrante en los

puerta de enlace.
TunnelIngressPackets Count 5 minutos Recuento de los paquetes

entrantes en los túneles
enlace.
TunnelIngressPacketDro Count 5 minutos Recuento de los paquetes

pTSMismatch entrantes eliminados de los
tráfico.
Configuración de alertas de Azure Monitor basadas en métricas

En los pasos del ejemplo siguiente se creará una alerta en una puerta de enlace para:
Métrica: TunnelAverageBandwidth
Condición: Ancho de banda > 10 bytes por segundo
Ventana: 5 minutos
Acción de aler ta: Email
1. Vaya al recurso de puerta de enlace de red virtual y seleccione Aler tas en la pestaña Super visión .
Después, cree una regla de alertas o modifique una existente.
2. Seleccione la instancia de VPN Gateway como el recurso.

3. Seleccione una métrica para configurar la alerta.
4. Configure la lógica de señal. Hay tres componentes:

a. Dimensiones Si la métrica tiene dimensiones, puede seleccionar valores de dimensión específicos
para que la alerta solo evalúe los datos de esa dimensión. Estos son opcionales.
b. Condición : Es la operación para evaluar el valor de métrica.
c. Time : Especifique la granularidad de los datos de la métrica y el período de tiempo para evaluar la
alerta.
5. Para ver las reglas configuradas, seleccione Administrar reglas de aler tas .
Pasos siguientes
Para configurar alertas en los registros de recursos de túnel, consulte Configuración de alertas en los registros
de diagnóstico de VPN Gateway.
Configuración de alertas de eventos de registro de
recursos de VPN Gateway
En este artículo se le ayuda a configurar alertas basadas en eventos de registro de recursos de Azure VPN
Gateway con Azure Monitor Log Analytics.
Los siguientes registros de recursos están disponibles en Azure:
* N O M B RE _ DESC RIP C IÓ N
GatewayDiagnosticLog Contiene los registros de recursos para los eventos de

configuración de puerta de enlace, los cambios principales y
los eventos de mantenimiento
TunnelDiagnosticLog Contiene los eventos de cambio del estado del túnel. Los
eventos de conexión/desconexión del túnel tienen un motivo
resumido para el cambio de estado si es aplicable
RouteDiagnosticLog Registra los cambios en rutas estáticas y eventos BGP que se

producen en la puerta de enlace
IKEDiagnosticLog Registra mensajes de control de IKE y eventos en la puerta

de enlace
P2SDiagnosticLog Registra mensajes de control de punto a sitio y eventos en la

puerta de enlace. La información del origen de conexión se
proporciona solo para conexiones IKEv2 y OpenVPN
Configuración de alertas en Azure Portal

Los pasos del ejemplo siguiente crean una alerta para un evento de desconexión que implica un túnel VPN de
sitio a sitio:
1. En Azure Portal, busque _ Log Analytics* en Todos los ser vicios y seleccione Áreas de trabajo de
Log Analytics .
2. Seleccione Crear en la página Log Analytics .
3. Seleccione Crear nuevo y rellene los detalles.

4. Busque la instancia de VPN Gateway en la hoja Monitor > Configuración de diagnóstico .
5. Para activar los diagnósticos, haga doble clic en la puerta de enlace y, después, seleccione Activar
diagnósticos .
6. Rellene los detalles y asegúrese de que Enviar a Log Analytics y TunnelDiagnosticLog están
seleccionados. Elija el área de trabajo de Log Analytics que creó en el paso 3.
NOTE
Inicialmente, los datos pueden tardar unas horas en mostrarse.
7. Vaya a la introducción del recurso de la puerta de enlace de red virtual y seleccione Aler tas en la pestaña
Super visión . Después, cree una regla de alertas o modifique una existente.
8. Seleccione el área de trabajo de Log Analytics y el recurso.
9. Seleccione Búsqueda de registros personalizada como la lógica de la señal en Agregar condición .

10. Escriba la consulta siguiente en el cuadro de texto Consulta de búsqueda . Reemplace los valores de <>
y TimeGenerated según corresponda.
AzureDiagnostics
| where Category == "TunnelDiagnosticLog"
| where _ResourceId == tolower("<RESOURCEID OF GATEWAY>")
| where TimeGenerated > ago(5m)
| where remoteIP_s == "<REMOTE IP OF TUNNEL>"
| where status_s == "Disconnected"
| project TimeGenerated, OperationName, instance_s, Resource, ResourceGroup, _ResourceId
| sort by TimeGenerated asc
Establezca el valor del umbral en 0 y seleccione Listo .
11. En la página Crear regla , seleccione Crear nueva en la sección GRUPOS DE ACCIONES . Rellene los
detalles y seleccione Aceptar .
12. En la página Crear regla , rellene los detalles de Personalizar acciones y asegúrese de que aparece el
nombre correcto en la sección NOMBRE DEL GRUPO DE ACCIONES . Seleccione Crear regla de
aler ta para crear la regla.
Configuración de alertas mediante PowerShell
Los pasos del ejemplo siguiente crearán una alerta para un evento de desconexión que implica un túnel VPN de
sitio a sitio.
1. Cree de un área de trabajo de Log Analytics:
$Location = 'westus2'
$ResourceGroupName = 'TestRG1'
$Sku = 'pergb2018'
$WorkspaceName = 'LogAnalyticsWS123'
New-AzOperationalInsightsWorkspace -Location $Location -Name $WorkspaceName -Sku $Sku -

ResourceGroupName $ResourceGroupName
2. Active el diagnóstico para la puerta de enlace de VPN:
$VpnGatewayName = 'VNet1GW'
$VpnGateway = Get-AzVirtualNetworkGateway -Name $VpnGatewayName -ResourceGroupName

$ResourceGroupName
$Workspace = Get-AzOperationalInsightsWorkspace -Name $WorkspaceName -ResourceGroupName
$ResourceGroupName
Set-AzDiagnosticSetting `
-Name 'VPN tunnel' `
-ResourceId $VpnGateway.Id `
-WorkspaceId $Workspace.ResourceId `
-Enabled $true `
-Category 'TunnelDiagnosticLog'
3. Cree un grupo de acciones.

Este código crea un grupo de acciones que envía una notificación por correo electrónico cuando se
desencadena una alerta:
$ActionGroupName = 'EmailAdmins' # Max. 60 characters long

$ActionGroupShortName = 'EmailAdmins' # Max. 12 characters long
$ActionGroupReceiverName = 'My receiver Name'
$EmailAddress = '[email protected]'
$ActionGroupReceiver = New-AzActionGroupReceiver -Name $ActionGroupReceiverName -UseCommonAlertSchema

-EmailReceiver -EmailAddress $EmailAddress
Set-AzActionGroup `
-ResourceGroupName $ResourceGroupName `
-Name $ActionGroupName `
-ShortName $ActionGroupShortName `
-Receiver @($ActionGroupReceiver)
4. Cree una regla de alerta basada en una búsqueda de registros personalizada:

$ActionGroupName = 'EmailAdmins'
$EmailSubject = 'Redmond VPN tunnel is disconnected'
$Location = 'westus2'
$RemoteIp = '104.42.209.46'
$VpnGatewayName = 'VNet1GW'
$VpnGateway = Get-AzVirtualNetworkGateway -Name $VpnGatewayName -ResourceGroupName

$ResourceGroupName
$Workspace = Get-AzOperationalInsightsWorkspace -Name $WorkspaceName -ResourceGroupName
$ResourceGroupName
$Query = @"
AzureDiagnostics |
where Category == "TunnelDiagnosticLog" |
where TimeGenerated > ago(5m) |
where _ResourceId == tolower("$($VpnGateway.id)") |
where remoteIP_s == "$($RemoteIp)" |
where status_s == "Disconnected" |
project TimeGenerated, OperationName, instance_s, Resource, ResourceGroup, _ResourceId |
sort by TimeGenerated asc
"@
$Source = New-AzScheduledQueryRuleSource -Query $Query -DataSourceId

$Workspace.ResourceId
$Schedule = New-AzScheduledQueryRuleSchedule -FrequencyInMinutes 5 -TimeWindowInMinutes 5
$TriggerCondition = New-AzScheduledQueryRuleTriggerCondition -ThresholdOperator 'GreaterThan' -
Threshold 0
$ActionGroup = Get-AzActionGroup -ResourceGroupName $ResourceGroupName -Name $ActionGroupName

$AznsActionGroup = New-AzScheduledQueryRuleAznsActionGroup -ActionGroup $ActionGroup.Id -
EmailSubject $EmailSubject
$AlertingAction = New-AzScheduledQueryRuleAlertingAction -AznsAction $AznsActionGroup -Severity
'1' -Trigger $TriggerCondition
New-AzScheduledQueryRule `
-ResourceGroupName $ResourceGroupName `
-Action $AlertingAction `
-Enabled $true `
-Description 'The tunnel between Azure and Redmond with IP address 104.42.209.46 is disconnected'
`
-Schedule $Schedule `
-Source $Source `
-Name 'The Azure to Redmond tunnel is disconnected'
Pasos siguientes
Para configurar alertas en las métricas de túnel, vea Configuración de alertas en métricas de VPN Gateway.
Configuración de captura de paquetes para
instancias de VPN Gateway
Los problemas relacionados con la conectividad y el rendimiento suelen ser complejos. Puede tardar mucho
tiempo y esfuerzo en suavizar la causa del problema. La captura de paquetes puede ayudarle a limitar el ámbito
de un problema a algunas partes de la red. Puede ayudarle a determinar si el problema está en el lado del
cliente de la red, en el lado de Azure de la red o en algún punto entre ambos. Después de limitar el problema, la
depuración y las medidas correctivas son más eficaces.
Existen algunas herramientas de capturas de paquetes disponibles comúnmente. La obtención de capturas de
paquetes apropiadas con estas herramientas puede resultar complicada, especialmente cuando se trabaja en
escenarios con un gran volumen de tráfico. Las capacidades de filtrado que proporciona una captura de
paquetes de Azure VPN Gateway son diferenciador importante. Puede usar una captura de paquetes de VPN
Gateway junto con las herramientas de captura de paquetes disponibles habitualmente.
Capacidades de filtrado de captura de paquetes de VPN Gateway

Según sus necesidades, la captura de paquetes de VPN Gateway se puede ejecutar en la puerta de enlace o en
una conexión específica. También puede ejecutar la captura de paquetes en varios túneles al mismo tiempo.
Puede capturar el tráfico unidireccional o bidireccional, el tráfico de IKE y ESP, y los paquetes internos junto con
el filtrado en una instancia de VPN Gateway.
El uso de un filtro de tupla de cinco elementos (subred de origen, subred de destino, puerto de origen, puerto de
destino y protocolo) y de marcas TCP (SYN, ACK, FIN, URG, PSH y RST) resulta útil al aislar problemas cuando
hay mucho volumen de tráfico.
Los ejemplos siguientes de JSON y un esquema JSON proporcionan explicaciones de cada propiedad. Estas son
algunas limitaciones a tener en cuenta al ejecutar capturas de paquetes:
En el esquema que se muestra aquí, el filtro es una matriz, pero en la actualidad no se pueden usar varios
filtros simultáneamente.
No se permiten varias capturas de paquetes en toda la puerta de enlace al mismo tiempo.
No se permiten varias capturas de paquetes en la misma conexión al mismo tiempo. Puede ejecutar varias
capturas de paquetes en diferentes conexiones a la vez.
Se puede ejecutar un máximo de cinco capturas de paquetes en paralelo por puerta de enlace. Estas capturas
de paquetes pueden ser una combinación de capturas de paquetes en toda la puerta de enlace y capturas de
paquetes por conexión.
La unidad de MaxPacketBufferSize es bytes, mientras que la de MaxFileSize es megabytes
Ejemplo de JSON
{
"TracingFlags": 11,
"MaxPacketBufferSize": 120,
"MaxFileSize": 200,
"Filters": [
{
"SourceSubnets": [
"20.1.1.0/24"
],
"DestinationSubnets": [
"10.1.1.0/24"
],
"SourcePort": [
500
],
"DestinationPort": [
4500
],
"Protocol": [
6
],
"TcpFlags": 16,
"CaptureSingleDirectionTrafficOnly": true
}
]
}
Esquema JSON
{
"type": "object",
"title": "The Root Schema",
"description": "The root schema input JSON filter for packet capture",
"default": {},
"additionalProperties": true,
"required": [
"TracingFlags",
"MaxPacketBufferSize",
"MaxFileSize",
"Filters"
],
"properties": {
"TracingFlags": {
"$id": "#/properties/TracingFlags",
"type": "integer",
"title": "The Tracingflags Schema",
"description": "Tracing flags that customer can pass to define which packets are to be captured.
Supported values are CaptureESP = 1, CaptureIKE = 2, CaptureOVPN = 8. The final value is OR of the bits.",
"default": 11,
"examples": [
11
]
},
"MaxPacketBufferSize": {
"$id": "#/properties/MaxPacketBufferSize",
"type": "integer",
"title": "The Maxpacketbuffersize Schema",
"description": "Maximum buffer size of each packet. The capture will only contain contents of
each packet truncated to this size.",
"default": 120,
"examples": [
120
]
},
"MaxFileSize": {
"$id": "#/properties/MaxFileSize",
"type": "integer",
"type": "integer",
"title": "The Maxfilesize Schema",
"description": "Maximum file size of the packet capture file. It is a circular buffer.",
"default": 100,
"examples": [
100
]
},
"Filters": {
"$id": "#/properties/Filters",
"type": "array",
"title": "The Filters Schema",
"description": "An array of filters that can be passed to filter inner ESP traffic.",
"default": [],
"examples": [
[
{
"Protocol": [
6
],
"CaptureSingleDirectionTrafficOnly": true,
"SourcePort": [
500
],
4500
],
"TcpFlags": 16,
"SourceSubnets": [
"20.1.1.0/24"
],
"10.1.1.0/24"
]
}
]
],
"additionalItems": true,
"items": {
"$id": "#/properties/Filters/items",
"type": "object",
"title": "The Items Schema",
"description": "An explanation about the purpose of this instance.",
"default": {},
"examples": [
{
"SourcePort": [
500
],
4500
],
"TcpFlags": 16,
"SourceSubnets": [
"20.1.1.0/24"
],
"10.1.1.0/24"
],
"Protocol": [
6
],
"CaptureSingleDirectionTrafficOnly": true
}
],
"additionalProperties": true,
"required": [
"SourceSubnets",
"DestinationSubnets",
"SourcePort",
"DestinationPort",
"Protocol",
"TcpFlags",
"CaptureSingleDirectionTrafficOnly"
],
"properties": {
"SourceSubnets": {
"$id": "#/properties/Filters/items/properties/SourceSubnets",
"type": "array",
"title": "The Sourcesubnets Schema",
"description": "An array of source subnets that need to match the Source IP address
of a packet. Packet can match any one value in the array of inputs.",
"default": [],
"examples": [
[
"20.1.1.0/24"
]
],
"items": {
"$id": "#/properties/Filters/items/properties/SourceSubnets/items",
"type": "string",
"default": "",
"examples": [
"20.1.1.0/24"
]
}
},
"DestinationSubnets": {
"$id": "#/properties/Filters/items/properties/DestinationSubnets",
"type": "array",
"title": "The Destinationsubnets Schema",
"description": "An array of destination subnets that need to match the Destination
IP address of a packet. Packet can match any one value in the array of inputs.",
"default": [],
"examples": [
[
"10.1.1.0/24"
]
],
"items": {
"$id": "#/properties/Filters/items/properties/DestinationSubnets/items",
"type": "string",
"default": "",
"examples": [
"10.1.1.0/24"
]
}
},
"SourcePort": {
"$id": "#/properties/Filters/items/properties/SourcePort",
"type": "array",
"title": "The Sourceport Schema",
"description": "An array of source ports that need to match the Source port of a
packet. Packet can match any one value in the array of inputs.",
"default": [],
"examples": [
[
500
]
],
"items": {
"items": {
"$id": "#/properties/Filters/items/properties/SourcePort/items",
"type": "integer",
"default": 0,
"examples": [
500
]
}
},
"DestinationPort": {
"$id": "#/properties/Filters/items/properties/DestinationPort",
"type": "array",
"title": "The Destinationport Schema",
"description": "An array of destination ports that need to match the Destination
port of a packet. Packet can match any one value in the array of inputs.",
"default": [],
"examples": [
[
4500
]
],
"items": {
"$id": "#/properties/Filters/items/properties/DestinationPort/items",
"type": "integer",
"default": 0,
"examples": [
4500
]
}
},
"Protocol": {
"$id": "#/properties/Filters/items/properties/Protocol",
"type": "array",
"title": "The Protocol Schema",
"description": "An array of protocols that need to match the Protocol of a packet.
Packet can match any one value in the array of inputs.",
"default": [],
"examples": [
[
6
]
],
"items": {
"$id": "#/properties/Filters/items/properties/Protocol/items",
"type": "integer",
"default": 0,
"examples": [
6
]
}
},
"TcpFlags": {
"$id": "#/properties/Filters/items/properties/TcpFlags",
"type": "integer",
"title": "The Tcpflags Schema",
"description": "A list of TCP flags. The TCP flags set on the packet must match any
flag in the list of flags provided. FIN = 0x01,SYN = 0x02,RST = 0x04,PSH = 0x08,ACK = 0x10,URG = 0x20,ECE =
0x40,CWR = 0x80. An OR of flags can be provided.",
"default": 0,
"examples": [
16
]
]
},
"CaptureSingleDirectionTrafficOnly": {
"$id": "#/properties/Filters/items/properties/CaptureSingleDirectionTrafficOnly",
"type": "boolean",
"title": "The Capturesingledirectiontrafficonly Schema",
"description": "A flags which when set captures reverse traffic also.",
"default": false,
"examples": [
true
]
}
}
}
}
}
}
Captura de paquetes: portal

Puede configurar la captura de paquetes en Azure Portal.
Captura de paquetes: PowerShell

En los siguientes ejemplos se muestran comandos de PowerShell que inician y detienen capturas de paquetes.
Para obtener más información sobre las opciones de parámetros, consulte Start-
AzVirtualnetworkGatewayPacketCapture.
Iniciar la captura de paquetes para una VPN Gateway
Start-AzVirtualnetworkGatewayPacketCapture -ResourceGroupName "YourResourceGroupName" -Name

"YourVPNGatewayName"
Puede usar el parámetro opcional -FilterData para aplicar un filtro.

Detener la captura de paquetes para una VPN Gateway
Stop-AzVirtualNetworkGatewayPacketCapture -ResourceGroupName "YourResourceGroupName" -Name

"YourVPNGatewayName" -SasUrl "YourSASURL"
Iniciar la captura de paquetes para una conexión de VPN Gateway
Start-AzVirtualNetworkGatewayConnectionPacketCapture -ResourceGroupName "YourResourceGroupName" -Name

"YourVPNGatewayConnectionName"
Puede usar el parámetro opcional -FilterData para aplicar un filtro.

Detener la captura de paquetes en una conexión de VPN Gateway
Stop-AzVirtualNetworkGatewayConnectionPacketCapture -ResourceGroupName "YourResourceGroupName" -Name

"YourVPNGatewayConnectionName" -SasUrl "YourSASURL"
Consideraciones clave
La ejecución de capturas de paquetes puede afectar al rendimiento. Recuerde detener la captura de paquetes
cuando no sea necesaria.
La duración de la captura de paquetes mínima sugerida es de 600 segundos. Debido a los problemas de
sincronización entre varios componentes de la ruta de acceso, es posible que las capturas de paquetes más
cortas no proporcionen datos completos.
Los archivos de datos de captura de paquetes se generan en formato PCAP. Use Wireshark u otras
aplicaciones disponibles habitualmente para abrir archivos PCAP.
Las capturas de paquetes no se admiten en las puertas de enlace basadas en directivas.
Si el parámetro SASurl no está configurado correctamente, es posible que se produzcan errores de
almacenamiento en el seguimiento. Para obtener ejemplos sobre cómo generar correctamente un parámetro
SASurl , consulte Stop-AzVirtualNetworkGatewayPacketCapture.
Pasos siguientes
Para más información sobre VPN Gateway, consulte ¿Qué es VPN Gateway?
Crear una puerta de enlace de red virtual con
redundancia de zona en Azure Availability Zones
Puede implementar puertas de enlace de VPN Gateway y ExpressRoute en Azure Availability Zones. Esto aporta
una mayor disponibilidad, escalabilidad y resistencia a las puertas de enlace de red virtual. Implementar puertas
de enlace en Azure Availability Zones separa de forma física y lógica las puertas de enlace dentro de una región,
y protege la conectividad de red local en Azure de errores de nivel de zona. Para obtener más información,
consulte About zone-redundant virtual network gateways (Acerca de las puertas de enlace de red virtual con
redundancia de zona) y About Azure Availability Zones (Acerca de Azure Availability Zones).
Antes de empezar
Azure PowerShell.

Declare las variables que desea utilizar. Use el ejemplo siguiente y sustituya los valores por los suyos propios
copie y pegue los valores de nuevo para volver a declarar las variables. Cuando especifique la ubicación,
compruebe que se admite la región que especifique. Para más información, consulte las preguntas más
frecuentes.
$RG1 = "TestRG1"
$VNet1 = "VNet1"
$Location1 = "CentralUS"
$FESubnet1 = "FrontEnd"
$BESubnet1 = "Backend"
$GwSubnet1 = "GatewaySubnet"
$VNet1Prefix = "10.1.0.0/16"
$FEPrefix1 = "10.1.0.0/24"
$BEPrefix1 = "10.1.1.0/24"
$GwPrefix1 = "10.1.255.0/27"
$Gw1 = "VNet1GW"
$GwIP1 = "VNet1GWIP"
$GwIPConf1 = "gwipconf1"
2. Crear la red virtual
Cree un grupo de recursos.
New-AzResourceGroup -ResourceGroupName $RG1 -Location $Location1
Cree una red virtual.
$fesub1 = New-AzVirtualNetworkSubnetConfig -Name $FESubnet1 -AddressPrefix $FEPrefix1

$besub1 = New-AzVirtualNetworkSubnetConfig -Name $BESubnet1 -AddressPrefix $BEPrefix1
$vnet = New-AzVirtualNetwork -Name $VNet1 -ResourceGroupName $RG1 -Location $Location1 -AddressPrefix
$VNet1Prefix -Subnet $fesub1,$besub1
3. Adición de la subred de puerta de enlace

de la red virtual. Utilice los siguientes ejemplos para agregar y establecer una subred de puerta de enlace:
Agregue la subred de puerta de enlace.
$getvnet = Get-AzVirtualNetwork -ResourceGroupName $RG1 -Name VNet1

Add-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -AddressPrefix 10.1.255.0/27 -VirtualNetwork $getvnet
Establezca la configuración de subred de puerta de enlace para la red virtual.
$getvnet | Set-AzVirtualNetwork
4. Solicitar una dirección IP pública

En este paso, seleccione las instrucciones que se aplican a la puerta de enlace que desea crear. La selección de
las zonas para la implementación de las puertas de enlace depende de las zonas especificadas para la dirección
IP pública.
Para las puertas de enlace con redundancia de zona
Solicite una dirección IP pública con una SKU de IP pública Estándar y no especifique ninguna zona. En este
caso, la dirección IP pública Estándar creada será una IP pública con redundancia de zona.
$pip1 = New-AzPublicIpAddress -ResourceGroup $RG1 -Location $Location1 -Name $GwIP1 -AllocationMethod Static
-Sku Standard
Para las puertas de enlace zonales

Solicite una dirección IP pública con una SKU de IP pública Estándar . Especifique la zona (1, 2 ó 3). Todas las
instancias de puerta de enlace se implementarán en esta zona.
$pip1 = New-AzPublicIpAddress -ResourceGroup $RG1 -Location $Location1 -Name $GwIP1 -AllocationMethod Static
-Sku Standard -Zone 1
Para las puertas de enlace regionales

Solicite una dirección IP pública con una SKU de IP pública Básica . En este caso, la puerta de enlace se
implementa como una puerta de enlace regional y no se agrega redundancia de zona a la puerta de enlace. Las
instancias de puerta de enlace se crean en las zonas respectivas.
$pip1 = New-AzPublicIpAddress -ResourceGroup $RG1 -Location $Location1 -Name $GwIP1 -AllocationMethod
Dynamic -Sku Basic
5. Creación de la configuración de IP
$getvnet = Get-AzVirtualNetwork -ResourceGroupName $RG1 -Name $VNet1
$subnet = Get-AzVirtualNetworkSubnetConfig -Name $GwSubnet1 -VirtualNetwork $getvnet
$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GwIPConf1 -Subnet $subnet -PublicIpAddress $pip1
6. Creación de la puerta de enlace

Cree la puerta de enlace de red virtual.
Para ExpressRoute
New-AzVirtualNetworkGateway -ResourceGroup $RG1 -Location $Location1 -Name $Gw1 -IpConfigurations $GwIPConf1

-GatewayType ExpressRoute -GatewaySku ErGw1AZ
Para VPN Gateway
New-AzVirtualNetworkGateway -ResourceGroup $RG1 -Location $Location1 -Name $Gw1 -IpConfigurations $GwIPConf1

-GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1AZ
P+F
¿Qué cambiará cuando proceda a implementar estas SKU nuevas?
Desde su perspectiva, puede implementar puertas de enlace con redundancia de zona. Esto significa que todas
las instancias de las puertas de enlace se implementarán en distintas zonas de disponibilidad de Azure, y cada
zona de disponibilidad es un dominio de error y actualización diferente. Por ello, las puertas de enlace son más
confiables, disponibles y resistentes a los errores de la zona.
¿Puedo usar Azure Portal?
Sí, puede usar Azure Portal para implementar las nuevas SKU. Sin embargo, verá estas nuevas SKU solo en las
regiones de Azure que tengan Azure Availability Zones.
¿Qué regiones están disponibles para usar las nuevas SKU?
Consulte Zonas de disponibilidad para obtener la lista más reciente de las regiones disponibles.
¿Puedo convertir/migrar/actualizar mis puertas de enlace de red virtual existentes en puertas de enlace
zonales o con redundancia de zona?
Actualmente no se permite migrar las puertas de enlace de red virtual existentes a puertas de enlace zonales o
con redundancia de zona. Sin embargo, puede eliminar la puerta de enlace existente y volver a crear una puerta
de enlace zonal o con redundancia de zona.
¿Puedo implementar puertas de enlace de VPN y ExpressRoute en la misma red virtual?
Se admite la coexistencia de puertas de enlace de VPN y ExpressRoute en la misma red virtual. Sin embargo, le
recomendamos que reserve un intervalo de direcciones IP /27 para la subred de puerta de enlace.
Configuración de una directiva de IPsec o IKE para
conexiones VPN S2S o conexiones entre redes
virtuales: Azure Portal
Este artículo le guiará por los pasos necesarios para configurar una directiva IPsec o IKE para conexiones VPN de
sitio a sitio o de red virtual a red virtual con VPN Gateway mediante Azure Portal. En las siguientes secciones se
le ayuda a crear y configurar una directiva IPsec o IKE, y aplicarla a una conexión nueva o existente.
Acerca de los parámetros de la directiva IPsec e IKE

combinaciones. Consulte Acerca de los requisitos criptográficos y las puertas de enlace de VPN de Azure para
ver de qué forma esto puede ayudar a garantizar que la conectividad entre locales y de red virtual a red virtual
satisface los requisitos de cumplimiento o de seguridad.
En este artículo se proporcionan instrucciones para crear y configurar una directiva IPsec o IKE, y aplicarla a una
conexión de VPN Gateway nueva o existente.
Consideraciones
La directiva IPsec/IKE solo funciona en las siguientes SKU de puerta de enlace:
VpnGw1~5 and VpnGw1AZ~5AZ _ _ Standard _ y _HighPerformance_ _ Solo se puede especificar
*una _ combinación de directivas para una conexión determinada. _ 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.
Consulte las especificaciones del proveedor de dispositivos VPN para asegurarse de que los dispositivos VPN
locales admiten la directiva. No se pueden establecer conexiones de sitio a sitio o de red virtual a red virtual
si las directivas son incompatibles.
Flujo de trabajo
En esta sección se describe el flujo de trabajo para crear y actualizar una directiva de IPsec o IKE en una conexión
VPN de sitio a sitio o de red virtual a red virtual:
1. Cree una red virtual y una puerta de enlace de VPN.
2. Cree una puerta de enlace de red local para la conexión entre locales, u otra red virtual y puerta de enlace
para la conexión de red virtual a red virtual.
3. Cree una conexión (IPsec o VNet2VNet).
4. Configure, actualice o elimine la directiva IPsec/IKE en los recursos de la conexión.
Las instrucciones que se dan en este artículo le ayudan a instalar y configurar directivas IPsec o IKE, como se
muestra en el diagrama:
Algoritmos criptográficos y niveles de seguridad de clave admitidos
Algoritmos y claves
configurar los clientes:
IP SEC O IK E O P C IO N ES
Cifrado de IKE AES256, AES192, AES128, DES3, DES
Integridad de IKE SHA384, SHA256, SHA1, MD5
Grupo DH DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048,

DHGroup2, DHGroup1, No

Integridad de IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
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)
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)
Requisitos importantes
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)
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 anterior:
IKE corresponde al modo principal o fase 1
IPsec corresponde al modo rápido o fase 2
El Grupo DH especifica el grupo Diffie-Hellmen utilizado en el modo principal o fase 1
El grupo PFS especifica el grupo Diffie-Hellmen utilizado en el modo rápido o 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.
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. 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
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 45 segundos.
Grupos Diffie -Hellman
En la tabla siguiente se muestran los grupos Diffie-Hellman admitidos en la directiva personalizada:

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

VPN de sitio a sitio con directiva IPsec o IKE
En esta sección se describen los pasos necesarios para crear una conexión VPN de sitio a sitio con una directiva
IPsec o IKE. Los pasos siguientes permiten crear la conexión, como se muestra en el diagrama siguiente:
Cree los siguientes recursos, como se muestra en las capturas de pantallas siguientes. Para ver los pasos
necesarios, consulte Creación de una conexión de sitio a sitio mediante Azure Portal.
Red vir tual: TestVNet1
Puer ta de enlace VPN: VNet1GW
Puer ta de enlace de red local: Site6

Connection: VNet1 a Site6
Paso 2: configurar la directiva IPsec o IKE en la conexión de VPN de sitio a sitio

En esta sección, configure una directiva de IPsec o IKE con los algoritmos y parámetros siguientes:
IKE: AES256, SHA384, DHGroup24, tiempo de expiración de DPD 45 segundos
IPsec: AES256, SHA256, PFS No, vigencia de SA 30000 segundos y 102400000 KB
1. Vaya al recurso de conexión, VNet1toSite6 , en Azure Portal. Seleccione la página Configuración y
seleccione Personalizada en Directiva IPsec o IKE para mostrar todas las opciones de configuración. En
la captura de pantalla siguiente se muestra la configuración de acuerdo con la lista:
2. Si usa GCMAES para IPsec, debe usar el mismo algoritmo GCMAES y longitud de clave para la integridad
y el cifrado IPsec. Por ejemplo, en la siguiente captura de pantalla se especifica GCMAES128 tanto para el
cifrado IPsec como para la integridad de IPsec:
3. Opcionalmente, puede seleccionar Habilitar en la opción Use policy based traffic selectors (Usar
selectores de tráfico basados en directivas) para que la puerta de enlace de VPN se pueda conectar a
dispositivos VPN basados en directivas de forma local, como se ha descrito anteriormente.
4. Una vez seleccionadas todas las opciones, seleccione Guardar para confirmar los cambios en el recurso
de conexión. La directiva se aplicará en un minuto aproximadamente.
IMPORTANT
Una vez que se haya especificado una directiva de IPsec o IKE en una conexión, la puerta de enlace de VPN de
Azure solo enviará o aceptará la propuesta de IPsec o IKE con los algoritmos criptográficos y los niveles de clave
especificados en esa conexión en particular. Asegúrese de que el dispositivo VPN local para la conexión usa o
acepta la combinación de directivas exacta. En caso contrario, no se establecerá el túnel VPN de sitio a sitio.
Las opciones Selector de tráfico basado en directiva y Tiempo de expiración de DPD se pueden
especificar con la directiva Predeterminada , sin la directiva IPsec o IKE personalizada, como se muestra en la
captura de pantalla anterior.
De red virtual a red virtual con la directiva IPsec o IKE

Los pasos necesarios para crear una conexión de red virtual a red virtual con una directiva de IPsec o IKE son
similares a los pasos para crear una conexión VPN de sitio a sitio.
1. Siga los pasos del artículo sobre la creación de una conexión de red virtual a red virtual para crear la
suya.
2. Tras completar los pasos, verá dos conexiones de red virtual a red virtual, como se muestra en la captura
de pantalla siguiente del recurso VNet2GW:
3. Vaya al recurso de la conexión y, después, a la Configuración del portal. Seleccione Personalizada en

Directiva IPsec o IKE para mostrar las opciones de directiva personalizadas. Seleccione los algoritmos
criptográficos con las longitudes de clave correspondientes.
La captura muestra una directiva de IPsec o IKE diferente con los algoritmos y parámetros siguientes:
IKE: AES128, SHA1, DHGroup14, tiempo de expiración de DPD 45 segundos
IPsec: GCMAES128, GCMAES128, PFS14, vigencia de SA de 14 400 segundos y 102 400 000 KB
4. Seleccione Guardar para aplicar los cambios de la directiva en el recurso de conexión.
5. Aplique la misma directiva al otro recurso de conexión, VNet2toVNet1. Si no lo hace, el túnel VPN de
IPsec/IKE no se conectará porque no coinciden las directivas.
IMPORTANT
Una vez que se haya especificado una directiva de IPsec o IKE en una conexión, la puerta de enlace de VPN de
Azure solo enviará o aceptará la propuesta de IPsec o IKE con los algoritmos criptográficos y los niveles de clave
especificados en esa conexión en particular. Asegúrese de que las directivas de IPsec para ambas conexiones son
iguales. En caso contrario, no se establecerá la conexión de red virtual a red virtual.
6. Después de completar estos pasos, la conexión se establecerá al cabo de unos minutos y tendrá la
topología de red siguiente:
Eliminación de una directiva de IPsec o IKE de una conexión

1. Para quitar una directiva personalizada de una conexión, vaya hasta el recurso de conexión y, después, a
la página Configuración para ver la directiva actual.
2. Seleccione Predeterminada en la opción Directiva IPsec o IKE . Se quitarán todas las directivas
personalizadas especificadas previamente en la conexión y se restaurará la configuración predeterminada
de IPsec/IKE en esta conexión:
3. Seleccione Guardar para quitar la directiva personalizada y restaurar la configuración predeterminada

de IPsec o IKE en la conexión.
Pasos siguientes
Para obtener información sobre los selectores de tráfico basados en directivas, vea Connect multiple on-
premises policy-based VPN devices (Conectar varios dispositivos VPN basados en directivas locales).
Configurar una directiva de IPsec o IKE para
conexiones VPN de sitio a sitio o de red virtual a
red virtual
Este artículo le guiará por los pasos para configurar una directiva de IPsec o IKE para conexiones VPN de sitio a
sitio o de red virtual a red virtual mediante el modelo de implementación de Resource Manager y PowerShell.
Acerca de los parámetros de la directiva de IPsec e IKE para Azure

VPN gateway
combinaciones. En About cryptographic requirements and Azure VPN gateways (Acerca de los requisitos de
cifrado y las puertas de enlace de VPN de Azure) se describe la manera en que esto puede ayudar a garantizar
que la conectividad entre locales y de red virtual a red virtual satisface los requisitos de cumplimiento o
seguridad.
En este artículo se proporcionan instrucciones para crear y configurar una directiva de IPsec o IKE y aplicarla a
una conexión nueva o existente:
Parte 1: flujo de trabajo para crear y establecer una directiva de IPsec o IKE
Parte 2: algoritmos criptográficos y niveles de clave admitidos
Parte 3: crear una conexión VPN de sitio a sitio con una directiva de IPsec o IKE
Parte 4: crear una conexión de red virtual a red virtual con una directiva de IPsec o IKE
Parte 5: administrar (crear, agregar, quitar) una directiva de IPsec o IKE para una conexión
IMPORTANT
1. Tenga en cuenta que la directiva de IPsec/IKE solo funciona en las SKU de puerta de enlace siguiente:
VpnGw1, VpnGw2, VpnGw3 (basadas en enrutamiento)
Standard _ y _ HighPerformance (basadas en rutas)
2. Solo se puede especificar una combinación de directivas para una conexión dada.
3. 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.
4. Consulte las especificaciones del proveedor de dispositivos VPN para asegurarse de que los dispositivos VPN locales
admiten la directiva. No se pueden establecer conexiones de sitio a sitio o de red virtual a red virtual si las directivas
son incompatibles.
Parte 1: flujo de trabajo para crear y establecer una directiva de IPsec

o IKE
En esta sección se describe el flujo de trabajo para crear y actualizar una directiva de IPsec o IKE en una conexión
VPN de sitio a sitio o de red virtual a red virtual:
1. Crear una red virtual y una puerta de enlace de VPN
2. Crear una puerta de enlace de red local para la conexión entre locales, u otra red virtual y puerta de enlace
para la conexión de red virtual a red virtual
3. Crear una directiva de IPsec o IKE con los algoritmos y parámetros seleccionados
4. Crear una conexión (IPsec o de red virtual a red virtual) con la directiva de IPsec o IKE
5. Agregar, actualizar o quitar una directiva de IPsec o IKE para una conexión existente
Las instrucciones incluidas en este artículo le ayudan a instalar y configurar directivas de IPsec o IKE como se
muestra en el diagrama:
Parte 2: algoritmos criptográficos y niveles de clave admitidos

configurar los clientes:
Grupo DH DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048,

DHGroup2, DHGroup1, No

Integridad de IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
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)
Selector de tráfico UsePolicyBasedTrafficSelectors** ($True/$False; Opcional,

valor predeterminado $False si no se especifica)
IMPORTANT
1. 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)
2. Si se usa GCMAES para el algoritmo de cifrado IPsec, se debe seleccionar el mismo algoritmo
GCMAES y longitud de clave para la integridad de IPsec; por ejemplo, el uso de GCMAES128 para
ambos
3. En la tabla anterior:
IKEv2 corresponde al modo principal o fase 1
IPsec corresponde al modo rápido o fase 2
El Grupo DH especifica el grupo Diffie-Hellmen utilizado en el modo principal o fase 1
El grupo PFS especifica el grupo Diffie-Hellmen utilizado en el modo rápido o fase 2
4. La vigencia de SA del modo principal de IKEv2 se fija en 28 800 segundos en las puertas de enlace de VPN de
Azure
5. Si establece "UsePolicyBasedTrafficSelectors" en $True en una conexión, configurará la puerta de enlace de VPN de
Azure de modo que se conecte al firewall 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. 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).
En la tabla siguiente se muestran los grupos Diffie-Hellman admitidos en la directiva personalizada:

DHGroup2048

Consulte RFC3526 y RFC5114 para ver información más detallada.
Parte 3: crear una conexión VPN de sitio a sitio con una directiva de
IPsec o IKE
En esta sección se describen los pasos necesarios para crear una conexión VPN de sitio a sitio con una directiva
de IPsec o IKE. Con los pasos siguientes crea la conexión como se muestra en el diagrama:
Consulte Creación de una conexión VPN de sitio a sitio para obtener instrucciones detalladas sobre cómo crear
una conexión VPN de sitio a sitio.
Antes de empezar
Instale los cmdlets de PowerShell de Azure Resource Manager. Vea Información general sobre Azure
PowerShell para obtener más información sobre la instalación de los cmdlets de PowerShell.
Para este ejercicio, se empieza por declarar las variables. Asegúrese de reemplazar los valores por los suyos
propios cuando realice la configuración para el entorno de producción.
$Sub1 = "<YourSubscriptionName>"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$DNS1 = "8.8.8.8"
$LNGName6 = "Site6"
$LNGPrefix61 = "10.61.0.0/16"
$LNGPrefix62 = "10.62.0.0/16"
$LNGIP6 = "131.107.72.22"
2. Conexión a su suscripción y creación de un nuevo grupo de recursos
Asegúrese de cambiar el modo de PowerShell para que use los cmdlets del Administrador de recursos. Para
obtener más información, consulte Uso de Windows PowerShell con el Administrador de recursos.
Abre la consola de PowerShell y conéctate a tu cuenta. Use el siguiente ejemplo para ayudarle a conectarse:
Connect-AzAccount
3. Creación de la red virtual, la puerta de enlace de VPN y la puerta de enlace de red local
En el ejemplo siguiente se crea la red virtual, TestVNet1, con tres subredes y VPN Gateway. Al reemplazar
valores, es importante que siempre asigne el nombre GatewaySubnet a la subred de la puerta de enlace. Si usa
otro, se produce un error al crear la puerta de enlace.



$gw1pip1

$gw1ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

$LNGIP6 -AddressPrefix $LNGPrefix61,$LNGPrefix62
Paso 2: Creación de una conexión VPN de sitio a sitio con una directiva IPsec/IKE
El script de ejemplo siguiente crea una directiva de IPsec o IKE con los algoritmos y parámetros siguientes:
IPsec: AES256, SHA256, sin PFS, 14 400 segundos de vigencia de SA y 102 400 000 KB

IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 14400 -SADataSizeKilobytes
102400000
Si usa GCMAES para IPsec, debe usar el mismo algoritmo GCMAES y longitud de clave para la integridad y el
cifrado IPsec. En el ejemplo anterior, los parámetros correspondientes serán "-IpsecEncryption GCMAES256 -
IpsecIntegrity GCMAES256" cuando se use GCMAES256.
2. Crear la conexión VPN de sitio a sitio con la directiva de IPsec o IKE
Cree una conexión VPN de sitio a sitio y aplique la directiva de IPsec o IKE creada anteriormente.
$lng6 = Get-AzLocalNetworkGateway -Name $LNGName6 -ResourceGroupName $RG1

$vnet1gw -LocalNetworkGateway2 $lng6 -Location $Location1 -ConnectionType IPsec -IpsecPolicies $ipsecpolicy6
-SharedKey 'AzureA1b2C3'
Opcionalmente, puede agregar "-UsePolicyBasedTrafficSelectors $True" al cmdlet para crear la conexión a fin de
permitir que la puerta de enlace de VPN se conecte a dispositivos VPN basados en directivas de forma local,
como se ha descrito anteriormente.
IMPORTANT
Una vez que se haya especificado una directiva de IPsec o IKE en una conexión, la puerta de enlace de VPN de Azure solo
enviará o aceptará la propuesta de IPsec o IKE con los algoritmos criptográficos y los niveles de clave especificados en esa
conexión en particular. Asegúrese de que el dispositivo VPN local para la conexión usa o acepta la combinación de
directivas exacta. En caso contrario, no se establecerá el túnel VPN de sitio a sitio.
Parte 4: crear una conexión de red virtual a red virtual con una
directiva de IPsec o IKE
Los pasos necesarios para crear una conexión de red virtual a red virtual con una directiva de IPsec o IKE son
similares a los pasos para crear una conexión VPN de sitio a sitio. Con los scripts de ejemplo siguientes crea la
conexión como se muestra en el diagrama:
Consulte Creación de una conexión de red virtual a red virtual para conocer los pasos detallados para crear una
conexión de red virtual a red virtual. Tiene que completar la parte 3 para crear y configurar TestVNet1 y VPN
Gateway.
Paso 1: crear la segunda red virtual y la puerta de enlace de VPN
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$DNS2 = "8.8.8.8"
2. Creación de la segunda red virtual y la puerta de enlace de VPN en el nuevo grupo de recursos



$gw2pip1

$gw2ipconf1 -GatewayType Vpn -VpnType RouteBased -GatewaySku HighPerformance
Paso 2: Creación de una conexión de red virtual a red virtual con la directiva de IPsec o IKE
De forma similar a la conexión VPN de sitio a sitio, cree una directiva de IPsec o IKE y aplíquela a la nueva
conexión.
El script de ejemplo siguiente crea una directiva de IPsec o IKE diferente con los algoritmos y parámetros
siguientes:
IKEv2: AES128, SHA1, DHGroup14
IPsec: GCMAES128, GCMAES128, PFS14, vigencia de SA de 14 400 segundos y 102 400 000 KB

IpsecEncryption GCMAES128 -IpsecIntegrity GCMAES128 -PfsGroup PFS14 -SALifeTimeSeconds 14400 -
SADataSizeKilobytes 102400000
2. Crear conexiones de red virtual a red virtual con la directiva de IPsec o IKE
Cree una conexión de red virtual a red virtual y aplique la directiva de IPsec o IKE creada. En este ejemplo,
ambas puertas de enlace están en la misma suscripción. Por esta razón, es posible crear y configurar las dos
conexiones con la misma directiva de IPsec o IKE en la misma sesión de PowerShell.

$vnet1gw -VirtualNetworkGateway2 $vnet2gw -Location $Location1 -ConnectionType Vnet2Vnet -IpsecPolicies
$ipsecpolicy2 -SharedKey 'AzureA1b2C3'

$vnet2gw -VirtualNetworkGateway2 $vnet1gw -Location $Location2 -ConnectionType Vnet2Vnet -IpsecPolicies
$ipsecpolicy2 -SharedKey 'AzureA1b2C3'
IMPORTANT
Una vez que se haya especificado una directiva de IPsec o IKE en una conexión, la puerta de enlace de VPN de Azure solo
enviará o aceptará la propuesta de IPsec o IKE con los algoritmos criptográficos y los niveles de clave especificados en esa
conexión en particular. Asegúrese de que las directivas de IPsec para ambas conexiones son iguales. En caso contrario, no
se establecerá la conexión de red virtual a red virtual.
Después de completar estos pasos, la conexión se establecerá al cabo de unos minutos y tendrá la topología de
red siguiente, tal como se mostró al principio:
Parte 5: actualizar una directiva de IPsec o IKE para una conexión

En la última sección se muestra cómo administrar la directiva de IPsec o IKE para una conexión existente de sitio
a sitio o de red virtual a red virtual. En el ejercicio siguiente se explica cómo se realizan las siguientes
operaciones en una conexión:
1. Mostrar la directiva de IPsec o IKE de una conexión
2. Agregar o actualizar la directiva de IPsec o IKE para una conexión
3. Eliminar la directiva de IPsec o IKE de una conexión
Los mismos pasos se aplican a las conexiones de sitio a sitio y de red virtual a red virtual.
IMPORTANT
La directiva de IPsec o IKE solo se admite en las puertas de enlace de VPN basadas en rutas Standard y HighPerformance.
No funciona en la SKU de puerta de enlace básica o la puerta de enlace de VPN basada en directivas.
1. Mostrar la directiva de IPsec o IKE de una conexión

En el ejemplo siguiente se muestra cómo obtener la directiva de IPsec o IKE configurada en una conexión. Los
scripts son una continuación de los ejercicios anteriores.
$connection6.IpsecPolicies
El último comando muestra la directiva de IPsec o IKE actual configurada en la conexión, si existe. La siguiente es
una salida de ejemplo para la conexión:
SALifeTimeSeconds : 14400
SADataSizeKilobytes : 102400000
IpsecEncryption : AES256
IpsecIntegrity : SHA256
IkeEncryption : AES256
IkeIntegrity : SHA384
DhGroup : DHGroup24
PfsGroup : PFS24
Si no hay ninguna directiva de IPsec o IKE configurada, el comando (PS> $connection6.IpsecPolicies) obtiene un
valor devuelto vacío. Esto no significa que IPsec o IKE no esté configurado en la conexión, sino que no hay
ninguna directiva de IPsec o IKE personalizada. La conexión real usa la directiva predeterminada que se negocia
entre el dispositivo VPN local y Azure VPN Gateway.
2. Agregar o actualizar una directiva de IPsec o IKE para una conexión
Los pasos para agregar una nueva directiva o actualizar una directiva existente en una conexión son los mismos:
crear una directiva y, después, aplicar la nueva directiva a la conexión.
$newpolicy6 = New-AzIpsecPolicy -IkeEncryption AES128 -IkeIntegrity SHA1 -DhGroup DHGroup14 -

IpsecEncryption AES256 -IpsecIntegrity SHA256 -PfsGroup None -SALifeTimeSeconds 14400 -SADataSizeKilobytes
102400000
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies

$newpolicy6
Para habilitar "UsePolicyBasedTrafficSelectors" al conectarse a un dispositivo VPN local basado en directivas,

agregue el parámetro "-UsePolicyBaseTrafficSelectors" al cmdlet o establézcalo en $False para deshabilitar la
opción:
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6 -IpsecPolicies

$newpolicy6 -UsePolicyBasedTrafficSelectors $True
Puede obtener la conexión de nuevo para comprobar si la directiva está actualizada.

$connection6.IpsecPolicies
Debería ver la salida de la última línea tal como se muestra en el ejemplo siguiente:
SALifeTimeSeconds : 14400
SADataSizeKilobytes : 102400000
IpsecEncryption : AES256
IpsecIntegrity : SHA256
IkeEncryption : AES128
IkeIntegrity : SHA1
DhGroup : DHGroup14
PfsGroup : None
3. Eliminar una directiva de IPsec o IKE de una conexión

Una vez que se quite la directiva personalizada de una conexión, Azure VPN Gateway vuelve a la lista
predeterminada de propuestas de IPsec o IKE y vuelve a negociar con el dispositivo VPN local.
$currentpolicy = $connection6.IpsecPolicies[0]
$connection6.IpsecPolicies.Remove($currentpolicy)
Set-AzVirtualNetworkGatewayConnection -VirtualNetworkGatewayConnection $connection6
Puede usar el mismo script para comprobar si la directiva se ha quitado de la conexión.
Pasos siguientes
Para obtener información sobre los selectores de tráfico basados en directivas, vea Connect multiple on-
premises policy-based VPN devices (Conectar varios dispositivos VPN basados en directivas locales).
Configuración de conexiones VPN S2S activo-activo
con Azure VPN Gateway
Este artículo le guiará por los pasos para crear conexiones activo-activo entre entornos locales y de red virtual a
red virtual mediante el modelo de implementación de Resource Manager y PowerShell. También puede
configurar una puerta de enlace activo-activo en Azure Portal.
Acerca de las conexiones entre entornos locales de alta disponibilidad

Para lograr una alta disponibilidad en la conectividad de red virtual a red virtual y entre entornos locales, debe
implementar varias puertas de enlace VPN y establecer varias conexiones en paralelo entre sus redes y Azure.
Consulte Conectividad de alta disponibilidad entre locales y de red virtual a red virtual para obtener
información general de las opciones de conectividad y la topología.
En este artículo se proporcionan instrucciones para configurar una conexión VPN activo-activo entre entornos
locales, así como una conexión activo-activo entre dos redes virtuales.
Parte 1: Creación y configuración de Azure VPN Gateway en el modo activo-activo
Parte 2: Establecimiento de conexiones activo-activo entre entornos locales
Parte 3: Establecimiento de conexiones activo-activo de red virtual a red virtual
Si ya tiene una instancia de VPN Gateway, puede hacer lo siguiente:
Actualizar una instancia de VPN Gateway existente de activo-en espera a activo-activo o viceversa
Puede combinar todos estos elementos para crear una red más compleja de alta disponibilidad que satisfaga
sus necesidades.
IMPORTANT
El modo activo-activo está disponible para todas las SKU, excepto Basic.
Parte 1: Creación y configuración de puertas de enlace VPN activo-

activo
Los pasos a continuación configurarán Azure VPN Gateway en modos activo-activo. Las diferencias clave entre
las puertas de enlace activo-activo y activo-en espera:
Tiene que crear dos configuraciones de IP de puerta de enlace con dos direcciones IP públicas
Tiene que establecer la marca EnableActiveActiveFeature
La SKU de puerta de enlace debe ser VpnGw1, VpnGw2, VpnGw3 o HighPerformance (SKU heredada).
Las demás propiedades son las mismas que las de las puertas de enlace que no son activo-activo.
Antes de empezar
Tendrá que instalar los cmdlets de PowerShell de Azure Resource Manager si no quiere usar CloudShell en el
explorador. Vea Información general sobre Azure PowerShell para obtener más información sobre la
instalación de los cmdlets de PowerShell.
Paso 1: Creación y configuración de VNet1
Para este ejercicio, comenzaremos declarando las variables. Si utiliza la opción "Probar" de Cloud Shell, se
conectará automáticamente a su cuenta. Si usa PowerShell localmente, utilice el siguiente ejemplo para ayudarle
a conectarse:
Connect-AzAccount
En el ejemplo siguiente, se declaran las variables con los valores para este ejercicio. Asegúrese de reemplazar los
valores por los suyos propios cuando realice la configuración para el entorno de producción. Puede usar estas
variables si está practicando los pasos para familiarizarse con este tipo de configuración. Modifique las variables
y después copie y pegue todo en la consola de PowerShell.
$Sub1 = "Ross"
$RG1 = "TestAARG1"
$VNetPrefix11 = "10.11.0.0/16"
$VNetPrefix12 = "10.12.0.0/16"
$FESubPrefix1 = "10.11.0.0/24"
$BESubPrefix1 = "10.12.0.0/24"
$GWSubPrefix1 = "10.12.255.0/27"
$VNet1ASN = 65010
$DNS1 = "8.8.8.8"
$Connection151 = "VNet1toSite5_1"
$Connection152 = "VNet1toSite5_2"
2. Creación de un nuevo grupo de recursos

Use el ejemplo siguiente para crear un grupo de recursos:
En el ejemplo siguiente se crea una red virtual denominada TestVNet1 y tres subredes llamadas:
GatewaySubnet, FrontEnd y Backend. Al reemplazar valores, es importante que siempre asigne el nombre
GatewaySubnet a la subred de la puerta de enlace. Si usa otro, se produce un error al crear la puerta de enlace.


Paso 2: Creación de la puerta de enlace de VPN para TestVNet1 con modo activo -activo
1. Creación de las configuraciones de direcciones de IP públicas y la IP de puerta de enlace
Solicite que se asignen dos direcciones IP públicas a la puerta de enlace que creará para la red virtual. También


$gw1pip1
$gw1pip2
2. Creación de la puerta de enlace VPN con una configuración activo-activo

Cree la puerta de enlace de red virtual para TestVNet1. Tenga en cuenta que hay dos entradas de
GatewayIpConfig y la marca EnableActiveActiveFeature está establecida. Se tardan unos 45 minutos o algo más
en crear una puerta de enlace.

$gw1ipconf1,$gw1ipconf2 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -Asn $VNet1ASN -
EnableActiveActiveFeature -Debug
3. Obtención de las direcciones IP públicas de puerta de enlace y la dirección IP del par BGP
Una vez creada la puerta de enlace, debe obtener la dirección IP del par BGP en Azure VPN Gateway. Esta
dirección es necesaria para configurar la instancia de Azure VPN Gateway como par BGP para los dispositivos
de VPN local.
$gw1pip1 = Get-AzPublicIpAddress -Name $GW1IPName1 -ResourceGroupName $RG1

$gw1pip2 = Get-AzPublicIpAddress -Name $GW1IPName2 -ResourceGroupName $RG1
Use los siguientes cmdlets para mostrar las dos direcciones IP públicas asignadas a la puerta de enlace VPN y
sus correspondientes direcciones IP del par BGP para cada instancia de puerta de enlace:
PS D:\> $gw1pip1.IpAddress
40.112.190.5
PS D:\> $gw1pip2.IpAddress
138.91.156.129
PS D:\> $vnet1gw.BgpSettingsText
{
"Asn": 65010,
"BgpPeeringAddress": "10.12.255.4,10.12.255.5",
"PeerWeight": 0
}
El orden de las direcciones IP públicas para las instancias de puerta de enlace y las direcciones de
emparejamiento BGP correspondiente es el mismo. En este ejemplo, la máquina virtual de la puerta de enlace
con la IP pública 40.112.190.5 utilizará 10.12.255.4 como su dirección de emparejamiento BGP y la puerta de
enlace con 138.91.156.129 usará 10.12.255.5. Esta información es necesaria cuando configura los dispositivos
VPN locales en conexión con la puerta de enlace activo-activo. La puerta de enlace se muestra en el diagrama
siguiente con todas las direcciones:
Una vez creada la puerta de enlace, puede usarla para establecer conexión activo-activo entre entornos locales o
de red virtual a red virtual. Las siguientes secciones lo guiarán por los pasos necesarios para completar el
ejercicio.
Parte 2: Establecimiento de una conexión activo-activo entre entornos

locales
dispositivo VPN local y una conexión para conectarse a la puerta de enlace de VPN de Azure con la puerta de
enlace de red local. En este ejemplo, la instancia de Azure VPN Gateway está en modo activo-activo. Como
resultado, aunque hay solo un dispositivo VPN local (puerta de enlace de red local) y un recurso de conexión,
ambas instancias de Azure VPN Gateway establecerán túneles VPN de S2S con el dispositivo local.
Antes de continuar, asegúrese de que ha completado la parte 1 de este ejercicio.
Este ejercicio continuará generando la configuración mostrada en el diagrama. Asegúrese de reemplazar los
valores por los que desea usar para su configuración.
$RG5 = "TestAARG5"
$LNGName51 = "Site5_1"
$LNGPrefix51 = "10.52.255.253/32"
$LNGIP51 = "131.107.72.22"
$LNGASN5 = 65050
$BGPPeerIP51 = "10.52.255.253"
Un par de cosas a tener en cuenta con respecto a los parámetros de la puerta de enlace de red local:
enlace de VPN o en otros distintos. Este ejemplo los muestra en distintos grupos de recursos pero en la
misma ubicación de Azure.
Si hay un único dispositivo VPN local como se muestra anteriormente, la conexión activo-activo puede
trabajar con o sin el protocolo BGP. Este ejemplo utiliza BGP para la conexión entre redes locales.
Si BGP está habilitado el prefijo que debe declarar para la puerta de enlace de red local es la dirección del
host de la dirección IP del par BGP en el dispositivo VPN. En este caso, es un prefijo /32 de
"10.52.255.253/32".
iguales, tiene que cambiar el ASN de la red virtual si el dispositivo VPN local ya utiliza el ASN para
emparejarse con otros vecinos de BGP.
2. Cree las puertas de enlace de red local para Site5
Antes de continuar, asegúrese de que sigue conectado a la suscripción 1. Cree el grupo de recursos si aún no se
ha creado.
1. Obtenga las dos puertas de enlace

$lng5gw1 = Get-AzLocalNetworkGateway -Name $LNGName51 -ResourceGroupName $RG5
2. Cree la conexión de TestVNet1 a Site5

En este paso, crea la conexión de TestVNet1 a Site5_1 con "EnableBGP" establecido como $True.

$vnet1gw -LocalNetworkGateway2 $lng5gw1 -Location $Location1 -ConnectionType IPsec -SharedKey 'AzureA1b2C3'
-EnableBGP $True
3. Parámetros VPN y BGP para el dispositivo VPN local

En el ejemplo siguiente se enumeran los parámetros que deberá especificar en la sección de configuración de
BGP en el dispositivo VPN local para este ejercicio:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.253
- Azure VNet BGP IP 1 : 10.12.255.4 for tunnel to 40.112.190.5
- Static routes : Destination 10.12.255.4/32, nexthop the VPN tunnel interface to 40.112.190.5
Destination 10.12.255.5/32, nexthop the VPN tunnel interface to 138.91.156.129
La conexión debe establecerse después de unos minutos y se iniciará la sesión de emparejamiento BGP una vez
establecida la conexión IPsec. En este ejemplo hasta ahora se ha configurado un solo dispositivo VPN local, con
el resultado que se muestra en el diagrama a continuación:
Paso 3: Conexión de dos dispositivos VPN locales con la puerta de enlace VPN activo -activo
Si tiene dos dispositivos VPN en la misma red local, puede lograr redundancia dual conectando Azure VPN
Gateway al segundo dispositivo VPN.
1. Creación de la puertas de enlace de red local para Site5
La dirección IP de puerta de enlace, el prefijo de dirección y la dirección de emparejamiento de BGP para la
segunda puerta de enlace de red local no pueden superponerse con la puerta de enlace de red local anterior en
la misma red local.
$LNGName52 = "Site5_2"
$LNGPrefix52 = "10.52.255.254/32"
$LNGIP52 = "131.107.72.23"
$BGPPeerIP52 = "10.52.255.254"

2. Paso 2: Conexión de la puerta de enlace de red virtual y la segunda puerta de enlace de red local
Cree la conexión de TestVNet1 a Site5_2 con "EnableBGP" establecido como $True
$lng5gw2 = Get-AzLocalNetworkGateway -Name $LNGName52 -ResourceGroupName $RG5

$vnet1gw -LocalNetworkGateway2 $lng5gw2 -Location $Location1 -ConnectionType IPsec -SharedKey 'AzureA1b2C3'
-EnableBGP $True
3. Los parámetros VPN y BGP para el segundo dispositivo VPN local

De forma similar, a continuación se indican los parámetros que tendrá que especificar en el segundo dispositivo
VPN:
- Site5 ASN : 65050

- Site5 BGP IP : 10.52.255.254
- Static routes : Destination 10.12.255.4/32, nexthop the VPN tunnel interface to 40.112.190.5
Destination 10.12.255.5/32, nexthop the VPN tunnel interface to 138.91.156.129
Una vez que se establece la conexión (túneles), tendrá dos dispositivos VPN redundantes y túneles que conectan
la red local y Azure:
Parte 3: Establecimiento de una conexión activo-activo de red virtual

a red virtual
En esta sección se crea una conexión de red virtual a red virtual activo-activo con BGP.
Las instrucciones que siguen son continuación de los pasos anteriores ya explicados. Tiene que completar la
Parte 1 para crear y configurar TestVNet1 y VPN Gateway con BGP.
Paso 1: cree TestVNet2 y la puerta de enlace de VPN
En este ejemplo, las redes virtuales pertenecen a la misma suscripción. Puede configurar las conexiones de red
virtual a red virtual entre distintas suscripciones, para ello consulte Configuración de una conexión de red
virtual a red virtual para más información. Asegúrese de agregar "-EnableBgp True" al crear las conexiones para
habilitar BGP.
$RG2 = "TestAARG2"
$VNetPrefix21 = "10.21.0.0/16"
$VNetPrefix22 = "10.22.0.0/16"
$FESubPrefix2 = "10.21.0.0/24"
$BESubPrefix2 = "10.22.0.0/24"
$GWSubPrefix2 = "10.22.255.0/27"
$VNet2ASN = 65020
$DNS2 = "8.8.8.8"


3. Creación de la puerta de enlace VPN activo-activo para TestVNet2

Solicite que se asignen dos direcciones IP públicas a la puerta de enlace que creará para la red virtual. También


$gw2pip1
$gw2pip2
Cree la puerta de enlace VPN con el número de AS y la marca "EnableActiveActiveFeature". Tenga en cuenta que
debe reemplazar el valor predeterminado del ASN en las puertas de enlace de VPN de Azure. Los ASN para las
redes virtuales conectadas deben ser diferentes para habilitar el enrutamiento de tránsito y de BGP.
$gw2ipconf1,$gw2ipconf2 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1 -Asn $VNet2ASN -
EnableActiveActiveFeature

En este ejemplo, ambas puertas de enlace están en la misma suscripción. Puede completar este paso en la
misma sesión de PowerShell.
1. Obtenga ambas puertas de enlace
Asegúrese de iniciar sesión y conectarse a la suscripción 1.

2. Cree ambas conexiones

En este paso, creará la conexión de TestVNet1 a TestVNet2 y viceversa.


IMPORTANT
Asegúrese de habilitar BGP para AMBAS conexiones.
Después de completar estos pasos, la conexión se establecerá en unos minutos y la sesión de emparejamiento
de BGP se iniciará una vez se complete la conexión de red virtual a red virtual con redundancia dual:
Actualización de una instancia de VPN Gateway existente

Al cambiar una puerta de enlace de activo-en espera a activo-activo, crea otra dirección IP pública y después
agrega una segunda configuración IP de puerta de enlace. En esta sección, le ayudamos a cambiar una instancia
de Azure VPN Gateway existente del modo activo-en espera al modo activo-activo o viceversa mediante
PowerShell. También puede cambiar una puerta de enlace en Azure Portal en la página Configuración de la
Cambio de una puerta de enlace de activo -en espera a una puerta de enlace activo -activo
En el ejemplo siguiente se convierte una puerta de enlace de activo-en espera en puerta de enlace activo-activo.
Reemplace los siguientes parámetros utilizados para los ejemplos con los valores que necesita para su propia
configuración y, a continuación, declare estas variables.
$GWName = "TestVNetAA1GW"
$VNetName = "TestVNetAA1"
$RG = "TestVPNActiveActive01"
$GWIPName2 = "gwpip2"
$GWIPconf2 = "gw1ipconf2"
Después de declarar las variables, puede copiar y pegar este ejemplo en la consola de PowerShell.

$gw = Get-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG
$location = $gw.Location
2. Cree la dirección IP pública, y agregue una segunda configuración IP de puerta de enlace
$gwpip2 = New-AzPublicIpAddress -Name $GWIPName2 -ResourceGroupName $RG -Location $location -

Add-AzVirtualNetworkGatewayIpConfig -VirtualNetworkGateway $gw -Name $GWIPconf2 -Subnet $subnet -
3. Habilite el modo activo-activo y actualice la puerta de enlace

En este paso, habilite el modo activo-activo y actualice la puerta de enlace. En el ejemplo, la instancia de VPN
Gateway usa actualmente una SKU estándar heredada. Sin embargo, el modo activo-activo no admite la SKU
estándar. Para cambiar el tamaño de la SKU heredada a uno que sea compatible (en este caso,
HighPerformance), solo tiene que especificar la SKU heredada compatible que quiere usar.
No se puede cambiar una SKU heredada a una de las SKU nuevas con este paso. Solo puede cambiar el
tamaño de una SKU heredada a otra SKU heredada compatible. Por ejemplo, no puede cambiar la SKU de
estándar a VpnGw1 (aunque VpnGw1 se admite para el modo activo-activo) porque el nivel estándar
incluye una SKU heredada y VpnGw1 incluye una SKU actual. Para obtener más información acerca de
cómo cambiar el tamaño y migrar las SKU, consulte SKU de Gateway.
Si desea cambiar el tamaño de una SKU actual, por ejemplo, VpnGw1 a VpnGw3, puede hacerlo mediante
este paso porque las SKU se encuentran en la misma familia. Para ello, debe usar el valor:
-GatewaySku VpnGw3 .
Al usar este valor en su entorno, si no es necesario cambiar el tamaño de la puerta de enlace, no tendrá que
especificar -GatewaySku. Tenga en cuenta que en este paso debe establecer el objeto de puerta de enlace en
PowerShell para desencadenar la actualización real. Esta actualización puede tardar entre 30 y 45 minutos,
incluso si no va a cambiar el tamaño de la puerta de enlace.
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -EnableActiveActiveFeature -GatewaySku

HighPerformance
Cambio de una puerta de enlace de activo -activo a una puerta de enlace activo -en espera
Reemplace los siguientes parámetros utilizados para los ejemplos con los valores que necesita para su propia
configuración y, a continuación, declare estas variables.
$GWName = "TestVNetAA1GW"
$RG = "TestVPNActiveActive01"
Tras declarar las variables, obtenga el nombre de la configuración IP que desea quitar.
$gw = Get-AzVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG

$ipconfname = $gw.IpConfigurations[1].Name
2. Quite la configuración de IP de puerta de enlace y deshabilite el modo activo-activo

Use este ejemplo para quitar la configuración IP de la puerta de enlace y deshabilitar el modo activo-activo.
Tenga en cuenta que debe establecer el objeto de puerta de enlace en PowerShell para desencadenar la
actualización real.
Remove-AzVirtualNetworkGatewayIpConfig -Name $ipconfname -VirtualNetworkGateway $gw

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -DisableActiveActiveFeature
Esta actualización puede tardar hasta 30 o 45 minutos.
Pasos siguientes
Solución de problemas de VPN Gateway
Las conexiones de VPN Gateway pueden tener errores por diversos motivos. En este artículo encontrará
vínculos que le ayudarán a solucionar estos problemas. Si quiere obtener una lista completa, consulte los
artículos incluidos en la tabla de contenido que se encuentra en la sección Solución de problemas , a la
izquierda de esta página.
Escenarios y solución de problemas

Validación del rendimiento de la VPN en una red virtual
Una conexión a la puerta de enlace de la VPN le permite establecer una conectividad segura y entre
entornos locales entre su red virtual dentro de Azure y la infraestructura local de TI. Este artículo muestra
cómo validar el rendimiento de red de los recursos locales en una máquina virtual de Azure. También
proporciona orientación para la solución de errores.
Configuración de dispositivos de firewall y VPN
En este artículo se proporcionan varias soluciones sugeridas para dispositivos de firewall o VPN de
terceros que se usan con VPN Gateway. El proveedor de dispositivos proporciona soporte técnico a los
dispositivos de firewall o VPN de terceros.
En este artículo se enumeran problemas comunes de conexión de punto a sitio que puede experimentar.
También se tratan las posibles causas de estos problemas y sus soluciones.
Después de configurar una conexión VPN de sitio a sitio entre una red local y una red virtual de Azure, la
conexión VPN de repente deja de funcionar y no se puede volver a conectar. Este artículo proporciona
pasos de solución de problemas para ayudarle a resolver este problema.
Pasos siguientes
También puede utilizar estos pasos para validar las conexiones de VNet y VPN.
Configuración del dispositivo de firewall o VPN de
terceros sugerida por la comunidad para Azure
VPN Gateway
Este artículo proporciona varias soluciones sugeridas para dispositivos de firewall o VPN de terceros que se
usan con Azure VPN Gateway.
NOTE
El proveedor de dispositivos proporciona soporte técnico a los dispositivos de firewall o VPN de terceros.
Más información
En la tabla siguiente se enumeran varios dispositivos comunes y la ayuda relacionada:
P RO DUC TO REF EREN C IA
Cisco ASA Soluciones sugeridas por la comunidad para Cisco ASA en

VPN de Azure
Cisco ISR Soluciones sugeridas por la comunidad para Cisco ISR en

VPN de Azure
Cisco ASR Soluciones sugeridas por la comunidad para Cisco ASR en

VPN de Azure
Sonicwall Busque VPN de Azure en el sitio de Sonicwall
Punto de control Busque VPN de Azure en el sitio de Checkpoint
Juniper Busque VPN de Azure en el sitio de Juniper
Barracuda Soluciones sugeridas por la comunidad para Barracuda en

VPN de Azure
F5 Soluciones sugeridas por la comunidad para F5 en VPN de

Azure
Palo Soluciones sugeridas por la comunidad para Palo en VPN de

Azure
WatchGuard Soluciones sugeridas por la comunidad para Watchguard en

VPN de Azure
Paso siguiente
Configuración de las puertas de enlace de Azure
Dispositivos compatibles conocidos
Validación del rendimiento de la VPN en una red
virtual
Una conexión a la puerta de enlace de la VPN le permite establecer una conectividad segura y entre entornos
locales entre su red virtual dentro de Azure y la infraestructura local de TI.
Este artículo muestra cómo validar el rendimiento de red de los recursos locales en una máquina virtual de
Azure.
NOTE
Este artículo se ha creado para ayudar a diagnosticar problemas comunes y solucionarlos. Si no puede resolver el
problema mediante el uso de la siguiente información, póngase en contacto con soporte técnico.
Información general
La conexión a la puerta de enlace de la VPN afecta a los siguientes componentes:
Dispositivo VPN local (vea una lista de dispositivos VPN validados).
Internet público
Azure VPN Gateway
Azure VM
El siguiente diagrama muestra la conectividad lógica de una red local en una red virtual de Azure a través de
VPN.
Cálculo de la entrada/salida máxima esperada

1. Determine los requisitos de rendimiento de la línea de base de la aplicación.
2. Establezca los límites de rendimiento de la puerta de enlace de VPN de Azure. Para obtener ayuda, consulte
la sección "SKU de puerta de enlace" de Acerca de VPN Gateway.
3. Determine la Guía de rendimiento de la máquina virtual de Azure para el tamaño de la máquina virtual.
4. Establezca el ancho de banda del proveedor de servicios de Internet (ISP).
5. Calcule el rendimiento esperado tomando el menor ancho de banda de la máquina virtual, VPN Gateway o
ISP, que se mide en megabits por segundo (/) dividido por ocho (8).
Si el rendimiento calculado no cumple con los requisitos de rendimiento de línea de base de la aplicación, debe
aumentar el ancho de banda del recurso que identificó como el cuello de botella. Para cambiar el tamaño de una
instancia de Azure VPN Gateway, vea Cambio de una SKU de puerta de enlace. Para cambiar el tamaño de una
máquina virtual, vea Cambio del tamaño de una VM. Si no obtiene el ancho de banda de Internet previsto,
también puede ponerse en contacto con el ISP.
NOTE
El rendimiento de VPN Gateway es un agregado de todas las conexiones de sitio a sitio, de red virtual a red virtual o de
punto a sitio.
Validación del rendimiento de red mediante el uso de herramientas

de rendimiento
Esta validación debe realizarse durante las horas de poca actividad, ya que la saturación de rendimiento del
túnel VPN durante las pruebas provoca que no se produzcan resultados precisos.
La herramienta que se usa para esta prueba es iPerf, que funciona en Windows y Linux, y tiene los modos de
cliente y servidor. Está limitada a 3 GB/s para máquinas virtuales Windows.
Esta herramienta no lleva a cabo operaciones de lectura/escritura en el disco. Solo se produce el tráfico TCP
generado automáticamente de un extremo a otro. Genera estadísticas basadas en la experimentación que mide
el ancho de banda disponible entre los nodos de cliente y servidor. Cuando se realiza la prueba entre dos nodos,
un nodo actúa como servidor y el otro nodo como cliente. Una vez completada esta prueba, se recomienda que
invierta los roles de los nodos para probar el rendimiento de carga y descarga en ambos nodos.
Descarga de iPerf
Descargue iPerf. Para más información, vea la documentación de Ambari.
NOTE
Los productos de terceros que se tratan en este artículo están fabricados por compañías independientes de Microsoft.
Microsoft no otorga ninguna garantía, implícita o de otro tipo, sobre el rendimiento o la confiabilidad de estos productos.
Ejecución de iPerf (iperf3.exe )

1. Habilite una regla NSG/ACL que permita el tráfico (para la prueba de la dirección IP pública en la
máquina virtual de Azure).
2. En ambos nodos, habilite una excepción de firewall para el puerto 5001.
Windows: Ejecute el comando siguiente como administrador:
netsh advfirewall firewall add rule name="Open Port 5001" dir=in action=allow protocol=TCP
localport=5001
Para quitar la regla cuando la prueba esté completa, ejecute este comando:
netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001
Azure Linux: las imágenes de Azure Linux tienen firewalls permisivos. Si hay una aplicación que realiza
la escucha en un puerto, se permite el tráfico. Las imágenes personalizadas que se protegen pueden
necesitar puertos abiertos de forma explícita. Los firewalls de nivel de sistema operativo Linux comunes
incluyen iptables , ufw , o firewalld .
3. En el nodo de servidor, cambie al directorio donde se extrae iperf3.exe. A continuación, ejecute iPerf en el
modo de servidor y configúrela para que escuche el puerto 5001 como se indica a continuación:
cd c:\iperf-3.1.2-win65
iperf3.exe -s -p 5001
NOTE
El puerto 5001 se puede personalizar para tener en cuenta las restricciones particulares del firewall de su entorno.
4. En el nodo de cliente, cambie al directorio donde se extrae la herramienta iperf y luego ejecute el
siguiente comando:
iperf3.exe -c <IP of the iperf Server> -t 30 -p 5001 -P 32
El cliente dirige treinta segundos de tráfico en el puerto 5001 al servidor. La marca "-P" indica que
estamos realizando 32 conexiones simultáneas en el nodo de servidor.
La siguiente pantalla muestra el resultado de este ejemplo:
5. (OPCIONAL) Para conservar los resultados de pruebas, ejecute este comando:
iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32 >> output.txt
6. Después de completar los pasos anteriores, ejecute los mismos pasos con los roles invertidos, de manera
que el nodo servidor será ahora el nodo cliente y viceversa.
NOTE
Iperf no es la única herramienta. NTTTCP es una solución alternativa para la realización de pruebas.
Prueba de máquinas virtuales que ejecutan Windows

Cargue Latte.exe en las máquinas virtuales.
Descargue la versión más reciente de Latte.exe.
Considere la posibilidad de colocar Latte.exe en una carpeta independiente, como c:\tools .
Permitir Latte.exe mediante el firewall de Windows
En el receptor, cree una regla Permitir en el Firewall de Windows para permitir la recepción de tráfico de
Latte.exe. Es más fácil permitir todo el programa Latte.exe por su nombre en lugar de determinados puertos TCP
de entrada.
Permita Latte.exe a través del Firewall de Windows de la siguiente forma:
netsh advfirewall firewall add rule program=<PATH>\latte.exe name="Latte" protocol=any dir=in action=allow
enable=yes profile=ANY
Por ejemplo, si ha copiado Latte.exe a la carpeta "c:\tools", este sería el comando

netsh advfirewall firewall add rule program=c:\tools\latte.exe name="Latte" protocol=any dir=in action=allow
enable=yes profile=ANY
Ejecución de pruebas de latencia

Inicie Latte.exe en el receptor (se ejecuta desde CMD, no desde PowerShell):
latte -a <Receiver IP address>:<port> -i <iterations>
Es suficiente alrededor de 65 000 iteraciones para obtener unos resultados representativos.

Cualquier número de puerto disponible es válido.
Si la máquina virtual tiene la dirección IP 10.0.0.4, sería similar al siguiente:
latte -c -a 10.0.0.4:5005 -i 65100
Inicie Latte.exe en el emisor (se ejecuta desde CMD, no desde PowerShell).

latte -c -a <Receiver IP address>:<port> -i <iterations>
El comando resultante es el mismo que en el receptor, excepto con la adición de "-c" para indicar que se trata del
"cliente" o del emisor.
latte -c -a 10.0.0.4:5005 -i 65100
Espere a que se muestren los resultados. Dependiendo de la distancia que haya entre las máquinas virtuales,
podría llevar unos minutos completarlos. Considere comenzar con menos iteraciones para probar si se ha
realizado correctamente antes de ejecutar pruebas más largas.
Prueba de máquinas virtuales que ejecutan Linux

Use SockPerf para probar las máquinas virtuales.
Instalación de SockPerf en las máquinas virtuales
En las máquinas virtuales Linux (tanto en el emisor como en el receptor), ejecute estos comandos para preparar
SockPerf en las máquinas virtuales:
CentOS y RHEL: instalación de GIT y otras herramientas útiles
sudo yum install gcc -y -q sudo yum install git -y -q sudo yum install gcc-c++ -y
sudo yum install ncurses-devel -y sudo yum install -y automake
Ubuntu: instalación de GIT y otras herramientas útiles

sudo apt-get install build-essential -y sudo apt-get install git -y -q
sudo apt-get install -y autotools-dev sudo apt-get install -y automake
Bash: todo
Desde la línea de comandos de bash (asume que git está instalado)
git clone https://github.com/mellanox/sockperf cd sockperf/ ./autogen.sh ./configure --prefix=
"Make" es más lento, puede tardar varios minutos

make
"Make install" es rápido

sudo make install
Ejecución de SockPerf en las máquinas virtuales

Comandos de ejemplo después de la instalación. Servidor o receptor: asume que la dirección IP del servidor es 10.0.0.4
sudo sockperf sr --tcp -i 10.0.0.4 -p 12345 --full-rtt
Cliente: asume que la dirección IP del servidor es 10.0.0.4

sockperf ping-pong -i 10.0.0.4 --tcp -m 1400 -t 101 -p 12345 --full-rtt
NOTE
Asegúrese de que no haya saltos intermedios (por ejemplo, una aplicación virtual) durante la prueba de rendimiento entre
la máquina virtual y la puerta de enlace. Si los resultados de las pruebas de iPERF/NTTTCP anteriores son deficientes (en
términos de rendimiento total), consulte el siguiente artículo para comprender los factores clave que subyacen a las
posibles causas principales del problema: https://docs.microsoft.com/azure/virtual-network/virtual-network-tcpip-
performance-tuning.
En particular, el análisis del seguimiento de la captura de paquetes (Wireshark/Monitor de red) recopilado en

paralelo del cliente y del servidor durante estas pruebas ayudará a evaluar el rendimiento deficiente. Estos
seguimientos pueden incluir la pérdida de paquetes, la latencia alta, el tamaño de MTU, la fragmentación, la
ventana TCP 0, fragmentos desordenados, etc.
Solución de problemas de copia de archivos lenta

Incluso si el rendimiento global evaluado con los pasos anteriores (iPERF/NTTTCP/etc.) era correcto, es posible
que experimente una copia lenta de los archivos al usar el Explorador de Windows o al arrastrar y soltar en una
sesión de RDP. Este problema suele ser debido a uno o ambos de los siguientes factores:
Las aplicaciones de copia de archivos, como el Explorador de Windows y RDP, no utilizan varios
subprocesos al copiar archivos. Para mejorar el rendimiento, utilice una aplicación de copia de archivos
de multiproceso como Richcopy para copiar archivos mediante 16 o 32 subprocesos. Para cambiar el
número de subprocesos de copia de archivos en Richcopy, haga clic en Acción > Opciones de copia >
Copia de archivos .
NOTE
No todas las aplicaciones funcionan de la misma manera y no todas las aplicaciones o procesos utilizan todos los
subprocesos. Si ejecuta la prueba, puede ver que algunos subprocesos están vacíos y no proporcionarán
resultados precisos de rendimiento. Para comprobar el rendimiento de la transferencia de archivos de la aplicación,
utilice varios subprocesos aumentando el número de subprocesos sucesivamente o disminuyéndolo para
encontrar el rendimiento óptimo de la aplicación o de la transferencia de archivos.
Velocidad de lectura/escritura del disco de VM insuficiente. Para más información, vea Solución de
problemas de Azure Storage.
Interfaz con orientación externa del dispositivo local

Se han mencionado las subredes de los intervalos locales a las que le gustaría que Azure llegara a través de
VPN en la puerta de enlace de la red local. A la vez, defina el espacio de direcciones de la red virtual de Azure en
el dispositivo local.
Puer ta de enlace basada en rutas : La directiva o el selector de tráfico para las VPN basadas en
enrutamiento se configura como conectividad de tipo cualquiera a cualquier (o caracteres comodín).
Puer ta de enlace basada 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.
Conexiones UsePolicyBasedTrafficSelectors : (si se establece "UsePolicyBasedTrafficSelectors" en $True
en una conexión, configurará la puerta de enlace de VPN de Azure de modo que se conecte al firewall
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) hacia y desde los prefijos de red virtual de Azure,
en lugar de cualquiera a cualquiera.
Una configuración inadecuada puede dar lugar a desconexiones frecuentes dentro del túnel, caídas de paquetes,
rendimiento deficiente y latencia.
Comprobación de la latencia
Puede comprobar la latencia con las siguientes herramientas:
WinMTR
TCPTraceroute
ping y psping (estas herramientas pueden proporcionar una buena estimación de RTT, pero no se pueden
usar en todos los casos).
Si observa un pico de latencia alta en cualquiera de los saltos antes de entrar en la red troncal de Microsoft, es
posible que desee realizar más investigaciones con su proveedor de servicios de Internet.
Si se detecta un pico de latencia grande e inusual en los saltos en "msn.net", póngase en contacto con el soporte
técnico de Microsoft para que lo investiguen.
Pasos siguientes
Para más información, consulte el vínculo siguiente:
Ayuda y soporte técnico de Microsoft
Solución de problemas: Problemas de conexión de
punto a sitio de Azure
En este artículo se enumeran problemas comunes de conexión de punto a sitio que puede experimentar.
También se tratan las posibles causas de estos problemas y sus soluciones.
Error de cliente de VPN: No se encontró ningún certificado.

Síntoma
Al intentar conectar a una red virtual de Azure mediante el cliente de VPN, aparece el mensaje de error
siguiente:
No se encuentra un cer tificado que se puede usar con este protocolo de autenticación extendido.
(Error 798)
Causa
Este problema se produce si el certificado de cliente no está en Cer tificados - Usuario
actual\Personal\Cer tificados .
Solución
Para solucionar este problema, siga estos pasos:
1. Abra el Administrador de certificados: haga clic en Inicio , escriba Administrar cer tificados de equipo
y, después, haga clic en Administrar cer tificados de equipo en el resultado de la búsqueda.
2. Asegúrese de que los certificados siguientes están en la ubicación correcta:
C ERT IF IC A DO LO C AT IO N
AzureClient.pfx Usuario actual\Personal\Certificados
AzureRoot.cer Equipo local\Entidades de certificación raíz de confianza
3. Vaya a C:\Users<UserName>\AppData\Roaming\Microsoft\Network\Connections\Cm<GUID> e instale

manualmente el certificado (archivo *.cer) en el almacén del usuario y el equipo.
Para más información sobre cómo instalar el certificado de cliente, consulte Generación y exportación de
certificados para conexiones de punto a sitio.
NOTE
Al importar el certificado de cliente, no seleccione la opción Habilitar la protección de clave privada de alta
seguridad .
No se pudo establecer la conexión de red entre el equipo y el

servidor VPN porque el servidor remoto no responde
Síntoma
Cuando lo intente y se conecte a una puerta de enlace de red virtual de Azure con IKEv2 en Windows, obtendrá
el mensaje de error siguiente:
No se pudo establecer la conexión de red entre el equipo y el ser vidor VPN porque el ser vidor
remoto no responde
Causa
El problema se produce si la versión de Windows no dispone de soporte técnico para la fragmentación de IKE.
Solución
operativos anteriores a Windows 10 y solo pueden usar SSTP.

Windows 10 Versión
1607
Windows 10 Versión 17 de enero de 2018 KB4057144

1703
Windows 10 Versión 22 de marzo de 2018 KB4089848

1709

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload del Registro
en 1.
Error de cliente de VPN: Mensaje recibido inesperado o con formato

incorrecto.
Síntoma
siguiente:
Mensaje recibido inesperado o con formato incorrecto. (Error 0x80090326)
Causa
Este problema se produce si se cumple una de las condiciones siguientes:
Las rutas definidas por el usuario (UDR) usadas con la ruta predeterminada en la subred de puerta de enlace
no están establecidas correctamente.
La clave pública del certificado raíz no se ha cargado en la puerta de enlace de VPN de Azure.
La clave está dañada o caducada.
Solución
Para solucionar este problema, siga estos pasos:
1. Quite UDR en la subred de puerta de enlace. Asegúrese de que UDR reenvía todo el tráfico correctamente.
2. Compruebe el estado del certificado raíz en Azure Portal para ver si se revocó. Si no se ha revocado, pruebe a
eliminar el certificado raíz y a volver a cargarlo. Para más información, vea Crear certificados.
Error de cliente de VPN: una cadena de certificados se ha procesado

pero ha finalizado
Síntoma
siguiente:
Se ha procesado una cadena de cer tificados, pero termina en un cer tificado raíz en el que el
proveedor de confianza no confía
Solución
1. Asegúrese de que los certificados siguientes están en la ubicación correcta:
C ERT IF IC A DO LO C AT IO N
AzureClient.pfx Usuario actual\Personal\Certificados
Azuregateway-GUID.cloudapp.net Usuario actual\Entidades de certificación raíz de

confianza
AzureGateway-GUID.cloudapp.net, AzureRoot.cer Equipo local\Entidades de certificación raíz de confianza
2. Si los certificados ya están en la ubicación, pruebe a eliminarlos y a volver a instalarlos. El certificado

azuregateway- GUID .cloudapp.net se encuentra en el paquete de configuración del cliente de VPN
descargado de Azure Portal. Puede usar archivadores de archivos para extraer los archivos del paquete.
Error en la descarga del archivo: no se ha especificado ningún URI de

destino.
Síntoma
Aparece el siguiente mensaje de error:
Error en la descarga del archivo. No se ha especificado el URI de destino.
Causa
Este problema se produce debido a un tipo de puerta de enlace incorrecto.
Solución
El tipo de puerta de enlace de la VPN debe ser VPN y el tipo de VPN RouteBased .
Error de cliente de VPN: error de script personalizado de VPN de

Azure
Síntoma
siguiente:
Error de script personalizado (para actualizar la tabla de enrutamiento). (Error 8007026f )
Causa
Este problema puede producirse si está intentando abrir la conexión VPN de sitio a punto mediante un acceso
directo.
Solución
Abra el paquete VPN directamente en lugar de hacerlo desde el acceso directo.
No se puede instalar el cliente de VPN

Causa
Es necesario que un certificado adicional confíe en la puerta de enlace de la VPN de la red virtual. El certificado
está incluido en el paquete de configuración del cliente de VPN que se genera desde Azure Portal.
Solución
Extraiga el paquete de configuración del cliente de VPN y busque el archivo .cer. Para instalar el certificado, siga
estos pasos:
1. Abra mmc.exe.
2. Agregue el complemento Cer tificados .
3. Seleccione la cuenta Equipo del equipo local.
4. Haga clic con el botón derecho en el nodo Entidades de cer tificación raíz de confianza . Haga clic en
All-Task > Impor t (Importar) y vaya al archivo .cer que extrajo del paquete de configuración del cliente de
VPN.
6. Intente instalar el cliente de VPN.
Error de Azure Portal: error al guardar la puerta de enlace de la VPN y

los datos no son válidos
Síntoma
Al intentar guardar los cambios de la puerta de enlace de la VPN en Azure Portal, aparece el mensaje de error
siguiente:
Error al guardar la puer ta de enlace de red vir tual< nombre de la puer ta de enlace >. Los datos del
cer tificado < identificador de cer tificado > no son válidos.
Causa
Este problema puede producirse si la clave pública del certificado raíz que se ha cargado contiene un carácter no
válido, por ejemplo, un espacio.
Solución
Asegúrese de que los datos del certificado no contienen caracteres no válidos como saltos de línea (retornos de
carro). El valor completo debe estar en una línea larga. El siguiente texto es un ejemplo del certificado:
-----BEGIN CERTIFICATE-----
MIIC5zCCAc+gAwIBAgIQFSwsLuUrCIdHwI3hzJbdBjANBgkqhkiG9w0BAQsFADAW
MRQwEgYDVQQDDAtQMlNSb290Q2VydDAeFw0xNzA2MTUwMjU4NDZaFw0xODA2MTUw
MzE4NDZaMBYxFDASBgNVBAMMC1AyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAz8QUCWCxxxTrxF5yc5uUpL/bzwC5zZ804ltB1NpPa/PI
sa5uwLw/YFb8XG/JCWxUJpUzS/kHUKFluqkY80U+fAmRmTEMq5wcaMhp3wRfeq+1
G9OPBNTyqpnHe+i54QAnj1DjsHXXNL4AL1N8/TSzYTm7dkiq+EAIyRRMrZlYwije
407ChxIp0stB84MtMShhyoSm2hgl+3zfwuaGXoJQwWiXh715kMHVTSj9zFechYd7
5OLltoRRDyyxsf0qweTFKIgFj13Hn/bq/UJG3AcyQNvlCv1HwQnXO+hckVBB29wE
sF8QSYk2MMGimPDYYt4ZM5tmYLxxxvGmrGhc+HWXzMeQIDAQABozEwLzAOBgNVHQ8B
Af8EBAMCAgQwHQYDVR0OBBYEFBE9zZWhQftVLBQNATC/LHLvMb0OMA0GCSqGSIb3
DQEBCwUAA4IBAQB7k0ySFUQu72sfj3BdNxrXSyOT4L2rADLhxxxiK0U6gHUF6eWz
/0h6y4mNkg3NgLT3j/WclqzHXZruhWAXSF+VbAGkwcKA99xGWOcUJ+vKVYL/kDja
gaZrxHlhTYVVmwn4F7DWhteFqhzZ89/W9Mv6p180AimF96qDU8Ez8t860HQaFkU6
2Nw9ZMsGkvLePZZi78yVBDCWMogBMhrRVXG/xQkBajgvL5syLwFBo2kWGdC+wyWY
U/Z+EK9UuHnn3Hkq/vXEzRVsYuaxchta0X2UNRzRq+o706l+iyLTpe6fnvW6ilOi
e8Jcej7mzunzyjz4chN0/WVF94MtxbUkLkqP
-----END CERTIFICATE-----
Error de Azure Portal: error al guardar la puerta de enlace de VPN y el

nombre del recurso no es válido
Síntoma
Al intentar guardar los cambios de la puerta de enlace de la VPN en Azure Portal, aparece el mensaje de error
siguiente:
Error al guardar la puer ta de enlace de red vir tual< nombre de la puer ta de enlace >. El nombre
del recurso < nombre del cer tificado que intenta cargar > no es válido.
Causa
Este problema se produce porque el nombre del certificado contiene un carácter no válido, como un espacio.
Error de Azure Portal: error de descarga de archivo de paquete de

VPN 503
Síntoma
Al intentar descargar el paquete de configuración del cliente de VPN, aparece el mensaje de error siguiente:
No se pudo descargar el archivo. Detalles del error : error 503. El ser vidor está ocupado.
Solución
Este error puede deberse a un problema de red temporal. Vuelva a intentar descargar el paquete VPN pasados
unos minutos.
Actualización de Azure VPN Gateway: todos los clientes de punto a

sitio no se pueden conectar
Causa
Si el certificado cubre más del 50 por ciento durante su vigencia, se deshace.
Solución
Para resolver este problema, vuelva a descargar e implementar el paquete de punto a sitio en todos los clientes.
Demasiados clientes de VPN conectados a la vez

Se alcanza el número máximo de conexiones permitidas. Puede ver el número total de clientes conectados en
Azure Portal.
El cliente de VPN no puede acceder a recursos compartidos de

archivos de red
Síntoma
El cliente de VPN se ha conectado a la red virtual de Azure, pero no puede acceder a recursos compartidos de
red.
Causa
El protocolo SMB se usa para el acceso a recursos compartidos de archivos. Cuando se inicia la conexión, el
cliente de VPN agrega las credenciales de sesión y se produce el error. Una vez establecida la conexión, el cliente
se ve obligado a usar las credenciales almacenadas en caché para la autenticación Kerberos. Este proceso inicia
consultas al Centro de distribución de claves (un controlador de dominio) para obtener un token. Como el
cliente se conecta desde Internet, es posible que no pueda alcanzar el controlador de dominio. Por lo tanto, el
cliente no pueden conmutar por error desde Kerberos a NTLM.
El único momento en que el cliente debe escribir una credencial es cuando tiene un certificado válido (con
SAN=UPN) emitido por el dominio al que está unido. El cliente también debe estar conectado físicamente a la
red de dominios. En este caso, el cliente intenta usar el certificado y llega al controlador de dominio. Luego, el
Centro de distribución de claves devuelve un error "KDC_ERR_C_PRINCIPAL_UNKNOWN". El cliente se ve
forzado a conmutar por error a NTLM.
Solución
Para solucionar el problema, deshabilite el almacenamiento en caché de credenciales de dominio desde la
subclave del Registro siguiente:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableDomainCreds - Set the value to 1
No se puede encontrar la conexión VPN de punto a sitio en Windows

después de volver a instalar el cliente de VPN
Síntoma
Se quita la conexión VPN de punto a sitio y luego se vuelve a instalar el cliente de VPN. En esta situación, la
conexión VPN no se configura correctamente. No se ve la conexión VPN en el valor Conexiones de red de
Windows.
Solución
Para resolver el problema, elimine los archivos de configuración antiguos del cliente VPN de
C:\Users\UserName\AppData\Roaming\Microsoft\Network\Connections<Vir tualNetworkId> y
vuelva a ejecutar el instalador del cliente VPN.
El cliente VPN de punto a sitio no puede resolver el FQDN de los

recursos en el dominio local
Síntoma
Cuando el cliente se conecta a Azure con una conexión VPN de punto a sitio, no puede resolver el FQDN de los
recursos del dominio local.
Causa
Un cliente VPN de punto a sitio normalmente usa servidores de Azure DNS configurados en la red virtual de
Azure. Los servidores de Azure DNS tienen prioridad sobre los servidores DNS locales que están configurados
en el cliente (salvo que la métrica de la interfaz de Ethernet sea menor), por lo que todas las consultas DNS se
envían a los servidores DNS de Azure. Si los servidores de Azure DNS no tienen los registros de los recursos
locales, se produce un error en la consulta.
Solución
Para solucionar el problema, asegúrese de que los servidores de Azure DNS usados en la red virtual de Azure
pueden resolver los registros DNS de los recursos locales. Para ello, puede usar los reenviadores DNS o
condicionales. Para más información, vea Resolución de nombres mediante su propio servidor DNS.
Se establece la conexión VPN de punto a sitio, pero aún no se puede

conectar a los recursos de Azure
Causa
Este problema puede producirse si el cliente VPN no obtiene las rutas de la instancia de Azure VPN Gateway.
Solución
Para solucionar este problema, restablezca la instancia de Azure VPN Gateway. Para asegurarse de que se están
usando las nuevas rutas, los clientes VPN de punto a sitio deben descargarse de nuevo después de que el
emparejamiento de red virtual se haya configurado correctamente.
Error: "La función de revocación no pudo comprobar la revocación

debido a que el servidor de revocación estaba sin conexión (Error
0x80092013)"
Causas
Este mensaje de error se produce si el cliente no puede tener acceso a http://crl3.digicert.com/ssca-sha2-g1.crl y
http://crl4.digicert.com/ssca-sha2-g1.crl. La comprobación de revocación requiere acceso a estos dos sitios. Este
problema se produce normalmente en el cliente que tiene el servidor proxy configurado. En algunos entornos, si
las solicitudes no pasan a través del servidor proxy, estas se deniegan en el firewall perimetral.
Solución
Compruebe la configuración del servidor proxy, asegúrese de que el cliente puede tener acceso a
http://crl3.digicert.com/ssca-sha2-g1.crl y http://crl4.digicert.com/ssca-sha2-g1.crl.
Error de cliente de VPN: se impidió la conexión debido a una directiva

configurada en el servidor RAS/VPN. (Error 812)
Causa
Este error se produce si el servidor RADIUS que se usa para autenticar el cliente de VPN tiene una configuración
incorrecta o la puerta de enlace de Azure no se puede comunicar con el servidor Radius.
Solución
Asegúrese de que el servidor RADIUS está configurado correctamente. Para más información, vea Integración
de la autenticación RADIUS con Servidor Azure AD Multi-Factor Authentication.
"Error 405" al descargar el certificado raíz de VPN Gateway

Causa
No se instaló el certificado raíz. El certificado raíz está instalado en el almacén de cer tificados de confianza
del cliente.
Error de cliente de VPN: no se pudo establecer la conexión remota
porque se produjo un error en los túneles VPN probados. (Error 800)
Causa
El controlador NIC está obsoleto.
Solución
Actualice el controlador NIC:
1. Haga clic en Inicio , escriba Administrador de dispositivos y selecciónelo en la lista de resultados. Si se le
pide una contraseña de administrador o una confirmación, escriba la contraseña o proporcione la
confirmación.
2. En las categorías de adaptadores de red , busque la NIC que quiere actualizar.
3. Haga doble clic en el nombre del dispositivo, seleccione Actualizar controlador y, luego, Buscar software
de controlador actualizado automáticamente .
4. Si Windows no encuentra un nuevo controlador, puede intentar buscar uno en el sitio web del fabricante del
dispositivo y seguir sus instrucciones.
5. Reinicie el equipo e intente la conexión de nuevo.
Error de cliente de VPN: Al marcar la conexión VPN , Estado =

Plataforma VPN no desencadenó la conexión.
También puede aparecer el siguiente error en el Visor de eventos, procedente de RasClient: "El usuario marcó
una conexión denominada , que no se realizó correctamente. El código de error devuelto en el error es 1460".
Causa
El Cliente VPN de Azure no tiene habilitado el permiso de aplicación "Aplicaciones en segundo plano" en la
configuración de aplicaciones de Windows.
Solución
1. En Windows, vaya a Configuración -> Privacidad -> Aplicaciones en segundo plano.
2. Active la opción "Permitir que las aplicaciones se ejecuten en segundo plano".
Error: "Error en la descarga del archivo. No se ha especificado el URI

de destino"
Causa
El motivo es un tipo de puerta de enlace incorrecto configurado.
Solución
El tipo de puerta de enlace de VPN de Azure debe ser VPN y el tipo de VPN debe ser RouteBased .
El instalador del paquete VPN no finaliza.

Causa
Este problema puede deberse a instalaciones anteriores del cliente de VPN.
Solución
Elimine los archivos de configuración antiguos del cliente VPN de
C:\Users\UserName\AppData\Roaming\Microsoft\Network\Connections<Vir tualNetworkId> y
ejecute de nuevo el instalador del cliente VPN.
El cliente de VPN hiberna o entra en modo de suspensión al cabo de
un tiempo
Solución
Compruebe la configuración de suspensión e hibernación en el equipo donde se ejecuta el cliente de VPN.
Solución de problemas de conexiones VPN de
punto a sitio desde clientes de VPN de Mac OS X
Este artículo le ayuda a solucionar problemas de conectividad de punto a sitio de Mac OS X con el cliente VPN
nativo e IKEv2. El cliente VPN de Mac para IKEv2 es muy básico y no permite muchas personalizaciones. Hay
solo cuatro opciones de configuración que deben comprobarse:
Dirección del servidor
Id. remoto
Id. local
Configuración de autenticación
Versión del SO (10.11 o posterior)
Solución de problemas de autenticación basada en certificados

1. Compruebe la configuración del cliente de VPN. Vaya a la Configuración de red presionando Comando
+ Mayús y, a continuación, escriba "VPN" para comprobar la configuración del cliente de VPN. En la lista,
haga clic en la entrada VPN que debe investigarse.
2. Compruebe que la dirección del ser vidor es el FQDN completo e incluye cloudapp.net.
3. El id. remoto debe ser el mismo que la dirección del servidor (FQDN de puerta de enlace).
4. El id. local debe ser el mismo que el asunto del certificado de cliente.
5. Haga clic en Configuración de autenticación para abrir la página Configuración de autenticación.
6. Compruebe que la opción Cer tificado está seleccionada en la lista desplegable.
7. Haga clic en el botón Seleccionar y compruebe que se ha seleccionado el certificado correcto. Haga clic
en Aceptar para guardar los cambios.
Solución de problemas de autenticación de nombre de usuario y

contraseña
1. Compruebe la configuración del cliente de VPN. Vaya a la Configuración de red presionando Comando
+ Mayús y, a continuación, escriba "VPN" para comprobar la configuración del cliente de VPN. En la lista,
haga clic en la entrada VPN que debe investigarse.
2. Compruebe que la dirección del ser vidor es el FQDN completo e incluye cloudapp.net.
3. El id. remoto debe ser el mismo que la dirección del servidor (FQDN de puerta de enlace).
4. El id. local puede estar en blanco.
5. Haga clic en el botón Configuración de autenticación y compruebe que se ha seleccionado "Nombre
de usuario" en la lista desplegable.
6. Compruebe que se han introducido las credenciales correctas.
Pasos adicionales
Si ha llevado a cabo los pasos anteriores y todo está configurado correctamente, descargue Wireshark y realice
una captura de paquetes.
1. Filtre por isakmp y examine los paquetes IKE_SA . Podrá consultar los detalles de la propuesta de
asociación de seguridad en Payload: Security Association .
2. Compruebe que el cliente y el servidor disponen de un conjunto común.
3. Si no hay ninguna respuesta del servidor en los seguimientos de red, compruebe que ha habilitado el
protocolo IKEv2 en la página de configuración de la puerta de enlace de Azure en el sitio web de Azure
Portal.
Pasos siguientes
Para obtener más ayuda, consulte el Soporte técnico de Microsoft.
Solución de problemas de un cliente VPN de
autenticación Azure AD
Este artículo le ayuda a solucionar problemas de un cliente VPN para conectarse a una red virtual con una VPN
de punto a sitio y la autenticación Azure Active Directory.
Ver Registro de estado

Vea el registro de estado para ver los mensajes de error.
1. Haga clic en el icono de flechas situado en la esquina inferior derecha de la ventana de cliente para mostrar
los Registros de estado .
2. Compruebe los registros en busca de errores que puedan indicar el problema.
3. Los mensajes de error se muestran en rojo.
Borrar información de inicio de sesión

Borrar información de inicio de sesión.
1. Seleccione... junto al perfil que quiere solucionar. Seleccione Configurar > Borrar cuenta guardada .
2. Seleccione Guardar .
3. Intente conectarse.
4. Si la conexión sigue sin funcionar, continúe con siguiente sección.
Ejecución de diagnósticos
Ejecutar diagnósticos en el cliente VPN.
1. Haga clic en … junto al perfil en el que desea ejecutar diagnósticos. Seleccione Diagnosticar-> Ejecutar
diagnósticos .
2. El cliente ejecutará una serie de pruebas y mostrará el resultado de la prueba
Acceso a Internet: comprueba si el cliente tiene Conectividad a Internet
Credenciales del cliente: comprueba si el punto de conexión de autenticación Azure Active Directory es
accesible
Resolución del servidor: se pone en contacto con el servidor DNS para resolver la dirección IP del
servidor VPN configurado
Disponibilidad del servidor: comprueba si el servidor VPN responde o no
3. Si se produce un error en alguna de las pruebas, póngase en contacto con el administrador de red para
resolver el problema.
4. En la sección siguiente se muestra cómo recopilar los registros, si es necesario.
Recopilar archivos de registro del cliente

Recopilar archivos de registro del cliente VPN. Los archivos de registro se pueden enviar al soporte técnico o al
administrador a través de un método de su elección. Por ejemplo, correo electrónico.
1. Haga clic en "..." junto al perfil en el que desea ejecutar diagnósticos. Seleccione Diagnosticar >
Mostrar directorio de registros .
2. El explorador de Windows se abre en la carpeta que contiene los archivos de registro.
Pasos siguientes
Para más información, consulte crear un inquilino de Azure Active Directory para conexiones VPN abiertas de
P2S que usan Autenticación de Azure AD.
Solución de problemas: una conexión VPN de sitio
a sitio de Azure no puede conectarse y deja de
funcionar
Después de configurar una conexión VPN de sitio a sitio entre una red local y una red virtual de Azure, la
conexión VPN de repente deja de funcionar y no se puede volver a conectar. Este artículo proporciona pasos de
solución de problemas para ayudarle a resolver este problema.
Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow.
Puede publicar su problema en ellos o @AzureSupport en Twitter. También puede enviar una solicitud de
soporte técnico de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure,
seleccione Obtener sopor te técnico .
Pasos para solucionar problemas

Para resolver el problema, primero intente restablecer la puerta de enlace de la VPN de Azure y restablecer el
túnel desde el dispositivo VPN local. Si el problema continua, siga estos pasos para identificar la causa del
problema.
Paso de requisito previo
Comprobación del tipo de la puerta de enlace de VPN de Azure.
1. Vaya a Azure Portal.
2. Compruebe la página Información general de la puerta de enlace de la VPN para obtener la
información del tipo.
Paso 1. Compruebe si el dispositivo VPN local está validado

1. Compruebe si está usando una versión del sistema operativo y dispositivo VPN validada. Si el dispositivo
no es un dispositivo VPN validado, tendrá que ponerse en contacto con el fabricante del dispositivo para
ver si hay algún problema de compatibilidad.
2. Asegúrese de que el dispositivo VPN esté configurado correctamente. Para más información, consulte
Ejemplos de edición de configuración de dispositivos.
Paso 2. Compruebe la clave compartida
Compare la clave compartida del dispositivo VPN local y la de la VPN de la instancia de Azure Virtual Network
para asegurarse de que las claves coinciden.
Para ver la clave compartida de la conexión VPN de Azure, use uno de los siguientes métodos:
Azure Por tal
1. Vaya a la conexión de sitio a sitio de la puerta de enlace VPN que ha creado.
2. En la sección Configuración , haga clic en Clave compar tida .
Azure PowerShell
NOTE
Para el modelo de implementación de Azure Resource Manager:
Get-AzVirtualNetworkGatewayConnectionSharedKey -Name <Connection name> -ResourceGroupName <Resource group

name>
Para el modelo de implementación clásico:
Get-AzureVNetGatewayKey -VNetName -LocalNetworkSiteName
Paso 3. Compruebe las direcciones IP del par de la VPN

La definición de IP en el objeto Puer ta de enlace de red local en Azure debe coincidir con el IP de
dispositivo local.
La definición de la dirección IP de la puerta de enlace de Azure establecida en el dispositivo local debe
coincidir con la dirección IP de la puerta de enlace de Azure.
Paso 4. Compruebe las UDR y los NSG de la subred de la puerta de enlace
Busque y quite Enrutamiento definido por el usuario (UDR) o Grupos de seguridad de red (NSG) en la subred de
puerta de enlace y, a continuación, pruebe el resultado. Si se resuelve el problema, valide la configuración de
NSG o UDR aplicada.
Paso 5. Compruebe la dirección de la interfaz externa del dispositivo VPN local
Si la dirección IP accesible desde Internet del dispositivo VPN está incluida en la definición de Red local en
Azure, es posible que experimente desconexiones esporádicas.
La interfaz externa del dispositivo debe estar directamente en Internet. No debería haber ninguna traducción
de direcciones de red o firewall entre Internet y el dispositivo.
Para configurar la agrupación en clústeres de firewall para que tenga una IP virtual, debe interrumpir el
clúster y exponer el dispositivo VPN directamente a una interfaz pública con la que la puerta de enlace pueda
interactuar.
Paso 6. Compruebe que las subredes coinciden exactamente (puertas de enlace basadas en directivas de
Azure )
Compruebe que los espacios de direcciones de red virtual coinciden exactamente entre la red virtual de
Azure y las definiciones locales.
Compruebe que las subredes coinciden exactamente entre la puer ta de enlace de la red local y las
definiciones locales para la red local.
Paso 7. Compruebe el sondeo de estado de la puerta de enlace de Azure
1. Abra el sondeo de estado en la dirección URL siguiente:
https://<YourVirtualNetworkGatewayIP>:8081/healthprobe
2. Haga clic en la advertencia de certificado.

3. Si recibe una respuesta, se considera que la puerta de enlace de la VPN es correcta. Si no recibe una
respuesta, puede que la puerta de enlace no sea correcta o que haya un NSG en la subred de puerta de
enlace que provoque el problema. El siguiente texto es una respuesta de ejemplo:
<?xml version="1.0"?>
<string xmlns="http://schemas.microsoft.com/2003/10/Serialization/">Primary Instance:
GatewayTenantWorker_IN_1 GatewayTenantVersion: 14.7.24.6</string>
Paso 8. Compruebe si el dispositivo VPN local cuenta con la característica confidencialidad directa perfecta
habilitada
La característica confidencialidad directa perfecta puede provocar problemas de desconexión. Si el dispositivo
VPN cuenta con la característica confidencialidad directa perfecta habilitada, deshabilítela. A continuación,
actualice la directiva IPsec de puerta de enlace de VPN.
Pasos siguientes
Configuración de una conexión de sitio a sitio en una red virtual
Configuración de una directiva IPsec/IKE para conexiones VPN de sitio a sitio
Solución de problemas: la VPN de sitio a sitio de
Azure se desconecta intermitentemente
Puede experimentar un problema en el que una conexión VPN de sitio a sitio de Microsoft Azure no sea estable
y se desconecte regularmente. Este artículo proporciona pasos de solución de problemas para ayudarlo a
identificar y resolver la causa del problema.
Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow.
Puede publicar su problema en ellos o @AzureSupport en Twitter. También puede enviar una solicitud de
soporte técnico de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure,
seleccione Obtener sopor te técnico .
Pasos para solucionar problemas

Paso de requisito previo
Comprobación del tipo de puerta de enlace de red virtual de Azure:
1. Vaya al Portal de Azure.
2. Compruebe la página Introducción de la puerta de enlace de red virtual para el tipo de información.
Paso 1: Comprobación de si el dispositivo VPN local está validado

1. Compruebe si está usando una versión del sistema operativo y dispositivo VPN validada. Si el dispositivo
VPN no está validado, tendrá que ponerse en contacto con el fabricante del dispositivo para ver si hay algún
problema de compatibilidad.
2. Asegúrese de que el dispositivo VPN esté configurado correctamente. Para obtener más información, vea
Edición de ejemplos de configuración de dispositivos.
Paso 2: Comprobación de la configuración de la asociación de seguridad (para puertas de enlace de red
virtual de Azure basadas en directivas)
1. Asegúrese de que la red virtual, las subredes y los intervalos en la definición de Puer ta de enlace de red
local en Microsoft Azure sean los mismos que la configuración en el dispositivo VPN local.
2. Compruebe que la configuración de la asociación de seguridad coincida.
Paso 3: Comprobación de los grupos de seguridad de red o las rutas definidas por el usuario en la subred de
puerta de enlace
Una ruta definida por el usuario en la subred de puerta de enlace puede restringir un tipo de tráfico y permitir
otro. Esto hace que parezca que la conexión VPN no es de confianza para un tipo de tráfico y que es buena para
otro.
Paso 4: Comprobación de la configuración "un túnel de VPN por par de subred" (para puertas de enlace de
red virtual basadas en directivas)
Asegúrese de que el dispositivo VPN local se haya establecido para tener un túnel VPN por par de subred
para las puertas de enlace de red virtual basadas en directivas.
Paso 5: Comprobación de la limitación de la asociación de seguridad (para puertas de enlace de red virtual
basadas en directivas)
La puerta de enlace de red virtual basada en directivas tiene un límite de 200 pares de la asociación de
seguridad de subred. Si el número de subredes de red virtual de Azure multiplicado por el número de subredes
locales es superior a 200, observará una desconexión esporádica de las subredes.
Paso 6: Comprobación de la dirección de la interfaz externa del dispositivo VPN local
Si la dirección IP accesible desde Internet del dispositivo VPN está incluida en la definición de Puer ta de
enlace de red local en Azure, es posible que experimente desconexiones esporádicas.
Paso 7: Comprobación de si el dispositivo VPN local cuenta con la característica Confidencialidad directa
perfecta habilitada
La característica Confidencialidad directa perfecta puede provocar problemas de desconexión. Si el
dispositivo VPN cuenta con la característica Confidencialidad directa perfecta habilitada , deshabilítela. A
continuación, actualice la directiva IPsec de puerta de enlace de red virtual.
Pasos siguientes
Configuración de una conexión de sitio a sitio en una red virtual
Configuración de la directiva IPsec/IKE para conexiones VPN de sitio a sitio
Creación de una conexión de sitio a sitio mediante
Este artículo muestra cómo usar Azure Portal para crear una conexión de puerta de enlace VPN de sitio a sitio
desde la red local a la red virtual. Los pasos de este artículo se aplican al modelo de implementación clásica, no
al modelo de implementación actual, Resource Manager. También se puede crear esta configuración con una
herramienta o modelo de implementación distintos, mediante la selección de una opción diferente en la lista
siguiente:
Antes de empezar
Compruebe que desea trabajar en el modelo de implementación clásica. Si desea trabajar en el modelo de
implementación de Resource Manager, consulte Creación de una conexión de sitio a sitio (Resource
Manager). Se recomienda usar el modelo de implementación de Resource Manager, ya que el modelo clásico
es heredado.
Se requiere PowerShell para especificar la clave compartida y crear la conexión de puerta de enlace VPN.
Valores de configuración de ejemplo para este ejercicio
prueba o hacer referencia a ellos para comprender mejor los ejemplos de este artículo. Normalmente, cuando
se trabaja con valores de dirección IP para el espacio de direcciones, se debe coordinar con el administrador de
red para evitar espacios de direcciones superpuestos, lo que puede afectar al enrutamiento. En este caso,
reemplace los valores de dirección IP por los suyos propios si quiere crear una conexión operativa.
Nombre de la red vir tual: TestVNet1
Nombre del sitio local: Site2
Espacio de direcciones de cliente: el espacio de direcciones que se encuentra en el sitio local.

Cuando se crea una red virtual que se usará para una conexión S2S, debe asegurarse de que los espacios de
direcciones que especifique no se superponen con ninguno de los espacios de direcciones de cliente de los sitios
locales a los que desea conectarse. Si tiene subredes superpuestas, la conexión no funcionará correctamente.
Si ya dispone de una red virtual, compruebe que la configuración sea compatible con el diseño de la
puerta de enlace de VPN. Preste especial atención a las subredes que se pueden superponer con otras
redes.
Si no tiene una red virtual, créela. Las capturas de pantalla se proporcionan a modo de ejemplo.
Asegúrese de reemplazar los valores por los suyos.
2. Seleccione +Crear un recurso . En el campo Buscar en el Marketplace , escriba "Virtual Network". En la
lista de resultados, busque Vir tual Network y seleccione esa opción para abrir la página Vir tual Network .
3. En la página Virtual Network, debajo del botón Crear, verá "Deploy with Resource Manager (change to
Classic)" [Implementar con Resource Manager (cambiar a la versión clásica)]. Resource Manager es el valor
predeterminado para crear una red virtual. No obstante, no quiere crear una red virtual de Resource
Manager. Seleccione (change to Classic) (cambiar a la versión clásica) para crear una red virtual clásica. A
continuación, elija la pestaña Información general y seleccione Crear .
4. En la página Create vir tual network(classic) [Crear red virtual (clásica)], en la pestaña Aspectos básicos ,
configure las opciones de la red virtual con los valores de ejemplo.
5. Seleccione Revisar y crear para validar la red virtual.
6. Se ejecuta la validación. Una vez validada la red virtual, seleccione Crear .
La configuración de DNS no es un paso necesario de esta configuración, pero el servidor DNS es necesario si
quiere resolver los nombres de las VM. La especificación de un valor no crea un servidor DNS nuevo. La
dirección IP del servidor DNS que especifique debe ser un servidor DNS que pueda resolver los nombres de los
recursos a los que se conecta.
Después de crear la red virtual, puede agregar la dirección IP de un servidor DNS para controlar la resolución de
nombres. Abra la configuración de su red virtual, seleccione los servidores DNS y agregue la dirección IP del
servidor DNS que quiere utilizar para la resolución de nombres.
1. Busque la red virtual en el portal.
2. En la página de la red virtual, en la sección Configuración , haga clic en Ser vidores DNS .
3. Agregue un servidor DNS.
4. Para guardar la configuración, haga clic en Guardar en la parte superior de la página.
Configuración del sitio y la puerta de enlace
Configuración del sitio
Normalmente, sitio local suele hacer referencia a la ubicación local. Contiene la dirección IP del dispositivo VPN
al que se creará una conexión y los intervalos de direcciones IP que se enrutarán a través de la puerta de enlace
VPN en el dispositivo VPN.
1. En la página de la red virtual, en Configuración , seleccione Conexiones de sitio a sitio .
2. En la página Conexiones de sitio a sitio, seleccione + Agregar .
3. En la página Configurar una conexión VPN y una puer ta de enlace , para Tipo de conexión , deje
seleccionado De sitio a sitio . Para este ejercicio, debe usar una combinación de los valores de ejemplo y
sus propios valores.
Dirección IP de la puer ta de enlace de VPN: es la dirección IP pública del dispositivo VPN en
la red local. El dispositivo VPN requiere una dirección IP IPv4 pública. Especifique una dirección IP
pública válida para el dispositivo VPN al que desea conectarse. Debe ser accesible para Azure. Si
no conoce la dirección IP del dispositivo VPN, siempre puede poner un valor de marcador de
posición (siempre que tenga el formato de una dirección IP pública válida) y cambiarlo más
adelante.
Espacio de direcciones de cliente: lista de los intervalos de direcciones IP que quiere enrutar a
la red local mediante esta puerta de enlace. Puede agregar varios intervalos de espacios de
direcciones. Asegúrese de que los intervalos que especifique aquí no se superponen con los
intervalos de otras redes a la que se conecta su red virtual, ni con los intervalos de direcciones de
la propia red virtual.
4. En la parte inferior de la página, NO seleccione Revisar y crear. En su lugar, seleccione Siguiente: Puer ta
de enlace> .
Configuración de la puerta de enlace de red virtual
1. En la página Puer ta de enlace , seleccione los siguientes valores:
Size: Es la SKU de la puerta de enlace que va a usa para crear la puerta de enlace de red virtual.
Las puertas de enlace de VPN clásicas utilizan las SKU antiguas (heredadas). Para más información
acerca de las SKU antiguas de puerta de enlace, consulte Funcionamiento de SKU de puerta de
enlace de red virtual (SKU antigua). Puede seleccionar Estándar para este ejercicio.
Tipo de enrutamiento: Seleccione el tipo de enrutamiento de la puerta de enlace. Esto también
se conoce como tipo de VPN. Es importante seleccionar el tipo correcto porque la puerta de enlace
no se puede convertir de un tipo a otro. El dispositivo VPN debe ser compatible con el tipo de
enrutamiento que seleccione. Para más información acerca del tipo de enrutamiento, consulte
Acerca de la configuración de VPN Gateway. Verá que muchos artículos hacen referencia a los
tipos de VPN 'RouteBased' y 'PolicyBased'. 'Dynamic' corresponde a 'RouteBased' y 'Static'
corresponde a 'PolicyBased'. Normalmente, se quiere el enrutamiento dinámico.
Subred de puer ta de enlace: El tamaño de la subred de la puerta de enlace que especifique
depende de la configuración de la puerta de enlace VPN que desea crear. Aunque es posible crear
una puerta de enlace tan pequeña como /29, le recomendamos que use /27 o /28. Esto crea una
subred mayor que incluye más direcciones. El uso de una subred de la puerta de enlace mayor
permite suficientes direcciones IP para dar cabida a posibles configuraciones futuras.
2. En la parte inferior de la página, seleccione Revisar y crear para validar la configuración. Seleccione
Crear para realizar la implementación. Según la SKU de puerta de enlace que seleccione, puede tardar
hasta 45 minutos en crear una puerta de enlace de red virtual.
Portal, PowerShell o la CLI.
S2S.
Recuperación de valores
Cuando crea redes virtuales clásicas en Azure Portal, el nombre que ve no es el nombre completo que usa para
PowerShell. Por ejemplo, una red virtual que pareciera tener el nombre TestVNet1 en el portal podría tener un
nombre mucho más largo en el archivo de configuración de red. En el caso de una red virtual del grupo de
recursos "ClassicRG" el nombre sería algo así: Group ClassicRG TestVNet1 . Cuando cree conexiones, es
importante usar los valores que ve en el archivo de configuración de red.
En los pasos siguientes, se conectará a la cuenta de Azure y descargará y verá el archivo de configuración de red
para obtener los valores requeridos para las conexiones.
1. Descargue e instale la versión más reciente de los cmdlets de PowerShell para Azure Service
Management (SM). La mayoría de los usuarios tienen los módulos de Resource Manager instalados
localmente, pero no tienen módulos para la administración de servicios. Los módulos de administración
de servicios son heredados y deben instalarse por separado. Para obtener más información, consulte la
Instalación de los cmdlets de administración de servicios.
2. Abra la consola de PowerShell con privilegios elevados y conéctela a su cuenta. Use los siguientes
ejemplos para conectarse. Estos comandos se deben ejecutar localmente mediante el módulo de
administración de servicios de PowerShell. Conéctese a su cuenta. Use el siguiente ejemplo para
conectarse:
Add-AzureAccount
3. Compruebe las suscripciones para la cuenta.
4. Si tiene varias suscripciones, seleccione la que quiera usar.
Select-AzureSubscription -SubscriptionId "Replace_with_your_subscription_ID"
5. Cree un directorio en el equipo. Por ejemplo, C:\AzureVNet

6. Exporte el archivo de configuración de red al directorio. En este ejemplo, se exporta el archivo de
configuración de red a C:\AzureNet .
7. Abra el archivo con un editor de texto y consulte los nombres de las redes virtuales y los sitios. Estos
serán los nombres que usará cuando cree las conexiones.
Los nombres de las redes vir tuales aparecen como Vir tualNetworkSite name =
Los nombres de los sitios aparecen como LocalNetworkSiteRef name =
NOTE
En el modelo de implementación clásica, este paso no está disponible en Azure Portal o a través de Azure Cloud Shell.
Debe usar la versión para Service Management (SM) de los cdmlets de Azure PowerShell localmente desde el escritorio.
En este paso, con los valores de los pasos anteriores, establezca la clave compartida y cree la conexión. La clave
que se establezca debe ser la misma que se usó en la configuración del dispositivo VPN.
1. Establezca la clave compartida y cree la conexión.
Cambie los valores de -VNetName y -LocalNetworkSiteName. Al especificar el nombre que contiene
espacios, escriba el valor entre comillas simples.
"SharedKe" es un valor que se puede generar y especificar. En el ejemplo, hemos usado "abc123" pero
puede usar algo más complejo. Lo importante es que el valor que especifique aquí debe ser el mismo
que el que se especificó al configurar el dispositivo VPN.
Set-AzureVNetGatewayKey -VNetName 'Group TestRG1 TestVNet1' `

-LocalNetworkSiteName '6C74F6E6_Site2' -SharedKey abc123
2. Cuando se crea la conexión, el resultado es: Estado: Correcto .
sitio a sitio .
Si tiene problemas para conectarse, consulte la sección de solución de problemas de la tabla de contenido en
el panel izquierdo.
Procedimientos para restablecer una puerta de enlace de VPN

pero no pueden establecer túneles IPsec con las Puertas de enlace de VPN de Azure. Para conocer los pasos,
consulte Restablecimiento de una puerta de enlace de VPN.
Procedimientos para cambiar la SKU de una puerta de enlace

Para que conocer los pasos para cambiar la SKU de puerta de enlace, consulte la sección Cambio de tamaño de
las SKU de una puerta de enlace.
Pasos siguientes
forzada.
Configuración de una conexión de punto a sitio
mediante la autenticación de certificado (clásica)
NOTE
Este artículo se ha escrito para el modelo de implementación clásico. Si es la primera vez que usa Azure, se recomienda
usar el modelo de implementación de Resource Manager. El modelo de implementación de Resource Manager es el
modelo más reciente y ofrece más opciones y compatibilidad de características que el modelo de implementación clásica.
Para conocer más sobre los modelos de implementación, consulte la información sobre los modelos de implementación.
Para conocer la versión de Resource Manager de este artículo, selecciónela en la lista desplegable o en la tabla de
contenido de la izquierda.
En este artículo se explica cómo crear una red virtual con una conexión de punto a sitio. Cree esta red virtual
con el modelo de implementación clásica en Azure Portal. Esta configuración utiliza certificados para autenticar
al cliente que se conecta, ya sean autofirmados o emitidos por una entidad de certificación. También puede crear
esta configuración con un modelo o una herramienta de implementación diferente mediante las opciones que
se describen en estos artículos:
Use una puerta de enlace de VPN de punto a sitio (P2S) para crear una conexión segura a la red virtual desde un
equipo cliente individual. Las conexiones VPN de punto a sitio son útiles cuando desea conectarse a la red
virtual desde una ubicación remota. Cuando hay solo unos pocos clientes que necesitan conectarse a una red
virtual, una VPN P2S es una solución útil en lugar de una VPN de sitio a sitio. Se establece una conexión VPN
P2S al iniciar la conexión desde el equipo cliente.
IMPORTANT
El modelo de implementación clásica admite solo clientes de VPN de Windows y usa el Protocolo de túnel de sockets
seguros (SSTP), un protocolo de VPN basado en SSL. Para admitir clientes de VPN que no sean de Windows, debe crear la
red privada virtual con el modelo de implementación de Resource Manager. El modelo de implementación de Resource
Manager admite IKEv2 VPN, además de SSTP. Para más información, consulte Acerca de las conexiones P25.
Configuración y requisitos
Requisitos
Las conexiones de autenticación de certificado de punto a sitio requieren los siguientes elementos. En este
artículo se describen los pasos que le ayudarán a crearlos.
Una puerta de enlace VPN dinámica.
La clave pública (archivo .cer) de un certificado raíz, que se carga en Azure. Esta clave se considera un
certificado de confianza y se usa para la autenticación.
Se genera un certificado de cliente a partir del certificado raíz y se instala en cada equipo cliente que se vaya
a conectar. Este certificado se usa para la autenticación de cliente.
Se debe generar un paquete de configuración de cliente de VPN e instalarlo en todos los equipos cliente que
se conectan. El paquete de configuración de cliente configura el cliente de VPN nativo que ya está en el
sistema operativo con la información necesaria para conectarse a la red virtual.
Las conexiones de punto a sitio no requieren un dispositivo VPN ni una dirección IP de acceso público local. Se
crea la conexión VPN sobre SSTP (Protocolo de túnel de sockets seguros). En el lado servidor, se admiten las
versiones 1.0, 1.1 y 1.2 de SSTP. El cliente decide qué versión va a usar. Para Windows 8.1 y versiones
posteriores, SSTP usa 1.2 de forma predeterminada.
Para más información, consulte Acerca de las conexiones de punto a sitio y las Preguntas más frecuentes.
Use los siguientes valores para crear un entorno de prueba o hacer referencia a ellos para comprender mejor
los ejemplos de este artículo:
Grupos de recursos: TestRG
la red virtual.
Espacio de direcciones de cliente: 172.16.201.0/24
dirección IP del grupo especificado.
Tipo de conexión : seleccione Punto a sitio .
Inter valo de direcciones de GatewaySubnet (bloque CIDR): 192.168.200.0/24
Antes de empezar, compruebe que tiene una suscripción a Azure. Si todavía no la tiene, puede activar sus
ventajas como suscriptor de MSDN o registrarse para obtener una cuenta gratuita.

Si ya dispone de una red virtual, compruebe que la configuración sea compatible con el diseño de la puerta de
enlace de VPN. Preste especial atención a las subredes que se pueden superponer con otras redes.

1. Navegue hasta la red virtual que ha creado.
2. En la página VNet, en Configuración, seleccione Puer ta de enlace . En la página Puer ta de enlace ,
puede ver la puerta de enlace de la red virtual. Esta red virtual todavía no tiene una puerta de enlace.
Haga clic en la nota que indica Haga clic aquí para agregar una conexión y una puer ta de enlace .
3. En la página Configurar una conexión VPN y una puer ta de enlace , seleccione la configuración
siguiente:
Tipo de conexión: de punto a sitio
Espacio de direcciones de cliente: agregue el intervalo de direcciones IP del que los clientes de VPN
reciben una dirección IP al conectarse. Use un intervalo de direcciones IP privadas que no se
superponga a la ubicación local desde la que se va a conectar ni a la red virtual a la que va a
conectarse.
4. Deje la casilla No configurar una puer ta de enlace en este momento sin seleccionar. Crearemos
una puerta de enlace.
5. En la parte inferior de la página, seleccione Next: Puer ta de enlace > .
6. En la pestaña Puer ta de enlace , seleccione los siguientes valores:
Size: El tamaño es la SKU de la puerta de enlace para la puerta de enlace de red virtual. En Azure
Portal, la SKU predeterminada es Predeterminada . Para más información acerca de las SKU de
puerta de enlace, vea Acerca de la configuración de VPN Gateway.
Tipo de enrutamiento: Debe seleccionar Dinámico para una configuración de punto a sitio. El
enrutamiento estático no funcionará.
Subred de puer ta de enlace: Este campo ya se ha autorrellenado. No puede cambiar el nombre. Si
intenta cambiar el nombre mediante PowerShell o cualquier otro medio, la puerta de enlace no
funcionará correctamente.
Inter valo de direcciones (bloque CIDR): Aunque es posible crear una subred de puerta de enlace
tan pequeña como /29, se recomienda que cree una subred mayor que incluya más direcciones
seleccionando al menos /28 o /27. Esto permitirá suficientes direcciones para dar cabida a posibles
configuraciones adicionales que desee en el futuro. Cuando trabaje con subredes de la puerta de
enlace, evite asociar un grupo de seguridad de red (NSG) a la subred de la puerta de enlace. La
asociación de un grupo de seguridad de red a esta subred puede causar que la puerta de enlace de
VPN no funcione según lo esperado.
7. Seleccione Revisar y crear para validar la configuración.
8. Una vez pasada la validación, seleccione Crear . Una puerta de enlace de VPN puede tardar hasta 45
minutos en completarse, según la SKU de puerta de enlace que seleccione.
Creación de certificados
Azure usa certificados para autenticar a los clientes VPN en VPN de punto a sitio. Cargue la información de clave
pública del certificado raíz en Azure. La clave pública se considerará de confianza. Deben generarse certificados
de cliente a partir del certificado raíz de confianza e instalarse en cada equipo cliente en el almacén de
certificados Certificados-Usuario actual/Personal/Certificados. El certificado se utiliza para autenticar al cliente
cuando se conecta a la red virtual.
Si usa certificados autofirmados, se deben crear con parámetros específicos. Puede crear un certificado
autofirmado con las instrucciones para PowerShell y Windows 10, o bien MakeCert. Es importante que siga los
pasos descritos en estas instrucciones cuando use certificados raíz autofirmados y genere certificados de cliente
a partir del certificado raíz autofirmado. En caso contrario, los certificados que cree no serán compatibles con
las conexiones P2S y recibirá un error de conexión.
Obtención de la clave pública (.cer) para el certificado raíz
Obtenga el archivo .cer del certificado raíz. Puede usar un certificado raíz generado mediante una solución
empresarial (opción recomendada) o generar un certificado autofirmado. Después de crear el certificado raíz,
exporte los datos (no la clave privada) del certificado público como un archivo .cer con codificación Base64
X.509. Este archivo se carga más adelante en Azure.
Cer tificado de empresa: Si usa una solución empresarial, puede utilizar la cadena de certificados
existente. Obtenga el archivo .cer para el certificado raíz que desee usar.
Cer tificado raíz autofirmado : Si no usa una solución de certificado de empresa, cree un certificado
raíz autofirmado. En caso contrario, los certificados que cree no serán compatibles con las conexiones de
P2S y los clientes recibirán un error de conexión al intentar conectarse. Puede usar Azure PowerShell,
MakeCert o bien OpenSSL. Los pasos descritos en los artículos siguientes describen cómo generar un
certificado raíz autofirmado compatible:
Instrucciones para Windows 10 y PowerShell: estas instrucciones requieren Windows 10 y PowerShell
para generar certificados. Los certificados de cliente que se generan desde el certificado raíz pueden
Instrucciones para MakeCert: use MakeCert para generar certificados si no tiene acceso a un equipo
con Windows 10. Aunque MakeCert está en desuso, todavía puede usarlo para generar certificados.
Los certificados de cliente que se generan desde el certificado raíz pueden instalarse en cualquier
certificado de cliente. Se genera desde el certificado raíz y se instala en cada equipo cliente. Si no instala ningún
certificado de cliente válido, la autenticación no podrá realizarse cuando el cliente trate de conectarse a la red
virtual.
Puede generar un certificado único para cada cliente o puede usar el mismo para varios clientes. La ventaja de
generar certificados de cliente únicos es la capacidad de revocar un solo certificado. De lo contrario, si varios
clientes usan el mismo certificado de cliente para autenticarse y este se revoca, deberá generar e instalar nuevos
certificados para cada cliente que use dicho certificado.
Si usa una solución de certificación de empresa, genere un certificado de cliente con el formato de
valor de nombre común [email protected]. Use este formato en lugar de domain
name\username.
Asegúrese de que el certificado de cliente se base en la plantilla de certificado de usuario que
tenga Autenticación de cliente como primer elemento de la lista de usuarios. Para comprobar el
certificado, haga doble clic en él y vea Uso mejorado de clave en la pestaña Detalles .
Cer tificado raíz autofirmado : siga los pasos de alguno de los siguientes artículos de certificados de
P2S para que los certificados de cliente que cree sean compatibles con las conexiones de P2S.
Si genera un certificado de cliente desde un certificado raíz autofirmado, este se instala automáticamente
en el equipo que utilizó para generarlo. Si desea instalar un certificado de cliente en otro equipo cliente,
expórtelo como un archivo .pfx junto con toda la cadena de certificados. De esta forma, creará un archivo
.pfx que contiene la información del certificado raíz necesaria para que el cliente se autentique.
Los pasos de estos artículos generan un certificado de cliente compatible que puede, posteriormente,
exportar y distribuir.
PowerShell para generar certificados. Los certificados generados pueden instalarse en cualquier
Instrucciones para MakeCert: use MakeCert si no tiene acceso a un equipo Windows 10 para
generar certificados. Aunque MakeCert está en desuso, todavía puede usarlo para generar
certificados. Puede instalar los certificados generados en cualquier cliente P2S compatible.
Carga del archivo .cer de certificado raíz
Una vez creada la puerta de enlace, cargue el archivo .cer (que contiene la información de clave pública) para un
certificado raíz de confianza en el servidor de Azure. No cargue la clave privada para el certificado raíz. Una vez
cargado el certificado, Azure lo usa para autenticar a los clientes que tienen instalado un certificado de cliente
generado a partir del certificado raíz de confianza. Más adelante, puede cargar más archivos de certificado raíz
de confianza, hasta un total de 20, si es necesario.
1. Vaya a la red virtual que creó.
2. En Configuración , seleccione Conexiones de punto a sitio .
3. Seleccione Administrar cer tificado .
4. Seleccione Cargar .
5. En el panel Cargar un cer tificado , seleccione el icono de la carpeta y navegue hasta el certificado que
quiere cargar.
6. Seleccione Cargar .
7. Una vez que el certificado se haya cargado correctamente, puede verlo en la página Administrar certificado.
Es posible que tenga que seleccionar Actualizar para ver el certificado que acaba de cargar.
Configurar el cliente
Para conectarse a una red virtual mediante una VPN de punto a sitio, cada cliente debe instalar un paquete para
configurar el cliente de VPN de Windows nativo. El paquete de configuración configura el cliente de VPN nativo
de Windows con los parámetros necesarios para conectarse a la red virtual.
Puede utilizar el mismo paquete de configuración de cliente VPN en todos los equipos cliente, siempre que la
versión coincida con la arquitectura del cliente. Para obtener la lista de sistemas operativos cliente compatibles,
consulte el documento Acerca de las conexiones de punto a sitio y las Preguntas más frecuentes.
Generación e instalación de un paquete de configuración de cliente de VPN
1. Vaya a la configuración Conexiones de punto a sitio de la red virtual.
2. En la parte superior de la página, seleccione el paquete de descarga que se corresponde con el sistema
operativo cliente en el que se va a instalar:
Para los clientes de 64 bits, seleccione Cliente de VPN (64 bits) .
Para los clientes de 32 bits, seleccione Cliente de VPN (32 bits) .
3. Azure genera un paquete con la configuración específica que requiere el cliente. Cada vez que realice
cambios en la red virtual o la puerta de enlace, deberá descargar un nuevo paquete de configuración de
cliente e instalarlo en los equipos cliente.
4. Una vez generado el paquete, seleccione Descargar .
5. Instale el paquete de configuración del cliente en el equipo cliente. Al realizar la instalación, si ve una
ventana emergente de SmartScreen que indica que Windows protegió su equipo, seleccione Más
información y, después, seleccione Ejecutar de todas formas . También puede guardar el paquete
para instalarlo en otros equipos cliente.
Instalación de un certificado de cliente
Para este ejercicio, al generar el certificado de cliente, se instaló automáticamente en el equipo. Para crear una
conexión P2S desde un equipo cliente distinto del que usó para generar los certificados de cliente, debe instalar
un certificado de cliente en ese equipo.
Al instalar un certificado de cliente, necesita la contraseña que se creó cuando se exportó el certificado de
cliente. Normalmente, puede instalar el certificado con tan solo hacer doble clic en él. Para más información,
consulte Instalación de un certificado de cliente exportado.
Conexión a la red virtual
NOTE
Debe tener derechos de administrador en el equipo cliente desde el que se va a conectar.
1. En el equipo cliente, vaya a la configuración de VPN.

2. Seleccione la VPN que ha creado. Si usó la configuración de ejemplo, la conexión estará etiquetada como
Grupo TestRG VNet1 .
3. Seleccione Conectar .
4. En el cuadro de Windows Azure Virtual Network, seleccione Conectar . Si aparece un mensaje emergente
sobre el certificado, seleccione Continuar para usar privilegios elevados y Sí para aceptar los cambios en la
configuración.
5. Si la conexión se realiza correctamente, verá una notificación Conectado .
conexiones P2S.

1. Verifique que la conexión VPN está activa. Abra un símbolo del sistema con privilegios elevados en el
equipo cliente y ejecute ipconfig/all .
2. Vea los resultados. Observe que la dirección IP recibida es una de las direcciones en el intervalo de
direcciones de conectividad de punto a sitio que especificó cuando creó la red virtual. Los resultados
deben ser parecidos a los del ejemplo siguiente:
PPP adapter VNet1:

DHCP Enabled....................: No
Subnet Mask.....................: 255.255.255.255
Para conectarse a una máquina virtual
Cree una Conexión a Escritorio remoto para conectarse a una máquina virtual implementada en la red virtual.
La mejor manera de verificar que puede conectarse a la máquina virtual es hacerlo mediante su dirección IP
privada, en lugar del nombre de equipo. Con este método prueba si puede conectarse, no si la resolución de
nombres está configurada correctamente.
1. Busque la dirección IP privada de la máquina virtual. Para buscar la dirección IP privada de una máquina
virtual, consulte sus propiedades en Azure Portal o use PowerShell.
2. Verifique que está conectado a su red virtual mediante la conexión VPN de punto a sitio.
3. Para abrir la Conexión a Escritorio remoto, escriba RDP o Conexión a Escritorio remoto en el cuadro de
búsqueda de la barra de tareas y, después, seleccione Conexión a Escritorio remoto . También puede abrir
esta opción con el comando mstsc de PowerShell.
4. En Conexión a Escritorio remoto , escriba la dirección IP privada de la máquina virtual. Si es necesario,
seleccione Mostrar opciones para ajustar más parámetros adicionales y, después, conéctese.
Solución de problemas de una conexión de RDP a una máquina virtual
Si tiene problemas para conectarse a una máquina virtual a través de su conexión VPN, puede comprobar varios
factores.
Escriba ipconfig para comprobar la dirección IPv4 asignada al adaptador de Ethernet en el equipo desde el
que intenta conectarse. Se crea un espacio de direcciones superpuesto 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. 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, consulte Solución de problemas de conexiones del
Para agregar o quitar certificados raíz de confianza

tienen un certificado generado a partir de dicha raíz ya no podrán autenticarse ni tampoco conectarse. Para que
esos clientes puedan volver a autenticarse y conectarse, debe instalar un nuevo certificado de cliente generado a
partir de un certificado raíz que sea de confianza en Azure.
Adición de un certificado raíz de confianza
Puede agregar hasta 20 archivos .cer de certificado raíz de confianza en Azure mediante el mismo proceso que
usó para agregar el primer certificado raíz de confianza.
Eliminación de un certificado raíz de confianza
1. En la sección Conexiones de punto a sitio de la página de la red virtual, seleccione Administrar
cer tificado .
2. Seleccione los puntos suspensivos junto al certificado que quiere quitar y, después, seleccione Eliminar .
Para revocar un certificado de cliente
Si es necesario, puede revocar un certificado de cliente. La lista de revocación de certificados permite denegar
de forma selectiva la conectividad de punto a sitio basada en certificados de cliente individuales. Este método
difiere de la forma en que se quita un certificado raíz de confianza. Si quita de Azure un archivo .cer de
certificado raíz de confianza, se revoca el acceso para todos los certificados de cliente generados y firmados con
el certificado raíz revocado. Al revocarse un certificado de cliente, en lugar del certificado raíz, se permite que el
resto de los certificados que se generaron con el certificado raíz sigan usándose para la autenticación de la
conexión de punto a sitio.
individuales.
Puede revocar un certificado de cliente si agrega la huella digital a la lista de revocación.
1. Recupere la huella digital del certificado de cliente. Para más información, consulte Cómo recuperar la huella
digital de un certificado.
2. Copie la información en un editor de texto y quite sus espacios de forma que sea una sola cadena continua.
3. Vaya a Conexión VPN de punto a sitio y seleccione Administrar cer tificado .
4. Seleccione Lista de revocación para abrir la página Lista de revocación .
5. En Huella digital , pegue la huella digital del certificado como una línea continua de texto, sin espacios.
6. Seleccione + Agregar a la lista para agregar la huella digital a la lista de revocación de certificados (CRL).
Una vez finalizada la actualización, el certificado no se puede usar para conectarse. Los clientes que intenten
conectarse con este certificado recibirán un mensaje que indica que el certificado ya no es válido.
P+F
Estas preguntas más frecuentes corresponden a las conexiones P2S que usan el modelo de implementación
clásica.
Windows 10
¿Puedo usar cualquier cliente de software VPN de punto a sitio que admita SSTP?
No. La compatibilidad se limita solo a las versiones de sistema operativo de Windows enumeradas.
¿Cuántos puntos de conexión de cliente VPN pueden existir en mi configuración punto a sitio?
La cantidad de puntos de conexión de cliente VPN depende de la SKU y el protocolo de la puerta de enlace.
P RUEB A S

n1
n1
n1
n1 Z
n1 Z
n1 Z
n2
n2
n2

n2 10000
n2 Z
n2 Z
n2 Z

n2 Z 10000
más bajo.
PA Q UET ES P O R

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000

AES256 y SHA256 500 Mbps 50.000
DES3 y SHA256 120 Mbps 50.000

AES256 y SHA256 500 Mbps 80 000
DES3 y SHA256 120 Mbps 55 000

AES256 y SHA256 550 Mbps 90 000
DES3 y SHA256 120 Mbps 60 000
¿Puedo usar mi propio CA raíz de PKI interna para la conectividad de punto a sitio?
Sí. Anteriormente, solo podían usarse certificados raíz autofirmados. Todavía puede cargar hasta 20 certificados
raíz.
Sí. Usamos el Protocolo de túnel de sockets de seguros (SSTP) para la tunelización a través de firewalls. Este
túnel aparece como una conexión HTTPS.
automática?
No. Las VPN de punto a sitio no admiten la reconexión automática y el DDNS.
¿Puedo tener configuraciones de sitio a sitio y de punto a sitio en la misma red virtual?
Sí. Ambas soluciones funcionarán si tiene un tipo de VPN basada en enrutamiento 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áticas o puertas de enlace que usan el cmdlet -
VpnType PolicyBased .
Sí. Sin embargo, las redes virtuales no pueden tener prefijos IP superpuestos y los espacios de dirección de
punto a sitio no pueden superponerse entre las redes virtuales.
e Internet.
Pasos siguientes
Para más información sobre las redes y las máquinas virtuales Linux, consulte Información general sobre
las redes de máquina virtual con Linux y Azure.
Para información de solución de problemas de P2S, consulte el artículo de solución de problemas de
conexión de punto a sitio de Azure.
Configuración de una conexión de red virtual a red
virtual (clásico)
Este artículo lo ayuda a crear una conexión de puerta de enlace de VPN entre las redes virtuales. Las redes
virtuales pueden estar en la misma región o en distintas, así como pertenecer a una única suscripción o a varias.
NOTE
Los pasos de este artículo se corresponden al modelo de implementación clásica y a Azure Portal. También se
puede crear esta configuración con una herramienta o modelo de implementación distintos, mediante la
selección de una opción diferente en la lista siguiente:
Acerca de conexiones de red virtual a red virtual

La conexión de una red virtual a otra (de red virtual a red virtual) en el modelo de implementación clásica con
una VPN Gateway es parecida a la conexión de una red virtual a la ubicación de un sitio local. Ambos tipos de
conectividad usan una puerta de enlace de VPN para proporcionar un túnel seguro con IPsec/IKE.
Las redes virtuales que se conecten pueden estar en suscripciones y regiones distintas. Puede combinar la
comunicación entre redes virtuales con configuraciones de varios sitios. Esto permite establecer topologías de
red que combinen la conectividad entre entornos con la conectividad entre redes virtuales.
¿Por qué debería conectarse a redes virtuales?
Puede que desee conectar redes virtuales por las siguientes razones:
Con Azure Load Balancer y Microsoft, o con una tecnología de agrupación en clústeres de otros
fabricantes, puede configurar cargas de trabajo de alta disponibilidad y redundancia geográfica en
varias regiones de Azure. Por ejemplo, puede configurar AlwaysOn de SQL con grupos de
disponibilidad distribuidos en varias regiones de Azure.
Aplicaciones regionales de varios niveles con límite de aislamiento sólido
En la misma región se pueden configurar aplicaciones de niveles múltiples con varias redes virtuales
conectadas entre sí, con un aislamiento sólido y una comunicación entre niveles segura.
Comunicación entre suscripciones y entre organizaciones en Azure
Si tiene varias suscripciones a Azure, puede conectar cargas de trabajo de distintas suscripciones
simultáneamente entre redes virtuales de forma segura.
Asimismo, tanto las empresas como los proveedores de servicios pueden habilitar la comunicación
entre organizaciones con tecnología VPN segura en Azure.
Para más información acerca de las conexiones de red virtual a red virtual, consulte Consideraciones de red
virtual a red virtual al final de este artículo.
Requisitos previos
Usamos el portal para la mayoría de los pasos, pero debe usar PowerShell para crear las conexiones entre las
redes virtuales. No puede crear las conexiones mediante Azure Portal porque no hay ninguna manera de
especificar la clave compartida en el portal. Cuando se trabaja con el modelo de implementación clásica, no se
puede usar Azure Cloud Shell. En su lugar, debe instalar la versión más reciente de los cmdlets de PowerShell
para Azure Service Management (SM) en el equipo. Estos cmdlets son diferentes de los de AzureRM o Az. Para
instalar los cmdlets de SM, consulte Instalación de cmdlets de Service Management. Para más información
sobre Azure PowerShell en general, consulte la documentación de Azure PowerShell.
Planificación
Es importante decidir los intervalos que usará para configurar las redes virtuales. Para esta configuración, debe
asegurarse de que ninguno de los intervalos de red virtual se superpongan entre sí o con cualquiera de las
redes locales a las que se conectan.
Redes virtuales
Para este ejercicio, usamos los valores de ejemplo siguientes:
Valores para TestVNet1
Nombre: TestVNet1
Espacio de direcciones: 10.11.0.0/16, 10.12.0.0/16 (opcional)
Nombre de subred: predeterminado
Intervalo de direcciones de subred: 10.11.0.0/24
Grupo de recursos: ClassicRG
Valores para TestVNet4
Nombre: TestVNet4
Espacio de direcciones: 10.41.0.0/16, 10.42.0.0/16 (opcional)
Nombre de subred: predeterminado
Intervalo de direcciones de subred: 10.41.0.0/24
Grupo de recursos: ClassicRG
Conexiones
En la tabla siguiente se muestra un ejemplo de cómo conectará las redes virtuales. Use los intervalos solo como
referencia. Escriba los intervalos para las redes virtuales. Necesitará esta información en pasos posteriores.
En este ejemplo, TestVNet1 se conecta a un sitio de red local que crea con el nombre "VNet4Local". La
configuración de VNet4Local contiene los prefijos de dirección para TestVNet4. El sitio local para cada red virtual
es la otra red virtual. Los valores de ejemplo siguientes se usan para esta configuración:
Ejemplo
VIRT UA L N ET W O RK ESPA C IO DE DIREC C IO N ES LO C AT IO N RED LO C A L
TestVNet1 TestVNet1 Este de EE. UU. SiteVNet4

(10.11.0.0/16) (10.41.0.0/16)
(10.12.0.0/16) (10.42.0.0/16)
TestVNet4 TestVNet4 Oeste de EE. UU. SiteVNet1

(10.41.0.0/16) (10.11.0.0/16)
(10.42.0.0/16) (10.12.0.0/16)
Creación de redes virtuales

En este paso, crea dos redes virtuales clásicas, TestVNet1 y TestVNet4. Si utiliza este artículo como ejercicio, use
los valores de ejemplo.
Cuando cree las redes vir tuales, recuerde la siguiente configuración:
Espacios de direcciones de la red vir tual : en la página Espacios de direcciones de la red virtual,
especifique el intervalo de direcciones que desea usar para la red virtual. Estas son las direcciones IP
dinámicas que se asignarán a las máquinas virtuales y a las demás instancias de rol implementadas en
esta red virtual.
Los espacios de direcciones que selecciona no se pueden superponer con los espacios de direcciones de
ninguna de las otras redes virtuales o las ubicaciones locales a las que se conectará esta red virtual.
Ubicación : al crear una red virtual, la debe asociar a una ubicación de Azure (región). Por ejemplo, Por
ejemplo, si desea que las máquinas virtuales que implemente en la red virtual se encuentren físicamente
en Oeste de EE.UU., seleccione esa ubicación. No se puede cambiar la ubicación asociada a la red virtual
después de crearla.
Después de crear las redes vir tuales, puede agregar la configuración siguiente:
Espacio de direcciones : no se requiere espacio de direcciones adicional para esta configuración, pero
puede agregar espacio de direcciones adicional después de crear la red virtual.
Subredes : no se requieren subredes adicionales para esta configuración, pero puede que quiera que las
máquinas virtuales estén en una subred independiente de las otras instancias de rol.
Ser vidores DNS : escriba el nombre del servidor DNS y la dirección IP. Mediante este valor no se crea un
servidor DNS. Le permite especificar el servidor DNS que desea usar para la resolución de nombres para
esta red virtual.
Para crear una red virtual clásica
Configuración de sitios y puertas de enlace

Azure usa la configuración especificada en cada sitio de red local para determinar cómo enrutar el tráfico entre
las redes virtuales. Cada red virtual debe señalar a la red local correspondiente a la que se desea redirigir el
tráfico. Puede determinar el nombre que quiere utilizar para hacer referencia a cada sitio de red local. Se
recomienda usar un nombre descriptivo.
Por ejemplo, TestVNet1 se conecta a un sitio de red local que cree con el nombre "VNet4Local". La configuración
de VNet4Local contiene los prefijos de dirección para TestVNet4.
Tenga en cuenta que el sitio local para cada red virtual es la otra red virtual.
VIRT UA L N ET W O RK ESPA C IO DE DIREC C IO N ES LO C AT IO N RED LO C A L
TestVNet1 TestVNet1 Este de EE. UU. SiteVNet4

(10.11.0.0/16) (10.41.0.0/16)
(10.12.0.0/16) (10.42.0.0/16)
TestVNet4 TestVNet4 Oeste de EE. UU. SiteVNet1

(10.41.0.0/16) (10.11.0.0/16)
(10.42.0.0/16) (10.12.0.0/16)
Para configurar un sitio

seleccionado De sitio a sitio .
la red local. Para este ejercicio, puede incluir una dirección ficticia porque todavía no tiene la
dirección IP de VPN Gateway del otro sitio. Por ejemplo: 5.4.3.2. Más adelante, una vez configurada
la puerta de enlace de la otra red virtual, puede ajustar este valor.
la otra red virtual mediante esta puerta de enlace. Puede agregar varios intervalos de espacios de
de enlace> .
Configuración de una puerta de enlace de red virtual
corresponde a 'PolicyBased'. Para esta configuración, seleccione Dynamic .
3. Puede continuar en el paso siguiente mientras se crea esta puerta de enlace.
Configuración de las opciones de TestVNet4
Repita los pasos de Creación de un sitio y una puerta de enlace para configurar TestVNet4 y reemplace los
valores cuando sea necesario. Si hace esto como ejercicio, use los valores de ejemplo.
Actualización de sitios locales

Una vez que se crean las puertas de enlace de red virtual para ambas redes virtuales, debe ajustar las
propiedades de Dirección IP de VPN Gateway de los sitios locales.
DIREC C IÓ N IP DE L A P UERTA DE
N O M B RE DE RED VIRT UA L SIT IO C O N EC TA DO EN L A C E
TestVNet1 VNet4Local Dirección IP de VPN Gateway para

TestVNet4
TestVNet4 VNet1Local Dirección IP de VPN Gateway para

TestVNet1
Parte 1: Obtención de la dirección IP pública de puerta de enlace de red virtual

1. Para navegar a su virtual, diríjase a Grupo de recursos y selecciónela.
2. En la página de la red virtual, en el panel Essentials de la derecha, busque la Dirección IP de la puer ta de
enlace y cópiela en el portapapeles.
Parte 2: Modificación de las propiedades de sitios locales
1. En Conexiones de sitio a sitio, seleccione la conexión. Por ejemplo, SiteVNet4.
2. En la página Propiedades de Conexión de sitio a sitio, seleccione Editar el sitio local .
3. En el campo Dirección IP de la puer ta de enlace de VPN , pegue la dirección IP de la puerta de enlace de
VPN que copió en la sección anterior.
4. Seleccione Aceptar .
5. El campo se actualiza en el sistema. También puede usar este método para agregar la dirección IP adicional
que quiere enrutar a este sitio.
Parte 3: Repetición de los pasos para la otra red virtual
Repita los pasos para TestVNet4.
Recuperar los valores de configuración

conectarse:
Add-AzureAccount

Crear conexiones
Una vez completados todos los pasos anteriores, puede establecer las claves compartidas previamente de
IPsec/IKE y cree la conexión. Este conjunto de pasos usa PowerShell. Las conexiones de red virtual a red virtual
del modelo de implementación clásica no se pueden configurar en Azure Portal porque la clave compartida no
se puede especificar en el portal.
En los ejemplos, verá que la clave compartida es exactamente la misma. Siempre debe coincidir con la clave
compartida. Asegúrese de reemplazar los valores de estos ejemplos por los nombres exactos de las redes
locales y los sitios de red local.
1. Cree la conexión de TestVNet1 a TestVNet4. Asegúrese de cambiar los valores.
Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet1' `

-LocalNetworkSiteName 'value for _VNet4Local' -SharedKey A1b2C3D4
2. Cree la conexión de TestVNet4 a TestVNet1.

Set-AzureVNetGatewayKey -VNetName 'Group ClassicRG TestVNet4' `
-LocalNetworkSiteName 'value for _VNet1Local' -SharedKey A1b2C3D4
3. Espere a que se inicialicen las conexiones. Una vez que se inicializa la puerta de enlace, el estado pasa a
ser "Correcto".
Error :
HttpStatusCode : OK
Id :
Status : Successful
RequestId :
StatusCode : OK
Preguntas más frecuentes y consideraciones

Estas consideraciones se aplican a las redes virtuales clásicas y a las puertas de enlace de red virtual clásicas.
Las redes virtuales pueden estar en la misma suscripción o en suscripciones distintas.
Las redes virtuales pueden estar en la misma región de Azure o en regiones distintas (ubicaciones).
Un servicio en la nube o un punto de conexión de equilibrio de carga no puede abarcar varias redes
La conexión simultánea de varias redes virtuales no requiere dispositivos VPN locales.
VNet a VNet admite la conexión a Azure Virtual Networks. No admite la conexión de máquinas virtuales o
servicios en la nube que no estén implementados en una red virtual.
Red virtual a red virtual requiere puertas de enlace de enrutamiento dinámico. No se admiten puertas de
enlace de enrutamiento estático de Azure.
La conectividad de red virtual se puede usar de forma simultánea con VPN de varios sitios. Existe un máximo
de 10 túneles de VPN para una VPN Gateway de red virtual conectada a otras redes virtuales o sitios locales.
Los espacios de direcciones de las redes virtuales y de los sitios de red local no se pueden solapar. Los
espacios de direcciones solapados provocarán un error al crear redes virtuales o al cargar archivos de
configuración netcfg.
No se admiten los túneles redundantes entre un par de redes virtuales.
Todos los túneles de VPN para la red virtual, incluidas las VPN de punto a sitio (P2S), comparten el ancho de
banda disponible para la VPN Gateway y el mismo Acuerdo de Nivel de Servicio de tiempo de actividad de
VPN Gateway de Azure.
El tráfico VNet a VNet viaja a través de la red troncal de Azure.
Pasos siguientes
Compruebe las conexiones. Consulte Comprobación de una conexión de VPN Gateway.
Configuración de la tunelización forzada mediante
el modelo de implementación clásica
seguridad crítico en la mayoría de las directivas de las empresas de TI. Sin la tunelización forzada, el tráfico
vinculado a Internet desde las máquinas virtuales en Azure siempre irá desde la infraestructura de red de Azure
directamente a Internet, sin la opción que permite inspeccionar o auditar el tráfico. Un acceso no autorizado a
Internet puede provocar la divulgación de información u otros tipos de infracciones de seguridad.
Manager.
Este artículo le guiará a través del proceso de configuración de la tunelización forzada para redes virtuales
creadas mediante el modelo de implementación clásica. La tunelización forzada puede configurarse mediante el
uso de PowerShell, no a través del portal. Si quiere configurar la tunelización forzada para el modelo de
implementación de Resource Manager, seleccione el artículo de Resource Manager de la siguiente lista
desplegable:
La tunelización forzada en Azure se configura a través de rutas definidas por el usuario (UDR) de redes virtuales.
La redirección del tráfico a un sitio local se expresa como una ruta predeterminada a la puerta de enlace de VPN
de Azure. La sección siguiente muestra la limitación actual de la tabla de enrutamiento y las rutas de una
instancia de Azure Virtual Network:
red virtual.
Ruta predeterminada: directamente a Internet. Los paquetes destinados a las direcciones IP
Con la liberación de las rutas definidas por el usuario, puede crear una tabla de enrutamiento para
agregar una ruta predeterminada y, después, asociar la tabla de enrutamiento a las subredes de la red
virtual para habilitar la tunelización forzada en esas subredes.
Deberá establecer un "sitio predeterminado" entre los sitios locales entre entornos conectados a la red
virtual.
La tunelización forzada debe asociarse a una red virtual que tiene una puerta de enlace de VPN de
enrutamiento dinámico (no una puerta de enlace estática).
ExpressRoute. Para más información, consulte ¿Qué es ExpressRoute?

En el ejemplo siguiente, la subred Frontend no usa la tunelización forzada. Las cargas de trabajo de la subred
Frontend pueden continuar para aceptar y responder a las solicitudes de los clientes directamente desde
Internet. Las subredes Mid-tier y Backend usan la tunelización forzada. Las conexiones salientes desde estas dos
subredes a Internet se fuerzan o redirigen a un sitio local a través de uno de los túneles VPN de sitio a sitio.
en Azure, al tiempo que continúa posibilitando la arquitectura de varios niveles de servicio necesaria. También
tiene la opción de aplicar la tunelización forzada a redes virtuales completas si no hay ninguna carga de trabajo
a través de Internet en las redes virtuales.
Requisitos previos
Antes de comenzar con la configuración, verifique que dispone de los elementos siguientes:
Suscripción a Azure. Si todavía no la tiene, puede activar sus ventajas como suscriptor de MSDN o registrarse
para obtener una cuenta gratuita.
Una red virtual configurada.

El siguiente procedimiento lo ayudará a especificar la tunelización forzada en una red virtual. Los pasos de
configuración corresponden al archivo de configuración de red virtual. En este ejemplo, la red virtual "MultiTier-
VNet" tiene tres subredes: las subredes "Frontend", "Midtier" y "Backend", con cuatro conexiones entre locales:
"DefaultSiteHQ" y tres ramas.
<VirtualNetworkSite name="MultiTier-VNet" Location="North Europe">
<AddressSpace>
</AddressSpace>
<Subnets>
<Subnet name="Frontend">
</Subnet>
<Subnet name="Midtier">
</Subnet>
<Subnet name="Backend">
</Subnet>
</Subnet>
</Subnets>
<Gateway>
<LocalNetworkSiteRef name="DefaultSiteHQ">
</Gateway>
Los siguientes pasos establecerán "DefaultSiteHQ" como la conexión de sitio predeterminada para la
tunelización forzada y configurarán las subredes Midtier y Backend para que usen dicha tunelización.
1. Abra la consola de PowerShell con privilegios elevados. Conéctese a su cuenta mediante el ejemplo
siguiente:
Add-AzureAccount
2. Cree una tabla de enrutamiento. Use el siguiente cmdlet para crear la tabla de enrutamiento.
New-AzureRouteTable –Name "MyRouteTable" –Label "Routing Table for Forced Tunneling" –Location "North
Europe"
3. Agregue una ruta predeterminada a la tabla de enrutamiento.

El siguiente ejemplo agrega una ruta predeterminada a la tabla de enrutamiento que creó en el paso 1.
Tenga en cuenta que la única ruta admitida es el prefijo de destino de 0.0.0.0/0 para el próximo salto
VPNGateway.
Get-AzureRouteTable -Name "MyRouteTable" | Set-AzureRoute –RouteTable "MyRouteTable" –RouteName

"DefaultRoute" –AddressPrefix "0.0.0.0/0" –NextHopType VPNGateway
4. Asocie la tabla de enrutamiento a las subredes.

Una vez creada una tabla de enrutamiento y agregada una ruta, use el ejemplo siguiente para agregar o
asociar la tabla de enrutamiento a una subred de la red virtual. Los siguientes ejemplos agregan la tabla
de enrutamiento MyRouteTable a las subredes Midtier y Backend de VNet MultiTier-VNet.
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Midtier" -RouteTableName

"MyRouteTable"
Set-AzureSubnetRouteTable -VirtualNetworkName "MultiTier-VNet" -SubnetName "Backend" -RouteTableName
"MyRouteTable"
5. Asigne un sitio predeterminado para la tunelización forzada.

En el paso anterior, los scripts del cmdlet de ejemplo crean la tabla de enrutamiento y la tabla de
enrutamiento asociada a dos de las subredes de la red virtual. El paso restante consiste en seleccionar un
sitio local entre las conexiones de varios sitios de la red virtual como el sitio predeterminado o túnel.
$DefaultSite = @("DefaultSiteHQ")
Set-AzureVNetGatewayDefaultSite –VNetName "MultiTier-VNet" –DefaultSite "DefaultSiteHQ"
Cmdlets de PowerShell adicionales

Para eliminar una tabla de enrutamiento
Remove-AzureRouteTable -Name <routeTableName>
Para mostrar una tabla de enrutamiento
Get-AzureRouteTable [-Name <routeTableName> [-DetailLevel <detailLevel>]]
Para eliminar una ruta de una tabla de enrutamiento
Remove-AzureRouteTable –Name <routeTableName>
Para quitar una ruta de una subred
Remove-AzureSubnetRouteTable –VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
Para mostrar la tabla de enrutamiento asociada a una subred
Get-AzureSubnetRouteTable -VirtualNetworkName <virtualNetworkName> -SubnetName <subnetName>
Para quitar un sitio predeterminado de una puerta de enlace de VPN de VNet
Remove-AzureVnetGatewayDefaultSite -VNetName <virtualNetworkName>

mediante PowerShell (clásico)
Este artículo le ayuda a eliminar una puerta de enlace de VPN en el modelo de implementación clásica mediante
PowerShell. Una vez que elimina la puerta de enlace de red virtual, modifique el archivo de configuración de red
para quitar los elementos que ya no usa.
Paso 1: Conexión con Azure

1. Instale los cmdlets más recientes de PowerShell.
debe instalar la versión más reciente de los cmdlets de PowerShell para Azure Service Management (SM) en el
equipo. Estos cmdlets son diferentes de los de AzureRM o Az. Para instalar los cmdlets de SM, consulte
2. Conéctese a su cuenta de Azure.
Abra la consola de PowerShell con privilegios elevados y conéctela a su cuenta. Use el siguiente ejemplo para
conectarse:
1. Abra la consola de PowerShell con privilegios elevados.
2. Conéctese a su cuenta. Use el siguiente ejemplo para conectarse:
Add-AzureAccount
Paso 2: Exportación y visualización del archivo de configuración de

red
Cree un directorio en el equipo y, a continuación, exporte el archivo de configuración de red al directorio. Use
este archivo para ver la información de la configuración actual y también para modificar la configuración de red.
En este ejemplo, se exporta el archivo de configuración de red a C:\AzureNet.
Abra el archivo con un editor de texto y consulte el nombre de la red virtual clásica. Cuando crea una red virtual
en Azure Portal, el nombre completo que Azure usa no aparece en el portal. Por ejemplo, una red virtual que
parece llamarse "ClassicVNet1" en Azure Portal puede que tenga un nombre mucho más largo en el archivo de
configuración de la red. El nombre podría ser similar al siguiente: "Group ClassicRG1 ClassicVNet1". Los
nombres de las redes virtuales aparecen como "Vir tualNetworkSite name =" . Use los nombres que
aparecen en el archivo de configuración de red cuando ejecute los cmdlets de PowerShell.
Paso 3: Eliminación de la puerta de enlace de red virtual

Cuando elimina una puerta de enlace de red virtual, se desconectan todas las conexiones a la red virtual a través
de la puerta de enlace. Si tiene clientes de P2S conectados a la red virtual, se desconectarán sin advertencia.
Este ejemplo elimina la puerta de enlace de red virtual. Asegúrese de usar el nombre completo de la red virtual
como aparece en el archivo de configuración de red.
Remove-AzureVNetGateway -VNetName "Group ClassicRG1 ClassicVNet1"
Si es correcto, el resultado mostrará lo siguiente:
Status : Successful
Paso 4: Modificación del archivo de configuración de red

Cuando elimina una puerta de enlace de red virtual, el cmdlet no modifica el archivo de configuración de red.
Debe modificar el archivo para quitar los elementos que ya no se usan. Las secciones siguientes lo ayudan a
modificar el archivo de configuración de red que descargó.
Referencias de sitio de red local
Cuando quite la información de referencia del sitio, haga cambios en la configuración en
ConnectionsToLocalNetwork/LocalNetworkSiteRef . Quitar una referencia a sitio local hace que Azure
elimine un túnel. Según la configuración que creó, puede que no aparezca LocalNetworkSiteRef .
<Gateway>
<LocalNetworkSiteRef name="D1BFC9CB_Site2">
</Gateway>
Ejemplo:
<Gateway>
</Gateway>
Sitios de red local

Quite los sitios locales que ya no usa. Según la configuración que haya creado, es posible que no aparezca el
elemento LocalNetworkSite en la lista.
<LocalNetworkSites>
<LocalNetworkSite name="Site1">
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
En este ejemplo, solo quitamos Site3.

<LocalNetworkSites>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
Grupo de direcciones de cliente

Si tuviera una conexión P2S a la red virtual, tendría un elemento VPNClientAddressPool . Quite los grupos de
direcciones de cliente que correspondan a la puerta de enlace de red virtual que eliminó.
<Gateway>
<VPNClientAddressPool>
</VPNClientAddressPool>
<ConnectionsToLocalNetwork />
</Gateway>
Ejemplo:
<Gateway>
<ConnectionsToLocalNetwork />
</Gateway>
GatewaySubnet
Elimine el elemento GatewaySubnet que corresponde a la red virtual.
<Subnets>
<Subnet name="FrontEnd">
</Subnet>
</Subnet>
</Subnets>
Ejemplo:
<Subnets>
<Subnet name="FrontEnd">
</Subnet>
</Subnets>
Paso 5: Carga del archivo de configuración de red

Guarde los cambios y cargue el archivo de configuración de red en Azure. Asegúrese de cambiar la ruta de
acceso según sea necesario para su entorno.
Si lo hace correctamente, el resultado será similar a este ejemplo:

OperationDescription OperationId OperationStatus
-------------------- ----------- ---------------
Set-AzureVNetConfig e0ee6e66-9167-cfa7-a746-7casb9 Succeeded
Agregar una conexión de sitio a sitio a una red
virtual con una conexión de VPN Gateway existente
(clásico)
NOTE
Este artículo le guiará a través del uso de PowerShell para agregar conexiones de sitio a sitio (S2S) a VPN
Gateway con una conexión existente. Este tipo de conexión se denomina con frecuencia, configuración
"multisitio". Los pasos de este artículo se aplican a las redes virtuales creadas con el modelo de implementación
clásica (también conocido como Service Management). Estos pasos no se aplican a las configuraciones de
conexión coexistentes de ExpressRoute/sitio a sitio.
Modelos de implementación y métodos
Manager.
Esta tabla se actualiza cada vez que hay nuevos artículos y nuevas herramientas disponibles para esta
configuración. Cuando aparezca un artículo, creamos un vínculo directo a él desde esta tabla.
Resource Manager Tutorial Compatible
Clásico No compatible Tutorial
Acerca de la conexión
Puede conectar varios sitios locales a una única red virtual. Esto resulta especialmente atractivo para crear
soluciones híbridas en la nube. La creación de una conexión de varios sitios en la puerta de enlace de red virtual
de Azure es similar a la creación de otras conexiones de sitio a sitio. De hecho, puede utilizar una Azure VPN
Gateway existente, siempre que la puerta de enlace sea dinámica (basada en ruta).
Si ya se ha conectado una puerta de enlace estática a la red virtual, puede cambiar el tipo de puerta de enlace a
dinámico sin tener que recompilar la red virtual para dar cabida a varios sitios. Antes de cambiar el tipo de
enrutamiento, asegúrese de que la VPN Gateway local admite configuraciones de VPN basadas en ruta.
Puntos que se deben tener en cuenta
No podrá usar el por tal para realizar cambios en esta red vir tual. Tiene que realizar los cambios en el
archivo de configuración de red en lugar de usar el portal. Si realiza cambios en el portal, sobrescribirán la
configuración de referencia a varios sitios de esta red virtual.
Debe sentirse cómodo al usar el archivo de configuración de red en el momento en el que complete el
procedimiento de varios sitios. Sin embargo, si hay más personas que trabajan en la configuración de red,
tendrá que asegurarse de que todos conocen esta limitación. Esto no significa que no pueda usar el portal en
absoluto. Puede usarlo para todo lo demás menos para hacer cambios de configuración en esta red virtual
concreta.
Antes de empezar
Antes de comenzar la configuración, compruebe que dispone de lo siguiente:
Hardware VPN compatible para cada ubicación local. Consulte Acerca de los dispositivos VPN para
conectividad de red virtual para comprobar si el dispositivo que quiere usar es un dispositivo que se sabe
que es compatible.
Una dirección IP IPv4 pública orientada externamente para cada dispositivo VPN. La dirección IP no se puede
ubicar detrás de un NAT. Esto es un requisito.
Alguna persona con experiencia en configuración de hardware de VPN Necesitará un conocimiento amplio
de cómo configurar el dispositivo VPN o trabajar con alguien que lo tenga.
Los intervalos de dirección IP que desea usar para la red virtual (si aún no ha creado uno).
Los intervalos de direcciones IP para cada uno de los sitios de red locales a los que se va a conectar. Tendrá
que asegurarse de que los intervalos de dirección IP para cada uno de los sitios de red locales a los que
desea conectarse no se solapan. De lo contrario, el portal o la API de REST rechazarán la configuración que se
carga.
Por ejemplo, si dispone de dos sitios de red locales que contienen el intervalo de dirección IP 10.2.3.0/24 y
dispone de un paquete con una dirección de destino 10.2.3.3, Azure no sabrá a qué sitio desea enviar el
paquete porque se solapan los intervalos de dirección. Para evitar problemas de enrutamiento, Azure no loe
permite cargar un archivo de configuración que disponga de intervalos que se solapan.
debe instalar la versión más reciente de los cmdlets de PowerShell para Azure Service Management (SM) en el
equipo. Estos cmdlets son diferentes de los de AzureRM o Az. Para instalar los cmdlets de SM, consulte
1. Crear una VPN de sitio a sitio

Si ya tiene una VPN de sitio a sitio con una puerta de enlace de enrutamiento dinámico, perfecto. Puede pasar a
Exportación de la configuración de la red virtual. De lo contrario, haga lo siguiente:
Si ya dispone de una red virtual de sitio a sitio, pero con una puerta de enlace de enrutamiento estático
(basada en directivas):
1. Cambie el tipo de puerta de enlace a enrutamiento dinámico. Una VPN de varios sitios requiere una puerta
de enlace de enrutamiento dinámico (también denominada basada en ruta). Para cambiar el tipo de puerta
de enlace, tendrá que eliminar primero la puerta de enlace existente y, a continuación, crear una nueva.
2. Configure la nueva puerta de enlace y cree un túnel de VPN. Para obtener instrucciones, consulte
Especificación del tipo de VPN y SKU. Asegúrese de especificar el tipo de enrutamiento como "Dinámico".
Si no dispone de una red virtual de sitio a sitio:
1. Cree la red virtual de sitio a sitio mediante las instrucciones que se describen en: Creación de una red virtual
con una conexión VPN de sitio a sitio.
2. Configure una puerta de enlace de enrutamiento mediante estas instrucciones: Configuración de una
instancia de VPN Gateway. Asegúrese de seleccionar enrutamiento dinámico como tipo de puerta de
enlace.
2. Exportar el archivo de configuración de red

Abra la consola de PowerShell con privilegios elevados. Para cambiar a la administración de servicios, use este
comando:
azure config mode asm
Conéctese a su cuenta. Use el siguiente ejemplo para conectarse:
Add-AzureAccount
Exporte el archivo de configuración de red de Azure mediante la ejecución del comando siguiente. Puede
cambiar la ubicación del archivo que se va a exportar a una ubicación diferente si es necesario.
3. Abrir el archivo de configuración de red

Abra el archivo de configuración de red que descargó en el último paso. Use el editor xml que desee. El archivo
debe tener un aspecto similar al siguiente:
<NetworkConfiguration xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration">
<VirtualNetworkConfiguration>
<LocalNetworkSites>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<AddressSpace>
</AddressSpace>
</LocalNetworkSite>
<VirtualNetworkSites>
<VirtualNetworkSite name="VNet1" AffinityGroup="USWest">
<AddressSpace>
</AddressSpace>
<Subnets>
<Subnet name="FE">
</Subnet>
<Subnet name="BE">
</Subnet>
</Subnet>
</Subnets>
<Gateway>
<LocalNetworkSiteRef name="Site1">
</Gateway>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
4. Agregar referencias de varios sitios

Cuando agregue o quite la información de referencia del sitio, realizará cambios de configuración en
ConnectionsToLocalNetwork/LocalNetworkSiteRef. Si se agrega una nueva referencia a sitio local se activa Azure
para la creación de un nuevo túnel. En el ejemplo siguiente, la configuración de red es para una conexión de sitio
único. Cuando haya terminado de realizar los cambios, guarde el archivo.
<Gateway>
<LocalNetworkSiteRef name="Site1"><Connection type="IPsec" /></LocalNetworkSiteRef>
</Gateway>
Para agregar referencias a sitios adicionales (crear una configuración de varios sitios), basta con agregar líneas
"LocalNetworkSiteRef" adicionales, como se muestra en el ejemplo siguiente:
<Gateway>
</Gateway>
5. Importar el archivo de configuración de red

Importe un archivo de configuración de red. Cuando importe este archivo con los cambios, se agregarán nuevos
túneles. Los túneles usarán la puerta de enlace dinámica que creó anteriormente. Puede usar PowerShell para
importar el archivo.
6. Descargar las claves

Una vez que se han agregado los nuevos túneles, use el cmdlet de PowerShell 'Get-AzureVNetGatewayKey' para
obtener las claves IPsec/IKE compartidas previamente para cada túnel.
Por ejemplo:
Get-AzureVNetGatewayKey –VNetName "VNet1" –LocalNetworkSiteName "Site1"

Get-AzureVNetGatewayKey –VNetName "VNet1" –LocalNetworkSiteName "Site2"
Si lo prefiere, también puede usar la API de REST de Obtención de la clave compartida de puerta de enlace de la
red virtual para obtener claves compartidas previamente.
7. Comprobación de las conexiones

Compruebe el estado del túnel de varios sitios. Después de descargar las claves para cada túnel, querrá
comprobar las conexiones. Use 'Get-AzureVnetConnection' para obtener una lista de túneles de redes virtuales,
como se muestra en el siguiente ejemplo. VNet1 es el nombre de la red virtual.
Get-AzureVnetConnection -VNetName VNET1
Valor devuelto del ejemplo:

LastConnectionEstablished : 5/2/2014 2:51:40 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site 'Site1' changed from Not
Connected to Connected.
LastEventTimeStamp : 5/2/2014 2:51:40 PM
LocalNetworkSiteName : Site1
OperationDescription : Get-AzureVNetConnection
OperationId : 7f68a8e6-51e9-9db4-88c2-16b8067fed7f
OperationStatus : Succeeded
LastConnectionEstablished : 5/2/2014 3:20:40 PM
LastEventID : 23401
LastEventMessage : The connectivity state for the local network site 'Site2' changed from Not
Connected to Connected.
LastEventTimeStamp : 5/2/2014 2:51:40 PM
LocalNetworkSiteName : Site2
OperationDescription : Get-AzureVNetConnection
OperationId : 7893b329-51e9-9db4-88c2-16b8067fed7f
OperationStatus : Succeeded
Pasos siguientes
Para más información sobre las VPN Gateway, consulte Acerca de las VPN Gateway.
Creación de una conexión de sitio a sitio mediante
Este artículo muestra cómo usar Azure Portal para crear una conexión de puerta de enlace VPN de sitio a sitio
desde la red local a la red virtual. Los pasos de este artículo se aplican al modelo de implementación clásica, no
al modelo de implementación actual, Resource Manager. También se puede crear esta configuración con una
herramienta o modelo de implementación distintos, mediante la selección de una opción diferente en la lista
siguiente:
Antes de empezar
Compruebe que desea trabajar en el modelo de implementación clásica. Si desea trabajar en el modelo de
implementación de Resource Manager, consulte Creación de una conexión de sitio a sitio (Resource
Manager). Se recomienda usar el modelo de implementación de Resource Manager, ya que el modelo clásico
es heredado.
Se requiere PowerShell para especificar la clave compartida y crear la conexión de puerta de enlace VPN.
Valores de configuración de ejemplo para este ejercicio
prueba o hacer referencia a ellos para comprender mejor los ejemplos de este artículo. Normalmente, cuando
se trabaja con valores de dirección IP para el espacio de direcciones, se debe coordinar con el administrador de
red para evitar espacios de direcciones superpuestos, lo que puede afectar al enrutamiento. En este caso,
reemplace los valores de dirección IP por los suyos propios si quiere crear una conexión operativa.
Nombre de la red vir tual: TestVNet1
Nombre del sitio local: Site2
Espacio de direcciones de cliente: el espacio de direcciones que se encuentra en el sitio local.

Cuando se crea una red virtual que se usará para una conexión S2S, debe asegurarse de que los espacios de
direcciones que especifique no se superponen con ninguno de los espacios de direcciones de cliente de los sitios
locales a los que desea conectarse. Si tiene subredes superpuestas, la conexión no funcionará correctamente.
Si ya dispone de una red virtual, compruebe que la configuración sea compatible con el diseño de la
puerta de enlace de VPN. Preste especial atención a las subredes que se pueden superponer con otras
redes.
Si no tiene una red virtual, créela. Las capturas de pantalla se proporcionan a modo de ejemplo.
Asegúrese de reemplazar los valores por los suyos.
Configuración del sitio y la puerta de enlace
Configuración del sitio
seleccionado De sitio a sitio . Para este ejercicio, debe usar una combinación de los valores de ejemplo y
sus propios valores.
la red local. El dispositivo VPN requiere una dirección IP IPv4 pública. Especifique una dirección IP
pública válida para el dispositivo VPN al que desea conectarse. Debe ser accesible para Azure. Si
no conoce la dirección IP del dispositivo VPN, siempre puede poner un valor de marcador de
posición (siempre que tenga el formato de una dirección IP pública válida) y cambiarlo más
adelante.
la red local mediante esta puerta de enlace. Puede agregar varios intervalos de espacios de
de enlace> .
Configuración de la puerta de enlace de red virtual
corresponde a 'PolicyBased'. Normalmente, se quiere el enrutamiento dinámico.
Portal, PowerShell o la CLI.
S2S.
Recuperación de valores
conectarse:
Add-AzureAccount

NOTE
En el modelo de implementación clásica, este paso no está disponible en Azure Portal o a través de Azure Cloud Shell.
Debe usar la versión para Service Management (SM) de los cdmlets de Azure PowerShell localmente desde el escritorio.
En este paso, con los valores de los pasos anteriores, establezca la clave compartida y cree la conexión. La clave
que se establezca debe ser la misma que se usó en la configuración del dispositivo VPN.
1. Establezca la clave compartida y cree la conexión.
Cambie los valores de -VNetName y -LocalNetworkSiteName. Al especificar el nombre que contiene
espacios, escriba el valor entre comillas simples.
"SharedKe" es un valor que se puede generar y especificar. En el ejemplo, hemos usado "abc123" pero
puede usar algo más complejo. Lo importante es que el valor que especifique aquí debe ser el mismo
que el que se especificó al configurar el dispositivo VPN.
Set-AzureVNetGatewayKey -VNetName 'Group TestRG1 TestVNet1' `

-LocalNetworkSiteName '6C74F6E6_Site2' -SharedKey abc123
2. Cuando se crea la conexión, el resultado es: Estado: Correcto .
sitio a sitio .
Si tiene problemas para conectarse, consulte la sección de solución de problemas de la tabla de contenido en
el panel izquierdo.
Procedimientos para restablecer una puerta de enlace de VPN

pero no pueden establecer túneles IPsec con las Puertas de enlace de VPN de Azure. Para conocer los pasos,
consulte Restablecimiento de una puerta de enlace de VPN.
Procedimientos para cambiar la SKU de una puerta de enlace

Para que conocer los pasos para cambiar la SKU de puerta de enlace, consulte la sección Cambio de tamaño de
las SKU de una puerta de enlace.
Pasos siguientes
forzada.
Migración de VPN Gateway (clásico) a Resource
Manager
Las instancias de VPN Gateway ahora se pueden migrar del modelo de implementación clásica al de Resource
Manager. Puede leer más información sobre las características y ventajas de Azure Resource Manager. En este
artículo, se explica cómo migrar desde implementaciones clásicas al nuevo modelo basado en Resource
Manager.
Las instancias de VPN Gateway se migran como parte de la migración de red virtual del modelo clásico al de
Resource Manager. Esta migración se realiza con una red virtual cada vez. No se necesita nada más en cuanto a
herramientas o requisitos previos para la migración. Los pasos de migración son idénticos a los de la migración
de red virtual existente y están documentados en la página de migración de recursos de IaaS. No existe ningún
tiempo de inactividad para la ruta de acceso de datos durante la migración y, por tanto, las cargas de trabajo
existentes seguirán funcionando sin que se pierda la conectividad local durante la migración. La dirección IP
pública asociada a la puerta de enlace de VPN no cambia durante el proceso de migración. Esto significa que no
tendrá que volver a configurar el enrutador local una vez completada la migración.
El modelo en Resource Manager es diferente del modelo clásico y se compone de puertas de enlace de red
virtual, puertas de enlace de red local y recursos de conexión. Estos representan la puerta de enlace de VPN en
sí y el sitio local representa el espacio de direcciones local y la conectividad entre ambos respectivamente. Una
vez completada la migración, las puertas de enlace no estarán disponibles en el modelo clásico y todas las
operaciones de administración en puertas de enlace de red virtual, puertas de enlace de red local y objetos de
conexión se deben llevar a cabo mediante el modelo de Resource Manager.
Escenarios admitidos
Los escenarios de conectividad VPN más habituales están cubiertos en la migración del modelo clásico al de
Resource Manager. Entre los escenarios compatibles, se incluyen:
Conectividad de punto a sitio
Conectividad de sitio a sitio con conexión de VPN Gateway a una ubicación local
Conectividad de red virtual a red virtual entre dos redes virtuales con puertas de enlace de VPN
Varias redes virtuales conectadas a la misma ubicación local
Conectividad multisitio
Redes virtuales con la tunelización forzada habilitada
Entre los escenarios no admitidos, se incluyen:
No se admite actualmente la red virtual con la puerta de enlace de ExpressRoute y VPN Gateway.
Escenarios de tránsito donde las extensiones de máquina virtual están conectadas a servidores locales. A
continuación, se detallan las limitaciones de conectividad VPN de tránsito.
NOTE
La validación de CIDR en el modelo de Resource Manager es más estricta que la del modelo clásico. Antes de comenzar la
migración, asegúrese de que los intervalos de direcciones clásicas dadas se ajusten al formato CIDR válido. Se puede
validar CIDR mediante alguno de los validadores de CIDR habituales. Si se migran sitios locales o redes virtuales con
intervalos de CIDR no válidos, se producirá un estado de error.
Migración de la conectividad de red virtual a red virtual
La conectividad de red virtual a red virtual del modelo clásico se lograba mediante la creación de una
representación en el sitio local de la red virtual conectada. Los clientes tenían que crear dos sitios locales que
representaban las dos redes virtuales que debían estar conectadas entre sí. Después, estos sitios se conectaban
a las redes virtuales correspondientes mediante un túnel IPsec para establecer la conectividad entre ambas
redes virtuales. Este modelo presenta problemas de facilidad de uso, ya que cualquier cambio en el intervalo de
direcciones de una red virtual se debe mantener también en la representación en sitio local correspondiente. En
el modelo de Resource Manager, esta solución ya no es necesaria. La conexión entre ambas redes virtuales se
puede lograr directamente mediante el tipo de conexión "Vnet2Vnet" en el recurso de conexión.
Durante la migración de red virtual, se detecta que la entidad conectada a la puerta de enlace de VPN de la red
virtual actual es otra red virtual. Una vez completada la migración de ambas redes virtuales, asegúrese de que
ya no se vean dos sitios locales que representen la otra red virtual. El modelo clásico con dos puertas de enlace
de VPN, dos sitios locales y dos conexiones entre ellos se transforma en el modelo de Resource Manager con
dos puertas de enlace de VPN y dos conexiones de tipo Vnet2Vnet.
Conectividad de VPN de tránsito

Puede configurar puertas de enlace de VPN en una topología de forma que la conectividad local para una red
virtual se logre mediante la conexión a otra red virtual que esté conectada directamente a un sitio local. Se trata
de la conectividad de VPN de tránsito, en la que las instancias en la primera red virtual se conectan a recursos
locales mediante el tránsito a la puerta de enlace de VPN en la red virtual conectada que está en conexión
directa con el sitio local. Para lograr esta configuración en el modelo de implementación clásica, debe crear un
sitio local que cuente con prefijos agregados que representen tanto la red virtual conectada como el espacio de
direcciones local. Este sitio local de representación se conecta después a la red virtual para lograr la conectividad
de tránsito. Este modelo clásico también presenta problemas de facilidad de uso similares, ya que cualquier
cambio en el intervalo de direcciones local también debe mantenerse en el sitio local que representa la
agregación de la red virtual y el sitio local. La introducción de la compatibilidad con BGP en las puertas de
enlace admitidas por Resource Manager simplifica el uso, ya que las puertas de enlace conectadas pueden
aprender rutas desde el sitio local sin necesidad de modificar los prefijos manualmente.
Puesto que se transforma la conectividad de red virtual a red virtual sin necesidad de sitios locales, el escenario
de tránsito pierde la conectividad local para la red virtual que está conectada de forma indirecta al sitio local. Se
puede mitigar la pérdida de conectividad de las siguientes dos maneras, una vez completada la migración:
Habilite BGP en las puertas de enlace de VPN que están conectadas entre sí y con el sitio local. Al habilitarse
BGP, se restaura la conectividad sin realizar ningún otro cambio de configuración, ya que las rutas se
aprenden y anuncian entre las puertas de enlace de red virtual. Tenga en cuenta que la opción de BGP solo
está disponible en las SKU Estándar y superiores.
Establezca una conexión explícita desde la red virtual afectada hacia la puerta de enlace de red local que
representa la ubicación local. Esto también podría requerir que se cambie la configuración del enrutador
local para crear y configurar el túnel IPsec.
Pasos siguientes
Después de leer sobre la compatibilidad con la migración de puerta de enlace de VPN, vaya a la página sobre la
migración de recursos de IaaS admitida por la plataforma del modelo clásico al de Resource Manager para
empezar.
Preguntas más frecuentes sobre VPN Gateway
Conexión a redes virtuales

¿Puedo conectar redes virtuales en diferentes regiones de Azure?
Sí. De hecho, 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 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 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 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 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 puerta de enlace de VPN, 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, instala un certificado y un paquete de configuración de cliente VPN,
que contiene la configuración que permite 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.
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 el selector de tráfico para las VPN basadas en
enrutamiento se configura como conectividad de tipo cualquiera a cualquier (o caracteres comodín).
¿Puedo actualizar mi puerta de enlace VPN basada en directivas a una basada en el enrutamiento?
No. No se puede cambiar un tipo de puerta de enlace de red virtual de Azure basada en directivas a una basada
en el enrutamiento o viceversa. Es necesario eliminar la puerta de enlace y volver a crearla, un proceso tarda
aproximadamente 60 minutos. La dirección IP de la puerta de enlace no se conserva, ni tampoco la clave
precompartida (PSK).
1. Elimine también las conexiones asociadas a la puerta de enlace que se va a eliminar.
2. Elimine la puerta de enlace:
Azure Portal
Azure PowerShell
Azure PowerShell: clásico
3. Creación de una puerta de enlace del tipo deseado y configuración de VPN completa
¿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?
Como se señaló antes, 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 con 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?
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.
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 configurar una tunelización forzada?
Sí. Consulte Configuración de una tunelización forzada.
¿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. Necesita 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?
S2S.
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?
Para la configuración de sitio a sitio entre locales se admiten los servidores de Windows Server 2012 con
servicio de enrutamiento y acceso remoto (RRAS).
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.
¿Cómo cambiar el tipo de autenticación para las conexiones de punto

a sitio?
Para cambiar el método de autenticación para las conexiones de punto a sitio, vaya a la sección Configuración
de punto a sitio en la VPN Gateway y active el botón de radio que desee. Las opciones actuales son
Cer tificado de Azure, Autenticación RADIUS y Azure Active Director y . Tenga en cuenta que es posible
que los clientes actuales no puedan conectarse después del cambio hasta que el nuevo perfil se haya
descargado y configurado en el cliente.
Punto a sitio mediante la autenticación de certificados de Azure

nativa
Esta sección se aplica al modelo de implementación de Resource Manager.
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI

No.
OpenSSL:
Punto a sitio mediante la autenticación RADIUS

Esta sección se aplica al modelo de implementación de Resource Manager.
Windows 10
Linux (StrongSwan)
iOS
NOTE
con TLS 1.2.
de 2018:


KB3140245
KB2977292
NOTE

que utiliza SSL.
automática?
mismo tiempo?


del Registro en 1.
ella?
Azure PowerShell

Azure CLI
Sí, se admiten.
Conexiones entre dos redes virtuales y multisitio

virtuales.
(AAD)?
inquilinos de AAD.
No.
Azure?
estos escenarios.
PolicyBased?
dinámico).
¿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?
Sí. Para más información, consulte la sección BGP.
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 Red virtual de Azure y Puerta de enlace de VPN
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 de REST para establecer la clave de VPN Gateway o el cmdlet PowerShell para
establecer el valor de clave que prefiera. La clave DEBE estar formada por caracteres ASCII imprimibles.
¿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.
¿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?
Solo se puede especificar 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?
configurar los clientes. Es preciso seleccionar una opción en cada campo.
Grupo DH DHGroup24, ECP384, ECP256, DHGroup14

(DHGroup2048), DHGroup2, DHGroup1, Ninguno

Integridad de IPsec GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1,

MD5
Vigencia de SA QM Segundos (entero; mín. 300 /predeterminado 27000

segundos)
KBytes)
Selector de tráfico UsePolicyBasedTrafficSelectors ($True/$False; default $False)
IMPORTANT
DHGroup2048 y 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 (*)
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
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):

DHGroup2048
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 es compatible con esta operación.
¿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.
¿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
¿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-AzVir tualNetworkGateway y busque la propiedad bgpPeeringAddress . En Azure Portal, en la
página Configuración de puer ta 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 dirección IP de BGP de
APIPA de Azure adicional en la puerta de enlace de VPN de Azure. Azure VPN Gateway selecciona la dirección
de APIPA que se va 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 dirección IP de APIPA BGP en una puerta
de enlace de VPN de Azure, como se describe en el artículo sobre la configuración del protocolo de puerta de
enlace de borde. Especifique esta dirección 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?
IMPORTANT
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. Tendrá 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.
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
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.
Preguntas más frecuentes sobre Virtual Network

Consulte información adicional de redes virtuales adicionales en las Preguntas frecuentes sobre redes virtuales.
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.
Límites, cuotas y restricciones de suscripción y
servicios de Microsoft Azure
Este documento enumeran algunos de los límites más comunes de Microsoft Azure, que a veces se denominan
cuotas.
Consulte Precios de Azure para más información sobre precios de Azure. Allí, puede calcular los costos mediante
el uso de la Calculadora de precios. También puede ir a la página de detalles de precios de un servicio
determinado, por ejemplo, Máquinas virtuales Windows. Si quiere obtener sugerencias para ayudar a
administrar los costos, vea Prevención de costos inesperados con la administración de costos y facturación de
Azure.
Administración de límites
NOTE
Algunos servicios tienen límites ajustables.
Cuando un servicio no tiene límites ajustables, en las tablas siguientes se usa el encabezado Límite . En esos casos, los
límites predeterminado y máximo son los mismos.
Cuando se puede ajustar el límite, las tablas incluyen encabezados de Límite predeterminado y Límite máximo . El
límite se puede aumentar por encima del límite predeterminado, pero no por encima del límite máximo.
Si desea aumentar el límite o la cuota por encima del límite predeterminado, abra una solicitud de soporte técnico al
cliente en línea sin cargo alguno.
Los términos límite flexible y límite máximo se usan a menudo de manera informal para describir el límite ajustable (límite
flexible) y el límite máximo actuales. Si un límite no es ajustable, no hay un límite flexible, solo un límite máximo.
Las suscripciones de evaluación gratuita no son aptas para aumentar el límite ni la cuota. Si tiene una
suscripción de evaluación gratuita, puede actualizar a una suscripción de Pago por uso. Para más información,
consulte Actualización de la suscripción de evaluación gratuita de Azure a pago por uso y Preguntas más
frecuentes sobre la cuenta gratuita de Azure.
Algunos límites se administran a nivel regional.
Usemos las cuotas de vCPU como ejemplo. Para solicitar un aumento de cuota con compatibilidad para vCPU,
debe decidir cuántas vCPU quiere usar en las distintas regiones. A continuación, realice una solicitud específica
para las cuotas de vCPU del grupo de recursos de Azure para las cantidades y regiones que desee. Si necesita
usar 30 vCPU en Oeste de Europa para ejecutar la aplicación allí, deberá solicitar específicamente 30 vCPU en
Oeste de Europa. Su cuota de vCPU no se aumenta en ninguna otra región: solo Oeste de Europa tiene la cuota
de 30 vCPU.
Como resultado, debe decidir cuáles deben ser sus cuotas de grupo de recursos de Azure para la carga de
trabajo en cada región. A continuación, solicite esa cantidad en cada región en la que se desea implementar. Para
obtener ayuda para determinar las cuotas actuales para regiones específicas, consulte Resolución de errores de
cuotas de recursos.
Límites generales
Para conocer los límites de los nombres de recursos, consulte Reglas y restricciones de nomenclatura para los
recursos de Azure.
Para más información sobre los límites de lectura y escritura de Resource Manager API, vea Limitación de
solicitudes de Resource Manager.
Límites de grupo de administración
Los límites siguientes se aplican a los grupos de administración.
RESO URC E L ÍM IT E
Grupos de administración por inquilino de Azure AD 10 000
Suscripciones por grupo de administración Sin límite.
Niveles de jerarquía de grupos de administración Nivel raíz más 6 niveles1
Grupo de administración primario directo por grupo de Uno

administración
Implementaciones de nivel de grupo de administración por 8002

ubicación
1Los 6 niveles no incluyen el nivel de suscripción.

2Si se alcanza el límite de 800
implementaciones, elimine las implementaciones que ya no necesite del historial.
Para eliminar las implementaciones de nivel de grupo de administración, use Remove-
AzManagementGroupDeployment o az deployment mg delete.
Límites de suscripción
Los límites siguientes se aplican cuando se usa Azure Resource Manager y grupos de recursos de Azure.
Suscripciones asociadas a un inquilino de Azure Active Sin límite

Directory
Coadministradores por suscripción Sin límite
Grupos de recursos por suscripción 980
Tamaño de solicitud de API de Azure Resource Manager 4 194 304 bytes
Etiquetas por suscripción1 50
Cálculos de etiquetas únicas por suscripción1 80 000
Implementaciones de nivel de suscripción por ubicación 8002
1Puede aplicar hasta 50 etiquetas directamente a una suscripción. Sin embargo, la suscripción puede contener
un número ilimitado de etiquetas que se aplican a los grupos de recursos y recursos de la misma. El número de
etiquetas por recurso o grupo de recursos se limita a 50. Resource Manager devuelve una lista de valores y
nombres de etiqueta únicos en la suscripción solo cuando haya 80 000 etiquetas, o menos. Sin embargo,
aunque haya más, es posible encontrar un recurso por etiqueta.
2
2Si alcanza el límite de 800
implementaciones, elimine del historial las que no vaya a volver a necesitar. Para
eliminar implementaciones de nivel de suscripción, use Remove-AzDeployment o az deployment sub delete.
Límites de los grupos de recursos
REC URSO L ÍM IT E
Recursos por grupo de recursos Los recursos no están limitados por el grupo de recursos. En
su lugar, están limitados por el tipo de recurso de un grupo
de recursos. Consulte la fila siguiente.
Recursos por grupo de recursos, por tipo de recurso 800: algunos tipos de recursos pueden superar el límite
de 800. Consulte Resources not limited to 800 instances per
resource group (Recursos no limitados a 800 instancias por
grupo de recursos).
Implementaciones por grupo de recursos en el historial de 8001

implementaciones
Recursos por implementación 800
Bloqueos de administración por ámbito único 20
Número de etiquetas por recurso o grupo de recursos 50
Longitud de la clave de etiqueta 512
Longitud del valor de la etiqueta 256
1Las implementaciones se eliminan automáticamente del historial a medida se aproxima al límite. Eliminar una
entrada del historial de implementaciones no afecta a los recursos implementados. Para obtener más
información, consulte Eliminaciones automáticas del historial de implementaciones.
Límites de plantilla
VA L UE L ÍM IT E
Parámetros 256
variables 256
Recursos (incluido el recuento de copia) 800
Salidas 64
Expresión de plantilla 24 576 caracteres
Recursos de plantillas exportadas 200
Tamaño de la plantilla 4 MB
Tamaño del archivo de parámetros 64 KB
Puede superar algunos límites de plantilla utilizando una plantilla anidada. Para más información, consulte Uso
de plantillas vinculadas al implementar recursos de Azure. Para reducir el número de parámetros, variables o
salidas, puede combinar varios valores en un objeto. Para más información, consulte Objetos como parámetros.
Límites de Active Directory
Estas son las restricciones de uso y otros límites de servicio para el servicio Azure Active Directory (Azure AD).
C AT EGO RY L ÍM IT E
Inquilinos Un usuario único puede pertenecer a un máximo de 500

inquilinos de Azure AD como miembro o invitado.
Un usuario único puede crear un máximo de 200 directorios.
Dominios No puede agregar más de 900 nombres de dominio

administrados. Si configura todos los dominios para la
federación con un entorno local de Active Directory, no
puede agregar más de 450 nombres de dominio en cada
inquilino.
Recursos De forma predeterminada, los usuarios de la edición

Gratis de Azure Active Directory pueden crear un
máximo de 50 000 recursos de Azure AD en un solo
inquilino. Si tiene al menos un dominio comprobado,
la cuota de servicio predeterminada de Azure AD se
amplía a 300 000 recursos de Azure AD. La cuota de
servicio de Azure AD para las organizaciones creadas
mediante el registro en modalidad de autoservicio
sigue siendo de 50 000 recursos de Azure AD, incluso
después de que se haya tomado el control de la
administración interna y la organización se haya
convertido en un inquilino administrado con al
menos un dominio verificado. Este límite de servicio
no está relacionado con el límite del plan de tarifa de
500 000 recursos de la página de precios de
Azure AD. Para superar la cuota predeterminada,
debe ponerse en contacto con el servicio de soporte
técnico de Microsoft.
Un usuario que no es administrador puede crear
hasta 250 recursos de Azure AD. Tanto los recursos
activos como los recursos eliminados que están
disponibles para restaurar se contabilizan para esta
cuota. Solo están disponibles para restaurar los
recursos de Azure AD que se han eliminado hace
menos de 30 días. Los recursos de Azure AD
eliminados que ya no están disponibles para
restaurar se contabilizan para esta cuota en un valor
de un cuarto durante 30 días. Si tiene desarrolladores
que probablemente superen repetidamente esta
cuota en el transcurso de sus tareas normales, puede
crear y asignar un rol personalizado con permiso para
crear un número ilimitado de registros de
aplicaciones.
Extensiones de esquema Las extensiones de tipo String pueden tener un

máximo de 256 caracteres.
Las extensiones de tipo Binary están limitadas a 256
bytes.
Solo 100 valores de extensión, entre todos los tipos y
todas las aplicaciones, son los únicos que se pueden
escribir en cualquier recurso de Azure AD único.
Las entidades User, Group, TenantDetail, Device,
Application y ServicePrincipal son las únicas que se
pueden ampliar con atributos de valor único de tipo
String o de tipo Binary.
Las extensiones de esquema solo están disponibles
en la versión preliminar de la versión 1.21 de Graph
API. La aplicación debe tener acceso de escritura para
registrar una extensión.
APLICACIONES Un máximo de 100 usuarios pueden ser propietarios

de una sola aplicación.
La aplicación de inicio de sesión único basada en
contraseña tiene un límite de 48 usuarios, lo que
significa que hay como máximo 48 claves para los
pares de nombre de usuario y contraseña por
aplicación. Si quiere agregar usuarios adicionales,
consulte las instrucciones de solución de problemas
en Solución de problemas de inicio de sesión único
basado en contraseña en Azure AD.
Manifiesto de aplicación Se puede agregar un máximo de 1200 entradas en el

manifiesto de aplicación.
Grupos Un usuario no administrador puede crear un máximo

de 250 grupos en una organización de Azure AD.
Cualquier administrador de Azure AD que pueda
administrar grupos en la organización también puede
crear un número ilimitado de grupos (hasta el límite
de objetos de Azure AD). Si asigna un rol para quitar
el límite de un usuario, asígnelos a un rol integrado
con menos privilegios, como Administrador de
usuarios o Administrador de grupos.
Una organización de Azure AD puede tener un
máximo de 5000 grupos dinámicos.
Un máximo de 100 usuarios pueden ser propietarios
de un solo grupo.
Cualquier número de recursos de Azure AD puede
ser miembro de un solo grupo.
Un usuario puede ser un miembro de cualquier
número de grupos.
De manera predeterminada, el número de miembros
de un grupo que se pueden sincronizar entre la
versión local de Active Directory y Azure Active
Directory mediante Azure AD Connect se limita a 50
000 miembros. Si necesita sincronizar la pertenencia
a un grupo que ha superado este límite, debe
incorporar la API del punto de conexión de Azure AD
Connect Sync V2.
Los grupos anidados de Azure AD no se admiten en
todos los escenarios.
En este momento, los siguientes son los escenarios

admitidos con los grupos anidados.
Se puede agregar un grupo como miembro de otro
grupo, y se puede lograr el anidamiento de grupos.
Notificaciones de pertenencia a grupos (cuando una
aplicación está configurada para recibir notificaciones
de pertenencia a grupos en el token, se incluyen los
grupos anidados en los que usuario que ha iniciado
sesión es miembro)
Acceso condicional (cuando una directiva de acceso
condicional tiene un ámbito de grupo)
Restricción del acceso al restablecimiento de
contraseña de autoservicio
Restricción de los usuarios que pueden realizar la
unión y el registro de dispositivos de Azure AD
Los siguientes escenarios NO se admiten para grupos

anidados:
Asignación de roles de aplicación (se admite la
asignación de grupos a una aplicación, pero los
grupos anidados dentro del grupo asignado
directamente no tendrán acceso), tanto para el
acceso como para el aprovisionamiento
Licencias basadas en grupos (al asignar una licencia
automáticamente a todos los miembros de un grupo)
Microsoft 365 Groups.
Proxy de aplicación Un máximo de 500 transacciones por segundo por

aplicación de proxy de aplicaciones
Un máximo de 750 transacciones por segundo para
la organización de Azure AD
Una transacción se define como una única solicitud y

respuesta http para un único recurso. Cuando se limitan, los
clientes recibirán una respuesta 429 (demasiadas solicitudes).
Panel de acceso No hay límite en el número de aplicaciones que se pueden

ver en el Panel de acceso por usuario, independientemente
de las licencias que se hayan asignado.
Informes Se puede ver o descargar en cualquier informe un máximo

de 1.000 filas. Los datos adicionales se truncan.
Unidades administrativas Un recurso de Azure AD puede ser un miembro de como

máximo 30 unidades administrativas.
Roles y permisos de Azure AD En una organización de Azure AD se puede crear un

máximo de 30 roles personalizados de Azure AD.
No se puede agregar un grupo como propietario del
grupo.
La capacidad de un usuario para leer la información
del inquilino de otros usuarios solo puede restringirse
mediante el modificador de Azure AD para toda la
organización para deshabilitar el acceso de todos los
usuarios no administradores a toda la información
del inquilino (no es recomendable). Para más
información, consulte Restricción de los permisos
predeterminados de los usuarios miembros.
Pueden pasar hasta 15 minutos o el cierre o inicio de
sesión antes de que surtan efecto las adiciones y
revocaciones de los miembros del rol de
administrador.
Límites de API Management

Número máximo de unidades de escalado 10 por región1
Tamaño de memoria caché 5 GiB por unidad2
Conexiones simultáneas de back-end3 por autoridad HTTP 2048 por unidad4
Tamaño máximo de respuestas en caché 2 MiB
Tamaño máximo del documento de directiva 256 KiB5
Dominios de puerta de enlace personalizados máximos por 20

cada instancia de servicio6
Número máximo de certificados de entidad de certificación 10

por instancia de servicio7
Número máximo de instancias de servicio por suscripción8 20
Número máximo de suscripciones por instancia de servicio8 500
Número máximo de certificados de cliente por instancia de 50

servicio8
Número máximo de API por instancia de servicio8 50
Número máximo de operaciones de API por instancia de 1,000

servicio8
Duración total máxima de la solicitud8 30 segundos
Tamaño máximo de carga útil en búfer8 2 MiB
Tamaño máximo de la dirección URL de la solicitud9 4096 bytes
Longitud máxima del segmento de la ruta de acceso de la 260 caracteres

dirección URL10
Tamaño máximo del esquema de API usado por la directiva 4 MB

de validación10
Tamaño máximo del cuerpo de solicitud o respuesta en la 100 KB

directiva de validación de contenido
Número máximo de puertas de enlace autohospedadas11 25
1Los límites de escalado dependen del plan de tarifa. Para ver los planes de tarifa y sus límites de escalado,
consulte Precios de API Management.
2El tamaño de la caché por unidad depende del plan de tarifa. Para ver los planes de tarifa y sus límites de
escalado, vea Precios de API Management.

3Las conexiones se agrupan y se vuelven a utilizar, a menos que el back-end las cierre explícitamente.
4Este límite es por unidad de los planes Básico, Estándar y Premium. El plan de desarrollador está limitado a
1024. Este límite no se aplica al plan de consumo.

5Este límite se aplica a los planes Básico, Estándar y Premium. En el plan de consumo, el tamaño del documento
de directiva se limita a 16 KiB.

6Solo se admiten varios dominios personalizados en los planes Desarrollador y Premium.
7Los certificados de CA no se admiten en el plan de consumo.
8Este límite es aplicable solo al plan de consumo. No hay límites en estas categorías para otros niveles.
9Solo se aplica al plan de consumo. Incluye una cadena de consulta de hasta 2048 bytes de longitud.
10 Para aumentar este límite, póngase en contacto con el soporte técnico.
11Las puertas de enlace autohospedadas solo se admiten en los planes Desarrollador y Premium. El límite se
aplica al número de recursos de puerta de enlace autohospedados. Para aumentar este límite, póngase en
contacto con el departamento de soporte técnico. Tenga en cuenta que el número de nodos (o réplicas)
asociados a un recurso de puerta de enlace autohospedado es ilimitado en el plan Premium y está limitado a un
solo nodo en el plan Desarrollador.
Límites de App Service
Entre los siguientes límites de App Service se incluyen límites para Web Apps, Mobile Apps y API Apps.
P REM IUM
RESO URC E GRAT UITO C O M PA RT IDO B Á SIC O ESTÁ N DA R ( V1- V3) A ISL A DO
Aplicaciones 10 100 Ilimitado2 Ilimitado2 Ilimitado2 Ilimitado2

web, móviles
o de API por
plan de Azure
App Service1
plan de App 10 por región 10 por grupo 100 por 100 por 100 por 100 por
Service de recursos grupo de grupo de grupo de grupo de
recursos recursos recursos recursos
Tipo de Compartido Compartido Dedicado3 Dedicado3 Dedicado3 Dedicado3

instancia de
proceso
Escalar 1 compartido 1 compartido 3 dedicados3 10 20 dedicados 100

horizontalme dedicados3 para v1 y v2; dedicados4
nte (número 30 dedicados
máximo de para v3.3
instancias)
Almacenamie 1 GB5 1 GB5 10 GB5 50 GB5 250 GB5 1 TB5

nto5
Para más de La cuota de
250 GB, envíe almacenamien
una solicitud to disponible
de soporte es de 999 GB.
técnico.
Tiempo de 3 minutos 3 minutos Sin límite, se Sin límite, se Sin límite, se Sin límite, se
CPU (5 paga según paga según paga según paga según
minutos)6 las tarifas las tarifas las tarifas las tarifas
estándar. estándar. estándar. estándar.
Tiempo de 60 minutos 240 minutos Sin límite, se Sin límite, se Sin límite, se Sin límite, se
CPU (día)6 paga según paga según paga según paga según
las tarifas las tarifas las tarifas las tarifas
estándar. estándar. estándar. estándar.
Memoria (1 1024 MB por 1024 MB por N/D N/D N/D N/D

hora) plan de App aplicación
Service
Ancho de 165 MB Ilimitado; se Ilimitado; se Ilimitado; se Ilimitado; se Ilimitado; se

banda aplican tasas aplican tasas aplican tasas aplican tasas aplican tasas
por por por por por
transferencia transferencia transferencia transferencia transferencia
de datos de datos de datos de datos de datos
Arquitectura 32 bits 32 bits 32 bits/64 32 bits/64 32 bits/64 32 bits/64

de la bits bits bits bits
aplicación
P REM IUM
Web Sockets 5 35 350 Sin límite Sin límite Sin límite

por instancia7
Conexiones IP 600 600 Depende del Depende del Depende del 16 000
de salida por tamaño de la tamaño de la tamaño de la
instancia instancia8 instancia8 instancia8
Conexiones 1 1 1 5 5 5
de depurador
simultáneas
por aplicación
Instancias de No No 10 10 10 10
App Service compatible compatible
Certificate
por
suscripción9
Dominios 0 (solo 500 500 500 500 500

personalizado subdominio
s por de
aplicación azurewebsites
.net)
Compatibilida No admitido, No admitido, Conexiones Se incluyen Se incluyen Se incluyen

d con certificado certificado SSL SNI conexiones conexiones conexiones
dominio comodín para comodín para ilimitadas SNI SSL SNI SSL SNI SSL
Compatibilida *.azurewebsit *.azurewebsit ilimitadas y 1 ilimitadas y 1 ilimitadas y 1
d con SSL es.net es.net conexión SSL conexión SSL conexión SSL
disponible de disponible de de IP de IP de IP
forma forma
predetermina predetermina
da. da.
Conexiones 5 por plan 25 por plan 200 por 200 por

híbridas aplicación aplicación
Integración X X X
de Virtual
Network
Puntos de 100 por

conexión aplicación
privados
Equilibrador X X X X X10
de carga
integrado
Restricciones 512 reglas 512 reglas 512 reglas 512 reglas 512 reglas 512 reglas
de acceso por aplicación por aplicación por aplicación por aplicación por aplicación por aplicación
Always On X X X X
P REM IUM
Copias de Copias de Copias de Copias de

seguridad seguridad seguridad seguridad
programadas programadas programadas programadas
cada 2 horas, cada hora, cada hora,
con un con un con un
máximo de máximo de 50 máximo de 50
12 copias de copias de copias de
seguridad al seguridad al seguridad al
día (manuales día (manuales día (manuales
y y y
programadas) programadas) programadas)
. . .
Autoscale X X X
WebJobs11 X X X X X X
Supervisión X X X X
de extremos
Espacios de 5 20 20
ensayo por
aplicación
Testing in X X X
Production
Registros de X X X X X X
diagnóstico
Kudu X X X X X X
Autenticación X X X X X X
y autorización
Certificados X X X X
administrados
de App
Service
(versión
preliminar
pública)12
Contrato de 99,95 % 99,95 % 99,95 % 99,95 %

nivel de
servicio
1Las aplicaciones y las cuotas de almacenamiento son por plan de App Service, a menos que se indique lo
contrario.
2El número real de aplicaciones que puedes hospedar en estas máquinas depende de la actividad de las
aplicaciones, el tamaño de las instancias de máquina y el correspondiente uso de los recursos.

3Las instancias dedicadas pueden tener diferentes tamaños. Para más información, consulte Precios de App
Service.
4Se permiten más a petición.
5
5El límite de almacenamiento es el tamaño total del contenido en todas las aplicaciones en el mismo plan de
App Service. El tamaño total del contenido de todas las aplicaciones en todos los planes de App Service en un
solo grupo de recursos y región no puede superar los 500 GB.
6Estos recursos están limitados por los recursos físicos en las instancias dedicadas (el tamaño de la instancia y el
número de instancias).
7Si se escala una aplicación en el nivel Básico a dos instancias, dispones de 350 conexiones simultáneas para
cada una de las dos. En el nivel Estándar u otro superior, no hay ningún límite teórico para los sockets web, pero
otros factores pueden limitar el número de estos. Por ejemplo, el número máximo de solicitudes simultáneas
permitidas (que define maxConcurrentRequestsPerCpu ) es: 7500 por máquina virtual pequeña, 15 000 por
máquina virtual mediana (7500 x 2 núcleos) y 75 000 por máquina virtual de gran tamaño (18 750 x 4 núcleos).
8 Las conexiones IP máximas se realizan por instancia y dependen del tamaño de la instancia: 1920 por
instancia B1/S1/P1V3, 3968 por instancia B2/S2/P2V3, 8064 por instancia B3/S3/P3V3.
9 El límite de cuota de App Service Certificate por suscripción se puede aumentar a través de una solicitud de
soporte técnico hasta un límite máximo de 200.

10Las SKU de App Service aislado pueden tener equilibrio de carga interno (ILB) con Azure Load Balancer, lo que
significa que no hay conectividad pública desde Internet. Como resultado, algunas características de un App
Service aislado con ILB deben usarse desde máquinas que tienen acceso directo al punto de conexión de red del
ILB.
11 Ejecute scripts o archivos ejecutables personalizados bajo demanda, según una programación o de manera
continua como tarea en segundo plano dentro de su instancia de App Service. Siempre disponible se requiere
para la ejecución continua de Trabajos web. No hay ningún límite predefinido en el número de trabajos web que
se pueden ejecutar en una instancia de App Service. Hay límites prácticos que dependen de lo que el código de
aplicación intente hacer.
12No se admiten los dominios desnudos. Solo se emiten certificados estándar (los certificados comodín no están
disponibles). Está limitado a un solo certificado gratuito por dominio personalizado.
Límites de Automation
Automatización de procesos
REC URSO L ÍM IT E N OTA S
Cantidad máxima de trabajos nuevos 100 Si se alcanza este límite, se producirá

que se puede enviar cada 30 segundos un error en las siguientes solicitudes
por cuenta de Automation (trabajos para crear un trabajo. El cliente recibe
no programados) una respuesta de error.
Cantidad máxima de trabajos en 200 Si se alcanza este límite, se producirá

ejecución simultáneos en la misma un error en las siguientes solicitudes
instancia de tiempo por cuenta de para crear un trabajo. El cliente recibe
Automation (trabajos no una respuesta de error.
programados)
Tamaño máximo de almacenamiento 10 GB (aproximadamente, 4 millones Si se alcanza este límite, se producirá

de metadatos de trabajo para un de trabajos) un error en las siguientes solicitudes
período sucesivo de 30 días para crear un trabajo.
Límite de flujo de trabajo máximo 1 MiB Una sola secuencia no puede mayor
que 1 MiB.
Cantidad máxima de módulos que se 5

puede importar cada 30 segundos por
cuenta de Automation
Tamaño máximo de un módulo 100 MB
Tamaño máximo de un archivo de 1 MB Se aplica a la configuración de estado

configuración de nodo
Tiempo de ejecución de trabajos, nivel 500 minutos por suscripción por mes
Gratis del calendario
Cantidad máxima de espacio en disco 1 GB Se aplica solo a los espacios aislados de

permitida por espacio aislado1 Azure.
Cantidad máxima de memoria que se 400 MB Se aplica solo a los espacios aislados de
asigna a un espacio aislado1 Azure.
Número máximo de sockets de red 1,000 Se aplica solo a los espacios aislados de
permitido por espacio aislado1 Azure.
Tiempo de ejecución máximo 3 horas Se aplica solo a los espacios aislados de

permitido por runbook 1 Azure.
Número máximo de cuentas de Sin límite

Automation en una suscripción
Número máximo de grupos de Hybrid 4.000

Worker por cuenta de Automation
Número máximo de trabajos 50

simultáneos que se pueden ejecutar en
un único Hybrid Runbook Worker
Tamaño máximo de los parámetros de 512 kilobytes

un trabajo de runbook
Parámetros máximos de runbook 50 Si alcanza el límite de 50 parámetros,

puede pasar una cadena JSON o XML
a un parámetro y analizarlo con el
runbook.
Tamaño máximo de carga útil de 512 kilobytes

webhook
Máximo de días que se conservan los 30 días

datos de trabajo
Tamaño máximo del estado de flujo de 5 MB Se aplica a los runbooks del flujo de
trabajo de PowerShell trabajo de PowerShell al aplicar el
punto de control del flujo de trabajo.
1Un espacio aislado es un entorno compartido que puede usarse en varios trabajos. Los trabajos con el mismo
espacio aislado están sujetos a las limitaciones de recursos de dicho espacio.

Change Tracking e Inventario
En la siguiente tabla se muestran los límites del elemento sometido a seguimiento por máquina para el
seguimiento de cambios.
Archivo 500
Registro 250
Software de Windows 250 No se incluye el costo de las

actualizaciones de software.
Paquetes Linux 1250
Servicios 250
Demonio 250
Administración de actualizaciones
En la tabla siguiente se muestran los límites de la administración de actualizaciones.
Número de máquinas por 1000

implementación de actualizaciones
Azure App Configuration

REC URSO L ÍM IT E
Almacenes de configuración: nivel Gratis 1 por suscripción
Almacenes de configuración: nivel Estándar ilimitado para cada suscripción
Solicitudes del almacén de configuración: nivel Gratis 1000 solicitudes por día
Solicitudes del almacén de configuración: nivel Estándar La limitación comienza en las 20 000 solicitudes por hora
Almacenamiento: nivel Gratis 10 MB
Almacenamiento: nivel Estándar 1 GB
Claves y valores 10 KB para un único elemento clave-valor
Límites de Azure Cache for Redis

Tamaño de memoria caché 1,2 TB
Bases de datos 64
Número máximo de clientes conectados 40.000

Réplicas de Azure Cache for Redis, para alta disponibilidad 1
Particiones en una caché premium con agrupación en 10

clústeres
Los tamaños y límite de Azure Cache for Redis son diferentes para cada plan de tarifa. Para ver los planes de
tarifa y sus tamaños asociados, vea los precios de Azure Cache for Redis.
Para información sobre los límites de configuración de Azure Cache for Redis, consulte Configuración
predeterminada del servidor Redis.
Dado que Microsoft realiza la configuración y la administración de instancias de Azure Cache for Redis, no se
admiten todos los comandos de Redis en Azure Cache for Redis. Para más información, consulte Comandos de
Redis que no se admiten en Azure Cache for Redis.
Límites de Azure Cloud Services

Roles web o de trabajo por implementación1 25
Puntos de conexión de entrada de instancia por 25

implementación
Puntos de conexión de entrada por implementación 25
Puntos de conexión internos por implementación 25
Certificados de servicio hospedados por implementación 199
1Cada servicio en la nube de Azure con roles web o de trabajo puede tener dos implementaciones, una para
producción y otra para ensayo. Este límite se refiere al número de roles diferentes, es decir, la configuración. No
hace referencia al número de instancias por rol, es decir, el escalado.
Límites de Azure Cognitive Search

Los planes de tarifa determinan la capacidad y los límites de su servicio de búsqueda. Los planes incluyen:
Gratis , compartido con otros suscriptores de Azure, se ha diseñado para proyectos de evaluación y de
desarrollo de pequeña envergadura.
Básico proporciona recursos informáticos dedicados para cargas de trabajo de producción en una escala
menor, con hasta tres réplicas para cargas de trabajo de consulta de alta disponibilidad.
Estándar incluye S1, S2, S3 y S3 de alta densidad y es para cargas de trabajo de producción mayores.
Existen varios niveles dentro del nivel Estándar para que pueda elegir una configuración de recursos que se
adapte mejor al perfil de la carga de trabajo.
Límites por suscripción
Puede crear varios servicios dentro de una suscripción. Cada uno de ellos se puede aprovisionar en un nivel
concreto. La única limitación es el número de servicios permitidos en cada nivel. Por ejemplo, puede crear hasta
doce servicios en el nivel básico y otros doce en el nivel de S1 dentro de la misma suscripción. Para más
información sobre los niveles, consulte Selección de una SKU o de un plan de tarifa de Azure Cognitive Search.
El límite máximo de servicios se puede elevar a petición. Si necesita tener más servicios en la misma suscripción,
póngase en contacto con el soporte técnico de Azure.
RESO URC GRAT IS 1{

E 3} B Á SIC A S1 S2 S3 S3 H D L1 L2
Servicios 1 16 16 8 6 6 6 6
máximos
Escala N/D 3 36 36 36 36 36 36
máxima unidades unidades unidades unidades unidades unidades unidades
en de de de de de de de
unidades búsqueda búsqueda búsqueda búsqueda búsqueda búsqueda búsqueda
de
búsqueda
(SU)2
1Gratis se basa en recursos compartidos, no dedicados. El escalado vertical no se admite en los recursos
compartidos.
2 Las unidades de búsqueda son unidades facturables, asignadas como réplica o como partición. Ambos
recursos se necesitan para las operaciones de almacenamiento, indexación y consulta. Para más información
sobre los cálculos de SU, consulte Escalado de niveles de recursos para cargas de trabajo de indexación y
consulta en Azure Search.
Límites por ser vicio de búsqueda
El límite de los servicios de búsqueda lo marcan el espacio en disco o por el número máximo de índices o
indexadores, lo que ocurra primero. En la tabla siguiente se documentan los límites de almacenamiento. Para
conocer los límites máximos de los objetos, consulte el artículo en que se especifican los límites por recurso.
RESO URC GRAT UIT

E O B Á SIC O 1 S1 S2 S3 S3 H D L1 L2
Contrato No Sí Sí Sí Sí Sí Sí Sí
de nivel
de
servicio
(SLA)2
Almacena 50 MB 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

miento
por
partición
Particione N/D 1 12 12 12 3 12 12
s por
servicio
Tamaño N/D 2 GB 25 GB 100 GB 200 GB 200 GB 1 TB 2 TB

de la
partición
Réplicas N/D 3 12 12 12 12 12 12
1 Básico tiene una partición fija. Se pueden usar unidades de búsqueda adicionales para agregar réplicas para
volúmenes de consultas mayores.
2 Los contratos de nivel de servicio están en vigor para los servicios facturables en los recursos dedicados. Los
servicios gratuitos y las características de versión preliminar no tienen SLA. Para los servicios facturables, los
SLA tomarán efecto cuando se aprovisione suficiente redundancia para el servicio. Se necesitan dos o más
réplicas para los contrato de nivel de servicio de consulta (lectura). Se necesitan tres o más réplicas para los
contratos de nivel de servicio de consulta e indexación (lectura y escritura). El número de particiones no se tiene
en cuenta en el contrato de nivel de servicio.
Para más información acerca de los límites, como el tamaño de documento, las consultas por segundo, las
claves, las solicitudes y las respuestas, consulte Límites de servicio en Azure Cognitive Search.
Límites de Azure Cognitive Services

Los límites siguientes son para el número de recursos de Cognitive Services por suscripción de Azure. Cada una
de las instancias de Cognitive Services puede tener limitaciones adicionales; para obtener más
información,consulte Azure Cognitive Services.
T IP O L ÍM IT E E JEM P LO
Combinación de recursos de Cognitive Máximo de 200 recursos totales de 100 recursos de Computer Vision en el
Services Cognitive Services. Oeste de EE. UU. 2, 50 recursos de
servicios de voz en el Oeste de EE. UU.
y 50 recursos de Text Analytics en el
Este de EE. UU.
Un solo tipo de recursos de Cognitive Máximo de 100 recursos por región, 100 recursos de Computer Vision en el
Services. con un máximo de 200 de recursos de Oeste de EE. UU. 2 y 100 recursos de
Cognitive Services en total. Computer Vision en el Este de EE. UU.
Límites de Azure Cosmos DB

Para los límites de Azure Cosmos DB, consulte Límites de Azure Cosmos DB.
Límites de Azure Data Explorer

En la tabla siguiente se describen los límites máximos de los clústeres de Azure Data Explorer.
Clústeres por región por suscripción 20
Instancias por clúster 1000
Número de bases de datos en un clúster 10 000
Número de opciones de configuración de la base de datos 70

adjunta en un clúster
En la tabla siguiente se describen los límites de las operaciones de administración realizadas en los clústeres de
Azure Data Explorer.
Á M B ITO O P ERA C IÓ N L ÍM IT E
Clúster lectura (por ejemplo, obtener un 500 por cada 5 minutos

clúster)
Á M B ITO O P ERA C IÓ N L ÍM IT E
Clúster escritura (por ejemplo, crear una base 1000 por hora
de datos)
Azure Database for MySQL

Para obtener más información sobre los límites de Azure Database for MySQL, consulte Limitaciones en Azure
Database for MySQL.
Azure Database for PostgreSQL

Para obtener más información sobre los límites de Azure Database for PostgreSQL, consulte Limitaciones en
Azure Database for PostgreSQL.
Límites de Azure Functions

A Z URE A P P
P L A N DE SERVIC E
REC URSO C O N SUM O P L A N P REM IUM P L A N DEDIC A DO EN VIRO N M EN T K UB ERN ET ES
Duración de 5 30 301 30 30
tiempo de
espera
predeterminada
(min)
Duración 10 sin enlazar7 sin enlazar2 sin enlazar sin enlazar

máxima de
tiempo de
espera (min)
Número máximo 600 activas sin enlazar sin enlazar sin enlazar sin enlazar
de conexiones (1200 en total)
salientes (por
instancia)
Tamaño máximo 100 100 100 100 Depende del

de la clúster
solicitud (MB)3
Longitud 4096 4096 4096 4096 Depende del

máxima de la clúster
cadena de
consulta3
Longitud 8192 8192 8192 8192 Depende del

máxima de URL clúster
de solicitud3
ACU por 100 210-840 100-840 210-2508 Precios de AKS

instancia
Memoria 1.5 3,5-14 1,75-14 3,5-14 Se admite

máxima (GB por cualquier nodo
instancia)
A Z URE A P P
P L A N DE SERVIC E
REC URSO C O N SUM O P L A N P REM IUM P L A N DEDIC A DO EN VIRO N M EN T K UB ERN ET ES
Aplicaciones de 100 100 sin enlazar4 sin enlazar sin enlazar

funciones por
plan
Planes de App 100 por región 100 por grupo 100 por grupo - -
Service de recursos de recursos
Almacenamiento 5 TB 250 GB 50-1000 GB 1 TB N/D

5
Dominios 5006 500 500 500 N/D

personalizados
por aplicación
Compatibilidad conexión SNI SSL conexiones SNI conexiones SNI conexiones SNI N/D
con dominio sin enlazar SSL ilimitadas y 1 SSL ilimitadas y 1 SSL ilimitadas y 1
Compatibilidad incluida conexión SSL de conexión SSL de conexión SSL de
con SSL IP incluidas IP incluidas IP incluidas
1 De manera predeterminada, el tiempo de expiración del runtime de Functions 1.x en un plan de App Service no
está enlazado.
2 Requiere que el plan de App Service se establezca en Always On. Abonar según las tarifas estándar.
3 Estos límites se establecen en el host.
4 El número real de aplicaciones de funciones que puede hospedar depende de la actividad de las aplicaciones,
el tamaño de las instancias de máquina y la utilización de recursos correspondiente.

5 El límite de almacenamiento es el tamaño total del almacenamiento temporal entre todas las aplicaciones en el
mismo plan de App Service. El plan de consumo usa Azure Files para el almacenamiento temporal.
6 Cuando la aplicación de funciones se hospeda en un plan de consumo, solo se admite solo la opción CNAME.
Para aplicaciones de funciones se hospedan en un plan Premium o en un plan de App Service, puede asignar un
dominio personalizado mediante un CNAME o un registro A.
7 Garantizado para un máximo de 60 minutos.
8 Los trabajos son roles que hospedan las aplicaciones del cliente. Los trabajos están disponibles en tres
tamaños fijos: Una CPU virtual/3,5 GB RAM; dos CPU virtuales/7 GB RAM; cuatro CPU virtuales/14 GB RAM.
Para más información, consulte Comparación de los planes de hospedaje de Functions.
Límites de Azure Kubernetes Service

Número máximo de clústeres por suscripción 1000
Número máximo de nodos por clúster con los conjuntos de 100

disponibilidad de máquina virtual y el SKU básico de Load
Balancer
Número máximo de nodos por clúster con Virtual Machine 1000 (100 nodos por grupo de nodos)
Scale Sets y el SKU estándar de Load Balancer
Número máximo de pods por nodo: Redes básicas con 110

Kubenet
Número máximo de pods por nodo: Conexiones de red Implementación de la CLI de Azure: 301
avanzadas con la interfaz de red de contenedor de Azure Plantilla de Azure Resource Manager: 301
Implementación del portal: 30
1Cuando implementa un clúster de Azure Kubernetes Service (AKS) con la CLI de Azure o una plantilla de
Resource Manager, este valor es configurable en hasta 250 pods por nodo. No puede configurar un número
máximo de pods por nodo después de haber implementado un clúster AKS, o si implementa un clúster
mediante Azure Portal.
Límites de Azure Machine Learning

Los valores más recientes para las cuotas de Proceso de Machine Learning pueden encontrarse en la Página de
cuotas de Azure Machine Learning.
Límites de Azure Maps

En la tabla siguiente se muestra el límite de uso del plan de tarifa S0 de Azure Maps. El límite de uso depende
del plan de tarifa.
RESO URC E L ÍM IT E DEL P L A N DE TA RIFA S0
Tasa de solicitud máxima por suscripción 50 solicitudes por segundo
En la tabla siguiente se muestra el límite de tamaño de los datos acumulados en las cuentas de Azure Maps de
una suscripción de Azure. El servicio Data de Azure Maps solo está disponible en el plan de tarifa S1.
Almacenamiento máximo por suscripción de Azure 1 GB
Tamaño máximo por carga de archivos 100 MB
Para obtener más información sobre los planes de tarifa de Azure Maps, vea los precios de Azure Maps.
Límites de Azure Monitor

Alertas
REC URSO L ÍM IT E P REDET ERM IN A DO L ÍM IT E M Á XIM O
Alertas de métricas (clásico) 100 reglas de alertas activas por Llame al soporte técnico.
suscripción.
Alertas de métricas 5000 reglas de alertas activas por Llame al soporte técnico.
suscripción tanto en la nube pública de
Azure, como en las nubes de Azure
China 21Vianet y Azure Government.
Si alcanza este límite, examine si puede
usar alertas de varios recursos del
mismo tipo.
5000 series temporales de métricas
por regla de alertas.
Alertas de registros de actividad 100 reglas de alerta activas por Igual que el predeterminado.
suscripción (este número no se puede
aumentar).
Alertas de registro 512 reglas de alertas activas por Llame al soporte técnico.
suscripción. 200 reglas de alertas
activas por recurso.
Longitud de la descripción de las Alertas de búsqueda de registros: Igual que el predeterminado.

reglas de alertas y las reglas de acción 4096 caracteres
Todas las demás, 2048 caracteres
Grupos de acciones
Inserción de aplicación de Azure 10 acciones de aplicación de Azure por Igual que el predeterminado
grupo de acciones.
Email 1000 acciones de correo electrónico en Igual que el predeterminado

un grupo de acciones.
no más de 100 mensajes de correo
electrónico en una hora.
Consulte también el artículo sobre las
limitaciones de velocidad.
ITSM 10 acciones de ITSM en un grupo de Igual que el predeterminado

acciones.
Aplicación lógica 10 acciones de aplicación lógica en un Igual que el predeterminado

grupo de acciones.
Runbook 10 acciones de runbook en un grupo Igual que el predeterminado

de acciones.
sms 10 acciones de SMS en un grupo de Igual que el predeterminado

acciones.
No más de 1 mensaje de texto cada 5
minutos.
Voz 10 acciones de voz en un grupo de Igual que el predeterminado

acciones.
No más de 1 llamada de voz cada 5
minutos.
webhook 10 acciones de webhook en un grupo Igual que el predeterminado

de acciones. El número máximo de
llamadas de webhook es 1500 por
minuto y suscripción. Están disponibles
otros límites en la información
específica de la acción.
Escalado automático
RESO URC E L ÍM IT E P REDET ERM IN A DO L ÍM IT E M Á XIM O
Opciones de escala automática 100 por región y suscripción. Igual que el predeterminado.
Perfiles de escalado automático 20 perfiles por configuración de Igual que el predeterminado.

escalado automático.
Consultas de registro y lenguaje

Límites generales de las consultas
L ÍM IT E DESC RIP C IÓ N
Lenguaje de consulta Azure Monitor usa el mismo lenguaje de consulta Kusto que
Azure Data Explorer. Consulte las diferencias del lenguaje de
consulta de registros de Azure Monitor para los elementos
del lenguaje KQL que no se admiten en Azure Monitor.
Regiones de Azure Las consultas de registro pueden experimentar una

sobrecarga excesiva cuando los datos abarcan áreas de
trabajo Log Analytics de varias regiones de Azure. Para más
información, consulte Límites de consulta.
Consultas entre recursos El número máximo de recursos de Application Insights y de

áreas de trabajo de Log Analytics en una sola consulta se
limita a 100.
No se admite la consulta entre recursos en el Diseñador de
vistas.
La consulta entre recursos en las alertas de registro se
admite en la nueva API scheduledQueryRules.
Consulte Límites de la consulta entre recursos para obtener
más información.
Limitación de las consultas de usuario

Azure Monitor tiene varios límites para protegerse frente a los usuarios que envían un número excesivo de
consultas. Este comportamiento puede sobrecargar potencialmente los recursos de back-end del sistema y
poner en peligro la capacidad de respuesta del servicio. Los límites siguientes están diseñados para proteger a
los clientes frente a interrupciones y garantizar un nivel de servicio coherente. Los límites y la limitación de
usuarios están diseñados para afectar solo a un escenario de uso extremo y no deben ser de importancia para
un uso normal.
M EA SURE L ÍM IT E P O R USUA RIO DESC RIP C IÓ N
Consultas simultáneas 5 Si ya hay 5 consultas en ejecución para

el usuario, las consultas nuevas se
colocan en una cola de simultaneidad
por usuario. Cuando finaliza una de las
consultas en ejecución, la siguiente
consulta se extrae de la cola y se inicia.
No se incluyen las consultas de reglas
de alertas.
Tiempo en la cola de simultaneidad 3 minutos Si una consulta se encuentra en la cola

durante más de 3 minutos sin iniciarse,
se terminará con una respuesta de
error HTTP con el código 429.
M EA SURE L ÍM IT E P O R USUA RIO DESC RIP C IÓ N
Total de consultas en la cola de 200 Una vez que el número de consultas

simultaneidad en la cola alcanza las 200, las consultas
adicionales se rechazarán con un
código de error HTTP 429. Este
número es adicional a las 5 consultas
que se pueden ejecutar
simultáneamente.
Velocidad de consulta 200 consultas cada 30 segundos Esta es la velocidad global con la que
un solo usuario puede enviar consultas
a todas las áreas de trabajo. Este límite
se aplica a consultas mediante
programación o a consultas iniciadas
por elementos de visualización, como
los paneles de Azure y la página de
resumen del área de trabajo de
Log Analytics.
Optimice las consultas como se describe en Optimización de las consultas de registro en Azure Monitor.
Los paneles y los libros pueden contener varias consultas en una sola vista que generan una ráfaga de
consultas cada vez que se cargan o actualizan. Considere la posibilidad de dividirlos en varias vistas que se
cargan a petición.
En Power BI, considere la posibilidad de extraer solo los resultados agregados en lugar de los registros sin
procesar.
Áreas de trabajo de Log Analytics
Volumen de colección de datos y retención
N IVEL L ÍM IT E P O R DÍA RET EN C IÓ N DE DATO S C O M EN TA RIO
Plan de tarifa actual por GB Sin límite Entre 30 y 730 días La retención de datos más
(Introducido en abril de allá de 31 días está
2018) disponible con cargos
adicionales. Obtenga
información sobre los
precios de Azure Monitor.
Niveles gratis heredados 500 MB 7 días Cuando el área de trabajo

(Introducidos en abril de alcance el límite de 500 MB
2016) por día, la ingesta de datos
se detiene y se reanuda al
comienzo del día siguiente.
Un día se basa en UTC.
Tenga en cuenta que los
datos que recopila Azure
Security Center no se
incluyen en este límite de
500 MB por día y se
seguirán recopilando más
allá de este límite.
Nivel heredado Sin límite De 30 a 730 días La retención de datos más

independiente por GB allá de 31 días está
(Introducidos en abril de disponible con cargos
2016) adicionales. Obtenga
N IVEL L ÍM IT E P O R DÍA RET EN C IÓ N DE DATO S C O M EN TA RIO
Heredado por nodo (OMS) Sin límite De 30 a 730 días La retención de datos más
(Introducidos en abril de allá de 31 días está
2016) disponible con cargos
adicionales. Obtenga
Nivel estándar heredado Sin límite 30 días No se puede ajustar la

retención
Nivel Premium heredado Sin límite 365 días No se puede ajustar la

retención
Número de áreas de trabajo por suscripción.
P L A N DE TA RIFA L ÍM IT E DEL Á REA DE T RA B A JO C O M EN TA RIO S
Nivel Gratis 10 Este límite no se puede aumentar.
Todos los demás niveles Sin límite Está limitado por el número de
recursos de un grupo de recursos y el
número de grupos de recursos por
suscripción.
Azure Por tal
C AT EGO RY L ÍM IT E C O M EN TA RIO S
Número máximo de registros 10 000 Para reducir los resultados, use un

devueltos por una consulta de registro ámbito de consulta, intervalo de
tiempo y filtros en la consulta.
API de recopilador de datos
Tamaño máximo de una sola 30 MB Dividir volúmenes más grandes en

publicación varias publicaciones.
Tamaño máximo de los valores de 32 KB Los campos de más de 32 KB se

campo truncan.
API de búsqueda
Número máximo de registros 500.000

devueltos por una única consulta
Tamaño máximo de los datos 64 000 000 bytes (~61 MiB)

devueltos
Tiempo máximo de ejecución de la 10 minutos Consulte Tiempos de espera para

consulta obtener más detalles.
Velocidad máxima de solicitud 200 solicitudes por 30 segundos por Consulte Límites de velocidad para
dirección IP de cliente o usuario de obtener más detalles.
Azure AD
Búsqueda de Azure Monitor Logs
Número máximo de registros 500.000
Tiempo de espera máximo de las 110 segundos

consultas
Gráficos La visualización en la página Registros

y el conector utilizan diferentes
bibliotecas de gráficos y algunas
funcionalidades no están disponibles
en el conector actualmente.
Límites generales del área de trabajo
Número máximo de columnas en una 500

tabla
Número máximo de caracteres para el 500

nombre de columna
Velocidad de volumen de ingesta de datos

Azure Monitor es un servicio de datos a gran escala que atiende a miles de clientes que envían terabytes de
datos cada mes a un ritmo creciente. Lo que se pretende con el límite de velocidad de volumen es evitar que los
clientes de Azure Monitor tengan clientes de picos de ingesta repentinos en entornos con varios inquilinos. En
las áreas de trabajo se define un umbral de velocidad de volumen de ingesta de datos de 500 MB
(comprimidos), lo que se traduce en, aproximadamente, 6 GB/min sin comprimir (el tamaño real puede variar
entre los tipos de datos en función de la longitud del registro y su relación de compresión). El límite de
velocidad se aplica a los datos ingeridos de recursos de Azure a través de Configuración de diagnóstico. Cuando
se alcanza el límite de velocidad, un mecanismo de reintento intenta ingerir los datos 4 veces en un período
de 30 minutos y quitarlos si se produce algún error en la operación. No se aplica a los datos ingeridos de
agentes ni a Data Collector API.
Cuando la velocidad de los datos enviados a un área de trabajo es superior al 80 % del umbral configurado en
dicha área, se envía un evento a la tabla Operación del área de trabajo cada 6 horas mientras se siga superando
el umbral. Cuando la velocidad de ingesta del volumen supera el umbral, se quitan algunos datos y se envía un
evento a la tabla Operación del área de trabajo cada 6 horas mientras se siga superando el umbral. Si la
velocidad de ingesta del sigue superando el umbral o prevé que lo va a alcanzar pronto, puede abrir una
solicitud de soporte técnico para solicitar su aumento.
Para crear reglas de alerta, con el fin de recibir una notificación cada vez que alcance los límites de ingesta,
consulte Supervisión del estado del área de trabajo de Log Analytics in Azure Monitor.
NOTE
Dependiendo del tiempo que lleve utilizando Log Analytics, es posible que tenga acceso a planes de tarifa heredados.
Obtenga más información sobre los planes de tarifa heredados de Log Analytics.
Application Insights
Hay algunos límites en el número de métricas y eventos por aplicación; es decir, por clave de instrumentación.
Los límites dependen del plan de precios que elija.
RESO URC E L ÍM IT E P REDET ERM IN A DO N OTA :
Total de datos por día 100 GB Se pueden reducir los datos si se

establece un límite. Si necesita más
datos, puede aumentar el límite en el
portal, hasta 1000 GB. Para
capacidades mayores de 1000 GB,
envíe un correo electrónico a
[email protected].
Limitaciones 32 000 eventos por segundo El límite se mide por minuto.
Registros de retención de datos Entre 30 y 730 días Este recurso es para Registros.
Métricas de retención de datos 90 días Este recurso es para el Explorador de

métricas.
Retención de resultados detallados 90 días Este recurso proporciona resultados

para la prueba de disponibilidad de detallados de cada paso.
varios pasos
Tamaño máximo de elementos de 64 KB

telemetría
Número máximo de elementos de 64 K

telemetría por lote
Longitud de nombres de propiedades 150 Consulte esquemas de tipos.

y métricas
Longitud de cadena del valor de 8192 Consulte esquemas de tipos.

propiedad
Longitud del mensaje de seguimiento 32 768 Consulte esquemas de tipos.

y excepción
Número de pruebas de disponibilidad 100

por aplicación
Retención de datos del generador de 5 días

perfiles
Datos enviados por día del generador 10 GB

de perfiles
Para más información, consulte Administración de precios y cuotas para Application Insights.
Límites de Azure Policy
Hay un número máximo de cada tipo de objeto de Azure Policy. Para las definiciones, una entrada de Scope
significa el grupo de administración o la suscripción. En el caso de las asignaciones y exenciones, una entrada de
Scope significa el grupo de administración, la suscripción, el grupo de recursos o el recurso individual.
W H ERE Q UÉ N ÚM ERO M Á XIM O
Ámbito Definiciones de directiva 500
Ámbito Definiciones de iniciativa 200
Inquilino Definiciones de iniciativa 2,500
Ámbito Asignaciones de iniciativas o directivas 200
Ámbito Exenciones 1000
Definición de directiva Parámetros 20
Definición de iniciativa Directivas 1000
Definición de iniciativa Parámetros 100
Asignaciones de iniciativas o directivas Exclusiones (notScopes) 400
Regla de directiva Condicionales anidados 512
Tarea de corrección Recursos 500
Límites de Azure Quantum

Límites y cuotas de proveedor
El servicio Azure Quantum admite proveedores de servicios tanto propios como de terceros. Los proveedores
de terceros poseen sus límites y cuotas. Los usuarios pueden ver las ofertas y los límites de Azure Portal al
configurar proveedores de terceros en la hoja de proveedor.
A continuación puede encontrar los límites de cuota publicados para el proveedor de soluciones de
optimización propio de Microsoft.
SKU Aprender y desarrollar
Trabajos simultáneos basados en CPU Hasta cinco trabajos simultáneos
Trabajos simultáneos basados en FPGA Hasta dos trabajos simultáneos
Horas de solucionador basadas en CPU Veinte horas al mes
Horas de solucionador basadas en FPGA Una hora al mes
Si usa la SKU Aprender y desarrollar, no puede solicitar un aumento de los límites de cuota. En su lugar, debe
cambiar a la SKU Rendimiento a escala.
SKU Rendimiento a escala
Trabajos simultáneos basados en CPU Hasta cien trabajos simultáneos Igual que el límite predeterminado
Trabajos simultáneos basados en FPGA Hasta diez trabajos simultáneos Igual que el límite predeterminado
Horas de solucionador 1000 horas al mes Hasta 50 000 horas al mes
Si necesita solicitar un aumento del límite, póngase en contacto con el soporte técnico de Azure.
Para más información, consulte la página de precios de Azure Quantum. Para información sobre las ofertas de
terceros, consulte la página del proveedor pertinente en Azure Portal.
Límites de control de acceso basado en rol de Azure

REC URSO L ÍM IT E
Asignaciones de roles para recursos de Azure por suscripción 2.000

de Azure
Asignaciones de roles para los recursos de Azure por grupo 500

de administración
Roles personalizados de Azure por inquilino 5.000
Roles personalizados de Azure por inquilino 2.000

(para Azure Germany y Azure China 21Vianet)
Límites de Azure SignalR Service

Unidades de Azure SignalR Service por 1 1

instancia para el nivel Gratis

instancia para el nivel Estándar

suscripción por región para el nivel
Gratis
Recuento total de unidades de Azure 150 Sin límite

SignalR Service por suscripción por
región
Conexiones por unidad por día del 20 20

nivel Gratis
Conexiones por unidad por día del 1,000 1,000

nivel Estándar
Mensajes incluidos por unidad por día 20.000 20.000

del nivel Gratis
Mensajes adicionales por unidad y día 0 0

en el nivel Gratis
Mensajes incluidos por unidad por día 1 000 000 1 000 000
del nivel Estándar
Mensajes adicionales por unidad y día Sin límite Sin límite

en el nivel Estándar
Para solicitar una actualización de los límites predeterminados de la suscripción, abra un vale de soporte técnico.
Límites de Azure VMware Solution

En la tabla siguiente se describen los límites máximos para Azure VMware Solution.
REC URSO L ÍM IT E
Clústeres por nube privada 12
Número mínimo de nodos por clúster 3
Número máximo de nodos por clúster 16
Nodos por nube privada 64
vCenter por nube privada 1
Emparejamientos con sitios de HCX 3 con Advanced Edition, 10 con Enterprise Edition
Máx. de SDDC vinculados a AVS ExpressRoute 4
Velocidad de puerto de AVS ExpressRoute 10 Gbps

La puerta de enlace de red virtual usada determina el ancho
de banda real. Para más detalles, vea Acerca de las puertas
de enlace de red virtual de ExpressRoute.
Direcciones IP públicas expuestas a través de vWAN 100
Límites de capacidad de vSAN 75 % del total que se puede usar (el 25 % restante se
mantiene disponible para el contrato de nivel de servicio)
En el caso de otros límites específicos de VMware, use la herramienta de configuración máxima de VMware.
Límites de Backup
Para obtener un resumen de la configuración y las limitaciones de compatibilidad de Azure Backup, consulte
Matriz de compatibilidad para Azure Backup.
Límites de Batch
Cuentas de Azure Batch por región y 1-3 50

suscripción
Núcleos dedicados por cuenta de 90-900 Ponerse en contacto con soporte

Batch técnico
Núcleos de baja prioridad por cuenta 10-100 Ponerse en contacto con soporte
de Batch técnico
Trabajos activos y programaciones de 100-300 10001

trabajos por cuenta de Batch (los
trabajos completados no tienen
ningún límite)
Grupos por cuenta de Batch 20-100 5001
1 Si quiere solicitar un aumento de este límite, póngase en contacto con el soporte técnico de Azure.
NOTE
Los límites predeterminados varían según el tipo de suscripción que se use para crear una cuenta de Batch. Las cuotas de
núcleos mostradas son para las cuentas de Batch del modo de servicio Batch. Vea las cuotas de su cuenta de Batch.
IMPORTANT
Para ayudarnos a administrar mejor la capacidad durante la pandemia sanitaria global, las cuotas de núcleo
predeterminadas para las nuevas cuentas de Batch en algunas regiones y para algunos tipos de suscripción se han
reducido con respecto al intervalo de valores anterior, en algunos casos a cero núcleos. Al crear una nueva cuenta de
Batch, debe comprobar la cuota de núcleos y solicitar un aumento de la cuota de núcleos si es necesario. Como
alternativa, considere la posibilidad de volver a usar aquellas cuentas de Batch que ya tengan suficiente cuota.
Límites del modelo de implementación clásica

Si usa el modelo de implementación clásico en lugar del modelo de implementación de Azure Resource
Manager, se aplican los límites siguientes.
vCPU por suscripción1 20 10 000
Coadministradores por suscripción 200 200
Cuentas de almacenamiento por 100 100

suscripción2
Servicios en la nube por suscripción 20 200
Redes locales por suscripción 10 500
Servidores DNS por suscripción 9 100

Direcciones IP reservadas por 20 100

suscripción
Grupos de afinidad por suscripción 256 256
Longitud del nombre de la suscripción 64 64

(caracteres)
1Recuento de instancias extrapequeñas como una vCPU hacia el límite de vCPU a pesar de usar un núcleo de
CPU parcial.
2El límite de la cuenta de almacenamiento incluye las cuentas de almacenamiento Estándar y Premium.
Límites de Container Instances

Grupos de contenedores de SKU estándar por región por 1001

suscripción
Grupos de contenedores de SKU dedicados por región por 01

suscripción
Número de contenedores por grupo de contenedor 60
Número de volúmenes por grupo de contenedor 20
Núcleos de SKU estándar (CPU) por región por suscripción 101,2
Núcleos de SKU estándar (CPU) para GPU K80 por región 181,2
por suscripción
Núcleos de SKU estándar (CPU) para GPU P100 o V100 por 01,2
región por suscripción
Puertos por IP 5
Tamaño del registro de instancia de contenedor: instancia en 4 MB

ejecución
Tamaño del registro de instancia de contenedor: instancia 16 KB o 1000 líneas

detenida
Creaciones de contenedores cada hora 3001
Creaciones de contenedores cada 5 minutos 1001
Eliminaciones de contenedores cada hora 3001
Eliminaciones de contenedores cada 5 minutos 1001
1Para solicitar un aumento del límite, cree una solicitud de soporte técnico de Azure. En las suscripciones
gratuitas, como la cuenta gratuita de Azure y Microsoft Azure for Students no se pueden aumentar los límites ni
las cuotas. Si tiene una suscripción gratuita, puede realizar la actualización a una suscripción de Pago por uso.
2Límite predeterminado de la suscripción de Pago por uso. El límite puede variar en otros tipos de categoría.
Límites de Container Registry

En la tabla siguiente se detallan las características y los límites de los niveles de servicio Básico, Estándar y
Premium.
REC URSO B Á SIC O ESTÁ N DA R P REM IUM
Se incluye almacenamiento1 10 100 500

(GiB)
Límite de almacenamiento 20 20 20
(TiB)
Tamaño máximo de la capa 200 200 200

de imagen (GiB)
Operaciones de lectura por 1,000 3000 10 000

minuto2, 3
Operaciones de escritura 100 500 2.000

por minuto2, 4
Ancho de banda de 30 60 100

descarga 2 (Mbps)
Ancho de banda de 10 20 50
carga 2 (Mbps)
webhooks 2 10 500
Replicación geográfica N/D N/D Compatible
Zonas de disponibilidad N/D N/D Versión preliminar
Confianza de contenido N/D N/D Compatible
Vínculo privado con puntos N/D N/D Compatible

de conexión privados
• Puntos de conexión N/D N/D 10

privados
Acceso a red virtual del N/D N/D Versión preliminar

punto de conexión de
servicio
Claves administradas por el N/D N/D Compatible

cliente
Permisos de ámbito de N/D N/D Versión preliminar

repositorio
REC URSO B Á SIC O ESTÁ N DA R P REM IUM
• Tokens N/D N/D 20.000
• Asignaciones de ámbito N/D N/D 20.000
• Repositorios por N/D N/D 500

asignación de ámbito
1 Almacenamiento incluido en la tarifa diaria de cada nivel. Se puede usar

más almacenamiento, hasta el límite
que imponga el almacenamiento del registro, con una tarifa diaria por GiB adicional. Para más información,
consulte Precios de Azure Container Registry. Si necesita más almacenamiento que el que proporciona el límite
de almacenamiento del registro, póngase en contacto con el soporte técnico de Azure.
2ReadOps, WriteOps y ancho de banda son estimaciones mínimas. Azure Container Registry se esfuerza por
mejorar el rendimiento adaptado a su uso.
3docker pull se traduce en varias operaciones de lectura en función del número de capas de la imagen, además
de la recuperación del manifiesto.
4docker push se traduce en varias operaciones de escritura, en función del número de capas que se deben
insertar. Un elemento docker push incluye operaciones de lectura para recuperar un manifiesto para una
imagen existente.
Límites de Content Delivery Network

Perfiles de Azure Content Delivery Network 25
Puntos de conexión de Content Delivery Network por perfil 25
Dominios personalizados por punto de conexión 25
Una suscripción de Content Delivery Network puede contener uno o varios perfiles de Content Delivery
Network. Un perfil de Content Delivery Network puede contener uno o varios puntos de conexión de Content
Delivery Network. Puede que quiera usar varios perfiles para organizar sus puntos de conexión de Content
Delivery Network por dominio de Internet, aplicación web o cualquier otro criterio.
Límites de Data Factory

Azure Data Factory es un servicio multiinquilino que tiene los siguientes límites predeterminados para
asegurarse de que las suscripciones de cliente están protegidas frente a las cargas de trabajo de los demás. Para
elevar los límites al máximo de la suscripción, póngase en contacto con el servicio de soporte técnico.
versión 2
Factorías de datos en una suscripción 800 800

de Azure
Número total de entidades como 5.000 Póngase en contacto con el servicio de

canalizaciones, conjuntos de datos, soporte técnico.
desencadenadores, servicios
vinculados, puntos de conexión
privados y entornos de ejecución de
integración de una factoría de datos
Núcleos de CPU totales para Azure- 256 Póngase en contacto con el servicio de
SSIS Integration Runtime en una soporte técnico.
suscripción
Ejecuciones de canalizaciones 10 000 10 000

simultáneas por factoría de datos
compartida entre todas las
canalizaciones de la factoría
Ejecuciones de actividades externas 3,000 3,000

simultáneas por suscripción por región
de Azure Integration Runtime
Las actividades externas se administran en el
entorno de ejecución de integración, pero se
ejecutan en servicios vinculados, incluidos
Databricks, procedimiento almacenado,
HDInsights, Web, etc. Este límite no se aplica
al entorno de ejecución de integración
autohospedado.
Ejecuciones de actividades de 1,000 1,000

canalización simultáneas por
suscripción por región de Azure
Integration Runtime
Las actividades de canalización se ejecutan
en el entorno de ejecución de integración, lo
que incluye Lookup, GetMetadata y Delete.
Este límite no se aplica al entorno de
ejecución de integración autohospedado.
Operaciones de creación simultáneas 200 200

por suscripción por región de Azure
Integration Runtime
Se incluye la prueba de la conexión, el
examen de las listas de carpetas y tablas y la
vista previa de los datos. Este límite no se
aplica al entorno de ejecución de integración
autohospedado.
Uso de unidades de integración de Grupo de regiones 12 : 6,000 Grupo de regiones 12 : 6,000

datos simultáneas1 por suscripción por Grupo de regiones 22 : 3000 Grupo de regiones 22 : 3000
región de Azure Integration Runtime Grupo de regiones 32 : 1500 Grupo de regiones 32 : 1500
Número máximo de actividades por 40 40

canalización, lo que incluye actividades
internas de contenedores
Número máximo de entornos 100 Póngase en contacto con el servicio de

vinculados de ejecución de integración soporte técnico.
que pueden crearse en un único
entorno de ejecución de integración
autohospedado
Parámetros máximos por canalización 50 50
Elementos ForEach 100 000 100 000
Paralelismo de ForEach 20 50
Número máximo de ejecuciones en 100 100

cola por canalización
Caracteres por expresión 8192 8192
Intervalo mínimo del desencadenador 15 minutos 15 minutos

de ventana de saltos de tamaño
constante
Número máximo de tiempos de 7 días 7 días

expiración de ejecuciones de actividad
de canalización
Bytes por objeto para objetos de 200 KB 200 KB

canalización3

conjunto de datos y de servicio
vinculados3
Bytes por carga para cada ejecución de 896 KB 896 KB

actividad4
Unidades de integración de datos1 por 256 256

ejecución de la actividad de copia
Llamadas API de escritura 1200/h 1200/h
Este límite lo impone Azure Resource

Manager, no Azure Data Factory.
Llamadas API de lectura 12 500/h 12 500/h
Este límite lo impone Azure Resource

Manager, no Azure Data Factory.
Supervisión de consultas por minuto 1,000 1,000
Tiempo máximo de la sesión de 8h 8h

depuración de flujo de datos
Número simultáneo de flujos de datos 50 Póngase en contacto con el servicio de

por entorno de ejecución de soporte técnico.
integración
Número simultáneo de sesiones de 3 3

depuración de flujo de datos por
usuario y fábrica
Límite de TTL de Azure IR de flujo de 4h 4h

datos
1 La unidad de integración de datos (DIU) se usa en una operación de copia de nube a nube, obtenga más
información en Unidades de integración de datos (versión 2). Para obtener información sobre facturación, vea
Precios de Azure Data Factory.
2 Azure Integration Runtime está disponible globalmente para garantizar el cumplimiento de los datos, la
eficacia y los costos de salida de red reducidos.
GRUP O DE REGIO N ES REGIO N S
Grupo de regiones 1 Centro de EE. UU., Este de EE. UU., Este de EE. UU. 2, Norte
de Europa, Oeste de Europa, Oeste de EE. UU., Oeste de
EE. UU. 2
Grupo de regiones 2 Este de Australia, Sudeste de Australia, Sur de Brasil, Centro

de la India, Este de Japón, Centro-norte de EE. UU., Centro-
sur de EE. UU., Sudeste de Asia, Centro-oeste de EE. UU.
Grupo de regiones 3 Otras regiones
3 Los objetos de canalización, de conjunto de datos y de servicio vinculado representan una agrupación lógica
de la carga de trabajo. Los límites de estos objetos no se corresponden con la cantidad de datos que se pueden
mover y procesar con Azure Data Factory. Data Factory está diseñado para escalarse a fin de manejar petabytes
de datos.
4 La carga de cada ejecución de actividad incluye la configuración de la actividad, las configuraciones de los
conjuntos de datos asociados y los servicios vinculados (si los hay), y una pequeña parte de las propiedades del
sistema que se generan por tipo de actividad. Los límites de tamaño de esta carga no se corresponden con la
cantidad de datos que se pueden mover y procesar con Azure Data Factory. Obtenga más información sobre los
síntomas y recomendaciones si se alcanza este límite.
versión 1
Canalizaciones dentro de una factoría 2,500 Póngase en contacto con el servicio de

de datos soporte técnico.
Conjuntos de datos dentro de una 5.000 Póngase en contacto con el servicio de

factoría de datos soporte técnico.
Fragmentos simultáneos por conjunto 10 10

de datos

canalización1

conjunto de datos y de servicio
vinculado1
Núcleos de clúster a petición de Azure 60 Póngase en contacto con el servicio de

HDInsight con una suscripción2 soporte técnico.
Unidades de movimiento de datos en 32 32

la nube por ejecución de actividad de
copia3
Número de reintentos de ejecuciones 1,000 MaxInt (32 bits)

de la actividad Canalización
1 Los objetos de canalización, de conjunto de datos y de servicio vinculado representan una agrupación lógica
de la carga de trabajo. Los límites de estos objetos no se corresponden con la cantidad de datos que se pueden
mover y procesar con Azure Data Factory. Data Factory está diseñado para escalarse a fin de manejar petabytes
de datos.
2Los núcleos de HDInsight a petición se asignan fuera de la suscripción que contiene Data Factory. Como
resultado, el límite anterior es el límite de núcleos aplicado por Data Factory para los núcleos de HDInsight a
petición. Es diferente al límite de núcleos asociado a la suscripción de Azure.
3 La unidad de movimiento de datos en la nube (DMU) para la versión 1
se usa en una operación de copia de
nube a nube, obtenga más información en Unidades de movimiento de datos de nube (versión 1). Para obtener
información sobre facturación, vea Precios de Azure Data Factory.
REC URSO L ÍM IT E IN F ERIO R P REDET ERM IN A DO L ÍM IT E M ÍN IM O
Intervalo de programación 15 minutos 15 minutos
Intervalo entre reintentos 1 segundo 1 segundo
Valor de tiempo de espera de 1 segundo 1 segundo

reintento
Límites de llamadas de servicio web

Azure Resource Manager tiene límites para las llamadas de API. Se pueden realizar llamadas API a un ritmo que
esté dentro de los límites de la API del Administrador de recursos de Azure.
Límites de Data Lake Analytics

Azure Data Lake Analytics facilita la compleja tarea de administrar infraestructuras distribuidas y códigos
complicados. Además, aprovisiona los recursos de forma dinámica y se puede usar para realizar análisis sobre
exabytes de datos. Cuando finaliza el trabajo, los recursos se reducen automáticamente. Solo se paga por la
capacidad de procesamiento empleada. Conforme aumenta o disminuye el tamaño de los datos almacenados o
la cantidad de proceso utilizado, no tiene que reescribir código. Para elevar los límites predeterminados de la
suscripción, póngase en contacto con el soporte técnico.
REC URSO L ÍM IT E C O M EN TA RIO S
Número máximo de trabajos 20

simultáneos
Número máximo de unidades de 250 Use cualquier combinación de hasta un

análisis (AU) por cuenta máximo de 250 unidades de análisis
entre 20 trabajos. Para aumentar este
límite, póngase en contacto con el
servicio de soporte técnico de
Microsoft.
Tamaño máximo del script para el 3 MB

envío de trabajos
Número máximo de cuentas de Data 5 Para aumentar este límite, póngase en

Lake Analytics por región y suscripción contacto con el servicio de soporte
Límites de Data Lake Storage

Azure Data Lake Storage Gen2 no es un servicio dedicado ni un tipo de cuenta de almacenamiento. Es la
versión más reciente de las funcionalidades dedicadas al análisis de macrodatos. Estas funcionalidades están
disponibles en una cuenta de almacenamiento de uso general v2 o de BlockBlobStorage, y para obtenerlas se
debe habilitar la característica Espacio de nombres jerárquico de la cuenta. Para conocer los objetivos la
escala, consulte estos artículos.
Objetivos de escala de Blob Storage.
Objetivos de escala de las cuentas de almacenamiento estándar.
Azure Data Lake Storage Gen1 es un servicio dedicado. Es un repositorio de gran escala en toda la empresa
para cargas de trabajo de análisis de macrodatos. Puede usar Data Lake Storage Gen1 para capturar datos de
cualquier tamaño, tipo y velocidad de ingesta en un único lugar para realizar análisis exploratorios y operativos.
No hay ningún límite en cuanto a la cantidad de datos que puede almacenar en una cuenta de Data Lake
Storage Gen1.
REC URSO L IM IT C O M EN TA RIO S
Número máximo de cuentas de Data 10 Para solicitar un aumento de este

Lake Store Gen1, por suscripción y por límite, póngase en contacto con el
región soporte técnico.
Número máximo de ACL de acceso, 32 Se trata de un límite máximo. Use

por archivo o carpeta grupos para administrar el acceso con
menos entradas.
Número máximo de ACL 32 Se trata de un límite máximo. Use

predeterminadas, por archivo o grupos para administrar el acceso con
carpeta menos entradas.
Límites de Data Share

Azure Data Share permite a las organizaciones compartir datos de forma simple y segura con sus clientes y
asociados.
REC URSO L ÍM IT E
Número máximo de recursos de Data Share por suscripción 100

de Azure
Número máximo de recursos compartidos enviados por 200

recurso de Data Share
Número máximo de recursos compartidos recibidos por 100

recurso de Data Share
Número máximo de invitaciones por recurso compartido 200

enviado
Número máximo de suscripciones a recursos compartidos 200

por recurso compartido enviado
Número máximo de conjuntos de datos por recurso 200

compartido
Número máximo de programaciones de instantáneas por 1

recurso compartido
Límites de Database Migration Service

Azure Database Migration Service es un servicio totalmente administrado diseñado para permitir migraciones
completas desde varios orígenes de base de datos hasta las plataformas de datos de Azure con un tiempo de
inactividad mínimo.
- RESO URC E L IM IT C O M EN TA RIO S
Número máximo de servicios por 10 Para solicitar un aumento de este

suscripción por región límite, póngase en contacto con el
soporte técnico.
Límites de Digital Twins

NOTE
Algunas áreas de este servicio tienen límites ajustables y otras no. Esto se representa en las tablas siguientes con la
columna ¿Ajustable? . Cuando se puede ajustar el límite, el valor de ¿Ajustable? es Sí.
Límites funcionales
En la tabla siguiente se enumeran los límites funcionales de Azure Digital Twins.
TIP
Para conocer las recomendaciones de modelado que operan dentro de estos límites funcionales, consulte Procedimientos
recomendados para diseñar modelos.
Á REA C A PA C IDA D L ÍM IT E P REDET ERM IN A DO ¿A JUSTA B L E?
Recurso de Azure Número de instancias de 10 Sí

Azure Digital Twins en una
región por suscripción
Gemelos digitales Número de gemelos de una 200 000 Sí

instancia de Azure Digital
Twins
Gemelos digitales Número de relaciones 5.000 No

entrantes en un solo
gemelo
Gemelos digitales Número de relaciones de 5.000 No

salida de un solo gemelo
Gemelos digitales Tamaño máximo (del cuerpo 32 KB No

JSON en una solicitud PUT
o PATCH) de un solo
gemelo
Gemelos digitales Tamaño máximo de carga 32 KB No

de solicitud
Enrutamiento Número de puntos de 6 No

conexión de una instancia
de Azure Digital Twins
Enrutamiento Número de rutas de una 6 Sí

Twins
Modelos Número de modelos de una 10 000 Sí

Twins
Modelos Número de modelos que se 250 No

pueden cargar en una única
llamada a la API
Modelos Tamaño máximo (del cuerpo 1 MB No

JSON en una solicitud PUT
o PATCH) de un solo
modelo
Modelos Número de elementos 100 No

devueltos en una única
página
Consultar Número de elementos 100 Sí

devueltos en una única
página
Consultar Número de expresiones 50 Sí

AND / OR de una
consulta
Á REA C A PA C IDA D L ÍM IT E P REDET ERM IN A DO ¿A JUSTA B L E?
Consultar Número de elementos de 50 Sí

matriz de una cláusula IN
/ NOT IN
Consultar Número de caracteres de 8,000 Sí

una consulta
Consultar Número de JOINS de una 5 Sí

consulta
Límites de frecuencia
En la tabla siguiente se reflejan los límites de frecuencia de distintas API.
API C A PA C IDA D L ÍM IT E P REDET ERM IN A DO ¿A JUSTA B L E?
API de modelos Número de solicitudes por 100 Sí

segundo
API de Digital Twins Número de solicitudes por 2.000 Sí

segundo
API de Digital Twins Número de operaciones de 50 Sí

creación y eliminación por
segundo en todos los
gemelos y las relaciones
API de Digital Twins Número de operaciones de 10 No

creación, actualización y
eliminación por segundo en
un único gemelo o sus
relaciones
API de consulta Número de solicitudes por 500 Sí

segundo
API de consulta Unidades de consulta por 4.000 Sí

segundo
API de rutas de eventos Número de solicitudes por 100 Sí

segundo
Otros límites
Los límites de los tipos de datos y los campos de los documentos de DTDL para los modelos de Azure Digital
Twins se pueden encontrar en la documentación de la especificación en GitHub: Lenguaje de definición de
Digital Twins (DTDL): versión 2.
Los detalles de la latencia de consulta y otras limitaciones de consulta se pueden consultar en Consulta del grafo
de gemelos.
Límites de Event Grid

Los siguientes límites se aplican a los temas de Azure Event Grid (temas del sistema, personalizados y de
asociados).
Temas personalizados por suscripción de Azure 100
Suscripciones de eventos por tema 500
Velocidad de publicación de un tema personalizado o de 5000 eventos por segundo o 5 MB por segundo (lo que se
asociado (entrada) cumpla primero)
Tamaño del evento 1 MB
Conexiones de punto de conexión privado por tema 64
Reglas de firewall de IP por tema 16
Los límites siguientes se aplican a los dominios de Azure Event Grid.
Temas por dominio de eventos 100 000
Suscripciones de eventos por tema dentro de un dominio 500
Suscripciones de eventos del ámbito de dominio 50
Tasa de publicación para un dominio de eventos (entrada) 5000 eventos por segundo o 5 MB por segundo (lo que se
cumpla primero)
Dominios de eventos por suscripción de Azure 100
Conexiones de punto de conexión privado por dominio 64
Reglas de firewall de IP por dominio 16
Límites de Event Hubs

En las tablas siguientes se enumeran las cuotas y los límites específicos de Azure Event Hubs. Para más
información sobre los precios de Event Hubs, consulte los precios de Event Hubs.
Límites comunes para todos los niveles
Los límites siguientes son comunes en todos los niveles.
L ÍM IT E N OTA S VA L UE
Número de espacios de nombres de - 100

Event Hubs por suscripción
Número de centros de eventos por Las solicitudes posteriores para la 10

espacio de nombres creación de un nuevo centro de
eventos se rechazan.
Tamaño del nombre de un centro de - 256 caracteres

eventos
L ÍM IT E N OTA S VA L UE
Tamaño del nombre de un grupo de - 256 caracteres

consumidores
Número de destinatarios no de época - 5

por grupo de consumidores
Número de reglas de autorización por Las solicitudes posteriores de creación 12

espacio de nombres de reglas de autorización se rechazan.
Número de llamadas al método - 50 por segundo

GetRuntimeInformation
Número de redes virtuales (VNet) - 128
Número de reglas de configuración de - 128

IP
Niveles Básico y Estándar

En la tabla siguiente se muestran los límites que pueden ser diferentes para los niveles básico y estándar.
L ÍM IT E N OTA S B Á SIC O ESTÁ N DA R
Tamaño máximo de la 256 KB 1 MB

publicación de Event Hubs
Número de grupos de 1 20
consumidores por centro de
eventos
Número de conexiones de Las solicitudes posteriores 100 5.000

AMQP por espacio de de conexiones adicionales
nombres se rechazan y el código que
llama recibe una excepción.
Período de retención 1 día 1-7 días

máximo de datos de
eventos
Unidades de rendimiento Si se supera este límite, los 20 20

máximo datos se limitan y se genera
un excepción por servidor
ocupado. Para solicitar un
número mayor de unidades
de procesamiento para el
nivel Estándar rellene una
solicitud de soporte técnico.
Las unidades de
rendimiento adicionales se
encuentran disponibles en
bloques de 20 y están
sujetas a un compromiso de
compra.
Número de particiones por 32 32

centro de eventos
NOTE
Los eventos se pueden publicar de forma individual o por lotes. El límite de publicación (según la SKU) se aplica
independientemente de si se trata de un evento único o un lote. Se rechazará la publicación de eventos que superen el
umbral máximo.
Nivel dedicado frente a nivel estándar

La oferta de Event Hubs dedicado se factura aplicando una tarifa mensual fija con un uso mínimo de 4 horas. El
nivel Dedicado ofrece todas las características del plan Estándar, pero con una capacidad de escalado de nivel
empresarial para aquellos clientes que tienen cargas de trabajo muy exigentes.
Consulte este documento, en el que se explica cómo crear un clúster de Event Hubs dedicado mediante Azure
Portal.
C A RA C T ERÍST IC A ESTÁ N DA R DEDIC A DO
Ancho de banda 20 TU (hasta 40 TU) 20 CU
Espacios de nombres 1 50 por CU
Event Hubs 10 por espacio de nombres 1000 por espacio de nombres
Eventos de entrada Pago por millones de eventos Se incluye
Tamaño de los mensajes 1 millón de bytes 1 millón de bytes
Particiones 32 por centro de eventos 1024 por centro de eventos

2000 por CU
Grupos de consumidores 20 por centro de eventos Sin límite por CU, 1000 por centro de
eventos
Conexiones asincrónicas 1000 incluidas, 5000 como máximo 100 000 incluidos y como máximo
Retención de mensajes 7 días, 84 GB incluidas por TU 90 días, 10 TB incluidas por TU
Capturar Pago por hora Se incluye
Limitaciones del registro de esquema

Límites que son iguales para los niveles estándar y dedicado
C A RA C T ERÍST IC A L ÍM IT E
Longitud máxima de un nombre de grupo de esquemas 50
Longitud máxima de un nombre de esquemas 100
Tamaño, en bytes, por esquema 1 MB
Número de propiedades por grupo de esquemas 1024
Tamaño, en bytes, por clave de propiedad del grupo 256

C A RA C T ERÍST IC A L ÍM IT E
Tamaño, en bytes, por valor de propiedad del grupo 1024
Límites que son distintos para los niveles estándar y dedicado
L ÍM IT E ESTÁ N DA R DEDIC A DO
Tamaño del registro de esquema 25 1024

(espacio de nombres), en megabytes
Números de grupos de esquemas en 1: sin incluir el grupo predeterminado 1000

un registro de esquemas o un espacio
de nombres
Número de versiones del esquema en 25 10000

todos los grupos de esquemas
Límites de IoT Central

IoT Central limita el número de aplicaciones que se pueden implementar en una suscripción a diez. Si quiere
aumentar este límite, póngase en contacto con el soporte técnico de Microsoft.
Límites de IoT Hub

En la tabla siguiente se enumeran los límites asociados a los diferentes niveles de servicio (S1, S2, S3 y F1). Para
información sobre el costo de cada unidad en cada nivel, consulte los Precios de IoT Hub.
RESO URC E S1 ESTÁ N DA R S2 ESTÁ N DA R S3 ESTÁ N DA R F 1 GRAT IS
Mensajes por día 400.000 6.000.000 300.000.000 8,000
Unidades máximas 200 200 10 1
NOTE
Si prevé usar más de 200 unidades con un centro de nivel S1 o S2, o 10 unidades con un centro de nivel S3, póngase en
contacto con el servicio de soporte técnico de Microsoft.
En la tabla siguiente se enumeran los límites que se aplican a los recursos de IoT Hub:
Cantidad máxima de Centros de IoT de pago por suscripción 50

a Azure
Cantidad máxima de Centros de IoT gratis por suscripción a 1

Azure
Número máximo de caracteres incluido en un identificador 128

de dispositivo
Número máximo de identidades del dispositivo 1,000

devueltas en una sola llamada
Retención máxima de mensajes de IoT Hub para los 7 días

mensajes de dispositivo a la nube
Tamaño máximo de mensaje del dispositivo a la nube 256 KB
Tamaño máximo de lote de dispositivo a la nube AMQP y HTTP: 256 KB para todo el lote
MQTT: 256 KB por cada mensaje
Número máximo de mensajes en lote del dispositivo a la 500

nube
Tamaño máximo de mensaje de nube a dispositivo 64 KB
TTL máximo para los mensajes de nube a dispositivo 2 días
Número máximo de entregas para los mensajes de nube a 100

dispositivo
messages
Profundidad máxima de la cola de la nube al dispositivo por 50

dispositivo
Número máximo de entregas de mensajes de comentarios 100

en respuesta a un mensaje de nube a dispositivo
TTL máximo para los mensajes de comentarios en 2 días

respuesta a un mensaje de nube a dispositivo
Tamaño máximo del dispositivo gemelo 8 KB para la sección etiquetas y 32 KB para las secciones de
propiedades deseadas y notificadas
Longitud máxima de la clave de cadena del dispositivo 1 KB

gemelo
Longitud máxima del valor de cadena del dispositivo gemelo 4 KB
Profundidad máxima del objeto en el dispositivo gemelo 10
Tamaño máximo de carga del método directo 128 KB
Retención máxima del historial de trabajos 30 días
Número máximo de trabajos simultáneos 10 (para S3), 5 para (S2), 1 (para S1)
Número máximo de puntos de conexión adicionales 10 (para S1, S2 y S3)
Número máximo de reglas de enrutamiento de mensajes 100 (para S1, S2 y S3)

Número máximo de secuencias de dispositivos conectados 50 (solo para S1, S2, S3 y F1)
simultáneamente
Nivel máximo de transferencia de datos de secuencia de 300 MB por día (solo para S1, S2, S3 y F1)
dispositivos
NOTE
Si necesita más de 50 centros de IoT de pago en una suscripción de Azure, póngase en contacto con el servicio de
soporte técnico de Microsoft.
NOTE
Actualmente, el número total de dispositivos más módulos que es posible registrar en un único centro de IoT se limita a 1
millón. Si quiere aumentar este límite, póngase en contacto con el soporte técnico de Microsoft.
El servicio IoT Hub limita las solicitudes cuando se superan las cuotas siguientes:
L IM ITA C IÓ N VA LO R P O R C EN T RO
Operaciones de registro de identidad 83,33/s/unidad (5000/min/unidad) (para S3).

(crear, recuperar, enumerar, actualizar, eliminar), 1,67/s/unidad (100/min/unidad) (para S1 y S2).
importación y exportación masiva o individual
Conexiones de dispositivos 6000/s/unidad (para S3), 120/s/unidad (para S2),

12/s/unidad (para S1).
Mínimo de 100/s.
Envíos de dispositivo a nube 6000/s/unidad (para S3), 120/s/unidad (para S2),

12/s/unidad (para S1).
Mínimo de 100/s.
Envíos de nube a dispositivo 83,33/s/unidad (5000/min/unidad) (para S3), 1,67/s/unidad

(100/min/unidad) (para S1 y S2).
Recepciones de nube a dispositivo 833,33/s/unidad (50 000/min/unidad) (para S3),

16,67/s/unidad (1000/min/unidad) (para S1 y S2).
Operaciones de carga de archivos Iniciaciones de carga de 83,33 archivos/s/unidad

(5000/min/unidad) (para S3), iniciaciones de carga de 1,67
archivos/s/unidad (100/min/unidad) (para S1 y S2).
Puede haber 10 000 URI de SAS fuera para una cuenta de
Azure Storage al mismo tiempo.
10 URI/dispositivo de SAS puede estar fuera al mismo
tiempo.
Métodos directos 24 MB/s/unidad (para S3), 480 KB/s/unidad (para S2),

160 KB/s/unidad (para S1).
Según un tamaño de medidor de limitación de 8 KB.
Lecturas de dispositivos gemelos 500/s/unidad (para S3), 100/s o 10/s/unidad como máximo
(para S2), 100/s (para S1)
L IM ITA C IÓ N VA LO R P O R C EN T RO
Actualizaciones de dispositivos gemelos 250/s/unidad (para S3), 50/s o 5/s/unidad como máximo
(para S2), 50/s (para S1)
Operaciones de trabajos 83,33/s/unidad (5000/min/unidad) (para S3), 1,67/s/unidad

(crear, actualizar, enumerar, eliminar) (100/min/unidad) (para S2), 1,67/s/unidad (100/min/unidad)
(para S1).
Resultado de operaciones por dispositivo de trabajos 50/s/unidad (para S3), 10/s o 1/s/unidad como máximo
(para S2), 10/s (para S1).
Velocidad de iniciación de secuencia de dispositivos 5 nuevas secuencias/s (solo para S1, S2, S3 y F1).
Límites de servicio IoT Hub Device Provisioning

En la tabla siguiente se enumeran los límites que se aplican a los recursos de Azure IoT Hub Device Provisioning
Service.
Servicios máximos de aprovisionamiento de dispositivos por 10

suscripción de Azure
Número máximo de inscripciones 1 000 000
Número máximo de registros 1 000 000
Número máximo de grupos de inscripciones 100
Número máximo de CA 25
Número máximo de centros de IoT vinculados 50
Tamaño máximo de mensaje 96 KB
NOTE
Para aumentar el número de inscripciones y registros del servicio de aprovisionamiento, póngase en contacto con Soporte
NOTE
No se puede aumentar el número máximo de entidades de certificación.
El servicio de aprovisionamiento de dispositivos limita las solicitudes cuando se superan las cuotas siguientes.
L IM ITA C IÓ N VA LO R P O R UN IDA D
Operaciones 200/min/servicio
Registros de dispositivos 200/min/servicio

L IM ITA C IÓ N VA LO R P O R UN IDA D
Operación de sondeo de dispositivos 5/10 s/dispositivo
Límites de Key Vault

El servicio Azure Key Vault admite dos tipos de recursos: almacenes y HSM administrados. En las dos secciones
siguientes se describen los límites de servicio para cada uno de ellos, respectivamente.
Tipo de recurso: almacén
En esta sección se describen los límites de servicio para el tipo de recurso vaults .
Transacciones clave (n.º máximo de transacciones permitidas en 10 segundos, por almacén y región 1):
C L AVE H SM C L AVE DE SO F T WA RE
C L AVE H SM L A S RESTA N T ES C L AVE DE SO F T WA RE L A S RESTA N T ES
T IP O DE C L AVE C L AVE C REAT E T RA N SA C C IO N ES C L AVE C REAT E T RA N SA C C IO N ES
2048 bits de RSA 5 1,000 10 2.000
3072 bits de RSA 5 250 10 500
4096 bits de RSA 5 125 10 250
ECC P-256 5 1,000 10 2.000
ECC P-384 5 1,000 10 2.000
ECC P-521 5 1,000 10 2.000
ECC SECP256K1 5 1,000 10 2.000
NOTE
En la tabla anterior, vemos que para las claves de software de 2048 bits RSA, se permiten 2000 transacciones GET cada
10 segundos. Para las claves HSM de 2048 bits RSA, se permiten 1000 transacciones GET cada 10 segundos.
Los umbrales de limitación se ponderan y el cumplimiento se basa en su suma. Por ejemplo, como se ha mostrado en la
tabla anterior, al realizar operaciones GET en las claves HSM RSA, resulta ocho veces más costoso usar claves de 4096 bits
en comparación con las claves de 2048 bits. Eso es porque 1000/125 = 8.
En un intervalo determinado de 10 segundos, un cliente de Azure Key Vault solo puede realizar una de las siguientes
operaciones antes de encontrar un código de estado HTTP de limitación 429 :
2000 transacciones GET de clave de software de 2048 bits RSA
1000 transacciones GET de clave HSM de 2048 bits RSA
125 transacciones GET de clave HSM de 4096 bits RSA
124 transacciones GET de clave HSM de 4096 bits y 8 transacciones GET de clave HSM de 2048 bits RSA
Secretos, claves de cuentas de almacenamiento administradas y transacciones de almacén:

N . º M Á XIM O DE T RA N SA C C IO N ES P ERM IT IDA S EN 10
T IP O DE T RA N SA C C IO N ES SEGUN DO S, P O R A L M A C ÉN Y REGIÓ N 1
Todas las transacciones 2.000
Vea la Guía de las limitaciones de Azure Key Vault para obtener información sobre cómo controlar la limitación
cuando se superan estos límites.
1 Un límite global para la suscripción para todos los tipos de transacciones es cinco veces el límite del almacén
de claves. Por ejemplo, en las otras transacciones HSM por suscripción, el límite es de 5000 transacciones en
10 segundos por suscripción.
Integración de Azure Private Link
NOTE
El número de almacenes de claves con puntos de conexión privados habilitados por suscripción es un límite ajustable. El
límite que se muestra a continuación es el límite predeterminado. Si desea solicitar un aumento del límite para su servicio,
envíe un correo electrónico a [email protected]. Estas solicitudes se aprobarán caso por caso.
REC URSO L ÍM IT E
Puntos de conexión privados por almacén de claves 64
Almacenes de claves con puntos de conexión privados por 400

suscripción
Tipo de recurso: HSM administrado (versión preliminar)

En esta sección se describen los límites de servicio para el tipo de recurso managed HSM .
Límites de objetos
EL EM EN TO L ÍM IT ES
Número de instancias de HSM por suscripción por región 1 (durante la versión preliminar)
Número de claves por grupo de HSM 5000
Número de versiones por clave 100
Número de definiciones de roles personalizados por HSM 50
Número de asignaciones de roles en el ámbito de HSM 50
Número de asignación de roles en cada ámbito de clave 10

individual
Límites de transacciones para operaciones administrativas (número de operaciones por segundo por instancia de HSM)
O P ERA C IÓ N N ÚM ERO DE O P ERA C IO N ES P O R SEGUN DO.
Todas las operaciones de RBAC 5

(incluye todas las operaciones CRUD para las definiciones de
roles y las asignaciones de roles)
O P ERA C IÓ N N ÚM ERO DE O P ERA C IO N ES P O R SEGUN DO.
Copia de seguridad/restauración completa de HSM 1

(solo se admite una operación simultánea de copia de
seguridad o restauración por instancia de HSM)
Límites de transacciones para operaciones criptográficas (número de operaciones por segundo por instancia de HSM)
Cada instancia de HSM administrada constituye tres particiones de HSM con equilibrio de carga. Los límites
de rendimiento son una función de la capacidad de hardware subyacente que se asigna a cada partición. Las
tablas siguientes muestran el rendimiento máximo con al menos una partición disponible. El rendimiento
real puede ser hasta tres veces superior si están disponibles las tres particiones.
Los límites de rendimiento indicados suponen que se utiliza una sola clave para lograr el máximo
rendimiento. Por ejemplo, si se usa una única clave RSA-2048, el rendimiento máximo será de
1100 operaciones de firma. Si utilizan 1100 claves diferentes con una transacción por segundo, no podrán
lograr el mismo rendimiento.
O p e r a c i o n e s d e c l a v e R SA (n ú m e r o d e o p e r a c i o n e s p o r se g u n d o p o r i n st a n c i a H SM )
O P ERA C IÓ N 2048 B IT S 3072 B IT S 4096 B IT S
Crear clave 1 1 1
Eliminación de clave 10 10 10
(eliminación temporal)
Purgado de clave 10 10 10
Copia de seguridad de clave 10 10 10
Restauración de clave 10 10 10
Obtención de información 1100 1100 1100

clave
Cifrado 10000 10000 6000
Descifrado 1100 360 160
Encapsulado 10000 10000 6000
Desencapsulado 1100 360 160
Firma 1100 360 160
Comprobar 10000 10000 6000
O p e r a c i o n e s d e c l a v e E C (n ú m e r o d e o p e r a c i o n e s p o r se g u n d o p o r i n st a n c i a d e H SM )
En esta tabla se describe el número de operaciones por segundo para cada tipo de curva.
O P ERA C IÓ N P - 256 P - 256K P - 384 P - 521
Crear clave 1 1 1 1
O P ERA C IÓ N P - 256 P - 256K P - 384 P - 521
Eliminación de clave 10 10 10 10
(eliminación
temporal)
Purgado de clave 10 10 10 10
Copia de seguridad 10 10 10 10
de clave
Restauración de clave 10 10 10 10
Obtención de 1100 1100 1100 1100

información clave
Firma 260 260 165 56
Comprobar 130 130 82 28
O p e r a c i o n e s d e c l a v e A E S (n ú m e r o d e o p e r a c i o n e s p o r se g u n d o p o r i n st a n c i a d e H SM )
Las operaciones de cifrado y descifrado suponen un tamaño de paquete de 4 KB.

Los límites de rendimiento para cifrar y descifrar se aplican a los algoritmos AES-CBC y AES-GCM.
Los límites de rendimiento para encapsular y desencapsular se aplican al algoritmo AES-KW.
O P ERA C IÓ N 128 B IT S 192 B IT S 256 B IT S
Crear clave 1 1 1
Eliminación de clave 10 10 10
(eliminación temporal)
Purgado de clave 10 10 10
Copia de seguridad de clave 10 10 10
Restauración de clave 10 10 10
Obtención de información 1100 1100 1100

clave
Cifrado 8000 8000 8000
Descifrado 8000 8000 8000
Encapsulado 9000 9000 9000
Desencapsulado 9000 9000 9000
Límites de identidad administrada

Cada identidad administrada cuenta para el límite de cuota de objetos de un inquilino de Azure AD, como
se indica en Restricciones y límites del servicio Azure AD.
La velocidad a la que se pueden crear identidades administradas tiene los siguientes límites:
1. Por inquilino de Azure AD por región de Azure: 200 operaciones de creación en 20 segundos.
2. Por suscripción de Azure por región de Azure: 40 operaciones de creación en 20 segundos.
Al crear identidades administradas asignadas por el usuario, solo se admiten caracteres alfanuméricos (0-
9, a-z, A-Z) y el guion (-). Para que la asignación a una máquina virtual o un conjunto de escalado de
máquinas virtuales funcione correctamente, el nombre está limitado a 24 caracteres.
Límites de Media Services

NOTE
En relación con los recursos que no están fijados, abra una incidencia de soporte técnico para solicitar un aumento en las
cuotas. No cree cuentas adicionales de Azure Media Services para obtener límites mayores.
Límites de cuentas
RESO URC E L ÍM IT E P REDET ERM IN A DO
Cuentas de Media Services en una suscripción única 100 (fijo)
Límites de recursos
Recursos por cuenta de Media Services 1 000 000
Límites de almacenamiento (elementos multimedia)

Tamaño de archivo En algunos casos, existe un límite máximo de tamaño de

archivo admitido para el procesamiento en Media Services.
(1)
Cuentas de almacenamiento 100(2) (cantidad fija)
1 El tamaño máximo admitido para un único blob es actualmente de 5 TB en Azure Blob Storage. En Media
Services, se aplican límites adicionales en función de los tamaños de máquina virtual utilizados por el servicio.
El límite de tamaño se aplica a los archivos que se cargan y también a los que se generan como resultado del
procesamiento (codificación o análisis) de Media Services. Si el archivo de origen es mayor de 260 GB, es muy
probable que el trabajo presente un error.
En la tabla siguiente se muestran los límites en cada una de las unidades reservadas de multimedia (S1, S2 y
S3). Si el archivo de origen es mayor que los límites definidos en la tabla, se producirá un error en el trabajo de
codificación. Si codifica orígenes de resolución en 4K de larga duración, debe usar unidades reservadas de
multimedia S3 para lograr el rendimiento necesario. Si tiene contenido de 4K mayor que el límite de 260 GB en
las unidades reservadas de multimedia S3, abra una incidencia de soporte técnico.
T IP O DE UN IDA D RESERVA DA DE M EDIO S TA M A Ñ O M Á XIM O DE EN T RA DA ( GB )
S1 26
T IP O DE UN IDA D RESERVA DA DE M EDIO S TA M A Ñ O M Á XIM O DE EN T RA DA ( GB )
S2 60
S3 260
2 Las cuentas de almacenamiento deben proceder de la misma suscripción de Azure.

Límites de trabajos (codificación y análisis)
Trabajos por cuenta de Media Services 500 000 (3) (cantidad fija)
Entradas de trabajo por trabajo 50 (cantidad fija)
Salidas de trabajo por trabajo 20 (cantidad fija)
Transformaciones por cuenta de Media Services 100 (cantidad fija)
Salidas de transformación en una transformación 20 (cantidad fija)
Archivos por entrada de trabajo 10 (cantidad fija)
3 Este número incluye los trabajos en cola, terminados, activos y cancelados. No incluye los trabajos eliminados.
Se eliminarán automáticamente los registros de trabajo de más de 90 días de su cuenta, aunque el número total
de registros no llegue a la cuota máxima.
Límites de streaming en vivo
Eventos en directo (4) por cuenta de Media Services 5
Salidas en directo por evento en directo 3 (5)
Duración máxima de la salida en directo Tamaño de la ventana de DVR
4 Para obtener información detallada sobre las limitaciones de eventos en directo, consulte Comparación de
tipos de objetos LiveEvent.
5 Los objetos LiveOutput comienzan cuando se crean y se detienen cuando se eliminan.
Límites de empaquetado y entrega

Puntos de conexión de streaming (detenidos o en ejecución) 2

por cuenta de Media Services
Filtros de manifiesto dinámico 100
Directivas de streaming 100 (6)

Localizadores de streaming únicos asociados con un recurso 100(7) (cantidad fija)

al mismo tiempo
6 Al usaruna directiva de streaming personalizada, debe diseñar un conjunto limitado de dichas directivas para
su cuenta de Media Service y reutilizarlas para sus localizadores de streaming siempre que se necesiten las
mismas opciones y protocolos de cifrado. No debe crear una nueva directiva de streaming para cada localizador
de streaming.
7 Los localizadores de streaming no están diseñados para administrar el control de acceso por usuario. Para
conceder derechos de acceso diferentes a usuarios individuales, use las soluciones de administración de
derechos digitales (DRM).
Límites de protección
Opciones por directiva de clave de contenido 30
Licencias por mes para cada uno de los tipos DRM en el 1 000 000
servicio de entrega de claves de Media Services por cuenta
Incidencia de soporte técnico

En el caso de recursos que no son fijos, puede solicitar que se generen las cuotas abriendo una incidencia de
soporte técnico. Incluya información detallada en la solicitud en los cambios de cuota que se desean, en los
escenarios de casos de uso y las regiones que se requieren.
No cree cuentas adicionales de Azure Media Services para obtener límites mayores.
Media Services v2 (heredado )
Para conocer los límites específicos de Media Services v2 (heredado), vea Media Services v2 (heredado).
Límites de Mobile Services

N IVEL GRAT UITO B Á SIC A ESTÁ N DA R
Llamadas a API 500.000 1,5 millones por unidad 15 millones por unidad
Dispositivos activos 500 Sin límite Sin límite
Escala N/D Hasta 6 unidades Sin límite de unidades
Notificaciones de inserción Nivel Gratis de Azure Nivel Básico de Notification Nivel Estándar de
Notification Hubs incluido, Hubs, hasta 10 millones de Notification Hubs, hasta
hasta 1 millón de inserciones 10 millones de inserciones
inserciones
Mensajería en tiempo real/ Limitado 350 por servicio móvil Sin límite
Web Sockets
Sincronizaciones sin Limitado Se incluye Se incluye

conexión
Scheduled jobs Limitado Se incluye Se incluye

Azure SQL Database 20 MB incluidos 20 MB incluidos 20 MB incluidos

(obligatorio)
Se aplicarán tarifas estándar
para capacidad adicional
Capacidad de CPU 60 minutos por día Sin límite Sin límite
Transferencia de datos 165 MB por día (sustitución Se incluye Se incluye

salientes a diario)
Para más información sobre límites y precios, consulte Precios de Azure Mobile Services.
Límites de Multi-Factor Authentication

El número máximo de intervalos o 0 50

direcciones IP de confianza por
suscripción
Recordar mis dispositivos: número de 14 60

días
Número máximo de contraseñas de 0 Sin límite

aplicación
Permitir X intentos durante una 1 99

llamada de MFA
Segundos de espera de mensajes de 60 600

texto bidireccionales
Segundos de omisión por única vez 300 1800

predeterminados
Bloquear la cuenta de usuario tras X Sin establecer 99

denegaciones consecutivas de MFA
Restablecer el recuento de bloqueos de Sin establecer 9999

cuenta tras X minutos
Desbloquear cuenta tras X minutos Sin establecer 9999
Límites de red
Límites de redes - Azure Resource Manager
Los límites siguientes solo se aplican a los recursos de redes administrados mediante Azure Resource
Manager por región y por suscripción. Aprenda a ver el uso de recursos actual comparado con los límites de su
suscripción.
NOTE
Recientemente hemos aumentado todos los límites predeterminados a sus límites máximos. Si no hay ninguna columna
de límite máximo, el recurso no tiene límites ajustables. Si el soporte técnico ha aumentado estos límites en el pasado y no
ve los límites actualizados en las tablas siguientes, abra una solicitud de soporte técnico al cliente en línea sin cargo
Redes virtuales 1,000
Subredes por red virtual 3,000
Emparejamientos de redes virtuales por red virtual 500
Puertas de enlace de red virtual (puertas de enlace VPN) por 1

red virtual
Puertas de enlace de red virtual (puertas de enlace 1

ExpressRoute) por red virtual
Servidores DNS por red virtual 20
Direcciones IP privadas por red virtual 65 536
Direcciones IP privadas por interfaz de red 256
Direcciones IP privadas por máquina virtual 256
Direcciones IP públicas por interfaz de red 256
Direcciones IP públicas por máquina virtual 256
Conexiones TCP concurrentes o flujo UDP por NIC de una 500.000

máquina virtual o instancia de rol
Tarjetas adaptadoras de red 65 536
Grupos de seguridad de red 5.000
Reglas de NSG por NSG 1,000
Direcciones IP y rangos especificados para el origen o 4.000

destino en un grupo de seguridad
Grupos de seguridad de aplicaciones 3,000
Grupos de seguridad de aplicaciones por configuración de IP, 20

por NIC
Configuraciones de IP por grupo de seguridad de 4.000

aplicaciones
Grupos de seguridad de aplicaciones que se pueden 100

especificar en todas las reglas de seguridad de un grupo de
seguridad de red
Tablas de rutas definidas por el usuario 200
Rutas definidas por el usuario por tabla de ruta 400
Certificados raíz de punto a sitio por Azure VPN Gateway 20
TAP de red virtual 100
Configuraciones de TAP de la interfaz de red por TAP de red 100

virtual
Límites de dirección IP pública
Direcciones IP públicas1 10 para Basic. Póngase en contacto con el servicio de

soporte técnico.
Direcciones IP públicas estáticas1 10 para Basic. Póngase en contacto con el servicio de

soporte técnico.
Direcciones IP públicas estándar1 10 Póngase en contacto con el servicio de

soporte técnico.
Direcciones IP públicas por grupo de 800 Póngase en contacto con el servicio de

recursos soporte técnico.
Prefijos de dirección IP pública Limitado por el número de direcciones Póngase en contacto con el servicio de
IP públicas estándar en una suscripción soporte técnico.
Longitud del prefijo de IP pública /28 Póngase en contacto con el servicio de

soporte técnico.
1Los límites predeterminados para las direcciones IP públicas varían según el tipo de categoría de la oferta, por
ejemplo, versión de prueba gratuita, Pago por uso o CSP. Por ejemplo, el valor predeterminado para las
suscripciones Contrato Enterprise es 1000.
Límites del equilibrador de carga
Los límites siguientes solo se aplican a los recursos de redes administrados a través de Azure Resource Manager
por región y por suscripción. Aprenda a ver el uso de recursos actual comparado con los límites de su
suscripción.
Standard Load Balancer
Equilibradores de carga 1,000
Reglas (Load Balancer + NAT de entrada) por recurso 1500

Reglas por NIC (en todas las direcciones IP de una NIC) 300
Configuraciones de direcciones IP de front-end 600
Tamaño de grupo de back-end 1000 configuraciones de IP, una sola red virtual
Recursos de back-end por Load Balancer 1 250
Puertos de alta disponibilidad 1 por front-end interno
Reglas de salida por Load Balancer 600
Instancias de Load Balancer por máquina virtual 2 (1 público y 1 interno)
1El límite es de hasta 150

recursos, en cualquier combinación de recursos de máquinas virtuales independientes,
recursos de conjuntos de disponibilidad y grupos de ubicación de conjuntos de escalado de máquinas virtuales.
Load Balancer básico
Equilibradores de carga 1,000
Reglas por recurso 250
Reglas por NIC (en todas las direcciones IP de una NIC) 300
Configuraciones de direcciones IP de front-end 2 200
Tamaño de grupo de back-end 300 configuraciones de IP, un solo conjunto de disponibilidad
Conjuntos de disponibilidad por Load Balancer 1
Instancias de Load Balancer por máquina virtual 2 (1 público y 1 interno)
2 El límite de un único recurso discreto en un grupo de back-end (máquina virtual independiente, conjunto de
disponibilidad o grupo de selección de escalado de máquinas virtuales) es tener hasta 250 configuraciones de IP
de front-end en una instancia de Load Balancer pública básica y una instancia de Load Balancer interna básica.
Los límites siguientes se aplican solo a los recursos de redes administrados a través del modelo de
implementación clásico por suscripción. Aprenda a ver el uso de recursos actual comparado con los límites de
su suscripción.
Redes virtuales 100 100
Sitios de red local 20 50
Servidores DNS por red virtual 20 20

Direcciones IP privadas por red virtual 4 096 4 096
Conexiones TCP concurrentes o flujo 500 000, hasta 1 000 000 de dos o 500 000, hasta 1 000 000 de dos o
UDP por NIC de una máquina virtual o varias NIC. varias NIC.
instancia de rol
Grupos de seguridad de red (NSG) 200 200
Reglas de NSG por NSG 200 1,000
Tablas de rutas definidas por el usuario 200 200
Rutas definidas por el usuario por 400 400

tabla de ruta
Direcciones IP públicas (dinámicas) 500 500
Direcciones IP públicas reservadas 500 500
Dirección IP pública por 5 Ponerse en contacto con soporte

implementación técnico
Dirección IP privada (equilibrio de 1 1

carga interno) por implementación
Listas de control de acceso (ACL) de 50 50

punto de conexión
Límites de ExpressRoute
REC URSO L ÍM IT E
Circuitos ExpressRoute por suscripción 10
Circuitos ExpressRoute por región y suscripción, con Azure 10

Resource Manager
Número máximo de rutas anunciadas para emparejamiento 4.000

privado de Azure con ExpressRoute estándar
Número máximo de rutas anunciadas para emparejamiento 10 000

privado de Azure con complemento de ExpressRoute
premium
Número máximo de rutas anunciadas desde el 200

emparejamiento privado de Azure a partir del espacio de
direcciones de red virtual de una conexión ExpressRoute
Número máximo de rutas anunciadas para emparejamiento 200

de Microsoft con ExpressRoute estándar
Número máximo de rutas anunciadas para emparejamiento 200

de Microsoft con el complemento de ExpressRoute premium
REC URSO L ÍM IT E
Número máximo de circuitos ExpressRoute vinculados a la 4

misma red virtual en la misma ubicación de emparejamiento
Número máximo de circuitos ExpressRoute vinculado a la 4

misma red virtual en distintas ubicaciones de
emparejamiento
Número de vínculos de red virtual permitidos por circuito Consulte la tabla Número de redes virtuales por circuito
ExpressRoute ExpressRoute.
Número de redes virtuales por circuito ExpressRoute
N ÚM ERO DE VÍN C ULO S DE RED

N ÚM ERO DE VÍN C ULO S DE RED VIRT UA L C O N C O M P L EM EN TO
TA M A Ñ O DEL C IRC UITO VIRT UA L PA RA ESTÁ N DA R P REM IUM
50 Mbps 10 20
100 Mbps 10 25
200 Mbps 10 25
500 Mbps 10 40
1 Gbps 10 50
2 Gbps 10 60
5 Gbps 10 75
10 Gbps 10 100
40 Gbps* 10 100
100 Gbps* 10 100
*Solo ExpressRoute Direct de 100 Gbps
NOTE
Las conexiones de Global Reach cuentan para el límite de conexiones de red virtual por circuito ExpressRoute. Por ejemplo,
un circuito Premium de 10 Gbps permitiría 5 conexiones de Global Reach y 95 conexiones a las puertas de enlace de
ExpressRoute, o bien 95 conexiones de Global Reach y 5 conexiones a las puertas de enlace de ExpressRoute, o cualquier
otra combinación hasta alcanzar el límite de 100 conexiones para el circuito.
Límites de la puerta de enlace de red virtual

Prefijos de dirección de red virtual 600 por puerta de enlace de VPN
Agregar rutas BGP 4000 por puerta de enlace de VPN

Prefijos de direcciones de puerta de enlace de red local 1000 por puerta de enlace de red local
de conexiones de sitio a sitio Depende de la SKU de puerta de enlace
Conexiones de punto a sitio Depende de la SKU de puerta de enlace
Límite de ruta de P2S: IKEv2 256 si no es de Windows / 25 si es de Windows
Límite de ruta de P2S: OpenVPN 1000
Máx. flows 100 000 para VpnGw1/AZ / 512 000 para VpnGw2-4/AZ
Límites de NAT Gateway

Direcciones IP públicas 16 por puerta de enlace NAT
Límites de Virtual WAN

Concentradores de Virtual WAN por región 1
Concentradores de Virtual WAN por Virtual WAN Regiones de Azure
Conexiones VPN (ramas) por concentrador 1,000
Rendimiento agregado por puerta de enlace de VPN de sitio 20 Gbps

a sitio de WAN virtual
Rendimiento por conexión VPN de Virtual WAN (2 túneles) 2 Gbps con un túnel de 1 Gbps/IPsec
Usuarios de punto a sitio por concentrador 10 000
Rendimiento agregado por puerta de enlace de VPN de 20 Gbps

usuario (punto a sitio) de WAN virtual
Rendimiento agregado por puerta de enlace de ExpressRoute 20 Gbps

de Virtual WAN
Conexiones del circuito ExpressRoute por centro 4
Conexiones de red virtual por concentrador 500 menos el número total de centros que haya en la WAN
virtual
Rendimiento agregado por enrutador de centro de la WAN 50 Gbps para el tránsito entre redes virtuales
virtual
Carga de trabajo de máquinas virtuales en todas las redes 2000

virtuales conectadas a un único centro de conectividad de
WAN virtual
Límites de Application Gateway
La tabla siguiente se aplica a v1, v2 y estándar y a SKU de WAF, a menos que se indique lo contrario.
REC URSO L ÍM IT E N OTA :
Azure Application Gateway 1000 por suscripción
Configuración de direcciones IP de 2 1 pública y 1 privada

front-end
Puertos de front-end 1001
Grupos de direcciones de back-end 1001
Servidores back-end por grupo 1,200
Agentes de escucha HTTP 2001 Limitado a 100 clientes de escucha

activos que enrutan el tráfico. Clientes
de escucha activos = número total de
clientes de escucha - clientes de
escucha no activos.
Si se establece una configuración
predeterminada dentro de una regla
de enrutamiento para enrutar el tráfico
(por ejemplo, tiene un cliente de
escucha, un grupo de back-end y la
configuración de HTTP), también
cuenta como cliente de escucha.
Reglas de equilibrio de carga HTTP 1001
Configuración de HTTP de back-end 1001
Instancias por puerta de enlace V1 SKU: 32

V2 SKU: 125
Certificados SSL 1001 Uno por cliente de escucha HTTP
Tamaño máximo de certificados SSL V1 SKU: 10 KB

V2 SKU: 16 KB
Certificados de autenticación 100
Certificados raíz de confianza 100
Tiempo de espera de solicitud mínimo 1 segundo
Tiempo de espera de solicitud máximo 24 horas
Número de sitios 1001 Uno por cliente de escucha HTTP
Asignaciones de URL por agente de 1

escucha
REC URSO L ÍM IT E N OTA :
Número máximo de reglas basadas en 100

rutas por mapa de direcciones URL
Configuraciones de redirección 1001
Número de conjuntos de reglas de 400

reescritura
Número de encabezado o 40
configuración de dirección URL por
conjunto de reglas de reescritura
Número de condiciones por conjunto 40

de reglas de reescritura
Conexiones simultáneas de WebSocket Puertas de enlace medianas 20k

Puertas de enlace grandes 50k
Longitud máxima de dirección URL 32 KB
Tamaño de encabezado máximo para 4 KB

HTTP/2
Tamaño máximo de carga de archivos 2 GB

(estándar)
Tamaño máximo de carga de archivos Puertas de enlaces v1 medianas WAF,

WAF 100 MB
Puertas de enlace v1 grandes WAF,
500 MB
V2 WAF, 750 MB
Límite de tamaño de cuerpo de WAF 128 KB

(sin archivos)
Máximo de reglas personalizadas de 100

WAF
Número máximo de exclusiones de 40

WAF por instancia de Application
Gateway
1 En caso de las SKU con WAF habilitado, debe limitar el número de recursos a 40.
Límites de Network Watcher
RESO URC E L ÍM IT E N OTA :
Azure Network Watcher 1 por región Network Watcher se crea para permitir
el acceso al servicio. Se requiere una
única instancia de Network Watcher
por suscripción y región.
Sesiones de captura de paquetes 10 000 por región Solo número de sesiones, sin capturas
guardadas.
RESO URC E L ÍM IT E N OTA :
Límites de Private Link

Los límites siguientes corresponden a Azure Private Link:
REC URSO L ÍM IT E
Número de puntos de conexión privados por red virtual 1000
Número de puntos de conexión privados por suscripción 64000
Número de servicios Private Link por suscripción 800
Número de configuraciones IP en un servicio Private Link 8 (este número es para las direcciones IP de NAT usadas por
PLS)
Número de puntos de conexión privados en el mismo 1000

servicio Private Link
Número de puntos de conexión privados por almacén de 64

claves
Número de almacenes de claves con puntos de conexión 400

privados por suscripción
Número de grupos de zonas DNS privados que se pueden 1

vincular a un punto de conexión privado
Número de zonas DNS de cada grupo 5
Límites de Purview
Los valores más recientes de las cuotas de Azure Purview se pueden encontrar en la página de cuotas de Azure
Purview.
Límites de Traffic Manager
Perfiles por suscripción 200
Extremos por perfil 200
Límites de Azure Bastion

Conexiones RDP simultáneas 25*
Conexiones SSH simultáneas 50**

*Puede variar debido a otras sesiones de RDP en curso u otras sesiones de SSH en curso.
**Puede variar si hay conexiones RDP existentes o el uso de otras sesiones SSH en curso.
Límites de Azure DNS
Zonas DNS públicas
Zonas DNS públicas por suscripción 250 1
Conjuntos de registros por zona DNS pública 10 000 1
Registros por conjunto de registros en la zona DNS pública 20
Número de registros de alias para un único recurso de Azure 20
1Si necesita aumentar estos límites, póngase en contacto con el soporte técnico de Azure.
Zonas de DNS privado
REC URSO L ÍM IT E
Zonas DNS privadas por suscripción 1000
Conjuntos de registros por zona DNS privada 25000
Registros por conjunto de registros para zonas DNS privadas 20
Vínculos de red virtual por zona DNS privada 1000
Vínculos de red virtual por zonas DNS privadas con el 100

registro automático habilitado
Número de zonas DNS privadas a la que se puede vincular 1

una red virtual con el registro automático habilitado
Número de zonas DNS privadas a la que se puede vincular 1000

una red virtual
Número de consultas de DNS que una máquina virtual 1000 1

puede enviar al solucionador de Azure DNS por segundo
Número máximo de consultas de DNS en cola (pendientes 200 1

de respuesta) por máquina virtual
1Estos límites se aplican a cada máquina virtual individual, no al nivel de red virtual. Las consultas de DNS que
superan estos límites se omiten.
Límites de Azure Firewall
REC URSO L ÍM IT E
Rendimiento de los datos 30 Gbps1
Reglas 10 000. Todos los tipos de reglas combinados.

REC URSO L ÍM IT E
Número máximo de reglas DNAT 298 para una sola dirección IP pública.
Todas las direcciones IP públicas adicionales contribuyen a
los puertos SNAT disponibles, pero reducen el número de
reglas de DNAT disponibles. Por ejemplo, dos direcciones IP
públicas permiten 297 reglas de DNAT. Si el protocolo de una
regla está configurado tanto para TCP como para UDP,
cuenta como dos reglas.
Tamaño mínimo de AzureFirewallSubnet /26
Intervalo de puertos en reglas de red y aplicación 1 - 65535
Direcciones IP públicas 250 máximo. Todas las IP públicas se pueden usar en las
reglas de DNAT y todas ellas contribuyen a los puertos SNAT
disponibles.
Direcciones IP de grupos de IP Máximo de 100 grupos de IP por firewall.

Máximo de 5000 direcciones IP individuales o prefijos IP por
cada grupo de IP.
Tabla de rutas De forma predeterminada, AzureFirewallSubnet tiene una

ruta 0.0.0.0/0 con el valor de NextHopType establecido en
Internet .
Azure Firewall debe tener conectividad directa a Internet. Si

AzureFirewallSubnet aprende una ruta predeterminada a la
red local mediante BGP, debe reemplazarla por una UDR
0.0.0.0/0 con el valor NextHopType establecido como
Internet para mantener la conectividad directa a Internet.
De forma predeterminada, Azure Firewall no admite la
tunelización forzada a una red local.
Sin embargo, si la configuración requiere la tunelización

forzada a una red local, Microsoft proporcionará soporte
según el caso. Póngase en contacto con soporte técnico para
que podamos revisar su caso. Si acepta, permitiremos su
suscripción y nos aseguraremos de que se mantenga la
conectividad del firewall a Internet requerida.
Nombres de dominio completo en las reglas de red Para lograr que el rendimiento sea bueno, no debe haber
más de 1000 nombres de dominio completo en todas las
reglas de red por firewall.
1Si necesita aumentar estos límites, póngase en contacto con el soporte técnico de Azure.
Límites de Azure Front Door Service
Recursos de Azure Front Door por suscripción 100
Hosts de front-end, que incluye los dominios personalizados 500

por recurso
Reglas de enrutamiento por recurso 500

Grupos de servidores back-end por recurso 50
Servidores back-end por grupo de servidores back-end 100
Patrones de ruta de acceso para coincidir con una regla de 25

enrutamiento
Direcciones URL en una sola llamada de purga de la caché 100
Reglas de firewall de aplicación web personalizadas por 100

directiva
Directiva del firewall de aplicaciones web por suscripción 100
Condiciones de coincidencia del firewall de aplicaciones web 10

por regla personalizada
Intervalos de direcciones IP del firewall de aplicaciones web 600

por condición de coincidencia
Valores de coincidencia de la cadena del firewall de 10

aplicaciones web por condición de coincidencia
Longitud del valor de coincidencia de la cadena del firewall 256

de aplicaciones web
Longitud del nombre del parámetro del cuerpo POST del 256
firewall de aplicaciones web
Longitud del nombre del encabezado HTTP del firewall de 256

aplicaciones web
Longitud del nombre de la cookie del firewall de aplicaciones 256

web
Tamaño del cuerpo de la solicitud HTTP del firewall de 128 KB

aplicaciones web inspeccionado
Longitud del cuerpo de respuesta personalizada del firewall 2 KB

de aplicaciones web
Límites de los servicios Azure Front Door Estándar/Premium (versión preliminar)

*** 500 perfiles Estándar y Premium totales por suscripción (máximo).
RESO URC E L ÍM IT E DE SK U ESTÁ N DA R L ÍM IT E DE SK U P REM IUM
Número máximo de puntos de 10 25

conexión por perfil
Número máximo de dominios 100 200

personalizados por perfil
RESO URC E L ÍM IT E DE SK U ESTÁ N DA R L ÍM IT E DE SK U P REM IUM
Número máximo de grupos de origen 100 200

por perfil
Número máximo de secretos por perfil 100 200
Número máximo de directivas de 100 200

seguridad por perfil
Número máximo de conjuntos de 100 200

reglas por perfil
Número máximo de reglas por 100 100

conjunto de reglas
Número máximo de orígenes por 50 50

grupo de origen
Número máximo de rutas por punto 100 200

de conexión
Condiciones de coincidencia del firewall 10 10

de aplicaciones web por regla
personalizada
Intervalos de direcciones IP del firewall 600 600

de aplicaciones web por condición de
coincidencia
Valores de coincidencia de la cadena 10 10

del firewall de aplicaciones web por
condición de coincidencia
Longitud del valor de coincidencia de 256 256

la cadena del firewall de aplicaciones
web
Longitud del nombre del parámetro 256 256

del cuerpo POST del firewall de
aplicaciones web
Longitud del nombre del encabezado 256 256

HTTP del firewall de aplicaciones web
Longitud del nombre de la cookie del 256 256

firewall de aplicaciones web
Tamaño del cuerpo de la solicitud HTTP 128 KB 128 KB

del firewall de aplicaciones web
inspeccionado
Longitud del cuerpo de respuesta 2 KB 2 KB

personalizada del firewall de
aplicaciones web
Valores de tiempo de expiración

Cliente para Front Door
Front Door tiene un tiempo de espera de la conexión TCP de 61 segundos.
Front Door al back-end de la aplicación
Si la respuesta es una respuesta fragmentada, se devuelve una respuesta 200 si se recibe el primer
fragmento, o cuando se recibe.
Después de que la solicitud HTTP se reenvía al back-end, Front Door espera 30 segundos al primer paquete
del back-end. A continuación, se devuelve un error 503 al cliente. Este valor se puede configurar desde el
campo sendRecvTimeoutSeconds de la API.
En el caso de los escenarios de almacenamiento en caché, este tiempo de expiración no se puede
configurar, por lo que si una solicitud se almacena en caché y el primer paquete tarda más de 30
segundos desde Front Door o desde el back-end, se devuelve un error 504 al cliente.
Una vez recibido el primer paquete del back-end, Front Door espera 30 segundos en un tiempo de expiración
de inactividad. A continuación, se devuelve un error 503 al cliente. Este valor de tiempo de expiración no se
puede configurar.
El tiempo de expiración de la sesión TCP desde Front Door hasta el back-end es de 90 segundos.
Límite de carga y descarga de datos
C O N C O DIF IC A C IÓ N DE
T RA N SF EREN C IA F RA GM EN TA DA
( C T E) SIN F RA GM EN TA C IÓ N DE H T T P
Descargar No hay ningún límite para el tamaño No hay ningún límite para el tamaño
de descarga. de descarga.
Cargar No hay ningún límite siempre y El tamaño no puede ser superior a

cuando cada carga de CTE sea inferior 2 GB.
a 2 GB.
Otros límites
Tamaño máximo de la dirección URL: 8192 bytes: especifica la longitud máxima de la dirección URL sin
procesar (esquema + nombre de host + puerto + ruta de acceso + cadena de consulta de la dirección URL)
Tamaño máximo de la cadena de consulta: 4096 bytes: especifica la longitud máxima de la cadena de
consulta, en bytes.
Tamaño máximo del encabezado de respuesta HTTP desde la dirección URL de sondeo de estado: 4096 bytes
(se ha especificado la longitud máxima de todos los encabezados de respuesta de los sondeos de estado).
Límites de Notification Hubs

Inserciones incluidas 1 millón 10 millones 10 millones
Dispositivos activos 500 200 000 10 millones
Cuota de etiquetas por 60 60 60

instalación o registro
Para más información sobre límites y precios, consulte Precios de Notification Hubs.
Límites de Service Bus

En la siguiente tabla se muestra la información de cuotas específica de la mensajería de Azure Service Bus. Para
obtener información sobre los precios y otras cuotas de Service Bus, vea Precios de Service Bus.
N O M B RE DE C UOTA Á M B ITO N OTA S VA L UE
Número máximo de Espacio de nombres Azure Portal rechaza las 100

espacios de nombres Básico solicitudes posteriores de
o Estándar por suscripción espacios de nombres Básico
de Azure o Estándar adicionales.
Número máximo de Espacio de nombres El portal rechaza las 100

espacios de nombres solicitudes posteriores de
Premium por suscripción de espacios de nombres
Azure Premium adicionales.
Tamaño de cola o tema Entidad Se define al crear la cola o el 1, 2, 3, 4 o 5 GB.

tema.
En la SKU Premium y en la
Los sucesivos mensajes SKU Estándar con
entrantes se rechazan y el particiones habilitadas, el
código que llama recibe una tamaño máximo de cola o
excepción. tema es de 80 GB.
Número de conexiones Espacio de nombres Las solicitudes posteriores Número neto de mensajes:
simultáneas en un espacio de conexiones adicionales 1000.
de nombres se rechazan y el código que
llama recibe una excepción. AMQP: 5000.
Las operaciones REST no
cuentan para las conexiones
de TCP simultáneas.
Número de solicitudes de Entidad Las solicitudes de recepción 5.000

recepción simultáneas en posteriores se rechazan y el
una cola, un tema o una código que llama recibe una
entidad de suscripción excepción. Esta cuota se
aplica a un número
combinado de operaciones
de recepción simultáneas en
todas las suscripciones de
un tema.
Número de temas o colas Espacio de nombres Se rechazan las posteriores 10 000 para el nivel Básico
por espacio de nombres solicitudes de creación colas o Estándar. El número total
o temas nuevos en el de temas y colas de un
espacio de nombres. Como espacio de nombres debe
resultado, si se configuran ser menor o igual a 10 000.
mediante Azure Portal, se
genera un mensaje de error. En el nivel Premium, 1000
Si se realiza una llamada por unidad de mensajería
desde la API de (MU).
administración, el código de
llamada recibe una
excepción.
Número de temas o colas Espacio de nombres Se rechazan las posteriores Niveles Básico y Estándar:
con particiones por espacio solicitudes de creación colas 100.
de nombres o temas con particiones
nuevos en el espacio de No se admiten entidades
nombres. Como resultado, con particiones en el nivel
si se configuran mediante Premium.
Azure Portal, se genera un
mensaje de error. Si se Cada cola o tema con
realiza una llamada desde la particiones cuenta para la
API de administración, el cuota de 1000 entidades
código que llama recibe una por espacio de nombres.
excepción
QuotaExceededExceptio
n.
Tamaño máximo de Entidad - 260 caracteres.

cualquier ruta de entidad de
mensajería: cola o tema
Tamaño máximo de Entidad - 50 caracteres.

cualquier nombre de
entidad de mensajería:
espacio de nombres,
suscripción o regla de
suscripción
Tamaño máximo de un Entidad - 128

identificador de mensaje
Tamaño máximo de un Entidad - 128

identificador de sesión de
mensaje
Tamaño de mensaje de una Entidad Los mensajes entrantes que Tamaño de mensaje
cola, un tema o una entidad superan estas cuotas se máximo: 256 KB para el
de suscripción rechazan y el código que nivel Estándar, 1 MB para el
llama recibe una excepción. nivel Premium.
Debido a la sobrecarga del

sistema, este límite es
menor que estos valores.
Tamaño de encabezado
máximo: 64 KB.
Número máximo de
propiedades de encabezado
en el contenedor de
propiedades:
byte/int.MaxValue .
Tamaño máximo de la
propiedad en el contenedor
de propiedades: sin límite
explícito. Limitado por
tamaño de encabezado
máximo.
Tamaño de propiedad de Entidad Se genera la excepción El tamaño máximo de

mensaje para una cola, un SerializationException . propiedad de mensaje para
tema o una entidad de cada propiedad es 32 000.
suscripción El tamaño acumulado de
todas las propiedades no
puede superar 64 000. Este
límite se aplica a todo el
encabezado del mensaje
asincrónico, que contiene
tanto las propiedades de
usuario como las
propiedades del sistema,
como el número de
secuencia, la etiqueta y el
identificador del mensaje.
Número de suscripciones Entidad Se rechazan las posteriores 2000 por tema para el nivel
por tema solicitudes de creación de Estándar y el nivel Premium.
suscripciones adicionales
para el tema. Como
resultado, si se configura a
través del portal, se
muestra un mensaje de
error. Si se realiza una
llamada desde la API de
administración, el código de
llamada recibe una
excepción.
Número de filtros SQL por Entidad Se rechazan las posteriores 2.000

tema solicitudes de creación de
filtros adicionales en el tema
y el código que realiza la
llamada recibe una
excepción.
Número de filtros de Entidad Se rechazan las posteriores 100 000

correlación por tema solicitudes de creación de
filtros adicionales en el tema
y el código que realiza la
llamada recibe una
excepción.
Tamaño de filtros o acciones Espacio de nombres Se rechazan las posteriores Longitud máxima de la
SQL solicitudes de creación de cadena de condición de
filtros adicionales y el filtro: 1024 (1 K).
código que realiza la
llamada recibe una Longitud máxima de la
excepción. cadena de acción de regla:
1024 (1 K).
Número máximo de
expresiones por acción de
regla: 32.
Número de reglas de Entidad, espacio de Se rechazan las posteriores Número máximo de reglas
autorización de acceso nombres solicitudes de creación de por tipo de entidad: 12.
compartido por espacio de reglas adicionales en el
nombres, cola o tema tema y el código que llama Las reglas que se
recibe una excepción. configuran en un espacio de
nombres de Service Bus se
aplican a todos los tipos:
colas, temas.
Número de mensajes por Transacción Los mensajes entrantes 100

transacción adicionales se rechazan y el
código que llama recibe una Para ambas operaciones
excepción que indica Send() y SendAsync() .
"Cannot send more than
100 messages in a single
transaction" (No se pueden
enviar más de 100
mensajes en una sola
transacción).
Número de reglas de filtro Espacio de nombres 128

de dirección IP y red virtual
Límites de Site Recovery

Los límites siguientes se aplican a Azure Site Recovery.
IDEN T IF IC A DO R DE L ÍM IT ES L ÍM IT E
Número de almacenes por suscripción 500
Número de servidores por almacén de Recovery Services 250
Número de grupos de protección por almacén de Recovery Sin límite

Services
Número de planes de recuperación por almacén de Recovery Sin límite

Services
Número de servidores por grupo de protección Sin límite
Número de servidores por el plan de recuperación 100
Límites de SQL Database

Para los límites de SQL Database, consulte Límites de recursos de SQL Database para bases de datos únicas,
Límites de recursos de SQL Database para grupos elásticos y bases de datos agrupadas y Límites de recursos de
SQL Database para SQL Managed Instance.
Límites de Azure Synapse Analytics

Para conocer los límites de Azure Synapse Analytics, consulte Límites de recursos de Azure Synapse.
Azure Files y Azure File Sync
Para más información sobre los límites de Azure Files y File Sync, vea Objetivos de escalabilidad y rendimiento
de Azure Files.
Límites de Storage
En la tabla siguiente se describen los límites predeterminados para las cuentas de blob en bloques, Blob Storage
y de uso general v1 y v2 de Azure. El límite de entrada hace referencia a todos los datos que se envían a una
cuenta de almacenamiento. El límite de salida hace referencia a todos los datos que se reciben de una cuenta de
almacenamiento.
NOTE
Puede solicitar unos límites de capacidad y de entrada mayores. Para solicitar un aumento, póngase en contacto con
Soporte técnico de Azure.
Número de cuentas de almacenamiento por región y 250

suscripción, incluidas las cuentas de almacenamiento
Estándar y Premium.
Capacidad máxima de la cuenta de almacenamiento 5 PiB 1
Número máximo de contenedores de blobs, blobs, recursos Sin límite

compartidos de archivos, tablas, colas, entidades o mensajes
por cuenta de almacenamiento
Tasa de solicitud total1 por cuenta de almacenamiento 20 000 solicitudes por segundo
Entrada máxima1 por cuenta de almacenamiento (regiones 10 Gbps

de Estados Unidos y Europa)
Entrada máxima1 por cuenta de almacenamiento (regiones 5 Gbps si RA-GRS o GRS está habilitado, 10 Gbps en el caso
distintas de Estados Unidos y Europa) de LRS o ZRS2
Salida máxima para las cuentas de uso general v2 y de Blob 50 Gbps

Storage (todas las regiones)
Salida máxima para cuentas de almacenamiento de uso 20 Gbps si RA-GRS o GRS están habilitado, 30 Gbps en el
general v1 (regiones de EE. UU.) caso de LRS o ZRS2
Salida máxima para cuentas de almacenamiento de uso 10 Gbps si RA-GRS o GRS está habilitado, 15 Gbps en el
general v1 (regiones no de EE. UU.) caso de LRS o ZRS2
Número máximo de reglas de red virtual por cuenta de 200

almacenamiento
Número máximo de reglas de dirección IP por cuenta de 200

almacenamiento
1Las cuentas estándar de Azure Storage admiten límites de capacidad y límites de entrada por solicitud
superiores. Para solicitar un aumento en los límites de cuenta, póngase en contacto con el soporte técnico de
Azure.
2
2 Si la cuenta de almacenamiento tiene habilitado el acceso de lectura con almacenamiento con redundancia
geográfica (RA-GRS) o el almacenamiento con redundancia de zona geográfica (RA-GZRS), los destinos de
salida de la ubicación secundaria son idénticos a los de la ubicación principal. Para más información, consulte
Replicación de Azure Storage.
NOTE
Microsoft recomienda usar una cuenta de almacenamiento de uso general v2 en la mayoría de los escenarios. Puede
actualizar fácilmente una cuenta de Azure Blob Storage o de uso general v1 a una cuenta de uso general v2 sin tiempo de
inactividad y sin la necesidad de copiar datos. Para más información, consulte Actualización a una cuenta de
almacenamiento de uso general v2.
Todas las cuentas de almacenamiento se ejecutan en una topología de red plana, independientemente del
momento en que se hayan creado. Para obtener más información acerca de la arquitectura de red plana de
Azure Storage y de la escalabilidad, vea Microsoft Azure Storage: A Highly Available Cloud Storage Service with
Strong Consistency (Microsoft Azure Storage: Un servicio de almacenamiento en nube altamente disponible de
gran coherencia).
Para más información sobre los límites de escalabilidad de las cuentas de almacenamiento estándar, consulte
Objetivos de escalabilidad para cuentas de almacenamiento estándar.
Límites de proveedor de recursos de Storage
Los límites siguientes se aplican solo si realiza operaciones de administración mediante Azure Resource
Manager con Azure Storage.
Operaciones de administración de la cuenta de 800 por cada 5 minutos

almacenamiento (lectura)
Operaciones de administración de la cuenta de 10 por segundo / 1 200 por hora

almacenamiento (escritura)
Operaciones de administración de la cuenta de 100 por cada 5 minutos

almacenamiento (lista)
Límites de almacenamiento de blobs de Azure

REC URSO DEST IN O DEST IN O ( VERSIÓ N P REL IM IN A R)
Tamaño máximo de contenedor de un Igual que la capacidad máxima de la

blob cuenta de almacenamiento
Número máximo de bloques en un 50 000 bloques

blob en bloques o blob en anexos
Tamaño máximo de un bloque en un 100 MiB 4000 MiB (versión preliminar)

blob en bloques
Tamaño máximo de un blob en 50 000 x 100 MiB (4,75 TiB, 50 000 x 4000 MiB (aproximadamente
bloques aproximadamente) 190,7 TiB) (versión preliminar)
Tamaño máximo de un bloque en un 4 MiB

blob en anexos
REC URSO DEST IN O DEST IN O ( VERSIÓ N P REL IM IN A R)
Tamaño máximo de un blob en anexos 50 000 x 4 MiB (195 GiB,

aproximadamente)
Tamaño máximo de un blob en 8 TiB2

páginas
Número máximo de directivas de 5

acceso almacenadas por contenedor
de blobs
Velocidad de solicitudes de destino Hasta 500 solicitudes por segundo

para un solo blob
Rendimiento de destino para un blob Hasta 60 MiB por segundo2

en una sola página
Rendimiento de destino para un blob Hasta los límites de entrada/salida de

en un solo bloque cuenta de almacenamiento1
1 El rendimiento de un único blob depende de varios factores, incluidos, sin limitación: simultaneidad, tamaño de
la solicitud, nivel de rendimiento, velocidad de origen de las cargas y destino de las descargas. Para aprovechar
las mejoras de rendimiento de blobs en bloques de alto rendimiento, cargue blobs o bloques más grandes. En
concreto, llame a la operación Put Blob o Put Block con un tamaño de blob o de bloque superior a 4 MiB para las
cuentas de almacenamiento estándar. Para los blobs en bloques prémium o las cuentas de almacenamiento de
Data Lake Storage Gen2, use un tamaño de bloque o de blob superior a 256 KiB.
2 Los blobs en páginas aún no se admiten en las cuentas que tienen el valor Espacio de nombres jerárquico .
En la tabla siguiente se describen los tamaños máximos de bloque y blob que permite la versión del servicio.
TA M A Ñ O M Á XIM O DEL
B LO B A T RAVÉS DE UN A
TA M A Ñ O M Á XIM O DE TA M A Ñ O M Á XIM O DE B LO B O P ERA C IÓ N DE ESC RIT URA
B LO Q UE ( A T RAVÉS DE P UT ( A T RAVÉS DE P UT B LO C K ÚN IC A ( A T RAVÉS DE P UT
VERSIÓ N DEL SERVIC IO B LO C K ) L IST ) B LO B )
Versión 2019-12-12 y 4000 MiB (versión Aproximadamente 190,7 5000 MiB (versión
posteriores preliminar) TiB (4000 MiB x 50 000 preliminar)
bloques) (versión
preliminar)
De la versión 2016-05-31 a 100 MiB Aproximadamente 4,75 TiB 256 MiB

la versión 2019-07-07 (100 MiB x 50 000 bloques)
Versiones anteriores 4 MiB Aproximadamente 195 GiB 64 MiB

a 2016-05-31 (4 MiB x 50 000 bloques)
Límites de Azure Queue Storage

RESO URC E DEST IN O
Tamaño máximo de una cola individual 500 TiB
Tamaño máximo de un mensaje de una cola 64 KiB

Número máximo de directivas de acceso almacenadas por 5

cola
Tasa de solicitud total por cuenta de almacenamiento 20 000 mensajes por segundo, asumiendo un tamaño de
mensaje de 1 KiB
Rendimiento objetivo de una única cola (mensajes de 1 KiB) Hasta 2000 mensajes por segundo
Límites de Azure Table Storage

La tabla siguiente describe la capacidad, escalabilidad y los objetivos de rendimiento de Table Storage.
Número de tablas en una cuenta de Azure Storage Solo limitadas por la capacidad de la cuenta de
almacenamiento
Número de particiones en una tabla Solo limitadas por la capacidad de la cuenta de

almacenamiento
Número de entidades de una partición Solo limitadas por la capacidad de la cuenta de

almacenamiento
Tamaño máximo de una tabla individual 500 TiB
Tamaño máximo de una única entidad, incluidos todos los 1 MiB

valores de propiedad
Número máximo de propiedades de una entidad de tabla 255 (incluyendo las tres propiedades de sistema:
Par titionKey , RowKey y Timestamp )
Tamaño máximo total de una propiedad individual en una Varía en función del tipo de propiedad. Para obtener más
entidad información, consulte los tipos de propiedades en la
descripción del modelo de datos del servicio Tabla.
Tamaño de la Par titionKey Una cadena de hasta 1 KB
Tamaño de la RowKey Una cadena de hasta 1 KB
Tamaño de una transacción de un grupo de entidades Una transacción puede incluir como máximo 100 entidades y
la carga debe ser inferior a 4 MiB. Una transacción de un
grupo de entidades solo puede incluir una actualización de
una entidad.
Número máximo de directivas de acceso almacenadas por 5

tabla
Tasa de solicitud total por cuenta de almacenamiento 20 000 transacciones por segundo, lo que supone un
tamaño de entidad de 1 KiB
Rendimiento de destino de una sola partición de tabla Hasta 2000 entidades por segundo
(entidades de 1 KiB)
Límites de discos de máquinas virtuales

Puede asociar un número de discos de datos a una máquina virtual de Azure. Según los objetivos de
escalabilidad y rendimiento de los discos de datos de una máquina virtual, puede determinar el número y el tipo
de disco necesarios para satisfacer sus requisitos de capacidad y rendimiento.
IMPORTANT
Para obtener un rendimiento óptimo, limite el número de discos muy usados que se conectan a la máquina virtual para
evitar una posible limitación. Si todos los discos asociados no se usan mucho al mismo tiempo, la máquina virtual puede
admitir un mayor número de discos.
Para discos administrados de Azure:

En la tabla siguiente se muestran los límites predeterminado y máximo del número de recursos por región y
suscripción. Los límites siguen siendo los mismos, independientemente de que los discos estén cifrados con
claves administradas por la plataforma o claves administradas por el cliente. No hay ningún límite en el número
de discos administrados, instantáneas e imágenes por grupo de recursos.
Discos administrados estándar 50.000
Discos administrados SSD estándar 50.000
Discos administrados Premium 50.000
Instantáneas Standard_LRS 50.000
Instantáneas Standard_ZRS 50.000
Imagen administrada 50.000
Para cuentas de almacenamiento estándar : una cuenta de almacenamiento estándar tiene una tasa de
solicitudes máxima total de 20 000 IOPS. El número total de IOPS en todos los discos de máquina virtual de una
cuenta de almacenamiento estándar no debe superar este límite.
Puede calcular aproximadamente el número de discos muy usados que admite una sola cuenta de
almacenamiento estándar en función del límite de tasa de solicitudes. Por ejemplo, en el caso de una máquina
virtual de nivel Básico, el número máximo de discos muy usados está alrededor de 66, que equivale a
20 000/300 IOPS por disco. El número máximo de discos muy usados para una máquina virtual de nivel
Estándar es de aproximadamente 40, que equivale a 20 000/500 IOPS por disco.
Para cuentas de almacenamiento premium: una cuenta de almacenamiento premium tiene una capacidad
total máxima de proceso de 50 Gbps. La capacidad total de proceso en todos los discos de la máquina virtual no
debe superar este límite.
Para más información, consulte Tamaños de máquina virtual.
Conjuntos de cifrado de disco
Hay una limitación de 1000 conjuntos de cifrado de disco por región y por suscripción. Para obtener más
información, vea la documentación de cifrado para máquinas virtuales Linux o Windows. Si necesita aumentar
la cuota, póngase en contacto con el soporte técnico de Azure.
Discos de máquinas virtuales administrados
Discos administrados HDD estándar
T IP O
DE
DISC
O
ESTÁ
N DA R S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Tama 32 64 128 256 512 1024 2 048 4 096 8192 16 32

ño de 384 767
disco
en
GiB
IOPS Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
por 500 500 500 500 500 500 500 500 1300 2000 2000
disco
Rendi Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta Hasta
mient 60 60 60 60 60 60 60 60 300 500 500
o de MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s
disco.
Discos administrados SSD estándar

TA
MA
ÑO
S
DE
SSD
EST
ÁN
DA
R E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP Has Has Has Has Has Has Has Has Has Has Has Has Has Has
S ta ta ta ta ta ta ta ta ta ta ta ta ta ta
por 500 500 500 500 500 500 500 500 500 500 500 200 400 600
disc 0 0 0
o
Ren Has Has Has Has Has Has Has Has Has Has Has Has Has Has
dim ta ta ta ta ta ta ta ta ta ta ta ta ta ta
ient 60 60 60 60 60 60 60 60 60 60 60 400 600 750
o MB MB MB MB MB MB MB MB MB MB/ MB/ MB MB MB
de /s /s /s /s /s /s /s /s /s s s /s /s /s
disc
o.
Discos administrados SSD Premium: Límites por disco

TA
MA
ÑO
S
DE
SSD
P RE
M IU
M P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Tam 4 8 16 32 64 128 256 512 102 2 4 819 16 32

año 4 048 096 2 384 767
de
disc
o
en
GiB
IOP 120 120 120 120 240 500 110 2,3 5.0 750 750 16 18 20.
S 0 00 00 0 0 000 000 000
apr
ovis
ion
ada
s
por
disc
o
Cap 25 25 25 25 50 100 125 150 200 250 250 500 750 900
acid MB MB MB MB MB MB MB MB MB MB MB MB MB MB
ad /s /s /s /s /s /s /s /s /s /s /s /s /s /s
de
pro
ces
o
apr
ovis
ion
ada
por
disc
o
Má 350 350 350 350 350 350 350 350

xim 0 0 0 0 0 0 0 0
o
de
IOP
S
de
ráfa
ga
por
disc
o
TA
MA
ÑO
S
DE
SSD
P RE
M IU
M P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Cap 170 170 170 170 170 170 170 170

acid MB MB MB MB MB MB MB MB
ad /s /s /s /s /s /s /s /s
de
pro
ces
o
máx
imo
de
ráfa
ga
por
disc
o
Dur 30 30 30 30 30 30 30 30
ació min min min min min min min min
n
máx
ima
de
ráfa
ga
Apt No No No No No No No No Sí, Sí, Sí, Sí, Sí, Sí,

o has hast hast hast hast hast
par ta a a a a a
a un un un un un un
rese año año año año año año
rva
Discos administrados SSD Premium: Límites por máquina virtual

Número máximo de IOPS por máquina virtual 80 000 IOPS con máquina virtual GS5
Rendimiento máximo por máquina virtual 2000 MB/s con máquina virtual GS5
Discos de máquinas virtuales no administrados

Discos de máquina vir tual administrados estándar : límites por disco
M Á Q UIN A VIRT UA L DE N IVEL

N IVEL DE M Á Q UIN A VIRT UA L M Á Q UIN A VIRT UA L DE N IVEL B Á SIC O ESTÁ N DA R
Tamaño del disco 4095 GB 4095 GB
Número máximo de IOPS de 8 KB por 300 500

disco persistente
M Á Q UIN A VIRT UA L DE N IVEL
N IVEL DE M Á Q UIN A VIRT UA L M Á Q UIN A VIRT UA L DE N IVEL B Á SIC O ESTÁ N DA R
Número máximo de discos que 66 40

realizan la cantidad máxima de IOPS
Discos de máquina vir tual no administrados premium: límites por cuenta
Capacidad total de disco por cuenta 35 TB
Capacidad total de instantáneas por cuenta 10 TB
Ancho de banda máximo por cuenta (entrada + salida1 ) <=50 Gbps
1Entrada hace referencia a todos los datos de las solicitudes que se envían a una cuenta de almacenamiento.
Salida hace referencia a todos los datos de las respuestas que se reciben desde una cuenta de almacenamiento.
Discos de máquina vir tual no administrados premium: límites por disco
T IP O DE DISC O
DE P REM IUM
STO RA GE P 10 P 20 P 30 P 40 P 50
Tamaño del disco 128 GB 512 GB 1024 GiB (1 TB) 2048 GiB (2 TB) 4095 GiB (4 TB)
Número máximo 500 2,300 5.000 7500 7500

de IOPS por
disco
Rendimiento 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
máximo por
disco
Número máximo 280 70 35 17 8

de discos por
cuenta de
almacenamiento
Discos de máquina vir tual no administrados premium: límites por máquina vir tual
Número máximo de IOPS por máquina virtual 80 000 IOPS con máquina virtual GS5
Rendimiento máximo por máquina virtual 2000 MB/s con máquina virtual GS5
Límites del sistema StorSimple

IDEN T IF IC A DO R DE L ÍM IT ES L ÍM IT E C O M EN TA RIO S
Número máximo de credenciales de la 64

cuenta de almacenamiento
Número máximo de contenedores de 64

volúmenes
Número máximo de volúmenes 255
Número máximo de programaciones 168 Una programación para cada hora y

por plantilla de ancho de banda cada día de la semana.
Tamaño máximo de un volumen en 64 TB para StorSimple 8100 y StorSimple 8100 y StorSimple 8600
capas en dispositivos físicos StorSimple 8600 son dispositivos físicos.
Tamaño máximo de un volumen en 30 TB para StorSimple 8010 StorSimple 8010 y StorSimple 8020
capas en dispositivos virtuales de 64 TB para StorSimple 8020 son dispositivos virtuales de Azure que
Azure utilizan almacenamiento Standard y
almacenamiento Premium,
respectivamente.
Tamaño máximo de un volumen 9 TB para StorSimple 8100 StorSimple 8100 y StorSimple 8600
anclado localmente en dispositivos 24 TB para StorSimple 8600 son dispositivos físicos.
físicos
Número máximo de conexiones iSCSI 512
Número máximo de conexiones de 512

iSCSI de iniciadores
Número máximo de registros de 64

control de acceso por dispositivo
Número máximo de volúmenes por 24

directiva de copia de seguridad
Número máximo de copias de 64

seguridad por directiva de copia de
seguridad
Número máximo de programaciones 10

por directiva de copia de seguridad
Número máximo de instantáneas de 256 Esta cantidad incluye las instantáneas

cualquier tipo que se pueden retener locales y en la nube.
por volumen
Número máximo de instantáneas que 10 000

pueden estar presentes en cualquier
dispositivo
Número máximo de volúmenes que se 16 Si hay más de 16 volúmenes, se

pueden procesar en paralelo para procesarán secuencialmente a
copia de seguridad, restauración o medida que las ranuras de
clonación procesamiento estén
disponibles.
No se pueden realizar copias de
seguridad nuevas de un
volumen clonado o de un
volumen en capas restaurado
hasta que no haya finalizado la
operación. Para un volumen
local, se permiten las copias de
seguridad después de que el
volumen está en línea.
Tiempo de recuperación de la <2 minutos El volumen estará disponible en

restauración y la clonación dos minutos de una operación
de restauración o clonación,
independientemente del
tamaño del volumen.
Es posible que el rendimiento
del volumen resulte más lento
de lo normal inicialmente, ya
que la mayoría de los datos y
metadatos todavía residen en
la nube. Es posible que el
rendimiento aumente a medida
que los datos fluyan de la nube
al dispositivo StorSimple.
El tiempo total para descargar
los metadatos depende del
tamaño del volumen asignado.
Los metadatos se traen
automáticamente al dispositivo
en segundo plano a una
velocidad de 5 minutos por
cada TB de datos de volumen
asignado. Es posible que esta
velocidad se vea afectada por el
ancho de banda de Internet a
la nube.
La operación de restauración o
clonación se completará
cuando todos los metadatos
estén en el dispositivo.
No se pueden realizar
operaciones de copia de
seguridad hasta que se haya
completado totalmente la
operación de restauración o
clonación.
Restauración del tiempo de <2 minutos El volumen estará disponible en

recuperación de volúmenes anclados dos minutos de operación de
localmente restauración,
independientemente del
tamaño del volumen.
Es posible que el rendimiento
del volumen resulte más lento
de lo normal inicialmente, ya
que la mayoría de los datos y
metadatos todavía residen en
la nube. Es posible que el
rendimiento aumente a medida
que los datos fluyan de la nube
al dispositivo StorSimple.
El tiempo total para descargar
los metadatos depende del
tamaño del volumen asignado.
Los metadatos se traen
automáticamente al dispositivo
en segundo plano a una
velocidad de 5 minutos por
cada TB de datos de volumen
asignado. Es posible que esta
velocidad se vea afectada por el
ancho de banda de Internet a
la nube.
A diferencia de los volúmenes
en capas, si hay volúmenes
anclados localmente, también
se descargan los datos del
volumen localmente en el
dispositivo. La operación de
restauración finaliza cuando
todos los datos de volúmenes
se transfieren al dispositivo.
Las operaciones de
restauración pueden ser largas
y el tiempo total para
completar la restauración
dependerá del tamaño del
volumen local aprovisionado, el
ancho de banda de Internet y
los datos existentes en el
dispositivo. Se permiten las
operaciones de copia de
seguridad en el volumen
anclado localmente mientras la
operación de restauración está
en curso.
Disponibilidad de restauración fina Última conmutación por error
Rendimiento máximo de lectura y 920/720 MB/s con una única interfaz Hasta dos veces con MPIO y dos
escritura del cliente, cuando se obtiene de red Ethernet de 10 gigabits interfaces de red.
desde la capa SSD*
Rendimiento máximo de lectura y 120/250 MB/s

escritura del cliente, cuando se obtiene
desde la capa HDD*
Rendimiento máximo de lectura y 11/41 MB/s El rendimiento de lectura depende de

escritura de cliente, cuando se obtiene que los clientes generen y mantengan
desde la capa de la nube* una profundidad de cola de E/S
suficiente.
*Se ha medido el rendimiento máximo por tipo de E/S con escenarios de escritura y de lectura del 100 %. Es
posible que el rendimiento real sea inferior y dependa de las condiciones de la red y de la mezcla de E/S.
Límites de Stream Analytics

Número máximo de unidades de 500 Para solicitar un aumento de unidades

streaming por suscripción por región de streaming para la suscripción
superior a 500, póngase en contacto
con el Soporte técnico de Microsoft.
Número máximo de entradas por 60 Hay un límite máximo de 60 entradas

trabajo por trabajo de Azure Stream Analytics.
Número máximo de salidas por trabajo 60 Hay un límite máximo de 60 salidas

por trabajo de Stream Analytics.
Número máximo de funciones por 60 Hay un límite máximo de 60 funciones

trabajo por trabajo de Stream Analytics.
Número máximo de unidades de 192 Hay un límite máximo de 192 unidades

streaming por trabajo de streaming por trabajo de Stream
Analytics.
Número máximo de trabajos por 1500 Cada suscripción puede tener hasta
región 1500 trabajos por región geográfica.
MB del blob de datos de referencia 5 GB Hasta 5 GB al usar 6 unidades de

búsqueda o más.
Número máximo de caracteres 512 000 Hay un límite máximo de

incluidos en una consulta 512 000 caracteres en una consulta de
trabajo de Azure Stream Analytics.
Límites de Virtual Machines

Límites de Virtual Machines
Máquinas virtuales por servicio en la nube1 50
Punto de conexión de entrada por servicio en la nube2 150
1Las máquinas virtuales creadas mediante el modelo de implementación clásico, en lugar de mediante Azure
Resource Manager, se almacenan automáticamente en un servicio en la nube. Puede agregar más máquinas
virtuales a ese servicio en la nube para usarlas para el equilibrio de carga y la disponibilidad.
2Los puntos de conexión de entrada permiten las comunicaciones con una máquina virtual desde fuera del
servicio en la nube de la máquina virtual. Las máquinas virtuales en el mismo servicio en la nube o red virtual
pueden comunicarse automáticamente entre sí.
Límites de Virtual Machines: Azure Resource Manager
Los límites siguientes se aplican cuando se usa Azure Resource Manager y grupos de recursos de Azure.
Máquinas virtuales por suscripción 25 0001 por región.
Total de núcleos de máquina virtual por suscripción 201 por región. Póngase en contacto con el soporte técnico
para aumentar el límite.
Total de núcleos de máquina virtual de Azure Spot por 201 por región. Póngase en contacto con el soporte técnico
suscripción para aumentar el límite.
Máquina virtual por serie, como Dv2 y F, núcleos por 201 por región. Póngase en contacto con el soporte técnico
suscripción para aumentar el límite.
Conjuntos de disponibilidad por suscripción 2500 por región.
Máquinas virtuales por conjunto de disponibilidad 200
Grupos con ubicación por proximidad por grupo de recursos 800
Certificados por conjunto de disponibilidad 1992
Certificados por suscripción Ilimitados3
1 Los límites predeterminados varían según el tipo de categoría de la oferta, por

ejemplo, Evaluación gratuita o
Pago por uso, y por serie, como Dv2, F y G. Por ejemplo, el valor predeterminado de la suscripción Contrato
Enterprise es 350.
2 Las propiedades como las claves públicas SSH también se insertan como certificados y cuentan para este
límite. Para omitir este límite, use la extensión de Azure Key Vault para Windows o la extensión Azure Key Vault
para Linux para instalar los certificados.
3 Con Azure Resource Manager, los certificados se almacenan en Azure Key Vault. El número de certificados para
una suscripción es ilimitado. Hay un límite de 1 MB de certificados por implementación, que consta de una sola
máquina virtual o un conjunto de disponibilidad.
NOTE
Los núcleos de máquina virtual tienen un límite total regional. También tienen un límite para la serie regional por tamaño,
como Dv2 y F. Estos límites se aplican por separado. Por ejemplo, considere una suscripción con un límite total de núcleos
de máquinas virtuales de Este de EE. UU. de 30, un límite de núcleos de serie A de 30 y un límite de núcleos de serie D de
30. Esta suscripción puede implementar 30 máquinas virtuales A1 o 30 máquinas virtuales D1, o una combinación de
ambas, con tal de que no supere un total de 30 núcleos. Ejemplo de una combinación es 10 máquinas virtuales A1 y 20
máquinas virtuales D1.
Límites de Shared Image Gallery

Hay límites por suscripción, para implementar los recursos con las galerías de imágenes compartidas:
100 galerías de imágenes compartidas por suscripción, por región
1000 definiciones de imágenes por suscripción, por región
10 000 versiones de imágenes por suscripción, por región
Límites de los conjuntos de escalado de máquinas virtuales

Número máximo de máquinas virtuales en un conjunto de 1,000

escalas
Número máximo de máquinas virtuales en función de una 600

imagen de máquina virtual personalizada en un conjunto de
escalado
Número máximo de conjuntos de escala en una región 2500
Consulte también
Understand Azure limits and increases (Descripción de los límites de Azure y cómo aumentarlos)
Tamaños de máquina virtual y servicio en la nube de Azure
Tamaños para Azure Cloud Services
Reglas y restricciones de nomenclatura para los recursos de Azure

VPN Gateway

Cargado por

Copyright:

Formatos disponibles

VPN Gateway

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

VPN Gateway

Cargado por

Copyright:

Formatos disponibles

Contents

Documentación de VPN Gateway

¿Qué es una puerta de enlace de red virtual?

Configuración de una instancia de VPN Gateway

DE P UN TO A SIT IO DE SIT IO A SIT IO EXP RESSRO UT E

Protocolos admitidos Protocolo de túnel de IPsec Conexión directa a través

Enrutamiento RouteBased (dinámico) Admitimos elementos BGP

Resistencia de la activa-pasiva activa-pasiva o activa-activa activa-activa

Acuerdo de Nivel de Acuerdo de Nivel de Acuerdo de Nivel de Acuerdo de Nivel de

Precios Precios Precios Precios

Documentación técnica Documentación de VPN Documentación de VPN Documentación de

SKU de puerta de enlace

Generació Basic Máx. 10 Máx. 128 No 100 Mbps No No

Generació VpnGw5 Máx. 30* Máx. 128 Máx. 10 Gbps Compatible No

Generació VpnGw5A Máx. 30* Máx. 128 Máx. 10 Gbps Compatible Sí

Generación 1 VpnGw1 GCMAES256 650 MBps 58 000

Generación 1 VpnGw2 GCMAES256 1 Gbps 90 000

Generación 1 VpnGw3 GCMAES256 1,25 Gbps 105 000

Generación 1 VpnGw1AZ GCMAES256 650 MBps 58 000

Generación 1 VpnGw2AZ GCMAES256 1 Gbps 90 000

Generación 1 VpnGw3AZ GCMAES256 1,25 Gbps 105 000

Creación de una red virtual

4. En la página Red vir tual , seleccione Crear .

Espacio de direcciones IPv4 : de manera predeterminada, se crea automáticamente un espacio de

Creación de una puerta de enlace de VPN

Visualización de la dirección IP pública

Cambio del tamaño de la SKU de una puerta de enlace

3. Seleccione el SKU en la lista desplegable.

Restablecimiento de una puerta de enlace

En este tutorial, aprenderá a:

Creación de una red virtual

1. Inicie sesión en Azure Portal.

3. Seleccione Red vir tual en los resultados de Marketplace .

4. En la página Red vir tual , seleccione Crear .

Espacio de direcciones IPv4 : de manera predeterminada, se crea automáticamente un espacio de

Creación de una puerta de enlace de VPN

Visualización de la dirección IP pública

Creación de una puerta de enlace de red local

Nombre: especifique el nombre del objeto de puerta de enlace de red local.

Configuración del dispositivo VPN

Creación de una conexión VPN

Comprobación de la conexión VPN

Conexión a una máquina virtual

3. Seleccione el SKU en la lista desplegable.

Restablecimiento de una puerta de enlace

En la tabla siguiente se incluyen vínculos a scripts de Azure PowerShell:

SC RIP T DESC RIP C IÓ N

Descarga de la plantilla de dispositivos VPN Descargue la plantilla de dispositivos VPN.

# Create a resource group

Remove-AzResourceGroup -Name TestRG1

Explicación del script

Add-AzVirtualNetworkSubnetConfig Agrega una configuración de subred. Esta configuración se

Get-AzVirtualNetwork Obtiene los detalles de una red virtual.

New-AzResourceGroup Crea un grupo de recursos en el que se almacenan todos los

New-AzVirtualNetworkSubnetConfig Crea una configuración de subred. Esta configuración se

New-AzVirtualNetwork Crea una red virtual.

New-AzPublicIpAddress Crea una dirección IP pública.

New-AzVirtualNetworkGateway Crea una puerta de enlace de VPN.

Remove-AzResourceGroup Quita un grupo de recursos y todos los recursos incluidos en

Set-AzVirtualNetwork Establece la configuración de subred para la red virtual.