Descripción general del VPN IPsec
Una VPN es una red privada que usa una red pública para conectar dos o más sitios remotos. En lugar de usar conexiones exclusivas entre redes, las VPN usan conexiones virtuales enrutadas (de túnel) mediante redes públicas. El VPN IPsec es un protocolo que consta de un conjunto de estándares que se usan para establecer una conexión VPN.
Una VPN proporciona un medio mediante el cual los equipos remotos se comunican de forma segura a través de una WAN pública, como Internet.
Una conexión VPN puede enlazar dos LAN (VPN de sitio a sitio) o un usuario de marcado remoto y una LAN. El tráfico que fluye entre estos dos puntos pasa a través de recursos compartidos tales como enrutadores, conmutadores y otros equipos de red que forman la WAN pública. Para proteger la comunicación VPN mientras se pasa a través de la WAN, los dos participantes crean un túnel de seguridad IP (IPsec).
El término túnel no denota modo túnel (consulte Procesamiento de paquetes en modo túnel). En su lugar, hace referencia a la conexión IPsec.
Topologías VPN IPsec en firewalls serie SRX
A continuación, se muestran algunas de las topologías VPN de IPsec compatibles con el sistema operativo (OS) Junos:
VPN de sitio a sitio: conecta dos sitios de una organización y permite comunicaciones seguras entre los sitios.
VPN radiales: conectan las sucursales a la oficina corporativa en una red empresarial. También puede utilizar esta topología para conectar radios entre sí mediante el envío de tráfico a través del concentrador.
VPN de acceso remoto: permite que los usuarios que trabajan en casa o que viajan se conecten a la oficina corporativa y a sus recursos. Esta topología a veces se denomina .end-to-site tunnel
Consulte también
Comparación de VPN basadas en políticas y basadas en rutas
Es importante comprender las diferencias entre las VPN basadas en políticas y basadas en rutas, y por qué una puede ser preferible a la otra.
Tabla 1 enumera las diferencias entre las VPN basadas en rutas y las VPN basadas en políticas.
|
VPN basadas en ruta |
VPN basadas en políticas |
|---|---|
|
Con las VPN basadas en rutas, una política no hace referencia específicamente a un túnel VPN. |
Con los túneles VPN basados en políticas, un túnel se trata como un objeto que, junto con el origen, el destino, la aplicación y la acción, constituye una política de túnel que permite el tráfico VPN. |
|
La directiva hace referencia a una dirección de destino. |
En una configuración de VPN basada en políticas, una política de túnel hace referencia específicamente a un túnel VPN por nombre. |
|
El número de túneles VPN basados en rutas que cree estará limitado por el número de entradas de ruta o el número de interfaces st0 admitidas por el dispositivo, el número que sea menor. |
El número de túneles VPN basados en políticas que puede crear está limitado por el número de directivas admitidas por el dispositivo. |
|
La configuración de túnel VPN basada en rutas es una buena opción cuando desea conservar los recursos del túnel mientras establece restricciones granulares en el tráfico VPN. |
Con una VPN basada en políticas, aunque puede crear varias políticas de túnel que hagan referencia al mismo túnel VPN, cada par de políticas de túnel crea una asociación de seguridad (SA) IPsec individual con el par remoto. Cada SA cuenta como un túnel VPN individual. |
|
Con un enfoque basado en rutas para las VPN, la regulación del tráfico no está acoplada a los medios de su entrega. Puede configurar docenas de directivas para regular el tráfico que fluye a través de un único túnel VPN entre dos sitios, y solo hay una SA IPsec en funcionamiento. Además, una configuración de VPN basada en rutas le permite crear políticas que hagan referencia a un destino al que se llega a través de un túnel VPN en el que la acción es denegar. |
En una configuración VPN basada en políticas, la acción debe permitirse y debe incluir un túnel. |
|
Las VPN basadas en ruta admiten el intercambio de información de enrutamiento dinámico a través de túneles VPN. Puede habilitar una instancia de un protocolo de enrutamiento dinámico, como OSPF, en una interfaz st0 que esté enlazada a un túnel VPN. |
El intercambio de información de enrutamiento dinámico no se admite en las VPN basadas en políticas. |
|
Las configuraciones basadas en rutas se utilizan para las topologías radiales. |
Las VPN basadas en políticas no se pueden usar para topologías radiales. |
|
Con las VPN basadas en rutas, una política no hace referencia específicamente a un túnel VPN. |
Cuando un túnel no conecta redes grandes que ejecutan protocolos de enrutamiento dinámico y no es necesario conservar túneles ni definir varias políticas para filtrar el tráfico a través del túnel, la mejor opción es un túnel basado en políticas. |
|
Las VPN basadas en ruta no admiten configuraciones de VPN de acceso remoto (acceso telefónico). |
Los túneles VPN basados en políticas son necesarios para las configuraciones de VPN de acceso remoto (acceso telefónico). |
|
Es posible que las VPN basadas en rutas no funcionen correctamente con algunos proveedores externos. |
Es posible que se requieran VPN basadas en políticas si el tercero requiere SA independientes para cada subred remota. |
|
Cuando el dispositivo de seguridad realiza una búsqueda de ruta para encontrar la interfaz a través de la cual debe enviar tráfico para llegar a una dirección, encuentra una ruta a través de una interfaz de túnel seguro () , que está enlazada a un túnel VPN específico. Con un túnel de VPN basado en rutas, puede considerar un túnel como un medio para entregar el tráfico y puede considerar la política como un método para permitir o denegar la entrega de ese tráfico. |
Con un túnel VPN basado en políticas, puede considerar un túnel como un elemento en la construcción de una política. |
|
Las VPN basadas en rutas admiten NAT para interfaces st0. |
Las VPN basadas en políticas no se pueden usar si se requiere NAT para el tráfico tunelizado. |
El ID de proxy es compatible con VPN basadas en rutas y en políticas. Los túneles basados en rutas también ofrecen el uso de múltiples selectores de tráfico, también conocidos como ID de proxy múltiple. Un selector de tráfico es un acuerdo entre pares de IKE para permitir el tráfico a través de un túnel, si el tráfico coincide con un par especificado de prefijo de dirección IP local y remota, intervalo de puertos de origen, intervalo de puertos de destino y protocolo. Puede definir un selector de tráfico dentro de una VPN basada en ruta específica, lo que puede dar lugar a varias SA IPsec de fase 2. Solo se permite el tráfico que se ajuste a un selector de tráfico a través de una SA. El selector de tráfico suele ser necesario cuando los dispositivos de puerta de enlace remota no son dispositivos de Juniper Networks.
Las VPN basadas en políticas solo se admiten en SRX5400, SRX5600 y SRX5800 línea. La compatibilidad de plataforma depende de la versión de Junos OS en su instalación.
Consulte también
Comparación de VPN basadas en políticas y VPN basadas en ruta
Tabla 2 resume las diferencias entre las VPN basadas en políticas y las VPN basadas en ruta.
VPN basadas en políticas |
VPN basadas en ruta |
|---|---|
En las VPN basadas en políticas, un túnel se aborda como un objeto que, junto con el origen, el destino, la aplicación y la acción, constituye una política de túnel que permite el tráfico de VPN. |
En las VPN basadas en ruta, una política no hace referencia específicamente a un túnel VPN. |
Una política de túnel hace referencia específicamente a un túnel VPN por nombre. |
Una ruta determina qué tráfico se envía a través del túnel según una dirección IP de destino. |
La cantidad de túneles VPN basados en políticas que puede crear está limitada por la cantidad de túneles admitidos por el dispositivo. |
La cantidad de túneles VPN basados en rutas que puede crear está limitada por la cantidad de interfaces st0 (para VPN de punto a punto) o la cantidad de túneles admitidos por el dispositivo, la opción que tenga el menor valor. |
Con una VPN basada en políticas, aunque puede crear varias políticas de túnel que hagan referencia al mismo túnel de VPN, cada par de políticas de túnel creará una SA de IPsec individual con el par remoto. Cada SA cuenta como un túnel VPN individual. |
Dado que la ruta, no la política, determina qué tráfico pasa por el túnel, es posible que se admitan varias políticas con una sola SA o VPN. |
En una VPN basada en políticas, la acción se debe permitir y debe incluir un túnel. |
En una VPN basada en ruta, la regulación del tráfico no se asocia con los medios de su entrega. |
El intercambio de información de enrutamiento dinámico no se admite en las VPN basadas en políticas. |
Las VPN basadas en ruta admiten el intercambio de información de enrutamiento dinámico a través de túneles VPN. Puede habilitar una instancia de un protocolo de enrutamiento dinámico, como OSPF, en una interfaz st0 que esté enlazada a un túnel VPN. |
Si necesita más granularidad que la que puede proporcionar una ruta para especificar el tráfico que se envía a un túnel, la mejor opción es usar una VPN basada en políticas con políticas de seguridad. |
Las VPN basadas en ruta utilizan rutas para especificar el tráfico que se envía a un túnel; una política no hace referencia específicamente a un túnel VPN. |
Con un túnel VPN basado en políticas, puede considerar un túnel como un elemento en la construcción de una política. |
Cuando el dispositivo de seguridad realiza una búsqueda de ruta para encontrar la interfaz a través de la cual debe enviar tráfico para comunicarse con una dirección, encuentra una ruta a través de una interfaz de túnel seguro (st0). Con un túnel de VPN basado en rutas, puede considerar un túnel como un medio para entregar el tráfico y puede considerar la política como un método para permitir o denegar la entrega de ese tráfico. |
Descripción del procesamiento de paquetes de IKE e IPsec
Un túnel VPN de IPsec se compone de la configuración de túneles y la seguridad aplicada. Durante la instalación de túneles, los pares establecen asociaciones de seguridad (SA), las cuales definen los parámetros para proteger el tráfico entre ellos. (Véase Información general sobre IPsec.) Una vez establecido el túnel, IPsec protege el tráfico enviado entre los dos extremos del túnel aplicando los parámetros de seguridad definidos por las SA durante la configuración del túnel. Dentro de la implementación de Junos OS, IPsec se aplica en modo de túnel, el cual admite los protocolos Carga de seguridad de encapsulación (ESP) y Encabezado de autenticación (AH).
En este tema, se incluyen las siguientes secciones:
Procesamiento de paquetes en modo de túnel
IPsec funciona en uno de dos modos: transporte o túnel. Cuando ambos extremos del túnel son hosts, puede utilizar cualquiera de los modos. Cuando al menos uno de los puntos de conexión de un túnel es una puerta de enlace de seguridad, como un enrutador o firewall de Junos OS, debe utilizar el modo de túnel. Los dispositivos Juniper Networks funcionan siempre en modo de túnel para túneles IPsec.
En el modo de túnel, todo el paquete IP original (carga y encabezado) se encapsula dentro de otra carga IP y se le anexa un nuevo encabezado, como se muestra en .Figura 1 El paquete original completo puede cifrarse, autenticarse o ambas cosas. Con el protocolo Encabezado de autenticación (AH), también se autentican el AH y los nuevos encabezados. Con el protocolo Carga de seguridad de encapsulación (ESP), también se puede autenticar el encabezado ESP.
En una VPN de sitio a sitio, las direcciones de origen y destino utilizadas en el nuevo encabezado son las direcciones IP de la interfaz de salida. Consulte Figura 2.
En una VPN de marcado, no existe una puerta de enlace de túnel en el extremo del túnel del cliente de marcado VPN; el túnel se extiende directamente al propio cliente (consulte Figura 3). En este caso, en los paquetes enviados desde el cliente de marcado, tanto el encabezado nuevo como el original encapsulado tienen la misma dirección IP: la del ordenador del cliente.
Algunos clientes VPN, como Netscreen-Remote , utilizan una dirección IP interna virtual (también llamada "dirección adhesiva"). NetScreen-Remote le permite definir la dirección IP virtual. En estos casos, la dirección IP interna virtual es la dirección IP de origen en el encabezado del paquete original del tráfico que se origina en el cliente, y la dirección IP que el ISP asigna dinámicamente al cliente de marcado es la dirección IP de origen en el encabezado exterior.
Consulte también
Distribución de sesiones de IKE e IPsec en SPU
En los dispositivos SRX5400, SRX5600 y SRX5800, IKE proporciona administración de túnel para IPsec y autentica a las entidades finales. IKE realiza un intercambio de claves Diffie-Hellman (DH) para generar un túnel IPsec entre los dispositivos de red. Los túneles IPsec generados por IKE se utilizan para cifrar, descifrar y autenticar el tráfico de usuario entre los dispositivos de red en la capa IP.
La VPN se crea mediante la distribución de la IKE y de la carga de trabajo de IPsec entre las distintas unidades de procesamiento de servicios (SPU) de la plataforma. En el caso de los túneles de sitio a sitio, la SPU con menor carga se elige como la SPU de ancla. Si varias SPU tienen la misma carga mínima, cualquiera de ellas puede elegirse como una SPU de ancla. En este caso, la carga corresponde a la cantidad de puertas de enlace de sitio a sitio o de túneles VPN manuales anclados en una SPU. En el caso de túneles dinámicos, los túneles dinámicos recién establecidos emplean un algoritmo de funcionamiento rotativo para seleccionar la SPU.
En IPsec, la carga de trabajo se distribuye con el mismo algoritmo que distribuye la IKE. La SA de fase 2 para un par de puntos de terminación de túnel de VPN determinado es propiedad exclusiva de una SPU en concreto, y todos los paquetes IPsec que pertenecen a esta SA de fase 2 se reenvían a la SPU de ancla de esa SA para el procesamiento de IPsec.
Varias sesiones de IPsec (SA de fase 2) pueden funcionar a través de una o más sesiones IKE. La SPU que se selecciona para anclar la sesión IPsec se basa en la SPU que ancla la sesión de IKE subyacente. Por lo tanto, todas las sesiones IPsec que se ejecutan en una sola puerta de enlace de IKE reciben servicio mediante la misma SPU y no tienen un equilibrio de carga en varias SPU.
Tabla 3 muestra un ejemplo de una línea SRX5000 con tres SPU que ejecutan siete túneles IPsec en tres puertas de enlace IKE.
SPU |
Puerta de enlace IKE |
Túnel IPsec |
|---|---|---|
SPU0 |
IKE-1 |
IPsec-1 |
IPsec-2 |
||
IPsec-3 |
||
SPU1 |
IKE-2 |
IPsec-4 |
IPsec-5 |
||
IPsec-6 |
||
SPU2 |
IKE-3 |
IPsec-7 |
Las tres SPUs tienen una carga igual de una puerta de enlace ICR cada uno. Si se crea una nueva puerta de enlace de IKE, puede seleccionar SPU0, SPU1 o SPU2 para anclar la puerta de enlace de IKE y sus sesiones IPsec.
La configuración y el desactivamiento de túneles IPsec existentes no afectan a la sesión de IKE subyacente ni a los túneles IPsec existentes.
Utilice el siguiente comando show para ver el recuento actual de túneles por SPU: show security ike tunnel-map.
Utilice la opción summary del comando para ver los puntos de anclaje de cada puerta de enlace: show security ike tunnel-map summary.
Compatibilidad de VPN para insertar tarjetas de procesamiento de servicios
Los dispositivos SRX5400, SRX5600 y SRX5800 tienen una arquitectura de procesador distribuido basada en chasis. La potencia de procesamiento de flujo se comparte y se basa en la cantidad de tarjetas de procesamiento de servicios (SPC). Puede escalar la potencia de procesamiento del dispositivo instalando nuevas SPC.
En un clúster de chasis SRX5400, SRX5600 o SRX5800, puede insertar nuevas SPC en los dispositivos sin afectar ni interrumpir el tráfico en los túneles VPN de IPsec o IKE existentes. Cuando se inserta una nueva SPC en cada chasis del cluster, los túneles existentes no se ven afectados y el tráfico sigue fluyendo sin interrupciones.
A partir de Junos OS versión 19.4R1, en todos los clústeres de chasis de SRX5000 línea, puede insertar una nueva tarjeta SRX5K-SPC3 (SPC3) o SRX5K-SPC-4-15-320 (SPC2) en un chasis existente que contenga una tarjeta SPC3. Solo puede insertar las tarjetas en un área superior a la de la tarjeta SPC3 existente en el chasis. Debe reiniciar el nodo después de insertar la SPC3 para activar la tarjeta. Una vez completado el reinicio del nodo, se distribuyen los túneles IPsec a las tarjetas.
Sin embargo, los túneles existentes no pueden usar la potencia de procesamiento de las unidades de procesamiento de servicio (SPU) en la nueva SPC. Una nueva SPU puede anclar túneles dinámicos y de sitio a sitio recién establecidos. Sin embargo, no se garantiza que los túneles recién configurados estén anclados a una nueva SPU.
Los túneles de sitio a sitio se anclan a diferentes SPU según un algoritmo de equilibrio de carga. El algoritmo de equilibrio de carga depende de los subprocesos de flujo de número que utiliza cada SPU. Los túneles que pertenecen a las mismas direcciones IP de puerta de enlace local y remota se anclan a la misma SPU con diferentes subprocesos de flujo RT utilizados por la SPU. La SPU con la carga más pequeña se elige como la SPU de ancla. Cada SPU mantiene una cantidad de subprocesos de flujo RT que se alojan en esa SPU en particular. El número de subprocesos de flujo RT alojados en cada SPU varía según el tipo de SPU.
Factor de carga de túnel = Cantidad de túneles anclados en la SPU / Cantidad total de subprocesos de flujo RT utilizados por la SPU.
Los túneles dinámicos se anclan en diferentes SPU según un algoritmo de operación rotativa. No se garantiza que los túneles recién configurados estén anclados a la nueva SPC.
A partir de Junos OS versión 18.2R2 y 18.4R1, todas las funciones de VPN IPsec existentes que actualmente se admiten en SRX5K-SPC3 (SPC3) solo se admitirán en dispositivos SRX5400, SRX5600 y SRX5800 cuando haya tarjetas SRX5K-SPC-4-15-320 (SPC2) y SPC3 instaladas y funcionando en el dispositivo en modo de clúster de chasis o en modo independiente.
Cuando se instalan tarjetas SPC2 y SPC3, puede comprobar la asignación de túnel en diferentes SPU mediante el comando show security ipsec tunnel-distribution.
Use el comando show security ike tunnel-map para ver la asignación de túnel en diferentes SPU con solo la tarjeta SPC2 insertada. El comando show security ike tunnel-map no es válido en un entorno en el cual hay tarjetas SPC2 y SPC3 instaladas.
Insertando la tarjeta SPC3: Directrices y limitaciones:
-
En un clúster de chasis, si uno de los nodos tiene una tarjeta SPC3 y el otro nodo tiene 2 tarjetas SPC3, no se admite la conmutación por error al nodo que tiene una tarjeta SPC3.
-
Debe insertar la SPC3 o la SPC2 en un chasis existente en una ranura más alta que una tarjeta SPC3 actual presente en una ranura inferior.
-
Para que SPC3 ISHU funcione, debe insertar la nueva tarjeta SPC3 en el número de la ranura superior.
-
En el clúster de chasis SRX5800, no debe insertar la tarjeta SPC3 en la ranura más alta (ranura nro. 11) debido al límite de alimentación y distribución de calor.
-
No se admite la extracción de calor de SPC3.
resume la línea SRX5000 con tarjeta SPC2 o SPC3 que admite o procesa:Tabla 4kmdiked
|
Línea SRX5000 |
Soporte para o Proceso |
|---|---|
|
SRX5000 línea con solo tarjeta SPC2 instalada |
Apoya el proceso. |
|
SRX5000 línea con solo tarjeta SPC3 instalada |
Apoya el proceso. |
|
SRX5000 línea con tarjetas SPC2 y SPC3 instaladas |
Apoya el proceso. |
Consulte también
Compatibilidad con aceleración criptográfica en tarjetas SRX5K-SPC3, plataformas SRX de gama media y firewall virtual vSRX
SRX5000 línea con la tarjeta SRX5K-SPC3 (tarjeta de procesamiento de servicios), las plataformas de gama media SRX (firewalls de las series SRX4100, SRX4200, SRX1500 y SRX4600) y el firewall virtual vSRX requiere un paquete como software de plano de control para instalar y habilitar las funciones de VPN IPsec.junos-ike
-
En SRX5000 línea con RE3, de forma predeterminada, el paquete se instala en Junos OS versiones 20.1R2, 20.2R2, 20.3R2, 20.4R1 y posteriores.
junos-ikeComo resultado, el proceso se ejecuta en el motor de enrutamiento de forma predeterminada en lugar del demonio de administración de claves IPsec (kmd).ikedikemd La línea SRX5000 con SRX5K-SPC3 descarga las operaciones criptográficas al motor criptográfico de hardware. -
Las plataformas de rango medio SRX que cubren firewalls de las series SRX1500, SRX4100, SRX4200 y SRX4600, descargan las operaciones criptográficas DH, RSA y ECDSA al motor criptográfico de hardware con dispositivos que ejecutan software.
junos-ikeEsta función está disponible en Junos OS versión 23.2R1 con dispositivos que tienen paquete instalado.junos-ikeLos dispositivos que continúan ejecutando software heredado (proceso kmd) no admiten esta característica.iked -
En el firewall virtual vSRX, el subproceso de CPU del plano de datos descarga las operaciones DH, RSA y ECDSA. La aceleración de hardware no está disponible en estos dispositivos. Esta función está disponible en Junos OS versión 23.2R1 con el paquete instalado en el dispositivo.
junos-ike
El describe la compatibilidad de aceleración de hardware para varios cifrados:Tabla 5
| Cifras | SRX1500 | SRX4100/SRX4200 | SRX4600 | SRX5K - SPC3 | vSRX3.0 | ||||
|---|---|---|---|---|---|---|---|---|---|
| KMD | IN.IKED | KMD | IN.IKED | KMD | IN.IKED | IN.IKED | KMD | IN.IKED | |
| DH (Grupos 1, 2, 5, 14) | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| DH (Grupos 19, 20) | No | Sí | No | Sí | No | Sí | Sí | Sí | Sí |
| DH (Grupos 15, 16) | No | Sí | No | Sí | No | Sí | Sí | Sí | Sí |
| Grupo DH 21 | No | Sí | No | Sí | No | Sí | Sí | Sí | Sí |
| Grupo DH 24 | Sí | Sí | Sí | Sí | Sí | Sí | No | No | No |
| RSA | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
| ECDSA (256, 384, 521) | No | Sí | No | Sí | No | Sí | Sí | Sí | Sí |
Para instalar el paquete IKE de Junos en el firewall de la serie SRX, utilice el siguiente comando:
user@host> request system software add optional://junos-ike.tgz Verified junos-ike signed by PackageProductionECP256_2022 method ECDSA256+SHA256 Rebuilding schema and Activating configuration... mgd: commit complete Restarting MGD ... WARNING: cli has been replaced by an updated version: CLI release 20220208.163814_builder.r1239105 built by builder on 2022-02-08 17:07:55 UTC Restart cli using the new version ? [yes,no] (yes)
Para utilizar el proceso con el fin de habilitar las características VPN IPsec en SRX5000 línea sin una tarjeta SPC3, debe ejecutar el comando.kmdrequest system software delete junos-ike Después de ejecutar el comando, reinicie el dispositivo.
Para comprobar el paquete junos-ike instalado, utilice el siguiente comando:
user@host> show version | grep ike
JUNOS ike [20190617.180318_builder_junos_182_x41]
JUNOS ike [20190617.180318_builder_junos_182_x41]
{primary:node0}
Consulte también
Compatibilidad de la característica VPN IPsec con el nuevo paquete
Los dos procesos y admiten las características de VPN IPsec en los firewalls de la serie SRX.ikedikemd Una sola instancia de y ejecutarse en el motor de enrutamiento a la vez.ikedikemd
De forma predeterminada, el paquete se instala en Junos OS versión 19.4R1 y posteriores para SRX5K-SPC3 con RE3.junos-ike Tanto los procesos como los que se ejecutan en el motor de enrutamiento están disponibles con este paquete.ikedikemd En SRX5K-SPC3 con RE2, este es un paquete opcional y debe instalarse explícitamente.
Para reiniciar el proceso en el motor de rutina, utilice el comando.ikemdrestart ike-config-management
Para reiniciar el proceso en el motor de enrutamiento, utilice el comando.ikedrestart ike-key-management
muestra los detalles de las versiones de Junos OS en las que se introdujo el paquete.Tabla 6junos-ike
|
Plataforma |
Versión de Junos OS con paquete |
|---|---|
|
SRX5K-SPC3 con RE3 |
19.4R1 y versiones posteriores como paquete predeterminado |
|
SRX5K-SPC3 con RE2 |
18.2R1 y posteriores como paquete opcional |
|
Firewall virtual vSRX |
20.3R1 y posterior como paquete opcional |
|
SRX1500 |
22.3R1 y versiones posteriores como paquete opcional |
|
SRX4100, SRX4200 SRX4600 |
22.3R1 y versiones posteriores como paquete opcional |
|
SRX1600, SRX2300 |
23.4R1 y versiones posteriores como paquete predeterminado |
Si no se tienen en cuenta las versiones de lanzamiento de Junos OS especificadas al instalar el paquete, es posible que las funciones no compatibles no funcionen como se esperaba.junos-ike
Para operar las características de VPN IPsec mediante el proceso heredado en línea SRX5000 sin una tarjeta SRX5K-SPC3, debe ejecutar el comando y reiniciar el dispositivo.kmdrequest system software delete junos-ike
No se admiten las características de VPN IPsec
En esta sección se proporciona un resumen de las características y configuraciones de VPN IPsec que no se admiten en SRX5000 línea con SRX5K-SPC3 y en instancias de Firewall virtual vSRX.
Para determinar si una característica es compatible con una plataforma específica o una versión de Junos OS, consulte el Explorador de características.
Tabla 7 resume las funciones de VPN IPsec no compatibles en los firewalls de la serie SRX y el firewall virtual vSRX que ejecutan el proceso iked:
|
Características |
Soporte en SRX5000 línea con instancias de firewall virtual SRX5K-SPC3 y vSRX |
|---|---|
|
Modo punto a multipunto de multidifusión de protocolo independiente (PIM) de AutoVPN. |
No |
|
Configurar clase de reenvío en VPN IPsec. |
No |
|
VPN de grupo. |
No |
|
Configuración del tamaño de paquete para la comprobación de ruta de datos de IPsec. |
No |
|
VPN IPsec basada en políticas. |
No |
Compatibilidad de protocolos de enrutamiento en túneles VPN IPsec
Admitimos protocolos de enrutamiento como OSPF, BGP, PIM, RIP y BFD para que se ejecuten en túneles IPsec en firewalls de la serie SRX y enrutadores de la serie MX en kmdejecución o ikeden procesos. La compatibilidad con el protocolo varía según el esquema de direccionamiento IP o el tipo de interfaz st0, punto a punto (P2P) o punto a multipunto (P2MP).
Tabla 8 resume la compatibilidad del protocolo OSPF en firewalls serie SRX y enrutadores MX.
| OSPF | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | Sí | No | Sí | No |
| SRX5K-SPC3 | Sí | No | Sí | No |
| SRX5K en modo mixto (SPC3 + SPC2) | Sí | No | Sí | No |
| Firewall virtual vSRX 3.0 | Sí | No | Sí | No |
| MX-SPC3 | Sí | No | No | No |
Tabla 9 resume la compatibilidad del protocolo OSPFv3 en firewalls serie SRX y enrutadores MX.
| OSPFv3 | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | No | Sí | No | Sí |
| SRX5K-SPC3 | No | Sí | No | Sí |
| SRX5K en modo mixto (SPC3 + SPC2) | No | Sí | No | Sí |
| Firewall virtual vSRX 3.0 | No | Sí | No | Sí |
| MX-SPC3 | No | Sí | No | No |
Tabla 10 resume la compatibilidad del protocolo BGP en firewalls serie SRX y enrutadores MX.
| protocolo de puerta de enlace de frontera (BGP) | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | Sí | Sí | Sí | Sí |
| SRX5K-SPC3 | Sí | Sí | Sí | Sí |
| SRX5K en modo mixto (SPC3 + SPC2) | Sí | Sí | Sí | Sí |
| Firewall virtual vSRX 3.0 | Sí | Sí | Sí | Sí |
| MX-SPC3 | Sí | Sí | No | No |
Tabla 11 resume la compatibilidad del protocolo PIM en firewalls de la serie SRX y enrutadores MX.
| PIM | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX550 HM, SRX650, SRX1400, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | Sí | No | No | No |
| SRX300, SRX320, SRX340, SRX345, SRX380 y SRX1500 | Sí | No | Sí | No |
| SRX5K-SPC3 | Sí | No | No | No |
| SRX5K en modo mixto (SPC3 + SPC2) | Sí | No | No | No |
| Firewall virtual vSRX | Sí | No | Sí Nota:
No se admite el subproceso múltiple. |
No |
| MX-SPC3 | Sí | No | No | No |
Tabla 12 resume la compatibilidad del protocolo RIP en firewalls de la serie SRX y enrutadores MX.
| RIP | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | Sí | Sí | No | No |
| SRX5K-SPC3 | Sí | Sí | No | No |
| SRX5K en modo mixto (SPC3 + SPC2) | Sí | Sí | No | No |
| Firewall virtual vSRX 3.0 | Sí | Sí | No | No |
| MX-SPC3 | Sí | Sí | No | No |
Tabla 13 resume la compatibilidad del protocolo BFP en firewalls serie SRX y enrutadores MX.
| BFD | ||||
|---|---|---|---|---|
| Dispositivos | P2P | P2MP | ||
| IPv4 | IPv6 | IPv4 | IPv6 | |
| SRX100, SRX110, SRX210, SRX220, SRX240, SRX300, SRX320, SRX340, SRX345, SRX380, SRX550, SRX550 HM, SRX650, SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600 y SRX5K-SPC2 | Sí | Sí | Sí | Sí |
| SRX5K-SPC3 | Sí | Sí | Sí | Sí |
| SRX5K en modo mixto (SPC3 + SPC2) | Sí | Sí | Sí | Sí |
| Firewall virtual vSRX 3.0 | Sí | Sí | Sí | Sí |
| MX-SPC3 | Sí | Sí | No | No |
Ventana anti-reproducción
En los firewalls de la serie SRX, está habilitado de forma predeterminada con un valor de tamaño de ventana de 64.anti-replay-window
En la línea SRX Series 5000 con tarjetas SPC3 instaladas, puede configurar el tamaño en el rango de 64 a 8192 (potencia de 2).anti-replay-window Para configurar el tamaño de la ventana, utilice la nueva opción.anti-replay-window-size Un paquete entrante se valida para ataques de reproducción en función de lo que está configurado.anti-replay-window-size
Puede configurar en dos niveles diferentes:replay-window-size
-
: configurado en el nivel de jerarquía [].Global level
edit security ipsecPor ejemplo:
[edit security ipsec] user@host# set anti-replay-window-size <64..8192>;
-
: configurado en el nivel de jerarquía [].VPN object
edit security ipsec vpn vpn-name ikePor ejemplo:
[edit security ipsec vpn vpn-name ike] user@host# set anti-replay-window-size <64..8192>;
Si se configura la antirreproducción en ambos niveles, el tamaño de ventana configurado para un nivel de objeto VPN tiene prioridad sobre el tamaño de ventana configurado en el nivel global. Si la antirreproducción no está configurada, el tamaño de la ventana es 64 de forma predeterminada.
Para deshabilitar la opción de ventana antirreproducción en un objeto VPN, utilice el comando en el nivel de jerarquía [].set no-anti-replayedit security ipsec vpn vpn-name ike No puede deshabilitar la antirreproducción a nivel global.
No puede configurar ambos y en un objeto VPN.anti-replay-window-sizeno-anti-replay
Consulte también
Descripción de VPN radiales
Si crea dos túneles VPN que terminan en un dispositivo, puede configurar un par de rutas para que el dispositivo dirija el tráfico que sale de un túnel hacia el otro túnel. También debe crear una política para permitir que el tráfico pase de un túnel al otro. Dicha disposición se conoce como VPN radial. (Consulte Figura 4.)
También puede configurar varias VPN y enrutar el tráfico entre dos túneles.
Los firewalls de la serie SRX solo admiten la función radial basada en rutas.
Consulte también
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice Feature Explorer a fin de determinar si una función es compatible con la plataforma.
junos-ike Como resultado, el proceso se ejecuta en el motor de enrutamiento de forma predeterminada en lugar del demonio de administración de claves IPsec (kmd).ikedikemd