NetScreen conceptos y ejemplos: Volumen 5 ... - Juniper Networks

NetScreen conceptos y ejemplos 

Manual de referencia de ScreenOS 

Volumen 5: VPNs 

ScreenOS 5.1.0 

Ref. 093-1370-000-SP 

Revisión B

Copyright Notice 

Copyright © 2004 Juniper Networks, Inc. All rights reserved. 

Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen 

Technologies, GigaScreen, and the NetScreen logo are registered trademarks 

of Juniper Networks, Inc. NetScreen-5GT, NetScreen-5XP, NetScreen-5XT, 

NetScreen-25, NetScreen-50, NetScreen-100, NetScreen-204, NetScreen-208, 

NetScreen-500, NetScreen-5200, NetScreen-5400, NetScreen-Global PRO, 

NetScreen-Global PRO Express, NetScreen-Remote Security Client, 

NetScreen-Remote VPN Client, NetScreen-IDP 10, NetScreen-IDP 100, 

NetScreen-IDP 500, GigaScreen ASIC, GigaScreen-II ASIC, and NetScreen 

ScreenOS are trademarks of Juniper Networks, Inc. All other trademarks and 

registered trademarks are the property of their respective companies. 

Information in this document is subject to change without notice. 

No part of this document may be reproduced or transmitted in any form or by 

any means, electronic or mechanical, for any purpose, without receiving written 

permission from: 

Juniper Networks, Inc. 

ATTN: General Counsel 

1194 N. Mathilda Ave. 

Sunnyvale, CA 94089-1206 

FCC Statement 

The following information is for FCC compliance of Class A devices: This 

equipment has been tested and found to comply with the limits for a Class A 

digital device, pursuant to part 15 of the FCC rules. These limits are designed to 

provide reasonable protection against harmful interference when the equipment 

is operated in a commercial environment. The equipment generates, uses, and 

can radiate radio-frequency energy and, if not installed and used in accordance 

with the instruction manual, may cause harmful interference to radio 

communications. Operation of this equipment in a residential area is likely to 

cause harmful interference, in which case users will be required to correct the 

interference at their own expense. 

The following information is for FCC compliance of Class B devices: The 

equipment described in this manual generates and may radiate radio-frequency 

energy. If it is not installed in accordance with NetScreen’s installation 

instructions, it may cause interference with radio and television reception. This 

equipment has been tested and found to comply with the limits for a Class B 

digital device in accordance with the specifications in part 15 of the FCC rules. 

These specifications are designed to provide reasonable protection against 

such interference in a residential installation. However, there is no guarantee 

that interference will not occur in a particular installation. 

If this equipment does cause harmful interference to radio or television 

reception, which can be determined by turning the equipment off and on, the 

user is encouraged to try to correct the interference by one or more of the 

following measures: 

• Reorient or relocate the receiving antenna. 

• Increase the separation between the equipment and receiver. 

• Consult the dealer or an experienced radio/TV technician for help. 

• Connect the equipment to an outlet on a circuit different from that to 

which the receiver is connected. 

Caution: Changes or modifications to this product could void the user's 

warranty and authority to operate this device. 

Disclaimer 

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE 

ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION 

PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED 

HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE 

SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR 

NETSCREEN REPRESENTATIVE FOR A COPY.

Contenido 

Contenido 

Prefacio ......................................................................... v 

Convenciones ........................................................... vi 

Convenciones de la interfaz de línea 

de comandos (CLI) ...................................................... vi 

Convenciones de la interfaz gráfica (WebUI)..............vii 

Convenciones para las ilustraciones........................... ix 

Convenciones de nomenclatura y conjuntos de 

caracteres .................................................................... x 

Documentación de NetScreen 

de Juniper Networks .................................................. xi 

Capítulo 1 IPSec ...........................................................1 

Introducción a las VPNs..............................................2 

Conceptos de IPSec...................................................3 

Modos...........................................................................4 

Modo de transporte ...............................................4 

Modo de túnel........................................................5 

Protocolos .....................................................................7 

AH...........................................................................7 

ESP..........................................................................8 

Administración de claves .............................................9 

Clave manual ........................................................9 

AutoKey IKE.............................................................9 

Asociación de seguridad ...........................................10 

Negociación de túnel ..............................................11 

Fase 1 .........................................................................11 

Modo principal y modo dinámico .......................12 

Intercambio Diffie-Hellman...................................13 

Fase 2......................................................................... 13 

Confidencialidad directa perfecta ..................... 15 

Protección contra reprocesamiento.................... 15 

Paquetes IKE e IPSec ................................................16 

Paquetes IKE............................................................... 16 

Paquetes IPSec........................................................... 20 

Capítulo 2 Criptografía de claves públicas ...............23 

Introducción a la criptografía de claves públicas...24 

PKI.............................................................................26 

Certificados y CRLs...................................................29 

Obtención manual de un certificado........................ 30 

Ejemplo: Petición de certificado manual ............ 31 

Ejemplo: Carga de certificados y CRLs ............... 34 

Ejemplo: Configuración de ajustes de CRL ......... 36 

Obtención automática de un certificado local ........ 38 

Ejemplo: Petición automática de certificado...... 39 

Renovación automática de certificado .................... 43 

Generación de pares de claves ......................... 43 

Comprobación de estado mediante OCSP.............44 

Configuración de OCSP............................................. 45 

Especificación de CRL u OCSP ............................ 45 

Visualización de los atributos de comprobación 

de estado ............................................................ 45 

Especificación de la URL de un servidor 

de respuesta OCSP .............................................. 46 

Eliminación de atributos de comprobación 

de estado ............................................................ 46 

Certificados autofirmados (“Self-Signed 

Certificates”).............................................................47 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs i

Contenido 

Asegurar el tráfico administrativo con SSL ..................48 

Validación de certificados...................................49 

Creación manual de certificados autofirmados..51 

Ejemplo: Certificado autofirmado y definido 

por el administrador.............................................53 

Autogeneración de certificados ..........................58 

Eliminación de certificados autofirmados............60 

Capítulo 3 Directivas VPN ...........................................61 

Opciones criptográficas...........................................62 

Opciones criptográficas punto a punto.....................63 

Opciones VPN de acceso telefónico .........................72 

Túneles basados en directivas y en rutas.................80 

Flujo de paquetes: VPN punto a punto ....................82 

Consejos para la configuración de un túnel ...........90 

Consideraciones sobre seguridad en VPNs 

basadas en rutas .....................................................93 

Ruta nula ....................................................................94 

Línea de acceso telefónico o arrendada..................96 

Ejemplo: Conmutación por error de la VPN 

hacia la línea arrendada o la ruta nula ..............97 

Interfaz de túnel ficticia ............................................100 

Enrutador virtual para interfaces de túnel ................101 

Reencaminar a otro túnel.........................................101 

Capítulo 4 VPNs punto a punto ................................103 

Configuraciones VPN punto a punto......................104 

Pasos de configuración de túneles punto a punto ..105 

Ejemplo: VPN punto a punto basada en rutas, 

AutoKey IKE.........................................................111 

Ejemplo: VPN punto a punto basada 

en directivas, AutoKey IKE ..................................126 

Ejemplo: VPN punto a punto basada en rutas, 

interlocutor dinámico ........................................ 137 


en directivas, interlocutor dinámico .................. 152 


en rutas, clave manual...................................... 166 


en directivas, clave manual .............................. 177 

Puertas de enlace IKE dinámicas con FQDN .........186 

Alias.......................................................................... 187 

Ejemplo: Interlocutor AutoKey IKE con FQDN ..... 188 

Sitios VPN con direcciones superpuestas ...............203 

Ejemplo: Interfaz de túnel con NAT-Src 

y NAT-Dst ............................................................ 206 

VPN en modo transparente ....................................221 

Ejemplo: VPN AutoKey IKE basada en 

directivas en modo transparente ...................... 222 

Capítulo 5 VPNs de acceso telefónico.....................233 

VPNs de acceso telefónico ....................................234 

Ejemplo: VPN de acceso telefónico basada 

en directivas, AutoKey IKE.................................. 235 


en rutas, interlocutor dinámico.......................... 244 


en directivas, interlocutor dinámico .................. 256 

Directivas bidireccionales para usuarios de VPN 

de acceso telefónico .............................................. 266 

Ejemplo: Directivas bidireccionales para VPNs 

de acceso telefónico ........................................ 267 

Identificación IKE de grupo....................................275 

Identificación IKE de grupo con certificados........... 276 

Tipos de identificación IKE ASN1-DN Wildcard 

y Container ........................................................ 278 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs ii

Contenido 

Ejemplo: Identificación IKE de grupo 

(certificados) ......................................................281 

ID IKE de grupo con claves previamente 

compartidas .............................................................288 

Ejemplo: ID IKE de grupo (claves 

previamente compartidas) ................................290 

Identificación IKE compartida................................297 

Ejemplo: ID IKE compartida (claves 

previamente compartidas) ................................298 

Capítulo 6. L2TP .........................................................307 

Introducción al L2TP ...............................................308 

Encapsulado y desencapsulado de paquetes .....312 

Encapsulado ............................................................312 

Desencapsulado ......................................................313 

Parámetros L2TP......................................................314 

Ejemplo: Configuración de un conjunto de 

direcciones IP y los ajustes predeterminados 

L2TP.....................................................................315 

L2TP y L2TP sobre IPSec...........................................317 

Ejemplo: Configuración de L2TP ........................318 

Ejemplo: Configuración de L2TP sobre IPSec .....326 

Ejemplo: L2TP bidireccional sobre IPSec ............339 

Capítulo 7. Funciones de VPN avanzadas ................349 

NAT-Traversal ..........................................................351 

Sondeos de NAT........................................................352 

Atravesar un dispositivo NAT .....................................354 

Suma de comprobación de UDP .............................357 

Paquetes de mantenimiento de conexión...............357 

Simetría iniciador/respondedor ................................358 

Ejemplo: Habilitación de NAT-Traversal ..............359 

Supervisión de VPNs................................................361 

Opciones de reencriptación y optimización ........... 362 

Interfaz de origen y dirección de destino................ 363 

Consideraciones sobre directivas............................ 365 

Configuración de la función de supervisión 

de VPN ..................................................................... 365 

Ejemplo: Especificación de las direcciones de 

origen y destino para la supervisión de VPN ..... 368 

Objetos y capturas SNMP para la supervisión 

de VPN ..................................................................... 380 

Múltiples túneles por interfaz de túnel ....................381 

Asignación de rutas a túneles.................................. 382 

Direcciones de interlocutores remotos..................... 383 

Entradas de tabla manuales y automáticas............ 385 

Entradas manuales en la tabla ......................... 385 

Entradas automáticas en la tabla ..................... 386 

Ejemplo: Múltiples VPNs en una interfaz 

de túnel para subredes superpuestas ............... 388 

Ejemplo: Entradas automáticas en la tabla 

de rutas y la tabla NHTB..................................... 420 

Anexo al ejemplo: OSPF para entradas 

automáticas en la tabla de rutas ...................... 438 

Puertas de enlace VPN redundantes .....................441 

Grupos VPN .............................................................. 442 

Mecanismos de supervisión ..................................... 443 

Latidos de IKE..................................................... 443 

Procedimiento de recuperación IKE.................. 444 

Comprobación de flag TCP SYN .............................. 447 

Ejemplo: Puertas de enlace VPN redundantes .. 448 

VPNs adosadas.......................................................460 

Ejemplo: VPNs adosadas ................................... 461 

VPNs radiales..........................................................471 

Ejemplo: VPNs radiales....................................... 472 

Índice ......................................................................... IX-I 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs iii

Contenido 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs iv

Prefacio 

Una red privada virtual (VPN) es un medio rentable y seguro para las empresas que ofrece a los usuarios acceso 

telefónico a la red de la empresa y permite que las redes remotas se comuniquen entre sí a través de Internet. Las 

conexiones privadas seguras a través de Internet son más económicas que las líneas privadas especializadas. Los 

dispositivos NetScreen ofrecen una funcionalidad VPN completa para aplicaciones VPN de acceso telefónico y 

punto a punto seguras. 

En el Volumen 5, “VPNs”, se describen los siguientes conceptos y funciones VPN disponibles en los dispositivos 

NetScreen: 

• Elementos del intercambio de claves de Internet (“Internet Key Exchange” o “IKE”) y de la seguridad del 

protocolo de Internet (“Internet Protocol Security” o “IPSec”) 

Certificados y listas de revocación de certificados (CRLs) en el contexto de infraestructura de claves 

públicas (PKI) 

VPNs punto a punto 

VPNs de acceso telefónico 

Protocolo de encapsulamiento de capa 2 (L2TP) y L2TP sobre IPSec 

Características avanzadas de VPN, como NAT-Traversal, supervisión de VPN, asociación de múltiples 

túneles VPN a una sola interfaz de túnel, puertas de enlace IKE redundantes y comportamiento de 

conmutación por error en túneles VPN. 

Este volumen incluye numerosos ejemplos que ilustran todas estas funciones. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs v

Prefacio Convenciones 

CONVENCIONES 

Este documento contiene distintos tipos de convenciones, que se explican en las siguientes secciones: 

“Convenciones de la interfaz de línea de comandos (CLI)” 

“Convenciones de la interfaz gráfica (WebUI)” en la página vii 

“Convenciones para las ilustraciones” en la página ix 

“Convenciones de nomenclatura y conjuntos de caracteres” en la página x 

Convenciones de la interfaz de línea de comandos (CLI) 

Las siguientes convenciones se utilizan para representar la sintaxis de los comandos de la interfaz de línea de 

comandos (CLI): 

Los comandos entre corchetes [ ] son opcionales. 

Los elementos entre llaves { } son obligatorios. 

Si existen dos o más opciones alternativas, aparecerán separadas entre sí por barras verticales ( | ). 

Por ejemplo: 

set interface { ethernet1 | ethernet2 | ethernet3 } manage 

significa “establecer las opciones de administración de la interfaz ethernet1, ethernet2 o ethernet3”. 

Las variables aparecen en cursiva. Por ejemplo: 

set admin user name password 

Los comandos CLI insertados en el contexto de una frase aparecen en negrita (salvo en el caso de las variables, 

que siempre aparecen en cursiva ). Por ejemplo: “Utilice el comando get system para visualizar el número de serie 

de un dispositivo NetScreen”. 

Nota: Para escribir palabras clave, basta con introducir los primeros caracteres que permitan al sistema reconocer 

de forma inequívoca la palabra que se está introduciendo. Por ejemplo, es suficiente escribir set adm u joe 

j12fmt54 para que el sistema reconozca el comando set admin user joe j12fmt54 . Aunque este método se 

puede utilizar para introducir comandos, en la presente documentación todos ellos se representan con sus 

palabras completas. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs vi


Convenciones de la interfaz gráfica (WebUI) 

En este manual se utiliza la comilla angular ( > ) para indicar las rutas de navegación de la WebUI por las que se 

pasa al hacer clic en opciones de menú y vínculos. Por ejemplo, la ruta para abrir el cuadro de diálogo de 

configuración de direcciones se representa como sigue: Objects > Addresses > List > New . A continuación se 

muestra la secuencia de navegación. 

1 

2 

1. Haga clic en Objects en la columna de menú. 

La opción de menú Objects se desplegará para 

mostrar las opciones subordinadas que contiene. 

2. (Menú Applet) Sitúe el mouse sobre Addresses. 

(Menú DHTML) Haga clic en Addresses. 

La opción de menú Addresses se desplegará para 

mostrar las opciones subordinadas que contiene. 

3 

3. Haga clic en List. 

Aparecerá la tabla de libretas de direcciones. 

4. Haga clic en el vínculo New. 

Aparecerá el cuadro de diálogo de configuración 

de nuevas direcciones. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs vii 

4


Para llevar a cabo una tarea en la WebUI, en primer lugar debe acceder al cuadro de diálogo apropiado, donde 

podrá definir objetos y establecer parámetros de ajuste. El conjunto de instrucciones de cada tarea se divide en dos 

partes: la ruta de navegación y los datos de configuración. Por ejemplo, el siguiente conjunto de instrucciones 

incluye la ruta al cuadro de diálogo de configuración de direcciones y los ajustes de configuración que se deben 

realizar: 

Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK : 

Address Name: addr_1 

IP Address/Domain Name: 

IP/Netmask: (seleccione), 10.2.2.5/32 

Zone: Untrust 

IP Address Name/Domain Name: 


Address Name: addr_1 

Zone: Untrust 

Haga clic 

en OK . 

Nota: En este ejemplo, no hay 

instrucciones para el campo 

Comment, por lo que se deja 

en blanco. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs viii


Convenciones para las ilustraciones 

Los siguientes gráficos conforman el conjunto básico de imágenes utilizado en las ilustraciones de este manual: 

Dispositivo NetScreen genérico 

Dominio de enrutamiento virtual 

Zona de seguridad 

Interfaces de zonas de seguridad 

Blanca = interfaz de zona protegida 

(ejemplo: zona Trust) 

Negra = interfaz de zona externa 

(ejemplo: zona sin confianza o zona Untrust) 

Interfaz de túnel 

Túnel VPN 

Icono de enrutador (router) 

Icono de conmutador (switch) 

Red de área local (LAN) con 

una única subred 

(ejemplo: 10.1.1.0/24) 

Internet 

Rango de direcciones IP dinámicas 

(DIP) 

Equipo de escritorio 

Equipo portátil 

Dispositivo de red genérico 

(ejemplos: servidor NAT, 

concentrador de acceso) 

Servidor 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs ix


Convenciones de nomenclatura y conjuntos de caracteres 

ScreenOS emplea las siguientes convenciones relativas a los nombres de objetos (como direcciones, usuarios 

administradores, servidores de autenticación, puertas de enlace IKE, sistemas virtuales, túneles de VPN y zonas) 

definidas en las configuraciones de ScreenOS. 

Si la secuencia de caracteres que conforma un nombre contiene al menos un espacio, la 

cadena completa deberá entrecomillarse mediante comillas dobles ( “ ); por ejemplo, 

set address trust “ local LAN” 10.1.1.0/24 . 

NetScreen eliminará cualquier espacio al comienzo o al final de una cadena entrecomillada; 

por ejemplo, “ local LAN ” se transformará en “local LAN”. 

NetScreen tratará varios espacios consecutivos como uno solo. 

En las cadenas de nombres se distingue entre mayúsculas y minúsculas; por el contrario, en 

muchas palabras clave de la interfaz de línea de comandos pueden utilizarse indistintamente. 

Por ejemplo, “local LAN” es distinto de “local lan”. 

ScreenOS admite los siguientes conjuntos de caracteres: 

Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de múltiples bytes (MBCS). Algunos 

ejemplos de SBCS son los juegos de caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS, 

también conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran el chino, el coreano 

y el japonés. 

Nota: Una conexión de consola sólo admite conjuntos SBCS. La WebUI admite tanto SBCS como MBCS, 

según el conjunto de caracteres que admita el explorador web. 

Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepción de las comillas dobles ( “ ), 

que tienen un significado especial como delimitadores de cadenas de nombres que contengan espacios. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs x

Prefacio Documentación de NetScreen de Juniper Networks 

DOCUMENTACIÓN DE NETSCREEN DE JUNIPER NETWORKS 

Para obtener documentación técnica sobre cualquier producto NetScreen de Juniper Networks, visite 

www.juniper.net/techpubs/. 

Para obtener soporte técnico, abra un expediente de soporte utilizando el vínculo “Case Manager” en la página web 

http://www.juniper.net/support/ o llame al teléfono 1-888-314-JTAC (si llama desde los EE.UU.) o al 

+1-408-745-9500 (si llama desde fuera de los EE.UU.). 

Si encuentra algún error o omisión en esta documentación, póngase en contacto con nosotros a través de la 

siguiente dirección de correo electrónico: 

techpubs-comments@juniper.net 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs xi

Prefacio Documentación de NetScreen de Juniper Networks 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs xii

Capítulo 1 

IPSec 

1 

En este capítulo se presentan los diversos elementos de seguridad de protocolo Internet (IPsec) y se explica cómo 

están relacionados con el encapsulamiento de red privada virtual (VPN, o “Virtual Private Network”). En primer lugar 

se incluye una “Introducción a las VPNs” en la página 2, y a continuación se tratan los siguientes elementos de 

IPSec: 

“Conceptos de IPSec” en la página 3 

– “Modos” en la página 4 

– “Protocolos” en la página 7 

– “Administración de claves” en la página 9 

– “Asociación de seguridad” en la página 10 

“Negociación de túnel” en la página 11 

– “Fase 1” en la página 11 

– “Fase 2” en la página 13 

“Paquetes IKE e IPSec” en la página 16 

– “Paquetes IKE” en la página 16 

– “Paquetes IPSec” en la página 20 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs 1

Capítulo 1 IPSec Introducción a las VPNs 

INTRODUCCIÓN A LAS VPNS 

Una red privada virtual (VPN) representa un medio de comunicación segura entre equipos remotos de una red de 

área extensa (WAN) pública, como Internet. 

Una conexión VPN puede enlazar dos redes de área local (LAN) entre sí, o un usuario de acceso telefónico remoto 

y una LAN. El tráfico que circula entre estos dos puntos atraviesa determinados recursos compartidos, como 

enrutadores, conmutadores y otros equipos de red que conforman la WAN pública. Para garantizar la seguridad de 

las comunicaciones VPN a través de la WAN, los dos participantes crean un túnel de seguridad IP (IPSec) 1 . 

Un túnel IPSec está formado por un par de asociaciones de seguridad (SA) unidireccionales (una a cada extremo 

del túnel) que especifican el índice de parámetros de seguridad (SPI), la dirección IP de destino y el protocolo de 

seguridad (encabezado de autenticación o carga de seguridad encapsulada) empleado. 

Nota: Para obtener más información sobre SPIs, consulte “Asociación de seguridad” en la página 10. Para obtener 

más información sobre los protocolos de seguridad IPSec, consulte “Protocolos” en la página 7. 

A través de la SA, un túnel IPSec puede proporcionar las siguientes funciones de seguridad: 

Privacidad (por encriptación) 

Integridad de contenido (por autenticación de datos) 

Autenticación de remitente y (si se usan certificados) función Sin rechazo (por autenticación de origen de 

datos) 

Las funciones de seguridad empleadas dependen de las necesidades particulares. Si sólo necesita autenticar el 

origen del paquete IP y la integridad de contenido, puede autenticar el paquete sin aplicar ningún tipo de 

encriptación. Por otro lado, si sólo le preocupa preservar la privacidad, puede encriptar el paquete sin aplicar ningún 

mecanismo de autenticación. También puede encriptar y autenticar el paquete. La mayoría de los diseñadores de 

seguridad de red se decantan por la encriptación, la autenticación y la protección contra reprocesamiento de 

paquetes para el tráfico VPN. 

NetScreen admite la tecnología IPSec para la creación de túneles VPN con dos tipos de mecanismos de 

elaboración de claves: 

Clave manual 

AutoKey IKE con un certificado o una clave previamente compartida 

1. El término “túnel” no denota ni transporte ni modo de túnel (consulte “Modos” en la página 4). Se refiere simplemente a la conexión IPSec. 


Capítulo 1 IPSec Conceptos de IPSec 

CONCEPTOS DE IPSEC 

La seguridad IP (IPSec) es un conjunto de protocolos relacionados utilizados para garantizar la seguridad de las 

comunicaciones en la capa de paquete IP mediante encriptación. IPSec está compuesto por dos modos y dos 

protocolos principales: 

Modos de túnel y de transporte 

Protocolo de encabezado de autenticación (AH) para la autenticación y protocolo de carga de seguridad 

encapsulada (ESP) para la encriptación (y la autenticación) 

IPSec también ofrece métodos para la negociación manual y automática de asociaciones de seguridad (SA) y 

distribución de claves; todos los atributos necesarios para ello están reunidos en un dominio de interpretación 

(DOI). Consulte las normas RFC 2407 y 2408. 

Nota: NetScreen no 

admite el modo de 

transporte con AH. 

Modo de transporte 

Protocolo AH 

Algoritmo de autenticación 

(MD5, SHA-1) 

Arquitectura IPSec 

Dominio de 

interpretación (DOI) 

Protocolo ESP 

Algoritmo de encriptación 

(DES, 3DES) 

Administración de claves y SA 

(manual y automática) 

Modo de túnel 



Nota: El dominio de interpretación (DOI) IPSec es un documento que contiene definiciones para todos los 

parámetros de seguridad requeridos para la negociación satisfactoria de un túnel VPN (fundamentalmente, todos 

los atributos necesarios para las negociaciones IKE y SA). 

Modos 

IPSec tiene dos modos operativos: transporte y túnel. Cuando ambos extremos del túnel son hosts, se puede 

utilizar tanto el modo de transporte como el modo de túnel. Cuando al menos uno de los puntos finales de un túnel 

es una puerta de enlace de seguridad (como un enrutador o un cortafuegos), hay que utilizar el modo de túnel. Los 

dispositivos NetScreen funcionan siempre en modo de túnel cuando se trata de túneles IPSec y en modo de 

transporte cuando se trata de túneles L2TP sobre IPSec. 

Modo de transporte 

El paquete IP original no está encapsulado en otro paquete IP. El paquete completo se puede autenticar (con AH), 

la carga se puede encriptar (con ESP), y el encabezado original continúa en texto sin formato tal como se envía por 

la WAN. 

Modo de transporte, 

AH 

Modo de transporte, 

ESP 

Encabezado 

original 

Encabezado 

original 

Encabezado 

AH 

Encabezado 

ESP 

Paquetes IP 

Encriptado 

Carga de 

datos 

Carga de 

datos 

Autenticado 

Autenticado 



Modo de túnel 

El paquete IP original completo (carga y encabezado) está encapsulado en otra carga IP y tiene adjunto un nuevo 

encabezado. El paquete original completo se puede encriptar, autenticar o ambas cosas. Con AH, se autentican el 

AH y los nuevos encabezados. Con ESP, se autentica el encabezado ESP. 

Modo de túnel, AH 

Modo de túnel, ESP 

Encabezado 

nuevo 

Encabezado 

nuevo 

Encabezado 

AH 

Encabezado 

ESP 

Paquetes IP 

Encabezado 

original 

Encabezado 

original 

Encriptado 

El paquete original está 

encapsulado. 

Carga de datos 


Autenticado 

Autenticado 

En una VPN punto a punto, las direcciones de origen y destino utilizadas en el encabezado nuevo son las 

direcciones IP de la interfaz de salida (en modo de ruta o NAT) o la dirección IP VLAN1 (en modo transparente); las 

direcciones de origen y destino de los paquetes encapsulados son las direcciones de los puntos finales definitivos 

de la conexión. 



Puerta de enlace de túnel 

de 

NetScreen-A 

Internet 

Puerta de enlace de túnel 

de 

NetScreen-B 

LAN Túnel 

LAN 

1 2 

A B 

A B 1 2 A B 

A B 

Carga de datos Carga de datos Carga de datos 


encapsulado. 

VPN punto a punto en modo de túnel 

En una VPN de acceso telefónico no existe ninguna puerta de enlace de túnel en el extremo del túnel 

correspondiente al cliente de acceso telefónico VPN; el túnel se prolonga directamente hasta el propio cliente. En 

este caso, en los paquetes enviados desde el cliente de acceso telefónico, tanto el encabezado nuevo como el 

encabezado encapsulado original tendrán la misma dirección IP: la dirección del equipo del cliente 2 . 

Cliente VPN de 

acceso telefónico 

A = 1 

Internet 

Túnel 

A B 1 2 A B 

A B 


puerta de enlace de túnel 

2. Algunos clientes VPN, como NetScreen-Remote, permiten definir una dirección IP interna 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 originado por el cliente, y la dirección IP que el ISP asigna dinámicamente al cliente de acceso 

telefónico es la dirección IP de origen en el encabezado externo. 

Juniper Networks NetScreen conceptos y ejemplos – Volumen 5: VPNs 6 

LAN 

Carga de datos Carga de datos Carga de datos 


encapsulado. 

VPN de acceso telefónico en modo de túnel 

2 

B


Protocolos 

IPSec utiliza dos protocolos para garantizar la seguridad de las comunicaciones en la capa IP: 

AH 

Encabezado de autenticación (AH): protocolo de seguridad que sirve para autenticar el origen de un 

paquete IP y verificar la integridad de su contenido. 

Carga de seguridad encapsulada (ESP): protocolo de seguridad que sirve para encriptar el paquete IP 

completo (y autenticar su contenido). 

El protocolo de encabezado de autenticación (AH) ofrece un medio para verificar la autenticidad/integridad del 

contenido y el origen de un paquete. Puede autenticar el paquete por la suma de comprobación calculada a través 

de un código de autenticación de mensajes basado en hash (HMAC) mediante una clave secreta y funciones MD5 

o SHA-1 hash. 

Síntesis de mensaje versión 5 (MD5, o Message Digest) : algoritmo que produce un hash de 128 bits 

(también denominado firma digital o síntesis del mensaje) a partir de un mensaje de longitud arbitraria y 

una clave de 16 bytes. El hash resultante se utiliza, como si fuese la huella dactilar de la entrada, para 

verificar la autenticidad y la integridad del contenido y el origen. 

Algortimo de hash seguro-1 (SHA-1, o Secure Hash Algorithm-1) : algoritmo que produce un hash de 

160 bits a partir de un mensaje de longitud arbitraria y una clave de 20 bytes. Normalmente, se considera 

más seguro que MD5 debido al mayor tamaño del hash que produce. Como el procesamiento 

computacional se realiza en ASIC de NetScreen, los costes de rendimiento son insignificantes. 

Nota: Para obtener más información sobre los algoritmos MD5 y SHA-1, consulte las siguientes normas RFC: 

(MD5) 1321, 2403; (SHA-1) 2404. Para obtener información sobre HMAC, consulte la norma RFC 2104. 



ESP 

El protocolo de carga de seguridad encapsulada (ESP) proporciona un medio para garantizar la privacidad 

(encriptación), la autenticación de origen y la integridad de contenidos (autenticación). El protocolo ESP en modo 

de túnel encapsula el paquete IP completo (encabezado y carga) y adjunta un nuevo encabezado IP al paquete 

ahora encriptado. Este nuevo encabezado IP contiene la dirección de destino necesaria para enrutar los datos 

protegidos a través de la red. 

Con ESP, es posible encriptar y autenticar, sólo encriptar o sólo autenticar. Para la encriptación se puede 

seleccionar cualquiera de los siguientes algoritmos de encriptación: 

Norma de encriptación de datos (DES) : algoritmo de bloque criptográfico con una clave de 56 bits. 

Triple DES (3DES) : versión más potente de DES en la que el algoritmo original DES se aplica en tres 

rondas mediante una clave de 168 bits. DES ofrece un ahorro de rendimiento significativo, pero no se 

considera aceptable para numerosas transferencias de material delicado o clasificado. 

Norma de encriptación avanzada (AES): norma de encriptación que, cuando sea adoptada por las 

infraestructuras de Internet de todo el mundo, ofrecerá una mayor interoperabilidad con otros dispositivos 

de seguridad de red. NetScreen admite AES con claves de 128, 192 y 256 bits. 

Para la autenticación, puede utilizar algoritmos MD5 o SHA-1. 

Para el algoritmo de autenticación o encriptación puede seleccionar NULL ; sin embargo, no es posible 

seleccionar NULL para ambos de forma simultánea. 



Administración de claves 

La distribución y la administración de claves son fundamentales para el uso satisfactorio de las redes VPN. IPSec 

admite los métodos de distribución de claves manual y automático. 

Clave manual 

Con las claves manuales, los administradores de ambos extremos de un túnel configuran todos los parámetros de 

seguridad. Ésta es una técnica viable para redes pequeñas y estáticas, donde la distribución, el mantenimiento y el 

seguimiento de las claves no resulta difícil. Sin embargo, la distribución segura de configuraciones de clave manual 

a través de largas distancias genera problemas de seguridad. Excepto en el caso de que las claves se transmitan 

“cara a cara”, no es posible estar completamente seguro de que las claves no hayan quedado comprometidas 

durante la transferencia. Además, a la hora de modificar la clave nos enfrentamos a los mismos problemas que a la 

hora de distribuirla inicialmente. 

AutoKey IKE 

Cuando es necesario crear y administrar numerosos túneles, se requiere un método en el que no haya que 

configurar cada elemento de forma manual. IPSec admite la generación y negociación automatizada de claves y 

asociaciones de seguridad mediante el protocolo de intercambio de claves de Internet (IKE). NetScreen denomina 

estas negociaciones de túnel automatizadas “AutoKey IKE” y admite AutoKey IKE con claves previamente 

compartidas y AutoKey IKE con certificados. 

AutoKey IKE con claves previamente compartidas 

Si AutoKey IKE utiliza claves previamente compartidas para autenticar a sus participantes en una sesión 

IKE, cada parte debe configurar e intercambiar de forma segura la clave compartida 3 por adelantado. En 

este sentido, el problema de distribución segura de claves es idéntico al que presentan las claves 

manuales. Sin embargo, al contrario de lo que ocurre con las claves manuales, una AutoKey, una vez 

distribuida, puede modificar sus claves automáticamente a intervalos predeterminados mediante el 

protocolo IKE. Con frecuencia, la modificación de claves aumenta la seguridad de forma considerable. 

Además, la automatización de esta tarea reduce significativamente las responsabilidades de administración 

de claves. Sin embargo, la modificación de claves eleva el nivel máximo de tráfico; por lo tanto, si se realiza 

a menudo, puede disminuir la eficacia de la transmisión de datos. 

3. Una clave previamente compartida es una clave que se utiliza tanto para la encriptación como para la desencriptación y que ambos participantes deben 

poseer antes de iniciar la comunicación. 



AutoKey IKE con certificados 

Cuando se utilizan certificados para autenticar a los participantes durante una negociación AutoKey IKE, 

cada parte genera un par de claves públicas/privadas (consulte el Capítulo 2, “Criptografía de claves 

públicas” en la página 23) y adquiere un certificado (consulte “Certificados y CRLs” en la página 29). Si la 

autoridad de certificación (CA) es fiable para ambas partes, los participantes podrán recuperar la clave 

pública del interlocutor y verificar la firma del interlocutor. No es necesario realizar un seguimiento de las 

claves y SAs; IKE lo hace automáticamente. 

Nota: Para obtener ejemplos de ambos túneles (clave manual y AutoKey IKE), consulte el Capítulo 4, “VPNs punto 

a punto” en la página 103. 

Asociación de seguridad 

Una asociación de seguridad (SA) es un acuerdo unidireccional entre los participantes VPN en lo que respecta a los 

métodos y parámetros empleados para garantizar la seguridad de un canal de comunicaciones. Una comunicación 

bidireccional completa requiere al menos dos SA, una para cada dirección. 

Una SA agrupa los siguientes componentes para garantizar la seguridad de las comunicaciones: 

– Claves y algoritmos de seguridad 

– Modo de protocolo (transporte o túnel) 

– Método de administración de claves (clave manual o AutoKey IKE) 

– Periodo de vigencia de SA 

Para el tráfico VPN saliente, la directiva invoca la SA asociada al túnel VPN. Para el tráfico entrante, el dispositivo 

NetScreen consulta la SA mediante los siguientes tres elementos: IP de destino, protocolo de seguridad (AH o 

ESP) y valor del índice de parámetros de seguridad (SPI). 


Capítulo 1 IPSec Negociación de túnel 

NEGOCIACIÓN DE TÚNEL 

Para un túnel IPSec de clave manual, como todos los parámetros de la asociación de seguridad (SA) se han 

definido previamente, no es necesario negociar qué SAs utilizar. Básicamente, el túnel ya se ha establecido. 

Cuando el tráfico coincide con una directiva que utilice ese túnel de clave manual o cuando una ruta utiliza el túnel, 

el dispositivo NetScreen simplemente encripta y autentica los datos, tal como se haya determinado, y los envía a la 

puerta de enlace de destino. 

Para establecer un túnel IPSec AutoKey IKE se requieren dos fases de negociación: 

Fase 1 

En la fase 1, los participantes establecen un canal seguro en el que negociar las SAs IPSec. 

En la fase 2, los participantes negocian las SAs IPSec para encriptar y autenticar los sucesivos 

intercambios de datos de usuario. 

La fase 1 de una negociación de túnel AutoKey IKE consiste en el intercambio de propuestas sobre cómo autenticar 

y garantizar la seguridad del canal. El intercambio se puede realizar en uno de estos dos modos: modo dinámico o 

modo principal (consulte más adelante). En cualquiera de los dos modos, los participantes intercambian propuestas 

de servicios de seguridad aceptables, como por ejemplo: 

Algoritmos de encriptación (DES y 3DES) y de autenticación (MD5 y SHA-1). Para obtener más información 

sobre estos algoritmos, consulte “Protocolos” en la página 7. 

Un grupo Diffie-Hellman (consulte “Intercambio Diffie-Hellman” en la página 13) 

Una clave previamente compartida o certificados RSA/DSA (consulte “AutoKey IKE” en la página 9) 

Una negociación de fase 1 correcta concluye cuando ambos extremos del túnel se ponen de acuerdo para aceptar 

al menos un conjunto de los parámetros de seguridad de fase 1 propuestos y comienzan a procesarlos. Los 

dispositivos NetScreen admiten hasta cuatro propuestas para negociaciones de fase 1 y permiten definir el grado 

de restricción del rango aceptable de parámetros de seguridad para la negociación de claves. 



Las propuestas predefinidas de fase 1 que ofrece NetScreen son las siguientes: 

Estándar: pre-g2-aes128-sha y pre-g2-3des-sha 

Compatibles: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha y pre-g2-des-md5 

Básicas: pre-g1-des-sha y pre-g1-des-md5 

También es posible definir propuestas de fase 1 personalizadas. 

Modo principal y modo dinámico 

La fase 1 se puede desarrollar en modo principal o en modo dinámico. Estos dos modos se describen a 

continuación. 

Modo principal: el iniciador y el destinatario envían tres intercambios en dos direcciones (seis mensajes en total) 

para lograr los siguientes servicios: 

Primer intercambio (mensajes 1 y 2): proponer y aceptar los algoritmos de encriptación y autenticación. 

Segundo intercambio (mensajes 3 y 4): ejecutar un intercambio Diffie-Hellman; el iniciador y el destinatario 

ofrecen un número aleatorio (propuesta) cada uno. 

Tercer intercambio (mensajes 5 y 6): enviar y verificar las identidades. 

La información transmitida en el tercer intercambio de mensajes está protegida por el algoritmo de encriptación 

establecido en los dos primeros intercambios. Es decir, las identidades de los participantes no se transmiten de 

modo transparente. 

Modo dinámico: el iniciador y el destinatario logran los mismos objetivos, pero en sólo dos intercambios y con un 

total de tres mensajes: 

Primer mensaje: el iniciador propone la SA, inicia el intercambio Diffie-Hellman y envía una propuesta y su 

identidad IKE. 

Segundo mensaje: el destinatario acepta la SA, autentica al iniciador y envía un nonce, su identidad IKE y, 

si se utilizan certificados, el certificado de destinatario. 

Tercer mensaje: el iniciador autentica al destinatario, confirma el intercambio y, si se utilizan certificados, 

envía el certificado de iniciador. 



Puesto que las identidades de los participantes se intercambian en modo transparente (en los dos primeros 

mensajes), el modo dinámico no ofrece protección de identidad. 

Nota: Cuando un usuario VPN de acceso telefónico negocia un túnel AutoKey IKE con una clave previamente 

compartida, se debe utilizar el modo dinámico. Recuerde también que un usuario VPN de acceso telefónico puede 

utilizar una dirección de correo electrónico, un nombre de dominio completo (FQDN) o una dirección IP como su ID 

IKE. Un interlocutor dinámico puede utilizar una dirección de correo electrónico o un FQDN, pero no una dirección 

IP. 

Intercambio Diffie-Hellman 

Un intercambio Diffie-Hellman permite a los participantes elaborar un valor secreto compartido. El punto fuerte de 

esta técnica es que permite a los participantes crear el valor secreto a través de un medio no seguro sin tener que 

transmitir este valor por la línea. Hay cinco grupos Diffie-Hellman (DH); NetScreen admite los grupos 1, 2 y 5. El 

tamaño del módulo primario utilizado en el cálculo de cada grupo varía del siguiente modo: 

Grupo DH 1: módulo de 768 bits 4 

Grupo DH 2: módulo de 1024 bits 

Grupo DH 5: módulo de 1536 bits 

Cuanto mayor es un módulo, más segura se considera la clave generada; no obstante, cuanto mayor es un módulo, 

más tarda el proceso de generación de claves. Como el módulo de cada grupo DH tiene un tamaño distinto, los 

participantes tienen que ponerse de acuerdo para utilizar el mismo grupo 5 . 

Fase 2 

Una vez que los participantes han establecido un canal seguro y autenticado, continúan con la fase 2, en la que 

negocian las SA para garantizar la seguridad de los datos que se van a transmitir a través del túnel IPSec. 

4. La seguridad del grupo DH 1 ha disminuido y Juniper Networks recomienda no utilizarlo. 

5. Si configura múltiples propuestas (hasta cuatro) para negociaciones de fase 1, utilice el mismo grupo Diffie-Hellman para todas ellas. La misma directriz se 

aplica a la creación de múltiples propuestas para negociaciones de fase 2. 



Al igual que ocurre en la fase 1, los participantes intercambian propuestas para determinar los parámetros de 

seguridad que se van a emplear en la SA. Una propuesta de fase 2 incluye también un protocolo de seguridad 

(encabezado de autenticación, AH, o carga de seguridad encapsulada, ESP) y algoritmos de encriptación y 

autenticación seleccionados. La propuesta también puede especificar un grupo Diffie-Hellman si se desea una 

confidencialidad directa perfecta (PFS). 

Nota: Para obtener más información sobre los grupos Diffie-Hellman, consulte “Intercambio Diffie-Hellman”. Para 

obtener más información sobre PFS, consulte “Confidencialidad directa perfecta” en la página 15. 

Independientemente del modo utilizado en la fase 1, la fase 2 funciona siempre en modo rápido e implica el 

intercambio de tres mensajes 5 . 

Los dispositivos NetScreen admiten hasta cuatro propuestas para negociaciones de fase 2 y permiten definir el 

grado de restricción del rango aceptable de parámetros de túnel. NetScreen también ofrece una función de 

protección contra reprocesamiento de paquetes. El uso de esta función no requiere negociación porque los 

paquetes se envían siempre con números de secuencia. Sólo existe la opción de comprobar los números de 

secuencia o no. (Para más información sobre la protección contra reprocesamiento de paquetes, consulte más 

adelante). 

Las propuestas predefinidas de fase 2 que ofrece NetScreen son las siguientes: 

Estándar: g2-esp-3des-sha y g2-esp-aes128-sha 

Compatibles: nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha y nopfs-esp-des-md5 

Básicas: nopfs-esp-des-sha y nopfs-esp-des-md5 

También es posible definir propuestas de fase 2 personalizadas. 

En la fase 2, los interlocutores también intercambian IDs de proxy. Una ID de proxy es una tupla de tres partes 

compuesta por dirección IP local/dirección IP remota/servicio. La ID de proxy para ambos interlocutores debe 

coincidir, es decir, el servicio especificado en la ID de proxy para ambos interlocutores debe ser idéntico, y la 

dirección IP local indicada para un interlocutor debe ser igual que la dirección IP remota indicada para el otro 

interlocutor. 



Confidencialidad directa perfecta 

La confidencialidad directa perfecta (PFS) es un método para derivar claves de fase 2 independientes y no 

relacionadas con las claves anteriores. De forma alternativa, la propuesta de fase 1 crea la clave (SKEYID_d) a 

partir de la que se derivan todas las claves de fase 2. La clave SKEYID_d puede generar claves de fase 2 con un 

mínimo de procesamiento de CPU. Lamentablemente, si un interlocutor no autorizado obtiene acceso a la clave 

SKEYID_d, todas las claves de encriptación quedarán comprometidas. 

PFS afronta este riesgo de seguridad forzando un nuevo intercambio de claves Diffie-Hellman para cada túnel de 

fase 2. Por lo tanto, utilizar PFS es más seguro, aunque el procedimiento de reencriptación de la fase 2 puede 

prolongarse ligeramente si la función PFS está habilitada. 

Protección contra reprocesamiento 

Se produce un ataque de reproducción cuando alguien intercepta una serie de paquetes y los utiliza posteriormente 

para inundar el sistema, provocando un rechazo de servicio (DoS), o para obtener acceso a la red fiable. La función 

de protección contra reprocesamiento de paquetes permite que los dispositivos NetScreen comprueben cada 

paquete IPSec para verificar si se ha recibido antes. Si llegan paquetes fuera de un rango de secuencia 

especificado, el dispositivo NetScreen los rechaza. 


Capítulo 1 IPSec Paquetes IKE e IPSec 

PAQUETES IKE E IPSEC 

Un túnel VPN IPSec consta de dos elementos importantes: 

Configuración del túnel: En primer lugar, los interlocutores establecen las asociaciones de seguridad 

(SAs), que definen los parámetros para asegurar el tráfico entre ellos. Los administradores de cada 

extremo pueden definir los SAs manualmente, o bien dinámicamente durante las negociaciones IKE de 

fase 1 y fase 2. La fase 1 se puede desarrollar en modo principal o en modo dinámico. La fase 2 ocurre 

siempre en modo rápido. 

Seguridad aplicada: IPSec protege el tráfico enviado entre los dos puntos terminales del túnel usando los 

parámetros de seguridad definidos en los SAs que los interlocutores acordaron durante la configuración del 

túnel. IPSec se puede aplicar en uno de ambos modos: modo de transporte (“Transport”) y modo de túnel 

(“Tunnel”). Ambos modos admiten los dos protocolos IPSec: Encapsulating Security Payload (ESP) y 

Authentication Header (AH). 

Para ayudar a desmitificar el procesamiento de paquetes que se produce durante las etapas IKE e IPSec de un túnel 

VPN, consulte las secciones siguientes, que muestran los encabezados de paquetes tanto para IKE como para IPSec. 

Paquetes IKE 

Cuando un paquete de texto puro que requiere encapsulamiento llega al dispositivo NetScreen y no existe ninguna 

SA activa de fase 2 para ese túnel, el dispositivo NetScreen inicia las negociaciones IKE (y descarta el paquete 6 ). 

Las direcciones de origen y de destino en el encabezado del paquete IP son las de las puertas de enlace IKE local 

y remota, respectivamente. En la carga de datos del paquete IP hay un segmento UDP que encapsula un paquete 

ISAKMP (IKE). El formato de los paquetes IKE es igual para la fase 1 y la fase 2. 

Paquete IKE 

(Para las fases 1 y 2) 

Encabezado 

IP 

Encabezado 

UDP 

Encabezado 

ISAKMP 


Nota: ISAKMP es el formato de paquetes utilizado por IKE. 

6. Cuando se descarta el paquete IP inicial, el host de origen lo reenvía. Típicamente, para cuando el segundo paquete alcanza el dispositivo NetScreen, las 

negociaciones IKE se han completado y el dispositivo NetScreen lo protege (como también protege todos los paquetes subsiguientes de esa sesión) con 

IPSec antes de reenviarlo. 



Encabezado IP 

Versión 

Longitud del 

encabezado 

Tiempo de vida (“Time to 

Live” o “TTL”) 

Encabezado UDP 

Identificación 

Tipo de servicio Tamaño total del paquete (en bytes) 

Protocolo ( 17 para UDP ) 

Suma de comprobación del encabezado 

Dirección de origen (puerta de enlace del interlocutor local) 

Dirección de destino (puerta de enlace del interlocutor remoto) 

Opciones IP (si las hay) 

Puerto de origen ( 500 para IKE ) 

Tamaño 

Encabezado ISAKMP (para IKE) 

Carga de datos siguiente 

Versión 

mayor 

Carga de datos IP 

Carga de datos UDP 

Cookie del iniciador 

Longitud del mensaje 

Carga de datos ISAKMP 

0 D M Desplazamiento del fragmento 

Cookie del respondedor 

(0000 para el primer paquete) 

Versión Tipo del intercambio 

menor 

ID del mensaje 

Suma de comprobación 

Relleno 

Puerto de destino ( 500 para IKE ) 


Flags


El campo “Next Payload” contiene un número que indica uno de los siguientes tipos de carga de datos: 

0002 – Carga de datos de la negociación SA; contiene una definición para la SA de fase 1 o de fase 2 

0004 – Carga de datos propuesta; puede ser una propuesta de fase 1 o de fase 2 

0008 – Carga de datos de transformación; la carga de datos de transformación es encapsulada en una 

carga de datos propuesta que se encapsula en una carga de datos SA 

0010 – Carga de datos Key Exchange (KE); contiene la información necesaria para realizar un intercambio 

de claves, como un valor público Diffie-Hellman 

0020 – Carga de datos de identificación (IDx) 

– En la fase 1, IDii indica la identificación del iniciador, mientras IDir indica la del respondedor 

– En la fase 2, IDui indica el iniciador del usuario, mientras IDur indica el respondedor 

Las identificaciones son tipos de IDs IKE, como FQDN, U-FQDN, dirección IP y ASN.1_DN. 

0040 – Carga de datos de certificado (CERT) 

0080 – Carga de datos de petición de certificado (CERT_REQ) 

0100 – Carga de datos de Hash (HASH); contiene el resultado resumido de una determinada función de 

transformación (“hash”) 

0200 – Carga de datos de firma (SIG); contiene una firma digital 

0400 – Carga de datos Nonce (Nx); contiene determinada información pseudoaleatoria necesaria para el 

intercambio 

0800 – Carga de datos de notificación 

1000 – Carga de datos de eliminación ISAKMP 

2000 – Carga de datos de ID del fabricante (VID); puede incluirse en cualquier punto de las negociaciones 

de fase 1. NetScreen la utiliza para marcar la compatibilidad con NAT-T. 

Cada carga de datos ISAKMP comienza con el mismo encabezado genérico: 

Encabezado genérico de la carga de datos ISAKMP 

Encabezado siguiente 

Reservado Longitud de la carga de datos (en bytes) 




Puede haber múltiples cargas de datos ISAKMP encadenadas, indicándose cada tipo de carga de datos 

subsiguiente en el valor del campo del encabezado siguiente. Un valor 0000 indica la última carga de datos 

ISAKMP. Consulte el ejemplo que aparece en el diagrama siguiente: 

Encabezado ISAKMP con cargas de datos genéricos ISAKMP 

Carga de datos siguiente 

(0002 para SA) 


(0004 para propuesta) 


(0008 para transformación) 


(0000 para fin) 

SPI del iniciador 

SPI del respondedor (0000 para el primer paquete) 

Versión 

mayor 

Versión 

menor 

ID del mensaje 

Longitud total del mensaje 

Carga de datos SA 

Tipo del intercambio 


Flags 

Reservado Longitud de la carga de datos SA 

Reservado Longitud de la carga de datos de la propuesta 

Carga de datos de la propuesta 

Reservado Longitud de la carga de datos de transformación 

Carga de datos de transformación 

Encabezado 

ISAKMP 

Carga de 

datos 

SA 

Carga de 

datos de la 

propuesta 

Carga de 

datos de 

transformación


Paquetes IPSec 

Una vez completadas las negociaciones IKE y después de que las dos puertas de enlace IKE hayan establecido las 

asociaciones de seguridad de fase 1 y fase 2 (SAs), el dispositivo NetScreen aplica la protección IPSec a los 

paquetes IP de texto puro subsiguientes que los hosts situados detrás de una puerta de enlace IKE envían a los 

hosts que se encuentran detrás de la otra puerta de enlace (asumiendo que las directivas permitan el tráfico). Si la 

SA de fase 2 especifica el protocolo Encapsulating Security Protocol (ESP) en modo de túnel, el paquete se 

parecerá al que aparece debajo 7 . Observe que el dispositivo NetScreen agrega dos encabezados adicionales al 

paquete original enviado por el host. 

Paquete IPSec – 

Encapsulating Security Payload (ESP) en el modo de túnel 

Paquete IPSec 

Enviado por la puerta 

de enlace IKE 

Encabezado 

IP2 

Encabezado 

ESP 

Encabezado 

IP1 

La puerta de enlace local agrega estos 

encabezados al paquete. 

Encabezado 

TCP 

Paquete original 

Enviado por el host iniciador 


Como muestra la ilustración anterior, el paquete que el host iniciador construye incluye la carga de datos, el 

encabezado TCP y el encabezado IP interno (IP1). 

El encabezado IP externo (IP2) que agrega el dispositivo NetScreen contiene la dirección IP de la puerta de enlace 

remota como dirección IP de destino y la dirección IP del dispositivo NetScreen local como dirección IP de origen. 

El dispositivo NetScreen también agrega un encabezado ESP entre los encabezados IP externo e interno. El 

encabezado ESP contiene información que permite al interlocutor remoto procesar correctamente el paquete al 

recibirlo. 

7. Para obtener más información sobre ESP, consulte “ESP” en la página 8. Para obtener información sobre el modo de túnel, consulte “Modo de túnel” en la 

página 5. 



Encriptado 

Encabezado IP externo (IP2) 

Versión 

Tamaño del 

encabezado 

Tiempo de vida (“Time 

to Live” o “TTL”) 

Encabezado ESP 



Protocolo ( 50 para ESP ) 


Dirección de origen (puerta de enlace del interlocutor local) 

Dirección de destino (puerta de enlace del interlocutor remoto) 



Carga de datos * ‡ (variable) 

Longitud de 

relleno * ‡ 

Relleno * ‡ (0-255 bytes) 

Datos de autenticación 

(variables) 


Relleno 

Índice de parámetros de seguridad (“Security Parameters Index” o “SPI”) del interlocutor remoto * 

* = secciones autenticadas del paquete 

‡ = secciones encriptadas del paquete 

Número correlativo* 

Vector de inicialización * (IV) – Primeros 8 octetos del campo de datos 


(4 para IP) * ‡ 

El campo de siguiente encabezado indica el tipo de datos contenidos en el campo de carga de datos. En el modo 

de túnel, este valor es 4, indicando IP-en-IP. Si se aplica ESP en el modo de transporte, este valor indica un 

protocolo de capa de transporte, como 6 para TCP o 17 para UDP. 


Auten- 

ticado


Encabezado IP interno (IP1) 

Versión 

Tamaño del 

encabezado 

Tiempo de vida (“Time 

to Live” o “TTL”) 

Encabezado TCP 

Tamaño del 

encabezado 



Protocolo ( 6 para TCP ) 

Dirección de origen (host iniciador) 

Dirección de destino (host receptor) 





Puerto de origen Puerto de destino 

U 

Reservado R 

G 

Suma de 

comprobación 

A 

C 

K 

Número correlativo 

Número de reconocimiento 

P 

S 

H 

R 

S 

T 

S 

Y 

N 

F 

I 

N 

Opciones (si las hay) 

Datos 

Tamaño de la 

ventana 

Indicador 

“Urgente” 

Relleno 

Relleno 


Capítulo 2 

Criptografía de claves públicas 

2 

En este capítulo se ofrece una introducción a la criptografía de claves públicas y al uso de certificados y listas de 

revocación de certificados (CRLs, o “Certificate Revocation Lists”) en el marco de las infraestructuras de claves 

públicas (PKI, o “Public Key Infraestructure”). El contenido del capítulo se divide en las siguientes secciones: 

“Introducción a la criptografía de claves públicas” en la página 24 

“PKI” en la página 26 

“Certificados y CRLs” en la página 29 

– “Obtención manual de un certificado” en la página 30 

– “Obtención automática de un certificado local” en la página 38 

– “Renovación automática de certificado” en la página 43 

“Comprobación de estado mediante OCSP” en la página 44 

– “Configuración de OCSP” en la página 45 

“Certificados autofirmados (“Self-Signed Certificates”)” en la página 47 

– “Asegurar el tráfico administrativo con SSL” en la página 48 


Capítulo 2 Criptografía de claves públicas Introducción a la criptografía de claves públicas 

INTRODUCCIÓN A LA CRIPTOGRAFÍA DE CLAVES PÚBLICAS 

En la criptografía de claves públicas se utiliza el par formado por una clave pública y otra privada para encriptar y 

desencriptar datos. Los datos encriptados con una clave pública, que su propietario pone a disposición de otros 

usuarios, sólo pueden ser desencriptados con la clave privada correspondiente, que el propietario mantendrá 

protegida y en secreto. Por ejemplo, si Alicia quiere enviar a Juan un mensaje encriptado, utilizará la clave pública 

de él para encriptarlo y, a continuación, se lo enviará. Cuando reciba el mensaje, Juan podrá desencriptarlo con su 

clave privada. 

El método inverso también resulta de gran utilidad; esto es, encriptar los datos con una clave privada y que se 

puedan desencriptar con la clave pública correspondiente. Este método se conoce como firma digital. Si, por 

ejemplo, Alicia desea que se sepa que ella es la autora de un mensaje, lo encripta con su clave privada y lo envía 

de forma pública a Juan. A continuación, Juan sólo puede desencriptar los datos utilizando la clave pública de 

Alicia, lo que significa que lo ha enviado ella. 

Los conjuntos de claves privada y pública también desempeñan un importante papel en el uso de certificados 

digitales. El procedimiento para firmar un certificado (por parte de una autoridad de certificación) y, a continuación, 

verificar la firma (por parte del receptor), se desarrolla tal y como se indica a continuación: 

Firma de un certificado 

1. La autoridad de certificación (CA) que emite el certificado lo somete a una operación matemática en la que 

se utiliza un algoritmo “hash” (MD5 o SHA-1) para generar una codificación. 

2. A continuación, la CA “firma” el certificado encriptando la codificación con su clave privada. El resultado es 

una firma digital. 

3. La CA envía el certificado firmado digitalmente a la persona que lo solicitó. 

Verificación de una firma digital 

1. Cuando el destinatario recibe el certificado, también genera otra codificación aplicando el mismo algoritmo 

hash (MD5 o SHA-1) en el archivo de certificado. 

2. El destinatario utiliza la clave pública de la CA para desencriptar la firma digital. 

3. El destinatario compara la codificación desencriptada con la codificación que acaba de generar. Si ambas 

coinciden, el destinatario puede confirmar la integridad de la firma de la CA y, por extensión, la integridad 

del certificado que lo acompaña. 


Capítulo 2 Criptografía de claves públicas Introducción a la criptografía de claves públicas 

1. La CA genera la codificación A a partir del certificado 

utilizando el algoritmo hash MD5 o SHA-1. 

2. Con su clave privada, la CA encripta la codificación A. El 

resultado es la codificación B, la firma digital. 

3. La CA envía el certificado firmado digitalmente a la 

persona que lo solicitó. 

1. Genera la codificación A a partir del certificado utilizando 

MD5 o SHA-1. 

2. Utilizando la clave pública de la CA, desencripta la 

codificación B. 

3. Compara la codificación A con la B. Si coinciden, el 

receptor sabrá que el certificado no está manipulado. 

Codificación A 

Codificación A 

Algoritmo hash 

(MD5 o SHA-1) 

Algoritmo hash 

(MD5 o SHA-1) 

El procedimiento de firma digital de los mensajes enviados por dos participantes en una sesión IKE funciona de 

forma muy parecida, con las siguientes diferencias: 

En lugar de generar una codificación a partir del certificado de la CA, el emisor la genera a partir de los 

datos del paquete IP. 

En vez de utilizar el par de claves pública/privada de la CA, los participantes utilizan el par de claves 

pública/privada del emisor. 


3 

Emisor (CA) 

Receptor 

2 

Comparación 

2 

1 

Cert. 

Codificación B 

Clave privada de la CA 

1 

Cert. 

Codificación B 

Clave pública de la CA

Capítulo 2 Criptografía de claves públicas PKI 

PKI 

El término infraestructura de claves públicas (PKI) hace referencia a la estructura jerárquica de confianza necesaria 

para la correcta implementación de la criptografía de claves públicas. Para verificar la fiabilidad de un certificado, es 

necesario poder identificar una ruta de CA fiables desde la CA que emite el certificado localmente hasta la autoridad 

raíz de un dominio de CA. 

Jerarquía de confianza de una PKI: 

dominio de CA 

La CA de nivel raíz valida las CA 

subordinadas. 

Las CAs subordinadas 

validan 

certificados locales y a 

otras CAs. 

Los certificados locales 

contienen la clave pública del 

usuario. 



Si los certificados se utilizan exclusivamente dentro de una organización, dicha organización puede tener su propio 

dominio de CA dentro del cual una CA de la empresa emite y valida certificados entre sus empleados. Si después 

esa organización desea que sus empleados puedan intercambiar sus certificados con otro dominio de CA (por 

ejemplo, con empleados de otra organización que tiene su propio dominio de CA), las dos CA pueden desarrollar 

una certificación cruzada; es decir, pueden llegar a un acuerdo para confiar mutuamente en la autoridad de cada 

una de ellas. En este caso, la estructura de la PKI no se extiende en vertical, sino en horizontal. 

Dominio CA: A Dominio CA: B 

Certificación 

cruzada 

Los usuarios del dominio A pueden utilizar sus certificados y pares de 

claves con los usuarios del dominio B porque ambas CA disponen de 

certificación cruzada entre sí. 

Por motivos prácticos y de comodidad, la PKI debe administrarse e implementarse de forma transparente. Para 

conseguirlo, NetScreen ScreenOS hace lo siguiente: 

1. Genera un par de claves pública/privada cuando se crea una petición de certificado. 

2. Proporciona esa clave pública como parte de la petición de certificado en un archivo de texto que se 

transmite a una autoridad de certificación (CA) para la inscripción del certificado (archivo PKCS #10). 



3. Permite cargar el certificado local, el certificado de CA y la lista de revocación de certificados (CRL) 1 en la 

unidad. 

También puede especificar un intervalo de tiempo para actualizar la CRL automáticamente. Para obtener 

más información sobre las CRL, consulte “Certificados y CRLs” en la página 29. 

4. Permite enviar certificados cuando se establece un túnel IPSec. 

5. Admite la validación ascendente de rutas de certificados a través de ocho niveles de autoridades CA en la 

jerarquía PKI. 

6. Es compatible con la norma de criptografía PKCS #7, lo que significa que el dispositivo NetScreen puede 

aceptar certificados X.509 y CRL empaquetadas según la norma PKCS #7 2 . La compatibilidad con PKCS 

#7 permite enviar múltiples certificados X.509 dentro de una única petición PKI. Ahora es posible configurar 

PKI para validar a la vez todos los certificados enviados por la CA emisora. 

7. Admite recuperación de CRL en línea a través de LDAP o HTTP. 

1. La autoridad de certificación normalmente proporciona una CRL. Aunque puede cargar una CRL en el dispositivo NetScreen, no podrá verla una vez 

cargada. 

2. NetScreen admite un tamaño de archivo PKCS #7 de hasta 7 kB. 


Capítulo 2 Criptografía de claves públicas Certificados y CRLs 

CERTIFICADOS Y CRLS 

Un certificado digital es un método electrónico para verificar la identidad de un usuario utilizando la palabra de una 

tercera parte en la que se confía, conocida como autoridad de certificación (CA). El servidor de CA que esté utilizando 

puede ser propiedad de una CA independiente 3 o de su propia organización, en cuyo caso usted será su propia CA. Si 

utiliza una CA independiente, debe ponerse en contacto con ella para obtener las direcciones de los servidores de CA 

y CRL (y conseguir certificados y listas de revocación de certificados) o la información que dichos servidores necesitan 

cuando envían peticiones de certificados personales. Si es su propia CA, podrá hacerlo por sí mismo. 

Nota: ScreenOS dispone de un certificado de CA para las descargas de autenticación desde el servidor de archivos 

de firmas de virus y el servidor de la base de datos de objetos de ataque Deep Inspection (DI). Para obtener más 

información sobre el servidor de archivos de firmas de virus, consulte “Análisis antivirus” en la página 4 -86. Para 

obtener más información sobre el servidor de la base de datos de objetos de ataque DI, consulte “Servidor de la 

base de datos de objetos de ataque” en la página 4 -141. 

Para utilizar un certificado digital y así autenticar su identidad al establecer una conexión VPN segura, siga estos 

pasos: 

Genere una clave en el dispositivo NetScreen, envíela a una CA para obtener un certificado personal 

(también llamado certificado local) y cargue el certificado en el dispositivo NetScreen. 

Consiga un certificado de la CA que emitió el certificado personal (básicamente para verificar la identidad 

de la CA que lo verifica a usted) y cargue el certificado de la CA en el dispositivo NetScreen. Esto lo puede 

hacer manual o automáticamente, utilizando el protocolo SCEP (Simple Certificate Enrollment Protocol). 

Si el certificado no contiene la extensión de punto de distribución de certificados (CDP) y no recibe 

automáticamente la CRL a través de LDAP o HTTP, puede obtenerla manualmente y cargarla en el 

dispositivo NetScreen. 

Durante el proceso de negociación, puede haber muchos casos en los que sea necesario revocar un certificado. Es 

posible que quiera revocar un certificado si sospecha que es peligroso o si su propietario ha dejado la empresa. Las 

revocaciones y validaciones de certificados se pueden administrar localmente (aunque esta solución es limitada) o 

con referencia a la CRL de una CA, a la que se puede acceder en línea de forma automática en intervalos diarios, 

semanales o mensuales, o según el intervalo predefinido por la CA. 

3. NetScreen admite las siguientes CAs: Baltimore, Entrust, Microsoft, Netscape, RSA Keon y Verisign. 



Obtención manual de un certificado 

Para conseguir un certificado firmado digitalmente siguiendo el método manual, debe seguir estos pasos: 

1. Generar un par de claves pública/privada 

2. Rellenar la petición de certificado 

3. Enviar la petición a la CA que desee 

4. Una vez recibido el certificado firmado, cargarlo en el dispositivo NetScreen junto con el certificado de CA 

Ahora dispondrá de los siguientes elementos con los siguientes objetivos: 

Un certificado local para el dispositivo NetScreen, para autenticar su identidad en cada conexión de túnel 

Un certificado de CA (clave pública de la CA), para verificar el certificado del otro interlocutor 

Si la lista de revocación de certificados (CRL) está incluida en el certificado de CA 4 , una CRL para 

identificar certificados no válidos 

Cuando reciba estos archivos (los archivos de certificado suelen tener la extensión .cer y los archivos de CRL, la 

extensión .crl), cárguelos en el dispositivo NetScreen siguiendo el procedimiento descrito en la siguiente sección. 

Nota: Si piensa utilizar el correo electrónico para enviar el archivo PKCS #10 y obtener los certificados, debe 

configurar adecuadamente los ajustes de NetScreen para poder enviar mensajes de correo electrónico al 

administrador del sistema. Deberá establecer los servidores DNS principal y secundario, y especificar los ajustes 

de dirección del servidor SMTP y del servidor de correo. 

4. La CRL puede acompañar al certificado de CA y se puede almacenar en la base de datos de NetScreen. Alternativamente, el certificado de CA puede 

contener la URL de la CRL (ya sea LDAP o HTTP) si ésta se encuentra almacenada en la base de datos de la CA. Si es incapaz de obtener la CRL por 

cualquiera de los métodos, puede introducir manualmente los ajustes predeterminados del servidor para la URL de la CRL en el dispositivo NetScreen, tal 

y como se explica en “Ejemplo: Configuración de ajustes de CRL” en la página 36. 



Ejemplo: Petición de certificado manual 

Cuando se solicita un certificado, el dispositivo NetScreen genera un par de claves. La clave pública se incorpora 

en la propia petición y, posteriormente, en el certificado local firmado digitalmente que recibirá de la CA. 

En el siguiente ejemplo, el administrador de seguridad realiza una petición de certificado para Michael Zhang en el 

departamento de desarrollo de Juniper Networks en Sunnyvale, California. Este certificado se utilizará en un 

dispositivo NetScreen con la dirección IP 10.10.5.44. El administrador ordena al dispositivo NetScreen que envíe la 

petición por correo electrónico al administrador de seguridad, que tiene la dirección admin@juniper.net. A 

continuación, el administrador de seguridad copia la petición y la pega en el campo de texto de petición de 

certificado en el punto de inscripción de certificados de la CA. Una vez finalizado el proceso de inscripción, la CA 

normalmente devuelve el certificado por correo electrónico al administrador de seguridad. 

Nota: Antes de generar una petición de certificado, compruebe que ha ajustado el reloj del sistema y que ha 

asignado un nombre de host y un nombre de dominio al dispositivo NetScreen. Si el dispositivo NetScreen se 

encuentra en un clúster NSRP, sustituya el nombre de host por un nombre de clúster. (Para obtener más 

información, consulte “Nombre de clúster” en la página 10 -18). 

WebUI 

1. Generación del certificado 

Objects > Certificates > New: Introduzca los siguientes datos y haga clic en Generate : 

Name: Michael Zhang 

Phone: 408-730-6000 

Unit/Department: Development 

Organization: Juniper Networks 

County/Locality: Sunnyvale 

State: CA 

Country: US 



E-mail: mzhang@juniper.net 5 

IP Address: 10.10.5.44 

Write to file: (seleccione) 

RSA: (seleccione) 

Create new key pair of 1024 6 length: (seleccione) 

El dispositivo NetScreen genera un archivo PKCS #10 y solicita que envíe el archivo por correo electrónico, 

lo guarde en disco o lo inscriba automáticamente a través del protocolo SCEP (“Simple Certificate 

Enrollment Protocol”). 

Seleccione la opción E-mail to , escriba admin@juniper.net y haga clic en OK 7 . 

2. Petición de certificado 

El administrador de seguridad abre el archivo y copia su contenido, procurando copiar el texto completo 

pero no los espacios en blanco situados delante o detrás del texto (comenzando por “-----BEGIN 

CERTIFICATE REQUEST-----” y finalizando en “-----END CERTIFICATE REQUEST-----”). 

A continuación, el administrador de seguridad sigue las direcciones de la petición de certificado en el sitio 

web de la CA, pegando el archivo PKCS #10 en el campo apropiado. 

3. Recuperación del certificado 

Cuando el administrador de seguridad recibe el certificado de la CA por correo electrónico, se lo reenvía a 

usted. Cópielo en un archivo de texto y guárdelo en su estación de trabajo (para después cargarlo en el 

dispositivo NetScreen a través de la interfaz WebUI) o en un servidor TFTP (para cargarlo a través de CLI). 

5. Ciertas CA no admiten direcciones de correo electrónico en los certificados. Si no incluye una dirección de correo electrónico en la petición de certificado 

local, no podrá utilizarla como identificación de IKE local al configurar el dispositivo NetScreen como interlocutor dinámico. En su lugar, podrá utilizar un 

nombre de dominio completo (si se encuentra en el certificado local) o dejar el campo vacío. De forma predeterminada, el dispositivo NetScreen envía su 

nombrehost.nombredominio. Si no especifica la identificación local para un interlocutor dinámico, introduzca el nombrehost.nombredominio del interlocutor 

en el dispositivo que se encuentra en el otro extremo del túnel IPSec en el campo de identificación del interlocutor. 

6. El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el certificado para SSL (consulte “Secure Sockets Layer” en la página 3 -8), asegúrese 

de que utiliza una longitud de bits que también sea compatible con su explorador web. 

7. Si utiliza la dirección de correo electrónico, se supone que ya ha configurado la dirección IP para el servidor SMTP: 

set admin mail server-name { ip_addr | dom_name }. 



CLI 

1. Generación del certificado 

set pki x509 dn country-name US 

set pki x509 dn email mzhang@juniper.net 

set pki x509 dn ip 10.10.5.44 

set pki x509 dn local-name “Santa Clara” 

set pki x509 dn name “Michael Zhang” 

set pki x509 dn org-name “Juniper Networks” 

set pki x509 dn org-unit-name Development 

set pki x509 phone 408-730-6000 

set pki x509 dn state-name CA 

set pki x509 default send-to admin@juniper.net 8 

exec pki rsa new-key 1024 

La petición de certificado se envía por correo electrónico a admin@juniper.net. 

2. Petición de certificado 

El administrador de seguridad abre el archivo y copia su contenido, procurando copiar el texto completo 

pero no los espacios en blanco situados delante o detrás del texto (comenzando por “-----BEGIN 

CERTIFICATE REQUEST-----” y finalizando en “-----END CERTIFICATE REQUEST-----”). 

A continuación, el administrador de seguridad sigue las direcciones de la petición de certificado en el sitio 

web de la CA, pegando el archivo PKCS #10 en el campo apropiado. 

3. Recuperación del certificado 

Cuando el administrador de seguridad recibe el certificado de la CA por correo electrónico, se lo reenvía a 

usted. Cópielo en un archivo de texto y guárdelo en su estación de trabajo (para después cargarlo en el 

dispositivo NetScreen a través de la interfaz WebUI) o en un servidor TFTP (para cargarlo a través de CLI). 

8. Si utiliza la dirección de correo electrónico, se supone que ya ha configurado la dirección IP para el servidor SMTP: 

set admin mail server-name { ip_addr | dom_name }. 



Ejemplo: Carga de certificados y CRLs 

La CA le devuelve los siguientes tres archivos para que los cargue en el dispositivo NetScreen: 

Un certificado de CA, que contiene la clave pública de la CA 

Un certificado local, que identifica su equipo local (su clave pública) 

Una CRL, que enumera los certificados revocados por la CA 

Para el ejemplo con la WebUI, habrá descargado los archivos a un directorio llamado C:\certs\ns en la estación de 

trabajo del administrador. Para el ejemplo con CLI, habrá descargado el directorio raíz TFTP a un servidor TFTP 

con la dirección IP 198.168.1.5. 

Nota: Los dispositivos NetScreen configurados con ScreenOS 2.5 o versiones posteriores, incluyendo los sistemas 

virtuales, permiten cargar certificados locales desde distintas CAs. 

En este ejemplo se muestra cómo se deben cargar dos archivos distintos, llamados auth.cer (certificado de CA) y 

local.cer (su clave pública), y el archivo de CRL, llamado distrust.crl. 

WebUI 

1. Objects > Certificates: Seleccione Load Cert y haga clic en Browse . 

2. Acceda al directorio C:\certs, seleccione auth.cer y haga clic en Open . 

La ruta del directorio y el nombre de archivo (C:\certs\ns\auth.cer) aparecerán en el campo File Browse. 

3. Haga clic en Load . 

Se cargará el archivo local.cer. 

4. Objects > Certificates: Seleccione Load Cert y haga clic en Browse . 

5. Acceda al directorio C:\certs, seleccione local.cer y haga clic en Open . 

La ruta del directorio y el nombre de archivo (C:\certs\ns\local.cer) aparecerán en el campo File Browse. 




Se cargará el archivo local.cer. 

7. Objects > Certificates: Seleccione Load CRL y haga clic en Browse . 

8. Acceda al directorio C:\certs, seleccione distrust.crl y haga clic en Open . 


CLI 

Se cargará el archivo de CRL distrust.crl. 

exec pki x509 tftp 198.168.1.5 cert-name auth.cer 

exec pki x509 tftp 198.168.1.5 cert-name local.cer 

exec pki x509 tftp 198.168.1.5 crl-name distrust.crl 



Ejemplo: Configuración de ajustes de CRL 

En la fase 1 de las negociaciones, los participantes consultan la lista CRL para comprobar si los certificados 

recibidos durante un intercambio IKE siguen siendo válidos. Si una CRL determinada no acompaña al certificado de 

CA correspondiente y no está cargada en la base de datos de NetScreen, el dispositivo NetScreen intentará 

recuperarla mediante la URL de LDAP o HTTP 9 definida en el propio certificado. Si no hay ninguna dirección URL 

definida en el certificado de CA, el dispositivo NetScreen utiliza la URL del servidor definido para ese certificado de 

CA. Si no define ninguna URL de CRL para un certificado de CA determinado, el dispositivo NetScreen utilizará el 

servidor CRL de la dirección URL de CRL predeterminada. 

Nota: Con ScreenOS 2.5 y versiones posteriores, al cargar la CRL puede desactivar la comprobación de firmas 

digitales. Sin embargo, si desactiva la comprobación del certificado de CRL pondrá en peligro la seguridad del 

dispositivo NetScreen. 

En este ejemplo, primero configurará el servidor de CA Entrust para comprobar la CRL diariamente mediante una 

conexión al servidor LDAP ubicado en 2.2.2.121 y la localización del archivo de CRL. A continuación configurará los 

ajustes predeterminados de validación de certificados para su uso en el servidor LDAP ubicado en 10.1.1.200, 

comprobando también diariamente la CRL. 

Nota: El número de índice (IDX) para el certificado de Entrust CA es 1. Para poder ver una lista de los números 

IDX de todos los certificados de CA cargados en un dispositivo NetScreen, utilice el siguiente comando CLI: 

get pki x509 list ca-cert . 

WebUI 

Objects > Certificates (Show: CA) > Server Settings (para NetScreen): Introduzca los siguientes datos y 

haga clic en OK : 

X509 Cert_Path Validation Level: Full 

CRL Settings: 

9. La extensión del punto de distribución de la CRL (.cdp) en un certificado X509 puede ser una URL HTTP o una URL LDAP. 



CLI 

URL Address: ldap:///CN=Entrust,CN=en2001,CN=PublicKeyServices, 

CN=Services,CN=Configuration,DC=EN2001,DC=com?CertificateRevocat 

ionList?base?objectclass=CRLDistributionPoint 

LDAP Server: 2.2.2.121 

Refresh Frequency: Daily 

Objects > Certificates > Default Cert Validation Settings: Introduzca los siguientes datos y haga clic en OK : 

X509 Certificate Path Validation Level: Full 

Certificate Revocation Settings: 

Check Method: CRL 

URL Address: ldap:///CN=NetScreen,CN=safecert,CN=PublicKeyServices, 

CN=Services,CN=Configuration,DC=SAFECERT,DC=com?CertificateRev 

ocationList?base?objectclass=CRLDistributionPoint 

LDAP Server: 10.1.1.200 

set pki authority 1 cert-path full 

set pki authority 1 cert-status crl url “ldap:///CN=Entrust,CN=en2001, 

CN=PublicKeyServices,CN=Services,CN=Configuration,DC=EN2000,DC=com?Certific 

ateRevocationList?base?objectclass=CRLDistributionPoint” 

set pki authority 1 cert-status crl server-name 2.2.2.121 

set pki authority 1 cert-status crl refresh daily 

set pki authority default cert-path full 

set pki authority default cert-status crl url “ldap:///CN=NetScreen, 

CN=safecert,CN=PublicKeyServices,CN=Services,CN=Configuration,DC=SAFECERT, 

DC=com?CertificateRevocationList?base?objectclass=CRLDistributionPoint” 

set pki authority default cert-status crl server-name 10.1.1.200 

set pki authority default cert-status crl refresh daily 

save 



Obtención automática de un certificado local 

Para utilizar un certificado digital y así autenticar su identidad al establecer una conexión VPN segura, siga estos 

pasos: 

Consiga el certificado de una autoridad de certificación (CA) de la cual desee obtener un certificado 

personal y cárguelo en el dispositivo NetScreen. 

Obtenga un certificado local (también llamado certificado personal) de la CA cuyo certificado de CA ya ha 

cargado y, a continuación, cargue el certificado local en el dispositivo NetScreen. Esto lo puede hacer 

manual o automáticamente, utilizando el protocolo SCEP (“Simple Certificate Enrollment Protocol”). 

Como durante el método manual para solicitar certificados locales se le va a pedir que copie información de un 

certificado a otro, puede llegar a ser un proceso largo. Para evitarlo, puede utilizar el método automático. 

Nota: Antes de utilizar el protocolo SCEP, debe llevar a cabo estas tareas: 

Configurar y habilitar DNS (consulte “Compatibilidad con DNS (sistema de nombres de dominio)” en la 

página 2 -379). 

Ajustar el reloj del sistema (consulte “Reloj del sistema” en la página 2 -467). 

Asignar un nombre de host y un nombre de dominio al dispositivo NetScreen. Si el dispositivo NetScreen se 

encuentra en un clúster NSRP, sustituya el nombre de host por un nombre de clúster. (Para obtener más 

información, consulte “Nombre de clúster” en la página 10 -18). 



Ejemplo: Petición automática de certificado 

En este ejemplo seguirá el método automático para solicitar un certificado local. Para ello utilizará el protocolo 

SCEP con la autoridad de certificación Verisign. Establecerá los siguientes ajustes de CA: 

Validación de la ruta de certificado completa 

RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe 10 

CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe 

Confirmación automática de la integridad de los certificados de CA 

CA ID, que identifica un servidor SCEP, donde el servidor SCEP de Verisign utilizará un nombre de 

dominio, como juniper.net, o un dominio establecido por Verisign para su empresa 

Contraseña de desafío 

Sondeo automático de certificado cada 30 minutos (de forma predeterminada no se realiza ningún sondeo) 

A continuación generará un par de claves RSA, especificando una longitud de 1024 bits, e iniciará la operación 

SCEP para solicitar un certificado local de la CA Verisign con los ajustes de CA anteriormente mencionados. 

Si utiliza la interfaz WebUI, hará referencia a los certificados de CA por su nombre. Si utiliza CLI, hará referencia a 

los certificados de CA por su número de índice (IDX). En este ejemplo, el número IDX de la CA Verisign es “1”. Para 

consultar los números IDX para los certificados de CA, utilice el siguiente comando: get pki x509 list ca-cert . 

Aparecerá un número IDX y un número de ID para cada certificado. Apunte el número IDX y utilícelo para hacer 

referencia al certificado de CA en los comandos. 

10. La interfaz de puerta de enlace común (CGI, o “Common Gateway Interface”) es un método estándar que utilizan los servidores web para enviar una petición 

de usuario a un programa de aplicación y recibir a cambio datos. La interfaz CGI forma parte del protocolo de transferencia de hipertexto (HTTP, o “Hypertext 

Transfer Protocol”). Debe especificar una ruta RA CGI aunque la autoridad de registro (RA) no exista. Si la RA no existe, utilice el valor especificado para 

la CA CGI. 



WebUI 

1. Ajustes del servidor de CA 

Objects > Certificates > Show CA > Server Settings (para Verisign): Introduzca los siguientes datos y haga 

clic en OK : 

X509 certificate path validation level: Full 

SCEP Settings: 

RA CGI: http://ipsec.verisigncom/cgi-bin/pkiclient.exe 

CA CGI: http://ipsec.verisigncom/cgi-bin/pkiclient.exe 

> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en 

Return para regresar a la página de configuración básica CA Server 

Settings: 

Polling Interval: 30 

Certificate Authentication: Auto 

Certificate Renew: 14 

2. Petición de certificado local 


Name: Michael Zhang 

Phone: 408-730-6000 

Unit/Department: Development 

Organization: Juniper Networks 

County/Locality: Sunnyvale 

State: CA 

Country: US 

Email: mzhang@juniper.net 

IP Address: 10.10.5.44 



Key Pair Information: 


Create new key pair of 1024 11 length. 

Ejecute el comando CLI get pki x509 pkcs para que el dispositivo NetScreen genere un archivo PKCS #10 

y, a continuación, siga uno de estos pasos: 

– Envíe el archivo PKCS #10 de petición de certificado a una dirección de correo electrónico 

– Guárdelo en disco 

– Inscríbalo automáticamente enviando el archivo a una CA que admita el protocolo SCEP 

3. Inscripción automática 

Seleccione la opción Automatically enroll to , luego la opción Existing CA server settings y, finalmente, 

Verisign en la lista desplegable. 

Póngase en contacto con Verisign para informarles sobre su petición de certificado. Verisign debe autorizar 

la petición de certificado antes de que usted pueda descargarlo. 

11. El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el certificado para SSL, asegúrese de que utiliza una longitud de bits que también 

sea compatible con su explorador web. 



CLI 

1. Ajustes del servidor de CA 

set pki authority 1 cert-path full 

set pki authority 1 scep ca-cgi “http://ipsec.verisign.com/cgi-bin 

/pkiclient.exe” 12 

set pki authority 1 scep ra-cgi “http://ipsec.verisign.com/cgi-bin 

/pkiclient.exe” 13 

set pki authority 1 scep polling-int 30 

set pki authority 1 scep renew-start 14 

2. Petición de certificado local 

set pki x509 dn country-name US 

set pki x509 dn email mzhang@juniper.net 

set pki x509 dn ip 10.10.5.44 

set pki x509 dn local-name “Santa Clara” 

set pki x509 dn name “Michael Zhang” 

set pki x509 dn org-name “Juniper Networks” 

set pki x509 dn org-unit-name Development 

set pki x509 phone 408-730-6000 

set pki x509 dn state-name CA 

exec pki rsa new 1024 

3. Inscripción automática 

exec pki x509 scep 1 

Si ésta es la primera petición de certificado que envía a esta CA, aparecerá un mensaje presentando un 

valor de marca de identidad para el certificado de CA. Debe ponerse en contacto con la CA para confirmar 

que se trata del certificado de CA correcto. 

Póngase en contacto con Verisign para informarles sobre su petición de certificado. Verisign debe autorizar 

la petición de certificado antes de que usted pueda descargarlo. 

12. La interfaz de puerta de enlace común (CGI, o “Common Gateway Interface”) es un método estándar que utilizan los servidores web para enviar una petición 

de usuario a un programa de aplicación y recibir a cambio datos. La interfaz CGI forma parte del protocolo de transferencia de hipertexto (HTTP, o “Hypertext 

Transfer Protocol”). 

13. Debe especificar una ruta RA CGI aunque la autoridad de registro (RA) no exista. Si la RA no existe, utilice el valor especificado para la CA CGI. 



Renovación automática de certificado 

Puede habilitar el dispositivo NetScreen para que renueve automáticamente los certificados adquiridos a través de 

SCEP. Esta función evita tener que acordarse de renovar los certificados en el dispositivo NetScreen antes de que 

venzan y, gracias al token, mantiene la validez de los certificados en todo momento. 

De forma predeterminada, esta función está inhabilitada. Puede configurar el dispositivo NetScreen para que envíe 

automáticamente una petición para renovar un certificado antes de que venza. Puede establecer el momento en 

que desee que el dispositivo NetScreen envíe la petición de renovación del certificado en días y minutos antes de la 

fecha de vencimiento. Si establece momentos distintos para cada certificado, evitará que el dispositivo NetScreen 

tenga que renovar todos los certificados al mismo tiempo. 

Para evitar problemas con esta función, el dispositivo NetScreen debe ser capaz de acceder al servidor SCEP y el 

certificado debe estar presente en el propio dispositivo NetScreen durante el proceso de renovación. También debe 

asegurarse de que la CA que emite el certificado pueda hacer lo siguiente: 

Admitir la aprobación automática de peticiones de certificado. 

Devolver el mismo nombre de dominio (DN). En otras palabras, la CA no debe modificar el nombre del 

sujeto ni la extensión SubjectAltName en el nuevo certificado. 

Puede activar y desactivar la función de renovación automática de certificados SCEP para todos los certificados 

SCEP o de forma individual. 

Generación de pares de claves 

Los dispositivos NetScreen guardan en memoria las claves generadas automáticamente. El número de claves 

depende del modelo de dispositivo. Durante el funcionamiento normal, el dispositivo NetScreen es capaz de 

disponer de claves suficientes para renovar certificados, puesto que cada vez que utiliza una clave genera otra 

nueva. El proceso de generación de claves normalmente se ejecuta en segundo plano a medida que el dispositivo 

tiene tiempo para generar una nueva clave antes de que se necesite utilizar otra. En caso de que el dispositivo 

NetScreen renueve un gran número de certificados al mismo tiempo y tenga que utilizar claves rápidamente, podría 

llegar a quedarse sin claves y tener que generarlas inmediatamente con cada nueva petición. En este caso, la 

generación de claves puede afectar al rendimiento del dispositivo NetScreen. Especialmente en un entorno de HA 

(alta disponibilidad), donde el rendimiento del dispositivo NetScreen puede disminuir durante una serie de minutos. 

El número de pares de claves generadas automáticamente en un dispositivo NetScreen depende del modelo. Para 

más información, consulte la hoja de especificaciones de su producto NetScreen. 


Capítulo 2 Criptografía de claves públicas Comprobación de estado mediante OCSP 

COMPROBACIÓN DE ESTADO MEDIANTE OCSP 

Cuando un dispositivo NetScreen realiza una operación en la que se utiliza un certificado, suele ser importante 

verificar su validez. Los certificados pueden quedar invalidados por vencimiento o por revocación. La forma habitual 

de comprobar el estado de los certificados es utilizar las listas de revocación de certificados (CRLs). El protocolo de 

estado de certificado en línea (OCSP, u “Online Certificate Status Protocol”) es otra forma de comprobar el estado 

de los certificados. Este protocolo ofrece información adicional sobre los certificados y realiza comprobaciones de 

estado periódicas. 

Cuando un dispositivo NetScreen utiliza el protocolo OCSP, se le considera el cliente OCSP (o solicitante). Dicho 

cliente envía una petición de verificación a un servidor llamado servidor de respuesta OCSP. ScreenOS es 

compatible con RSA Keon y Verisign como servidores de respuesta OCSP 14 . La petición del cliente incluye la 

identidad del certificado que se debe comprobar. Antes de que el dispositivo NetScreen pueda realizar operaciones 

OCSP, debe configurarlo para que reconozca la ubicación del servidor de respuesta OCSP. 

Una vez recibida la petición, el servidor de respuesta OCSP confirma que la información de estado del certificado 

está disponible y, a continuación, devuelve el estado actual al dispositivo NetScreen. La respuesta del servidor 

OCSP contiene el estado de revocación del certificado, el nombre del servidor de respuesta y el periodo de validez 

de la respuesta. A menos que la respuesta sea un mensaje de error, el servidor de respuesta firmará la respuesta 

utilizando su clave privada. El dispositivo NetScreen verifica la validez de la firma del servidor de respuesta 

utilizando su certificado. Este certificado del servidor de respuesta puede estar incorporado en la respuesta OCSP 

o almacenado localmente y especificado en la configuración de OCSP. Si el certificado está almacenado 

localmente, utilice el siguiente comando para especificar el certificado almacenado localmente: 

set pki authority id_num1 cert-status ocsp cert-verify id id_num2 

id_num1 identifica el certificado de CA que emitió el certificado que se va a verificar; id_num2 identifica el 

certificado almacenado localmente que el dispositivo utiliza para verificar la firma en la respuesta OCSP. 

Si el certificado del servidor de respuesta no está incorporado en la respuesta OCSP o almacenado localmente, el 

dispositivo NetScreen verifica la firma utilizando el certificado de la CA que emitió el certificado en cuestión. 

14. Juniper Networks también ha sido evaluado satisfactoriamente con el servidor de respuesta OCSP Valicert durante un examen exhaustivo en el pasado. 



Configuración de OCSP 

Puede utilizar comandos CLI para configurar un dispositivo NetScreen para OCSP. La mayoría de estos comandos 

utilizan un número de identificación para asociar la URL de referencia de la revocación con el certificado de CA. 

Puede obtener este número ID con el siguiente comando CLI: 

get pki x509 list ca-cert 

Nota: El dispositivo NetScreen asigna de forma dinámica el número ID del certificado de CA cuando se elabora la 

lista de certificados de CA. Este número puede cambiar si se modifica el almacenamiento de certificados. 

Especificación de CRL u OCSP 

Para especificar el método de comprobación de revocaciones (CRL, OCSP o ninguno) para un certificado de una 

determinada CA, utilice la siguiente sintaxis en CLI: 

set pki authority id_num cert-status revocation-check { CRL | OCSP | none } 

donde id_num será el número de identificación del certificado. 

El siguiente ejemplo especifica la comprobación de revocaciones con OCSP. 

set pki authority 3 cert-status revocation-check ocsp 

El número de ID 3 identifica el certificado de la CA. 

Visualización de los atributos de comprobación de estado 

Para visualizar los atributos de comprobación de estado de una CA determinada, utilice la siguiente sintaxis en CLI: 

get pki authority id_num cert-status 

donde id_num será el número de identificación del certificado emitido por la CA. 

Para visualizar los atributos de comprobación de estado para la CA que emitió el certificado 7: 

get pki authority 7 cert-status 



Especificación de la URL de un servidor de respuesta OCSP 

Para especificar la cadena de URL de un servidor de respuesta OCSP para un certificado en particular, utilice la 

siguiente sintaxis en CLI: 

set pki authority id_num cert-status ocsp url url_str 

Para especificar la cadena de URL de un servidor de respuesta OCSP (http:\\192.168.10.10) para la CA con 

certificado 5, utilice la siguiente sintaxis en CLI: 

set pki authority 5 cert-status ocsp url http:\\192.168.10.10 

Para eliminar la URL (http:\\192.168.2.1) de un servidor de CRL para el certificado 5: 

unset pki authority 5 cert-status ocsp url http:\\192.168.2.1 

Eliminación de atributos de comprobación de estado 

Para eliminar todos los atributos de comprobación de estado de una CA emisora de un determinado certificado, 

utilice la siguiente sintaxis: 

unset pki authority id_num cert-status 

Para eliminar todos los atributos de revocación relativos al certificado 1: 

unset pki authority 1 cert-status 


Capítulo 2 Criptografía de claves públicas Certificados autofirmados (“Self-Signed Certificates”) 

CERTIFICADOS AUTOFIRMADOS (“SELF-SIGNED CERTIFICATES”) 

Un certificado autofirmado es un certificado firmado y publicado por la misma entidad; es decir, el emisor y el sujeto 

del certificado coinciden. Por ejemplo, los certificados CA de todas las autoridades de certificación raíz (CAs) son 

autofirmados. 

Los dispositivos NetScreen generan automáticamente un certificado autofirmado al encenderse, si no hay ningún 

certificado ya configurado para Secure Sockets Layer (SSL), como es el caso cuando se enciende por primera vez. 

El dispositivo NetScreen que crea un certificado autogenerado y autofirmado es el único dispositivo que lo utiliza. El 

dispositivo nunca exporta este certificado fuera de sí mismo. Aunque el dispositivo NetScreen se encuentra en un 

clúster del protocolo de redundancia de NetScreen (“NetScreen Redundancy Protocol” o “NSRP”), no incluye el 

certificado autofirmado y autogenerado con otros tipos de certificados al sincronizar objetos PKI con otros 

miembros del clúster. (Los miembros del NSRP intercambian certificados autofirmados generados manualmente. 

Para obtener información sobre la generación manual de certificados autofirmados, consulte “Creación manual de 

certificados autofirmados” en la página 51). 

Aunque no se pueden exportar certificados autofirmados y autogenerados, puede copiar su nombre de sujeto y 

huella. A continuación, puede entregarlo a un administrador remoto que más adelante podrá utilizar el nombre del 

sujeto y la huella digital para verificar el certificado autofirmado recibido durante las negociaciones SSL. Comprobar 

el nombre del sujeto y la huella digital es una precaución importante contra los ataques por interposición de intrusos 

(“man-in-the-middle attacks”), en los que alguien intercepta un intento de conexión SSL y finge ser el dispositivo 

NetScreen de destino, respondiendo con su propio certificado autofirmado. (Para obtener más información sobre la 

verificación de certificados autofirmados, consulte “Validación de certificados” en la página 49). 



Asegurar el tráfico administrativo con SSL 

Puede utilizar un certificado autofirmado al establecer una conexión Secure Sockets Layer (SSL) con el dispositivo 

NetScreen. Si administra el dispositivo a través de WebUI, SSL puede proporcionar autenticación y encriptación 

para asegurar su tráfico administrativo. Puede incluso configurar un dispositivo NetScreen para redirigir un intento 

de conexión administrativo utilizando HTTP (puerto predeterminado 80) hacia SSL (puerto predeterminado 443). 

Nota: Para obtener más información sobre SSL, incluyendo el mecanismo de redirección HTTP-a-SSL, consulte 

“Secure Sockets Layer” en la página 3 -8. 

De forma predeterminada, el dispositivo NetScreen pone a disposición el certificado autofirmado y autogenerado 

para las negociaciones SSL. Es el certificado SSL predeterminado. Si más adelante instala un certificado firmado 

por una CA o configura el dispositivo NetScreen para que genere otro certificado autofirmado 15 , puede utilizar uno 

de estos otros certificados para SSL. Si elimina el certificado autofirmado y autogenerado y no asigna otro 

certificado para su uso en SSL, el dispositivo NetScreen genera automáticamente otro certificado autofirmado la 

próxima vez que el dispositivo se reinicie 16 . 

15. Para averiguar cómo crear otro certificado autofirmado, consulte “Creación manual de certificados autofirmados” en la página 51. 

16. Para averiguar cómo eliminar un certificado autofirmado y autogenerado, consulte “Eliminación de certificados autofirmados” en la página 60. 



Validación de certificados 

Durante el establecimiento de conexión SSL, el dispositivo NetScreen se autentica enviando un certificado al cliente 

SSL. Cuando el dispositivo NetScreen envía un certificado autofirmado, el cliente SSL no puede validarlo 

comprobando la firma de la CA emisora porque no la publicó ninguna CA. No obstante, cuando el dispositivo 

NetScreen presenta un certificado autofirmado para establecer una sesión SSL, el explorador web del equipo del 

administrador intenta validarlo con un certificado CA en su almacén de CAs (autoridades de certificación). Si no 

puede encontrar esa autoridad, el explorador visualiza un mensaje como el siguiente, pidiendo al administrador que 

acepte o rechace el certificado en cuestión: 

Cuando un explorador recibe un certificado 

autofirmado, pueden aparecer dos tipos de alertas 

de seguridad. 

Si esta es la primera vez que se conecta al dispositivo NetScreen después de su arranque inicial, el reloj del 

sistema puede no estar en hora. Por lo tanto, el período de validez indicado en el certificado también puede ser 

inexacto. Aunque ponga en hora el reloj del sistema y regenere un certificado autofirmado, el explorador web nunca 

podrá encontrar una CA que lo autentique, por lo que el administrador debe estar preparado para obtener uno de 

los mensajes antedichos cada vez que el dispositivo NetScreen utilice un certificado autofirmado para una conexión 

SSL. 



Sin poder recurrir a la validación del certificado por parte de una CA imparcial e independiente, el administrador que 

inicie una sesión a través de SSL podría preguntarse si el certificado autofirmado recibido realmente procede del 

dispositivo NetScreen al que está intentando conectarse. (Después de todo, el certificado podría ser un impostor 

que esté utilizando un ataque por interposición de intrusos (man-in-the-middle attack) para intentar enmascararse 

como dispositivo NetScreen). El administrador puede validar el certificado recibido utilizando el nombre del sujeto y 

la huella digital del certificado autofirmado. Puede entregar el nombre del sujeto y la huella digital al administrador 

para que pueda validar el certificado autofirmado cuando el dispositivo NetScreen lo suministre más adelante para 

autenticarse. 

Para consultar el nombre del sujeto y la huella digital de un certificado autofirmado y autogenerado, utilice el 

comando siguiente 17 : 

ns-> get pki x509 cert system 

. . . 

CN=0043022002000186,CN=system generated,CN=self-signed, 

. . . 

finger print (md5) 

finger print (sha) 

Después de ver el nombre del sujeto y la huella digital, puede copiarlos y entregarlos (con el método seguro y “fuera 

de banda” que usted elija) al administrador que posteriormente se conectará al dispositivo NetScreen a través de 

SSL. Cuando el cliente SSL del administrador reciba el certificado desde el dispositivo NetScreen durante el 

establecimiento de conexión SSL, podrá comparar el nombre del sujeto y la huella digital del certificado recibido con 

los recibidos anteriormente “fuera de banda”. Si coinciden, sabrá que el certificado es auténtico. Dada la ausencia 

de una autoridad CA de confianza para autenticar el certificado, sin nombre de sujeto y huella digital que comparar, 

el administrador remoto no puede saber con certeza si el certificado es genuino. 

17. WebUI no permite visualizar los detalles de un certificado autofirmado y autogenerado. 



Creación manual de certificados autofirmados 

El dispositivo NetScreen genera automáticamente un certificado autofirmado la primera vez que se enciende, con el 

fin de admitir SSL durante la conexión inicial. Sin embargo, puede que desee generar un certificado autofirmado 

distinto del que genera automáticamente el dispositivo NetScreen. Éstas son algunas razones posibles para 

reemplazar el certificado autofirmado y autogenerado por un certificado autofirmado y definido por el administrador: 

El certificado autofirmado y autogenerado utiliza un tamaño de clave fijo de 1024 bits. Dependiendo de sus 

necesidades, puede necesitar claves con un tamaño mayor o menor, que puede controlar al generar su 

propia clave autofirmada. 

Puede que desee utilizar un certificado con un nombre de sujeto distinto del creado automáticamente. 

Puede necesitar varios certificados autofirmados. En los dispositivos NetScreen que admiten sistemas 

virtuales, el sistema raíz puede compartir el certificado autofirmado y autogenerado con todos los sistemas 

virtuales. Sin embargo, los administradores de vsys pueden preferir generar sus propios certificados 

autofirmados y, a continuación, exigir a sus administradores que comprueben el nombre del sujeto y la 

huella digital de estos certificados específicos en lugar de los atributos de un certificado compartido. 

Nota: A diferencia de un certificado autofirmado y autogenerado, que nunca sale del dispositivo en el cual se crea, 

un certificado autofirmado y generado manualmente se incluye con otros certificados cuando un dispositivo 

NetScreen de un clúster NSRP sincroniza objetos PKI con otros miembros del clúster. 

Aunque puede configurar varios componentes de un certificado autofirmado (como los campos de nombres 

distinguidos (“distinguished name” o “DN”), el nombre alternativo del sujeto y el tamaño de la clave), los siguientes 

elementos de nombres comunes (“common name” o “CN”) siempre aparecen al final del DN: 

“CN = dev_serial_num, CN = NetScreen self-signed” 



Aunque el principal uso previsto de un certificado autofirmado es permitir que un dispositivo NetScreen pueda 

establecer inmediatamente conexiones Secure Sockets Layer (SSL), este certificado se puede utilizar igual que 

cualquier otro certificado firmado por una CA. Las aplicaciones de un certificado autofirmado pueden ser las 

siguientes: 

Establecer una conexión Secure Sockets Layer (SSL) para proteger el tráfico administrativo hacia un 

dispositivo NetScreen 

Asegurar el tráfico entre NetScreen-Security Manager (NSM) y un dispositivo NetScreen 

Autenticar interlocutores IKE al establecer túneles VPN 

Nota: Para la versión actual de ScreenOS, NetScreen solamente admite certificados autofirmados para su 

uso con SSL. 



Ejemplo: Certificado autofirmado y definido por el administrador 

En este ejemplo, definirá los siguientes componentes de un certificado autofirmado para su uso con SSL: 

Distinguished Name/Subject Name: 

– Name: 4ssl 

– Organization: jnpr 

– FQDN: www.juniper.net 

Key type and length: RSA, 1024 bits 

Después de definirlo, generará el certificado y lo visualizará. A continuación, podrá copiar el nombre del sujeto y la 

huella digital (también denominados “thumbprint”) para su distribución a otros administradores que inicien una 

sesión a través de SSL para administrar el dispositivo NetScreen. 

Cuando un administrador intente iniciar una sesión con SSL, el dispositivo NetScreen le enviará este certificado. 

Cuando lo reciba, podrá abrirlo y comparar el nombre del sujeto y la huella digital que aparecen en el certificado con 

la información que recibió previamente. Si coinciden, sabrá que el certificado es auténtico. 

WebUI 

1. Definir los atributos del certificado 


Certificate Subject Information: 

Name: 4ssl 

Organization: jnpr 

FQDN: www.juniper.net 

Key Pair Information: 


Create new key pair of 1024 length. 



2. Generar el certificado autofirmado 

Cuando el dispositivo NetScreen ha completado la generación de la clave, compone una petición de 

certificado. Haga clic en Generate Self-Signed Cert . 

3. Ver el certificado autofirmado 

Objects > Certificates > Show Local: Haga clic en Detail para ver el certificado recién creado. 

Aparece la página siguiente con los detalles del certificado: 

Puede copiar el nombre del sujeto y la huella digital desde esta página y comunicarlo a otros 

administradores que pretendan utilizar SSL al administrar el dispositivo NetScreen. Cuando inicien una 

conexión SSL, podrán utilizar esta información para asegurarse de que el certificado que reciben procede, 

de hecho, del dispositivo NetScreen. 



CLI 

1. Definir los atributos del certificado 

set pki x509 dn name 4ssl 

set pki x509 dn org-name jnpr 

set pki x509 cert-fqdn www.juniper.net 

save 

2. Generar el certificado autofirmado 

Para generar un par de claves pública/privada que los dispositivos NetScreen utilizarán en sus 

peticiones de certificado, ejecute el comando siguiente: 

exec pki rsa new-key 1024 

Después de que el dispositivo NetScreen genere un par de claves, compondrá la petición de 

certificado siguiente: 

-----BEGIN CERTIFICATE REQUEST----- 

MIIB0jCCATsCAQAwZTENMAsGA1UEChMESk5QUjEZMBcGA1UEAxMQMDA0MzAyMjAw 

MjAwMDE4NjEQMA4GA1UEAxMHcnNhLWtleTEYMBYGA1UEAxMPd3d3Lmp1bmlwZXIu 

bmV0MQ0wCwYDVQQDEwQ1c3NsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDP 

aAtelkL4HxQmO1w1jv9NMmrWnzdVYnGrKrXnw2MaB3xEgouWrlymEkZetA2ouKeA 

D24SL0h1YvJ7Sd9PvkhwHOnvP1zkOCWA84TgvxBzcAyeBnS1UpSwcC0admX0Da6T 

80EUuGrmUWodddRFUc8o5d2VGTUOM7WgcFDZRSGQGwIDAQABoC0wKwYJKoZIhvcN 

AQkOMR4wHDAaBgNVHREEEzARgg93d3cuanVuaXBlci5uZXQwDQYJKoZIhvcNAQEF 

BQADgYEAgvDXI4H905y/2+k4omo9Y4XQrgq44Rj3jqXAYYMgQBd0Q8HoyL5NE3+i 

QUkiYjMTWO2wIWzEr4u/tdAISEVTu03achZa3zIkUtn8sD/VYKhFlyPCBVvMiaHd 

FzIHUgBuMrr+awowJDG6wARhR75w7pORXy7+aAmvIjew8YRre9s= 

-----END CERTIFICATE REQUEST----- 



Para conocer el número de identificación del par de claves, utilice el comando siguiente: 

get pki x509 list key-pair 

Getting OTHER PKI OBJECT ... 

IDX ID num X509 Certificate Subject Distinguish Name 

=========================================================================== 

0000 176095259 CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=0043022002000186, 

O=jnpr, 

=========================================================================== 

Para generar el certificado autofirmado, ejecute el comando siguiente, haciendo referencia al número 

de identificación del par de claves que vio en el resultado del comando anterior: 

exec pki x509 self-signed-cert key-pair 176095259 

3. Ver el certificado autofirmado 

Para visualizar el certificado autofirmado recién creado, ejecute el comando siguiente: 

get pki x509 list local-cert 

Getting LOCAL CERT ... 

IDX ID num X509 Certificate Subject Distinguish Name 

=========================================================================== 

0000 176095261 LOCAL CERT friendly name 

LOCAL CERT friendly name 

CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=0043022002000186, 

O=jnpr, 

Expire on 10-19-2009 17:20, Issued By: 


O=jnpr, 

=========================================================================== 



Para ver el certificado más detalladamente, ejecute el comando siguiente usando el número de 

identificación del certificado: 

get pki x509 cert 176095261 

-0001 176095261 LOCAL CERT friendly name 


O=jnpr, 

Expire on 10-19-2009 17:20, Issued By: 


O=jnpr, 

Serial Number: 

subject alt name extension: 

email(1): (vacío) 

fqdn(2): (www.juniper.net) 

ipaddr(7): (vacío) 

no renew 



subject name hash: 

use count: 

flag 

Puede copiar el nombre del sujeto (“subject name”) y la huella digital (“fingerprint”) desde esta 

página y comunicarlo a otros administradores que pretendan utilizar SSL para administrar el dispositivo 

NetScreen. Cuando inicien una conexión SSL, podrán utilizar esta información para asegurarse de que el 

certificado que reciben procede, de hecho, del dispositivo NetScreen. 



Autogeneración de certificados 

La primera vez que se encienda el dispositivo NetScreen, generará automáticamente un certificado autofirmado. El 

principal propósito de este certificado es reconocer inmediatamente SSL después del arranque inicial de un 

dispositivo NetScreen. Para ver este certificado, utilice el comando CLI siguiente 18 : 

get pki x509 cert system 


Expire on 08- 3-2014 16:19, Issued By: 


Serial Number: 



subject name hash: 

De forma predeterminada, el dispositivo NetScreen genera automáticamente un certificado autofirmado durante el 

proceso de arranque si se cumplen las condiciones siguientes: 

En el dispositivo no existe ningún certificado autofirmado generado automáticamente. 

No se ha asignado ningún certificado para su uso con SSL. 

Puede utilizar el comando siguiente para consultar si ya hay configurado un certificado para SSL: 

get ssl 

web SSL enable. 

web SSL port number(443). 

web SSL cert: Default - System Self-Signed Cert. 

web SSL cipher(RC4_MD5). 

En el resultado anterior, puede ver que SSL está utilizando el certificado autofirmado y generado 

automáticamente (“System”). 

18. Sólo CLI permite ver certificados autofirmados generados automáticamente. 



El diagrama siguiente muestra la ruta de decisiones que el dispositivo NetScreen toma al encenderse para la 

generación de certificados: 

Ruta de decisiones para 

la autogeneración de 

certificados 

Comienzo del proceso 

de arranque 

¿Hay cert 

autogen y 

autofirm? 

No 

¿Hay cert 

para SSL? 

No generar automáticamente 

un certificado autofirmado. 

Si elimina el certificado autofirmado y generado automáticamente, asigne otro certificado para su uso con SSL y 

resetee el dispositivo; el dispositivo NetScreen no generará otro certificado autofirmado durante el proceso de 

arranque. Si a continuación cambia la configuración de SSL para no asignarle ningún certificado y luego resetea el 

dispositivo, el dispositivo NetScreen generará automáticamente un nuevo certificado autofirmado durante el 

siguiente proceso de arranque. 


Sí 

No 

Generar 

automáticamente un 

certificado autofirmado. 

Sí


Eliminación de certificados autofirmados 

Puede eliminar un certificado autofirmado generado automática o manualmente, igual que se puede con cualquier 

tipo de certificado. Puede que disponga de un certificado firmado por una CA que prefiera utilizar para SSL en lugar 

de un certificado autofirmado. Sea cual sea el motivo para eliminar el certificado autofirmado y autogenerado, utilice 

el comando CLI siguiente 19 : 

delete pki object-id system 

Para eliminar un certificado autofirmado y configurado por el administrador, utilice el comando siguiente, donde 

id_num es el número de identificación del certificado que desea eliminar 20 : 

delete pki object-id id_num 

Si elimina el certificado autofirmado y autogenerado y más adelante desea que el dispositivo NetScreen genere 

otro, haga lo siguiente: 

No asigne ningún otro certificado para SSL (puede utilizar el comando siguiente: unset ssl cert ). 

Restablezca el dispositivo NetScreen. 

El dispositivo NetScreen puede redirigir el tráfico HTTP (puerto predeterminado 80) enviado al dispositivo hacia 

SSL (puerto predeterminado 443) 21 . Por lo tanto, para asegurarse de que un certificado esté disponible para SSL, 

durante el proceso de arranque el dispositivo NetScreen siempre comprueba si existe un certificado autofirmado y 

autogenerado o si se ha asignado a SSL otro certificado. Si no hay ningún certificado autofirmado y autogenerado y 

no se asigna ningún otro certificado para su uso con SSL, el dispositivo NetScreen genera automáticamente un 

certificado autofirmado. 

19. Sólo CLI permite eliminar certificados autofirmados generados automáticamente. 

20. Para averiguar el número de identificación de un certificado, utilice el comando siguiente: get pki x509 list local-cert . 

21. Para obtener información sobre la redirección del tráfico HTTP a SSL, consulte “Redireccionamiento de HTTP a SSL” en la página 3 -12. 


Capítulo 3 

Directivas VPN 

3 

NetScreen ofrece una variedad de opciones criptográficas para configurar un túnel VPN. Incluso para configurar un 

túnel simple es necesario elegir entre varias opciones. El objetivo de la primera mitad de este capítulo es resumir 

todas las opciones disponibles para una VPN punto a punto básica y una VPN de acceso telefónico básica y ofrecer 

uno o más motivos para decantarse por una opción u otra. 

En la segunda mitad del capítulo, examinaremos las diferencias que existen entre los túneles VPN basados en 

rutas y los túneles VPN basados en directivas. A continuación revisaremos el flujo de paquetes de un túnel VPN 

AutoKey IKE punto a punto basado en directivas y basado en rutas para ver las etapas de procesamiento de 

entrada y salida por las que pasa un paquete. El capítulo termina con algunos consejos útiles de configuración VPN 

que hay que tener en cuenta a la hora de configurar un túnel. 

El capítulo está organizado del siguiente modo: 

“Opciones criptográficas” en la página 62 

– “Opciones criptográficas punto a punto” en la página 63 

– “Opciones VPN de acceso telefónico” en la página 72 

“Túneles basados en directivas y en rutas” en la página 80 

“Flujo de paquetes: VPN punto a punto” en la página 82 

“Consejos para la configuración de un túnel” en la página 90 

“Consideraciones sobre seguridad en VPNs basadas en rutas” en la página 93 

– “Ruta nula” en la página 94 

– “Línea de acceso telefónico o arrendada” en la página 96 

– “Interfaz de túnel ficticia” en la página 100 

– “Enrutador virtual para interfaces de túnel” en la página 101 

– “Reencaminar a otro túnel” en la página 101 


Capítulo 3 Directivas VPN Opciones criptográficas 

OPCIONES CRIPTOGRÁFICAS 

Durante la configuración de una VPN es necesario tomar numerosas decisiones sobre la criptografía que se desea 

utilizar. Surgirán preguntas sobre cuál es el grupo Diffie-Hellman adecuado, qué algoritmo de encriptación ofrece el 

mejor equilibrio entre seguridad y rendimiento, etc. En esta sección se presentan todas las opciones criptográficas 

requeridas para configurar un túnel VPN punto a punto básico y un túnel VPN de acceso telefónico básico. También 

se indican una o más ventajas de cada opción para ayudarle a tomar una decisión. 

La primera decisión que hay que tomar es si se va a optar por un túnel VPN punto a punto (entre dos dispositivos 

NetScreen) o por un túnel VPN de acceso telefónico (desde el cliente VPN NetScreen-Remote hasta el dispositivo 

NetScreen). Aunque esta decisión depende de la configuración de red, las diferencias entre estos dos tipos de 

túneles afectan a algunas opciones criptográficas. Por lo tanto, las opciones se presentan en dos modelos de 

decisión distintos: 

“Opciones criptográficas punto a punto” en la página 63 

“Opciones VPN de acceso telefónico” en la página 72 

Cuando haya decidido qué tipo de túnel desea configurar (de acceso telefónico o punto a punto), consulte el 

modelo de decisión correspondiente para obtener las indicaciones oportunas. En cada modelo se presentan las 

decisiones criptográficas que deberá tomar durante la configuración del túnel. A continuación, se señalan los 

motivos que justifican la elección de cada opción del modelo. 

Nota: En el Capítulo 4, “VPNs punto a punto”, y el Capítulo 5, “VPNs de acceso telefónico”, se incluyen ejemplos de 

configuración de ambos tipos de túneles. 



Opciones criptográficas punto a punto 

Durante la configuración de un túnel VPN punto a punto básico, deberá seleccionar las opciones criptográficas del 

siguiente modelo de decisión que se ajusten a sus necesidades. A continuación se indican las ventajas de cada 

opción. 

Nota: Las opciones recomendadas por Juniper Networks están resaltadas en color púrpura. Para obtener 

información sobre las distintas opciones IPSec, consulte el Capítulo 1, “IPSec”. 

1. Método de administración de claves: 

AutoKey IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o bien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clave manual 

2. Modo: 

Dinámico o bien Principal 

3. Tipo de autenticación: 

Certificados o bien Clave 

previamente compartida 

4. Tipo de certificado: 

RSA o DSA 

5. Longitud de bits: 

512 o bien 768 o bien 1024 o 

bien 2048 

8. ID IKE local: 

Dirección IP o bien 

U-FQDN o bien FQDN o bien 

ASN1-DN 

Fase 1, puerta de enlace IKE 

6. Grupo Diffie-Hellman IKE: 

1 o bien 2 o bien 5 

7. Algoritmos de autenticación y 

encriptación IKE: 

AES o bien DES o bien 3DES 

y 

MD5 o bien SHA-1 

9. ID IKE remota: 

Dirección IP o bien 


ASN1-DN 

13. Protocolo IPSec: ESP o AH 

ESP . . . . . . . . o bien . . . . . . . . AH 

14. Modo: 

Túnel o bien Transporte 

15. Opciones ESP: 

Encriptación o bien Encriptación y 

autenticación o bien Auth 

16. Algoritmos de 

encriptación: 


10. Comprobación contra reprocesamiento de paquetes: 

Sí o no 

Sí o bien No 

11. Confidencialidad directa perfecta: 

Sí o bien No 

12. Grupo Diffie-Hellman IPSec: 


Fase 2, túnel VPN 


autenticación: 




1. Método de administración de claves: Clave manual o AutoKey IKE 

AutoKey IKE 

– Ofrece una renovación de claves automática, con lo que aumenta la seguridad. 

Clave manual 

– Resulta útil para depurar problemas IKE. 

– Elimina los retardos de negociación IKE a la hora de establecer un túnel. 

2. Modo: dinámico o principal 

Dinámico 

– Es necesario cuando la dirección IP de uno de los interlocutores IPSec está asignada de forma 

dinámica y si se utiliza una clave previamente compartida. 

Principal 

– Ofrece protección de identidad. 

– Se puede utilizar cuando el usuario de acceso telefónico posee una dirección IP estática o si se 

utilizan certificados para la autenticación. 

3. Tipo de autenticación: clave previamente compartida o certificados 

Certificados 

– Ofrece mayor seguridad que las claves previamente compartidas porque es posible validar los 

certificados a través de una autoridad de certificación (CA). (Para obtener más información, consulte 

el Capítulo 2, “Criptografía de claves públicas”). 

Clave previamente compartida 

– Es más fácil de manejar y más rápida de configurar, porque no requiere una infraestructura de claves 

públicas (PKI). 



4. Tipo de certificado: RSA o DSA 

Depende de la CA de la que se obtengan los certificados. Ningún tipo de certificado presenta ventajas en 

comparación con el otro. 

5. Longitud de bits: 512, 768, 1024 ó 2048 

512 

768 

– Su nivel máximo de procesamiento es el más bajo. 

– Ofrece más seguridad que la opción de 512 bits. 

– Su nivel máximo de procesamiento es inferior al de las opciones de 1024 y 2048 bits. 

1024 

– Ofrece más seguridad que las opciones de 512 y 768 bits. 

– Su nivel máximo de procesamiento es inferior al de la opción de 2048 bits. 

2048 

– Ofrece la máxima seguridad. 

6. Grupo Diffie-Hellman IKE: 1, 2 ó 5 

Grupo Diffie-Hellman 1 

– Su nivel máximo de procesamiento es inferior al de los grupos Diffie-Hellman 2 y 5. 

– Aceleración de procesamiento proporcionada por el hardware NetScreen. 

Diffie-Hellman Group 2 

– Su nivel máximo de procesamiento es inferior al del grupo Diffie-Hellman 5. 

– Ofrece más seguridad que el grupo Diffie-Hellman 1. 






7. Algoritmos de autenticación y encriptación IKE: AES, DES o 3DES y MD5 o SHA-1 

AES 

– Tiene un mayor nivel de encriptación que DES y 3DES si las longitudes de clave son iguales. 


– Algoritmo de encriptación aprobado para las normas federales para procesamiento de la información 

(FIPS, o “Federal Information Processing Standards”) y los criterios comunes de EAL4. 

DES 

– Su nivel máximo de procesamiento es inferior al de 3DES y AES. 

– Resulta útil cuando el interlocutor remoto no admite AES. 

3DES 

– Ofrece más seguridad criptográfica que DES. 


MD5 

– Su nivel máximo de procesamiento es inferior al de SHA-1. 

SHA-1 

– Ofrece más seguridad criptográfica que MD5. 

– Es el único algoritmo de autenticación que admiten las normas FIPS. 

8. ID IKE local: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN 

Dirección IP 

– Sólo se puede utilizar si el dispositivo NetScreen local tiene una dirección IP estática. 

– Es la ID IKE predeterminada cuando se utiliza una clave previamente compartida para la autenticación. 

– Se puede utilizar con un certificado si la dirección IP aparece en el campo SubjectAltName. 



U-FQDN 

– Nombre de dominio completo de usuario (U-FQDN, dirección de correo electrónico): se puede utilizar 

con una clave previamente compartida o un certificado si el U-FQDN aparece en el campo 

SubjectAltName. 

FQDN 

– Nombre de dominio completo (FQDN): se puede utilizar con una clave previamente compartida o un 

certificado si el FQDN aparece en el campo SubjectAltName. 

– Resulta útil para puertas de enlace VPN que tengan direcciones IP dinámicas. 

– Es la ID IKE predeterminada cuando se utilizan certificados RSA o DSA para la autenticación. 

ASN1-DN 

– Sólo se puede utilizar con certificados. 

– Resulta útil si la CA no admite el campo SubjectAltName en los certificados que emite. 

9. ID IKE remota: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN 

Dirección IP 

– No requiere la introducción de una ID IKE remota para un interlocutor con dirección IP estática cuando 

se utilizan claves previamente compartidas para la autenticación y el interlocutor es un dispositivo 

NetScreen. 

– Se puede utilizar para un dispositivo con dirección IP estática. 

– Se puede utilizar con una clave previamente compartida o un certificado si la dirección IP aparece en 

el campo SubjectAltName. 

U-FQDN 






FQDN 




– No requiere la introducción de una ID IKE remota cuando se utilizan certificados para la autenticación 

y el interlocutor es un dispositivo NetScreen. 

ASN1-DN 



10. Comprobación contra reprocesamiento de paquetes: Sí o no 

Sí 

– Permite al destinatario comprobar los números de secuencia de los encabezados de paquetes para 

prevenir ataques de rechazo de servicio (DoS) provocados cuando un atacante reenvía paquetes 

IPSec interceptados. 

No 

– Desactivar esta opción tal vez sea la solución a problemas de compatibilidad con interlocutores de 

terceros. 

11. Confidencialidad directa perfecta: Sí o no 

Sí 

– Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los interlocutores 

realizan un segundo intercambio Diffie-Hellman para generar la clave utilizada para la 

encriptación/desencriptación IPSec. 

No 

– Agiliza la configuración del túnel. 

– Reduce el procesamiento durante las negociaciones IPSec de fase 2. 



12. Grupo Diffie-Hellman IPSec: 1, 2 ó 5 











ESP 

AH 

– Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad mediante encriptación y 

encapsulado del paquete IP original e integridad mediante autenticación. 

– Puede proporcionar sólo encriptación o sólo autenticación. 

– Encabezado de autenticación (AH): ofrece autenticación del paquete IP completo, incluyendo el 

encabezado IPSec y el encabezado IP externo. 

14. Modo: túnel o transporte 

Túnel 

– Oculta el encabezado IP original, con lo que aumenta la privacidad. 

Transporte 

– Es necesario para el soporte del túnel L2TP sobre IPSec. 



15. Opciones ESP: sólo encriptación, sólo autenticación o encriptación y autenticación 

Encriptación 

– Ofrece un rendimiento más rápido y su nivel máximo de procesamiento es inferior al de la opción de 

encriptación y autenticación. 

– Resulta útil cuando se requiere confidencialidad, pero no autenticación. 

Encriptación y autenticación 

– Resulta útil si se desea obtener confidencialidad y autenticación. 

Auth 

– Resulta útil cuando se requiere autenticación, pero no confidencialidad. Por ejemplo, cuando la 

información no es secreta, pero es importante determinar que procede realmente de la persona que 

dice enviarla y que nadie ha manipulado el contenido durante la transmisión. 

16. Algoritmos de encriptación: AES, DES o 3DES 

AES 



– Algoritmo de encriptación aprobado para normas FIPS y criterios comunes EAL4. 

DES 



3DES 





17. Algoritmos de autenticación: MD5 o SHA-1 

MD5 


SHA-1 


Si se utilizan las opciones recomendadas de la lista anterior, una configuración VPN punto a punto genérica entre 

dos dispositivos NetScreen con direcciones IP estáticas estaría formada por los siguientes componentes: 

AutoKey IKE Confidencialidad directa perfecta (PFS) = sí 

Modo principal Grupo Diffie-Hellman 2 para fase 2 

Certificados de 1024 bits (RSA o DSA) Carga de seguridad encapsulada (ESP) 

Grupo Diffie-Hellman 2 para fase 1 Modo de túnel 

Encriptación = AES Encriptación y autenticación 

Autenticación = SHA-1 Encriptación = AES 

ID IKE = dirección IP (valor predeterminado) Autenticación = SHA-1 

Protección contra reprocesamiento de paquetes = sí 



Opciones VPN de acceso telefónico 

Durante la configuración de un túnel VPN de acceso telefónico básico, deberá seleccionar las opciones 

criptográficas del siguiente modelo de decisión que se ajusten a sus necesidades. A continuación se indican las 

ventajas de cada opción. 

Nota: Las opciones recomendadas por Juniper Networks están resaltadas en color púrpura . Para obtener 

información sobre las distintas opciones IPSec, consulte el Capítulo 1, “IPSec”. 

1. Modo: 

Dinámico o bien Principal 

2. Tipo de autenticación: 

Certificados o bien Clave 

previamente compartida 

3. Tipo de certificado: 

RSA o DSA 

4. Longitud de bits: 

512 o bien 768 o bien 1024 o 

bien 2048 

7. ID IKE local: 

Dirección IP (valor 

predeterminado) o bien 


ASN1-DN 

Fase 1, puerta de enlace IKE 

Método de administración de claves = AutoKey IKE 

5. Grupo Diffie-Hellman IKE: 


6. Algoritmos de autenticación y 

encriptación IKE: 


y 


8. ID IKE remota: 

Dirección IP (valor 

predeterminado) o bien 


ASN1-DN 

12. Protocolo IPSec: 

ESP . . . . . . . . o bien . . . . . . . . AH 

13. Modo: 

Túnel o bien Transporte 

14. Opciones ESP: 

Encriptación o bien Encriptación y autenticación 

o bien Autenticación 

15. Algoritmos de encriptación: 


9. Comprobación contra 

reprocesamiento de paquetes: 

Sí o bien No 

10. Confidencialidad directa 

perfecta: 

Sí o bien No 

11. Grupo Diffie-Hellman IPSec: 


Fase 2, túnel VPN 






1. Modo: Dinámico o principal 

Dinámico 

– Es necesario cuando la dirección IP de uno de los interlocutores IPSec está asignada de forma 

dinámica y si se utiliza una clave previamente compartida. 

– Se puede utilizar con certificados o claves previamente compartidas para la autenticación. 

Principal 

– Ofrece protección de identidad. 

2. Tipo de autenticación: clave previamente compartida o certificados 

Certificados 

– Ofrece mayor seguridad que las claves previamente compartidas porque es posible validar los 

certificados a través de una autoridad de certificación (CA). (Para obtener más información, consulte 

el Capítulo 2, “Criptografía de claves públicas”). 


– Es más fácil de manejar y más rápida de configurar, porque no requiere una infraestructura de claves 

públicas (PKI). 

3. Tipo de certificado: RSA o DSA 

Depende de la CA de la que se obtengan los certificados. Ningún tipo de certificado presenta ventajas en 

comparación con el otro. 

4. Longitud de bits: 512, 768, 1024 ó 2048 

512 

768 

– Su nivel máximo de procesamiento es el más bajo. 

– Ofrece más seguridad que la opción de 512 bits. 

– Su nivel máximo de procesamiento es inferior al de las opciones de 1024 y 2048 bits. 



1024 

– Ofrece más seguridad que las opciones de 512 y 768 bits. 

– Su nivel máximo de procesamiento es inferior al de la opción de 2048 bits. 

2048 


5. Grupo Diffie-Hellman IKE: 1, 2 ó 5 










6. Algoritmos de autenticación y encriptación IKE: AES, DES o 3DES y MD5 o SHA-1 

AES 




DES 





3DES 



MD5 


SHA-1 


7. ID IKE local: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN 

Dirección IP (valor predeterminado) 

– No requiere la introducción de una ID IKE para un dispositivo con dirección IP estática. 




U-FQDN 




FQDN 




ASN1-DN 





8. ID IKE remota: dirección IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN 

Dirección IP (valor predeterminado) 

– No requiere la introducción de una ID IKE para un dispositivo con dirección IP estática. 




U-FQDN 




FQDN 




ASN1-DN 



9. Comprobación contra reprocesamiento de paquetes: Sí o no 

Sí 

No 

– Permite al destinatario comprobar los números de secuencia de los encabezados de paquetes para 

prevenir ataques de rechazo de servicio (DoS) provocados cuando un atacante reenvía paquetes 

IPSec interceptados. 

– Desactivar esta opción tal vez sea la solución a problemas de compatibilidad con interlocutores de 

terceros. 



10. Confidencialidad directa perfecta: Sí o no 

Sí 

No 

– Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los interlocutores 

realizan un segundo intercambio Diffie-Hellman para generar la clave utilizada para la 

encriptación/desencriptación IPSec. 

– Agiliza la configuración del túnel. 

– Reduce el procesamiento durante las negociaciones IPSec de fase 2. 

11. Grupo Diffie-Hellman IPSec: 1, 2 ó 5 













ESP 

AH 

– Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad mediante encriptación y 

encapsulado del paquete IP original e integridad mediante autenticación. 

– Puede proporcionar sólo encriptación o sólo autenticación. 

– Encabezado de autenticación (AH): ofrece autenticación del paquete IP completo, incluyendo el 

encabezado IPSec y el encabezado IP externo. 

13. Modo: túnel o transporte 

Túnel 

– Oculta el encabezado IP original, con lo que aumenta la privacidad. 

Transporte 

– Es necesario para el soporte del túnel L2TP sobre IPSec. 

14. Opciones ESP: sólo encriptación, sólo autenticación o encriptación y autenticación 

Encriptación 

– Ofrece un rendimiento más rápido y su nivel máximo de procesamiento es inferior al de la opción de 

encriptación y autenticación. 

– Resulta útil cuando se requiere confidencialidad, pero no autenticación. 

Encriptación y autenticación 

– Resulta útil si se desea obtener confidencialidad y autenticación. 

Autenticación 

– Resulta útil cuando se requiere autenticación, pero no confidencialidad. Por ejemplo, cuando la 

información no es secreta, pero es importante determinar que procede realmente de la persona que 

dice enviarlo y que nadie ha manipulado el contenido durante la transmisión. 



15. Algoritmos de encriptación: AES, DES o 3DES 

AES 




DES 



3DES 



16. Algoritmos de autenticación: MD5 o SHA-1 

MD5 


SHA-1 


Si se utilizan las opciones recomendadas de la lista anterior, una configuración VPN de acceso telefónico genérica 

entre dos dispositivos NetScreen con direcciones IP estáticas estaría formada por los siguientes componentes: 

Modo dinámico Confidencialidad directa perfecta (PFS) = sí 

Certificados de 1024 bits (RSA o DSA) Grupo Diffie-Hellman 2 para fase 2 

Grupo Diffie-Hellman 2 para fase 1 Carga de seguridad encapsulada (ESP) 

Encriptación = AES Modo de túnel 

Autenticación = SHA-1 Encriptación y autenticación 

ID IKE = U-FQDN (dirección de correo electrónico) Encriptación = AES 

Protección contra reprocesamiento de paquetes = sí Autenticación = SHA-1 


Capítulo 3 Directivas VPN Túneles basados en directivas y en rutas 

TÚNELES BASADOS EN DIRECTIVAS Y EN RUTAS 

La configuración de un dispositivo NetScreen para el soporte VPN es particularmente flexible. Es posible crear 

túneles VPN basados en directivas y basados en rutas. Además, en cada tipo de túnel se puede utilizar clave 

manual o AutoKey IKE para administrar las claves utilizadas para la encriptación y la autenticación. 

En el caso de los túneles VPN basados en directivas, un túnel se gestiona como un objeto (o un bloque de 

construcción) que, junto con el origen, el destino, el servicio y la acción, comprende una directiva que permite el 

tráfico VPN. (En realidad, la acción de directiva VPN es tunnel , pero la acción permit está implícita si no se 

especifica). En una configuración VPN basada en directivas, una directiva hace referencia de forma específica a un 

túnel VPN por su nombre. 

En las VPN basadas en rutas, la directiva no hace referencia de forma específica al túnel VPN. En su lugar, la 

directiva hace referencia a una dirección de destino. Cuando el dispositivo NetScreen realice una consulta de ruta 

para averiguar la interfaz a través de la que debe enviar el tráfico para alcanzar esa dirección, encontrará una ruta 

a través de una interfaz de túnel, que estará asociada a un túnel 1 VPN específico. 

Por lo tanto, con un túnel VPN basado en directivas, un túnel se puede considerar como un elemento en la 

construcción de una directiva. Con un túnel VPN basado en rutas, un túnel se puede considerar como un medio 

para entregar tráfico, y la directiva se puede considerar como un método para permitir o denegar la entrega de 

dicho tráfico. 

El número de túneles VPN basados en directivas que se pueden crear está limitado por el número de directivas que 

admita el dispositivo. El número de túneles VPN basados en rutas que se puede crear está limitado por el número 

de entradas de ruta o por el número de interfaces de túnel que admita el dispositivo (el que sea más pequeño). 

La configuración de un túnel VPN basado en rutas es una elección acertada si desea conservar los recursos de 

túnel y ajustar restricciones granulares para el tráfico VPN. Aunque puede crear numerosas directivas que hagan 

referencia al mismo túnel VPN, cada directiva crea una asociación de seguridad (SA) IPSec individual con el 

interlocutor remoto; cada una de estas asociaciones cuenta como un túnel VPN independiente. Con el enfoque 

basado en rutas para las VPN, la regulación del tráfico no está ligada al medio de entrega. Es posible configurar 

docenas de directivas para regular el tráfico que circula a través de un único túnel VPN entre dos puntos, si sólo hay 

1. Normalmente, una interfaz de túnel está asociada a un solo túnel. No obstante, también es posible asociar una interfaz de túnel a varios túneles. Para 

obtener más información, consulte “Múltiples túneles por interfaz de túnel” en la página 381. 


Capítulo 3 Directivas VPN Túneles basados en directivas y en rutas 

una SA IPSec operativa. Además, la configuración de una VPN basada en rutas permite crear directivas que hagan 

referencia a un destino alcanzado a través de un túnel VPN donde la acción sea deny , en contraste con la 

configuración de una VPN basada en directivas, donde, como hemos indicado antes, la acción debe ser tunnel con 

la acción implícita permit . 

Otra ventaja de las VPN basadas en rutas es el intercambio de información de enrutamiento dinámico a través de 

túneles VPN. Es posible habilitar una instancia de un protocolo de enrutamiento dinámico, como BGP (Border 

Gateway Protocol), en una interfaz de túnel asociada a un túnel VPN. La instancia de enrutamiento local 

intercambia información de enrutamiento a través del túnel con un vecino habilitado en una interfaz de túnel 

asociada al otro extremo. 

Si un túnel no conecta grandes redes en las que se ejecuten protocolos de enrutamiento dinámico y no es 

necesario conservar túneles o definir diversas directivas para filtrar el tráfico a través del túnel, tiene sentido 

configurar un túnel basado en directivas. Además, como no existe ninguna red más allá de un cliente VPN de 

acceso telefónico, los túneles VPN basados en directivas pueden ser una buena elección para configuraciones 

VPN de acceso telefónico. 

Dicho esto, si el cliente de acceso telefónico admite una dirección IP interna virtual (como NetScreen-Remote), 

existen argumentos convincentes para utilizar una configuración VPN basada en rutas. Un túnel VPN de acceso 

telefónico basado en rutas presenta las siguientes ventajas: 

Se puede asociar su interfaz de túnel a cualquier zona para requerir o no la aplicación de directivas. 

Se pueden definir rutas para forzar el tráfico a través del túnel, al contrario de lo que ocurre con una 

configuración VPN basada en directivas. 

Un túnel VPN basado en rutas simplifica la adición de un radio a una configuración radial (consulte “VPNs 

radiales” en la página 471). 

Puede ajustar la ID de proxy para que acepte cualquier dirección IP del cliente VPN de acceso telefónico 

configurando la dirección del cliente remoto como 255.255.255.255/32. 

Puede definir una o más direcciones IP asignadas (MIP) en la interfaz del túnel. 

Nota: Para obtener un ejemplo de una configuración VPN basada en rutas para un cliente de acceso telefónico, 

consulte “Ejemplo: VPN de acceso telefónico basada en rutas, interlocutor dinámico” en la página 244. 


Capítulo 3 Directivas VPN Flujo de paquetes: VPN punto a punto 

FLUJO DE PAQUETES: VPN PUNTO A PUNTO 

Para comprender mejor cómo interactúan los diversos componentes que intervienen en la creación de un túnel 

IPSec, en esta sección se describe el proceso de un flujo de paquetes a través de un túnel (tanto cuando un 

dispositivo NetScreen envía tráfico VPN saliente como cuando recibe tráfico VPN entrante). Se explica el proceso 

de una VPN basada en rutas y a continuación se incluye un anexo en el que se indican los dos puntos del flujo que 

difieren en el caso de una VPN basada en directivas. 

Una empresa con sede en Tokio acaba de abrir una sucursal en París y necesita conectar los dos puntos mediante 

un túnel IPSec. El túnel tiene las siguientes características: AutoKey IKE, protocolo ESP, AES para encriptación, 

SHA-1 para autenticación con clave previamente compartida y comprobación contra reprocesamiento de paquetes 

habilitada. Los dispositivos NetScreen que protegen cada punto se encuentran en modo NAT, y todas las zonas se 

ubican en el dominio de enrutamiento trust-vr. Las direcciones son las siguientes: 

Zona Trust 

ethernet1 

10.1.1.1/24 

10.1.1.5 

Tokio 

LAN 

Oficina 

de 

Tokio 

tunnel.1, 10.1.2.1/24 

Zona Untrust 

Interfaz de salida: ethernet3, 1.1.1.1/24 

Enrutador externo: 1.1.1.250 

Internet 

La ruta de un paquete procedente de 10.1.1.5/32 en la LAN de Tokio y destinado a 10.2.2.5/32 en la LAN de París 

a través de un túnel IPSec se desarrolla tal como se describe en las subsecciones siguientes. 


vpn1 

Zona Untrust 

Enrutador externo: 2.2.2.250 

Interfaz de salida: ethernet3, 2.2.2.2/24 

tunnel.2, 10.2.1.1/24 

Oficina 

de 

París 

París 

LAN 

10.2.2.5 

ethernet1 

10.2.2.1/24 

Zona Trust


Tokio (iniciador) 

1. El host en 10.1.1.5 envía un paquete para 10.2.2.5 a 10.1.1.1, que es la dirección IP ethernet1 y es la 

puerta de enlace predeterminada configurada en los ajustes TCP/IP del host. 

2. El paquete llega a ethernet1, que está asociado a la zona Trust. 

3. Si hay habilitadas opciones SCREEN como la detección de suplantación de IP para la zona Trust, el 

dispositivo NetScreen activa el módulo SCREEN en este momento. La comprobación de SCREEN puede 

producir uno de los tres resultados siguientes: 

– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para bloquear el 

paquete correspondiente, el dispositivo NetScreen descarta el paquete y genera una entrada en el 

registro de eventos. 

– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para registrar el 

evento pero no bloquear el paquete, el dispositivo NetScreen registra el evento en la lista de 

contadores SCREEN para ethernet1 y continúa con el paso siguiente. 

– Si el mecanismo SCREEN no detecta ningún comportamiento anómalo, el dispositivo NetScreen 

procede al paso siguiente. 

Si no ha habilitado ninguna opción SCREEN para la zona Trust, el dispositivo NetScreen continúa 

inmediatamente con el paso siguiente. 

4. El módulo de sesiones realiza una consulta de sesiones para comprobar si el paquete coincide con una 

sesión existente. 

Si el paquete no coincide con una sesión existente, el dispositivo NetScreen ejecuta los pasos restantes 

con el procedimiento de procesamiento del primer paquete. 

Si el paquete coincide con una sesión existente, el dispositivo NetScreen ejecuta el procedimiento de 

procesamiento rápido utilizando la información disponible en la entrada de sesiones existente para 

procesar el paquete. El procedimiento de procesamiento rápido omite las consultas de rutas y directivas 

porque la información generada por los pasos omitidos ya se obtuvo durante el procesamiento del primer 

paquete de la sesión. 



5. El módulo de asignación de direcciones comprueba si una dirección IP asignada (MIP) utiliza la dirección IP 

de destino 10.2.2.5. Como 10.2.2.5 no se utiliza en ninguna configuración MIP, el dispositivo NetScreen 

continúa con el paso siguiente. (Para obtener información sobre el procesamiento de paquetes cuando 

existe traducción de direcciones de destino [NAT-dst], MIP o VIP, consulte “Flujo de paquetes para 

NAT-Dst” en la página 7 -38). 

6. Para determinar la zona de destino, el módulo de rutas realiza una consulta de rutas para 10.2.2.5. (El 

módulo de rutas utiliza la interfaz de entrada para determinar qué enrutador virtual debe utilizar para la 

consulta de rutas). Encuentra una entrada de ruta que dirige el tráfico a 10.2.2.5 a través de la interfaz 

tunnel.1 asociada a un túnel VPN llamado “vpn1”. La interfaz de túnel se encuentra en la zona Untrust. 

Determinando las interfaces de entrada y salida, el dispositivo NetScreen determina las zonas de origen y 

de destino y puede realizar una consulta de directivas. 

7. El motor de directivas realiza una consulta de directivas entre las zonas Trust y Untrust (según lo 

determinado por las correspondientes interfaces de entrada y de salida). La acción especificada en la 

directiva que coincide con la dirección de origen y la zona, la dirección de destino y la zona, y el servicio es 

permitir. 

8. El módulo IPSec comprueba si existe una asociación de seguridad (SA) de fase 2 activa con el interlocutor 

remoto. Mediante la comprobación de SA de fase 2 se pueden obtener los siguientes resultados: 

– Si el módulo IPSec descubre una SA de fase 2 activa con el interlocutor, continúa con el paso 10. 

– Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor, descarta el paquete y 

activa el módulo IKE. 

9. El módulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor remoto. Mediante la 

comprobación de SA de fase 1 se pueden obtener los siguientes resultados: 

– Si el módulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza esta SA para negociar 

una SA de fase 2. 

– Si el módulo IKE no descubre una SA de fase 1 activa con el interlocutor, inicia negociaciones de fase 

1 en modo principal y, luego, negociaciones de fase 2. 



10. El módulo IPSec coloca un encabezado ESP y un encabezado IP externo en el paquete. Utilizando la 

dirección especificada como interfaz de salida, indica 1.1.1.1 como dirección IP de origen en el encabezado 

externo. Utilizando la dirección especificada para la puerta de enlace remota, indica 2.2.2.2 como la 

dirección IP de destino en el encabezado externo. A continuación, encripta el paquete desde la carga hasta 

el siguiente campo de encabezado en el encabezado IP original. Luego, autentica el paquete desde el 

finalizador ESP hasta el encabezado ESP. 

11. El dispositivo NetScreen envía el paquete encriptado y autenticado dirigido a 2.2.2.2 a través de la interfaz 

de salida (ethernet3) al enrutador externo en 1.1.1.250. 

París (destinatario) 

1. El paquete llega a 2.2.2.2, que es la dirección IP de ethernet3, una interfaz asociada a la zona Untrust. 

2. Mediante el SPI, la dirección IP de destino y el protocolo IPSec incluidos en el encabezado de paquete 

externo, el módulo IPSec intenta localizar una SA de fase 2 activa con el interlocutor iniciador junto con las 

claves para autenticar y desencriptar el paquete. Mediante la comprobación de SA de fase 2 se puede 

obtener uno de los tres siguientes resultados: 

– Si el módulo IPSec descubre una SA de fase 2 activa con el interlocutor, continúa con el paso 4. 

– Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor pero puede comparar una 

SA de fase 2 inactiva utilizando la dirección IP de origen pero no el SPI, descarta el paquete, realiza 

una entrada en el registro de eventos y envía una notificación al interlocutor iniciador para avisar de 

que ha recibido un SPI incorrecto. 

– Si el módulo IPSec no descubre una SA de fase 2 activa con el interlocutor, descarta el paquete y 

activa el módulo IKE. 

3. El módulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor remoto. Mediante la 

comprobación de SA de fase 1 se pueden obtener los siguientes resultados: 

– Si el módulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza esta SA para negociar 

una SA de fase 2. 

– Si el módulo IKE no descubre una SA de fase 1 activa con el interlocutor, inicia negociaciones de fase 

1 en modo principal y, luego, negociaciones de fase 2. 

4. El módulo IPSec realiza una comprobación contra reprocesamiento de paquetes. Mediante esta 

comprobación se puede obtener uno de los dos resultados siguientes: 



– Si el paquete no pasa la comprobación contra reprocesamiento de paquetes (porque se detecte un 

número de secuencia que el dispositivo NetScreen ya haya recibido), el dispositivo NetScreen 

descarta el paquete. 

– Si el paquete pasa la comprobación contra reprocesamiento de paquetes, el dispositivo NetScreen 

continúa con el siguiente paso. 

5. El módulo IPSec intenta autenticar el paquete. Mediante la comprobación de autenticación se puede 

obtener uno de los dos resultados siguientes: 

– Si el paquete no pasa la comprobación de autenticación, el dispositivo NetScreen descarta el 

paquete. 

– Si el paquete pasa la comprobación de autenticación, el dispositivo NetScreen continúa con el 

siguiente paso. 

6. Mediante la SA de fase 2 y las claves, el módulo IPSec desencripta el paquete, descubriendo la dirección 

de origen original (10.1.1.5) y el destino final (10.2.2.5). Averigua que el paquete ha llegado a través de 

vpn1, que está asociada a tunnel.1. A partir de este momento, el dispositivo NetScreen gestiona el paquete 

teniendo en cuenta que su interfaz de entrada es tunnel.1 en lugar de ethernet3. También ajusta la ventana 

deslizante contra reprocesamiento de paquetes. 

7. Si hay habilitadas opciones SCREEN para la zona Untrust, el dispositivo NetScreen activa el módulo 

SCREEN en este momento. La comprobación de SCREEN puede producir uno de los tres resultados 

siguientes: 

– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para bloquear el 

paquete correspondiente, el dispositivo NetScreen descarta el paquete y genera una entrada en el 

registro de eventos. 

– Si un mecanismo SCREEN detecta un comportamiento anómalo y está configurado para registrar el 

evento pero no bloquear el paquete, el dispositivo NetScreen registra el evento en la lista de 

contadores SCREEN para ethernet3 y continúa con el paso siguiente. 

– Si el mecanismo SCREEN no detecta ningún comportamiento anómalo, el dispositivo NetScreen 

procede al paso siguiente. 

8. El módulo de sesiones realiza una consulta de sesiones para comprobar si el paquete coincide con una 

sesión existente. A continuación, aplica el procedimiento de procesamiento del primer paquete o de 

procesamiento rápido. 



Si el paquete coincide con una sesión existente, el dispositivo NetScreen ejecuta “Fast Processing”, 

utilizando la información disponible en la entrada de sesiones existente para procesar el paquete. “Fast 

Processing” omite todos los pasos salvo los dos últimos (encriptar el paquete y reenviarlo) porque la 

información generada por los pasos omitidos ya se obtuvo durante el procesamiento del primer paquete de 

la sesión. 

9. El módulo de asignación de direcciones comprueba si una dirección IP asignada (MIP) o virtual (VIP) utiliza 

la dirección IP de destino 10.2.2.5. Como 10.2.2.5 no se utiliza en ninguna configuración MIP o VIP, el 

dispositivo NetScreen continúa con el paso siguiente. 

10. El módulo de rutas utiliza primero la interfaz de entrada para determinar el enrutador virtual que debe 

utilizar para la consulta de rutas; en este caso, trust-vr. A continuación, realiza una consulta de rutas para 

10.2.2.5 en trust-vr y descubre que el acceso se ha llevado a cabo a través de ethernet1. Determinando la 

interfaz de entrada (tunnel.1) y la de salida (ethernet1), el dispositivo NetScreen puede determinar las 

zonas de origen y destino. La interfaz tunnel.1 está asociada a la zona Untrust y ethernet1 a la zona Trust. 

El dispositivo NetScreen puede realizar ahora una consulta de directivas. 

11. El motor de directivas comprueba su lista de directivas desde la zona Untrust hasta la zona Trust y 

encuentra una directiva que permite el acceso. 

12. El dispositivo NetScreen reenvía el paquete a través de ethernet1 a su destino en 10.2.2.5. 



Anexo: VPN basadas en directivas 

El flujo de paquetes para una configuración VPN basada en directivas difiere en dos puntos del de la configuración 

VPN basada en rutas: la consulta de rutas y la consulta de directivas. 

Tokio (iniciador) 

Las primeras etapas del flujo de paquetes saliente son las mismas para las configuraciones VPN basadas 

en rutas y las basadas en directivas hasta que se producen las consultas de rutas y de directivas: 

Consulta de rutas: para determinar la zona de destino, el módulo de rutas realiza una consulta de 

rutas para 10.2.2.5. Si no encuentra ninguna entrada para esa dirección específica, el módulo de 

rutas, resuelve una ruta a través de ethernet3, que está asociada a la zona Untrust. Determinando las 

interfaces de entrada y salida, el dispositivo NetScreen determina las zonas de origen y de destino y 

puede realizar una consulta de directivas. 

Consulta de directivas: el motor de directivas realiza una consulta de directivas en las zonas Trust y 

Untrust. La consulta compara la dirección de origen y la zona, la dirección de destino y la zona, y el 

servicio, y encuentra una directiva que hace referencia a un túnel VPN llamado vpn1. 

El dispositivo NetScreen reenvía el paquete a través de ethernet1 a su destino en 10.2.2.5. 

París (destinatario) 

La mayoría de las etapas del flujo de paquetes entrante en el extremo del destinatario son idénticas tanto 

para las configuraciones VPN basadas en directivas como para las basadas en rutas, excepto que el túnel 

no está asociado a una interfaz de túnel, sino a una zona de túnel. El dispositivo NetScreen averigua que el 

paquete ha llegado a través de vpn1, que está asociada a la zona de túnel Untrust-Tun, cuya zona 

portadora es la zona Untrust. Al contrario de lo que ocurre en las VPN basadas en rutas, el dispositivo 

NetScreen considera que ethernet3 es la interfaz de entrada del paquete desencriptado (y no tunnel.1). 

El flujo cambia cuando concluye la desencriptación del paquete. En este punto, las consultas de rutas y 

directivas difieren: 

Consulta de rutas: el módulo de rutas realiza una consulta de rutas para 10.2.2.5 y descubre que el 

acceso se ha producido a través de ethernet1, que está asociada a la zona Trust. Averiguando que la 

zona Untrust es la zona de origen (porque vpn1 está asociada a la zona de túnel Untrust-Tun, cuya 



zona portadora es la zona Untrust) y determinando la zona de destino a partir de la interfaz de salida 

(ethernet1 está asociada a la zona Trust), el dispositivo NetScreen puede buscar ahora una directiva 

desde la zona Untrust hasta la zona Trust que haga referencia a vpn1. 

Consulta de directivas: el motor de directivas comprueba su lista de directivas desde la zona Untrust 

hasta la zona Trust y encuentra una directiva que hace referencia a un túnel VPN llamado vpn1 y que 

permite el acceso a 10.2.2.5. 

Entonces, el dispositivo NetScreen reenvía el paquete a su destino. 


Capítulo 3 Directivas VPN Consejos para la configuración de un túnel 

CONSEJOS PARA LA CONFIGURACIÓN DE UN TÚNEL 

Esta sección contiene algunas indicaciones o consejos que conviene tener en cuenta a la hora de configurar 

túneles VPN. Cuando configure un túnel VPN IPSec, recuerde lo siguiente: 

NetScreen admite un máximo de cuatro propuestas para las negociaciones de fase 1 y un máximo de 

cuatro propuestas para las negociaciones de fase 2. Un interlocutor tiene que estar configurado para 

aceptar al menos una propuesta de fase 1 y una propuesta de fase 2 realizadas por el otro interlocutor. 

Para obtener información sobre las negociaciones IKE de fase 1 y fase 2, consulte “Negociación de túnel” 

en la página 11. 

Si desea utilizar certificados para la autenticación y hay más de un certificado local cargado en el 

dispositivo NetScreen, deberá especificar qué certificado desea que utilice cada configuración de túnel 

VPN. Para obtener más información sobre los certificados, consulte el Capítulo 2, “Criptografía de claves 

públicas” en la página 23. 

Para una VPN básica basada en directivas: 

– Utilice direcciones definidas por el usuario en la directiva, no la dirección predefinida “Any”. 

– Las direcciones y el servicio especificados en las directivas configuradas en los dos extremos de la 

VPN deben coincidir. 

– Utilice directivas simétricas para el tráfico VPN bidireccional. 

La ID de proxy para ambos interlocutores debe coincidir, es decir, el servicio especificado en la ID de proxy 

para ambos interlocutores debe ser idéntico, y la dirección IP local indicada para un interlocutor debe ser 

igual que la dirección IP remota indicada para el otro interlocutor 2 . 

– Para una configuración VPN basada en rutas, la ID de proxy es configurable por el usuario. 

– Para una configuración VPN basada en directivas, el dispositivo NetScreen (de forma 

predeterminada) deriva la ID de proxy a partir de la dirección de origen, la dirección de destino y el 

servicio especificados en la directiva que hace referencia al túnel VPN en la lista de directivas. 

También es posible definir una ID de proxy para una VPN basada en directivas que reemplace la ID 

de proxy derivada. 

2. La ID de proxy es una tupla de tres partes compuesta por dirección IP local-dirección IP remota-servicio. 



El método más simple para garantizar que las ID de proxy coinciden es utilizar 0.0.0.0/0 para la dirección 

local, 0.0.0.0/0 para la dirección 3 remota y “any” para el servicio. En lugar de utilizar la ID de proxy para el 

control de acceso, se utilizan directivas para controlar el tráfico procedente de y destinado a la VPN. Para 

obtener ejemplos de configuraciones VPN con ID de proxy configurables por el usuario, consulte los 

ejemplos de VPN basadas en rutas del Capítulo 4, “VPNs punto a punto”. 

3. Si la dirección remota es la dirección interna virtual de un cliente VPN de acceso telefónico, utilice 255.255.255.255/32 para la dirección IP remota/máscara 

de red en la ID de proxy. 



Siempre que coincidan los ajustes de ID de proxy de los interlocutores, es irrelevante si un interlocutor 

define una VPN basada en rutas y el otro, una VPN basada en directivas. Si el interlocutor 1 utiliza una 

configuración VPN basada en directivas, y el interlocutor utiliza una configuración VPN basada en rutas, el 

interlocutor 2 deberá definir una ID de proxy que coincida con la ID de proxy derivada de la directiva 4 del 

interlocutor 1. Si el interlocutor 1 realiza la traducción de direcciones de red de origen (NAT-src) mediante 

un conjunto de DIP, utilice la dirección y la máscara de red para el conjunto de DIP como dirección remota 

en la ID de proxy del interlocutor 2. Por ejemplo: 

Si el conjunto de DIP es: Utilice esto en la ID de proxy: 

1.1.1.8 – 1.1.1.8 1.1.1.8/32 

1.1.1.20 – 1.1.1.50 1.1.1.20/26 

1.1.1.100 – 1.1.1.200 1.1.1.100/25 

1.1.1.0 – 1.1.1.255 1.1.1.0/24 

Para obtener más información sobre las IDs de proxy cuando se utilizan con NAT-src y NAT-dst, consulte 

“Sitios VPN con direcciones superpuestas” en la página 203. 

Como las ID de proxy admiten o bien un servicio, o bien todos los servicios, el servicio de una ID de proxy 

derivada a partir de una VPN basada en directivas que haga referencia a un grupo de servicios se 

considera como “any”. 

Cuando ambos interlocutores tienen direcciones IP estáticas, pueden utilizar la ID IKE predeterminada, es 

decir, su dirección IP. Cuando un usuario de acceso telefónico o interlocutor tiene una dirección IP 

asignada de forma dinámica, dicho usuario o interlocutor debe utilizar otro tipo de ID IKE. Un nombre 

completo (FQDN) es una buena elección para un interlocutor dinámico, y un U-FQDN (dirección de correo 

electrónico) es una buena elección para un usuario de acceso telefónico. Se pueden utilizar los dos tipos de 

ID IKE FQDN y U-FQDN con claves previamente compartidas y certificados (si el FQDN o U-FQDN 

aparece en el campo SubjectAltName del certificado). Si utiliza certificados, el interlocutor dinámico o el 

usuario de acceso telefónico también podrá utilizar todo o parte del ASN1-DN como ID IKE. 

4. El interlocutor 1 también puede definir una ID de proxy que coincida con la ID de proxy del interlocutor 2. La ID de proxy definida por el usuario del interlocutor 

1 reemplaza la ID de proxy que el dispositivo NetScreen deriva de los componentes de la directiva. 


Capítulo 3 Directivas VPN Consideraciones sobre seguridad en VPNs basadas en rutas 

CONSIDERACIONES SOBRE SEGURIDAD EN VPNS BASADAS EN RUTAS 

Aunque los cambios de rutas no afectan a las VPNs basadas en directivas, las VPNs basadas en rutas son otra 

cuestión. El dispositivo NetScreen puede enrutar paquetes a través del túnel de una VPN basada en rutas 

combinando rutas estáticas con protocolos de enrutamiento dinámico. Mientras no ocurra ningún cambio de ruta, el 

dispositivo NetScreen encripta y reenvía constantemente los paquetes destinados a las interfaces de túnel 

asociadas a los túneles de la VPN basada en rutas. 

Sin embargo, cuando se utiliza el seguimiento de VPN con una configuración de túnel VPN basado en rutas, el 

estado del túnel puede cambiar de activo (up) a inactivo (down). Cuando esto ocurre, todas las entradas de la tabla 

de rutas que hacen referencia a la interfaz de túnel asociada a ese túnel cambian a inactivas. A continuación, si el 

dispositivo NetScreen examina las rutas para buscar tráfico que originalmente debería estar encriptado y enviarse a 

través de un túnel asociado a esa interfaz de túnel, no tendrá en cuenta la ruta relativa a la interfaz de túnel y 

buscará la siguiente ruta con mayor coincidencia. La ruta que encontrará podría ser la ruta predeterminada. Con 

esta ruta, el dispositivo NetScreen enviaría fuera el tráfico desencriptado (es decir, en texto puro o sin formato ) a 

través de una interfaz sin túnel a la WAN pública. 

Para evitar reencaminar el tráfico previsto originalmente para un túnel VPN a la WAN pública como texto puro, 

puede configurar el dispositivo NetScreen para que desvíe dicho tráfico a otro túnel, reencaminarlo a una línea 

arrendada o simplemente descartarlo, utilizando una de las siguientes soluciones: 

“Ruta nula” en la página 94 (descarta el tráfico cuando la ruta a la interfaz de túnel se desactiva) 

“Línea de acceso telefónico o arrendada” en la página 96 (reencamina el tráfico a otra ruta segura cuando 

la ruta a la interfaz de túnel se desactiva) 

“Interfaz de túnel ficticia” en la página 100 (descarta el tráfico cuando la ruta a la interfaz de túnel se 

desactiva) 

“Enrutador virtual para interfaces de túnel” en la página 101 (descarta el tráfico cuando la ruta a la interfaz 

de túnel se desactiva) 

“Reencaminar a otro túnel” en la página 101 (reencamina el tráfico a un túnel VPN alternativo cuando la 

ruta a la interfaz de túnel se desactiva) 



Ruta nula 

Si el estado de un túnel VPN cambia a “inactivo” (“down”), el dispositivo NetScreen cambia cualquier ruta que haga 

referencia a esa interfaz de túnel a “inactiva”. Si la ruta a la interfaz de túnel deja de estar disponible y la opción 

siguiente es la ruta predeterminada (por ejemplo), a continuación el dispositivo NetScreen utiliza la ruta 

predeterminada para reenviar el tráfico previsto originalmente para el túnel VPN. Para evitar enviar tráfico en texto 

sin formato hacia la WAN pública cuando se produce un cambio de ruta, puede utilizar una ruta nula. Una ruta nula 

apunta a la misma dirección de destino que la ruta a través de la interfaz de túnel, pero dirige el tráfico hacia la 

interfaz Null. La interfaz Null es una interfaz lógica que descarta el tráfico enviado hacia ella. Asigne a la ruta nula 

una métrica más elevada (más alejada de cero) que la ruta que utiliza la interfaz de túnel para que la ruta nula tenga 

una prioridad inferior. 

Nota: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces nulas. Sin embargo, puede utilizar una 

interfaz de túnel ficticia para lograr el mismo objetivo. Para obtener más información, consulte “Interfaz de túnel 

ficticia” en la página 100. 

Por ejemplo, si crea una ruta estática a través de tunnel.1 hacia una LAN remota con la dirección IP 10.2.2.0/24, su 

métrica recibirá automáticamente el valor predeterminado 1: 

set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1 

get route 

… 

Dest-Routes for (4 entries) 

ID IP-Prefix Interface Gateway P Pref Mtr Vsys 

* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root 

* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root 

* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root 

* 4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root 

En la tabla de enrutamiento anterior, un asterisco (*) indica que una ruta está activa, “S” indica una “ruta 

estática” y “C” indica una “ruta conectada”. 



En la tabla de enrutamiento anterior, el dispositivo NetScreen tiene dos rutas para alcanzar cualquier dirección en la 

subred 10.2.2.0/24. La primera opción es la ruta nº 4 porque coincide en mayor medida con esa dirección. La 

segunda opción es la ruta predeterminada (0.0.0.0/0). 

Si a continuación agrega otra ruta a 10.2.2.0/24 a través de la interfaz Null y le asigna un valor mayor que 1, esa 

ruta se convierte en la segunda opción de enrutamiento hacia cualquier dirección de la subred 10.2.2.0/24. Si la ruta 

hacia 10.2.2.0/24 a través de tunnel.1 se desactiva, el dispositivo NetScreen utiliza la ruta hacia la interfaz Null. El 

dispositivo NetScreen reenvía el tráfico destinado a 10.2.2.0/24 hacia esa interfaz y luego lo descarta. 

set vrouter trust-vr route 10.2.2.0/24 interface null metric 10 

get route 

… 

Dest-Routes for (5 entries) 


* 3 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root 

* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root 

* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root 

4 10.2.2.0/24 tun.1 0.0.0.0 S 20 1 Root 

* 5 10.2.2.0/24 null 0.0.0.0 S 20 10 Root 

En la tabla de enrutamiento anterior, la ruta hacia 10.2.2.0/24 a través de tunnel.1 está inactiva (indicado por la 

ausencia de un asterisco en la columna izquierda). Por lo tanto, el dispositivo NetScreen busca la siguiente ruta con 

la mayor coincidencia con la dirección de destino y encuentra la ruta nº 5. (La siguiente opción después de la ruta nº 

5 es la ruta predeterminada con la identificación nº 3). A continuación, el dispositivo NetScreen reenvía el tráfico 

para 10.2.2.0/24 a la interfaz Null, que descarta el tráfico. Consecuentemente, si la ruta que utiliza tunnel.1 se 

desactiva, el dispositivo NetScreen descarta el tráfico para 10.2.2.0/24 en lugar de utilizar la ruta nº 3 para 

reenviarlo hacia fuera a través de ethernet3 como texto puro al enrutador en 1.1.1.250. 



Línea de acceso telefónico o arrendada 

Si no desea que el tráfico dirigido a un interlocutor remoto se descarte cuando el túnel hacia ese interlocutor se 

desactive, puede agregar una ruta alternativa hacia ese interlocutor a través de una línea de acceso telefónico o 

arrendada. Esta ruta alternativa utilizará la misma dirección IP de destino que la ruta a través del túnel VPN, pero 

tendrá otra interfaz de salida y una métrica menos prioritaria. Si la ruta a través del túnel VPN llegase a 

desactivarse, el dispositivo NetScreen reencaminaría el tráfico dirigido al interlocutor remoto a través de la línea de 

acceso telefónico o arrendada. 

Cuando utilice una línea de acceso telefónico o arrendada como ruta de siguiente opción, todavía existe la 

posibilidad de que las rutas de primera y de segunda opción puedan desactivarse simultáneamente. En ese caso, el 

dispositivo NetScreen recurre a la tercera opción, que puede ser la ruta predeterminada. En previsión de tal 

situación, puede convertir la ruta de acceso telefónico o arrendada en la segunda opción y la ruta nula en la tercera 

opción (consulte “Ruta nula” en la página 94). La ilustración siguiente muestra cómo estas opciones de tratamiento 

de un fallo de enrutamiento pueden funcionar en tándem. 

Primera opción: Un túnel VPN 

hacia el interlocutor remoto. Dispositivo 

ethernet1 

10.1.1.1/24 

NetScreen 

local 

ethernet3 

Zona Trust 

1.1.1.1/24 

LAN 

local 

Segunda opción: Una ruta estática 2 

sobre una línea de acceso telefónico o 

arrendada hacia el interlocutor de la 

VPN. Su métrica es mayor que la de la 

ruta que utiliza el túnel VPN. Esta 3 

opción de enrutamiento reenvía el 

tráfico como texto puro a través de la 

línea protegida al interlocutor. 

Tercera opción: Una ruta nula con una 

métrica superior que la de la línea de 

acceso telefónico o arrendada. Esta 

opción descarta el tráfico. 

1 

tunnel.1 

ethernet4 

1.2.2.1/24 

Interfaz 

Null 

Descartar 

tráfico 

Internet 

Túnel VPN 

Línea de 

acceso 

telefónico o 

arrendada 

Zona Untrust 

Interlocutor de la VPN 

remoto 

LAN 

remota 



Ejemplo: Conmutación por error de la VPN hacia la línea arrendada o la ruta nula 

En este ejemplo, deseamos que el tráfico procedente de la sucursal detrás de NetScreen-A alcance la red 

corporativa situada detrás de NetScreen-B a través de una conexión VPN segura. Si el túnel falla, el tráfico deberá 

fluir a través de una línea arrendada hacia la oficina corporativa. Si tanto el túnel VPN como la línea arrendada 

fallan, NetScreen-A deberá descartar el tráfico en lugar de enviarlo fuera hacia Internet como texto puro. 

Creará tres rutas en NetScreen-A para alcanzar a 10.2.2.0/24 y asignará a cada una otra métrica: 

Ruta preferida – utilizar tunnel.1, asociado a vpn1 (métrica = 1) 

Ruta secundaria – utilizar ethernet4 y la puerta de enlace en 1.2.2.5 para utilizar la línea arrendada (métrica = 2) 

Ruta terciaria – utilice la interfaz nula para descartar tráfico (métrica = 10) 

Al crear la ruta preferida, utilizará la métrica predeterminada de una ruta estática, que es 1. Asignará una métrica de 

2 a la ruta secundaria; es decir, la ruta de respaldo a través de la línea arrendada (mostrada en rojo en el diagrama 

de debajo). La métrica es inferior que la de la ruta preferida a través del túnel VPN. El dispositivo NetScreen no 

utiliza la ruta secundaria a menos que falle la ruta preferida a través del túnel VPN. 

Finalmente, agregará una ruta NULA con una métrica de 10. Si la ruta preferida falla y a continuación también falla 

la ruta secundaria, el dispositivo NetScreen descartará todos los paquetes. Todas las zonas de seguridad se 

encuentran en el dominio de enrutamiento trust-vr. 

Nota: Ese ejemplo muestra solamente la configuración para cuatro rutas (tres para la conmutación por error) en 

NetScreen-A. No incluye la configuración de otros elementos necesarios, como interfaces y directivas. 

Preferencias de rutas: 

1. tunnel.1 -> vpn1 

2. ethernet4 -> línea arrendada 

3. null interface -> descartar 

LAN 

10.1.1.0/24 

3 

ethernet3 

1.1.1.1/24 


Internet 


Ruta NULA 

tunnel.1 

ethernet4 

1.2.2.1/24 

El tráfico fluye desde la sucursal 

a la oficina corporativa. 

Puerta de enlace 

1.1.1.250 

1 

vpn1 

ethernet3 

2.2.2.2/24 

2 

Línea arrendada (ruta de respaldo) 

Puerta de enlace: 1.2.2.5/24 

ethernet4 

2.3.3.2/24 

tunnel.1 

LAN 

10.2.2.0/24 

Nota: Las zonas de seguridad no se 

muestran en esta ilustración. 



WebUI (NetScreen-A) 

Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK : 

Network Address/Netmask: 0.0.0.0/0 

Gateway: (seleccione) 

Interface: ethernet3 

Gateway IP Address: 1.1.1.250 

Metric: 1 




Interface: tunnel.1 


Metric: 1 






Metric: 2 




Interface: Null 


Metric: 10 



CLI (NetScreen-A) 

set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 



metric 2 


save 

Puede verificar la presencia de las nuevas rutas ejecutando el comando get route . 

ns-> get route 

… 

Dest-Routes for (7 entries)) 


* 4 0.0.0.0/0 eth3 1.1.1.250 S 20 1 Root 

* 2 1.1.1.0/24 eth3 0.0.0.0 C 0 0 Root 

* 7 10.2.2.0/24 null 0.0.0.0 S 20 10 Root 

* 5 10.2.2.0/24 tunnel.1 0.0.0.0 S 20 1 Root 

* 6 10.2.2.0/24 eth4 1.2.2.5 S 20 2 Root 

* 1 10.1.1.0/24 eth1 0.0.0.0 C 0 0 Root 

* 3 1.2.2.0/24 eth4 0.0.0.0 C 0 0 Root 

La entrada de la tabla de rutas con la identificación 5 dirige el tráfico destinado a 10.2.2.0/24 hacia tunnel.1 y luego 

a través del túnel VPN. Es la ruta preferida para que el tráfico alcance la red 10.2.2.0. Si ese túnel falla, la siguiente 

mejor ruta es la correspondiente a la entrada 6 sobre una línea arrendada a través de una puerta de enlace en 

1.2.2.5. Si la conexión de la entrada de ruta 6 falla, la entrada de ruta 7 se convierte en la siguiente mejor ruta y el 

dispositivo NetScreen dirige el tráfico destinado a 10.2.2.0/24 hacia la interfaz nula, que lo descarta. 



Interfaz de túnel ficticia 

Cuando se produce un error, en lugar de conmutar el tráfico de un túnel VPN a una interfaz nula (donde se 

descarta), se puede utilizar una interfaz de túnel inoperativa para lograr el mismo objetivo. 

Nota: Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces nulas (consulte “Ruta nula” en la página 

94). Sin embargo, puede utilizar una interfaz de túnel ficticia para lograr el mismo objetivo. 

Para configurar una interfaz de túnel ficticia, haga lo siguiente: 

1. Cree una segunda interfaz de túnel, pero no la asocie a un túnel VPN. En su lugar, asóciela a una 

zona de túnel que se encuentre en el mismo dominio de enrutamiento virtual que la primera interfaz 

de túnel 5 . 

2. Defina una segunda ruta hacia el mismo destino utilizando esta segunda interfaz de túnel y asígnele 

una métrica más alta (más alejada de cero) que la de la ruta preferida. 

Cuando el estado de la interfaz de túnel en funcionamiento pase de activo a inactivo y la entrada de la 

tabla de rutas relativa a esa interfaz quede inactiva, las búsquedas de rutas encontrarán esta segunda 

ruta a la interfaz de túnel no operativa. El dispositivo NetScreen reenviará el tráfico a la segunda 

interfaz de túnel, y como no está asociada a un túnel VPN, el dispositivo descartará el tráfico. 

5. Si una interfaz de túnel está asociada a una zona de túnel, su estado siempre será activo. 



Enrutador virtual para interfaces de túnel 

Para evitar que, al desactivarse la ruta programada a través de un túnel VPN, el tráfico que originalmente debía 

atravesar el túnel, sea conmutado a causa del error hacia la ruta predeterminada, puede crear un dominio de 

enrutamiento virtual especial exclusivamente para el tráfico VPN. Para configurarlo, proceda de la siguiente 

manera: 

1. Cree un enrutador virtual independiente para utilizarlo con todas las rutas que apunten a interfaces de 

túnel y déle, por ejemplo, el nombre “VR-VPN”. 

2. Cree una zona de seguridad (llamada, por ejemplo, “zona VPN”) y asóciela a VR-VPN. 

3. Asocie todas las interfaces de túnel a la zona VPN e introduzca todas las direcciones de ubicaciones 

remotas a las que desee acceder a través de túneles VPN en esta zona. 

4. Configure rutas estáticas en todos los demás enrutadores virtuales a VR-VPN para el tráfico que 

desee que esté encriptado y se envíe a través de los túneles. En caso necesario, defina rutas 

estáticas para el tráfico desencriptado desde VR-VPN a otros enrutadores virtuales. Estas rutas son 

necesarias para permitir que el tráfico VPN entrante pase por el túnel si se inicia desde la ubicación 

remota. 

Si el estado de una interfaz de túnel pasa de activo a inactivo, el dispositivo NetScreen aún lo 

reenviará a VR-VPN, donde debido a que ahora el estado de la ruta a esa interfaz está inactivo y no 

hay otras rutas adecuadas, el dispositivo NetScreen descartará el tráfico. 

Reencaminar a otro túnel 

Puede configurar dos o más túneles VPN hacia el mismo interlocutor remoto. Si uno de los túneles se desactiva, el 

dispositivo NetScreen puede reencaminar el tráfico a través de otro túnel VPN. Para obtener información y ejemplos 

sobre la configuración de túneles VPN redundantes, consulte: 

“Interfaces Dual Untrust” en la página 10 -69 

“Ejemplo: Conmutación por error del túnel activo-a-respaldo” en la página 10 -79 

“Ejemplo: Túneles activos duales” en la página 10 -88 

“Ejemplo: Aplicación de pesos a la conmutación por error de túneles” en la página 10 -95. 




Capítulo 4 

VPNs punto a punto 

4 

En este capítulo se explica cómo configurar un túnel de red privada virtual (VPN) punto a punto entre dos 

dispositivos NetScreen. Aquí se examinan los túneles VPN basados en rutas y basados en directivas, se presentan 

los diversos elementos que hay que tener en cuenta al configurar un túnel y se ofrecen varios ejemplos. 

“Configuraciones VPN punto a punto” en la página 104 

– “Pasos de configuración de túneles punto a punto” en la página 105 

– “Ejemplo: VPN punto a punto basada en rutas, AutoKey IKE” en la página 111 

– “Ejemplo: VPN punto a punto basada en directivas, AutoKey IKE” en la página 126 

– “Ejemplo: VPN punto a punto basada en rutas, interlocutor dinámico” en la página 137 

– “Ejemplo: VPN punto a punto basada en directivas, interlocutor dinámico” en la página 152 

– “Ejemplo: VPN punto a punto basada en rutas, clave manual” en la página 166 

– “Ejemplo: VPN punto a punto basada en directivas, clave manual” en la página 177 

“Puertas de enlace IKE dinámicas con FQDN” en la página 186 

– “Ejemplo: Interlocutor AutoKey IKE con FQDN” en la página 188 

“Sitios VPN con direcciones superpuestas” en la página 203 

– “Ejemplo: Interfaz de túnel con NAT-Src y NAT-Dst” en la página 206 

“VPN en modo transparente” en la página 221 

– “Ejemplo: VPN AutoKey IKE basada en directivas en modo transparente” en la página 222 


Capítulo 4 VPNs punto a punto Configuraciones VPN punto a punto 

CONFIGURACIONES VPN PUNTO A PUNTO 

Existe un túnel VPN IPSec entre dos puertas de enlace, y cada puerta de enlace necesita una dirección IP. Si 

ambas puertas de enlace tienen direcciones IP estáticas, se pueden configurar los siguientes tipos de túneles: 

Túnel VPN punto a punto AutoKey IKE (con clave previamente compartida o certificados) 

Túnel VPN punto a punto con clave manual 

Si una puerta de enlace tiene una dirección estática, y la otra tiene una dirección asignada de forma dinámica, se 

puede configurar el siguiente tipo de túnel: 

Túnel VPN punto a punto de interlocutor dinámico AutoKey IKE (con clave previamente compartida o 

certificados) 

Tal como se utiliza aquí, una VPN punto a punto estática implica la existencia de un túnel IPSec para conectar dos 

puntos, cada uno de ellos con un dispositivo NetScreen operativo como puerta de enlace segura. La interfaz o 

subinterfaz física utilizada como interfaz de salida en ambos dispositivos tiene una dirección IP fija, y los hosts 

internos también tienen direcciones IP estáticas. Si el dispositivo NetScreen se encuentra en modo transparente, 

utiliza la dirección VLAN1 como dirección IP para la interfaz de salida. Con una VPN punto a punto estática, los 

hosts situados en cualquier extremo del túnel pueden iniciar la configuración del túnel VPN porque la dirección IP 

de la puerta de enlace remota se mantiene constante y, por tanto, accesible. 

Si la interfaz de salida de uno de los dispositivos NetScreen tiene una dirección IP asignada dinámicamente, dicho 

dispositivo se considera un interlocutor dinámico y la VPN se configura de forma distinta. Con una VPN punto a 

punto de interlocutor dinámico, sólo los hosts ubicados detrás del interlocutor dinámico pueden iniciar la 

configuración del túnel VPN, ya que sólo su puerta de enlace remota tiene una dirección IP fija y, por tanto, es 

accesible desde su puerta de enlace local. Sin embargo, una vez que se ha establecido un túnel entre un 

interlocutor dinámico y un interlocutor estático, los hosts ubicados detrás de cualquier puerta de enlace pueden 

iniciar tráfico VPN si los hosts de destino tienen direcciones IP fijas. 

Nota: Para obtener más información sobre las opciones de VPN disponibles, consulte el Capítulo 1, “IPSec”. Si 

desea obtener ayuda para elegir entre las distintas opciones, consulte el Capítulo 3, “Directivas VPN”. 



Pasos de configuración de túneles punto a punto 

La configuración de un túnel VPN punto a punto requiere la coordinación de la configuración del túnel con la 

configuración de otros ajustes (interfaces, direcciones, rutas y directivas). Los tres ejemplos de configuración VPN 

incluidos en esta sección se enmarcan en el siguiente contexto: una oficina de Tokio desea comunicarse de forma 

segura con una oficina de París a través de un túnel VPN IPSec. 

Zona Trust 

Eth1 

10.1.1.1/24 

NAT 

LAN 

10.1.1.0/24 

Oficina 

de Tokio 


de Tokio 

Los administradores de ambas oficinas configuran los siguientes ajustes: 

Interfaces: Zonas de seguridad y túnel 

Direcciones 

VPN (una de las opciones siguientes) 

– AutoKey IKE 

– Interlocutor dinámico 

– Clave manual 

Rutas 

Directivas 

Internet 

Túnel: vpn1 

enrutador externo, 2.2.2.250 

Eth3, 2.2.2.2/24 

tunnel.1, sin numerar 

Zona Untrust 

Zona Untrust 

Eth3, 1.1.1.1/24 




de París 

Oficina 

de París 

LAN 

10.2.2.0/24 

Eth1 

10.2.2.1/24 

NAT 

Zona Trust 



Zona Trust 

Eth1 

10.1.1.1/24 

NAT 

Oficina 

de Tokio 


Eth3, 1.1.1.1/24 

Zona Untrust 

1. Interfaces: Zonas de seguridad y túnel 

Internet 

Zona Untrust 

Eth3, 2.2.2.2/24 


Oficina 

de París 

Eth1 

10.2.2.1/24 

NAT 

Zona Trust 

El administrador de la oficina de Tokio configura las interfaces de zona de seguridad y túnel con los ajustes 

que aparecen en rojo en la ilustración anterior. Asimismo, el administrador de la oficina de París configura 

los ajustes que aparecen en azul. 

Ethernet3 va a ser la interfaz de salida para el tráfico VPN y la puerta de enlace remota para el tráfico VPN 

enviado desde el otro extremo del túnel. 

Ethernet1 se encuentra en modo NAT, por lo que cada administrador puede asignar direcciones IP a todos 

los hosts internos, incluso si el tráfico pasa de la zona Trust a la zona Untrust, el dispositivo NetScreen 

traduce la dirección IP de origen de los encabezados de los paquetes a la dirección de la interfaz de la zona 

Untrust, ethernet3 (1.1.1.1 para Tokio y 2.2.2.2 para París). 

Para una VPN basada en rutas, cada administrador asocia la interfaz de túnel tunnel.1 al túnel VPN vpn1. 

Definiendo una ruta al espacio de direcciones de la LAN de la oficina remota, el dispositivo NetScreen 

puede dirigir todo el tráfico asociado a dicha LAN a la interfaz tunnel.1, y por tanto, a través del túnel al que 

está asociada tunnel.1. 

Como no se requieren servicios NAT basados en directivas, una configuración VPN basada en rutas no 

requiere que tunnel.1 tenga una dirección IP/máscara de red, y una configuración VPN basada en 

directivas ni siquiera requiere una interfaz de túnel. 



Trust_LAN 

Trust, 10.1.1.0/24 

Tokio 

Untrust, 10.1.1.0/24 

Zona Trust 

Eth1 

10.1.1.1/24 

NAT 

LAN 

Internet 

LAN 

2. Direcciones 

Oficina 

de Tokio 


Eth3, 1.1.1.1/24 

Zona Untrust 

Zona Untrust 

Eth3, 2.2.2.2/24 


Oficina 

de París 

Eth1 

10.2.2.1/24 

NAT 

Zona Trust 

Los administradores definen direcciones para su posterior uso en directivas de entrada y salida. El 

administrador de la oficina de Tokio define las direcciones que aparecen en rojo en la ilustración anterior. 

Asimismo, el administrador de la oficina de París configura las direcciones que aparecen en azul. 

Para VPN basadas en directivas, el dispositivo NetScreen deriva las ID de proxy a partir de las directivas 1 . 

Como las ID de proxy utilizadas por los dispositivos NetScreen-A a ambos extremos del túnel VPN deben 

coincidir exactamente, no es posible utilizar la dirección predefinida “ANY”, cuya dirección IP es 0.0.0.0/0, 

en un extremo del túnel si se utiliza una dirección más específica en el otro extremo. Por ejemplo: 

Si la ID de proxy de Tokio es ... y la ID de proxy de París es ... las ID de proxy no 

From: 0.0.0.0/0 

To: 10.1.1.0/24 

coincidirán, y las 

To: 10.2.2.0/24 From: 10.2.2.0/24 

negociaciones IKE 

 

Service: ANY Service: ANY 

fracasarán. 

 

Para las VPN basadas en rutas, es posible utilizar “0.0.0.0/0–0.0.0.0/0–any” para definir las direcciones IP 

local y remota y el tipo de servicio para una ID de proxy. Y luego se pueden utilizar directivas más restrictivas 

para filtrar el tráfico VPN entrante y saliente por dirección de origen, dirección de destino y tipo de servicio. 

1. En ScreenOS 5.0.0, también es posible definir IDs de proxy para túneles VPN referenciados en configuraciones VPN basadas en directivas. 

París 

Untrust, 10.2.2.0/24 

Trust_LAN 

Trust, 10.2.2.0/24 



Trust_LAN 

Trust, 10.1.1.0/24 

Tokio 

Untrust, 10.1.1.0/24 

Zona Trust 

Oficina 

de Tokio 

Zona Untrust 

3. VPN 

Es posible configurar una de las tres VPNs siguientes: 

– AutoKey IKE 

Zona Untrust 

Eth1 

10.1.1.1/24 

NAT 


Eth3, 1.1.1.1/24 

LAN 

Internet 

Túnel: vpn1 

LAN 

Eth3, 2.2.2.2/24 


Oficina 

de París 

Eth1 

10.2.2.1/24 

NAT 

Zona Trust 

Trust_LAN 

Trust, 10.2.2.0/24 

París 

Untrust, 10.2.2.0/24 

El método AutoKey IKE utiliza una clave previamente compartida o un certificado para renovar (es 

decir, modificar) las claves de encriptación y autenticación automáticamente en intervalos definidos 

por el usuario (conocidos como periodos de vigencia de clave). En esencia, actualizar estas claves 

con frecuencia refuerza la seguridad, aunque unos periodos de vigencia de clave excesivamente 

breves pueden reducir el rendimiento general. 

– Interlocutor dinámico 

Un interlocutor dinámico es una puerta de enlace remota que tiene una dirección IP asignada de 

forma dinámica. Como es posible que la dirección IP del interlocutor remoto sea diferente cada vez 

que comienzan las negociaciones IKE, los hosts situados detrás del interlocutor deben iniciar el tráfico 

VPN. Asimismo (si se utiliza una clave previamente compartida para la autenticación), el interlocutor 

debe enviar una ID IKE durante el primer mensaje de las negociaciones de fase 1 en modo dinámico 

para identificarse. 

– Clave manual 

El método de clave manual requiere la configuración y actualización manual de las claves de encriptación 

y autenticación. Este método es una opción viable para un conjunto pequeño de túneles VPN. 



trust-vr 

Dst 10.2.2.0/24 

Utilizar tunnel.1 

Dst 10.2.2.0/24 

Zona Trust 

Oficina 

de Tokio 

Zona Untrust 

Utilizar NULL 

Métrica: 50 

Eth1 

Dst 0.0.0.0/0 10.1.1.1/24 

Utilizar puerta 

NAT 

de enlace eth3: 1.1.1.250 

Trust_LAN 

LAN 

Trust, 10.1.1.0/24 

Interfaz Null 


Eth3, 1.1.1.1/24 

Enrutador externo, 1.1.1.250 

Internet 

Túnel: vpn1 

LAN 

Tokio 

Untrust, 10.1.1.0/24 

Enrutador externo, 2.2.2.250 

Eth3, 2.2.2.2/24 

Interfaz Null 

Eth1 

10.2.2.1/24 


NAT 

Zona Untrust 

Oficina 

de París 

Zona Trust 

Trust_LAN 

Trust, 10.2.2.0/24 

París 

Untrust, 10.2.2.0/24 

trust-vr 

Dst 10.1.1.0/24 


Dst 10.1.1.0/24 

Utilizar NULL 

Métrica: 50 

Dst 0.0.0.0/0 


de enlace eth3: 

2.2.2.250 

4. Rutas 

Los administradores de cada extremo del túnel deben configurar al menos las rutas siguientes: 

– Una ruta para tráfico destinada a una dirección de la LAN remota a través de tunnel.1. 

– Una ruta predeterminada para el resto del tráfico, incluyendo el tráfico de túnel VPN externo, para el 

acceso a Internet a través de ethernet3 y el enrutador externo situado más allá (1.1.1.250 para la 

oficina de Tokio y 2.2.2.250 para la de París) 2 . El enrutador externo es la puerta de enlace 

predeterminada hacia la que el dispositivo NetScreen reenvía todo el tráfico para el que no disponga 

de una ruta específica en su tabla de enrutamiento. 

– Una ruta nula, de modo que si en algún momento el estado cambia de tunnel.1 a “inactivo” y cualquier 

ruta que haga referencia a tunnel.1 se desactiva, el dispositivo NetScreen no utilice la ruta 

predeterminada para reenviar el tráfico destinado a la LAN remota fuera de ethernet3 sin encriptar. 

Una ruta nula utiliza la LAN remota como dirección de destino, pero envía tráfico a la interfaz Null, una 

interfaz lógica que descarta todo el tráfico que recibe. Asigne a la ruta nula una métrica superior (más 

alejada de cero) que la ruta a la LAN remota que utiliza tunnel.1, haciendo la ruta nula menos 

preferente que la ruta que hace referencia a la interfaz de tunnel.1. 

2. Si el dispositivo NetScreen de la oficina de Tokio recibe su dirección IP externa de forma dinámica de su ISP (es decir, si desde el punto de vista de la oficina 

de París, el dispositivo NetScreen de la oficina de Tokio es un interlocutor dinámico), el ISP proporciona automáticamente al dispositivo NetScreen de Tokio 

su dirección IP de puerta de enlace predeterminada. 



trust-vr 

Dst 10.2.2.0/24 


Dst 0.0.0.0/0 



1.1.1.250 

Trust_LAN 

Trust, 10.1.1.0/24 

Tokio 

Untrust, 10.1.1.0/24 

Trust -> Untrust 

Trust_LAN -> París 

ANY, Permit 

Untrust -> Trust 

París-> Trust_LAN 

ANY, Permit 

Zona Trust 

Eth1 

10.1.1.1/24 

NAT 

Interfaz Null 


Eth3, 1.1.1.1/24 


Internet 

LAN LAN 

Túnel: vpn1 


Eth1 

Eth3, 2.2.2.2/24 


Interfaz Null 10.2.2.1/24 

NAT 

5. Directivas 

Oficina 

de Tokio 

Zona Untrust 

Zona Untrust 

Oficina 

de París 

Zona Trust 

trust-vr 

Dst 10.1.1.0/24 


Dst 0.0.0.0/0 



2.2.2.250 

Trust_LAN 

Trust, 10.2.2.0/24 

París 

Untrust, 10.2.2.0/24 

Trust -> Untrust 

Trust_LAN -> París 

ANY, Permit 

Untrust -> Trust 

París-> Trust_LAN 

ANY, Permit 

Los administradores de cada extremo del túnel definen directivas para permitir el tráfico entre las dos 

oficinas: 

– Una directiva que permita cualquier tipo de tráfico desde “Trust_LAN” en la zona Trust hasta “París” o 

“Tokio” en la zona Untrust 

– Una directiva que permita cualquier tipo de tráfico desde “París” o “Tokio” en la zona Untrust hasta 

“Trust_LAN” en la zona Trust 

Como la ruta preferente al punto remoto indica tunnel.1, que está asociada al túnel VPN vpn1, no es 

necesario que la directiva haga referencia al túnel VPN. 



Ejemplo: VPN punto a punto basada en rutas, AutoKey IKE 

En este ejemplo, un túnel AutoKey IKE que utiliza un secreto previamente compartido o un par de certificados (uno 

por cada extremo del túnel) proporciona la conexión segura entre las oficinas de Tokio y París. Para los niveles de 

seguridad de las fases 1 y 2, debe especificar una propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de 

clave previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas 

predefinido “Compatible” para la fase 2. Todas las zonas se encuentran en trust-vr. 

Topología de las zonas 

configuradas en el dispositivo 

NetScreen de Tokio 

Tokio París 

Tokio 

París 

Zona 

Trust 

Tokio 

Zona Trust 

eth1, 10.1.1.1/24 

Zona 

Untrust 

Interfaz de salida 

Zona Untrust 

eth3, 1.1.1.1/24 

Puerta de enlace 1.1.1.250 


Tunnel.1 

Internet 

Túnel VPN 


Zona Untrust 

eth3, 2.2.2.2/24 



Tunnel.1 



NetScreen de París 

Zona 

Untrust 

París 

Zona Trust 

eth1, 10.2.2.1/24 

La configuración de un túnel AutoKey IKE basado en rutas mediante un secreto previamente compartido o 

certificados implica los siguientes pasos: 

1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de seguridad y a la interfaz de túnel. 

2. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust, asociarla a la interfaz de túnel y 

configurar su ID de proxy. 


Zona 

Trust


3. Introducir las direcciones IP de los puntos finales local y remoto en las libretas de direcciones para las 

zonas Trust y Untrust. 

4. Introducir una ruta predeterminada al enrutador externo en trust-vr, una ruta al destino a través de la 

interfaz de túnel y otra ruta nula al destino. Asigne una métrica más alta (más alejada de cero) a la ruta nula 

para que se convierta en la siguiente opción de ruta al destino. A continuación, si el estado de la interfaz de 

túnel cambia a “inactivo” y la ruta que hace referencia a esa interfaz también se inactiva, el dispositivo 

NetScreen utiliza la ruta nula, que descarta todo tráfico enviado hacia él, en lugar de la ruta 

predeterminada, que reenvía tráfico no encriptado. 

5. Definir directivas para la circulación del tráfico VPN entre ambos sitios. 

En los ejemplos siguientes, la clave previamente compartida es h1p8A24nG5. Se asume que ambos participantes 

tienen certificados RSA y utilizan Entrust como autoridad de certificación (CA). (Para más información sobre cómo 

obtener y cargar certificados, consulte “Certificados y CRLs” en la página 29). 

WebUI (Tokio) 

1. Interfaces 

Network > Interfaces > Edit (para ethernet1): Introduzca los siguientes datos y haga clic en Apply : 

Zone Name: Trust 

Static IP: (seleccione esta opción si es posible) 

IP Address/Netmask: 10.1.1.1/24 

Seleccione los siguientes datos y haga clic en OK : 

Interface Mode: NAT 

Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK : 

Zone Name: Untrust 





Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga clic en OK : 

Tunnel Interface Name: tunnel.1 

Zone (VR): Untrust (trust-vr) 

Unnumbered: (seleccione) 

Interface: ethernet3 (trust-vr) 



3. VPN 

Address Name: Trust_LAN 



Zone: Trust 


Address Name: Paris_Office 



Zone: Untrust 

VPNs > AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK : 

Gateway Name: To_Paris 

Security Level: Custom 

Remote Gateway Type: 

Static IP Address: (seleccione), IP Address/Hostname: 2.2.2.2 




(o bien) 

Certificados 

Preshared Key: h1p8A24nG5 

Outgoing Interface: ethernet3 


Return para regresar a la página de configuración básica de puerta de 

enlace: 


Phase 1 Proposal (for Custom Security Level): pre-g2-3des-sha 

Mode (Initiator): Main (ID Protection) 




enlace: 


Phase 1 Proposal (for Custom Security Level): rsa-g2-3des-sha 

Preferred certificate (optional) 

Peer CA: Entrust 

Peer Type: X509-SIG 

VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK : 

VPN Name: Tokyo_Paris 

Security Level: Compatible 



Remote Gateway: 

Predefined: (seleccione), To_Paris 


Return para regresar a la página de configuración básica de AutoKey IKE: 


Bind to: Tunnel Interface, tunnel.1 

Proxy-ID: (seleccione) 

Local IP / Netmask: 10.1.1.0/24 

Remote IP / Netmask: 10.2.2.0/24 

Service: ANY 

4. Rutas 









Interface: Tunnel.1 





5. Directivas 





Metric: 10 

Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK : 

Name: To_Paris 

Source Address: Trust_LAN 

Destination Address: Paris_Office 

Service: ANY 

Action: Permit 

Position at Top: (seleccione) 

Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y haga clic en OK : 

Name: From_Paris 

Source Address: Paris_Office 

Destination Address: Trust_LAN 

Service: ANY 





WebUI (París) 

1. Interfaces 





















Zone: Trust 



3. VPN 


Address Name: Tokyo_Office 



Zone: Untrust 



(o bien) 

Gateway Name: To_Tokyo 








enlace: 






Certificados 




enlace: 







Name: Paris_Tokyo 



Predefined: (seleccione), To_Tokyo 








Service: ANY 



4. Rutas 

Network > Routing > Routing Entries > trust-vr New : Introduzca los siguientes datos y haga clic en OK : 















Metric: 10 



5. Directivas 


Name: To_Tokyo 

Source Address: 

Address Book Entry: (seleccione), Trust_LAN 

Destination Address: 

Address Book Entry: (seleccione), Tokyo_Office 

Service: ANY 



Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y haga clic en OK : 

Name: From_Tokyo 





Service: ANY 





CLI (Tokio) 

1. Interfaces 

set interface ethernet1 zone trust 

set interface ethernet1 ip 10.1.1.1/24 

set interface ethernet1 nat 

set interface ethernet3 zone untrust 


set interface tunnel.1 zone untrust 

set interface tunnel.1 ip unnumbered interface ethernet3 


set address trust Trust_LAN 10.1.1.0/24 

set address untrust Paris_Office 10.2.2.0/24 

3. VPN 


set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3 

preshare h1p8A24nG5 proposal pre-g2-3des-sha 

set vpn Tokyo_Paris gateway To_Paris sec-level compatible 

set vpn Tokyo_Paris bind interface tunnel.1 

set vpn Tokyo_Paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any 

(o bien) 



Certificado 

set ike gateway To_Paris address 2.2.2.2 main outgoing-interface ethernet3 

proposal rsa-g2-3des-sha 

set ike gateway To_Paris cert peer-ca 1 3 

set ike gateway To_Paris cert peer-cert-type x509-sig 

set vpn Tokyo_Paris gateway To_Paris sec-level compatible 



4. Rutas 




5. Directivas 

set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any 

permit 

set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN 

any permit 

save 

3. El número 1 es el número de ID de la CA. Para consultar los números ID de CAs, utilice el siguiente comando: get ike ca . 



CLI (París) 

1. Interfaces 










set address untrust Tokyo_Office 10.1.1.0/24 

3. VPN 


set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3 


set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible 

set vpn Paris_Tokyo bind interface tunnel.1 

set vpn Paris_Tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any 

(o bien) 



Certificado 

set ike gateway To_Tokyo address 1.1.1.1 main outgoing-interface ethernet3 


set ike gateway To_Tokyo cert peer-ca 1 

set ike gateway To_Tokyo cert peer-cert-type x509-sig 

set vpn Paris_Tokyo gateway To_Tokyo sec-level compatible 



4. Rutas 




5. Directivas 

set policy top name “To_Tokyo” from trust to untrust Trust_LAN Tokyo_Office any 

permit 

set policy top name “From_Tokyo” from untrust to trust Tokyo_Office Trust_LAN 

any permit 

save 



Ejemplo: VPN punto a punto basada en directivas, AutoKey IKE 

En este ejemplo, un túnel AutoKey IKE que utiliza un secreto previamente compartido o un par de certificados (uno 

por cada extremo del túnel) proporciona la conexión segura entre las oficinas de Tokio y París. Para los niveles de 

seguridad de las fases 1 y 2, debe especificar una propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de 

clave previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas 

predefinido “Compatible” para la fase 2. Todas las zonas se encuentran en trust-vr. 

Zona 

Trust 




Tokio París 

Tokio 

París 

Zona 

Untrust-Tun 

Zona 

Untrust 

Tokio 

Zona Trust 

eth1, 10.1.1.1/24 


Zona Untrust 

eth3, 1.1.1.1/24 


Internet 

Túnel VPN 


Zona Untrust 

eth3, 2.2.2.2/24 





Zona 

Untrust 

Zona 

Untrust-Tun 

París 

Zona Trust 

eth1, 10.2.2.1/24 

La configuración de un túnel AutoKey IKE utilizando AutoKey IKE mediante un secreto previamente compartido o 


1. Definir las direcciones IP de la interfaz de zona de seguridad. 

2. Realizar entradas en la libreta de direcciones para las entidades finales local y remota. 


Zona 

Trust


3. Definir la puerta de enlace remota y el modo de intercambio de claves, y especificar un secreto previamente 

compartido o un certificado. 

4. Crear la VPN Autokey IKE. 

5. Configurar una ruta predeterminada que conduzca al enrutador externo. 

6. Configurar directivas. 


tienen certificados RSA y utilizan Entrust como autoridad de certificación (CA). (Para más información sobre cómo 

obtener y cargar certificados, consulte “Certificados y CRLs” en la página 29). 

WebUI (Tokio) 

1. Interfaces 














3. VPN 





Zone: Trust 





Zone: Untrust 









> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en OK 

para regresar a la página de configuración básica de la puerta de enlace: 






(o bien) 

Certificados 


> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en OK 

para regresar a la página de configuración básica de la puerta de enlace: 








4. Ruta 



Remote Gateway: Predefined: (seleccione), To_Paris 








5. Directivas 


Name: To/From Paris 




Address Book Entry: (seleccione), Paris_Office 

Service: ANY 

Action: Tunnel 

Tunnel VPN: Tokyo_Paris 

Modify matching bidirectional VPN policy: (seleccione) 





1. Interfaces 
















Zone: Trust 





Zone: Untrust 



3. VPN 



(o bien) 

Certificados 









enlace: 







enlace: 










VPN Name: Paris_Tokyo 


Remote Gateway: Predefined: (seleccione), To_Tokyo 

4. Ruta 






5. Directivas 


Name: To/From Tokyo 





Service: ANY 


Tunnel VPN: Paris_Tokyo 





CLI (Tokio) 

1. Interfaces 








set address untrust paris_office 10.2.2.0/24 

3. VPN 


set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3 


set vpn tokyo_paris gateway to_paris sec-level compatible 

(o bien) 

Certificados 

set ike gateway to_paris address 2.2.2.2 main outgoing-interface ethernet3 


set ike gateway to_paris cert peer-ca 1 4 

set ike gateway to_paris cert peer-cert-type x509-sig 





4. Ruta 


5. Directivas 

set policy top name “To/From Paris” from trust to untrust Trust_LAN 

paris_office any tunnel vpn tokyo_paris 

set policy top name “To/From Paris” from untrust to trust paris_office 

Trust_LAN any tunnel vpn tokyo_paris 

save 

CLI (París) 

1. Interfaces 








set address untrust tokyo_office 10.1.1.0/24 

3. VPN 


set ike gateway to_tokyo address 1.1.1.1 main outgoing-interface ethernet3 


set vpn paris_tokyo gateway to_tokyo sec-level compatible 

(o bien) 



Certificados 



set ike gateway to_tokyo cert peer-ca 1 

set ike gateway to_tokyo cert peer-cert-type x509-sig 

set vpn paris_tokyo gateway to_tokyo tunnel proposal nopfs-esp-3des-sha 

4. Ruta 


5. Directivas 

set policy top name “To/From Tokyo” from trust to untrust Trust_LAN 

tokyo_office any tunnel vpn paris_tokyo 

set policy top name “To/From Tokyo” from untrust to trust tokyo_office 

Trust_LAN any tunnel vpn paris_tokyo 

save 



Ejemplo: VPN punto a punto basada en rutas, interlocutor dinámico 

En este ejemplo, un túnel VPN AutoKey IKE que utiliza una clave previamente compartida o un par de certificados 

(uno por cada extremo del túnel) proporciona la conexión segura entre los dispositivos NetScreen para proteger las 

oficinas de Tokio y París. La interfaz de zona Untrust para el dispositivo NetScreen en la oficina de París tiene una 

dirección IP estática. El ISP de la oficina de Tokio asigna la dirección IP para la interfaz de zona Untrust de forma 

dinámica a través del protocolo DHCP. Como sólo el dispositivo NetScreen de París tiene una dirección fija para su 

zona Untrust, el tráfico VPN se debe originar desde los hosts de la oficina de Tokio. Una vez establecido un túnel, el 

tráfico que atraviese el túnel se puede originar desde cualquier extremo de dicho túnel. Todas las zonas de túnel y 

de seguridad se encuentran en trust-vr. 

Zona 

Trust 




Tokio 

Zona Trust 

eth1, 10.1.1.1/24 

Zona 

Untrust 


Zona Untrust 

eth3 y puerta de enlace 

asignadas dinámicamente 

por el ISP 


Tunnel.1 

Internet 

Túnel VPN 

Servidor DHCP 

2.1.1.5 


Zona Untrust 

eth3, 2.2.2.2/24 


2.2.2.250 


Tunnel.1 




Tokio París 

Tokio 

París 

Zona 

Untrust 

París 

Zona Trust 

eth1, 10.2.2.1/24 


Zona 

Trust


La clave previamente compartida es h1p8A24nG5. Se parte de la base de que ambos participantes ya tienen 

certificados RSA emitidos por la autoridad de certificación (CA) Verisign, y la dirección de correo electrónico 

pmason@abc.com aparece en el certificado local de NetScreen A. (Para obtener más información sobre la adquisición 

y la carga de certificados, consulte “Certificados y CRLs” en la página 29). Para los niveles de seguridad de las fases 1 

y 2, debe especificar una propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de clave previamente 

compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas “Compatible” para la fase 2. 

Indique tres rutas en los dispositivos NetScreen en cada extremo del túnel VPN: 

Una ruta predeterminada que conduzca al enrutador externo en trust-vr. 

Una ruta al destino a través de la interfaz de túnel 

Una ruta nula al destino. Asigne una métrica más alta (más alejada de cero) a la ruta nula para que se 

convierta en la siguiente opción de ruta al destino. A continuación, si el estado de la interfaz de túnel 

cambia a “inactivo” y la ruta que hace referencia a esa interfaz también se inactiva, el dispositivo NetScreen 

utiliza la ruta nula, que descarta todo tráfico enviado hacia él, en lugar de la ruta predeterminada, que 

reenvía tráfico no encriptado. 

Finalmente, configure directivas para permitir tráfico bidireccional entre los dos sitios. 

WebUI (Tokio) 

1. Interfaces 









Introduzca los siguientes datos y haga clic en OK : 

Obtain IP using DHCP: (seleccione) 5 

5. La dirección IP del servidor DHCP no se puede especificar mediante WebUI; no obstante, sí se puede especificar mediante comandos CLI. 





3. VPN 









Zone: Trust 





Zone: Untrust 









(o bien) 

Certificados 


Local ID: pmason@abc.com 


6. El U-FQDN “pmason@abc.com” debe aparecer en el campo SubjectAltName del certificado. 



enlace: 



Mode (Initiator): Aggressive 

Local ID: pmason@abc.com 6 




enlace: 




Preferred Certificate (optional): 

Peer CA: Verisign 











Bind to: Tunnel Interface: (seleccione), tunnel.1 




Service: ANY 

4. Rutas 





Gateway IP Address: 0.0.0.0 7 






7. El ISP proporciona la dirección IP de la puerta de enlace de forma dinámica a través del protocolo DHCP. 




5. Directivas 





Metric: 10 






Service: Any 








Service: Any 






1. Interfaces 










IP Address: 2.2.2.2/24 











Zone: Trust 



3. VPN 





Zone: Untrust 



(o bien) 




Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com 





enlace: 






Certificados 




enlace: 








VPN Name: Paris_Tokyo 






Bind to: Tunnel Interface: (seleccione), tunnel.1 




Service: ANY 



4. Rutas 





Gateway IP Address: (seleccione), 2.2.2.250 











Metric: 10 



5. Directivas 






Service: Any 








Service: Any 





CLI (Tokio) 

1. Interfaces 





set interface ethernet3 dhcp client 

set interface ethernet3 dhcp client settings server 1.1.1.5 






3. VPN 


set ike gateway To_Paris address 2.2.2.2 aggressive local-id pmason@abc.com 

outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha 

set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible 



(o bien) 



Certificados 

set ike gateway To_Paris address 2.2.2.2 aggressive local-id pmason@abc.com 8 

outgoing-interface ethernet3 proposal rsa-g2-3des-sha 

set ike gateway To_Paris cert peer-ca 1 9 

set ike gateway To_Paris cert peer-cert-type x509-sig 

set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible 



4. Rutas 

set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 10 



5. Directivas 

set policy top from trust to untrust Trust_LAN Paris_Office any permit 

set policy top from untrust to trust Paris_Office Trust_LAN any permit 

save 



10. El ISP proporciona la dirección IP de la puerta de enlace de forma dinámica a través del protocolo DHCP, por lo tanto, no se puede especificar aquí. 



CLI (París) 

1. Interfaces 











3. VPN 


set ike gateway To_Tokyo dynamic pmason@abc.com aggressive outgoing-interface 

ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha 

set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible 



(o bien) 



Certificados 

set ike gateway To_Tokyo dynamic pmason@abc.com aggressive outgoing-interface 

ethernet3 proposal rsa-g2-3des-sha 

set ike gateway To_Tokyo cert peer-ca 1 11 

set ike gateway To_Tokyo cert peer-cert-type x509-sig 

set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible 



4. Rutas 




5. Directivas 

set policy top from trust to untrust Trust_LAN Tokyo_Office any permit 

set policy top from untrust to trust Tokyo_Office Trust_LAN any permit 

save 




Ejemplo: VPN punto a punto basada en directivas, interlocutor dinámico 

En este ejemplo, un túnel VPN conecta de forma segura a los usuarios de la zona Trust situados detrás de 

NetScreen A con el servidor de correo de la zona corporativa DMZ protegida por NetScreen B. La interfaz de zona 

Untrust para NetScreen B tiene una dirección IP estática. El ISP de NetScreen A asigna la dirección IP para su 

interfaz de zona Untrust de forma dinámica a través del protocolo DHCP. Puesto que sólo NetScreen B tiene una 

dirección fija para su zona Untrust, el tráfico VPN se debe originar desde los hosts situados detrás de NetScreen A. 

Una vez que NetScreen A haya establecido el túnel, el tráfico que atraviese el túnel se puede originar desde 

cualquiera de sus extremos. Todas las zonas se encuentran en el dominio de enrutamiento trust-vr. 

Zona 

Trust 

Petición 

SMTP o POP3 


configuradas en NetScreen-A 

en la sucursal 

A B 

A 

B 

Zona 

Untrust 

Sucursal 

Zona Trust 

eth1, 10.1.1.1/24 


Zona Untrust 

eth3 y puerta de enlace 

asignadas dinámicamente 

por el ISP 

Internet 


Zona Untrust 

eth3, 2.2.2.2/24 


2.2.2.250 


Túnel VPN 

Servidor DHCP 

2.1.1.5 


Nota: antes de realizar una conexión SMTP o POP3 con el servidor 

de correo corporativo, Phil debe iniciar primero una conexión HTTP, 

FTP o Telnet para que NetScreen A pueda autenticarle. 


configuradas en NetScreen-B 

en la sede central 

Zona 

Untrust 

Oficina corporativa 

Zona DMZ 

eth2, 3.3.3.3/24 

Petición 

IDENT 

Servidor de 

correo 

3.3.3.5 


Zona 

DMZ


En este ejemplo, el usuario de autenticación local Phil (nombre de usuario: pmason; contraseña: Nd4syst4) desea 

recoger su correo electrónico del servidor del sitio corporativo. Cuando intenta hacerlo, pasa por dos 

autenticaciones: primero, el dispositivo NetScreen A le autentica de forma local antes de permitir que el tráfico 

originado por él atraviese el túnel 12 ; después, el programa de servidor de correo le autentica de nuevo enviando una 

petición IDENT a través del túnel. 

Nota: El servidor de correo puede enviar la petición IDENT a través del túnel sólo si los administradores de los 

dispositivos NetScreen A y B agregan un servicio personalizado para ello (TCP, puerto 113) y configuran directivas 

que permitan el tráfico a través del túnel hacia la subred 10.10.10.0/24. 

La clave previamente compartida es h1p8A24nG5. Se parte de la base de que ambos participantes ya tienen 

certificados RSA emitidos por la autoridad de certificación (CA) Verisign, y la dirección de correo electrónico 

pmason@abc.com aparece en el certificado local de NetScreen A. (Para obtener más información sobre la 

adquisición y la carga de certificados, consulte “Certificados y CRLs” en la página 29). Para los niveles de seguridad 

de las fases 1 y 2, debe especificar la propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de clave 

previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas predefinido 

“Compatible” para la fase 2. 


1. Interfaces 







12. Como Phil es un usuario de autenticación, antes de que pueda realizar una petición SMTP o POP3, debe iniciar primero una conexión HTTP, FTP o Telnet 

para que NetScreen A pueda responder con un mensaje de petición de inicio de sesión/usuario de cortafuegos para autenticarle. Una vez que NetScreen 

A le haya autenticado, tendrá permiso para establecer contacto con el servidor de correo corporativo a través del túnel VPN. 




2. Usuario 


Obtain IP using DHCP: (seleccione) 13 

Objects > Users > Local > New: Introduzca los siguientes datos y haga clic en OK : 


User Name: pmason 

Status: Enable 

Authentication User: (seleccione) 

User Password: Nd4syst4 

Confirm Password: Nd4syst4 


Address Name: Trusted network 



Zone: Trust 


Address Name: Mail Server 



Zone: Untrust 

13. La dirección IP del servidor DHCP no se puede especificar mediante WebUI; no obstante, sí se puede especificar mediante comandos CLI. 



4. Servicios 

Objects > Services > Custom > New: Introduzca los siguientes datos y haga clic en OK : 

Service Name: Ident 

Service Timeout: 

Use protocol default: (seleccione) 

Transport Protocol: TCP (seleccione) 

Source Port: Low 0, High 65535 

Destination Port: Low 113, High 113 

Objects > Services > Group > New: Introduzca los siguientes datos, mueva los siguientes servicios y, 

finalmente, haga clic en OK : 

Group Name: Remote_Mail 

Group Members AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK : 

Gateway Name: To_Mail 








(o bien) 

Certificados 





enlace: 








enlace: 










6. Ruta 

Name: branch_corp 


Remote Gateway Tunnel: To_Mail 


7. Directivas 







Address Book Entry: (seleccione), Trusted network 


Address Book Entry: (seleccione), Mail Server 

Service: Remote_Mail 


VPN Tunnel: branch_corp 






WebUI (NetScreen-B) 


Return para regresar a la página de configuración básica de directiva: 

Authentication: (seleccione) 

Auth Server: Local 

User: (seleccione), Local Auth User - pmason 

1. Interfaces 


Zone Name: DMZ 












Zona: DMZ 




3. Servicios 

Address Name: branch office 



Zone: Untrust 











Group Members


4. VPN 


Gateway Name: To_branch 



Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com 






enlace: 




(o bien) 

Certificados 




enlace: 










5. Ruta 

VPN Name: corp_branch 



Predefined: (seleccione), To_branch 


6. Directivas 





Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK : 




Address Book Entry: (seleccione), branch office 



VPN Tunnel: corp_branch 






1. Interfaces 





set interface ethernet3 dhcp client 

set interface ethernet3 dhcp client settings server 1.1.1.5 

2. Usuario 

set user pmason password Nd4syst4 


set address trust “trusted network” 10.1.1.0/24 

set address untrust “mail server” 3.3.3.5/32 

4. Servicios 

set service ident protocol tcp src-port 0-65535 dst-port 113-113 

set group service remote_mail 

set group service remote_mail add http 

set group service remote_mail add ftp 

set group service remote_mail add telnet 

set group service remote_mail add ident 

set group service remote_mail add mail 

set group service remote_mail add pop3 



5. VPN 


set ike gateway to_mail address 2.2.2.2 aggressive local-id pmason@abc.com 

outgoing-interface ethernet3 preshare h1p8A24nG5 proposal pre-g2-3des-sha 

set vpn branch_corp gateway to_mail sec-level compatible 

(o bien) 

Certificados 

set ike gateway to_mail address 2.2.2.2 aggressive local-id pmason@abc.com 15 

outgoing-interface ethernet3 proposal rsa-g2-3des-sha 

set ike gateway to_mail cert peer-ca 1 16 

set ike gateway to_mail cert peer-cert-type x509-sig 

set vpn branch_corp gateway to_mail sec-level compatible 

6. Ruta 

set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 17 

7. Directivas 

set policy top from trust to untrust “trusted network” “mail server” 

remote_mail tunnel vpn branch_corp auth server Local user pmason 

set policy top from untrust to trust “mail server” “trusted network” 

remote_mail tunnel vpn branch_corp 

save 






CLI (NetScreen-B) 

1. Interfaces 

set interface ethernet2 zone dmz 





set address dmz “mail server” 3.3.3.5/32 

set address untrust “branch office” 10.1.1.0/24 

3. Servicios 






4. VPN 


set ike gateway to_branch dynamic pmason@abc.com aggressive outgoing-interface 


set vpn corp_branch gateway to_branch tunnel sec-level compatible 

(o bien) 



Certificados 

set ike gateway to_branch dynamic pmason@abc.com aggressive outgoing-interface 


set ike gateway to_branch cert peer-ca 1 18 

set ike gateway to_branch cert peer-cert-type x509-sig 

set vpn corp_branch gateway to_branch sec-level compatible 

5. Ruta 


6. Directivas 

set policy top from dmz to untrust “mail server” “branch office” remote_mail 

tunnel vpn corp_branch 

set policy top from untrust to dmz “branch office” “mail server” remote_mail 

tunnel vpn corp_branch 

save 




Ejemplo: VPN punto a punto basada en rutas, clave manual 

En este ejemplo, un túnel con clave manual ofrece un canal de comunicación segura entre las oficinas de Tokio y 

París. Las zonas Trust de cada punto se encuentran en modo NAT. Las direcciones son las siguientes: 

Tokio: 

- Interfaz de zona Trust (ethernet1): 10.1.1.1/24 

- Interfaz de zona Untrust (ethernet3): 1.1.1.1/24 

Las zonas de seguridad Trust y Untrust se encuentran en el dominio de enrutamiento trust-vr. La interfaz de zona 

Untrust (ethernet3) actúa como interfaz de salida para el túnel VPN. 

Zona 

Trust 




Tokio 

Zona Trust 

eth1, 10.1.1.1/24 

Zona 

Untrust 


Zona Untrust 

eth3, 1.1.1.1/24 


1.1.1.250 


París: 

Internet 

Túnel VPN 

- Interfaz de zona Trust (ethernet1): 10.2.2.1/24 

- Interfaz de zona Untrust (ethernet3): 2.2.2.2/24 

Tokio París 

Tokio 

París 


tunnel.1 


Zona Untrust 

eth3, 2.2.2.2/24 


2.2.2.250 


tunnel.1 




Zona 

Untrust 

París 

Zona Trust 

eth1, 10.2.2.1/24 

Zona 

Trust


Para configurar el túnel, lleve a cabo los siguientes pasos en los dispositivos NetScreen a ambos extremos del 

túnel: 


2. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust y asociarla a la interfaz de túnel. 










WebUI (Tokio) 

1. Interfaces 























Zone: Trust 





Zone: Untrust 

3. VPN 

VPNs > Manual Key > New: Introduzca los siguientes datos y haga clic en OK : 

VPN Tunnel Name: Tokyo_Paris 

Gateway IP: 2.2.2.2 

Security Index: 3020 (Local), 3030 (Remote) 


ESP-CBC: (seleccione) 

Encryption Algorithm: 3DES-CBC 



Generate Key by Password: asdlk24234 

Authentication Algorithm: SHA-1 

Generate Key by Password: PNas134a 


Return para regresar a la página de configuración básica del túnel de 

clave manual: 


4. Rutas 
















Metric: 10 



5. Directivas 


Name: To Paris 





Service: ANY 




Name: From Paris 





Service: ANY 






1. Interfaces 





















Zone: Trust 



3. VPN 





Zone: Untrust 


VPN Tunnel Name: Paris_Tokyo 











clave manual: 




4. Rutas 
















Metric: 10 



5. Directivas 


Name: To Tokyo 





Service: ANY 




Name: From Tokyo 





Service: ANY 





CLI (Tokio) 

1. Interfaces 











3. VPN 

set vpn Tokyo_Paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface 

ethernet3 esp 3des password asdlk24234 auth sha-1 password PNas134a 


4. Rutas 




5. Directivas 

set policy top name “To Paris” from trust to untrust Trust_LAN Paris_Office any 

permit 

set policy top name “From Paris” from untrust to trust Paris_Office Trust_LAN 

any permit 

save 



CLI (París) 

1. Interfaces 











3. VPN 

set vpn Paris_Tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface 



4. Rutas 




5. Directivas 

set policy top name “To Tokyo” from trust to untrust Trust_LAN Tokyo_Office any 

permit 

set policy top name “From Tokyo” from untrust to trust Tokyo_Office Trust_LAN 

any permit 

save 



Ejemplo: VPN punto a punto basada en directivas, clave manual 

En este ejemplo, un túnel con clave manual ofrece un canal de comunicación segura entre las oficinas de Tokio y 

París utilizando ESP con encriptación 3DES y autenticación SHA-1. Las zonas Trust de cada punto se encuentran 

en modo NAT. Las direcciones son las siguientes: 

Tokio: 

- Interfaz Trust (ethernet1): 10.1.1.1/24 

- Interfaz Untrust (ethernet3): 1.1.1.1/24 

Las zonas de seguridad Trust y Untrust y la zona de túnel Untrust-Tun se encuentran en el dominio de enrutamiento 

trust-vr. La interfaz de zona Untrust (ethernet3) actúa como interfaz de salida para el túnel VPN. 

Zona 

Trust 




Zona 

Untrust 

Tokio 

Zona Trust 

eth1, 10.1.1.1/24 


Zona Untrust 

eth3, 1.1.1.1/24 


1.1.1.250 


París: 

Internet 

Túnel VPN 

- Interfaz Trust (ethernet1): 10.2.2.1/24 

- Interfaz Untrust (ethernet3): 2.2.2.2/24 

Tokio París 

Tokio 

París 

Zona 

Untrust-Tun 


Zona Untrust 

eth3, 2.2.2.2/24 


2.2.2.250 




Zona 

Untrust 

Zona 

Untrust-Tun 

París 

Zona Trust 

eth1, 10.2.2.1/24 

Zona 

Trust


Para configurar el túnel, lleve a cabo los cinco pasos siguientes en los dispositivos NetScreen-A ambos extremos 

del túnel: 

1. Asignar direcciones IP a las interfaces físicas asociadas a las zonas de seguridad. 

2. Configurar el túnel VPN y designar su interfaz de salida en la zona Untrust. 



4. Introducir una ruta predeterminada que conduzca al enrutador externo. 

5. Configurar directivas para que el tráfico VPN circule de forma bidireccional por el túnel. 

WebUI (Tokio) 

1. Interfaces 

















3. VPN 


Zone: Trust 





Zone: Untrust 


VPN Tunnel Name: Tokyo_Paris 











clave manual: 

Bind to: Tunnel Zone, Untrust-Tun 



4. Ruta 


5. Directivas 






Name: To/From Paris 





Service: ANY 


Tunnel VPN: Tokyo_Paris 






1. Interfaces 
















Zone: Trust 





Zone: Untrust 



3. VPN 


VPN Tunnel Name: Paris_Tokyo 


Security Index (HEX Number): 3030 (Local), 3020 (Remote) 









clave manual: 


4. Ruta 








5. Directivas 


Name: To/From Tokyo 





Service: ANY 


Tunnel VPN: Paris_Tokyo 





CLI (Tokio) 

1. Interfaces 









3. VPN 

set vpn tokyo_paris manual 3020 3030 gateway 2.2.2.2 outgoing-interface 


set vpn tokyo_paris bind zone untrust-tun 

4. Ruta 


5. Directivas 

set policy top name “To/From Paris” from trust to untrust Trust_LAN 

paris_office any tunnel vpn tokyo_paris 

set policy top name “To/From Paris” from untrust to trust paris_office 

Trust_LAN any tunnel vpn tokyo_paris 

save 



CLI (París) 

1. Interfaces 









3. VPN 

set vpn paris_tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface 


set vpn paris_tokyo bind zone untrust-tun 

4. Ruta 


5. Directivas 

set policy top name “To/From Tokyo” from trust to untrust Trust_LAN 

tokyo_office any tunnel vpn paris_tokyo 

set policy top name “To/From Tokyo” from untrust to trust tokyo_office 

Trust_LAN any tunnel vpn paris_tokyo 

save 


Capítulo 4 VPNs punto a punto Puertas de enlace IKE dinámicas con FQDN 

PUERTAS DE ENLACE IKE DINÁMICAS CON FQDN 

Para un interlocutor IKE que obtenga su dirección IP de forma dinámica, es posible especificar su nombre de 

dominio completo (FQDN) en la configuración local para la puerta de enlace remota. Por ejemplo, un proveedor de 

servicios de Internet (ISP) podría asignar direcciones IP a sus clientes a través del protocolo DHCP. El ISP toma 

direcciones de un amplio conjunto de direcciones y las asigna cuando los clientes se conectan en línea. Aunque el 

interlocutor IKE posee un FQDN que no varía, tiene una dirección IP que cambia de forma impredecible. El 

interlocutor IKE dispone de tres métodos para mantener una asignación DNS (“Domain Name Service”) entre su 

FQDN y su dirección IP asignada de forma dinámica (un proceso denominado DNS dinámico). 

Si el interlocutor IKE remoto es un dispositivo NetScreen, el administrador puede avisar manualmente al 

servidor DNS para que actualice su asignación entre FQDN y dirección IP cada vez que el dispositivo 

NetScreen reciba una dirección IP nueva de su ISP. 

Si el interlocutor IKE remoto es cualquier otro tipo de dispositivo terminal VPN en el que se esté ejecutando 

software DNS dinámico, dicho software puede notificar al servidor DNS sus cambios de dirección para que 

el servidor actualice su tabla de asignación entre FQDN y dirección IP. 

Si el interlocutor IKE remoto es un dispositivo NetScreen o cualquier otro tipo de dispositivo terminal VPN, 

un host ubicado detrás de él puede ejecutar un programa de actualización automática entre FQDN y 

dirección IP que avise al servidor DNS de los cambios de dirección. 

Dispositivo NetScreen local 

1.1.1.1 

1. El servidor DHCP toma la dirección 2.2.2.28 de su 

conjunto de direcciones IP y la asigna al interlocutor 

IKE. 

2. El interlocutor IKE notifica al servidor DNS la nueva 

dirección para que éste pueda actualizar su tabla de 

asignación entre FQDN y dirección IP. 

Internet 

Túnel VPN 

Conjunto de 

direcciones IP 

2.2.2.10 – 

2.2.7.9 

Interlocutor IKE 

2.2.2.28 = www.ns.com 

Servidor DHCP 

Servidor DNS 

Sin que sea necesario conocer la dirección IP actual de un interlocutor IKE remoto, es posible configurar un túnel 

VPN AutoKey IKE que conecte con dicho interlocutor utilizando su FQDN en lugar de una dirección IP. 


1 

www.ns.com 

2


Alias 

También es posible utilizar un alias para el FQDN del interlocutor IKE remoto si el servidor DNS al que consulta el 

dispositivo NetScreen local devuelve sólo una dirección IP. Si el servidor DNS devuelve varias direcciones IP, el 

dispositivo local utilizará la primera que reciba. Como no existe ninguna garantía sobre el orden de aparición de las 

direcciones en la respuesta del servidor DNS, es posible que el dispositivo NetScreen local utilice la dirección IP 

incorrecta y, por tanto, las negociaciones IKE podrían fracasar. 

1 

2 

3a 

3b 

Dispositivo NetScreen local El dispositivo NetScreen local desea 

establecer un túnel VPN IKE con su 

interlocutor remoto. Utiliza 

www.jnpr.net como dirección de puerta 

de enlace remota. 

Interlocutor IKE remoto 


El dispositivo NetScreen 

utiliza esta dirección IP. 

Consulta DNS: www.jnpr.net = IP ? 

Respuesta DNS: 

www.jnpr.net = 1.1.1.202 



Servidor DNS 


Si el interlocutor IKE remoto se encuentra en 

1.1.1.202, las negociaciones IKE se desarrollan 

con éxito. 



Si el interlocutor 

IKE remoto se 

encuentra en 

1.1.1.114 

ó 

1.1.1.20, las 

negociaciones 

IKE fracasan. 




Ejemplo: Interlocutor AutoKey IKE con FQDN 

En este ejemplo, un túnel VPN AutoKey IKE que utiliza un secreto previamente compartido o un par de certificados 

(uno por cada extremo del túnel) proporciona una conexión segura entre dos oficinas de Tokio y París. La oficina de 

París tiene una dirección IP asignada de forma dinámica, por lo que la oficina de Tokio utiliza el FQDN del 

interlocutor remoto (www.nspar.com) como dirección de la puerta de enlace remota en su configuración de 

túnel VPN. 

La siguiente configuración corresponde a un túnel VPN basado en rutas. Para los niveles de seguridad de las fases 

1 y 2, debe especificar una propuesta de fase 1 (ya sea pre-g2-3des-sha para el método de clave previamente 

compartida o rsa-g2-3des-sha para certificados) y seleccionar el conjunto de propuestas predefinido “Compatible” 

para la fase 2. Todas las zonas se encuentran en trust-vr. 




Tokio 

Zona 

Trust 

Tokio 

Zona Trust 

eth1, 10.1.1.1/24 

Zona 

Untrust 

París 


Zona Untrust 

eth3, 1.1.1.1/24 


1.1.1.250 

Internet 

Túnel VPN 

Interfaz de túnel: tunnel.1 

Puerta de enlace remota: www.nspar.com 




Tokio París 

Zona 

Untrust 


Zona Untrust 

eth3, IP y puerta de 

enlace a través del 

protocolo DHCP 

www.nspar.com 

Interfaz de túnel: tunnel.1 

Puerta de enlace remota: 1.1.1.1 

París 

Zona Trust 

eth1, 10.2.2.1/24 


Zona 

Trust


La configuración de un túnel AutoKey IKE basado en rutas mediante un secreto previamente compartido o 



2. Definir la puerta de enlace remota y el modo de intercambio de claves, y especificar un secreto previamente 

compartido o un certificado. 

3. Configurar el túnel VPN, designar su interfaz de salida en la zona Untrust, asociarla a la interfaz de túnel y 

configurar su ID de proxy. 









6. Definir directivas para la circulación del tráfico entre ambos sitios. 


tienen certificados RSA y utilizan Entrust como autoridad de certificación (CA). (Para obtener información sobre la 

adquisición y la carga de certificados, consulte el Volumen 4 de NetScreen conceptos y ejemplos: manual de 

referencia, VPNs ). 

WebUI (Tokio) 

1. Interfaces 












IP Address/Netmask: 1.1.1.1 











Zone: Trust 





Zone: Untrust 



3. VPN 



(o bien) 

Certificados 




Static IP Address: (seleccione), IP Address/Hostname: www.nspar.com 





enlace: 







enlace: 




















Service: ANY 

4. Rutas 















5. Directivas 





Metric: 10 


Name: To_Paris 


Destination Address: Paris_Office 

Service: ANY 





Policies > Policy (From: Untrust, To: Trust) > New Policy: Introduzca los siguientes datos y haga clic en OK : 


Name: From_Paris 

Source Address: Paris_Office 


Service: ANY 


1. Nombre de host y nombre de dominio 


Network > DNS: Introduzca los siguientes datos y haga clic en Apply : 

2. Interfaces 

Host Name: www 

Domain Name: nspar.com 









Obtain IP using DHCP: (seleccione) 





4. VPN 









Zone: Trust 





Zone: Untrust 









(o bien) 

Certificados 





enlace: 







enlace: 








VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK: 

Name: Paris_Tokyo 











Service: ANY 

5. Rutas 

Network > Routing > Routing Entries > trust-vr New: Introduzca los siguientes datos y haga clic en OK: 













6. Directivas 





Metric: 10 


Name: To Tokyo 


Destination Address: Tokyo_Office 

Service: ANY 




Name: From Tokyo 

Source Address: Tokyo_Office 


Service: ANY 





CLI (Tokio) 

1. Interfaces 











3. VPN 


set ike gateway to_paris address www.nspar.com main outgoing-interface 



set vpn tokyo_paris bind interface tunnel.1 

set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any 

(o bien) 



Certificado 

set ike gateway to_paris address www.nspar.com main outgoing-interface 


set ike gateway to_paris cert peer-ca 1 20 

set ike gateway to_paris cert peer-cert-type x509-sig 


set vpn tokyo_paris bind interface tunnel.1 

set vpn tokyo_paris proxy-id local-ip 10.1.1.0/24 remote-ip 10.2.2.0/24 any 

4. Rutas 




5. Directivas 

set policy top name “To Paris” from trust to untrust Trust_LAN paris_office any 

permit 

set policy top name “From Paris” from untrust to trust paris_office Trust_LAN 

any permit 

save 




CLI (París) 

1. Nombre de host y nombre de dominio 

set hostname www 

set domain nspar.com 

2. Interfaces 





set interface ethernet3 ip dhcp-client enable 






4. VPN 





set vpn paris_tokyo bind interface tunnel.1 

set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any 

(o bien) 



Certificado 



set ike gateway to_tokyo cert peer-ca 1 

set ike gateway to_tokyo cert peer-cert-type x509-sig 


set vpn paris_tokyo bind interface tunnel.1 

set vpn paris_tokyo proxy-id local-ip 10.2.2.0/24 remote-ip 10.1.1.0/24 any 

5. Rutas 




6. Directivas 

set policy top name “To Tokyo” from trust to untrust Trust_LAN tokyo_office any 

permit 

set policy top name “From Tokyo” from untrust to trust tokyo_office Trust_LAN 

any permit 

save 


Capítulo 4 VPNs punto a punto Sitios VPN con direcciones superpuestas 

SITIOS VPN CON DIRECCIONES SUPERPUESTAS 

Como el rango de direcciones IP privadas es relativamente pequeño, es bastante probable que las direcciones de 

las redes protegidas de dos interlocutores VPN se superpongan 21 . Para el tráfico VPN bidireccional entre dos 

entidades finales con direcciones superpuestas, los dispositivos NetScreen de los dos extremos del túnel deben 

aplicar una traducción de direcciones de red de origen y de destino (NAT-src y NAT-dst) al tráfico VPN que circule 

entre ellos. 

Para NAT-src, las interfaces a ambos extremos del túnel deben poseer direcciones IP en subredes únicas entre sí, 

con un conjunto de direcciones IP dinámicas (DIP) en cada una de dichas subredes 22 . Las directivas que regulan el 

tráfico VPN saliente pueden aplicar NAT-src mediante direcciones de conjunto DIP para traducir las direcciones de 

origen originales y convertirlas en direcciones de un espacio de direcciones neutro. 

Hay dos posibilidades para aplicar NAT-dst al tráfico VPN entrante: 

NAT-dst basada en directivas: una directiva puede aplicar NAT-dst para traducir el tráfico VPN entrante y 

convertirlo en una dirección que se encuentre en la misma subred que la interfaz de túnel (pero no en el 

mismo rango que el conjunto de DIP local utilizado para el tráfico VPN saliente) o en una dirección de otra 

subred sobre la que el dispositivo NetScreen tenga una entrada en su tabla de rutas. (Para obtener 

información sobre el enrutamiento a la hora de configurar NAT-dst, consulte “Enrutamiento para NAT-Dst” 

en la página 7 -42). 

Dirección IP asignada (MIP): una directiva puede hacer referencia a una MIP como dirección de destino. La 

MIP utiliza una dirección que se encuentra en la misma subred que la interfaz de túnel (pero no en el mismo 

rango que el conjunto de DIP local utilizado para el tráfico VPN de salida). (Para obtener información sobre 

las MIP, consulte “Direcciones IP asignadas” en la página 7 -92). 

El tráfico VPN entre dos puntos con direcciones superpuestas requiere la traducción de direcciones en ambos 

sentidos. Como la dirección de origen del tráfico saliente no puede ser la misma que la dirección de destino del 

tráfico entrante (la dirección NAT-dst o MIP no puede estar en el conjunto de DIP), las direcciones de las que se 

incluyen referencias en las directivas de entrada y salida no pueden ser simétricas. 

21. Un espacio de direcciones superpuesto se produce cuando los rangos de direcciones IP de dos redes coinciden parcial o totalmente. 

22. El rango de direcciones en un conjunto de DIP debe estar en la misma subred que la interfaz de túnel, pero no es necesario que el conjunto incluya la 

dirección IP de la interfaz o cualquier otra dirección MIP o VIP que pueda encontrarse en dicha subred. Para las interfaces de zona de seguridad, es posible 

definir una dirección IP extendida y un conjunto de DIP auxiliar en una subred distinta de la de la dirección IP de la interfaz. Para obtener más información, 

consulte “Interfaz extendida y DIP” en la página 2 -283. 



Si desea que el dispositivo NetScreen realice una traducción de direcciones de origen y destino para el tráfico VPN 

bidireccional que atraviese el mismo túnel, dispone de las dos opciones siguientes: 

Puede definir una ID de proxy 23 para una configuración VPN basada en directivas. Si hace referencia de 

forma específica a un túnel VPN en una directiva, el dispositivo NetScreen deriva una ID de proxy a partir 

de los componentes de la directiva que hagan referencia a dicho túnel. El dispositivo NetScreen deriva la ID 

de proxy al crear la directiva por primera vez, y a partir de entonces, cada vez que el dispositivo se reinicia. 

Sin embargo, si define manualmente una ID de proxy para un túnel VPN al que se haga referencia en una 

directiva, el dispositivo NetScreen aplicará la ID de proxy definida por el usuario y no la ID de proxy 

derivada a partir de la directiva. 

Puede utilizar una configuración de túnel VPN basada en rutas, que debe tener una ID de proxy definida 

por el usuario. Con una configuración de túnel VPN basada en rutas, no se hace referencia de forma 

específica a un túnel VPN en una directiva. En su lugar, la directiva controla (permite o deniega) el acceso 

a un destino en particular. La ruta que conduce a dicho destino apunta a una interfaz de túnel que, a su vez, 

está asociada a un túnel VPN. Como el túnel VPN no está asociado directamente a ninguna directiva a 

partir de la que se pueda derivar una ID de proxy de la dirección de origen, la dirección de destino y el 

servicio, habrá que definir una ID de proxy de forma manual. (Recuerde que una configuración VPN basada 

en rutas también permite crear múltiples directivas que hagan uso de un único túnel VPN; es decir, una SA 

de fase 2 sencilla). 

Examine las direcciones de la siguiente ilustración en la que se ejemplifica un túnel VPN entre dos puntos con 

espacios de direcciones superpuestas: 

Espacio de 

direcciones 

internas 

10.1.1.0/24 

NetScreen-A Túnel VPN 


tunnel.1 

10.10.1.1/24 

10.10.1.2 – 10.10.1.2 DIP 

10.10.1.5 (a 10.1.1.5) MIP 

Direcciones en directivas 

tunnel.2 

10.20.2.1/24 

MIP 10.20.2.5 (a 10.1.1.5) 

DIP 10.20.2.2 – 10.20.2.2 

Espacio de 

direcciones 

internas 

10.1.1.0/24 

23. Una ID de proxy es un tipo de acuerdo entre interlocutores IKE para permitir el tráfico a través de un túnel si el tráfico cumple una tupla especificada de 

dirección local, dirección remota y servicio. 



Si los dispositivos NetScreen de la ilustración anterior derivan las ID de proxy a partir de las directivas, como ocurre 

en las configuraciones VPN basadas en directivas, las directivas de entrada y salida dan como resultado las 

siguientes IDs de proxy: 

NetScreen-A NetScreen-B 

Local Remota Servicio Local Remota Servicio 

Salida 10.10.1.2/32 10.20.2.5/32 Any Entrada 10.20.2.5/32 10.10.1.2/32 Any 

Entrada 10.10.1.5/32 10.20.2.2/32 Any Salida 10.20.2.2/32 10.10.1.5/32 Any 

Como puede ver, existen dos IDs de proxy: una para el tráfico VPN entrante y otra para el saliente. Cuando el 

dispositivo NetScreen A envía tráfico por primera vez desde 10.10.1.2/32 hasta 10.20.2.5/32, los dos interlocutores 

realizan negociaciones IKE y generan asociaciones de seguridad (SAs) de fase 1 y fase 2. La SA de fase 2 da 

como resultado la ID de proxy de salida anterior para el dispositivo NetScreen A y la ID de proxy de entrada para el 

dispositivo NetScreen B. 

Si NetScreen B envía tráfico a NetScreen A, la consulta de directivas para el tráfico de 10.20.2.2/32 a 10.10.1.5/32 

indica que no hay ninguna SA de fase 2 activa para tal ID de proxy. Por lo tanto, los dos interlocutores utilizan la SA 

de fase 1 existente (asumiendo que su periodo de vigencia no haya caducado) para negociar una SA de fase 2 

distinta. Las IDs de proxy resultantes se indican en la tabla anterior como ID de proxy de entrada para NetScreen A 

e ID de proxy de salida para NetScreen B. Hay dos SAs de fase 2 (dos túneles VPN) porque las direcciones son 

asimétricas y requieren IDs de proxy distintas. 

Para crear un solo túnel para tráfico VPN bidireccional, puede definir las siguientes IDs de proxy con direcciones 

cuyo alcance incluya las direcciones de origen y destino traducidas en cada extremo del túnel: 


Local Remota Servicio Local Remota Servicio 

10.10.1.0/24 10.20.2.0/24 Any 10.20.2.0/24 10.10.1.0/24 Any 

o bien 

0.0.0.0/0 0.0.0.0/0 Any 0.0.0.0/0 0.0.0.0/0 Any 

Las IDs de proxy anteriores comprenden las direcciones que aparecen tanto en el tráfico VPN entrante como en el 

saliente que circule entre ambos puntos. La dirección 10.10.1.0/24 incluye el conjunto de DIP 10.10.1.2 – 10.10.1.2 



y la dirección MIP 10.10.1.5. Asimismo, la dirección 10.20.2.0/24 incluye el conjunto de DIP 10.20.2.2 – 10.20.2.2 y 

la dirección MIP 10.20.2.5 24 . Las IDs de proxy anteriores son simétricas, es decir, la dirección local de NetScreen A 

es la dirección remota de NetScreen B y viceversa. Si NetScreen A envía tráfico a NetScreen B, la SA de fase 2 y la 

ID de proxy también se aplican al tráfico enviado de NetScreen B a NetScreen A. Por lo tanto, sólo se requiere una 

única SA de fase 2 (es decir, un único túnel VPN) para el tráfico bidireccional entre dos puntos. 

Para crear un túnel VPN para el tráfico bidireccional entre dos puntos con espacios de direcciones superpuestas 

cuando las direcciones para NAT-src y NAT-dst configuradas en el mismo dispositivo se encuentran en subredes 

distintas, la ID de proxy para el túnel debe ser (IP local) 0.0.0.0/0 – (IP remota) 0.0.0.0/0 – tipo de servicio . Si desea 

utilizar direcciones más restrictivas en la ID de proxy, las direcciones para NAT-src y NAT-dst deberán encontrarse 

en la misma subred. 

Ejemplo: Interfaz de túnel con NAT-Src y NAT-Dst 

En este ejemplo vamos a configurar un túnel VPN entre el dispositivo “NetScreen A” situado en la sede central y el 

dispositivo “NetScreen B” situado en la sucursal de la empresa. El espacio de direcciones para las entidades finales 

VPN se superpone; ambas utilizan direcciones en la subred 10.1.1.0/24. Para superar este conflicto, utilizaremos 

NAT-src para traducir la dirección de origen del tráfico VPN saliente y NAT-dst para traducir la dirección de destino 

del tráfico VPN entrante. Las directivas permiten que todas las direcciones de la LAN corporativa accedan a un 

servidor FTP de la sucursal, y que todas las direcciones de la sucursal accedan a un servidor FTP de la sede 

central. 

Nota: Para obtener más información sobre la traducción de direcciones de red de origen y destino (NAT-src y 

NAT-dst), consulte el Volumen 7, “Traducción de direcciones”. 

Las configuraciones de ambos extremos del túnel utilizan los siguientes parámetros: AutoKey IKE, clave 

previamente compartida (“netscreen1”) y el nivel de seguridad predefinido como “Compatible” para propuestas de 

fase 1 y fase 2. (Para ver los detalles sobre estas propuestas, consulte “Negociación de túnel” en la página 11). 

La interfaz de salida de NetScreen-A en la sede central es ethernet3, que tiene la dirección IP 1.1.1.1/24 y está 

asociada a la zona Untrust. NetScreen-B, en la sucursal, utiliza esta dirección como puerta de enlace IKE remota. 

24. La dirección 0.0.0.0/0 incluye todas las direcciones IP y, por tanto, las direcciones del conjunto de DIP y MIP. 



La interfaz de salida de NetScreen-B en la sucursal es ethernet3, que tiene la dirección IP 2.2.2.2/24 y está 

asociada a la zona Untrust. NetScreen-A, en la sede central, utiliza esta dirección como puerta de enlace IKE 

remota. 

La interfaz de zona Trust de ambos dispositivos NetScreen es ethernet1 y tiene la dirección IP 10.1.1.1/24. Todas 

las zonas de ambos dispositivos NetScreen se encuentran en el dominio de enrutamiento trust-vr. 

Zona 

Trust 


configuradas en NetScreen-A 

en la sede central 

Servidor A 

10.1.1.5 

Red A 

10.1.1.0/24 

Red A 

Zona 

Untrust 

Tunnel.1 10.10.1.1/24 Tunnel.1 10.20.1.1/24 

DIP 5 10.10.1.2 – 10.10.1.2 

NAT-Dst 10.10.1.5 –> 10.1.1.5 


configuradas en NetScreen B 

en la sucursal 

A B A 

B 

DIP 6 10.20.1.2 – 10.20.1.2 

NAT-Dst 10.20.1.5 –> 10.1.1.5 

Red B 

10.1.1.0/24 

Los usuarios de la red A pueden acceder al servidor B. Los usuarios de la red B 

pueden acceder al servidor A. 

Todo el tráfico circula a través del túnel VPN entre los dos puntos. 


Túnel VPN 

Servidor A “vpn1” 

Red B 

Servidor B 

10.1.1.5 

Servidor B 


Zona 

Untrust 



2.2.2.250 

2.2.2.250 

Internet 


Zona 

Trust



1. Interfaces 

2. DIP 














Fixed IP: (seleccione) 

IP Address / Netmask: 10.10.1.1/24 

Network > Interfaces > Edit (para tunnel.1) > DIP > New: Introduzca los siguientes datos y haga clic en OK : 

ID: 5 

IP Address Range: (seleccione), 10.10.1.2 ~ 10.10.1.2 

Port Translation: (seleccione) 

In the same subnet as the interface IP or its secondary IPs: (seleccione) 





Address Name: corp 



Zone: Trust 


Address Name: virtualA 



Zone: Trust 


Address Name: branch1 



Zone: Untrust 


Address Name: serverB 



Zone: Untrust 



4. VPN 


VPN Name: vpn1 


Remote Gateway: Create a Simple Gateway: (seleccione) 

Gateway Name: branch1 

Type: Static IP: (seleccione), Address/Hostname: 2.2.2.2 

Preshared Key: netscreen1 


Outgoing Interface: ethernet3 25 







Service: ANY 

25. La interfaz de salida no necesita estar en la misma zona a la que está asociada la interfaz del túnel, aunque en este caso se encuentran en la misma zona. 



5. Rutas 
















Metric: 10 

6. Directivas 



Address Book Entry: (seleccione), corp 


Address Book Entry: (seleccione), serverB 

Service: FTP 







NAT: 

Source Translation: (seleccione) 

DIP On: 5 (10.10.1.2–10.10.1.2)/X-late 



Address Book Entry: (seleccione), branch1 


Address Book Entry: (seleccione), virtualA 

Service: FTP 





NAT: 

Destination Translation: (seleccione) 

Translate to IP: (seleccione), 10.1.1.5 

Map to Port: (anule la selección) 




1. Interfaces 

2. DIP 

















ID: 6 








Address Name: branch1 



Zone: Trust 


Address Name: virtualB 



Zone: Trust 





Zone: Untrust 


Address Name: serverA 



Zone: Untrust 



4. VPN 





Gateway Name: corp 




Outgoing Interface: ethernet3 26 







Service: ANY 




5. Rutas 
















Metric: 10 

6. Directivas 





Address Book Entry: (seleccione), serverA 

Service: FTP 







NAT: 


DIP on: 6 (10.20.1.2–10.20.1.2)/X-late 





Address Book Entry: (seleccione), virtualB 

Service: FTP 





NAT: 


Translate to IP: 10.1.1.5 

Map to Port: (anule la selección) 




1. Interfaces 







set interface tunnel.1 ip 10.10.1.1/24 

2. DIP 

set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2 


set address trust corp 10.1.1.0/24 

set address trust virtualA 10.10.1.5/32 

set address untrust branch1 10.20.1.2/32 

set address untrust serverB 10.20.1.5/32 

4. VPN 

set ike gateway branch1 address 2.2.2.2 outgoing-interface ethernet3 27 preshare 

netscreen1 sec-level compatible 

set vpn vpn1 gateway branch1 sec-level compatible 

set vpn vpn1 bind interface tunnel.1 

set vpn vpn1 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 any 




5. Rutas 




6. Directivas 

set policy top from trust to untrust corp serverB ftp nat src dip-id 5 permit 

set policy top from untrust to trust branch1 virtualA ftp nat dst ip 10.1.1.5 

permit 

save 


1. Interfaces 








2. DIP 



set address trust branch1 10.1.1.0/24 

set address trust virtualB 10.20.1.5/32 

set address untrust corp 10.10.1.2/32 

set address untrust serverA 10.10.1.5/32 



4. VPN 

set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 28 preshare 


set vpn vpn1 gateway corp sec-level compatible 



5. Rutas 




6. Directivas 

set policy top from trust to untrust branch1 serverA ftp nat src dip-id 6 

permit 

set policy top from untrust to trust corp virtualB ftp nat dst ip 10.1.1.5 

permit 

save 



Capítulo 4 VPNs punto a punto VPN en modo transparente 

VPN EN MODO TRANSPARENTE 

Si las interfaces de los dispositivos NetScreen se encuentran en modo transparente (es decir, si no tienen 

direcciones IP y operan en la capa 2 del modelo OSI 29 ), puede utilizar la dirección IP VLAN1 como punto terminal de 

la VPN. En lugar de una interfaz de salida, tal como se utiliza cuando las interfaces se encuentran en modo NAT o 

de rutas (es decir, cuando tienen direcciones IP y operan en la capa 3), un túnel VPN hace referencia a una zona de 

salida. De forma predeterminada, un túnel utiliza la zona V1-Untrust como su zona de salida. Si tiene múltiples 

interfaces asociadas a la misma zona de salida, el túnel VPN puede utilizar cualquiera de ellas. 

Nota: En el momento de esta publicación, un dispositivo NetScreen cuyas interfaces se encuentren en modo 

transparente sólo admite VPN basadas en directivas. Para obtener más información sobre el modo transparente, 

consulte “Modo transparente” en la página 2 -108. 

29. El modelo OSI es un modelo estándar en el sector de redes de una arquitectura de protocolos de red. El modelo OSI está compuesto por siete capas; la 

capa 2 es la capa de enlace de datos, y la capa 3 es la capa de red. 



Ejemplo: VPN AutoKey IKE basada en directivas en modo transparente 

En este ejemplo, vamos a configurar un túnel VPN AutoKey IKE basado en directivas entre dos dispositivos 

NetScreen cuyas interfaces operan en modo transparente. 

Nota: No es necesario que las interfaces de ambos dispositivos NetScreen se encuentren en modo transparente. 

Las interfaces del dispositivo situado a un extremo del túnel pueden encontrarse en modo transparente, y las del 

otro dispositivo pueden encontrarse en modo NAT o de rutas. 

Los elementos clave para la configuración de los dispositivos NetScreen situados a ambos extremos del túnel son 

éstos: 

Elementos de 

configuración 

Zona V1-Trust Interface: ethernet1, 0.0.0.0/0 

(habilite la administración para el 

administrador local) 


Interface: ethernet1, 0.0.0.0/0 

(habilite la administración para el 

administrador local) 

Zona V1-Untrust Interface: ethernet3, 0.0.0.0/0 Interface: ethernet3, 0.0.0.0/0 

Interfaz VLAN1 IP Address: 1.1.1.1/24 

Manage IP: 1.1.1.2 * 

Direcciones local_lan: 1.1.1.0/24 in V1-Trust 

peer_lan: 2.2.2.0/24 en V1-Untrust 

Puerta de enlace IKE gw1, 2.2.2.2, preshared key h1p8A24nG5, 

security: compatible 

IP Address: 2.2.2.2/24 

Manage IP: 2.2.2.3 

local_lan: 2.2.2.0/24 in V1-Trust 

peer_lan: 1.1.1.0/24 in V1-Untrust 

gw1, 1.1.1.1, preshared key h1p8A24nG5, 

security: compatible 

Túnel VPN security: compatible security: compatible 

Directivas local_lan -> peer_lan, any service, vpn1 

peer_lan -> local_lan, any service, vpn1 

local_lan -> peer_lan, any service, vpn1 

peer_lan -> local_lan, any service, vpn1 

Enrutador externo IP Address: 1.1.1.250 IP Address: 2.2.2.250 

Ruta 0.0.0.0/0, use VLAN1 interface 

to gateway 1.1.1.250 

0.0.0.0/0, use VLAN1 interface 

to gateway 2.2.2.250 

* 

Puede separar el tráfico VPN del administrativo utilizando la dirección IP de administración para recibir el tráfico administrativo y la dirección 

VLAN1 para terminar el tráfico VPN. 



La configuración de un túnel AutoKey IKE basado en directivas para un dispositivo NetScreen cuyas interfaces se 

encuentren en modo transparente implica los siguientes pasos: 

1. Eliminar las direcciones IP de las interfaces físicas y asociarlas a las zonas de seguridad de capa 2. 

2. Asignar una dirección IP y una dirección IP de administración a la interfaz VLAN1. 


zonas V1-Trust y V1-Untrust. 

4. Configurar el túnel VPN y designar su zona de salida como zona V1-Untrust. 

5. Introducir una ruta predeterminada que conduzca al enrutador externo en trust-vr. 



1. Interfaces 

Nota: El desplazamiento de la dirección IP VLAN1 a una subred distinta hace que el dispositivo NetScreen 

elimine todas las rutas relacionadas con la interfaz VLAN1 anterior. A la hora de configurar un dispositivo 

NetScreen a través de la WebUI, la estación de trabajo debe acceder a la primera dirección VLAN1 y 

encontrarse en la misma subred que la dirección nueva. Después de cambiar la dirección VLAN1, deberá 

modificar la dirección IP de su estación de trabajo para que se encuentre en la misma subred que la nueva 

dirección VLAN1. Es posible que también tenga que reubicar su estación de trabajo en una subred 

físicamente adyacente al dispositivo NetScreen. 

Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes datos y haga clic en OK : 



Management Services: WebUI, Telnet, Ping 30 

30. Se deben habilitar las opciones de administración para WebUI, Telnet y Ping tanto en la zona V1-Trust como en la interfaz VLAN1 para que un administrador 

local de la zona V1-Trust pueda acceder a la dirección IP de administración de VLAN1. Si la administración a través de la WebUI aún no está habilitada en 

las interfaces de zona V1-Trust y VLAN1, no será posible acceder al dispositivo NetScreen a través de la WebUI para realizar estos ajustes. En su lugar, 

deberá habilitar la administración mediante WebUI en estas interfaces a través de una conexión de consola. 




Management Services: WebUI, Telnet 

Other Services: Ping 


Zone Name: V1-Trust 




Zone Name: V1-Untrust 



Address Name: local_lan 



Zone: V1-Trust 


Address Name: peer_lan 



Zone: V1-Untrust 



3. VPN 


Gateway Name: gw1 





Outgoing Zone: V1-Untrust 


4. Ruta 




Predefined: (seleccione), gw1 




Interface: VLAN1 (VLAN) 




5. Directivas 



Address Book Entry: (seleccione), local_lan 


Address Book Entry: (seleccione), peer_lan 

Service: ANY 


Tunnel VPN: vpn1 






1. Interfaces 

Nota: El desplazamiento de la dirección IP VLAN1 a una subred distinta hace que el dispositivo NetScreen 

elimine todas las rutas relacionadas con la interfaz VLAN1 anterior. A la hora de configurar un dispositivo 

NetScreen a través de la WebUI, la estación de trabajo debe acceder a la primera dirección VLAN1 y 

encontrarse en la misma subred que la dirección nueva. Después de cambiar la dirección VLAN1, deberá 

modificar la dirección IP de su estación de trabajo para que se encuentre en la misma subred que la nueva 

dirección VLAN1. Es posible que también tenga que reubicar su estación de trabajo en una subred 

físicamente adyacente al dispositivo NetScreen. 

Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes datos y haga clic en OK : 



Management Services: WebUI 31 , Telnet, Ping 


Management Services: WebUI, Telnet 

Other Services: Ping 


Zone Name: V1-Trust 



Zone Name: V1-Untrust 


31. Si la administración a través de la WebUI aún no está habilitada en las interfaces de zona V1-Trust y VLAN1, no será posible acceder al dispositivo 

NetScreen a través de la WebUI para realizar estos ajustes. En su lugar, deberá habilitar la administración mediante WebUI en estas interfaces a través de 

una conexión de consola. 




3. VPN 


Address Name: local_lan 



Zone: V1-Trust 


Address Name: peer_lan 



Zone: V1-Untrust 







Outgoing Zone: V1-Untrust 





Predefined: (seleccione), gw1 



4. Ruta 


5. Directivas 



Interface: VLAN1 (VLAN) 




Address Book Entry: (seleccione), local_lan 


Address Book Entry: (seleccione), peer_lan 

Service: ANY 


Tunnel VPN: vpn1 






1. Interfaces y zonas 

unset interface ethernet1 ip 

unset interface ethernet1 zone 

set interface ethernet1 zone v1-trust 

set zone v1-trust manage web 

set zone v1-trust manage telnet 

set zone v1-trust manage ping 32 



set interface ethernet3 zone v1-untrust 

set interface vlan1 ip 1.1.1.1/24 

set interface vlan1 manage-ip 1.1.1.2 

set interface vlan1 manage web 

set interface vlan1 manage telnet 

set interface vlan1 manage ping 


set address v1-trust local_lan 1.1.1.0/24 

set address v1-untrust peer_lan 2.2.2.0/24 

3. VPN 

set ike gateway gw1 address 2.2.2.2 main outgoing-interface v1-untrust preshare 

h1p8A24nG5 sec-level compatible 

set vpn vpn1 gateway gw1 sec-level compatible 

32. Se deben habilitar las opciones de administración para WebUI, Telnet y Ping tanto en la zona V1-Trust como en la interfaz VLAN1 para que un administrador 

local de la zona V1-Trust pueda acceder a la dirección IP de administración de VLAN1. 



4. Rutas 

set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 1.1.1.250 

5. Directivas 

set policy top from v1-trust to v1-untrust local_lan peer_lan any tunnel vpn 

vpn1 

set policy top from v1-untrust to v1-trust peer_lan local_lan any tunnel vpn 

vpn1 

save 


1. Interfaces y zonas 



set interface ethernet1 zone v1-trust 

set zone v1-trust manage 



set interface ethernet3 zone v1-untrust 

set interface vlan1 ip 2.2.2.2/24 

set interface vlan1 manage-ip 2.2.2.3 

set interface vlan1 manage 


set address v1-trust local_lan 2.2.2.0/24 

set address v1-untrust peer_lan 1.1.1.0/24 



3. VPN 

set ike gateway gw1 address 1.1.1.1 main outgoing-interface v1-untrust preshare 

h1p8A24nG5 sec-level compatible 


4. Rutas 

set vrouter trust-vr route 0.0.0.0/0 interface vlan1 gateway 2.2.2.250 

5. Directivas 

set policy top from v1-trust to v1-untrust local_lan peer_lan any tunnel vpn 

vpn1 

set policy top from v1-untrust to v1-trust peer_lan local_lan any tunnel vpn 

vpn1 

save 


Capítulo 5 

VPNs de acceso telefónico 

Los dispositivos NetScreen admiten conexiones a VPNs de acceso telefónico. Puede configurar un dispositivo 

NetScreen con una dirección IP estática para asegurar un túnel IPSec a un cliente NetScreen-Remote o a otro 

dispositivo NetScreen con una dirección IP dinámica. 

5 

En este capítulo se ofrecen ejemplos de los siguientes conceptos relacionados con las VPN de acceso telefónico: 

“VPNs de acceso telefónico” en la página 234 

– “Ejemplo: VPN de acceso telefónico basada en directivas, AutoKey IKE” en la página 235 

– “Ejemplo: VPN de acceso telefónico basada en rutas, interlocutor dinámico” en la página 244 

– “Ejemplo: VPN de acceso telefónico basada en directivas, interlocutor dinámico” en la página 256 

– “Ejemplo: Directivas bidireccionales para VPNs de acceso telefónico” en la página 267 

“Identificación IKE de grupo” en la página 275 

– “Ejemplo: Identificación IKE de grupo (certificados)” en la página 281 

– “Ejemplo: ID IKE de grupo (claves previamente compartidas)” en la página 290 

“Identificación IKE compartida” en la página 297 

– “Ejemplo: ID IKE compartida (claves previamente compartidas)” en la página 298 


Capítulo 5 VPNs de acceso telefónico VPNs de acceso telefónico 

VPNS DE ACCESO TELEFÓNICO 

Es posible configurar túneles para usuarios de VPN de acceso telefónico de forma individual o reuniendo varios 

usuarios en un grupo VPN de acceso telefónico, en cuyo caso sólo tendrá que configurar un túnel. También es 

posible crear un usuario de identificación IKE de grupo, lo que permite definir un usuario cuya identificación IKE se 

utilizará como parte de todas las IDs IKE de los usuarios IKE de acceso telefónico. Esto permite ahorrar bastante 

tiempo cuando hay grandes grupos de usuarios de acceso telefónico, puesto que no tendrá que configurar a cada 

usuario IKE individualmente. 

Nota: Para obtener más información sobre la creación de grupos de usuarios IKE, consulte “Usuarios y grupos de 

usuarios IKE” en la página 8 -78. Para obtener más información sobre la función de identificación IKE de grupo, 

consulte “Identificación IKE de grupo” en la página 275. 

Si el cliente de acceso telefónico admite una dirección IP interna virtual, como hace el dispositivo 

NetScreen-Remote, también puede crear un túnel AutoKey IKE de VPN de acceso telefónico para interlocutor 

dinámico (con clave o certificados previamente compartidos). Puede configurar una puerta de enlace segura 

NetScreen con una dirección IP estática para asegurar un túnel IPSec a un cliente NetScreen-Remote o a otro 

dispositivo NetScreen con una dirección IP dinámica. 

Nota: Para obtener más información sobre las opciones de VPN disponibles, consulte el Capítulo 1, “IPSec”. Si 

desea obtener ayuda para elegir entre las distintas opciones, consulte el Capítulo 3, “Directivas VPN”. 

Puede configurar túneles VPN basados en directivas para usuarios de acceso telefónico a VPNs. En el caso de un 

cliente dinámico de acceso telefónico 1 , puede configurar una VPN basada en directivas o basada en rutas. Dado 

que el cliente dinámico de acceso telefónico puede admitir una dirección IP interna virtual, al igual que el dispositivo 

NetScreen, puede configurar una entrada de la tabla de enrutamiento a esa dirección interna virtual a través de una 

interfaz de túnel designada. De esta forma podrá configurar un túnel VPN basado en rutas entre el dispositivo 

NetScreen y el cliente. 

Nota: Un interlocutor dinámico de acceso telefónico es prácticamente idéntico a un interlocutor dinámico punto a 

punto, excepto por el hecho de que la dirección IP interna del cliente de acceso telefónico es una dirección virtual. 

1. Un cliente dinámico de acceso telefónico es un cliente de acceso telefónico que admite una dirección IP interna virtual. 



Ejemplo: VPN de acceso telefónico basada en directivas, AutoKey IKE 

En este ejemplo, un túnel AutoKey IKE que utiliza una clave previamente compartida o un par de certificados (uno 

por cada extremo del túnel 2 ) proporciona el canal de comunicación segura entre el usuario IKE Wendy y el servidor 

UNIX. El túnel, nuevamente, utiliza ESP con encriptación 3DES y autenticación SHA-1. 

Para configurar el túnel AutoKey IKE utilizando AutoKey IKE con una clave previamente compartida o con 

certificados, es necesario realizar la siguiente configuración en la empresa: 

1. Configurar interfaces para las zonas Trust y Untrust, que se encuentran en el dominio de enrutamiento 

trust-vr. 

2. Introducir la dirección del servidor UNIX en la libreta de direcciones de la zona Trust. 

3. Definir a Wendy como usuario IKE. 

4. Configurar la puerta de enlace remota y la VPN AutoKey IKE. 

5. Configurar una ruta predeterminada. 

6. Crear una directiva de la zona Untrust a la zona Trust que permita que el usuario de acceso telefónico 

acceda a UNIX. 

Usuario remoto: Wendy 

NetScreen-Remote 

Internet 

Túnel VPN 

Zona 

Untrust 


Zona Untrust 

ethernet3, 1.1.1.1/24 


1.1.1.250 


Zona Trust 

ethernet1, 10.1.1.1/24 

2. La clave previamente compartida es h1p8A24nG5. Se parte de la base de que ambos participantes ya disponen de certificados. Para obtener más 

información sobre los certificados, consulte “Certificados y CRLs” en la página 29. 


LAN 

Zona 

Trust 

Servidor 

UNIX 

10.1.1.5


La clave previamente compartida es h1p8A24nG5. En este ejemplo se asume que ambos participantes ya tienen 

certificados RSA emitidos por Verisign, y que el certificado local en NetScreen-Remote contiene el U-FQDN 

wparker@email.com. (Para más información sobre cómo obtener y cargar certificados, consulte “Certificados y 

CRLs” en la página 29). Para los niveles de seguridad de las fases 1 y 2, debe especificar la propuesta de fase 1 

(ya sea pre-g2-3des-sha para el método de clave previamente compartida o rsa-g2-3des-sha para certificados) y 

seleccionar el conjunto de propuestas predefinido “Compatible” para la fase 2. 

WebUI 

1. Interfaces 











2. Dirección 


Address Name: UNIX 



Zone: Trust 



3. Usuario 

4. VPN 


User Name: Wendy 

Status: Enable (seleccione) 

IKE User: (seleccione) 

Simple Identity: (seleccione) 

IKE Identity: wparker@email.com 



Gateway Name: Wendy_NSR 



Dialup User: (seleccione), User: Wendy 





enlace: 






(o bien) 

Certificados 




enlace: 








VPN Name: Wendy_UNIX 



Predefined: (seleccione), Wendy_NSR 

5. Ruta 








6. Directiva 

CLI 


1. Interfaces 


Address Book Entry: (seleccione), Dial-Up VPN 


Address Book Entry: (seleccione), UNIX 

Service: ANY 


Tunnel VPN: Wendy_UNIX 

Modify matching bidirectional VPN policy: (anule la selección) 







2. Dirección 

set address trust unix 10.1.1.5/32 

3. Usuario 

set user wendy ike-id u-fqdn wparker@email.com 



4. VPN 


set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3 


set vpn wendy_unix gateway wendy_nsr sec-level compatible 

(o bien) 

Certificados 

set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3 


set ike gateway wendy_nsr cert peer-ca 1 3 

set ike gateway wendy_nsr cert peer-cert-type x509-sig 

set vpn wendy_unix gateway wendy_nsr sec-level compatible 

5. Ruta 


6. Directiva 

set policy top from untrust to trust “Dial-Up VPN” unix any tunnel vpn 

wendy_unix 

save 

3. El número 1 es el número de ID de la CA. Para consultar los números ID de CAs, utilice el siguiente comando: get pki x509 list ca-cert . 



Editor de directivas de seguridad de NetScreen-Remote 

1. Haga clic en Options > Secure > Specified Connections . 

2. Haga clic en Add a new connection y escriba UNIX junto al icono de nueva conexión que aparecerá en 

pantalla. 

3. Configure las opciones de conexión: 

Connection Security: Secure 

Remote Party Identity and Addressing: 

ID Type: IP Address, 10.1.1.5 

Protocol: All 

Connect using Secure Gateway Tunnel: (seleccione) 


4. Haga clic en el signo MÁS situado a la izquierda del icono de UNIX para ampliar la directiva de la conexión. 

5. Haga clic en My Identity: Siga uno de estos dos pasos: 

Haga clic en Pre-shared Key > Enter Key : Escriba h1p8A24nG5 y haga clic en OK . 

ID Type: (seleccione E-mail Address ) y escriba wparker@email.com . 

(o bien) 

Seleccione un certificado en la lista desplegable Select Certificate. 

ID Type: (seleccione E-mail Address ) 4 

6. Haga clic en el icono Security Policy , seleccione Aggressive Mode y desactive Enable Perfect Forward 

Secrecy (PFS) . 

7. Haga clic en el símbolo MÁS situado a la izquierda del icono Security Policy y, a continuación, en el 

símbolo MÁS situado a la izquierda de Authentication (Phase 1) y de Key Exchange (Phase 2) para ampliar 

más aún la directiva. 

4. La dirección de correo electrónico del certificado aparecerá automáticamente en el campo del identificador. 



8. Haga clic en Authentication (Phase 1) > Proposal 1 : Seleccione el siguiente método y algoritmos de 


Authentication Method: Pre-Shared Key 

(o bien) 

Authentication Method: RSA Signatures 

Encrypt Alg: Triple DES 

Hash Alg: SHA-1 

Key Group: Diffie-Hellman Group 2 

9. Haga clic en Key Exchange (Phase 2) > Proposal 1: Seleccione los siguientes protocolos IPSec: 

Encapsulation Protocol (ESP): (seleccione) 



Encapsulation: Tunnel 

10. Haga clic en Key Exchange (Phase 2) > Create New Proposal : Seleccione los siguientes protocolos 

IPSec: 



Hash Alg: MD5 


11. Haga clic en Key Exchange (Phase 2) > Create New Proposal : Seleccione los siguientes protocolos IPSec: 


Encrypt Alg: DES 






IPSec: 

13. Haga clic en File > Save Changes . 



Hash Alg: MD5 




Ejemplo: VPN de acceso telefónico basada en rutas, interlocutor dinámico 

En este ejemplo, un túnel VPN conecta de forma segura al usuario situado tras el dispositivo NetScreen-Remote a 

la interfaz de la zona Untrust del dispositivo NetScreen que protege el servidor de correo en la zona DMZ. La 

interfaz de la zona Untrust tiene una dirección IP estática. El cliente NetScreen-Remote tiene una dirección IP 

externa asignada dinámicamente y una dirección IP interna estática (virtual). El administrador del dispositivo 

NetScreen debe conocer la dirección IP interna del interlocutor por dos motivos: 

Puede utilizarla en directivas. 

Puede crear una ruta asociando la dirección con una interfaz de túnel unida a un túnel VPN apropiado. 

Cuando el cliente NetScreen-Remote establece el túnel, el tráfico a través de él puede originarse desde el otro 

extremo. Todas las zonas del dispositivo NetScreen se encuentran en el dominio de enrutamiento Trust-vr. 

Petición 

SMTP 

Usuario remoto: Phil 


Dirección IP interna 

10.10.10.1 

Zona Untrust 

Internet 

Túnel VPN 

Dirección IP externa 

dinámica 

Puerta de 

enlace 

1.1.1.250 



ethernet3 

ethernet2 

1.1.1.1/24 1.2.2.1/24 

Zona DMZ 

Servidor de 

correo 

electrónico 

1.2.2.5 


Tunnel.1 

Petición 

IDENT 

En este ejemplo, Phil desea acceder a su correo electrónico desde el servidor de correo de la empresa. Cuando 

intenta hacerlo, es autenticado por el programa del servidor de correo, que le envía una petición IDENT a través del 

túnel. 

Nota: El servidor de correo puede enviar la petición IDENT a través del túnel sólo si el administrador NetScreen 

agrega un servicio personalizado para ello (TCP, puerto 113) y establece una directiva de salida que permita el 

tráfico a través del túnel hacia 10.10.10.1. 



La clave previamente compartida es h1p8A24nG5. Partiremos de la base de que ambos participantes ya tienen 


pm@juniper.net. (Para más información sobre cómo obtener y cargar certificados, consulte “Certificados y CRLs” 

en la página 29). Para los niveles de seguridad de las fases 1 y 2, debe especificar la propuesta de fase 1 (ya sea 

pre-g2-3des-sha para el método de clave previamente compartida o rsa-g2-3des-sha para certificados) y 


Introduzca las tres rutas siguientes en el dispositivo NetScreen: 

Una ruta predeterminada que conduzca al enrutador externo en trust-vr. 

Una ruta al destino a través de la interfaz de túnel. 

Una ruta nula al destino. Asigne una métrica más alta (más alejada de cero) a la ruta nula para que se 

convierta en la siguiente opción de ruta al destino. A continuación, si el estado de la interfaz de túnel 

cambia a “inactivo” y la ruta que hace referencia a esa interfaz también se inactiva, el dispositivo NetScreen 

utiliza la ruta nula, que descarta todo tráfico enviado hacia él, en lugar de la ruta predeterminada, que 

reenvía tráfico no encriptado. 

Finalmente, creará directivas permitiendo que el tráfico fluya en ambas direcciones entre Phil y el servidor de 

correo. 

WebUI 

1. Interfaces 





















Zone: DMZ 


3. Servicios 

Address Name: Phil 



Zone: Untrust 













Group Members AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK : 


(o bien) 

Gateway Name: To_Phil 



Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net 





enlace: 






Certificados 




enlace: 








VPN Name: corp_Phil 



Predefined: (seleccione), To_Phil 



Bind to: Interfaz de túnel: (seleccione), tunnel.1 




Service: Any 



5. Rutas 
















Metric: 10 



6. Directivas 

Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK : 


Address Book Entry: (seleccione), Phil 






Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK : 










CLI 

1. Interfaces 








set address dmz “Mail Server” 1.2.2.5/32 

set address untrust phil 10.10.10.1/32 

3. Servicios 






4. VPN 


set ike gateway to_phil dynamic pm@juniper.net aggressive outgoing-interface 


set vpn corp_phil gateway to_phil sec-level compatible 

set vpn corp_phil bind interface tunnel.1 

set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any 

(o bien) 



Certificados 



set ike gateway to_phil cert peer-ca 1 5 

set ike gateway to_phil cert peer-cert-type x509-sig 


set vpn corp_phil bind interface tunnel.1 

set vpn corp_phil proxy-id local-ip 1.2.2.5/32 remote-ip 10.10.10.1/32 any 

5. Rutas 




6. Directivas 

set policy top from dmz to untrust “Mail Server” phil remote_mail permit 

set policy top from untrust to dmz phil “Mail Server” remote_mail permit 

save 





1. Haga clic en Options > Global Policy Settings y seleccione la casilla de verificación Allow to Specify 

Internal Network Address . 

2. Options > Secure > Specified Connections . 

3. Haga clic en el botón Add a new connection y escriba Mail junto al icono de la nueva conexión que 

aparecerá en pantalla. 





Protocol: All 



5. Haga clic en el signo MÁS situado a la izquierda del icono de unix para ampliar la directiva de la conexión. 

6. Haga clic en el icono Security Policy, seleccione Aggressive Mode y desactive Enable Perfect Forward 


7. Haga clic en My Identity y lleve a cabo una de estas dos acciones: 

Haga clic en Pre-shared Key > Enter Key : Escriba h1p8A24nG5 y haga 

clic en OK . 

ID Type: E-mail Address; pm@juniper.net 

Internal Network IP Address: 10.10.10.1 

(o bien) 

Seleccione el certificado que contiene la dirección de correo electrónico 

“pm@juniper.net” en la lista desplegable “Select Certificate”. 











(o bien) 





10. Haga clic en Key Exchange (Phase 2) > Proposal 1 : Seleccione los siguientes protocolos IPSec: 






IPSec: 



Hash Alg: MD5 





IPSec: 






IPSec: 




Hash Alg: MD5 




Ejemplo: VPN de acceso telefónico basada en directivas, interlocutor dinámico 

En este ejemplo, un túnel VPN conecta de forma segura al usuario situado tras el dispositivo NetScreen-Remote a 

la interfaz de la zona Untrust del dispositivo NetScreen que protege el servidor de correo en la zona DMZ. La 

interfaz de la zona Untrust tiene una dirección IP estática. El cliente NetScreen-Remote tiene una dirección IP 

externa asignada dinámicamente y una dirección IP interna estática (virtual). El administrador del dispositivo 

NetScreen debe conocer la dirección IP interna del cliente, de forma que pueda agregarla a la libreta de direcciones 

de la zona Untrust para su uso en directivas de tráfico de túnel desde ese origen. Cuando el cliente 

NetScreen-Remote establece el túnel, el tráfico que lo atraviesa puede originarse desde el otro extremo. 

Usuario remoto: Phil 


Zona Untrust 


Petición 

SMTP 

ethernet3, 1.1.1.1/24 


1.1.1.250 


Zona DMZ 

ethernet2, 1.2.2.1/24 

Dirección IP interna 

10.10.10.1 

Dirección IP externa 

dinámica 

Internet 

Túnel VPN 

Zona 

Untrust 

En este ejemplo, Phil desea acceder a su correo electrónico desde el servidor de correo de la empresa. Cuando 

intenta hacerlo, es autenticado por el programa del servidor de correo, que le envía una petición IDENT a través del 

túnel. 

Nota: El servidor de correo puede enviar la petición IDENT a través del túnel sólo si el administrador NetScreen 

agrega un servicio personalizado para ello (TCP, puerto 113) y establece una directiva de salida que permita el 

tráfico a través del túnel hacia 10.10.10.1. 


Zona 

DMZ 

Petición 

IDENT 

Servidor de 

correo 

electrónico 

1.2.2.5


La clave previamente compartida es h1p8A24nG5. En este ejemplo se asume que ambos participantes ya tienen 


pm@juniper.net. (Para más información sobre cómo obtener y cargar certificados, consulte “Certificados y CRLs” 

en la página 29.) Para los niveles de seguridad de las fases 1 y 2, debe especificar la propuesta de fase 1 (ya sea 

pre-g2-3des-sha para el método de clave previamente compartida o rsa-g2-3des-sha para certificados) y 


WebUI 

1. Interfaces 














Zone: DMZ 




3. Servicios 

Address Name: Phil 



Zone: Untrust 











Group Members


4. VPN 



(o bien) 

Certificados 

Gateway Name: To_Phil 



Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net 





enlace: 







enlace: 










VPN Name: corp_Phil 



Predefined: (seleccione), To_Phil 

5. Ruta 






6. Directivas 

Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y haga clic en OK : 







VPN Tunnel: corp_Phil 





CLI 

1. Interfaces 






set address dmz “mail server” 1.2.2.5/32 

set address untrust phil 10.10.10.1/32 

3. Servicios 






4. VPN 





(o bien) 



Certificados 



set ike gateway to_phil cert peer-ca 1 6 

set ike gateway to_phil cert peer-cert-type x509-sig 


5. Ruta 


6. Directivas 

set policy top from untrust to dmz phil “mail server” remote_mail tunnel vpn 

corp_phil 

set policy top from dmz to untrust “mail server” phil remote_mail tunnel vpn 

corp_phil 

save 





1. Haga clic en Options > Global Policy Settings y seleccione Allow to Specify Internal Network 

Address . 

2. Options > Secure > Specified Connections . 

3. Haga clic en Add a new connection y escriba Mail junto al icono de nueva conexión que aparecerá en 

pantalla. 





Protocol: All 



5. Haga clic en el signo MÁS situado a la izquierda del icono de unix para ampliar la directiva de la conexión. 

6. Haga clic en el icono Security Policy seleccione Aggressive Mode y desactive Enable Perfect Forward 


7. Haga clic en My Identity y lleve a cabo una de estas dos acciones: 

Haga clic en Pre-shared Key > Enter Key : Escriba h1p8A24nG5 y haga 

clic en OK . 



(o bien) 

Seleccione el certificado que contiene la dirección de correo electrónico 

“pmason@email.com” en la lista desplegable “Select Certificate”. 











(o bien) 











IPSec: 



Hash Alg: MD5 





IPSec: 






IPSec: 




Hash Alg: MD5 




Directivas bidireccionales para usuarios de VPN de acceso telefónico 

Es posible crear directivas bidireccionales para VPNs de acceso telefónico. Esta configuración presenta unas 

funciones similares a la configuración VPN para interlocutores dinámicos. Sin embargo, con una configuración de 

VPN para interlocutores dinámicos, el administrador del dispositivo NetScreen debe conocer el espacio de 

direcciones IP interno del usuario de acceso telefónico, de forma que pueda utilizarlo como dirección de destino 

cuando configure una directiva de salida (consulte “Ejemplo: VPN de acceso telefónico basada en directivas, 

interlocutor dinámico” en la página 256). Con una configuración de usuario de VPN de acceso telefónico, el 

administrador del sitio LAN no necesita conocer el espacio de direcciones interno del usuario de acceso telefónico. 

El dispositivo NetScreen que protege la red LAN utiliza la dirección predefinida “Dial-Up VPN” como dirección de 

origen en la directiva de entrada y la de destino en la directiva de salida. 

La posibilidad de crear directivas bidireccionales para un túnel VPN permite que el tráfico se origine en un extremo 

de la LAN de la conexión VPN cuando ya se ha establecido la conexión (el equipo remoto debe iniciar en primer 

lugar la creación del túnel). Observe que, a diferencia de un túnel VPN de acceso telefónico de interlocutor 

dinámico, con esta función es necesario que sean idénticos los servicios de las directivas de entrada y salida. 

Nota: NetScreen no admite grupos de servicios ni de direcciones en las directivas bidireccionales que hacen 

referencia a una configuración de VPN de acceso telefónico. 

Tenga en cuenta que el espacio de direcciones interno de dos o más usuarios de una VPN de acceso telefónico 

conectados simultáneamente podría hacer que se superpusieran. Por ejemplo, los usuarios de acceso telefónico A 

y B podrían tener un espacio de direcciones IP interno 10.2.2.0/24. Si esto sucede, el dispositivo NetScreen envía 

todo el tráfico de VPN saliente al usuario A y al usuario B a través de la VPN de la que se incluye una referencia en 

la primera directiva que encuentre en la lista de directivas. Si la directiva de salida relativa a la VPN del usuario A 

aparece primero en la lista de directivas, el dispositivo NetScreen envía al usuario A todo el tráfico VPN saliente 

para los usuarios A y B. 

De forma similar, la dirección interna de un usuario de acceso telefónico podría superponerse con una dirección de 

cualquier otra directiva, independientemente de si esa otra directiva hace referencia a un túnel VPN. Si esto 

sucede, el dispositivo NetScreen aplica la primera directiva que coincida con los atributos básicos de tráfico 

relativos a la dirección de origen, dirección de destino, número de puerto de origen, número de puerto de destino o 

servicio. Para evitar que una directiva bidireccional para una VPN de acceso telefónico con una dirección derivada 

dinámicamente anule otra directiva con una dirección estática, Juniper Networks recomienda colocar la directiva 

bidireccional de VPN de acceso telefónico en una posición más baja en la lista de directivas. 



Ejemplo: Directivas bidireccionales para VPNs de acceso telefónico 

En este ejemplo configuraremos directivas bidireccionales para un túnel VPN de acceso telefónico AutoKey IKE 

llamado VPN_dial para el usuario IKE dialup-j con la identificación IKE jf@ns.com . Para las negociaciones de la 

fase 1, utilice la propuesta pre-g2-3des-sha con la clave previamente compartida Jf11d7uU . Seleccione el conjunto 

predefinidos de propuestas “Compatible” para las negociaciones de la fase 2. 

El usuario IKE inicia una conexión VPN al dispositivo NetScreen desde la zona Untrust para acceder a los 

servidores corporativos de la zona Trust. Una vez el usuario IKE establece la conexión VPN, el tráfico se puede 

iniciar desde cualquiera de los dos extremos del túnel. 

La interfaz de la zona Trust es ethernet1, tiene la dirección IP 10.1.1.1/24 y se encuentra en modo NAT. La interfaz 

de la zona Untrust es ethernet3 y tiene la dirección IP 1.1.1.1/24. La ruta predeterminada apunta al enrutador 

externo situado en 1.1.1.250. 

WebUI 

1. Interfaces 













2. Objetos 

3. VPN 


Address Name: trust_net 



Zone: Trust 


User Name: dialup-j 



Simple Identity: (seleccione); jf@ns.com 


Gateway Name: dialup1 



Dialup User: (seleccione); dialup-j 

Preshared Key: Jf11d7uU 



enlace: 







4. Ruta 

VPN Name: VPN_dial 



Create a Simple Gateway: (seleccione) 


Type: 

Dialup User: (seleccione); dialup-j 

Preshared Key: Jf11d7uU 










5. Directivas 





Address Book Entry: (seleccione), trust_net 

Service: ANY 


VPN Tunnel: VPN_dial 




CLI 

1. Interfaces 






2. Objetos 

set address trust trust_net 10.1.1.0/24 

set user dialup-j ike-id u-fqdn jf@ns.com 

3. VPN 

set ike gateway dialup1 dialup dialup-j aggressive outgoing-interface ethernet3 

preshare Jf11d7uU proposal pre-g2-3des-sha 

set vpn VPN_dial gateway dialup1 sec-level compatible 

4. Ruta 


5. Directivas 

set policy from untrust to trust “Dial-Up VPN” trust_net any tunnel vpn 

VPN_dial 

set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn 

VPN_dial 

save 





2. Haga clic en Add a new connection y escriba Corp junto al icono de nueva conexión que aparecerá en 

pantalla. 



Remote Party Identity and Addressing 

ID Type: IP Subnet 

Subnet: 10.1.1.0 

Mask: 255.255.255.0 

Protocol: All 



4. Haga clic en el signo MÁS situado a la izquierda del icono de UNIX para ampliar la directiva de la conexión. 

5. Haga clic en My Identity : Siga uno de estos dos pasos: 

Haga clic en Pre-shared Key > Enter Key : Escriba Jf11d7uU y haga clic en OK . 

ID Type: (seleccione E-mail Address ) y escriba jf@ns.com . 











(o bien) 











IPSec: 



Hash Alg: MD5 



IPSec: 








IPSec: 



Hash Alg: MD5 




Capítulo 5 VPNs de acceso telefónico Identificación IKE de grupo 

IDENTIFICACIÓN IKE DE GRUPO 

Algunas organizaciones pueden tener muchos usuarios de acceso telefónico VPN. Por ejemplo, un departamento 

de ventas puede tener cientos de usuarios, muchos de los cuales necesitarán comunicación segura por acceso 

telefónico cuando se encuentran fuera de las oficinas. Con tantos usuarios, no resulta práctico crear una definición 

de usuario, una configuración de VPN y una directiva para cada uno. 

Para evitar este problema, el método de identificación IKE de grupo permite que una sola definición esté disponible 

para múltiples usuarios. La definición de usuario para una identificación IKE de grupo se aplica a todos los usuarios 

que tengan certificados con valores específicos en el nombre completo (DN) o a todos los usuarios cuya 

identificación IKE completa y clave previamente compartida en su cliente VPN coincida con una identificación IKE 

parcial y una clave previamente compartida del dispositivo NetScreen. 

Nota: Cuando un usuario IKE de acceso telefónico se conecta al dispositivo NetScreen, éste primero extrae y 

utiliza la identificación IKE completa para buscar sus registros de puerta de enlace de interlocutor por si el usuario 

no pertenece a un grupo de usuarios de identificación IKE de grupo. Si la búsqueda con la identificación IKE 

completa no ofrece ningún resultado, el dispositivo NetScreen realizará una nueva búsqueda de parte de la 

identificación IKE, buscando coincidencias entre la identificación IKE entrante incorporada y un usuario ya 

configurado de la identificación IKE de grupo. 

Debe agregar un único usuario de identificación IKE de grupo a un grupo de usuarios IKE de una VPN de acceso 

telefónico y especificar el número máximo de conexiones simultáneas que admitirá dicho grupo. El número máximo 

de sesiones simultáneas no podrá exceder el número máximo de asociaciones de seguridad admitidas en la fase 1 

o el número máximo de túneles VPN admitidos en la plataforma NetScreen. 



Identificación IKE de grupo con certificados 

La identificación IKE de grupo con certificados es una técnica para llevar a cabo la autenticación IKE para un grupo 

de usuarios IKE de acceso telefónico sin tener que configurar un perfil de usuario independiente para cada uno de 

ellos. En lugar de hacer eso, el dispositivo NetScreen utiliza un único perfil de usuario de identificación IKE de grupo 

con una identificación IKE parcial. El usuario IKE de acceso telefónico podrá establecer correctamente un túnel 

VPN a un dispositivo NetScreen si la configuración de VPN en su cliente VPN especifica un certificado que 

contenga elementos de nombre completo con coincidan con los configurados como definición de la identificación 

IKE parcial en el perfil de usuario de identificación IKE de grupo en el dispositivo NetScreen. 

Usuarios IKE 

de acceso 

telefónico 

ID IKE de grupo completa 

(nombre completo) 

Certificado 

DN: 

cn=alice 

ou=eng 

---------- 

---------- 

Certificado 

DN: 

cn=bob 

ou=eng 

---------- 

---------- 

Certificado 

DN: 

cn=carol 

ou=sales 

---------- 

---------- 

 

 

 

Identificación IKE de grupo con certificados 

Nota: Como el nombre completo 

en el certificado de Carol no 

incluye ou=eng , NetScreen 

rechaza la petición de conexión. 

Grupo de usuarios de acceso 

telefónico 

Usuario de identificación IKE de 

grupo 

Tipo de ID IKE ASN1-DN 

ID IKE parcial: ou=eng 

Para autenticar el usuario, NetScreen compara 

un elemento específico del nombre completo 

(DN) asociado al grupo de usuarios de acceso 

telefónico con el elemento correspondiente del 

certificado y del DN utilizados en la carga de 

datos de la identificación IKE que acompaña al 

paquete inicial de la fase 1. 



Puede configurar una identificación IKE de grupo con certificados tal y como se indica a continuación: 

En el dispositivo NetScreen: 

1. Cree un nuevo usuario de identificación IKE de grupo con una identidad IKE parcial (como 

ou=sales,o=netscreen) y especifique cuántos usuarios de acceso telefónico podrán utilizar el perfil de la 

identificación IKE de grupo para conectarse. 

2. Asigne el nuevo usuario de ID IKE de grupo al grupo de usuarios de acceso telefónico 7 y asigne un nombre 

al grupo. 

3. En la configuración de la VPN de acceso telefónico AutoKey IKE, especifique el nombre del grupo de 

usuarios de acceso telefónico, indique que las negociaciones de la fase 1 serán del modo dinámico y que 

para la autenticación se utilizarán certificados (RSA o DSA, según el tipo de certificado cargado en los 

clientes VPN de acceso telefónico). 

4. Cree una directiva que permita el tráfico de entrada a través de la VPN de acceso telefónico especificada. 

En el cliente VPN: 

1. Obtenga y cargue un certificado cuyo nombre completo contenga la misma información definida en la 

identificación IKE parcial del dispositivo NetScreen. 

2. Configure un túnel VPN al dispositivo NetScreen utilizando el modo dinámico para las negociaciones de la 

fase 1, especifique el certificado cargado anteriormente y seleccione Distinguished Name para el tipo de 

identificación IKE local. 

A continuación, cada usuario IKE de acceso telefónico que disponga de un certificado con elementos de nombre 

completo que coincidan con la identificación IKE parcial definida en el perfil de usuario de la ID IKE de grupo podrán 

establecer correctamente un túnel al dispositivo NetScreen. Por ejemplo, si el usuario de ID IKE de grupo tiene la ID 

IKE OU=sales,O=netscreen, el dispositivo NetScreen aceptará las negociaciones de fase 1 de cualquier usuario 

que tenga un certificado con esos elementos en su nombre completo. El número máximo de usuarios IKE de 

acceso telefónico que se podrán conectar al dispositivo NetScreen dependerá del número máximo de sesiones 

simultáneas que especifique en el perfil de usuario de identificación IKE de grupo. 

7. Sólo puede asignar un usuario de ID IKE de grupo a un grupo de usuarios IKE. 



Tipos de identificación IKE ASN1-DN Wildcard y Container 

Cuando se define la ID IKE para un usuario IKE de grupo, se utiliza el nombre completo según la norma ASN-1 

(ASN1-DN) como tipo de identificación IKE de la configuración de identidad. Esta notación constituye una cadena 

de valores, ordenados normalmente desde lo más general a lo más específico. Por ejemplo: 

ASN1-DN: C=us,ST=ca,L=sunnyvale,O=juniper,OU=sales,CN=joe 

C=us 

ST=ca 

L=sunnyvale 

O=juniper 

OU=sales 

CN=joe 

Específico 

General 

Leyenda: 

C = País 

ST = Estado 

L = Localidad 

O = Organización 

OU = Unidad organizativa 

CN = Nombre común 

Cuando se configura el usuario de la identificación IKE de grupo, debe especificar la ID ASN1-DN del interlocutor 

como uno de estos dos tipos: 

Wildcard: NetScreen autentica la ID de un usuario IKE de acceso telefónico si los valores de los campos 

identificativos del ASN1-DN de dicho usuario coinciden con los de los campos identificativos del ASN1-DN 

del usuario IKE de grupo. El tipo de ID Wildcard sólo admite un valor por cada campo identificativo (por 

ejemplo, “ou=eng” o bien “ou=sw”, pero no “ou=eng,ou=sw”). Así, el orden que sigan los campos 

identificativos en las dos cadenas ASN1-DN no es importante. 

Container: NetScreen autentica la ID de un usuario IKE de acceso telefónico si los valores de los campos 

identificativos del ASN1-DN de dicho usuario coinciden exactamente con los de los campos identificativos 

del ASN1-DN del usuario IKE de grupo. El tipo de ID Container admite múltiples entradas por cada campo 

identificativo (por ejemplo, “ou=eng,ou=sw,ou=screenos”). El orden de los valores en los campos 

identificativos de las dos cadenas ASN1-DN debe ser idéntico. 

Cuando configure una ID de ASN1-DN para un usuario IKE remoto, deberá especificar el tipo como “wildcard” o 

“container”, y definir la ID ASN1-DN que espere recibir en el certificado del interlocutor (p. ej., 

“c=us,st=ca,cn=jrogers”). Si configura una ID ASN1-DN para una ID IKE local, utilice la siguiente palabra clave: 

[DistinguishedName]. Incluya los corchetes y escríbalo exactamente como se indica. 



ID IKE del ASN1-DN de tipo Wildcard 

Un ASN1-DN de tipo Wildcard hace necesario que los valores de la ID IKE del nombre completo del interlocutor 

remoto coincidan con los valores de la ID IKE parcial del ASN1-DN del usuario IKE de grupo. El orden que sigan 

estos valores en la cadena del ASN1-DN es irrelevante. Por ejemplo, si la ID del usuario IKE de acceso telefónico y 

la ID del usuario IKE de grupo son las siguientes: 

ID IKE del ASN1-DN completo del usuario IKE de acceso telefónico: 

CN=christine,OU=finance,O=netscreen,ST=ca,C=us 

ID IKE parcial del ASN1-DN del usuario IKE de grupo: C=us,O=netscreen 

una ID IKE de tipo Wildcard del ASN1-DN hace que coincidan las dos IDs IKE, aunque el orden de los valores en 

las dos IDs difiere. 

El ASN1-DN del usuario IKE de 

acceso telefónico contiene los 

valores especificados en el 

ASN1-DN del usuario IKE de 

grupo. El orden de los valores es 

irrelevante. 

ID IKE del ASN1-DN 

del usuario IKE de 


E= 

CN=christine 

OU=finance 

O=juniper 

L= 

ST=ca 

C=us 


 

ID IKE Wildcard del 

ASN1-DN del usuario IKE 

de grupo 

E= 


C=us 

ST= 

L= 

O=juniper 

OU= 

CN=


ID IKE del ASN1-DN de tipo Container 

Una ID de tipo Container del ASN1-DN permite que la ID del usuario IKE de grupo tenga múltiples entradas en cada 

campo identificativo. NetScreen autentica un usuario IKE de acceso telefónico si la ID de usuario de acceso 

telefónico contiene valores que coinciden al cien por cien con los valores de la ID del usuario IKE de grupo. Al 

contrario de lo que sucede con el tipo Wildcard, el orden de los campos del ASN1-DN también debe coincidir en las 

IDs del usuario IKE de acceso telefónico y del usuario IKE de grupo. Si hay valores múltiples, su orden en los 

campos correspondientes también deberá ser igual. 

El primer ASN1-DN de usuario 

IKE de acceso telefónico 

contiene valores exactamente 

iguales a los del ASN1-DN del 

usuario IKE de grupo. El orden 

de las entradas múltiples en el 

campo identificativo OU 

también es igual. 

El segundo ASN1-DN de 

usuario IKE de acceso 

telefónico contiene valores 

exactamente iguales a los del 

ASN1-DN del usuario IKE de 

grupo. Sin embargo, el orden 

de las entradas múltiples en el 

campo identificativo OU no es 

igual. 

ID IKE del ASN1-DN del usuario 


E= 

C=us 

ST=ca 

L= sf 

O=juniper 

OU=mkt,OU=dom,OU=west 

CN=yuki 

ID IKE del ASN1-DN del usuario 


E= 

C=us 

ST=ca 

L= la 

O=juniper 

OU=mkt,OU=west,OU=dom 

CN=joe 


 


ID IKE Container del ASN1-DN del 

usuario IKE de grupo 


 

E= 

C=us 

ST= 

L= 

O=juniper 


CN= 

ID IKE Container del ASN1-DN 

del usuario IKE de grupo 

E= 

C=us 

ST= 

L= 

O=juniper 


CN=


Ejemplo: Identificación IKE de grupo (certificados) 

En este ejemplo definirá un nuevo usuario de identificación IKE de grupo llamado User1. A continuación, 

configurará la definición para que acepte un máximo de 10 negociaciones simultáneas en la fase 1 por parte de 

clientes VPN con certificados RSA que contengan O=netscreen y OU=marketing . La autoridad de certificación (CA) 

será Verisign. El grupo de usuarios IKE de acceso telefónico será office_1 . 

Usuario de 

acceso 

telefónico con ID 

IKE: 

o=juniper 

ou=marketing 

Zona Untrust 

Túnel VPN 


Zona Untrust 

eth3, 1.1.1.1/24 

puerta de enlace 

1.1.1.250 

Perfil de usuario de 

identificación IKE de grupo 

User Name: User1 

Grupo de usuarios: office_1 

Nombre completo: 

o=juniper 

ou=marketing 

Zona Trust 

eth1, 10.1.1.1/24 

Modo NAT 

Zona Trust 

web1 

10.1.1.5 

Los usuarios IKE de acceso telefónico envían un nombre completo como su ID IKE. El nombre completo (DN) en un 

certificado para un usuario IKE de acceso telefónico en este grupo puede aparecer como la siguiente cadena: 

C=us,ST=ca,L=sunnyvale,O=netscreen,OU=marketing,CN=michael zhang,CN=a2010002,CN=ns500, 

CN=4085557800,CN=rsa-key,CN=10.10.5.44 

Como los valores O=netscreen y OU=marketing aparecen en el certificado del interlocutor y el usuario utiliza el 

nombre completo como su tipo de identificación IKE, el dispositivo NetScreen autenticará el usuario. 

Para los niveles de seguridad de las fases 1 y 2, debe especificar la propuesta de fase 1 (rsa-g2-3des-sha para 

certificados) y seleccionar el conjunto de propuestas predefinido “Compatible” para la fase 2. 

Ahora debe configurar una VPN de acceso telefónico y una directiva que permita el tráfico HTTP a través del túnel 

VPN para acceder al servidor web Web1. También se incluirá la configuración del cliente VPN remoto (utilizando 

NetScreen-Remote). 



WebUI 

1. Interfaces 








2. Dirección 





3. Usuarios 

Address Name: web1 



Zone: Trust 



Status Enable: (seleccione) 




Number of Multiple Logins with same ID: 10 

Use Distinguished Name For ID: (seleccione) 

OU: marketing 

Organization: juniper 

Objects > User Groups > Local > New: Escriba office_1 en el campo Group Name, realice la acción que se 

indica a continuación y, finalmente, haga clic en OK : 

Seleccione User1 y utilice el botón AutoKey Advanced > Gateway > New: Introduzca los siguientes datos y haga clic en OK : 

Gateway Name: Corp_GW 


Remote Gateway Type: Dialup User Group: (seleccione), Group: office_1 




enlace: 










5. Ruta 

VPN Name: Corp_VPN 


Remote Gateway: Predefined: (seleccione), Corp_GW 


6. Directiva 









Address Book Entry: (seleccione), web1 

Service: HTTP 


Tunnel VPN: Corp_VPN 





CLI 

1. Interfaces 






2. Dirección 

set address trust web1 10.1.1.5/32 

3. Usuarios 

set user User1 ike-id asn1-dn wildcard o=juniper,ou=marketing share-limit 10 

set user-group office_1 user User1 

4. VPN 

set ike gateway Corp_GW dialup office_1 aggressive outgoing-interface ethernet3 


set ike gateway Corp_GW cert peer-ca 1 8 

set ike gateway Corp_GW cert peer-cert-type x509-sig 

set vpn Corp_VPN gateway Corp_GW sec-level compatible 

5. Ruta 


6. Directiva 

set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn Corp_VPN 

save 






2. Haga clic en Add a new connection y escriba web1 junto al icono de nueva conexión que aparecerá en 

pantalla. 





Protocol: Seleccione All , escriba HTTP , pulse el tabulador y escriba 80 . 



4. Haga clic en el signo MÁS situado a la izquierda del icono de web1 para ampliar la directiva de la conexión. 

5. Haga clic en My Identity : Seleccione el certificado que tiene los elementos o=netscreen,ou=marketing en 

su nombre completo en la lista desplegable Select Certificate 9 . 

ID Type: Seleccione Distinguished Name en la lista desplegable. 






8. Haga clic en Authentication (Phase 1) > Proposal 1 : Seleccione los siguientes algoritmos de encriptación 

e integridad de datos: 





9. En este ejemplo se parte de la base de que ya ha cargado un certificado adecuado en el cliente NetScreen-Remote. Para obtener más información sobre 

cómo cargar certificados en el cliente NetScreen-Remote, consulte la documentación de NetScreen-Remote. 









IPSec: 



Hash Alg: MD5 



IPSec: 






IPSec: 




Hash Alg: MD5 




ID IKE de grupo con claves previamente compartidas 

La identificación IKE de grupo con claves previamente compartidas es una técnica para llevar a cabo la 

autenticación IKE para un grupo de usuarios IKE de acceso telefónico sin tener que configurar un perfil de usuario 

independiente para cada uno de ellos. En lugar de hacer eso, el dispositivo NetScreen utiliza un único perfil de 

usuario de identificación IKE de grupo con una identificación IKE parcial. El usuario IKE de acceso telefónico podrá 

establecer correctamente un túnel VPN a un dispositivo NetScreen si la configuración de su cliente VPN tiene la 

clave previamente compartida correcta y si la mayor parte de la ID IKE completa del usuario coincide con la ID IKE 

parcial del perfil de usuario de la identificación IKE de grupo. 

Usuarios IKE 

de acceso 

telefónico 

ID IKE de grupo con 

claves previamente 

compartidas 

+ 

Clave previamente 

compartida 

alice.eng.ns.com 

+ 

011fg3322eda837c 

bob.eng.ns.com 

+ 

bba7e22561c5da82 

carol.ns.com 

+ 

834a2bbd32adc4e9 

 

 

 

ID IKE de grupo con claves 

previamente compartidas 

Nota: Como la ID IKE de Carol no es 

carol.eng.ns.com , NetScreen 

rechaza la petición de conexión. 

Grupo de usuarios de acceso 

telefónico 

Usuario de identificación IKE de 

grupo 

ID IKE parcial: eng.ns.com 

Valor de inicialización de clave 

previamente compartida: N11wWd2 

NetScreen genera en tiempo real una clave 

previamente compartida cuando un usuario 

IKE envía su identificación IKE completa. 

(Clave previamente compartida de cada 

usuario IKE = valor inicial de clave previamente 

compartida x ID IKE completa). 

Para autenticar el usuario, NetScreen compara 

su clave generada con la clave previamente 

compartida que acompaña al paquete inicial de 

la fase 1. 

El tipo de ID IKE que utilice para la ID IKE de grupo con función de clave previamente compartida puede ser una 

dirección de correo electrónico o un nombre de dominio completo (FQDN). 



Puede configurar una identificación IKE de grupo con claves previamente compartidas tal y como se indica a 

continuación: 

En el dispositivo NetScreen: 

1. Cree un nuevo usuario de identificación IKE de grupo con una identidad IKE parcial (como juniper.net) y 

especifique cuántos usuarios de acceso telefónico podrán utilizar el perfil de la identificación IKE de grupo 

para conectarse. 

2. Asigne el nuevo usuario de ID IKE de grupo a un grupo de usuarios de acceso telefónico. 

3. En la configuración de la VPN de acceso telefónico AutoKey IKE, asigne un nombre para la puerta de 

enlace remota (p. ej., road1), especifique el grupo de usuarios de acceso telefónico e introduzca un valor 

inicial de clave previamente compartida. 

4. Utilice el siguiente comando CLI para generar una clave previamente compartida individual para el usuario 

de acceso telefónico utilizando el valor inicial de clave previamente compartida y la ID IKE completa del 

usuario (como joe@juniper.net). 

exec ike preshare-gen name_str usr_name_str 

(por ejemplo) exec ike preshare-gen road1 joe@juniper.net 

5. Registre la clave previamente compartida para poder utilizarla durante la configuración de un cliente VPN 

remoto. 


Configure un túnel VPN al dispositivo NetScreen utilizando el modo dinámico en las negociaciones de la 

fase 1 e introduzca la clave previamente compartida que generó anteriormente en el dispositivo NetScreen. 

Posteriormente, el dispositivo NetScreen podrá autenticar correctamente a cada usuario individual cuya ID IKE 

contenga una sección que coincida con el perfil de usuario de ID IKE de grupo parcial. Por ejemplo, si el usuario de 

ID IKE de grupo tiene la identidad IKE juniper.net , cualquier usuario con ese nombre de dominio en su ID IKE 

puede iniciar negociaciones IKE de fase 1 en modo dinámico con el dispositivo NetScreen. Por ejemplo: 

alice@juniper.net , bob@juniper.net y carol@juniper.net . El número de usuarios que se pueden conectar 

dependerá del número máximo de sesiones simultáneas especificadas en el perfil de usuario de ID IKE de grupo. 



Ejemplo: ID IKE de grupo (claves previamente compartidas) 

En este ejemplo definirá un nuevo usuario de identificación IKE de grupo llamado User2 . A continuación, 

configurará la definición para que acepte un máximo de 10 negociaciones simultáneas en la fase 1 por parte de 

clientes VPN con claves previamente compartidas que contengan una ID IKE que termine con la cadena 

juniper.net . El valor inicial de la clave previamente compartida es jk930k . El grupo de usuarios IKE de acceso 

telefónico será office_2 . 

Usuario de acceso 

telefónico 

con ID IKE: 

joe@juniper.net 

Tanto para las negociaciones de fase 1 como de fase 2, deberá seleccionar el nivel de seguridad predefinido como 

“Compatible”. Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr. 

WebUI 

1. Interfaces 

Zona Untrust 

Túnel VPN 


Zona Untrust 

ethernet3, 1.1.1.1/24 

puerta de enlace 

1.1.1.250 







Perfil de usuario de 


Nombre de usuario: User2 

Grupo de usuarios: office_2 

ID simple: juniper.net 

Zona Trust 

ethernet1, 10.1.1.1/24 

Modo NAT 

Zona Trust 

web1 

10.1.1.5 




2. Dirección 





3. Usuarios 




Zone: Trust 







IKE Identity: juniper.net 

Objects > User Groups > Local > New: Escriba office_2 en el campo Group Name, realice la acción que se 


Seleccione User2 y utilice el botón


4. VPN 

Nota: La WebUI sólo permite introducir un valor para la clave previamente compartida, pero no un valor 

inicial a partir del cual el dispositivo NetScreen derive una clave previamente compartida. Para introducir 

un valor inicial para clave previamente compartida al configurar una puerta de enlace IKE, debe utilizar la 

interfaz CLI. 


VPN Name: Corp_VPN 


Remote Gateway: Predefined: (seleccione), Corp_GW 

5. Ruta 






6. Directiva 






Service: HTTP 


Tunnel VPN: Corp_VPN 





CLI 

1. Interfaces 






2. Dirección 


3. Usuarios 

set user User2 ike-id u-fqdn juniper.net share-limit 10 

set user-group office_2 user User2 

4. VPN 

set ike gateway Corp_GW dialup office_2 aggressive seed-preshare jk930k 

sec-level compatible 

set vpn Corp_VPN gateway Corp_GW sec-level compatible 

5. Ruta 


6. Directiva 

set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn 

Corp_VPN 

save 



Obtención de la clave previamente compartida 

La clave previamente compartida sólo se puede obtener utilizando el siguiente comando CLI: 

exec ike preshare-gen name_str usr_name_str 

La clave previamente compartida, basada en el valor inicial de clave previamente compartida jk930k (como 

se especificó en la configuración de la puerta de enlace remota llamada Corp_GW ) y la identificación 

completa de usuario individual joe@juniper.net es 11ccce1d396f8f29ffa93d11257f691af96916f2 . 




pantalla. 





Protocol: Seleccione All , escriba HTTP , pulse el tabulador y escriba 80 . 




5. Haga clic en el icono Security Policy, seleccione Aggressive Mode y desactive Enable Perfect Forward 


6. Haga clic en My Identity : Haga clic en Pre-shared Key > Enter Key : Escriba 

11ccce1d396f 8f29 f f a 93d11257f 6 91a f 96916f 2 y haga clic en OK . 

ID Type: (seleccione E-mail Address ) y escriba joe@juniper.net . 




símbolo MÁS situado a la izquierda de Authentication (Phase 1) y Key Exchange (Phase 2) para ampliar 

aún más la directiva. 







9. Haga clic en Authentication (Phase 1) > Create New Proposal : Seleccione los siguientes protocolos 

IPSec: 



Hash Alg: MD5 



IPSec: 






IPSec: 





Hash Alg: MD5 








IPSec: 



Hash Alg: MD5 



IPSec: 






IPSec: 



Hash Alg: MD5 




Capítulo 5 VPNs de acceso telefónico Identificación IKE compartida 

IDENTIFICACIÓN IKE COMPARTIDA 

La función de identificación IKE compartida facilita la implementación de un gran número de usuarios de acceso 

telefónico. Gracias a ella, el dispositivo NetScreen autentica múltiples usuarios VPN de acceso telefónico utilizando 

una única identificación IKE de grupo y clave compartida. De esta forma, proporciona protección IPSec para 

grandes grupos de usuarios remotos por medio de una configuración VPN común. 

Esta función es similar a la identificación IKE de grupo con función de claves previamente compartidas, con las 

siguientes diferencias: 

Con la función de ID IKE de grupo, la ID IKE puede ser una dirección de correo electrónico o un nombre de 

dominio completo (FQDN). Para esta función, la ID IKE debe ser una dirección de correo electrónico. 

En lugar de utilizar el valor inicial de clave previamente compartida y la ID IKE de usuario completa para 

generar una clave previamente compartida para cada usuario, se especifica una única clave previamente 

compartida para todos los usuarios del grupo. 

Debe utilizar XAuth para autenticar los usuarios individuales. 

Para configurar una ID IKE compartida y una clave previamente compartida en el dispositivo NetScreen: 

1. Cree un nuevo usuario de identificación IKE de grupo y especifique cuántos usuarios de acceso telefónico 

podrán utilizar la ID IKE para conectarse. En esta función, utilice una dirección de correo electrónico como 

ID IKE. 

2. Asigne la nueva ID IKE de grupo a un grupo de usuarios de acceso telefónico. 

3. En la configuración VPN de acceso telefónico a LAN AutoKey IKE, cree una puerta de enlace de ID IKE 

compartida. 

4. Defina los usuarios XAuth y habilite XAuth en la puerta de enlace IKE remota. 


Configure un túnel VPN al dispositivo NetScreen utilizando el modo dinámico en las negociaciones de la fase 1 e 

introduzca la clave previamente compartida que definió anteriormente en el dispositivo NetScreen. A continuación, 

éste autenticará cada usuario remoto tal y como se indica a continuación: 



Durante las negociaciones de la fase 1, el dispositivo NetScreen primero autentica el cliente VPN comparando la ID 

IKE y la clave previamente compartida que el cliente envía con la ID IKE y la clave previamente compartida del 

dispositivo NetScreen. Si coinciden, el dispositivo NetScreen utiliza XAuth para autenticar el usuario individual. 

Envía una petición de inicio de sesión al usuario remoto entre las negociaciones IKE de la fase 1 y la fase 2. Si el 

usuario remoto consigue conectarse con el nombre de usuario y la contraseña correctos, comenzarán las 

negociaciones de la fase 2. 

Ejemplo: ID IKE compartida (claves previamente compartidas) 

En este ejemplo crearemos un nuevo usuario de identificación IKE de grupo llamado Remote_Sales. Aceptará 

hasta 250 negociaciones simultáneas de fase 1 desde clientes VPN con la misma clave previamente compartida 

(abcd1234). El nombre del grupo de usuarios IKE de acceso telefónico será R_S . Además, configuraremos dos 

usuarios XAuth, Joe y Mike. 

Tanto para las negociaciones de fase 1 como de fase 2, deberá seleccionar el nivel de seguridad predefinido como 

“Compatible”. Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr. 

Usuario de acceso telefónico 

con 

ID IKE: joe@ns.com 

Contraseña XAuth: 1234 

Zona Untrust 


ethernet3, 1.1.1.1/24 

ethernet1, 10.1.1.1/24 

Modo NAT 

Zona Trust 

Usuario de acceso telefónico 

con 

ID IKE: mike@ns.com 

Contraseña XAuth: 5678 

Túneles VPN 

Perfil de usuario de ID IKE 

compartida 

Nombre de usuario: Remote_Sales 

Grupo de usuarios: R_S 

ID simple: sales@ns.com 

web1 

10.1.1.5 



WebUI 

1. Interfaces 








2. Dirección 





3. Usuarios 




Zone: Trust 


User Name: Remote_Sales 







IKE Identity: sales@ns.com 

Objects > User Groups > Local > New: Escriba R_S en el campo Group Name, realice la acción que se 


Seleccione Remote_sales y utilice el botón Users > Local > New: Introduzca los siguientes datos y haga clic en OK : 

User Name: Joe 


XAuth User: (seleccione) 

Password: 1234 

Confirm Password: 1234 


User Name: Mike 


XAuth User: (seleccione) 

Password: 5678 

Confirm Password: 5678 

4. VPN 


Gateway Name: sales_gateway 

Security Level: Compatible (seleccione) 

Remote Gateway Type: Dialup Group (seleccione), R_S 



Preshared Key: abcd1234 


> Advanced: Introduzca los siguientes datos y haga clic en Return para 

regresar a la página de configuración básica de puerta de enlace: 

Enable XAuth: (seleccione) 

Local Authentication: (seleccione) 

Allow Any: (seleccione) 


5. Ruta 

VPN Name: Sales_VPN 


Remote Gateway: Predefined: (seleccione) sales_gateway 





Network Address / Netmask: 0.0.0.0/0 






6. Directiva 






Service: HTTP 


Tunnel VPN: Sales_VPN 





CLI 

1. Interfaces 






2. Dirección 


3. Usuarios 

set user Remote_Sales ike-id sales@ns.com share-limit 250 

set user-group R_S user Remote_Sales 

set user Joe password 1234 

set user Joe type xauth 

set user Mike password 5678 

set user Mike type xauth 

4. VPN 

set ike gateway sales_gateway dialup R_S aggressive outgoing-interface 

ethernet3 preshare abcd1234 sec-level compatible 

set ike gateway sales_gateway xauth 

set vpn sales_vpn gateway sales_gateway sec-level compatible 

set vpn sales_vpn bind zone untrust-tun 

5. Ruta 

set route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250 

6. Directiva 

set policy top from untrust to trust “Dial-Up VPN” web1 http tunnel vpn sales_vpn 

save 




En este ejemplo se muestra la configuración del usuario Joe. 



pantalla. 



Remote Party ID Type: IP Address 

Dirección IP: 10.1.1.5 


ID Type: IP Address; 1.1.1.1 




6. Haga clic en My Identity : Haga clic en Pre-shared Key > Enter Key : Escriba abcd1234 y haga clic en 

OK . 

ID Type: (seleccione E-mail Address ) y escriba sales@ns.com . 


símbolo MÁS situado a la izquierda de Authentication (Phase 1) y Key Exchange (Phase 2) para ampliar 

aún más la directiva. 



Authentication Method: Pre-Shared Key; Extended Authentication 







IPSec: 



Hash Alg: MD5 



IPSec: 






IPSec: 



Hash Alg: MD5 








IPSec: 





Hash Alg: MD5 



IPSec: 






IPSec: 



Hash Alg: MD5 




Capítulo 6 

L2TP 

6 

Este capítulo proporciona una introducción al protocolo L2TP (Layer 2 Tunneling Protocol), su utilización en solitario 

y con soporte IPSec, y a continuación algunos ejemplos de la configuración de L2TP y L2TP sobre IPSec: 

“Introducción al L2TP” en la página 308 

“Encapsulado y desencapsulado de paquetes” en la página 312 

“Parámetros L2TP” en la página 314 

– “Ejemplo: Configuración de un conjunto de direcciones IP y los ajustes predeterminados L2TP” en la 

página 315 

“L2TP y L2TP sobre IPSec” en la página 317 

– “Ejemplo: Configuración de L2TP” en la página 318 

– “Ejemplo: Configuración de L2TP sobre IPSec” en la página 326 

– “Ejemplo: L2TP bidireccional sobre IPSec” en la página 339 


Capítulo 6 L2TP Introducción al L2TP 

INTRODUCCIÓN AL L2TP 

El protocolo L2TP proporciona a un usuario de acceso telefónico una forma de realizar una conexión con un 

protocolo punto a punto virtual (PPP) a un servidor de red L2TP (LNS), que puede ser un dispositivo NetScreen. 

L2TP envía tramas PPP por un túnel entre un concentrador de acceso L2TP (LAC) y el LNS. 

En origen, L2TP se diseñó para que un LAC residente en un sitio ISP se conectase por túnel a un LNS en el sitio de 

otro ISP o empresa. El túnel L2TP no llega hasta al equipo del usuario de acceso telefónico, sino sólo hasta el LAC 

en el ISP local del usuario de acceso telefónico. (A veces, a esto se le llama configuración L2TP obligatoria). 

Usuario de 

acceso 

telefónico 

Conexión de 

acceso 

telefónico 

ISP 

Internet 

Dispositivo NetScreen 

Concentrador 

de acceso 

L2TP 

(LAC) 

Túnel L2TP 

(reenvío de sesiones PPP 

del LAC al LNS) 

Servidor de red 

L2TP 

(LNS) 

LAN 

de empresa 

Un cliente NetScreen-Remote sobre Windows 2000 o Windows NT, o un cliente Windows 2000 por sí mismo, 

puede actuar como un LAC. El túnel L2TP puede llegar directamente hasta el equipo del usuario de acceso 

telefónico, proporcionando así un encapsulado de protocolos punto a punto. (A veces, a esta solución se le llama 

configuración L2TP voluntaria). 




o Windows 2000 

(LAC) 

ISP 

Internet 

Debido a que el enlace PPP va desde el usuario de acceso telefónico a través de Internet hasta el dispositivo 

NetScreen (LNS), es el dispositivo NetScreen y no el ISP quien asigna al cliente su dirección IP, las direcciones de 

los servidores DNS y WINS, y autentica al usuario, bien desde la base de datos local o desde un servidor de 

autenticado externo (RADIUS, SecurID, o LDAP). 

De hecho, el cliente recibe dos direcciones IP, una para su conexión física al ISP, y otra lógica procedente del LNS. 

Cuando el cliente se conecta a su ISP, por ejemplo utilizando el protocolo PPP, el ISP realiza las asignaciones de 

IP y DNS, y autentica al cliente. Esto permite a los usuarios conectarse a Internet con una dirección IP pública, que 

se convierte en la dirección IP externa del túnel L2TP. 

En primer lugar, el ISP asigna al 

cliente una dirección IP pública y las 

direcciones de los servidores DNS. 

1 

Túnel L2TP 

(reenvío de sesiones PPP 

del LAC al LNS) 


DNS: 6.6.6.6, 7.7.7.7 

Dispositivo 


(LNS) 

LAN 

de empresa 


ISP


Después, cuando el túnel L2TP envía las tramas PPP encapsuladas al dispositivo NetScreen, éste asigna al cliente 

una dirección IP y los ajustes de DNS y WINS. La dirección IP puede ser del conjunto de direcciones privadas no 

utilizables en Internet. Ésta se convierte en la dirección IP interna del túnel L2TP. 

En segundo lugar, el dispositivo NetScreen, actuando 

como LNS, asigna al cliente una dirección IP privada 

(lógica), y las direcciones de los servidores DNS y WINS. 

2 


DNS: 10.1.1.10, 1.2.2.10 

WINS: 10.1.1.48, 10.1.1.49 

Internet 


(LNS) 

Conjunto de direcciones IP 

10.10.1.1 – 10.10.1.254 

LAN de empresa 

10.1.1.0/24 

Nota: Las direcciones IP asignadas al cliente L2TP deben estar en una subred diferente de la de las direcciones IP 

en la LAN corporativa. 



La versión actual de ScreenOS proporciona el siguiente soporte al L2TP: 

Túneles L2TP con origen en un host con Windows 2000 1 

Combinación de L2TP e IPSec en modo de transporte (L2TP sobre IPSec) 

– Para NetScreen-Remote: L2TP sobre IPSec con negociaciones en modo principal utilizando 

certificados, y en modo dinámico utilizando una clave previamente compartida o certificados 

– Para Windows 2000: L2TP sobre IPSec, con negociaciones en modo principal que utilizan certificados 

Directiva de acceso telefónico saliente para túneles L2TP y L2TP sobre IPSec. Una directiva de acceso 

telefónico saliente se puede emparejar con una entrante para proporcionar un túnel bidireccional. 

Autenticación de usuario utilizando PAP (Password Authentication Protocol) y CHAP (Challenge 

Handshake Authentication Protocol) desde la base de datos local o un servidor externo de autenticado 

(RADIUS, SecurID, o LDAP) 

Nota: La base de datos local y los servidores RADIUS son compatibles con PAP y CHAP SecurID y los 

servidores LDAP sólo son compatibles con PAP. 

Asignación de las direcciones IP de los usuarios, los servidores DNS (Domain Name System), y los 

servidores WINS (Windows Internet Naming Service) desde la base de datos local o un servidor RADIUS 

Túneles L2TP y L2TP sobre IPSec para el sistema raíz y los sistemas virtuales 

Nota: Para utilizar el L2TP, el dispositivo NetScreen debe operar en la capa 3, con interfaces de la zona de 

seguridad en modo NAT o de ruta. Cuando el dispositivo NetScreen opera en la capa 2, con interfaces de 

la zona de seguridad en modo transparente, no aparece información relacionada con el L2TP en el WebUI, 

y los comandos CLI relativos al L2TP provocan mensajes de error. 

1. De forma predeterminada, Windows 2000 realiza L2TP sobre IPSec. Para forzarlo a utilizar sólo L2TP, debe dirigirse a la clave ProhibitIPSec en el registro 

y cambiar 0 (L2TP sobre IPSec) por 1 (sólo L2TP ). (Antes de hacerlo, Juniper Networks recomienda hacer una copia de seguridad del registro.) Haga clic 

en Inicio > Ejecutar : Escriba regedit . Haga doble click en HKEY_LOCAL_MACHINE > System > CurrentControlSet > Services > RasMan > 

Parameters . Haga doble clic en ProhibitIPSec : Escriba 1 en el campo Value data, seleccione Hexadecimal como base de numeración, y después haga 

clic en OK . Reinicie. (Si no encuentra esta entrada en el registro, consulte la documentación de Microsoft Windows para obtener información sobre cómo 

crear una). 


Capítulo 6 L2TP Encapsulado y desencapsulado de paquetes 

ENCAPSULADO Y DESENCAPSULADO DE PAQUETES 

L2TP emplea el encapsulado de paquetes como forma de transportar tramas PPP desde el LAC hasta el LNS. 

Antes de ver ejemplos específicos de configuración del L2TP y el L2TP sobre IPSec, se muestra un resumen del 

encapsulado y desencapsulado implicados en el proceso L2TP. 

Encapsulado 

Cuando un usuario de acceso telefónico dentro de una red IP envía datos por un túnel L2TP, el LAC encapsula el 

paquete IP dentro de una serie de tramas de la capa 2, paquetes de la capa 3, y segmentos de la capa 4. 

Suponiendo que el usuario de acceso telefónico se conecte al ISP local por un enlace PPP, el encapsulado será 

como se indica a continuación: 

1. Los datos se ubican en la carga de la trama IP. 

2. El paquete IP se encapsula en una trama PPP. 

3. La trama PPP se encapsula en una trama L2TP. 

4. La trama L2TP se encapsula en un segmento UDP. 

5. El segmento UDP se encapsula en un paquete IP. 

6. El paquete IP se encapsula en una trama PPP para realizar la conexión física entre el usuario de acceso 

telefónico y el ISP. 


Capítulo 6 L2TP Encapsulado y desencapsulado de paquetes 

Desencapsulado 

Cuando el LAC inicia el enlace PPP hacia el ISP, el desencapsulado y reenvío del contenido anidado será como se 

indica a continuación: 

ISP 

LNS 

1. El ISP finaliza el enlace PPP y asigna una dirección IP al equipo del usuario. 

En la carga PPP hay un paquete IP. 

2. El ISP quita el encabezado PPP y reenvía el paquete IP al LNS. 

3. El LNS quita el encabezado IP. 

En la carga IP hay un segmento UDP que especifica el puerto 1701, el número del puerto reservado para 

L2TP. 

4. El LNS quita el encabezado UDP. 

En la carga UDP hay una trama L2TP. 

5. El LNS procesa la trama L2TP, utilizando los datos tunnel ID y call ID del encabezado L2TP para identificar 

el túnel L2TP concreto. Después, el LNS quita el encabezado L2TP. 

En la carga L2TP hay una trama PPP. 

6. El LNS procesa la trama PPP, y asigna una dirección lógica IP al equipo del usuario. 

En la carga PPP hay un paquete IP. 

7. El LNS enruta el paquete IP hacia su último destino, donde el encabezado IP se elimina y los datos se 

extraen del paquete IP. 


Capítulo 6 L2TP Parámetros L2TP 

PARÁMETROS L2TP 

El LNS utiliza L2TP para proporcionar los ajustes PPP para un usuario de acceso telefónico que habitualmente 

proviene de un ISP. Estos ajustes son los siguientes: 

Dirección IP: el dispositivo NetScreen selecciona una dirección de un conjunto de direcciones IP y la asigna 

al equipo del usuario de acceso telefónico. El proceso de selección recorre cíclicamente el conjunto de 

direcciones IP, esto es, en el grupo desde 10.10.1.1 hasta 10.10.1.3, las direcciones se seleccionan 

siguiendo el ciclo que se indica: 10.10.1.1 – 10.10.1.2 – 10.10.1.3 – 10.10.1.1 – 10.10.1.2 … 

Direcciones IP de los servidores DNS primario y secundario: el dispositivo NetScreen proporciona estas 

direcciones para uso del equipo del usuario de acceso telefónico. 

Direcciones IP del servidor WINS primario y secundario: el dispositivo NetScreen también proporciona 

estas direcciones para uso del equipo del usuario de acceso telefónico. 

El LNS también autentica al usuario mediante un nombre de usuario y una contraseña. Se pueden introducir los 

datos del usuario en la base de datos local o en un servidor externo de autenticado (RADIUS, SecurID, o LDAP). 

Nota: El servidor RADIUS o SecurID que se utiliza para autenticar a los usuarios L2TP puede ser el mismo 

servidor utilizado para los usuarios de red, u otro diferente. 

Además, puede especificar uno de los siguientes esquemas para la autenticación PPP: 

Challenge Handshake Authentication Protocol (CHAP), en el que el dispositivo NetScreen envía un desafío 

(clave de cifrado) al usuario de acceso telefónico después de que éste haya hecho una petición de enlace 

PPP, y el usuario cifra su nombre de usuario y contraseña con la clave. La base de datos local y los 

servidores RADIUS soportan CHAP. 

Password Authentication Protocol (PAP), que envía la contraseña del usuario de acceso telefónico sin 

codificar junto con la petición de enlace PPP. La base de datos local y los servidores RADIUS, SecurID, y 

LDAP soportan PAP. 

“ANY”, lo que significa que el dispositivo NetScreen negocia el CHAP, y si éste falla, entonces el PAP. 



Puede aplicar a los usuarios o grupos de usuarios de acceso telefónico los parámetros predeterminados L2TP que 

se configuran en la página básica de configuración de L2TP (VPNs > L2TP > Default Settings) o con el comando 

set l2tp default . También puede aplicar los parámetros L2TP que se configuran específicamente para los usuarios 

L2TP en la página de configuración de usuario (Users > Users > Local > New) o con el comando set user name_str 

remote-settings . Los ajustes específicos de usuario L2TP reemplazan a los ajustes predeterminados L2TP. 

Ejemplo: Configuración de un conjunto de direcciones IP y los ajustes 

predeterminados L2TP 

En este ejemplo, se define un conjunto de direcciones IP en un rango de 10.1.3.40 a 10.1.3.100. Se especifican las 

direcciones IP de los servidores DNS 1.1.1.2 (primario) y 1.1.1.3 (secundario). El dispositivo NetScreen realiza la 

autenticación PPP mediante CHAP. 

Nota: Especifique el servidor de autenticación para cada túnel L2TP. 

Zona 

Trust 

RADIUS 

10.1.1.245 

Zona 

Untrust 

DNS 1 

1.1.1.2 

Nota: El conjunto de direcciones 

L2TP debe pertenecer a una 

subred distinta de la de la zona 

Trust. 

Internet 

DNS 2 

1.1.1.3 

ethernet1, 

10.1.1.1/24 

Conjunto de direcciones 

IP L2TP 

10.1.3.40 – 10.1.3.100 

ethernet3, 

1.1.1.1/24 



WebUI 

1. Conjunto de direcciones IP 

Objects > IP Pools > New: Introduzca los siguientes datos y haga clic en OK : 

2. Ajustes predeterminados de L2TP 

CLI 

IP Pool Name: Sutro 

Start IP: 10.1.3.40 

End IP: 10.1.3.100 

VPNs > L2TP > Default Settings: Introduzca los siguientes datos y haga clic en Apply : 


IP Pool Name: Sutro 

PPP Authentication: CHAP 

DNS Primary Server IP: 1.1.1.2 

DNS Secondary Server IP: 1.1.1.3 

WINS Primary Server IP: 0.0.0.0 

WINS Secondary Server IP: 0.0.0.0 

set ippool sutro 10.1.3.40 10.1.3.100 


set l2tp default ippool sutro 

set l2tp default ppp-auth chap 

set l2tp default dns1 1.1.1.2 


save 


Capítulo 6 L2TP L2TP y L2TP sobre IPSec 

L2TP Y L2TP SOBRE IPSEC 

Aunque el usuario de acceso telefónico puede ser autenticado mediante CHAP o PAP, el túnel L2TP no está 

encriptado, y por tanto no es un túnel VPN auténtico. El objetivo del L2TP es simplemente permitir al administrador 

del dispositivo NetScreen local la asignación de direcciones IP a un usuario de acceso telefónico remoto, de forma 

que sea posible introducir referencias a estas direcciones en las directivas. 

Para encriptar un túnel L2TP, es necesario aplicarle un esquema de encriptación. Puesto que L2TP supone que la 

red entre el LAC y el LNS es IP, se puede utilizar IPSec para proporcionar la encriptación. Esta combinación se 

llama L2TP sobre IPSec. L2TP sobre IPSec requiere el establecimiento de un túnel L2TP y otro IPSec ambos con 

los mismos extremos, y después enlazarlos en una directiva. L2TP sobre IPSec requiere que el túnel IPSec esté en 

modo de transporte para que la dirección del extremo del túnel quede sin codificar. (Para obtener información sobre 

el modo de transporte y el modo de túnel, consulte “Modos” en la página 4.) 

Se puede crear un túnel L2TP entre un dispositivo NetScreen y un host con Windows 2000 si se cambian los 

ajustes del registro de Windows 2000. (Para ver las instrucciones de como cambiar el registro, consulte la nota al 

pie de la página 311.) 

Se puede crear un túnel L2TP sobre IPSec entre un dispositivo NetScreen y cualquiera de los siguientes clientes 

VPN: 

Un host que ejecute NetScreen-Remote en los sistemas operativos Windows 2000 o Windows NT 

Un host que ejecute Windows 2000 (sin NetScreen-Remote) 2 

2. Para proporcionar autenticación cuando se utiliza Windows 2000 sin NetScreen-Remote, se deben utilizar certificados. 



Ejemplo: Configuración de L2TP 

En este ejemplo, se crea un grupo de usuarios de acceso telefónico llamado “fs” (de “field-sales”) y se configura un 

túnel L2TP llamado “sales_corp”, utilizando ethernet3 (zona Untrust) como interfaz de salida de túnel L2TP. El 

dispositivo NetScreen aplica los siguientes ajustes del túnel L2TP predeterminados al grupo de usuarios de acceso 

telefónico. 

Los usuarios L2TP se autentican a través de la base de datos local. 

La autenticación PPP utiliza CHAP. 

El rango del conjunto de direcciones IP (denominado “global”) es de 10.10.2.100 a 10.10.2.180 3 . 

Los servidores DNS son 1.1.1.2 (primario) y 1.1.1.3 (secundario). 

Nota: Una configuración con sólo L2TP no es segura. Se recomienda sólo para depuración. 

Autenticado/L2TP grupo de 

usuarios de acceso telefónico: fs 

Adam 

Betty 

Carol 

Zona 

Untrust 

Túnel L2TP: 

sales_corp 

Internet 

DNS 1: 1.1.1.2 

DNS 2: 1.1.1.3 


ethernet3, 1.1.1.1/24 

Conjunto de 

direcciones IP: global 

10.10.2.100 – 

10.10.2.180 

ethernet1, 

10.1.1.1/24 

Los clientes remotos L2TP van sobre el sistema operativo Windows 2000. Para obtener información sobre la 

configuración del L2TP en los clientes remotos, consulte la documentación de Windows 2000. A continuación se 

proporciona sólo la configuración del dispositivo NetScreen al final del túnel L2TP. 

3. El conjunto de direcciones IP de L2TP debe pertenecer a una subred distinta de la de las direcciones de la red corporativa. 

Red 

corporativa 

Zona Trust 



WebUI 

1. Interfaces 








2. Usuarios L2TP 





User Name: Adam 


L2TP User: (seleccione) 

User Password: AJbioJ15 

Confirm Password: AJbioJ15 




User Name: Betty 



User Password: BviPsoJ1 

Confirm Password: BviPsoJ1 


3. Grupo de usuarios L2TP 

User Name: Carol 



User Password: Cs10kdD3 

Confirm Password: Cs10kdD3 

Objects > User Groups > Local > New: Escriba fs en el campo Group Name, haga lo siguiente, y luego 

haga clic OK : 

Seleccione Adam y utilice el botón




IP Pool Name: global 

Start IP: 10.10.2.100 

End IP: 10.10.2.180 

VPNs > L2TP > Default Settings: Introduzca los siguientes datos y haga clic en OK : 

5. Túnel L2TP 







VPNs > L2TP > Tunnel > New: Introduzca los siguientes datos y haga clic en OK : 

Name: sales_corp 

Use Custom Settings: (seleccione) 

Authentication Server: Local 

Dialup Group: Local Dialup Group - fs 




Peer IP: 0.0.0.0 4 

Host Name (optional): Introduzca el nombre del equipo que actúa como 

LAC 5 . 

Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS. 

Nota: Para añadir un secreto al LAC para autenticar el túnel L2TP, se debe modificar el registro de 

Windows 2000 de la siguiente forma: 

(1) Haga clic en Inicio > Ejecutar , y luego escriba regedit . Se abre el editor del registro. 

(2) Haga clic en HKEY_LOCAL_MACHINE . 

(3) Haga clic con el botón secundario en SYSTEM , y luego seleccione Buscar en el menú emergente 

que aparece. 

(4) Escriba ms_l2tpminiport , y luego haga clic en Buscar siguiente . 

(5) En el menú Edición, resalte la opción Nuevo , y luego seleccione Valor de cadena. 

(6) Escriba Contraseña . 

(7) Haga doble clic en Contraseña . Aparece el cuadro de diálogo de edición de cadena. 

(8) Escriba la contraseña en el campo “Value” data. Debe coincidir con la palabra introducida en el 

campo L2TP Tunnel Configuration Secret en el dispositivo NetScreen. 

(9) Reinicie el equipo Windows 2000. 

Cuando se utiliza L2TP sobre IPSec, que es la opción predeterminada de Windows 2000, no es necesaria 

la autenticación del túnel; todos los mensajes L2TP son encriptados y autenticados por IPSec. 

Keep Alive: 60 6 

4. Debido a que el ISP del interlocutor le asigna dinámicamente una dirección IP, introduzca aquí 0.0.0.0 . 

5. Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo siguiente: Haga clic en Inicio > Configuración > Panel de Control > Sistema . 

Aparece el cuadro de diálogo de propiedades del sistema. Haga clic en la ficha de Identificación de red , y consulte la entrada Nombre completo del 

equipo . 

6. El valor Keep Alive (mantenimiento de conexión) es el número de segundos de inactividad antes de que el dispositivo NetScreen envíe una señal Hello 

L2TP al LAC. 



6. Ruta 

Network > Routing > Routing Entries > New: Introduzca los siguientes datos y haga clic en OK : 

7. Directiva 









Address Book Entry: (seleccione), Any 

NAT: Off 

Service: ANY 


Tunnel L2TP: sales_corp 




CLI 

1. Usuarios de acceso telefónico 

set user adam type l2tp 

set user adam password AJbioJ15 

unset user adam type auth 7 

set user betty type l2tp 

set user betty password BviPsoJ1 

unset user betty type auth 

set user carol type l2tp 

set user carol password Cs10kdD3 

unset user carol type auth 

2. Grupo de usuarios L2TP 

set user-group fs location local 

set user-group fs user adam 

set user-group fs user betty 

set user-group fs user carol 


set ippool global 10.10.2.100 10.10.2.180 

set l2tp default ippool global 

set l2tp default auth server Local 




7. Definir una contraseña para un usuario le clasifica automáticamente como un usuario autenticado. Por lo tanto, para definir el tipo de usuario como L2TP 

en sentido estricto, se debe desactivar el tipo de usuario autenticado. 




set l2tp sales_corp outgoing-interface ethernet3 

set l2tp sales_corp auth server Local user-group fs 

5. Ruta 


6. Directiva 

set policy top from untrust to trust “Dial-Up VPN” any any tunnel l2tp 

sales_corp 

save 



Ejemplo: Configuración de L2TP sobre IPSec 

Este ejemplo utiliza el tunel L2TP creado en el ejemplo anterior (“Ejemplo: Configuración de L2TP” en la página 

318). Además, se superpone un túnel IPSec al túnel L2TP para proporcionar encriptación. El túnel IPSec negocia la 

fase 1 en modo agresivo utilizando un certificado RSA previamente cargado, cifrado 3DES y autenticación SHA-1. 

La autoridad de certificación (CA) será Verisign. (Para más información sobre cómo obtener y cargar certificados, 

consulte el Capítulo 2, “Criptografía de claves públicas” en la página 23.) La negociación de fase 2 utiliza el nivel de 

seguridad predefinido como “Compatible” para las propuestas de fase 2. El túnel IPSec está en modo de transporte. 

La zona Trust predefinida y la zona de acceso telefónico definida por el usuario se encuentran en el dominio de 

enrutamiento trust-vr. Las interfaces para las zonas de acceso telefónico y Trust son ethernet2 (1.3.3.1/24) y 

ethernet1 (10.1.1.1/24) respectivamente. La zona Trust está en modo NAT. 

Los usuarios de acceso telefónico Adam, Betty y Carol utilizan clientes NetScreen-Remote sobre un sistema 

operativo Windows 2000 8 . La configuración del NetScreen-Remote para el usuario de acceso telefónico Adam 

también se incluye en lo que sigue. (La configuración del NetScreen-Remote para los otros dos usuarios de acceso 

telefónico es la misma que para Adam.) 

IKE-L2TP 

Grupo de usuarios de acceso telefónico: fs 

Betty 

Adam 

Carol 

Clientes 


Zona de 

acceso 

telefónico 

Internet 

Túnel L2TP: sales_corp 

Túnel VPN: from_sales 

DNS 1: 1.1.1.2 

DNS 2: 1.1.1.3 


ethernet2, 1.3.3.1/24 

Conjunto de 

direcciones IP: global 

10.10.2.100 – 

10.10.2.180 

ethernet1, 

10.1.1.1/24 

Red 

corporativa 

Zona Trust 

8. Para configurar un túnel L2TP sobre IPSec para Windows 2000 (sin NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y el 

tipo de identificación IKE debe ser ASN1-DN. 



WebUI 

1. Zona definida por el usuario 

Network > Zones > New: Introduzca los siguientes datos y haga clic en OK: 

Zone Name: Dialup 

Virtual Router Name: trust-vr 

Zone Type: Layer 3 (seleccione) 

Block Intra-Zone Traffic: (seleccione) 

TCP/IP Reassembly for ALG: (anule la selección) 

Nota: La zona Trust está preconfigurada. No es necesario crearla. 

2. Interfaces 








Zone Name: Dialup 





3. Usuarios IKE/L2TP 


User Name: Adam 



Simple Identity: (seleccione) 9 

IKE Identity: ajackson@abc.com 


User Password: AJbioJ15 

Confirm Password: AJbioJ15 


User Name: Betty 




IKE Identity: bdavis@abc.com 


User Password: BviPsoJ1 

Confirm Password: BviPsoJ1 

9. La ID IKE debe ser la misma que la que envía el cliente NetScreen-Remote, que es la dirección de correo electrónico que aparece en el certificado que el 

cliente utiliza para la autenticación. 




4. Grupo de usuarios IKE/L2TP 

User Name: Carol 




IKE Identity: cburnet@abc.com 


User Password: Cs10kdD3 

Confirm Password: Cs10kdD3 

Objects > User Groups > Local > New: Escriba fs en el campo Group Name, haga lo siguiente, y luego haga 

clic OK : 

Seleccione Adam y utilice el botón






Start IP: 10.10.2.100 

End IP: 10.10.2.180 

VPNs > L2TP > Default Settings: Introduzca los siguientes datos y haga clic en Apply : 











Name: sales_corp 

Dialup Group: (seleccione) Local Dialup Group - fs 

Authentication Server: Local 


Peer IP: 0.0.0.0 10 

Host Name (optional): Si quiere restringir el túnel L2TP a un host específico, 

introduzca el nombre del equipo que actúa como LAC 11 . 

Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS 12 

Keep Alive: 60 13 

10. Debido a que la dirección IP del interlocutor es dinámica, introduzca aquí 0.0.0.0 . 

Nota: El nombre del host y los ajustes del secreto puede que sean 

desconocidos. Se recomienda que sólo los usuarios avanzados utilicen 

estos ajustes. 

11. Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo siguiente: Haga clic en Inicio > Configuración > Panel de control > Sistema . 

Aparece el cuadro de diálogo de propiedades del sistema. Haga clic en la ficha de Identificación de red , y consulte la entrada Nombre completo del 

equipo . 

12. Para añadir un secreto al LAC para autenticar el túnel L2TP, se debe modificar el registro de Windows 2000 de la siguiente forma: Consulte la nota del 

ejemplo anterior. 

13. El valor Keep Alive es el número de segundos de inactividad antes de que el dispositivo NetScreen envíe una señal Hello L2TP al LAC. 



8. Túnel VPN 


Gateway Name: field 



Dialup User Group: (seleccione), Group: fs 




enlace: 

Security Level: User Defined: Custom 

Phase 1 Proposal: rsa-g2-3des-sha 

Mode (Initiator): Aggressive 14 





Name: from_sales 


Remote Gateway: Predefined: field 




Transport Mode: (seleccione) 

14. Windows 2000 (sin NetScreen-Remote) sólo admite negociaciones en modo principal. 



9. Directiva 

Policies > (From: Dialup, To: Trust) New: Introduzca los siguientes datos y haga clic en OK : 





Service: ANY 


Tunnel VPN: from_sales 


L2TP: sales_corp 




CLI 

1. Zona definida por el usuario 

set zone name dialup 

set zone dialup vrouter trust-vr 

set zone dialup block 

2. Interfaces 




set interface ethernet2 zone dialup 


3. Usuarios L2TP/IKE 

set user adam type ike l2tp 

set user adam password AJbioJ15 

unset user adam type auth 

set user adam ike-id u-fqdn ajackson@abc.com 

set user betty type ike l2tp 

set user betty password BviPsoJ1 

unset user betty type auth 

set user betty ike-id u-fqdn bdavis@abc.com 

set user carol type ike l2tp 

set user carol password Cs10kdD3 

unset user carol type auth 

set user carol ike-id u-fqdn cburnet@abc.com 



4. Grupo de usuarios IKE/L2TP 

set user-group fs location Local 

set user-group fs user adam 

set user-group fs user betty 

set user-group fs user carol 


set ippool global 10.10.2.100 10.10.2.180 


set l2tp default ippool global 





set l2tp sales_corp outgoing-interface ethernet2 

set l2tp sales_corp auth server Local user-group fs 

8. Túnel VPN 

set ike gateway field dialup fs aggressive 15 outgoing-interface ethernet2 


set ike gateway field cert peer-ca1 16 

set ike gateway field cert peer-cert-type x509-sig 

set vpn from_sales gateway field transport sec-level compatible 

9. Directiva 

set policy top from dialup to trust “Dial-Up VPN” any any tunnel vpn from_sales 

l2tp sales_corp 

save 

15. Windows 2000 (sin NetScreen-Remote) sólo admite negociaciones en modo principal. 




Editor de directivas de seguridad de NetScreen-Remote (Adam 17 ) 


2. Haga clic en Add a new connection y escriba AJ junto al icono de nueva conexión que aparecerá en 

pantalla. 





Protocol: UDP 

Port: L2TP 

Connect using Secure Gateway Tunnel: (anule la selección) 

4. Haga clic en el signo MÁS situado a la izquierda del icono de AJ para ampliar la directiva de la conexión. 

5. Haga clic en My Identity y configure lo siguiente: 

Seleccione el certificado con la dirección de correo electrónico especificada 

como ID IKE del usuario en el dispositivo NetScreen en la lista desplegable 

Select Certificate. 

ID Type: Dirección de correo electrónico 18 

Port: L2TP 

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode . 




17. Para configurar los túneles L2TP sobre IPSec para los clientes NetScreen-Remote de Betty y Carol, siga el procedimiento que aquí se describe para Adam. 







(o bien) 








Encapsulation: Transport 


IPSec: 



Hash Alg: MD5 



IPSec: 








IPSec: 




Hash Alg: MD5 


14. También es necesario configurar la conexión de red para Windows 2000 utilizando el asistente para 

conexión de red. 

Nota: Cuando se configura el asistente para conexión de red, se debe introducir un nombre de host 

destino o una dirección IP. Introduzca 1.3.3.1. Posteriormente, cuando inicie la conexión y reciba una 

petición de nombre de usuario y contraseña, introduzca adam, AJbioJ15. Para más información, consulte 

la documentación de Microsoft Windows 2000. 



Ejemplo: L2TP bidireccional sobre IPSec 

En este ejemplo, ethernet1 (10.1.1.1/24) es la interfaz de la zona Trust y se encuentra en modo NAT, mientras que 

ethernet3 (1.1.1.1/24) es la interfaz de la zona Untrust. Usted creará túneles L2TP sobre IPSec entre un usuario de 

acceso telefónico NetScreen-Remote y una LAN corporativa. El usuario remoto trabaja con una aplicación 

X-Windows, lo que requiere establecer directivas bidireccionales. 

Configurará las directivas entrantes y salientes para el túnel VPN de acceso telefónico AutoKey IKE denominado 

VPN_dial para el usuario IKE dialup-j con la ID de IKE jf@ns.com. y el túnel L2TP denominado tun1. El usuario IKE 

inicia una conexión IPSec al dispositivo NetScreen desde la zona Untrust para acceder a los servidores 

corporativos de la zona Trust. En este punto, solamente se permite la comunicación L2TP. Después de la 

negociación L2TP/PPP, se establece el túnel L2TP. Con las directivas bidireccionales configuradas, el tráfico puede 

iniciarse desde cualquier extremo del túnel. 

El usuario de acceso telefónico dialup-j utiliza un cliente NetScreen-Remote con el sistema operativo Windows 

2000 19 . La configuración de NetScreen-Remote para el usuario de acceso telefónico dialup-j aparece después de 

este ejemplo. 

Cliente de NetScreen-Remote 

ejecutando X-Windows Server 

Zona de acceso 

telefónico 

Internet 

Túnel L2TP sobre 

IPSec 

ethernet3 

1.1.1.1/24 

Enrutador externo 

1.1.1.250 

ethernet1 

10.1.1.1/24 

Zona Trust 

Servidor Unix 

19. Para configurar un túnel L2TP sobre IPSec para Windows 2000 (sin NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y el 

tipo de identificación IKE debe ser ASN1-DN. 


LAN


WebUI 

1. Interfaces 








2. Dirección 





Address Name: trust_net 



Zone: Trust 



3. Usuario L2TP/IKE 

4. L2TP 


User Name: dialup-j 



Simple Identity: (seleccione) 20 

IKE Identity: jf@ns.com 

Authentication User: (seleccione) 


User Password: abc123 

Confirm Password: abc123 


Name: tun1 

Use Default Settings: (seleccione) 

Secret: netscreen 

Keepalive: 60 

20. La ID IKE debe ser la misma que la que envía el cliente NetScreen-Remote, que es la dirección de correo electrónico que aparece en el certificado que el 

cliente utiliza para la autenticación. 



5. VPN 



Security Level: (seleccione); Standard 

Remote Gateway Type: Dialup User; (seleccione), dialup-j 

Preshared Key: n3TsCr33N 

Outgoing Interface: (seleccione) ethernet3 


regresar a la página de configuración básica de la puerta de enlace 

AutoKey IKE: 


Enable NAT-Traversal: (seleccione) 

UDP Checksum: (seleccione) 

Keepalive Frequency: 5 


VPN Name: VPN_dial 

Remote Gateway: Predefined: (seleccione), dialup1 


regresar a la página de configuración básica de AutoKey IKE: 

Security Level: Standard (seleccione) 

Transport Mode (sólo para L2TP sobre IPSec): (seleccione) 



6. Ruta 

Network > Routing > Routing Entries > New: Introduzca los siguientes datos y haga clic en OK : 

7. Directivas 










Service: ANY 


Tunnel VPN: VPN_dial 


L2TP: (seleccione) tun1 






Service: ANY 



CLI 

1. Interfaces 


Tunnel VPN: VPN_dial 


L2TP: tun1 






2. Dirección 

set address trust trust_net 10.1.1.0/24 

3. Usuario L2TP/IKE 

set user dialup-j ike-id u-fqdn jf@ns.com 

set user dialup-j type auth ike l2tp 

set user dialup-j password abc123 

4. L2TP 

set l2tp tun1 outgoing-interface ethernet3 secret "netscreen" keepalive 60 

5. VPN 

set ike gateway dialup1 dialup "dialup-j" aggressive outgoing-interface 

ethernet3 preshare n3TsCr33N sec-level standard 

set ike gateway dialup1 nat-traversal udp-checksum 

set ike gateway dialup1 nat-traversal keepalive-frequency 5 

set vpn VPN_dial gateway dialup1 no-replay transport idletime 0 sec-level 

standard 



6. Ruta 


7. Directivas 

set policy from untrust to trust “Dial-Up VPN” “trust_net” any tunnel vpn 

VPN_dial tun1 

set policy from trust to untrust trust_net “Dial-Up VPN” any tunnel vpn 

VPN_dial l2tp tun1 

save 



Editor de directivas de seguridad de NetScreen-Remote (para el usuario dialup-j) 


2. Haga clic en Add a new connection y escriba dialup-j junto al icono de nueva conexión que aparecerá en 

pantalla. 




IP Address: 1.1.1.1 

Protocol: UDP 

Port: L2TP 

Connect using Secure Gateway Tunnel: (anule la selección) 

4. Haga clic en el signo MÁS situado a la izquierda del icono de dialup-j para ampliar la directiva de la 

conexión. 

5. Haga clic en My Identity y configure lo siguiente: 

Seleccione el certificado con la dirección de correo electrónico especificada 

como ID IKE del usuario en el dispositivo NetScreen en la lista desplegable 

Select Certificate. 

ID Type: Dirección de correo electrónico 21 

Port: L2TP 

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode . 










(o bien) 



Key Group: Diffie-Hellman Group 2 22 







IPSec: 



Hash Alg: MD5 



IPSec: 



22. Si la opción Perfect Forwarding Secrecy (PFS) está activada en el dispositivo NetScreen (grupo DF 1, 2 o 5), también debe estar activada para el cliente 

VPN en NetScreen-Remote. 






IPSec: 




Hash Alg: MD5 


También es necesario configurar la conexión de red para Windows 2000 utilizando el asistente para conexión de 

red. 

Nota: Cuando se configura el asistente para conexión de red, se debe introducir un nombre de host destino o una 

dirección IP. Introduzca 1.1.1.1. Posteriormente, cuando inicie la conexión y se le solicite el nombre de usuario y la 

contraseña, introduzca dialup-j, abc123. Para más información, consulte la documentación de Microsoft Windows 

2000. 


Capítulo 7 

Funciones de VPN avanzadas 

En este capítulo se tratan algunos usos más avanzados de la tecnología VPN: 

“NAT-Traversal” en la página 351 

– “Atravesar un dispositivo NAT” en la página 354 

– “Suma de comprobación de UDP” en la página 357 

– “Paquetes de mantenimiento de conexión” en la página 357 

– “Simetría iniciador/respondedor” en la página 358 

“Supervisión de VPNs” en la página 361 

– “Opciones de reencriptación y optimización” en la página 362 

– “Interfaz de origen y dirección de destino” en la página 363 

– “Consideraciones sobre directivas” en la página 365 

– “Configuración de la función de supervisión de VPN” en la página 365 

– “Objetos y capturas SNMP para la supervisión de VPN” en la página 380 

“Múltiples túneles por interfaz de túnel” en la página 381 

– “Asignación de rutas a túneles” en la página 382 

– “Direcciones de interlocutores remotos” en la página 383 

– “Entradas de tabla manuales y automáticas” en la página 385 

“Puertas de enlace VPN redundantes” en la página 441 

– “Grupos VPN” en la página 442 

– “Mecanismos de supervisión” en la página 443 

– “Comprobación de flag TCP SYN” en la página 447 

7 


Capítulo 7 Funciones de VPN avanzadas 

“VPNs adosadas” en la página 460 

– “Ejemplo: VPNs adosadas” en la página 461 

“VPNs radiales” en la página 471 

– “Ejemplo: VPNs radiales” en la página 472 


Capítulo 7 Funciones de VPN avanzadas NAT-Traversal 

NAT-TRAVERSAL 

Los estándares de Internet NAT (Network Address Translation ) y NAPT (Network Address Port Translation) 

permiten que una red de área local (LAN) utilice un grupo de direcciones IP para el tráfico interno y un segundo 

grupo de direcciones para el tráfico externo. Los dispositivos NAT generan estas direcciones externas utilizando 

conjuntos predeterminados de direcciones IP. 

Cuando se configura un túnel IPSec, la presencia de un dispositivo NAT en la ruta de datos no afecta a las 

negociaciones IKE de fase 1 y fase 2, que siempre encapsulan paquetes IKE dentro de segmentos UDP (User 

Datagram Protocol). Sin embargo, si se aplica NAT a los paquetes IPSec una vez finalizadas las negociaciones de 

fase 2, el túnel fallará. Una de las muchas razones por las que NAT provoca el fallo de IPSec 1 es que en el 

protocolo ESP (Encapsulating Security Protocol), los dispositivos NAT no pueden distinguir la ubicación del 

encabezado de capa 4 para la traducción del puerto (porque está encriptado). En el protocolo de encabezado de 

autenticación (AH, o “Authentication Header”), los dispositivos NAT no pueden modificar el número de puerto, pero 

falla la comprobación de autenticación, que incluye el paquete IPSec completo. 

Para solucionar estos problemas, los dispositivos NetScreen y el cliente NetScreen-Remote (versión 6.0 o posterior 2 ) 

pueden aplicar una función NAT-Traversal (NAT-T). NAT-T agrega una capa de encapsulación UDP a los paquetes 

IPSec si detecta al menos un dispositivo NAT en la ruta de datos durante los intercambios de fase 1, según lo 

establecido en las especificaciones IETF draft-ietf-ipsec-nat-t-ike-00.txt y draft-ietf-ipsec-udp-encaps-00.txt , así 

como en versiones más recientes de estas especificaciones. 

Los dispositivos NAT pueden crear otro problema si también están preparados para IKE/IPSec e intentan procesar 

paquetes con el número de puerto IKE 500 o con los números de protocolo 50 (para ESP) y 51 (para AH). Para 

evitar ese procesamiento intermedio de paquetes IKE, la versión 2 de las especificaciones IETF previamente 

mencionadas propone el desplazamiento (o “flotación”) de los números de puertos UDP 500 a 4500 para IKE. Para 

evitar el procesamiento intermedio de paquetes IPSec, ambas especificaciones 0 y 2 insertan un encabezado UDP 

entre el encabezado IP externo y el encabezado ESP o AH, cambiando así el valor 50 o 51 del campo “Protocol” 

1. Para obtener una lista de las incompatibilidades IPSec/NAT, consulte el documento draft-ietf-ipsec-nat-regts-00.txt de Bernard Aboba. 

2. NetScreen-Remote 6 y 7 es compatible con NAT-T según las especificaciones draft-ietf-ipsec-nat-t-ike-00.txt y draft-ietf-ipsec-udp-encaps-00.txt . 

NetScreen-Remote 8.2 es compatible con las especificaciones 02. 



(para ESP o AH, respectivamente) a 17 (para UDP). Además, el encabezado UDP insertado también utiliza el 

puerto 4500. La versión actual de ScreenOS es compatible con NAT-T de acuerdo con las especificaciones 

draft-ietf-ipsec-nat-t-ike-02.txt y draft-ietf-ipsec-udp-encaps-02.txt , así como con la versión 0 de estas 

especificaciones. 

Nota: NetScreen no admite NAT-T para los túneles de clave manual ni para el tráfico IPSec usando AH. NetScreen 

sólo admite NAT-T para túneles AutoKey IKE con ESP. 

Sondeos de NAT 

Para comprobar si ambos extremos del túnel VPN admiten NAT-T, NetScreen envía dos hashes MD-5 en la carga 

de datos de ID del fabricante en los dos primeros intercambios de las negociaciones de fase 1, un hash para el 

título de la especificación 0 y otro para el título de la especificación 2: 

“4485152d 18b6bbcd 0be8a846 9579ddcc”, que es una transformación (“hash”) MD-5 de 

“draft-ietf-ipsec-nat-t-ike-00” 

“90cb8091 3ebb696e 086381b5 ec427b1f”, que es una transformación (“hash”) MD-5 de 

“draft-ietf-ipsec-nat-t-ike-02” 

Ambos interlocutores deben enviar y recibir al menos uno de estos valores en la ID de carga de datos del fabricante 

para que el sondeo NAT-T continúe. Si envían hashes correspondientes a ambas especificaciones, NetScreen 

utiliza la implementación NAT-T correspondiente a la especificación 2. 

Si los dispositivos de cada punto terminal admiten NAT-T, se envían mutuamente cargas de datos NAT de 

descubrimiento (NAT-D) durante los intercambios tercero y cuarto de la fase 1 (modo principal) o durante los 

intercambios segundo y tercero (modo dinámico) 3 . Las cargas de datos de NAT-D contienen un hash negociado de 

la siguiente información: 

Hash del destino NAT-D: 

Cookie del iniciador (CKY-I) 

Cookie del respondedor (CKY-R) 

Dirección IP del interlocutor IKE remoto (de destino) 

Número del puerto de destino 

3. La carga de datos de descubrimiento NAT (“Nat-Discovery” o “NAT-D”) es un tipo de carga de datos IKE para NAT-T recientemente introducido. El número 

de tipo de carga de datos NAT-D es 0130. Para obtener una lista de otros tipos de carga de datos IKE, consulte “Paquetes IKE” en la página 16. 



Hash del origen NAT-D (uno o varios 4 ): 

Cookie del iniciador (CKY-I) 

Cookie del respondedor (CKY-R) 

Dirección IP del interlocutor IKE local (de origen) 

Número del puerto de origen 

Cuando cada interlocutor compara los hashes que recibe con los que envía, puede reconocer si entre ellos se ha 

producido una traducción de direcciones. La identificación de los paquetes modificados implica la de la ubicación 

del dispositivo NAT: 

Si coincide con entonces 

el hash de destino del 

interlocutor local 

al menos uno de los hashes de 

origen del interlocutor local 


origen del interlocutor remoto 


interlocutor remoto 

Si no coincide con entonces 


interlocutor local 


origen del interlocutor local 


origen del interlocutor remoto 


interlocutor remoto 

no se ha producido ninguna traducción de 

direcciones. 

no se ha producido ninguna traducción de 

direcciones. 

hay un dispositivo NAT delante del 

interlocutor remoto. 

hay un dispositivo NAT delante del 

interlocutor local. 

Conocer la ubicación del dispositivo NAT es importante porque los paquetes de mantenimiento de conexión IKE 

deben iniciarse desde el interlocutor situado detrás del dispositivo NAT. Consulte “Paquetes de mantenimiento de 

conexión” en la página 357. 

Si ambos interlocutores cumplen la especificación IETF 2, también desplazan (“flotan”) el número de puerto IKE de 

500 a 4500 tan pronto como detectan un dispositivo NAT entre ellos durante las negociaciones de la fase 1. En el 

modo principal, los números de puertos flotan a 4500 en los intercambios quinto y sexto de la fase 1, y 

posteriormente durante todos los intercambios de la fase 2. En modo dinámico, el número de puerto se desplaza al 

4500 en el tercer (y último) intercambio de la fase 1, y luego durante todos los intercambios de la fase 2. Los 

interlocutores también utilizan 4500 como número de puerto UDP para todo el tráfico IPSec subsiguiente. 

4. NAT-T admite múltiples hashes de origen NAT-D para dispositivos equipados con múltiples interfaces e implementaciones que no especifiquen una interfaz 

saliente. 



Atravesar un dispositivo NAT 

En la siguiente ilustración, un dispositivo NAT situado en el perímetro de la LAN de un hotel recibe un paquete de 

un cliente VPN de acceso telefónico con la dirección IP 2.1.1.5, asignada por el hotel. Para todo el tráfico saliente, 

el dispositivo NAT sustituye la dirección IP de origen en el encabezado externo por la nueva dirección 2.2.2.2. 

Durante las negociaciones de la fase 1, el cliente VPN y el dispositivo NetScreen detectan que los dos participantes 

VPN admiten NAT-T, que hay un dispositivo NAT en la ruta de datos y que se encuentra delante del cliente VPN. 

Hotel Empresa 

Cliente VPN de 


Dispositivo NAT 

IP de origen 200.1.1.1 -> 210.2.2.2 

Internet 

Túnel VPN 


Si se encapsulan los paquetes IPSec dentro de paquetes UDP (cosa que harán tanto el cliente VPN como el 

dispositivo NetScreen) se resuelve el problema de fallo en la comprobación de autenticación. El dispositivo NAT los 

procesa como paquetes UDP, cambiando el puerto de origen en el encabezado UDP sin modificar el SPI en el 

encabezado AH o ESP. Los participantes VPN retiran la capa UDP y procesan los paquetes IPSec, que no tendrán 

problemas en la comprobación de autenticación, ya que los contenidos autenticados no habrán cambiado. 

Puede presentarse otro problema si el dispositivo NAT está preparado para IKE/IPSec. Un dispositivo NAT 

preparado para IKE/IPSec podría intentar procesar el tráfico IKE/IPSec en lugar de reenviarlo. Para impedir tal 

procesamiento intermedio, NAT-T (v2) cambia los números de puertos UDP de origen y de destino para IKE de 500 

a 4500. NAT-T también inserta un marcador no-ESP en el encabezado UDP justo antes de la carga de datos. Para 

el tráfico IPSec, NAT-T (v0 y v2) inserta un encabezado UDP entre el encabezado IP externo y el encabezado ESP. 

El paquete UDP también utiliza 4500 como número de ambos puertos, el de origen y el de destino. 

Según lo mencionado, NAT-T (v2) agrega un marcador no-ESP entre el encabezado y la carga de datos del 

segmento del UDP que encapsula el paquete ISAKMP. El marcador no ESP consta de 4 bytes a cero (0000) y se 

agrega al segmento UDP para distinguir un paquete ISAKMP encapsulado de un paquete encapsulado ESP, que 

no tiene tal marcador. Sin el marcador no ESP, el receptor no sabría si el paquete encapsulado era un paquete 



ISAKMP o un paquete ESP, porque el encabezado UDP utiliza 4500 para ambos tipos. Utilizando este marcador se 

indica el tipo correcto de paquete encapsulado para que el receptor pueda desmultiplexarlo correctamente. 

Como puede comprobar en la ilustración siguiente, después de detectar un dispositivo NAT en la ruta de datos, los 

números de los puertos de origen y de destino en el encabezado UDP de un paquete IKE cambian de 500 a 4500. 

Asimismo, los puntos terminales del túnel VPN insertan un marcador no ESP entre el encabezado UDP y la carga de 

datos para distinguir el paquete ISAKMP encapsulado de un paquete ESP. El receptor puede utilizar este marcador 

para distinguir el paquete ISAKMP encapsulado de un paquete ESP y para desmultiplexarlo correctamente. 

Paquete IKE 

(Para las fases 1 y 2) 

Encabezado 

IP 

Segmento UDP 

Encabezado 

UDP 

Encabezado 

ISAKMP 


Tamaño 

Segmento UDP después de detectar un dispositivo NAT 


Tamaño 


Nota: ISAKMP es el formato de paquetes utilizado por IKE. 


Marcador no ESP (0000) 








Como puede ver en la ilustración siguiente, después de detectar un dispositivo NAT en la ruta de datos, los puntos 

terminales del túnel VPN insertan un encabezado UDP adicional entre el encabezado IP externo y el encabezado 

ESP de un paquete IPSec. Dado que no hay ningún marcador no ESP, el receptor puede distinguir el paquete ESP 

encapsulado de un un paquete ISAKMP y desmultiplexar el paquete ESP correctamente. 

Paquete IPSec – 

Carga de seguridad encapsulada (ESP) 

Paquete IPSec 

Enviado por la puerta de 

enlace IKE 

Encabezado 

IP2 

Paquete IPSec ESP después de detectar un dispositivo NAT 

Encabezado 

IP2 

Encabezado 

ESP 

Paquete IPSec 

Enviado por la puerta de enlace IKE 

Encabezado 

UDP 

Encabezado 

IP1 

La puerta de enlace local agrega estos 

encabezados al paquete. 

Encabezado 

ESP 

La puerta de enlace local agrega 

estos encabezados al paquete. 

Encabezado UDP 

Puerto de origen ( 4500 para ESP ) 

Tamaño 

Encabezado 

TCP 

Encabezado 

IP1 



Enviado por el host 



Enviado por el host iniciador 

Encabezado 


TCP 

Puerto de destino ( 4500 para ESP ) 




Suma de comprobación de UDP 

Todos los paquetes UDP contienen una suma de comprobación de UDP, un valor calculado que garantiza que los 

paquetes UDP no tienen errores de transmisión. Los dispositivos NetScreen no necesitan utilizar la suma de 

comprobación de UDP para NAT-T, de modo que la WebUI y la CLI presentan la suma de comprobación como 

ajuste opcional. Aún así, ciertos dispositivos NAT precisan de suma de comprobación, por lo que puede ser 

necesario habilitar o inhabilitar esta opción. De forma predeterminada, al habilitar NAT-T se incluye la suma de 

comprobación UDP. 

WebUI 

VPNs > AutoKey Advanced > Gateway > New: Introduzca los parámetros necesarios para la nueva puerta 

de enlace del túnel tal y como se describe en el Capítulo 4, “VPNs punto a punto” en la página 103 o en el 

Capítulo 5, “VPNs de acceso telefónico” en la página 233, introduzca los siguientes datos y, finalmente, 




enlace: 


UDP Checksum: Enable 

CLI 

set ike gateway name nat-traversal udp-checksum 

unset ike gateway name nat-traversal udp-checksum 

Paquetes de mantenimiento de conexión 

Cuando un dispositivo NAT asigna una dirección IP a un host, el dispositivo NAT determina el intervalo de tiempo que 

la nueva dirección será válida si no hay tráfico. Por ejemplo, un dispositivo NAT podría invalidar cualquier dirección IP 

generada que no se utilice durante 20 segundos. Por eso, suele ser necesario que los participantes IPSec envíen 

periódicamente paquetes de mantenimiento de conexión (paquetes UDP vacíos) a través del dispositivo NAT, de 

forma que la asignación NAT no cambie hasta que las asociaciones de seguridad de fase 1 y fase 2 expiren. 

Nota: Los dispositivos NAT tienen distintos intervalos de tiempo de espera de sesión, dependiendo del fabricante y 

el modelo. Es importante determinar qué intervalo tiene el dispositivo NAT, para poder establecer un valor de 

frecuencia de mantenimiento de conexión por debajo de dicho intervalo. 



Simetría iniciador/respondedor 

Cuando dos dispositivos NetScreen establecen un túnel en ausencia de un dispositivo NAT, cada dispositivo puede 

funcionar como iniciador o respondedor. Sin embargo, si uno de los hosts se encuentra tras un dispositivo NAT, 

esta simetría iniciador/respondedor podría llegar a ser imposible. Esto sucede cuando el dispositivo NAT genera 

direcciones IP dinámicamente. 

Nota: Las zonas de seguridad ilustradas a continuación se 

muestran desde la perspectiva de NetScreen-B. 

Host A 

Zona Untrust Zona Trust 


Internet 

Dispositivo 

NAT NetScreen-B 

Túnel 

1.2.1.1 1.1.1.250 

Conjunto de direcciones IP 

1.2.1.2 - 1.2.1.50 

Host B 

10.1.1.5 

El dispositivo NAT traduce la dirección IP de origen en 

paquetes que recibe del dispositivo NetScreen B, utilizando 

direcciones que toma de su conjunto de direcciones IP. 

En la ilustración anterior, NetScreen-B se encuentra en una subred situada tras un dispositivo NAT. Si el dispositivo 

NAT genera nuevas direcciones IP de origen para los paquetes que recibe desde NetScreen-B (tomándolas 

dinámicamente de un conjunto de direcciones IP), NetScreen-A no puede identificar inequívocamente a NetScreen 

B. Por lo tanto, NetScreen-A no podrá iniciar con éxito un túnel con NetScreen-B. NetScreen-A debe actuar como 

respondedor, NetScreen-B como iniciador, y ambos deben realizar las negociaciones de fase 1 en modo dinámico. 

No obstante, si el dispositivo NAT genera la nueva dirección IP utilizando una dirección IP asignada (MIP) o 

cualquier otro método de direccionamiento “1:1”, NetScreen A podrá identificar de forma única a NetScreen B. En 

consecuencia, tanto NetScreen-A como NetScreen-B podrán actuar como iniciadores y ambos podrán utilizar el 

modo principal o dinámico en la fase 1. 



Nota: Si habilita NAT-T en un dispositivo NetScreen que actúa como respondedor y lo configura para que lleve a 

cabo las negociaciones IKE en modo principal, este dispositivo y todos sus interlocutores configurados en la misma 

interfaz de salida deberán usar las mismas propuestas de fase 1 y presentadas en el mismo orden. Los 

interlocutores podrán ser de los siguientes tipos: 

Interlocutor dinámico (interlocutores con direcciones IP asignadas dinámicamente) 

Usuarios VPN de acceso telefónico 

Interlocutores con direcciones IP estáticas tras un dispositivo NAT 

Como no es posible conocer la identidad de un interlocutor durante las negociaciones de fase 1 en modo principal 

hasta los dos últimos mensajes, las propuestas de fase 1 deberán ser iguales para que las negociaciones IKE se 

puedan llevar a cabo. 

Cuando se configura IKE en modo principal para uno de los tipos de interlocutor anteriormente mencionados en la 

misma interfaz de salida, el dispositivo NetScreen comprueba automáticamente que todas las propuestas de fase 1 

sean iguales y tengan el mismo orden. Si las propuestas son distintas, el dispositivo NetScreen generará un 

mensaje de error. 

Ejemplo: Habilitación de NAT-Traversal 

En el siguiente ejemplo, un dispositivo NAT ubicado en el perímetro de la red local de un hotel asigna una dirección 

al cliente VPN de acceso telefónico utilizado por Michael Smith, un comercial que está participando en una 

convención. Para que Michael Smith pueda acceder a la LAN corporativa por medio de un túnel VPN de acceso 

telefónico, se debe habilitar NAT-T para la puerta de enlace remota “msmith”, configurada en el dispositivo 

NetScreen, y para la puerta de enlace remota, configurada en el cliente VPN de acceso telefónico. También deberá 

habilitar el dispositivo NetScreen para que incluya una suma de comprobación de UDP en sus transmisiones, y 

establecer una frecuencia de mantenimiento de conexión de 8 segundos. 

Hotel Empresa 

Cliente VPN de acceso 

telefónico 

Dispositivo NAT 

Internet 

Túnel VPN 




WebUI 

CLI 

VPNs > AutoKey Advanced > Gateway > New: Introduzca los parámetros necesarios para la nueva puerta 

de enlace del túnel tal y como se describe en el Capítulo 4, “VPNs punto a punto” en la página 103 o en el 

Capítulo 5, “VPNs de acceso telefónico” en la página 233, introduzca los siguientes datos y, finalmente, 




enlace: 


UDP Checksum: Enable 

Keepalive Frequency: 8 segundos (0~300 Sec) 

Nota: Cuando se configura una VPN de acceso telefónico con CLI, el dispositivo NetScreen activa 

automáticamente NAT-Traversal. 

set ike gateway msmith nat-traversal 

set ike gateway msmith nat-traversal udp-checksum 

set ike gateway msmith nat-traversal keepalive-frequency 8 

save 


Capítulo 7 Funciones de VPN avanzadas Supervisión de VPNs 

SUPERVISIÓN DE VPNS 

Cuando se habilita la supervisión de VPNs para un túnel específico, el dispositivo NetScreen envía peticiones de 

eco ICMP (o “pings”) a través del túnel en intervalos determinados (configurables en segundos) para supervisar la 

conectividad de la red a través del túnel 5 . Si la actividad de estas peticiones indica que el estado de supervisión de 

VPN ha cambiado, el dispositivo NetScreen activará una de las siguientes capturas del protocolo simple de gestión 

de redes (SNMP, o “Simple Network Management Protocol”): 

Up to Down: esta captura se produce cuando el estado de supervisión de VPN para el túnel está activo 

(up), pero un número consecutivo de peticiones de eco ICMP determinado no provoca respuesta y no hay 

otro tráfico VPN entrante 6 . Entonces el estado cambia a inactivo (down). 

Down to Up: cuando el estado de la supervisión de VPN es inactivo (down), pero la petición de eco ICMP 

obtiene una sola respuesta, el estado pasa a activo (up). La captura “down-to-up” sólo se produce si se ha 

inhabilitado la opción de reencriptación y la asociación de seguridad de fase 2 aún está activa cuando una 

petición de eco ICMP obtiene respuesta a través del túnel. 

Nota: Para obtener más información sobre los datos SNMP que proporciona la supervisión de VPN, consulte 

“Objetos y capturas SNMP para la supervisión de VPN” en la página 380. 

Usted aplica la supervisión de VPN por cada objeto VPN, no necesariamente por cada túnel VPN. Un objeto VPN 

es el que se define con el comando set vpn , o con sus equivalentes de WebUI. Una vez definido un objeto VPN, 

puede hacer referencia a él en unas o más directivas (creando VPNs basadas en directivas). Dado que ScreenOS 

deriva un túnel de VPN basada en directivas a partir de un objeto VPN más los demás parámetros de la directiva, 

un solo objeto VPN puede ser un elemento de numerosos túneles VPN. Esta distinción entre objeto VPN y túnel 

5. Para cambiar el intervalo de pings, puede utilizar el siguiente comando CLI: set vpnmonitor interval número . El intervalo predeterminado es de 10 

segundos. 

6. Para cambiar el límite de peticiones de eco ICMP consecutivas sin respuesta, puede utilizar el siguiente comando CLI: set vpnmonitor threshold number . 

El valor predeterminado es de 10 peticiones. 



VPN es importante porque Juniper Networks recomienda aplicar la supervisión de VPN a no más de 100 túneles 

IPSec VPN (si no habilita la optimización). Si habilita la optimización, no habrá límite al número de túneles VPN a 

los que pueda aplicar la supervisión de VPN. Para obtener información sobre la opción de optimización, consulte 

“Opciones de reencriptación y optimización” en la página 362. 

Nota: La optimización de la supervisión de VPN funciona objeto por objeto. Para activarla en todos los objetos de la 

VPN, en ninguno o sólo en algunos. 

Opciones de reencriptación y optimización 

Si se habilita la opción de reencriptación, el dispositivo NetScreen comienza a enviar peticiones de eco ICMP 

inmediatamente después de completar la configuración del túnel y seguirá enviándolas indefinidamente. Las 

peticiones de eco desencadenan un intento de iniciar negociaciones IKE para establecer un túnel VPN hasta que el 

estado de la supervisión de VPN para el túnel sea activo (up). A continuación, el dispositivo NetScreen utiliza las 

peticiones de eco con fines de supervisión de VPN. Si el estado de la supervisión de VPN para el túnel pasa de 

activo a inactivo, el dispositivo NetScreen desactivará su asociación de seguridad (SA) de fase 2 para ese 

interlocutor. El dispositivo NetScreen continuará enviando peticiones de eco a su interlocutor según los intervalos 

definidos, desencadenando intentos de reiniciar las negociaciones IKE de fase 2 (y las de fase 1, si fuera necesario) 

hasta que tenga éxito. En ese momento, el dispositivo NetScreen reactivará la asociación de seguridad de fase 2, 

generará una nueva clave y restablecerá el túnel. En el registro de eventos aparecerá un mensaje indicando que se 

ha realizado correctamente una operación de reencriptación 7 . 

La opción de reencriptación se puede utilizar para garantizar que un túnel AutoKey IKE siempre esté activo, quizá 

para supervisar dispositivos en la ubicación remota o para permitir que los protocolos de enrutamiento dinámico 

memoricen rutas en una ubicación remota y transmitir mensajes a través del túnel. Otra aplicación de la supervisión 

de VPN con la opción de reencriptación es completar automáticamente la tabla de asociación de túneles a saltos 

siguientes (tabla NHTB) y la tabla de rutas cuando se asocian múltiples túneles VPN a una sola interfaz de túnel. 

Para ver un ejemplo de este último uso, consulte “Múltiples túneles por interfaz de túnel” en la página 381. 

Si desactiva la opción de reencriptación, el dispositivo NetScreen sólo realizará la supervisión de VPN cuando el 

túnel esté activo con tráfico generado por el usuario. 

7. Si un dispositivo NetScreen es un cliente DHCP, una actualización de DHCP en una dirección distinta hará que IKE se reencripte. Sin embargo, una 

actualización de DHCP en la misma dirección no provocará la reencriptación de IKE. 



De forma predeterminada, la optimización de la supervisión de VPN está inhabilitada. Si la habilita ( set vpn name 

monitor optimized ), el comportamiento de la supervisión de VPN cambiará tal y como se indica a continuación: 

El dispositivo NetScreen considerará el tráfico entrante a través del túnel VPN equivalente a las respuestas 

de eco ICMP. Si se acepta tráfico entrante en sustitución de las respuestas de eco ICMP se pueden reducir 

las falsas alarmas que podrían producirse cuando hay mucho tráfico a través del túnel y las respuestas de 

eco no consiguen pasar. 

Si hay tráfico entrante y saliente a través del túnel VPN, el dispositivo NetScreen también suprimirá las 

peticiones de eco de supervisión de VPN. Esto puede contribuir a reducir el tráfico de red. 

Aunque la optimización de supervisión de VPN presenta algunas ventajas, observe que la supervisión deja de 

ofrecer estadísticas SNMP precisas, como el tiempo de retardo de red de VPN, cuando se activa la opción de 

optimización. Además, si se utiliza la supervisión de VPN para hacer un seguimiento de la disponibilidad de una 

dirección IP de destino en el extremo remoto de un túnel, la función de optimización puede hacer que los resultados 

sean erróneos. 

Interfaz de origen y dirección de destino 

De forma predeterminada, la función de supervisión de VPN utiliza la dirección IP de la interfaz de salida local como 

dirección de origen y la dirección IP de la puerta de enlace remota como dirección de destino. Si el interlocutor 

remoto es un cliente VPN de acceso telefónico (como NetScreen-Remote) con una dirección IP interna, el 

dispositivo NetScreen detectará automáticamente su dirección interna y la utilizará como destino. El cliente VPN 

puede ser un usuario XAuth con una dirección IP interna asignada, un usuario VPN o el miembro de un grupo VPN 

de acceso telefónico con una dirección IP interna. También puede especificar el uso de otras direcciones IP de 

origen y destino para la supervisión de VPN, sobre todo para permitir la supervisión de VPN cuando el otro extremo 

de un túnel VPN no es un dispositivo NetScreen. 

Como la supervisión de VPN funciona de forma independiente en las ubicaciones local y remota, la dirección de 

origen configurada en el dispositivo ubicado en un extremo del túnel no tiene por qué ser la dirección de destino 

configurada en el dispositivo ubicado en el otro extremo. De hecho, es posible habilitar la supervisión de VPN en 

ambos extremos del túnel o sólo en uno de ellos. 



NetScreen-A –> NetScreen-B 

NetScreen-A envía peticiones 

de eco desde su interfaz de 

salida a la puerta de enlace 

remota; es decir, desde la 

interfaz de zona Untrust en 

NetScreen-A a la interfaz de 

zona Untrust en NetScreen-B. 

(comportamiento predeterminado) 

NetScreen-A –> NetScreen-Remote 

NetScreen-A envía peticiones de 

eco desde la interfaz de zona 

Trust a NetScreen-Remote. 

NetScreen-Remote necesita una 

directiva que admita el tráfico 

ICMP entrante desde una 

dirección más allá de la puerta 

de enlace remota; es decir, 

desde más allá de la interfaz de 

zona Untrust de NetScreen-A. 

LAN 

Zona Trust 


Dirección origen: 

interfaz de la zona Trust 

LAN 

NetScreen-A –> Terminador de VPN de otro fabricante 

NetScreen-A envía peticiones 

de eco desde la interfaz de zona 

Trust a un dispositivo ubicado 

más allá de la puerta de enlace 

remota. Esto podría ser 

necesario si el interlocutor 

remoto no responde a 

peticiones de eco pero admite 

directivas que permitan el tráfico 

entrante de estas peticiones de 

eco. 




interfaz de salida 

Túnel VPN 

Túnel VPN 

Túnel VPN 

Dirección destino: 

puerta de enlace remota 


Zona Untrust 

Zona Trust 

Zona Untrust 

Nota: NetScreen-A precisa de una directiva que permita el tráfico de peticiones de eco de la zona Trust 

a la zona Untrust. 


interfaz de la zona Trust 

LAN 

Zona Trust Zona Untrust 




servidor FTP 

Terminador de VPN 

de otro fabricante 

Nota: NetScreen-A precisa de una directiva que permita el tráfico de peticiones de eco de la zona Trust 

a la zona Untrust. 

Nota: Si al otro lado de un túnel se encuentra un cliente de VPN NetScreen-Remote que recibe su dirección a 

través de XAuth, el dispositivo NetScreen utilizará de forma predeterminada la dirección IP asignada a XAuth como 

destino para la supervisión de VPN. Para obtener más información sobre XAuth, consulte “Usuarios y grupos de 

usuarios XAuth” en la página 8 -83. 


LAN


Consideraciones sobre directivas 

Debe crear una directiva en el dispositivo de envío para permitir que las peticiones de eco procedentes de la zona 

donde se encuentra la interfaz de origen pasen a través del túnel VPN a la zona que contiene la dirección de 

destino si: 

La interfaz de origen se encuentra en una zona distinta de la dirección de destino. 

La interfaz de origen se encuentra en la misma zona que la dirección de destino y está habilitado el bloqueo 

intrazonal. 

Asimismo, debe crear una directiva en el dispositivo receptor para permitir que las peticiones de eco procedentes 

de la zona donde se encuentra la dirección de origen pasen a través del túnel VPN a la zona que contiene la 

dirección de destino si: 

La dirección de destino se encuentra en una zona distinta de la dirección de origen. 

La dirección de destino se encuentra en la misma zona que la dirección de origen y está habilitado el 

bloqueo intrazonal. 

Nota: Si el dispositivo receptor es un producto de otro fabricante que no responde a las peticiones de eco ICMP, 

cambie el destino a un host interno en la LAN del interlocutor remoto que sí responda. El cortafuegos del 

interlocutor remoto siempre debe disponer de una directiva que permita el paso de las peticiones de eco ICMP. 

Configuración de la función de supervisión de VPN 

Para habilitar la supervisión de VPN, siga estos pasos: 

WebUI 

VPNs > AutoKey IKE > New: Configure la VPN, haga clic en Advanced , introduzca los siguientes datos, 

haga clic en Return para regresar a la página de configuración básica de VPN y, finalmente, haga clic en 

OK : 

VPN Monitor : seleccione la opción para habilitar la supervisión de VPN en 

este túnel VPN. 



(o bien) 

Source Interface: elija una interfaz en la lista desplegable. Si elige “default”, 

el dispositivo NetScreen utilizará la interfaz de salida. 

Destination IP: introduzca una dirección IP de destino. Si no introduce ningún 

dato, el dispositivo NetScreen utilizará la dirección IP de puerta de enlace 

remota. 

Rekey: seleccione esta opción si desea que el dispositivo NetScreen intente 

realizar las negociaciones IKE de fase 2 (y de fase 1 si fuera necesario) si 

el estado del túnel cambia de activo a inactivo. Cuando seleccione esta 

opción, el dispositivo NetScreen intentará realizar las negociaciones IKE 

para configurar el túnel y comenzar la supervisión de VPN inmediatamente 

después de terminar la configuración. 

Anule la selección de esta opción si no desea que el dispositivo NetScreen 

intente realizar las negociaciones IKE cuando el estado del túnel cambie 

de activo a inactivo. Si la opción de reencriptación está inhabilitada, la 

supervisión de VPN comenzará cuando el tráfico generado por el usuario 

haya desencadenado el inicio de las negociaciones IKE y se detendrá 

cuando el estado del túnel pase de activo a inactivo. 

VPNs > Manual Key > New: Configure la VPN, haga clic en Advanced , introduzca los siguientes datos, 

haga clic en Return para regresar a la página de configuración básica de VPN y, finalmente, haga clic en 

OK : 

VPN Monitor : seleccione la opción para habilitar la supervisión de VPN en 

este túnel VPN. 

Source Interface: elija una interfaz en la lista desplegable. Si elige “default”, 

el dispositivo NetScreen utilizará la interfaz de salida. 

Destination IP: introduzca una dirección IP de destino. Si no introduce ningún 

dato, el dispositivo NetScreen utilizará la dirección IP de puerta de enlace 

remota. 



CLI 

set vpnmonitor frequency number 8 

set vpnmonitor threshold number 9 

set vpn name_str monitor [ source-interface interface 10 [ destination-ip 

ip_addr 11 ] ] [optimized] [ rekey 12 ] 

save 

8. La frecuencia de supervisión de VPN se mide en segundos. El intervalo predeterminado es de 10 segundos. 

9. El límite (threshold) de supervisión de VPN es el número de peticiones de eco ICMP seguidas sin respuesta que determina si la puerta de enlace remota 

es accesible a través del túnel o no. El límite predeterminado es de 10 peticiones de eco ICMP consecutivas con respuesta o 10 peticiones consecutivas 

sin respuesta. 

10. Si no elige una interfaz de origen, el dispositivo NetScreen utilizará la interfaz de salida como predeterminada. 

11. Si no elige una dirección IP de destino, el dispositivo NetScreen utilizará la dirección IP de la puerta de enlace remota. 

12. La opción de reencriptación no está disponible para los túneles VPN con clave manual. 



Ejemplo: Especificación de las direcciones de origen y destino para la supervisión 

de VPN 

En este ejemplo configuraremos un túnel VPN AutoKey IKE entre dos dispositivos NetScreen (NetScreen-A y 

NetScreen-B). En el dispositivo A, configure la supervisión de VPN desde su interfaz de zona Trust (ethernet1) a la 

interfaz de zona Trust (10.2.1.1/24) del dispositivo NetScreen-B. En NetScreen-B, configure la supervisión de VPN 

desde su interfaz de zona Trust interface (ethernet1) a un servidor de red local corporativa (10.1.1.5) ubicado tras 

NetScreen-A. 


Zonas e interfaces 


ethernet1 

ethernet1 

- Zona: Trust 

- Zona: Trust 

- Dirección IP: 10.1.1.1/24 

- Dirección IP: 10.2.1.1/24 

- Modo de interfaz: NAT 

- Modo de interfaz: NAT 

ethernet3 

- Zona: Untrust 

- Dirección IP: 1.1.1.1/24 

Parámetros de túnel AutoKey IKE basado en rutas 

Fase 1 

- Nombre de puerta de enlace: gw1 

- Dirección IP estática de puerta de enlace: 2.2.2.2 

- Nivel de seguridad: Compatible * 

- Clave previamente compartida: Ti82g4aX 

- Interfaz de salida: ethernet3 

- Modo: Principal 

Fase 2 

- Nombre de túnel VPN: vpn1 

- Nivel de seguridad: Compatible † 

- Supervisión de VPN: src = ethernet1; dst = 10.2.1.1 

- Asociado a interfaz: tunnel.1 

ethernet3 

- Zona: Untrust 

- Dirección IP: 2.2.2.2/24 

Fase 1 

- Nombre de puerta de enlace: gw1 

- Dirección IP estática de puerta de enlace: 1.1.1.1 

- Propuestas: Compatible 

- Clave previamente compartida: Ti82g4aX 

- Interfaz de salida: ethernet3 

- Modo: Principal 

Fase 2 

- Nombre de túnel VPN: vpn1 

- Nivel de seguridad: Compatible 

- Supervisión de VPN: src = ethernet1; dst = 10.1.1.5 

- Asociado a interfaz: tunnel.1 

* El nivel de seguridad Compatible en la fase 1 incluye las siguientes propuestas: pre-g2-3des-sha, pre-g2-3des-md5, pre-g2-des-sha y pre-g2-des-md5. 

† 

El nivel de seguridad Compatible en la fase 2 incluye las siguientes propuestas: nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha 

y nopfs-esp-des-md5. 




Rutas 

A 0.0.0.0/0, utilizar ethernet3, puerta de enlace 

1.1.1.250 

A 10.2.1.0/24, utilizar tunnel.1, sin puerta de enlace 

(Ruta nula: para derivar el tráfico a 10.2.1.0/24 si 

tunnel.1 se desactiva) Para 10.2.1.0/24, utilizar interfaz 

nula, métrica: 10 

Como los dos dispositivos envían peticiones de eco ICMP desde una interfaz en su zona Trust a una dirección de 

su zona Untrust, los administradores en ambos extremos del túnel VPN deben definir directivas que permitan que 

las peticiones pasen de una zona a otra. 


1. Interfaces 







A 0.0.0.0/0, utilizar ethernet3, puerta de enlace 

2.2.2.250 

A 10.1.1.0/24, utilizar tunnel.1, sin puerta de enlace 

(Ruta nula: para derivar el tráfico a 10.1.1.0/24 si 

tunnel.1 se desactiva) Para 10.1.1.0/24, utilizar interfaz 

nula, métrica: 10 

Nota: Como los dos terminadores VPN de este ejemplo son dispositivos NetScreen, es posible utilizar las 

direcciones predeterminadas de origen y destino para la supervisión VPN. El uso de otras opciones se incluye 

únicamente para ilustrar la configuración de un dispositivo NetScreen para que pueda utilizarlas. 







Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga clic en OK : 



Zone (VR): Trust (trust-vr) 


Interface: ethernet1(trust-vr) 





Zone: Trust 


Address Name: Remote_LAN 



Zone: Untrust 



3. VPN 







Type: 

Static IP: (seleccione), Address/Hostname: 2.2.2.2 

Preshared Key: Ti82g4aX 









Service: ANY 

VPN Monitor: (seleccione) 

Source Interface: ethernet1 

Destination IP: 10.2.1.1 

Rekey: (anule la selección) 



4. Rutas 












5. Directivas 





Metric: 10 





Address Book Entry: (seleccione), Remote_LAN 

Service: ANY 







1. Interfaces 





Service: Any 















Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga clic en OK : 


3. VPN 


Zone (VR): Trust (trust-vr) 


Interface: ethernet1(trust-vr) 





Zone: Trust 


Address Name: Remote_LAN 



Zone: Untrust 









Type: 

Static IP: (seleccione), Address/Hostname: 1.1.1.1 

Preshared Key: Ti82g4aX 









Service: ANY 

VPN Monitor: (seleccione) 

Source Interface: ethernet1 

Destination IP: 10.1.1.5 

Rekey: (anule la selección) 

4. Rutas 


















Metric: 10 

5. Directivas 

Policies > (From: Trust, To: Untrust) New: Introduzca los siguientes datos y haga clic en OK: 





Service: ANY 










Service: Any 






1. Interfaces 






set interface tunnel.1 zone trust 




set address untrust Remote_LAN 10.2.1.0/24 

3. VPN 

set ike gateway gw1 address 2.2.2.2 main outgoing-interface ethernet3 preshare 

Ti82g4aX sec-level compatible 




set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.2.1.1 

4. Rutas 




5. Directivas 

set policy top from trust to untrust Trust_LAN Remote_LAN any permit 

set policy top from untrust to trust Remote_LAN Trust_LAN any permit 

save 




1. Interfaces 






set interface tunnel.1 zone trust 




set address untrust Remote_LAN 10.1.1.0/24 

3. VPN 

set ike gateway gw1 address 1.1.1.1 main outgoing-interface ethernet3 preshare 

Ti82g4aX sec-level compatible 




set vpn vpn1 monitor source-interface ethernet1 destination-ip 10.1.1.5 

4. Rutas 




5. Directivas 

set policy top from trust to untrust Trust_LAN Remote_LAN any permit 

set policy top from untrust to trust Remote_LAN Trust_LAN any permit 

save 



Objetos y capturas SNMP para la supervisión de VPN 

ScreenOS permite determinar el estado y las condiciones de las VPN activas utilizando objetos y capturas SNMP 

(Simple Network Management Protocol) para la supervisión de VPN. La MIB de supervisión de VPN indica si cada 

petición de eco ICMP provoca una respuesta, un promedio actualizado de respuestas enviadas correctamente, la 

latencia de la respuesta y la latencia media de los últimos 30 intentos. 

Nota: Para permitir que la aplicación de gestión SNMP reconozca las MIBs de supervisión de VPN, es necesario 

importar en la aplicación los archivos de extensión MIB específicos de NetScreen. Puede encontrar los archivos de 

extensión MIB en el CD de documentación de NetScreen que recibió con su dispositivo NetScreen. 

Si se habilita la función de supervisión de VPN en un túnel VPN AutoKey IKE o con clave manual, el dispositivo 

NetScreen activará sus objetos SNMP de supervisión de VPN, que incluyen los siguientes datos: 

Número total de sesiones de VPN activas 

Hora en la que se inició cada sesión 

Elementos de asociación de seguridad (SA) de cada sesión: 

– Tipos de algoritmos de encriptación (DES o 3DES) y de autenticación (MD5 o SHA-1) ESP 

– Tipo de algoritmo de encabezado de autenticación (MD5 o SHA-1) 

– Protocolo de intercambio de claves (AutoKey IKE o clave manual) 

– Método de autenticación de fase 1 (clave previamente compartida o certificados) 

– Tipo de VPN (acceso telefónico o punto a punto) 

– Direcciones IP de interlocutor y puerta de enlace local 

– IDs de interlocutor y puerta de enlace local 

– Número SPI (índice de parámetro de seguridad, “Security Parameter Index”) 

Parámetros de estado de sesión 

– Estado de supervisión de VPN (activo o inactivo) 

– Estado de túnel (activo o inactivo) 

– Estado de fase 1 y 2 (inactivo o activo) 

– Periodo de vigencia de fase 1 y 2 (tiempo en segundos antes de la reencriptación; el periodo de 

vigencia de fase 2 también se registra en bytes restantes antes de la reencriptación) 


Capítulo 7 Funciones de VPN avanzadas Múltiples túneles por interfaz de túnel 

MÚLTIPLES TÚNELES POR INTERFAZ DE TÚNEL 

Es posible asociar múltiples túneles VPN IPSec a una sola interfaz de túnel. Para vincular un destino específico a 

uno de los túneles VPN asociados a la misma interfaz de túnel, el dispositivo NetScreen utiliza dos tablas: la tabla 

de rutas y la de asociación de túneles a saltos siguientes (NHTB). El dispositivo NetScreen asigna la dirección IP de 

puerta de enlace al siguiente salto, especificada en la entrada de la tabla de rutas, a un túnel VPN particular 

especificado en la tabla NHTB. Con esta técnica, una sola interfaz de túnel puede admitir varios túneles VPN. 

(Consulte “Asignación de rutas a túneles” en la página 382.) 

Túneles VPN basados en rutas 

para múltiples interlocutores 

remotos. 

Todos los túneles comparten 

la misma interfaz de túnel. 


El dispositivo NetScreen puede ordenar el tráfico VPN enviado a través de una sola interfaz de túnel 

a tantos túneles VPN como admita la tabla de rutas o la capacidad del túnel VPN (lo que sea menor). 

El número máximo de túneles VPN no está limitado por el número de interfaces de túnel que se puedan crear, sino 

por la capacidad de la tabla de rutas o el número máximo de túneles VPN dedicados admitido (lo que sea menor). 

Por ejemplo, si el dispositivo NetScreen admite 4.000 rutas y 1.000 túneles VPN dedicados, será posible crear 

1.000 túneles VPN y asociarlos a una sola interfaz de túnel. Si el dispositivo NetScreen admite 8.192 rutas y 10.000 

túneles VPN dedicados, será posible crear 8.000 túneles VPN y asociarlos a una sola interfaz de túnel 13 . Para ver la 

capacidad máxima de rutas y túneles de su dispositivo NetScreen, consulte la hoja de datos correspondiente del 

producto. 

13. Si la capacidad de la tabla de rutas es lo que va a establecer el límite, deberá restar al total de túneles VPN basados en rutas las rutas generadas 

automáticamente por las interfaces de zona de seguridad y otras rutas estáticas (como la ruta a la puerta de enlace predeterminada) que tendrá que definir. 



Asignación de rutas a túneles 

Para ordenar el tráfico a través de túneles VPN asociados a la misma interfaz de túnel, el dispositivo NetScreen 

asigna la dirección IP de la puerta de enlace al salto siguiente especificada en la ruta a un nombre de túnel VPN 

determinado. La asignación de entradas en la tabla de rutas a entradas en la tabla NHTB se muestra a 

continuación. En la siguiente ilustración, el dispositivo NetScreen local enruta el tráfico enviado de 10.2.1.5 a 

10.1.1.5 a través de la interfaz tunnel.1 y, a continuación, a través de vpn2. 

10.2.1.5 

10.2.0.0/16 

LAN de zona 

Trust 


con múltiples túneles 

asignados a la interfaz 

tunnel.1 

tunnel.1 

vpn1 

vpn2 

vpn3 

10.1.1.1 

10.1.3.1 

Interlocutores VPN remotos (con direcciones IP 

externas asignadas dinámicamente y direcciones 

IP de interfaz de túnel fijas) y sus LAN protegidas 

10.1.2.1 

10.1.0.0/24 

10.1.2.0/24 

10.1.1.0/24 

10.1.1.5 

Tabla de rutas Tabla de asociación de túneles a saltos siguientes 

ID IP-Prefix (Dst) Interface Gateway Next-Hop VPN Flag 

1 10.1.0.0/24 tunnel.1 10.1.1.1 10.1.1.1 vpn1 static 



Se puede utilizar un protocolo de enrutamiento 

dinámico como Border Gateway Protocol (BGP) para 

rellenar la tabla de rutas automáticamente, o bien 

introducir manualmente estas rutas. La dirección IP de 

la puerta de enlace es la dirección de la interfaz de túnel 

en la ubicación del interlocutor remoto. 

Durante las negociaciones de fase 2, los dos interlocutores 

IKE intercambian direcciones de interfaz de túnel e introducen 

automáticamente estas asociaciones de túnel a salto 

siguiente. De forma opcional también se pueden introducir 

manualmente. La dirección IP del siguiente salto será la 

dirección IP de interfaz de túnel del interlocutor remoto. 

En las entradas anteriores, la dirección IP de la puerta de enlace en la tabla de rutas, que también es la dirección IP 

de salto siguiente en la tabla NHTB, es la interfaz de túnel en la ubicación del interlocutor remoto. Esta dirección IP 

vincula la ruta (y, en consecuencia, la interfaz de túnel especificada en la ruta) a un túnel VPN determinado para el 

tráfico destinado al prefijo IP especificado. 



El dispositivo NetScreen utiliza la dirección IP de la interfaz de túnel del interlocutor remoto como puerta de enlace 

y dirección IP del salto siguiente. Puede introducir la ruta manualmente o hacer que un protocolo de enrutamiento 

dinámico introduzca automáticamente una ruta que haga referencia a la dirección IP de interfaz de túnel del 

interlocutor como puerta de enlace en la tabla de rutas. La misma dirección IP se tiene que introducir como salto 

siguiente, junto con el nombre de túnel VPN correspondiente, en la tabla NHTB. Una vez más, dispone de dos 

alternativas: puede introducirla manualmente o hacer que el dispositivo NetScreen la recoja del interlocutor remoto 

durante las negociaciones de fase 2 y la introduzca manualmente. 

El dispositivo NetScreen utiliza la dirección IP de puerta de enlace en la entrada de la tabla de rutas y la dirección IP 

de salto siguiente en la entrada de la tabla NHTB como elemento común para vincular la interfaz de túnel con el 

túnel VPN correspondiente. El dispositivo NetScreen puede así dirigir el tráfico destinado al prefijo IP especificado 

en la ruta con el túnel VPN adecuado especificado en la tabla NHTB. 

Direcciones de interlocutores remotos 

El esquema de direccionamiento interno de los interlocutores remotos a los que se accede por VPNs basadas en 

rutas debe ser único para todos ellos. Una forma de conseguirlo es realizar una traducción de direcciones de red 

(NAT) de las direcciones de origen y de las de destino por cada interlocutor remoto. Además, las direcciones IP de 

interfaz de túnel también deben ser únicas para todos los interlocutores remotos. Si pretende conectar un gran 

número de ubicaciones remotas, será absolutamente necesario elaborar un esquema de direcciones. A 

continuación se muestra un ejemplo de esquema de direcciones para un máximo de 1.000 túneles VPN: 

Dst en tabla de 

rutas local 

Interfaz de túnel local Puerta de enlace/salto 

siguiente 

(interfaz de túnel de 

interlocutor) 

10.0.3.0/24 tunnel.1 10.0.2.1/24 vpn1 

10.0.5.0/24 tunnel.1 10.0.4.1/24 vpn2 

10.0.7.0/24 tunnel.1 10.0.6.1/24 vpn3 

… … … … 

Túnel VPN 

10.0.251.0/24 tunnel.1 10.0.250.1/24 vpn125 



Dst en tabla de 

rutas local 

Interfaz de túnel local Puerta de enlace/salto 

siguiente 

(interfaz de túnel de 

interlocutor) 

10.1.3.0/24 tunnel.1 10.1.2.1/24 vpn126 

10.1.5.0/24 tunnel.1 10.1.4.1/24 vpn127 

10.1.7.0/24 tunnel.1 10.1.6.1/24 vpn128 

… … … … 

10.1.251.0/24 tunnel.1 10.1.250.1/24 vpn250 

10.2.3.0/24 tunnel.1 10.2.2.1/24 vpn251 

… … … … 

10.2.251.0/24 tunnel.1 10.2.250.1/24 vpn375 

… … … … 

10.7.3.0/24 tunnel.1 10.7.2.1/24 vpn876 

… … … … 

Túnel VPN 

10.7.251.0/24 tunnel.1 10.7.250.1/24 vpn1000 

La interfaz de túnel en el dispositivo NetScreen local es 10.0.0.1/24. En todos los hosts remotos, hay una interfaz de 

túnel con una dirección IP que aparece como la dirección IP de puerta de enlace/salto siguiente en la tabla de rutas 

local y en la tabla NHTB. 

Si desea ver un ejemplo que ilustra la asociación de múltiples túneles a una sola interfaz de túnel con traducción de 

direcciones, consulte “Ejemplo: Múltiples VPNs en una interfaz de túnel para subredes superpuestas” en la 

página 388. 



El dispositivo NetScreen 

local y todos sus 

interlocutores ejecutan la 

traducción de direcciones de 

destino (NAT-dst) con 

desplazamiento de IP en el 

tráfico VPN entrante y 

traducción de direcciones de 

origen (NAT-src) desde la 

dirección IP de interfaz de 

túnel de salida con 

traducción de puertos en el 

tráfico VPN saliente. Para 

10.0.4.1/24 

NAT-dst 10.0.5.1 -> 


internas 

IF 10.0.2.1/24 

NAT-dst 10.0.3.1 -> 


internas 

vpn1 

vpn2 

vpn3 

10.0.6.1/24 

NAT-dst 10.0.7.1 -> 

direcciones IP internas 

10.1.1.1/24 

NAT-dst 10.1.2.1 -> 


vpn251 

internas 

obtener más información 

sobre NAT-src y NAT-dst, 

consulte el Volumen 7, Dispositivo NetScreen 

“Traducción de direcciones”. 

local 

10.0.0.1/24 

vpn751 

10.6.2.1/24 

NAT-dst 10.6.3.1-> 


internas 

NAT-dst 10.0.1.1 -> 


vpn1000 

10.7.250.1/24 

NAT-dst 10.7.251.1 -> 


Entradas de tabla manuales y automáticas 

Puede incluir entradas manualmente en las tablas NHTB y de rutas. También puede automatizar la carga de las 

tablas NHTB y de rutas. Si se va a trabajar con un número pequeño de túneles asociados a una sola interfaz de 

túnel, el método manual puede funcionar bien. Sin embargo, para un gran número de túneles, el método automático 

reduce la configuración y el mantenimiento administrativos, ya que las rutas se ajustan dinámicamente cuando los 

túneles o interfaces dejan de estar disponibles en la interfaz de túnel en la ubicación del concentrador. 

Entradas manuales en la tabla 

Un túnel VPN se puede asignar manualmente a la dirección IP de la interfaz de túnel de un interlocutor remoto en la 

tabla de asociación de túneles a saltos siguientes (NHTB). En primer lugar debe ponerse en contacto con el 

administrador remoto y conocer las direcciones IP utilizadas por la interfaz de túnel en ese extremo del túnel. A 

continuación podrá asociar esta dirección al nombre de túnel VPN en la tabla NHTB con el siguiente comando: 

set interface tunnel.1 nhtb peer’s_tunnel_interface_address vpn name_str 



Una vez hecho esto, podrá introducir una ruta estática en la tabla de rutas que utiliza la dirección IP de interfaz de 

túnel como puerta de enlace. Puede introducir la ruta por medio de la WebUI o con el siguiente comando CLI: 

set vrouter name -str route dst_addr interface tunnel.1 gateway peer’s_tunnel_interface_addr 

Entradas automáticas en la tabla 

Para que la tabla de rutas y la tabla NHTB se rellenen automáticamente, se deben cumplir las siguientes 

condiciones: 

Los interlocutores remotos de todos los túneles VPN asociados a una sola interfaz de túnel local deben ser 

dispositivos NetScreen con ScreenOS 5.0.0. 

Cada interlocutor remoto debe asociar su túnel a una interfaz de túnel, y esa interfaz debe tener una 

dirección IP única entre todas las direcciones de interfaz de túnel de los interlocutores. 

En ambos extremos del túnel VPN, habilite la supervisión de VPN con la opción de reencriptación (Rekey), 

o habilite la opción de nueva conexión de latidos de IKE (IKE Heartbeat Reconnect) para cada puerta de 

enlace remota 14 . 

Los interlocutores locales y remotos deben tener habilitada una instancia de un protocolo de enrutamiento 

dinámico 15 en sus interfaces de túnel de conexión. 

El uso de supervisión de VPN con la opción de reencriptación permite que los dispositivos NetScreen situados en 

ambos extremos de un túnel puedan establecer el túnel sin tener que esperar a que haya tráfico VPN originado por 

el usuario 16 . Una vez habilitada la supervisión de VPN con la opción de reencriptación a los dos lados de un túnel 

VPN, los dos dispositivos NetScreen llevarán a cabo las negociaciones IKE de fase 1 y 2 para establecer el túnel. 

(Para obtener más información, consulte “Supervisión de VPNs” en la página 361). 

14. Si se ejecuta un protocolo de enrutamiento dinámico en las interfaces de túnel, el tráfico generado por el protocolo puede desencadenar negociaciones IKE 

aunque no se habilite la supervisión de VPN con la opción de reencriptación o la opción de nueva conexión de latidos de IKE. En cualquier caso, Juniper 

Networks recomienda no confiar en que el tráfico de enrutamiento dinámico desencadene las negociaciones IKE. En lugar de ello, utilice la supervisión de 

VPN con la opción de reencriptación o de nueva conexión de latidos de IKE. 

15. Para OSPF (“Open Shortest Path First” = “abrir primero la ruta más corta”), debe configurar la interfaz de túnel en el interlocutor local como interfaz “punto 

a multipunto” antes de activar el protocolo de enrutamiento en la interfaz. 

16. En el caso de interlocutores remotos con una dirección IP externa asignada dinámicamente o con un nombre de dominio completo (FQDN) asignado a una 

dirección IP dinámica, el interlocutor remoto primero debe iniciar las negociaciones IKE. Sin embargo, dado que la asociación de seguridad de fase 2 en el 

dispositivo NetScreen local guarda en caché la dirección IP asignada dinámicamente del interlocutor remoto, cada interlocutor puede reiniciar las 

negociaciones IKE para restablecer un túnel cuyo estado de supervisión de VPN haya cambiado de activo a inactivo. 



Durante las negociaciones de fase 2, los dispositivos NetScreen intercambian entre sí direcciones IP de interfaz de 

túnel. Cada módulo IKE puede introducir automáticamente la dirección IP de interfaz de túnel y su nombre de túnel 

VPN correspondiente en la tabla NHTB. 

Para hacer que el dispositivo NetScreen pueda introducir rutas a destinos remotos automáticamente en esta tabla 

de rutas, debe habilitar una instancia de BGP en las interfaces de túnel locales y remotas. Los pasos básicos son 

los siguientes: 

1. Crear una instancia de enrutamiento BGP en el enrutador virtual que contiene la interfaz de túnel a la que 

se han asociado múltiples túneles VPN. 

2. Habilitar la instancia de enrutamiento en el enrutador virtual. 

3. Habilitar la instancia de enrutamiento en la interfaz de túnel que conduce a los interlocutores BGP. 

Los interlocutores remotos también llevan a cabo estos pasos. 

En el dispositivo local (o concentrador), también debe definir una ruta predeterminada y una ruta estática a cada 

dirección IP de interfaz de túnel de los interlocutores. Las rutas estáticas a las interfaces de túnel de los 

interlocutores son necesarias para que el dispositivo concentrador pueda acceder inicialmente a sus vecinos BGP a 

través del túnel VPN correcto. 

Después de establecer las comunicaciones, los vecinos BGP intercambian información de enrutamiento, de forma 

que pueden rellenar automáticamente sus tablas de rutas. Una vez que los dos interlocutores establecen un túnel 

VPN entre sí, pueden enviar y recibir información de enrutamiento desde y hacia el dispositivo local. Cuando la 

instancia de enrutamiento dinámico en el dispositivo NetScreen aprende una ruta a un interlocutor a través de un 

interfaz de túnel local, incluye la dirección IP de la interfaz de túnel del interlocutor remoto como puerta de enlace en 

la ruta. 

Para ver un ejemplo que ilustra la configuración de múltiples túneles asociados a una única interfaz de túnel, donde 

el dispositivo “concentrador” rellena sus tablas NHTB y de rutas automáticamente, consulte “Ejemplo: Entradas 

automáticas en la tabla de rutas y la tabla NHTB” en la página 420. 



Ejemplo: Múltiples VPNs en una interfaz de túnel para subredes superpuestas 

En este ejemplo asociaremos tres túneles VPN AutoKey IKE basados en rutas (vpn1, vpn2 y vpn3) a una sola 

interfaz de túnel (tunnel.1). Los túneles van de NetScreen A a tres interlocutores remotos: peer1, peer2 y peer3. Las 

entradas de las tablas NHTB y de rutas para los tres interlocutores se agregarán manualmente a NetScreen A. 

La interfaz tunnel.1 de NetScreen-A se asocia a tres túneles VPN. 

Nota: La zona Trust de 

NetScreen-A no se muestra. 

Zona Trust 

ethernet1 

10.1.1.1/24 


tunnel.1 

10.0.0.1/30 

Conjunto de DIP 5: 

10.0.0.2 - 10.0.0.2 

ethernet3 

1.1.1.1/24 

Enrutador 

externo 

1.1.1.250 

vpn1 

vpn2 

vpn3 

Zona Untrust 

peer1 

Las configuraciones de túnel VPN a ambos extremos de cada túnel utilizan los siguientes parámetros: AutoKey IKE, 

clave previa compartida (peer1: “netscreen1”, peer2: “netscreen2”, peer3: “netscreen3”) y el nivel de seguridad 

predefinidos como “Compatible” para las propuestas de fase 1 y fase 2. (Para ver los detalles sobre estas 

propuestas, consulte “Negociación de túnel” en la página 11). 

Todas las zonas de seguridad e interfaces en cada dispositivo se encuentran en el dominio de enrutamiento virtual 

trust-vr del dispositivo correspondiente. 

En este ejemplo se utiliza el mismo espacio de direcciones (10.1.1.0/24) en cada LAN para mostrar cómo se puede 

utilizar la traducción de direcciones de red de origen y destino (NAT-src y NAT-dst) para evitar problemas de 

direccionamiento entre los interlocutores IPSec. Para obtener más información sobre NAT-src y NAT-dst, consulte 

el Volumen 7, “Traducción de direcciones”. 


peer3 

peer2 

LAN 

LAN 

vpn1 

Puerta de enlace IKE: peer1, 2.2.2.2 

Interfaz de túnel del interlocutor remoto: 

10.0.2.1 

LAN 

vpn2 

Puerta de enlace IKE: peer2, 

3.3.3.3 

Interfaz de túnel del 

interlocutor remoto: 10.0.4.1 

vpn3 


Interfaz de túnel del interlocutor remoto: 

10.0.6.1



1. Interfaces 

















ID: 5 











Zone: Trust 


Address Name: oda1 



Zone: Trust 


3. VPNs 

Address Name: peers 



Zone: Untrust 





Gateway Name: peer1 













Service: ANY 


















Service: ANY 
















Service: ANY 

4. Rutas 

Network > Routing > Routing Entries > (trust-vr) New: Introduzca los siguientes datos y haga clic en OK : 















































Interface: null 


Metric: 10 



Network > Interfaces > Edit (para tunnel.1) > NHTB > New: Introduzca los siguientes datos y haga clic en 

Add : 

New Next Hop Entry: 


VPN: vpn1 

Network > Interfaces > Edit (para tunnel.1) > NHTB: Introduzca los siguientes datos y haga clic en Add : 



VPN: vpn2 

Network > Interfaces > Edit (para tunnel.1) > NHTB: Introduzca los siguientes datos y haga clic en Add : 

5. Directivas 



VPN: vpn3 



Address Book: (seleccione), corp 


Address Book: (seleccione), peers 

Service: Any 




Return para regresar a la página de configuración básica de directivas: 

NAT: 


DIP On: 5 (10.0.0.2–10.0.0.2)/X-late 






Address Book Entry: (seleccione), peers 


Address Book Entry: (seleccione), oda1 

Service: Any 



1. Interfaces 









set address trust corp 10.1.1.0/24 

set address trust oda1 10.0.1.0/24 

set address untrust peers 10.0.0.0/16 



NAT: 


Translate to IP Range: (seleccione), 10.1.1.0 - 10.1.1.254 



3. VPNs 

set ike gateway peer1 address 2.2.2.2 outgoing-interface ethernet3 preshare 


set vpn vpn1 gateway peer1 sec-level compatible 













4. Rutas 


set vrouter trust-vr route 10.0.1.0/24 interface ethernet1 

set vrouter trust-vr route 10.0.3.0/24 interface tunnel.1 gateway 10.0.2.1 







set interface tunnel.1 nhtb 10.0.2.1 vpn vpn1 





5. Directivas 

set policy from trust to untrust corp peers any nat src dip-id 5 permit 

set policy from untrust to trust peers oda1 any nat dst ip 10.1.1.0 10.1.1.254 

permit 

save 



Peer1 

La siguiente configuración es la que el administrador remoto del dispositivo NetScreen en la ubicación peer1 debe 

introducir para crear un túnel VPN a NetScreen en la empresa. El administrador remoto configura el dispositivo 

NetScreen para que realice NAT en el origen y en el destino (NAT-src y NAT-dst) porque las direcciones internas se 

encuentran en el mismo espacio de direcciones que las de la LAN corporativa: 10.1.1.0/24. Peer1 lleva a cabo 

NAT-src utilizando el conjunto de DIP 6 para traducir todas las direcciones de origen internas a 10.0.2.2 al enviar 

tráfico a través de VPN1 a NetScreen-A. Peer1 lleva a cabo NAT-dst en el tráfico VPN enviado desde NetScreen-A, 

traduciendo las direcciones de 10.0.3.0/24 a 10.1.1.0/24 con desplazamiento de direcciones. 

Zona Untrust 

vpn1 desde 


WebUI (Peer1) 

1. Interfaces 

ethernet3 

2.2.2.2/24 

Enrutador 

externo 

2.2.2.250 

tunnel.10 

10.0.2.1/30 

Conjunto de DIP 6 

10.0.2.2 - 10.0.2.2 

Peer1 

Nota: Para obtener más información sobre NAT-src y NAT-dst, consulte el Volumen 7, “Traducción de direcciones”. 







ethernet1 

10.1.1.1/24 

Rango NAT-dst 

10.0.3.0 – 10.0.3.255 

Zona Trust 

LAN 

10.1.1.0/24 

NAT-dst de 

10.0.3.0 – 10.0.3.255 

a 

10.1.1.0 – 10.1.1.255 

con desplazamiento de 

direcciones 












Network > Interfaces > Edit (para tunnel.10) > DIP > New: Introduzca los siguientes datos y haga clic en 

OK : 

ID: 6 






Address Name: lan 



Zone: Trust 



3. VPN 





Zone: Trust 


Address Name: to_corp 



Zone: Untrust 


Address Name: fr_corp 



Zone: Untrust 


















Service: ANY 

4. Rutas 






Metric: 1 






Metric: 1 








Metric: 10 


5. Directivas 





Metric: 12 



Address Book Entry: (seleccione), fr_corp 



Service: Any 







NAT: 





Address Book Entry: (seleccione), lan 


Address Book Entry: (seleccione), to_corp 

Service: Any 





NAT: 


DIP On: 6 (10.0.2.2–10.0.2.2)/X-late 



CLI (Peer1) 

1. Interfaces 









set address trust lan 10.1.1.0/24 


set address untrust to_corp 10.0.1.0/24 

set address untrust fr_corp 10.0.0.2/32 

3. VPN 

set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare 





4. Rutas 

set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 2.2.2.250 metric 1 

set vrouter trust-vr route 10.0.3.0/24 interface ethernet1 metric 1 

set vrouter trust-vr route 10.0.0.0/8 interface tunnel.10 metric 10 


5. Directivas 

set policy from trust to untrust lan to_corp any nat src dip-id 6 permit 

set policy from untrust to trust fr_corp oda2 any nat dst ip 10.1.1.0 

10.1.1.254 permit 

save 



Peer2 







traduciendo las direcciones de 10.0.5.0/24 a 10.1.1.0/24 con desplazamiento de direcciones. ethernet3 

ethernet3 

3.3.3.3/24 


3.3.3.250 

Zona Untrust 

vpn2 desde 


WebUI (Peer2) 

tunnel.20 

10.0.4.1/30 


10.0.4.2 - 10.0.4.2 

Peer2 

Nota: Para obtener más información sobre NAT-src y NAT-dst, consulte el Volumen 7, “Traducción de direcciones”. 

1. Interfaces 







ethernet1 

10.1.1.1/24 

Rango NAT-dst 

10.0.5.0 – 10.0.5.255 

Zona Trust 

LAN 

10.1.1.0/24 

NAT-dst de 

10.0.5.0 – 10.0.5.255 

a 

10.1.1.0 – 10.1.1.255 


direcciones 














ID: 7 








Zone: Trust 



3. VPN 





Zone: Trust 





Zone: Untrust 





Zone: Untrust 


















Service: ANY 

4. Rutas 






Metric: 1 






Metric: 1 








Metric: 10 


5. Directivas 





Metric: 12 






Service: Any 







NAT: 


DIP On: 7 (10.0.4.2–10.0.4.2)/X-late 






Service: Any 





NAT: 





CLI (Peer2) 

1. Interfaces 













3. VPN 






4. Rutas 





5. Directivas 



10.1.1.254 permit 

save 



Peer3 







traduciendo las direcciones de 10.0.7.0/24 a 10.1.1.0/24 con desplazamiento de direcciones. 

ethernet3 

4.4.4.4/24 


4.4.4.250 

Zona Untrust 

vpn3 desde 


WebUI (Peer3) 

tunnel.30 

10.0.6.1/30 


10.0.6.2 - 10.0.6.2 

Peer3 

Nota: Para obtener más información sobre NAT-dst, consulte el Volumen 7, “Traducción de direcciones”. 

1. Interfaces 







ethernet1 

10.1.1.1/24 

Rango NAT-dst 

10.0.7.0 – 10.0.7.255 

Zona Trust 

LAN 

10.1.1.0/24 

NAT-dst de 

10.0.7.0 – 10.0.7.255 

a 

10.1.1.0 – 10.1.1.255 


direcciones 



Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes datos y haga clic en OK: 




Network > Interfaces > New Tunnel IF: Introduzca los siguientes datos y haga clic en OK: 





Network > Interfaces > Edit (para tunnel.30) > DIP > New: Introduzca los siguientes datos y haga clic en 

OK: 

ID: 7 





Objects > Addresses > List > New: Introduzca los siguientes datos y haga clic en OK: 




Zone: Trust 



3. VPN 





Zone: Trust 





Zone: Untrust 





Zone: Untrust 


















Service: ANY 

4. Rutas 






Metric: 1 






Metric: 1 








Metric: 10 


5. Directivas 





Metric: 12 






Service: Any 







NAT: 


DIP On: 8 (10.0.6.2–10.0.6.2)/X-late 






Service: Any 





NAT: 





CLI (Peer3) 

1. Interfaces 













3. VPN 






4. Rutas 





5. Directivas 



10.1.1.254 permit 

save 



Ejemplo: Entradas automáticas en la tabla de rutas y la tabla NHTB 

En este ejemplo asociaremos dos túneles VPN AutoKey IKE basados en rutas (vpn1 y vpn2) a una sola interfaz de 

túnel (tunnel.1) en NetScreen-A, ubicado en la empresa. La red que cada interlocutor remoto protege tiene múltiples 

rutas tras la ruta conectada. Al utilizar BGP (Border Gateway Protocol), los interlocutores comunican sus rutas a 

NetScreen-A. Este ejemplo permite el tráfico VPN desde la ubicación corporativa tras NetScreen-A a los 

interlocutores. 

Nota: En este ejemplo también puede utilizar OSPF (“Open Shortest Path First” = “abrir primero la ruta más corta”) 

en lugar de BGP como protocolo de enrutamiento. Consulte “Anexo al ejemplo: OSPF para entradas automáticas 

en la tabla de rutas” en la página 438 para ver las configuraciones de OSPF. 

La interfaz tunnel.1 de NetScreen-A se 

asocia a dos túneles VPN. 

Zona Trust 

ethernet1 

10.1.1.1/24 


tunnel.1 

10.0.0.1/30 

Nota: La zona Trust de 

NetScreen-A no se muestra. 

ethernet3 

1.1.1.1/24 

Enrutador 

externo 

1.1.1.250 

vpn1 


Interfaz de túnel del interlocutor remoto: 2.3.3.1 

vpn1 

vpn2 

Zona Untrust 


peer1 

peer2 

vpn2 


Interfaz de túnel del interlocutor remoto: 3.4.4.1 

? 

? 

Las rutas tras cada interlocutor son 

desconocidas para NetScreen-A 

hasta que los interlocutores utilizan 

BGP para enviarlas. 

? 

? 

? 

?


Las configuraciones de túnel VPN a ambos extremos de cada túnel utilizan los siguientes parámetros: AutoKey IKE, 

clave previa compartida (peer1: “netscreen1”, peer2: “netscreen2”) y el nivel de seguridad predefinido como 

“Compatible” para las propuestas de fase 1 y fase 2. (Para ver los detalles sobre estas propuestas, consulte 

“Negociación de túnel” en la página 11). 

Al configurar las dos siguientes funciones, puede habilitar NetScreen A para rellenar sus tablas de rutas y NHTB 

automáticamente 17 . 

Supervisión de VPN con la opción de reencriptación (o de nueva conexión de latidos de IKE) 18 

Enrutamiento dinámico BGP en tunnel.1 

Cuando se activa la supervisión de VPN con la opción de reencriptación para un túnel VPN AutoKey IKE, 

NetScreen A establece una conexión VPN con su interlocutor remoto en el momento en que usted y el 

administrador en la ubicación remota terminan de configurar el túnel. Los dispositivos no esperan a que aparezca 

tráfico VPN generado por el usuario para iniciar las negociaciones IKE. Durante las negociaciones de fase 2, el 

dispositivo NetScreen intercambia su dirección IP de interfaz de túnel, de forma que NetScreen A realiza 

automáticamente una asociación de la VPN al siguiente salto en su tabla NHTB. 

La opción de reencriptación garantiza que cuando finalice el periodo de validez de las claves de fase 1 y 2, los 

dispositivos negociarán automáticamente la generación de nuevas claves sin que ningún usuario tenga que 

intervenir. La supervisión de VPN con la opción de reencriptación habilitada ofrece básicamente una forma de 

conservar siempre activo un túnel VPN, aun cuando no haya tráfico generado por usuario. Esto es necesario para 

que las instancias de enrutamiento dinámico BGP, que usted y el administrador crean y habilitan en las interfaces 

de túnel a ambos lados de los túneles, puedan enviar información de enrutamiento a NetScreen y rellenen 

automáticamente su tabla de rutas con las rutas que necesita para dirigir el tráfico a través del túnel VPN antes de 

que esas rutas sean necesarias para el tráfico generado por el usuario. (Los administradores en las ubicaciones de 

los interlocutores tienen que introducir una única ruta estática al resto de la red privada virtual a través de la interfaz 

de túnel en cada ubicación). 

17. Si se ejecuta un protocolo de enrutamiento dinámico en las interfaces de túnel, el tráfico generado por el protocolo puede desencadenar negociaciones IKE 

aunque no se habilite la supervisión de VPN con la opción de reencriptación o la opción de nueva conexión de latidos de IKE. En cualquier caso, Juniper 

Networks recomienda no confiar en que el tráfico de enrutamiento dinámico desencadene las negociaciones IKE. En lugar de ello, utilice la supervisión de 

VPN con la opción de reencriptación o de nueva conexión de latidos de IKE. 

18. Si las interfaces de túnel se ejecutan con BGP, el tráfico generado por BGP puede desencadenar negociaciones IKE aun cuando no se habilite la supervisión 

de VPN con la opción de reencriptación o la opción de nueva conexión de latidos de IKE. En cualquier caso, Juniper Networks recomienda no confiar en 

que el tráfico BGP desencadene las negociaciones IKE. En lugar de esto, utilice la supervisión de VPN con la opción de reencriptación o de nueva conexión 

de latidos de IKE. 



Debe introducir una ruta predeterminada y rutas estáticas en NetScreen-A para acceder a sus vecinos BGP a 

través de los túneles VPN adecuados. Todas las zonas de seguridad e interfaces en cada dispositivo se encuentran 

en el dominio de enrutamiento virtual trust-vr del dispositivo correspondiente. 


1. Interfaces 


















2. VPNs 
















Service: ANY 

VPN Monitor 19 : (seleccione) 

Rekey: (seleccione) 





19. Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP de destino. Para obtener más información sobre estas opciones, consulte 

“Supervisión de VPNs” en la página 361. 














Service: ANY 

VPN Monitor 20 : (seleccione) 

Rekey: (seleccione) 

3. Ruta estática 








20. Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP de destino. Para obtener más información sobre estas opciones, consulte 

“Supervisión de VPNs” en la página 361. 







4. Enrutamiento dinámico 





Network > Routing > Virtual Routers > Edit (para trust-vr) > Create BGP Instance: Introduzca los siguientes 

datos y haga clic en OK : 

AS Number (obligatorio): 99 

BGP Enabled: (seleccione) 

Network > Interfaces > Edit (para tunnel.1) > BGP: Seleccione la casilla de verificación Protocol BGP y, a 

continuación, haga clic en OK . 

Network > Routing > Virtual Routers > Edit (para trust-vr) > Edit BGP Instance > Neighbors: Introduzca los 

siguientes datos y haga clic en Add : 

AS Number: 99 

Remote IP: 2.3.3.1 

Outgoing Interface: tunnel.1 



AS Number: 99 





5. Directiva 



1. Interfaces 


Address Book: (seleccione), Any 


Address Book: (seleccione), Any 

Service: ANY 









2. VPNs 






set vpn vpn1 monitor rekey 








set vpn vpn2 monitor rekey 

3. Rutas estáticas 





ns-> set vrouter trust-vr protocol bgp 99 

ns-> set vrouter trust-vr protocol bgp enable 

ns-> set interface tunnel.1 protocol bgp 

ns-> set vrouter trust-vr 

ns(trust-vr)-> set protocol bgp 

ns(trust-vr/bgp)-> set neighbor 2.3.3.1 remote-as 99 outgoing interface 

tunnel.1 

ns(trust-vr/bgp)-> set neighbor 2.3.3.1 enable 


tunnel.1 


ns(trust-vr/bgp)-> exit 

ns(trust-vr)-> exit 

5. Directiva 

set policy from trust to untrust any any any permit 

save 



Peer1 


introducir para crear un túnel VPN a NetScreen-A en la empresa. El administrador remoto configura el dispositivo 

NetScreen para permitir el tráfico entrante desde el sitio corporativo. También configura el dispositivo NetScreen 

para comunicar rutas internas a su vecino BGP a través de vpn1. 

WebUI (Peer1) 

Zona Untrust 

vpn1 desde 


ethernet3 

2.2.2.2/24 

Enrutador 

externo 

2.2.2.250 

tunnel.10 

2.3.3.1/30 

Peer1 

1. Interfaces 







ethernet1 

2.3.4.1/24 



2.3.4.0/24 

Zona Trust 


2.3. 

2.3.



2. Dirección 

3. VPN 









Zone: Untrust 


















Service: ANY 







Metric: 1 







Metric: 1 











AS Number: 99 



6. Directiva 


CLI (Peer1) 





Service: ANY 


1. Interfaces 







2. Dirección 




3. VPN 
















tunnel.10 




6. Directiva 

set policy from untrust to trust corp any any permit 

save 



Peer2 



NetScreen para permitir el tráfico entrante desde el sitio corporativo. También configura el dispositivo NetScreen 

para comunicar rutas internas a su vecino BGP a través de vpn2. 

vpn2 desde 


WebUI (Peer2) 

Zona Untrust 

ethernet3 

3.3.3.3/24 


3.3.3.250 

tunnel.20 

3.4.4.1/30 

1. Interfaces 



Peer2 

ethernet1 

3.4.5.1/24 







3 .4.5.0/24 

Zona Trust 


3.4. 

3.4.



2. Dirección 

3. VPN 









Zone: Untrust 


















Service: ANY 







Metric: 1 






Metric: 1 












AS Number: 99 



6. Directiva 


CLI (Peer2) 





Service: ANY 


1. Interfaces 









2. Dirección 


3. VPN 
















tunnel.20 




6. Directiva 

set policy from untrust to trust corp any any permit 

save 



Anexo al ejemplo: OSPF para entradas automáticas en la tabla de rutas 

También puede configurar OSPF en lugar del enrutamiento dinámico BGP para que los interlocutores comuniquen 

sus rutas a NetScreen-A. Para permitir que tunnel.1 en NetScreen-A pueda formar adyacencias OSPF con sus 

interlocutores, debe configurar la interfaz de túnel como interfaz "punto a multipunto". La configuración de 

enrutamiento dinámico OSPF para cada dispositivo se muestra a continuación. 


Enrutamiento dinámico (OSPF) 

Network > Routing > Virtual Routers > Edit (para trust-vr) > Create OSPF Instance: Seleccione OSPF 

Enabled y haga clic en Apply . 

Area > Configure (para el área 0.0.0.0): Haga clic en Interfaces > Edit (para tunnel.1) > OSPF: Introduzca los siguientes datos y haga clic en Apply : 



Bind to Area: (seleccione), Seleccione 0.0.0.0 en la lista desplegable 

Protocol OSPF: Enable 

Link Type: Point-to-Multipoint (seleccione) 

ns-> set vrouter trust-vr protocol ospf 

ns-> set vrouter trust-vr protocol ospf enable 

ns-> set interface tunnel.1 protocol ospf area 0 

ns-> set interface tunnel.1 protocol ospf link-type p2mp 

ns-> set interface tunnel.1 protocol ospf enable 

ns-> save 



WebUI (Peer1) 




Area > Configure (para el área 0.0.0.0): Haga clic en Interfaces > Edit (para tunnel.1) > OSPF: Introduzca los siguientes datos y haga clic en Apply : 

CLI (Peer1) 








ns-> save 

WebUI (Peer2) 




Area > Configure (para el área 0.0.0.0): Haga clic en


Network > Interfaces > Edit (para tunnel.1) > OSPF: Introduzca los siguientes datos y haga clic en Apply : 

CLI (Peer2) 








ns-> save 


Capítulo 7 Funciones de VPN avanzadas Puertas de enlace VPN redundantes 

PUERTAS DE ENLACE VPN REDUNDANTES 

La función de puertas de enlace redundantes NetScreen ofrece una solución para la conectividad VPN continua 

durante y después de una conmutación por error punto a punto. Es posible crear un grupo VPN para proporcionar 

un grupo de hasta cuatro puertas de enlace redundantes a la que se pueden conectar túneles VPN AutoKey IKE 

IPSec 21 de interlocutor dinámico punto a punto o punto a punto basados en directivas. Cuando el dispositivo 

NetScreen recibe por primera vez tráfico que coincide con una directiva relativa a un grupo VPN, realiza las 

negociaciones IKE de fase 1 y fase 2 con todos los miembros de ese grupo. El dispositivo NetScreen envía datos a 

través del túnel VPN a la puerta de enlace con la mayor prioridad (o “peso”) del grupo. Para todas las demás 

puertas de enlace del grupo, el dispositivo NetScreen actualiza las asociaciones de seguridad de fase 1 y 2 y 

mantiene activos los túneles enviando a través de ellos paquetes de mantenimiento de conexión IKE. Si el túnel 

VPN activo falla, puede producir una conmutación por error al túnel y la puerta de enlace con el segundo nivel de 

prioridad del grupo. 

Nota: En este esquema se asume que los sitios situados detrás de las puertas de enlace redundantes están 

conectados de tal forma que los datos se replican entre los hosts de todos los sitios. Además, cada sitio (al ser 

dedicado para alta disponibilidad) tiene un conjunto redundante de dispositivos NetScreen que funcionan en modo 

de alta disponibilidad. Así, el límite de conmutación por fallo de VPN que se ajuste debe ser mayor que el límite de 

conmutación por error del dispositivo o se podrían producir conmutaciones por error innecesarias. 

= Datos 

= Latidos de IKE 

Grupo VPN, ID 1 Grupo VPN, ID 1 

(Después de una conmutación por error de VPN) 

21. Los grupos VPN no admiten L2TP, L2TP-sobre-IPSec, acceso telefónico, clave manual ni tipos de túneles VPN basados en rutas. En una configuración de 

interlocutores dinámicos punto a punto, el dispositivo NetScreen que supervisa el grupo VPN debe tener la dirección IP Untrust asignada dinámicamente, 

mientas que las direcciones IP de los miembros del grupo VPN deben ser estáticas. 



Grupos VPN 

Un grupo VPN es un conjunto de configuraciones de túnel VPN para hasta cuatro puertas de enlace remotas de 

destino. Los parámetros de asociación de seguridad (SA) de fase 1 y fase 2 para cada túnel de un grupo pueden 

ser distintos o idénticos (excepto en el caso de la dirección IP de la puerta de enlace remota, que, lógicamente, 

debe ser diferente). El grupo VPN tiene un número de ID inequívoco, y a cada miembro del grupo se le asigna un 

peso inequívoco para indicar su lugar en el rango de preferencia para convertirse en el túnel activo. Un valor de 1 

constituye el rango inferior o de menor preferencia. 

Nota: En esta ilustración, el 

sombreado simboliza el peso de 

cada túnel. Cuanto más oscuro 

sea el sombreado de un túnel, 

mayor será su prioridad. 

El dispositivo NetScreen que se comunica con los miembros del grupo VPN y los propios miembros tienen una 

relación supervisor/destino. El dispositivo de supervisión supervisa continuamente la conectividad y el correcto 

estado de cada dispositivo de destino. El supervisor utiliza las siguientes herramientas para ello: 

Latidos de IKE 

Intentos de recuperación de IKE 

Supervisor 

Grupo VPN 1 Peso 

4 

D 

Ambas herramientas se describen en la sección siguiente, “Mecanismos de supervisión” en la página 443. 

Nota: La relación supervisor/destino no tiene por qué ser de un solo sentido. El dispositivo de supervisión también 

puede ser un miembro de un grupo VPN y, por tanto, ser a su vez el destino de otro dispositivo de supervisión. 


e 

s 

t 

i 

n 

o 

3 

2 

1


Mecanismos de supervisión 

NetScreen utiliza dos mecanismos para supervisar los miembros de un grupo VPN con el fin de determinar su 

capacidad para terminar tráfico VPN: 


Intentos de recuperación de IKE 

Utilizando estas dos herramientas junto con la opción de conmutación por error de aplicación TCP (consulte 

“Comprobación de flag TCP SYN” en la página 447), los dispositivos NetScreen pueden detectar si es necesario 

realizar una conmutación por error de la VPN y desviar el tráfico al nuevo túnel sin tener que interrumpir el servicio 

de VPN. 


Los latidos de IKE son mensajes de saludo que los interlocutores IKE se envían mutuamente bajo la protección de 

una asociación de seguridad (SA) de fase 1 establecida para confirmar la conectividad y el correcto estado del otro. 

Por ejemplo, si device_m (el “supervisor”) no recibe un determinado número de latidos (el valor predeterminado es 

5) de device_t (el “destino”), device_m llega a la conclusión de que device_t está inactivo. Device_m elimina de su 

memoria caché las asociaciones de seguridad (SAs) de fase 1 y fase 2 correspondientes y comienza el 

procedimiento de recuperación IKE. (Consulte “Procedimiento de recuperación IKE” en la página 444). 

Device_t también elimina sus SAs. 

Nota: La función de latidos de IKE debe estar habilitada en los dispositivos ubicados a ambos extremos de un túnel 

VPN en un grupo VPN. Si está habilitada en device_m pero no en device_t, device_m suprime la transmisión de 

latidos de IKE y genera el siguiente mensaje en el registro de eventos: “Heartbeats have been disabled because 

the peer is not sending them” (los latidos se han desactivado porque el interlocutor no los está enviando). 

Los latidos de IKE deben fluir en ambos 

sentidos a través del túnel VPN. 



Para definir el intervalo de latidos de IKE y el umbral para un túnel VPN específico (el valor predeterminado es 5), 

realice los siguientes pasos: 

WebUI 

CLI 

VPNs > AutoKey Advanced > Gateway > Edit (para la puerta de enlace cuyo umbral de latidos de IKE 

desee modificar) > Advanced: Introduzca los valores nuevos en los campos “Heartbeat Hello” y “Heartbeat 

Threshold” y haga clic en OK. 

set ike gateway name_str heartbeat hello number 

set ike gateway name_str heartbeat threshold number 

Procedimiento de recuperación IKE 

Después de que el dispositivo NetScreen de supervisión haya determinado que un dispositivo de destino está 

inactivo, el supervisor deja de enviar latidos de IKE y elimina las SA para dicho interlocutor de su caché de SA. Tras 

un intervalo definido, el supervisor intenta iniciar negociaciones de fase 1 con el interlocutor fallido. Si el primer 

intento no tiene éxito, el supervisor continúa intentando establecer negociaciones de fase 1 a intervalos regulares 

hasta que obtiene resultados satisfactorios. 



Para definir el intervalo de recuperación IKE para un túnel VPN específico (el ajuste mínimo es 60 segundos), 

realice uno de los siguientes pasos: 

WebUI 

CLI 

Intervalo: 

5 minutos 

(300 segundos) . .. 

Supervisor 

Intentos de 

negociación de fase 1 

IKE cada 5 minutos Destino 

. 

VPNs > AutoKey Advanced > Gateway > Edit (para la puerta de enlace cuyo intervalo de reconexión de IKE 

desee modificar) > Advanced: Introduzca el valor en segundos en el campo Heartbeat Reconnect y haga 

clic en OK. 

set ike gateway name_str heartbeat reconnect number 

. 

. 

Intento fallido 

Intento fallido 

Intento con éxito 

Cuando el miembro con el mayor peso de un grupo VPN realiza una conmutación por error del túnel a otro miembro 

del grupo y, a continuación, conecta de nuevo con el dispositivo de supervisión, se realiza automáticamente una 

conmutación por recuperación del túnel al primer miembro. El sistema de ponderación hace que la puerta de enlace 

que tiene la mayor valoración del grupo se encargue siempre de gestionar los datos VPN si es posible. 


. 

.


En la siguiente ilustración se muestra el proceso al que se somete un miembro de un grupo VPN cuando la 

ausencia de latidos de una puerta de enlace de destino sobrepasa el umbral de fallo. 

1. 

2. 

3. 

4. 

5. 

Supervisor Destino 

Latidos IKE en ambos sentidos 

El destino deja de enviar latidos IKE. 

El supervisor realiza una conmutación por error de la VPN (si el destino estaba 

gestionando datos VPN), elimina las SA de fase 1 y fase 2 e intenta establecer 

de nuevo el túnel VPN con los intervalos especificados. 

El destino responde a la iniciación de fase 1 con latidos IKE habilitados. 

Las negociaciones de fase 1 y fase 2 IKE tienen éxito, el túnel se 

salvaguarda y se realiza una conmutación por recuperación de la 

VPN (si su peso da preferencia a otros miembros del grupo VPN). 



Comprobación de flag TCP SYN 

Para que se produzca una conmutación por error VPN gradual, el manejo de las sesiones TCP debe estar 

direccionado. Si, después de una conmutación por error, la nueva puerta de enlace activa recibe un paquete 

durante una sesión TCP existente, la nueva puerta de enlace lo gestiona como si fuera el primer paquete de una 

sesión TCP nueva y comprueba si el flag SYN está activado en el encabezado del paquete. Como este paquete en 

realidad forma parte de una sesión existente, no tiene el flag SYN activado. En consecuencia, la nueva puerta de 

enlace rechaza el paquete. Con la comprobación de flag TCP SYN habilitada, todas las aplicaciones TCP se tienen 

que reconectar después de que se produzca la conmutación por error. 

Para resolver este problema, puede inhabilitar la comprobación de flag SYN para las sesiones TCP en túneles VPN 

del siguiente modo: 

WebUI 

CLI 

No es posible inhabilitar la comprobación de flag SYN mediante la WebUI. 

unset flow tcp-syn-check-in-tunnel 

Nota: De forma predeterminada, la comprobación de flag SYN está habilitada. 



Ejemplo: Puertas de enlace VPN redundantes 

En este ejemplo, un sitio corporativo tiene un túnel VPN que conecta con un centro de datos y un segundo túnel que 

conecta con un centro de datos de respaldo. Todos los datos se replican a través de una conexión de línea punto a 

punto entre los dos centros de datos. Los centros de datos están separados físicamente para proporcionar un 

servicio continuo, incluso en caso de fallo catastrófico, como un corte de corriente de 24 horas o una catástrofe 

natural. 

El nombre y la ubicación del dispositivo, las interfaces físicas y sus direcciones IP para las zonas Trust y Untrust, y 

la ID de grupo VPN y el peso de cada dispositivo NetScreen son los siguientes: 

Ubicación 

del dispositivo 

Nombre del 

dispositivo 

Interfaz física y 

dirección IP 

(zona Trust) 

Interfaz física, 

dirección IP, puerta de enlace 

predeterminada 

(zona Untrust) 

ID de grupo 

VPN y peso 

Empresa Monitor1 ethernet1, 10.10.1.1/24 ethernet3, 1.1.1.1/24, (GW) 1.1.1.2 – – 

Centro de datos (primario) Target1 ethernet1, 10.1.1.1/16 ethernet3, 2.2.2.1/24, (GW) 2.2.2.2 ID = 1, Peso = 2 

Centro de datos (de 

respaldo) 

Target2 ethernet1, 10.1.1.1/16 ethernet3, 3.3.3.1/24, (GW) 3.3.3.2 ID = 1, Peso = 1 

Nota: El espacio de direcciones interno en ambos centros de datos debe ser idéntico. 

Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr. Todos los túneles AutoKey IKE 

punto a punto utilizan el nivel de seguridad predefinido como “Compatible” para propuestas de fase 1 y fase 2. Las 

claves previamente compartidas autentican a los participantes. 



Nota: Las zonas de seguridad y los enrutadores 

externos no se muestran en esta ilustración. 

10.10.1.0/24 

Sitio corporativo 

WebUI (Monitor1) 

1. Interfaces 

Trust, eth1 

10.10.1.1/24 

Monitor1 

Untrust, eth3 

1.1.1.1/24 







Untrust, eth3 

2.2.2.1/24 

Untrust, eth3 

3.3.3.1/24 

Target1 

Internet 

Target2 

Trust, eth1 

10.1.1.1/16 

Trust, eth1 

10.1.1.1/16 

10.1.0.0/16 

10.1.0.0/16 

Sitio primario del 

centro de datos 

Línea punto a 

punto para la 

réplica de datos 

del sitio primario 

al sitio de 

respaldo 

Sitio de copia 

de seguridad 

del centro de 

datos 









Address Name: in_trust 



Zone: Trust 


3. VPNs 

Address Name: data_ctr 



Zone: Untrust 

VPNs > AutoKey Advanced > VPN Group: Introduzca 1 en el campo VPN Group ID y haga clic en Add . 


Gateway Name: target1 


Remote Gateway Type: Static IP Address: (seleccione), IP Address: 2.2.2.1 

Preshared Key: SLi1yoo129 






enlace: 



Heartbeat: 

Hello: 3 Seconds 

Reconnect: 60 seconds 

Threshold: 5 


VPN Name: to_target1 


Remote Gateway: Predefined: (seleccione), target1 



VPN Group: VPN Group -1 

Weight: 2 


Gateway Name: target2 


Remote Gateway Type: Static IP Address: (seleccione), IP Address: 3.3.3.1 

Preshared Key: CMFwb7oN23 






enlace: 



Heartbeat: 



Threshold: 5 


VPN Name: to_target2 


Remote Gateway: Predefined: (seleccione), target2 



VPN Group: VPN Group -1 

Weight: 1 

4. Ruta 





Gateway IP Address: 1.1.1.2(untrust) 



5. Directivas 



Address Book Entry: (seleccione), in_trust 


Address Book Entry: (seleccione), data_ctr 

Service: ANY 


VPN: VPN Group -1 





WebUI (Target1) 

1. Interfaces 













Address Name: in_trust 



Zone: Trust 





Zone: Untrust 



3. VPN 


Gateway Name: monitor1 




Preshared Key: SLi1yoo129 




enlace: 



Heartbeat: 



VPN > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK : 

Nombre: to_monitor1 


Remote Gateway: Predefined: (seleccione), monitor1 



4. Ruta 


5. Directivas 






WebUI (Target2) 


Address Book Entry: (seleccione), in_trust 



Service: ANY 


Tunnel VPN: monitor1 



Nota: Siga los pasos de configuración de Target1 para configurar Target2, pero defina la dirección IP de la 

interfaz de zona Untrust como 3.3.3.1/24, la dirección IP de puerta de enlace predeterminada como 3.3.3.2 

y utilice CMFwb7oN23 para generar la clave previamente compartida. 



CLI (Monitor1) 

1. Interfaces 







set address trust in_trust 10.10.1.0/24 

set address untrust data_ctr 10.1.0.0/16 

3. VPNs 

set ike gateway target1 address 2.2.2.1 main outgoing-interface ethernet3 

preshare SLi1yoo129 sec-level compatible 

set ike gateway target1 heartbeat hello 3 

set ike gateway target1 heartbeat reconnect 60 

set ike gateway target1 heartbeat threshold 5 

set vpn to_target1 gateway target1 sec-level compatible 

set ike gateway target2 address 3.3.3.1 main outgoing-interface ethernet3 

preshare CMFwb7oN23 sec-level compatible 

set ike gateway target2 heartbeat hello 3 

set ike gateway target2 heartbeat reconnect 60 

set ike gateway target2 heartbeat threshold 5 

set vpn to_target2 gateway target2 sec-level compatible 

set vpn-group id 1 vpn to_target1 weight 2 

set vpn-group id 1 vpn to_target2 weight 1 

unset flow tcp-syn-check-in-tunnel 

4. Ruta 




5. Directivas 

set policy top from trust to untrust in_trust data_ctr any tunnel “vpn-group 1” 

set policy top from untrust to trust data_ctr in_trust any tunnel “vpn-group 1” 

save 

CLI (Target1) 

1. Interfaces 







set address trust in_trust 10.1.0.0/16 


3. VPN 

set ike gateway monitor1 address 1.1.1.1 main outgoing-interface ethernet3 

preshare SLi1yoo129 sec-level compatible 

set ike gateway monitor1 heartbeat hello 3 

set ike gateway monitor1 heartbeat threshold 5 

set vpn to_monitor1 gateway monitor1 sec-level compatible 

4. Ruta 


5. Directivas 

set policy top from trust to untrust in_trust corp any tunnel vpn to_monitor 

set policy top from untrust to trust corp in_trust any tunnel vpn to_monitor 

save 



CLI (Target2) 

Nota: Siga los pasos de configuración de Target1 para configurar Target2, pero defina la dirección IP de la 

interfaz de zona Untrust como 3.3.3.1/24, la dirección IP de puerta de enlace predeterminada como 3.3.3.2 

y utilice CMFwb7oN23 para generar la clave previamente compartida. 


Capítulo 7 Funciones de VPN avanzadas VPNs adosadas 

VPNS ADOSADAS 

Puede aplicar directivas interzonales en el lado del concentrador para el tráfico que circule de un túnel VPN a otro 

ubicando los puntos radiales en zonas diferentes 22 . Como se encuentran en zonas distintas, el dispositivo 

NetScreen del concentrador debe realizar una consulta de directivas antes de enrutar el tráfico de un túnel a otro. 

Así, es posible controlar el tráfico que circule a través de los túneles VPN entre los puntos radiales. Esta 

configuración se denomina “VPN adosada”. 

VPNs adosadas 

Zona 

Zona 

Radio A Radio B 

X1 

X2 

VPN1 VPN2 

Consulta 

de 

directivas 

Concentrador (hub) 

22. De forma opcional, puede habilitar un bloqueo intrazonal y definir una directiva intrazonal para controlar el tráfico entre las dos interfaces de túnel dentro de 

la misma zona. 



Ventajas de las VPNs adosadas: 

Puede conservar el número de VPNs que necesite crear. Por ejemplo, el punto de perímetro A puede enlazar 

con el concentrador y los puntos de perímetro B, C, D, etc., pero A sólo tiene que configurar un túnel VPN. 

Especialmente para usuarios de NetScreen-5XP, que pueden utilizar un máximo de diez túneles VPN de 

forma simultánea, aplicar el método radial aumenta de manera significativa las opciones y funciones de VPN. 

El administrador del dispositivo concentrador puede controlar completamente el tráfico VPN entre los 

puntos de perímetro. Por ejemplo: 

– Puede permitir sólo la circulación de tráfico HTTP desde A hasta B, pero permitir la circulación de 

cualquier tipo de tráfico desde B hasta A. 

– Puede permitir el acceso a C del tráfico procedente de A, pero denegar el acceso a A del tráfico 

procedente de C. 

– Puede permitir a un host concreto de A el acceso a toda la red D y, al mismo tiempo, permitir sólo a un 

host concreto de D acceder a otro host distinto en A. 

El administrador del dispositivo concentrador puede controlar completamente el tráfico saliente de todas las 

redes del perímetro. En cada punto de perímetro debe existir primero una directiva que dirija todo el tráfico 

de salida a través de las VPN radiales hasta el concentrador; por ejemplo: set policy top from trust to 

untrust any any any tunnel vpn name_str (donde name_str define el túnel VPN específico que conecta 

cada punto de perímetro con el concentrador). En el concentrador, el administrador puede controlar el 

acceso a Internet, permitiendo determinado tipo de tráfico (por ejemplo, sólo HTTP), realizando bloqueos 

de URL o sitios web no deseables, etc. 

Se pueden utilizar concentradores regionales y túneles interconectados en una configuración radial, 

permitiendo que los puntos de radio de una región accedan a los puntos de radio de otra. 

Ejemplo: VPNs adosadas 

El ejemplo siguiente es parecido al “Ejemplo: VPNs radiales” en la página 472, excepto en un detalle: el dispositivo 

NetScreen del lado del concentrador en Nueva York realiza una comprobación de directivas en el tráfico que enruta 

entre los dos túneles con destino a las sucursales de Tokio y París. Colocando cada sitio remoto en una zona 

distinta, el tráfico VPN se controla en el concentrador. 

La dirección LAN de Tokio se encuentra en la zona definida por el usuario X1, y la dirección LAN de París se 

encuentra en la zona definida por el usuario X2. Ambas zonas se encuentran en el dominio de enrutamiento Trust-VR. 

Nota: Para crear zonas definidas por el usuario, primero hay que adquirir y cargar una clave de software de zona 

en el dispositivo NetScreen. 



El túnel VPN1 se asocia a la interfaz tunnel.1, y el túnel VPN2 se asocia a la interfaz tunnel.2. Aunque no se 

asignan direcciones IP a las interfaces de zona X1 y X2, se asignan direcciones a ambas interfaces de túnel. Las 

rutas para estas interfaces aparecen automáticamente en la tabla de enrutamiento Trust-VR. Colocando la 

dirección IP de una interfaz de túnel en la misma subred que la de destino, el tráfico destinado a dicha subred se 

enruta a la interfaz de túnel. 

La interfaz de salida es ethernet3, que está asociada a la zona Untrust. Como puede ver en la siguiente ilustración, 

ambos túneles terminan en la zona Untrust; sin embargo, los puntos finales para el tráfico que utiliza estos túneles 

se encuentran en las zonas X1 y X2. Los túneles utilizan AutoKey IKE con claves previamente compartidas. Hay 

que seleccionar el nivel de seguridad predefinido como “Compatible” para ambas propuestas de fase 1 y fase 2. La 

zona Untrust se asocia a untrust-vr. Como los túneles están basados en rutas (es decir, el túnel correcto se 

determina por el enrutamiento, no por un nombre de túnel especificado en una directiva), las IDs de proxy se 

incluyen en la configuración de cada túnel. 

Nota: A continuación se proporciona sólo la configuración del dispositivo NetScreen situado en el lado del concentrador. 

Dominio de 

enrutamiento 

Trust-VR VPN1 

Zona Trust 


de Nueva York 

Zona Untrust 

eth3, IP 123.1.1.1/24 

Sede central en 

Nueva York 

(concentrador) 

Consulta 

de 

directivas 

Interfaz: 

tunnel.1 

10.10.1.2/24 

eth1, 10.1.1.1/24 Interfaz: 

tunnel.2 

10.20.1.2/24 



IP 123.1.1.2 

Zona X1 


VPN1 

VPN2 

Zona X2 

Tokio (radio) 

110.1.1.1 

París (radio) 

220.2.2.2 

Dominio de 

enrutamiento 

Untrust-VR 

LAN de Tokio 

10.10.1.0/24 

LAN de París 

10.20.1.0/24


WebUI 

1. Zonas de seguridad y enrutadores virtuales 





Zone Name: Null 

Network > Zones > Edit (para Untrust): Introduzca los siguientes datos y haga clic en OK : 

Virtual Router Name: untrust-vr 


Network > Zones > New: Introduzca los siguientes datos y haga clic en OK : 

Zone Name: X1 



Network > Zones > New: Introduzca los siguientes datos y haga clic en OK : 

Zone Name: X2 





2. Interfaces 







Zone (VR): X1 (trust-vr) 





Zone (VR): X2 (trust-vr) 





3. VPN para la oficina de Tokio 


VPN Name: VPN1 



Gateway Name: Tokyo 






Proxy-ID: (seleccione) 23 



Service: ANY 

23. Para configurar el túnel VPN en el dispositivo NetScreen que protege las oficinas de Tokio y París, ejecute uno de estos procedimientos: 

(VPN basada en rutas) Seleccione la casilla de verificación Enable Proxy-ID y escriba 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París) para IP Local/Netmask, 

y 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París) para IP remota/Netmask . 

(VPN basada en directivas) Realice una entrada en la libreta de direcciones de la zona Trust para 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París), y otra en la 

libreta de direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París). Utilícelas como direcciones de origen y destino en la directiva 

relativa al túnel VPN al sitio del concentrador (hub). 



4. VPN para la oficina de París 





Gateway Name: París 









Service: ANY 



5. Rutas 



Next Hop Virtual Router Name: (seleccione), untrust-vr 

Network > Routing > Routing Entries > untrust-vr New: Introduzca los siguientes datos y haga clic en OK : 







Address Name: Tokyo LAN 



Zone: X1 


Address Name: Paris LAN 



Zone: X2 



7. Directivas 

Policy > (From: X1, To: X2) New: Introduzca los siguientes datos y haga clic en OK : 


Address Book Entry: (seleccione), Tokyo LAN 


Address Book Entry: (seleccione), Paris LAN 

Service: ANY 



Policy > (From: X2, To: X1) New: Introduzca los siguientes datos y haga clic en OK : 


Address Book Entry: (seleccione), Paris LAN 


Address Book Entry: (seleccione), Tokyo LAN 

Service: ANY 





CLI 




set zone untrust vrouter untrust-vr 

set zone untrust block 

set zone name x1 

set zone x1 vrouter trust-vr 

set zone x1 block 

set zone name x2 

set zone x2 vrouter trust-vr 

set zone x2 block 

2. Interfaces 



set interface tunnel.1 zone x1 


set interface tunnel.2 zone x2 



set ike gateway Tokyo address 110.1.1.1 outgoing-interface ethernet3 preshare 


set vpn VPN1 gateway Tokyo sec-level compatible 

set vpn VPN1 bind interface tunnel.1 

set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 any 24 

24. Para configurar el túnel VPN en el dispositivo NetScreen que protege las oficinas de Tokio y París, ejecute uno de estos procedimientos: 

(VPN basada en rutas) Introduzca los siguientes comandos: set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 (Tokyo) and set vpn 

VPN1 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 (Paris) . 

(VPN basada en directivas) Realice una entrada en la libreta de direcciones de la zona Trust para 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (París), y otra en la 

libreta de direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (París). Utilícelas como direcciones de origen y destino en las directivas 

relativas al túnel VPN al sitio del concentrador (hub). 




set ike gateway Paris address 220.2.2.2 outgoing-interface ethernet3 preshare 


set vpn VPN2 gateway Paris sec-level compatible 


set vpn VPN2 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 any 

5. Rutas 

set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr 

set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 123.1.1.2 


set address x1 “Tokyo LAN” 10.10.1.0/24 

set address x2 “Paris LAN” 10.20.1.0/24 

7. Directivas 

set policy top from x1 to x2 “Tokyo LAN” “Paris LAN” any permit 25 

set policy top from x2 to x1 “Paris LAN” “Tokyo LAN” any permit 

save 

25. Puede hacer caso omiso al siguiente mensaje, que aparece porque las interfaces de túnel están en modo NAT: “Warning: Some interfaces in the 

zone are in NAT mode. Traffic might not pass through them!” 


Capítulo 7 Funciones de VPN avanzadas VPNs radiales 

VPNS RADIALES 

Si crea dos túneles VPN que terminen en un dispositivo NetScreen, puede configurar un par de rutas para que el 

dispositivo NetScreen dirija el tráfico que salga de un túnel hacia el otro. Si ambos túneles están incluidos en la 

misma zona, no es necesario crear una directiva para permitir que el tráfico pase de un túnel a otro. Sólo es 

necesario definir las rutas. Esta configuración se denomina “VPN radial”. 

Zona Untrust 

Sitios remotos 

El dispositivo NetScreen enruta el 

tráfico de un túnel a otro. 

Túneles VPN 

radiales 

También es posible configurar VPNs múltiples en una zona y enrutar el tráfico entre dos túneles cualesquiera. 

Zona Untrust 

El dispositivo NetScreen enruta el 

tráfico entre túneles. 

Túneles VPN radiales múltiples 



Ejemplo: VPNs radiales 

En este ejemplo, dos sucursales de Tokio y París se comunican entre sí a través de un par de túneles VPN (VPN1 

y VPN2). Cada túnel tiene su punto de origen en el sitio remoto y termina en la sede central de Nueva York. El 

dispositivo NetScreen de la sede central enruta el tráfico que sale de un túnel hacia el otro. 

Inhabilitando el bloqueo intrazonal, el dispositivo NetScreen de la sede central sólo tiene que hacer una consulta 

de rutas (no una consulta de directivas) para dirigir el tráfico de un túnel a otro porque ambos puntos finales 

remotos se encuentran en la misma zona (zona Untrust) 26 . 

Los túneles se asocian a las interfaces de túnel (tunnel.1 y tunnel.2), que están sin numerar. Los túneles utilizan 

AutoKey IKE con claves previamente compartidas. Hay que seleccionar el nivel de seguridad predefinido como 

“Compatible” para ambas propuestas de fase 1 y fase 2. La zona Untrust se asocia a untrust-vr. La interfaz de zona 

Untrust es ethernet3. 

Nota: La siguiente configuración es aplicable a VPN basadas en rutas. Si configura VPN radiales basadas en 

directivas, debe utilizar las zonas Trust y Untrust en las directivas; no puede utilizar zonas de seguridad definidas 

por el usuario. 

Nueva York: sede central 

(concentrador) 

Zona Untrust 

Interfaz de 

salida 

eth3 

IP 1.1.1.1 

Interfaz: 

tunnel.1 

Interfaz: 

tunnel.2 

Puerta de 

enlace 


IP 1.1.1.250 

Internet 

VPN1 

26. De forma opcional, puede mantener el bloqueo intrazonal habilitado y definir una directiva intrazonal que permita el tráfico entre las dos interfaces de túnel. 


VPN2 

Tokio 2.2.2.2 

(radio) 

París 3.3.3.3 

(radio) 

Dominio de enrutamiento 

untrust-vr 

LAN de Tokio 

10.2.2.0/24 

LAN de París 

10.3.3.0/24


WebUI (Nueva York) 








2. Interfaces 


Block Intra-Zone Traffic: (anule la selección) 







Zone (VR): Untrust (untrust-vr) 


Interface: ethernet3 (untrust-vr) 













Gateway Name: Tokyo 










Service: ANY 








Gateway Name: Paris 










Service: ANY 

5. Rutas 




















WebUI (Tokio) 








2. Interfaces 
















3. Dirección 

4. VPN 






Address Name: Paris 



Zone: Untrust 





Gateway Name: New York 












Service: ANY 

5. Rutas 



Next Hop Virtual Router Name: (seleccione); untrust-vr 













6. Directivas 






Address Book Entry: (seleccione), Paris 

Service: ANY 













2. Interfaces 












3. Dirección 






Address Name: Tokyo 



Zone: Untrust 



4. VPN 





Gateway Name: New York 










Service: ANY 

5. Rutas 



Next Hop Virtual Router Name: (seleccione); untrust-vr 









6. Directivas 









Address Book Entry: (seleccione), Tokyo 

Service: ANY 




CLI (Nueva York) 





unset zone untrust block 

2. Interfaces 








set ike gateway Tokyo address 2.2.2.2 outgoing-interface ethernet3 preshare 


set vpn VPN1 gateway Tokyo sec-level compatible 




set ike gateway Paris address 3.3.3.3 outgoing-interface ethernet3 preshare 


set vpn VPN2 gateway Paris sec-level compatible 



5. Rutas 

set vrouter untrust-vr route 10.2.2.0/24 interface tunnel.1 



save 



CLI (Tokio) 





2. Interfaces 








3. Dirección 

set address untrust Paris 10.3.3.0/24 

4. VPN 

set ike gateway “New York” address 1.1.1.1 outgoing-interface ethernet3 

preshare netscreen1 sec-level compatible 

set vpn VPN1 gateway “New York” sec-level compatible 



5. Rutas 






6. Directivas 

set policy from trust to untrust any Paris any permit 

set policy from untrust to trust Paris any any permit 

save 

CLI (París) 





2. Interfaces 








3. Dirección 

set address untrust Tokyo 10.2.2.0/24 

4. VPN 

set ike gateway “New York” address 1.1.1.1 outgoing-interface ethernet3 

preshare netscreen2 sec-level compatible 

set vpn VPN2 gateway “New York” sec-level compatible 





5. Rutas 




6. Directivas 

set policy from trust to untrust any Tokyo any permit 

set policy from untrust to trust Tokyo any any permit 

save 




Índice 

Índice 

Símbolos 

3DES 8 

A 

AES (Advanced Encryption Standard) 8 

AH 3, 7 

archivos MIB, importación 380 

asociación de seguridad 

véase SAs 

ataques 

repetición 15 

autenticación 

algoritmos 7, 66, 71, 75, 79 

C 

carga de seguridad encapsulada 

véase ESP 

certificado local 30 

certificados 10 

CA 26, 30 

carga 34 

local 30 

petición 31 

por correo electrónico 30 

revocación 29, 44 

certificados de CA 26, 30 

Challenge Handshake Authentication Protocol 

véase CHAP 

CHAP 311, 314 

clave manual 166, 177 

administración 9 

clave previamente compartida 9, 235 

CLI 

convenciones vi 

código de autenticación de mensajes basado en 

hash 

véase HMAC 

comprobación contra reprocesamiento de 

paquetes 68, 76 

confidencialidad directa perfecta 

véase PFS 

conjuntos de caracteres compatibles con 

ScreenOS x 

conjuntos de DIP 

interfaces extendidas 203 

NAT para VPNs 203 

container 280 

convenciones 

CLI vi 

ilustración ix 

nombres x 

WebUI vii 

CRL (lista de revocación de certificados) 28, 44 

carga 28 

D 

DES 8 

Diffie-Hellman, grupos 13, 65, 69, 74, 77 


extendidas 203 

directivas 

VPNs bidireccionales 178 

DN (nombre completo) 275 

DNS 

ajustes de L2TP 314 

E 

encabezado de autenticación 

véase AH 

encriptación 

algoritmos 8, 66, 70, 74, 79 

ESP 3, 7, 8 

encriptación y autenticación 70, 78 

sólo autenticación 70 

sólo encriptación 70 

F 

Fase 1 11 

propuestas 11 

propuestas, predefinidas 12 

Fase 2 13 

propuestas 13, 14 

propuestas, predefinidas 14 

firma digital 24 

flujo de paquetes 

VPN basada en directivas 88–89 

VPN basada en rutas 82–87 

VPN de entrada 85–87 

VPN de salida 83–85 

H 

HMAC 7 

I 


certificados 276–287 

clave previamente compartida 288–296 

IDs de proxy 14 

coincidencia 81, 90 

VPNs y NAT 203–204 

IKE 9, 111, 126, 235 

ID IKE, Windows 200 328, 341 

ID local, ASN1-DN 278 

ID remota, ASN1-DN 278 

identificación IKE 66–68, 75–76 

identificación IKE de grupo, container 280 

identificación IKE de grupo, wildcard 279 

IDs de proxy 14 

latidos 443 

mensajes de saludo 443 

propuestas de fase 1, predefinidas 12 

propuestas de fase 2, predefinidas 14 

puertas de enlace redundantes 441–459 

recomendaciones de ID IKE 92 

Juniper Networks NetScreen Concepts & Examples – Volume 5: VPNs IX-I

Índice 

usuario de identificación IKE compartida 

297–306 

usuario de identificación IKE de grupo 

275–296 

ilustración 

convenciones ix 

infraestructura de claves públicas 

véase PKI 

intercambio de claves de Internet 

véase IKE 

intercambio Diffie-Hellman 13 

interfaces 

extendidas 203 

null 109 

interfaz nula 109 

IPSec 3 

AH 2, 69, 78 

ESP 2, 69, 78 

firma digital 24 

modo de transporte 4, 311, 317, 326 

modo de túnel 5 

negociación de túnel 11 

SAs 2, 10, 11, 14 

SPI 2 

túnel 2 

K 

keepalive 

frecuencia, NAT-T 357 

L2TP 322 

L 

L2TP 307–348 

autenticado del túnel Windows 2000 322 

bidireccional 311 

concentrador de accesos: véase LAC 

configuración obligatoria 308 

configuración voluntaria 308 

desencapsulado 313 

encapsulado 312 

Keep Alive 322 

L2TP en solitario sobre Windows 2000 311 

modo de funcionamiento 311 

parámetros predeterminados 315 

señal hello 322 

servidor de red: véase LNS 

servidor RADIUS 314 

servidor SecurID 314 

soporte de ScreenOS 311 

túnel 317 

Windows 2000 331 

L2TP sobre IPSec 4, 317, 326 

bidireccional 311 

túnel 317 

LAC 308 

NetScreen-Remote 5.0 308 

Windows 2000 308 

Layer 2 Tunneling Protocol 

véase L2TP 

LNS 308 

M 

MD5 7 

Message Digest versión 5 

véase MD5 

MIP 

VPNs 203 

modo de transporte 4, 311, 317, 326 


modo dinámico 12 

modo principal 12 

módulo 13 

N 

NAT 

IPSec y NAT 351 

servidores NAT 351 

NAT-dst 

VPNs 203 

NAT-src 

VPNs 206 

NAT-T 351–360 

frecuencia de mantenimiento de conexión 357 

habilitar 359 

iniciador y respondedor 358 

obstáculos para VPNs 354 

paquete IKE 354 

paquete IPSec 356 

sondeos de NAT 352–353 

NAT-Traversal 

véase NAT-T 


interlocutor dinámico 244, 256 

opción NAT-T 351 

VPN AutoKey IKE 235 

nombres 

convenciones x 

Norma de encriptación de datos 

véase DES 

O 

OCSP (Online Certificate Status Protocol) 44 

client 44 

servidor de respuesta 44 

opción de reencriptación, supervisión de VPN 362 

opciones criptográficas 62–79 

acceso telefónico 72–79 

algoritmos de autenticación 66, 71, 75, 79 

algoritmos de encriptación 66, 70, 74, 79 

comprobación contra reprocesamiento de 

paquetes 68, 76 

Diffie-Hellman, grupos 65, 69, 74, 77 

ESP 70, 78 

identificación IKE 66–68, 75–76 

longitudes de bits de los certificados 65, 73 

métodos de administración de claves 64 

modo de transporte 78 


modos de fase 1 64, 73 

PFS 68, 77 

protocolos IPSec 69, 78 

punto a punto 63–71 

recomendaciones VPN de acceso 

telefónico 79 

recomendaciones VPN punto a punto 71 

tipos de autenticación 64, 73 

P 

PAP 311, 314 

par de claves pública/privada 27 

Password Authentication Protocol 

véase PAP 

Juniper Networks NetScreen Concepts & Examples – Volume 5: VPNs IX-II

Índice 

PFS 15, 68, 77 

PKI 26 

PPP 309 

propuestas 

Fase 1 11, 90 

Fase 2 14, 90 

protección contra reprocesamiento de paquetes 15 

protocolo punto a punto 

véase PPP 

protocolos 

CHAP 311 

PAP 311 

PPP 309 


comprobación de flag TCP SYN 447 

procedimiento de recuperación 444 

R 

RADIUS 

L2TP 314 

RFC 

(MD5) 

1321 7 

2403 7 

(SHA-1) 

2404 7 

2104 7 

2407 3 

2408 3 

ruta nula 109 

S 

SAs 10, 11, 14 

comprobación en flujo de paquetes 84 

SCEP (Simple Certificate Enrollment Protocol) 38 

Secure Hash Algorithm-1 

véase SHA-1 

SecurID 

L2TP 314 

Seguridad IP 

véase IPSec 

SHA-1 7 

SNMP 

archivos MIB, importación 380 

supervisión de VPN 380 

supervisión de VPN 361–379 

cambios de estado 361, 366 

dirección de destino 363–367 

dirección de destino, XAuth 364 

directivas 365 

diseño de rutas 93 

interfaz de salida 363–367 

opción de reencriptación 362, 386 

peticiones de eco ICMP 380 

SNMP 380 

T 

tabla NHTB 381–387 

asignación de rutas a túneles 382 

entradas automáticas 386 

entradas manuales 385 

esquema de direccionamiento 383 

TCP 

comprobación de flag SYN 447 

Triple DES 

véase 3DES 

U 

UDP 

encapsulación NAT-T 351 

suma de comprobación 357 

usuario de identificación IKE de grupo 275–296 

certificados 276 

clave previamente compartida 288 

usuarios 

identificación IKE compartida 297–306 

identificación IKE de grupo 275–296 

V 

Verisign 44 

VPN AutoKey IKE 9 

administración 9 

VPN basada en directivas 80 

VPN basadas en rutas 80–81 

VPNs 

alias FQDN 187 

AutoKey IKE 9 

basadas en rutas o basadas en directivas 80 

consejos de configuración 90–92 

Diffie-Hellman, grupos 13 

Fase 1 11 

Fase 2 13 

flujo de paquetes 82–89 

FQDN para puerta de enlace 186–202 

grupos redundantes, procedimiento de 

recuperación 444 

grupos VPN 441 

IDs de proxy, coincidencia 90 

intercambio Diffie-Hellman 13 

MIP 203 

modo dinámico 12 

modo principal 12 

múltiples túneles por interfaz de túnel 381–437 

NAT para direcciones superpuestas 203–220 

NAT-dst 203 

NAT-src 206 

opciones criptográficas 62–79 

protección contra reprocesamiento de 

paquetes 15 


SAs 10 

supervisión y reencriptación de VPN 362 

túnel siempre activo 362 

Juniper Networks NetScreen Concepts & Examples – Volume 5: VPNs IX-III 

W 

WebUI 

convenciones vii 

wildcard 279 

WINS 

ajustes de L2TP 314 

X 

XAuth 

supervisión de VPN 364

Índice 

Juniper Networks NetScreen Concepts & Examples – Volume 5: VPNs IX-IV

NetScreen conceptos y ejemplos: Volumen 5 ... - Juniper Networks

Create successful ePaper yourself

Delete template?

Save as template?