VPN Juniper

Conceptos y ejemplos
Manual de referencia de ScreenOS
Volumen 5:
Redes privadas virtuales
Versin 6.0.0, Rev. 02
Juniper Networks, Inc.

1194 North Mathilda Avenue
Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Nmero de pieza: 530-017771-01-SP, Revisin 02
Copyright Notice
Copyright 2007 Juniper Networks, Inc. All rights reserved.
Juniper Networks and the Juniper Networks logo are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other
trademarks, service marks, registered trademarks, or registered service marks in this document are the property of Juniper Networks or their respective
owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document or for
any obligation to update information in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication
without notice.
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 Juniper Networks 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 JUNIPER NETWORKS REPRESENTATIVE FOR A COPY.
ii
Contenido
Acerca de este volumen
vii
Convenciones del documento ....................................................................... viii

Convenciones de la interfaz de usuario web ........................................... viii
Convenciones de interfaz de lnea de comandos .................................... viii
Convenciones de nomenclatura y conjuntos de caracteres ....................... ix
Convenciones para las ilustraciones .......................................................... x
Asistencia y documentacin tcnica................................................................ xi
Captulo 1
Seguridad del protocolo de Internet
Introduccin a las redes privadas virtuales....................................................... 2

Conceptos de IPSec.......................................................................................... 3
Modos ....................................................................................................... 4
Modo de transporte............................................................................. 4
Modo de tnel ..................................................................................... 4
Protocolos ................................................................................................. 6
Encabezado de autenticacin .............................................................. 6
Carga de seguridad encapsulada ......................................................... 6
Administracin de claves........................................................................... 7
Clave manual ...................................................................................... 7
AutoKey IKE........................................................................................ 7
Asociaciones de seguridad......................................................................... 8
Negociacin de tnel........................................................................................ 9
Fase 1........................................................................................................ 9
Modo principal y modo dinmico ..................................................... 10
Intercambio Diffie-Hellman............................................................... 11
Fase 2...................................................................................................... 11
Confidencialidad directa perfecta ...................................................... 12
Proteccin contra reprocesamiento de paquetes............................... 12
Paquetes IKE e IPSec ..................................................................................... 12
Paquetes IKE ........................................................................................... 13
Paquetes IPSec ........................................................................................ 16
Captulo 2
Criptografa de claves pblicas
19
Introduccin a la criptografa de claves pblicas ............................................ 20

Firma de un certificado ........................................................................... 20
Verificacin de una firma digital .............................................................. 20
Infraestructura de claves pblicas .................................................................. 22
Certificados y CRL.......................................................................................... 24
Peticin manual de un certificado ........................................................... 26
Carga de certificados y listas de revocacin de certificados ..................... 28
Configuracin de ajustes de CRL.............................................................. 29
Obtencin automtica de un certificado local .......................................... 31
Contenido
iii
Manual de referencia de ScreenOS: Conceptos y ejemplos
Renovacin automtica de certificado ..................................................... 34

Generacin de pares de claves.................................................................35
Protocolo de estado de certificado en lnea (OCSP) ........................................ 35
Especificacin de un mtodo de comprobacin de revocacin de
certificados ....................................................................................... 36
Visualizacin de los atributos de comprobacin de estado ...................... 37
Especificacin de una URL del servidor de respuesta del protocolo de
estado de certificado en lnea............................................................ 37
Eliminacin de atributos de comprobacin de estado.............................. 37
Certificados autofirmados .............................................................................. 38
Validacin de certificados ........................................................................ 39
Creacin manual de certificados autofirmados ........................................ 40
Establecimiento de un certificado autofirmado y definido por el
administrador ................................................................................... 41
Autogeneracin de certificados................................................................ 45
Eliminar certificados autofirmados .......................................................... 46
Captulo 3
Directrices para las redes privadas virtuales
49
Opciones criptogrficas.................................................................................. 50
Opciones criptogrficas punto a punto ....................................................50
Opciones VPN de acceso telefnico ......................................................... 57
Tneles basados en directivas y en rutas ....................................................... 64
Flujo de paquetes: VPN punto a punto ........................................................... 66
Directrices para la configuracin de tneles ................................................... 72
Consideraciones sobre seguridad en redes privadas virtuales basadas en
rutas ........................................................................................................ 74
Ruta Null.................................................................................................. 74
Lnea de acceso telefnico o arrendada ................................................... 76
Conmutacin por error de la VPN hacia la lnea arrendada o la ruta
Null ................................................................................................... 77
Interfaz Tunnel ficticia ............................................................................. 79
Enrutador virtual para interfaces Tunnel.................................................. 80
Reenrutamiento a otro tnel.................................................................... 80
Captulo 4
Redes privadas virtuales de punto a punto
81
Configuraciones VPN punto a punto............................................................... 82

VPN punto a punto basada en rutas, AutoKey IKE ................................... 88
VPN punto a punto basada en directivas, AutoKeyIKE............................. 97
VPN punto a punto basada en rutas, interlocutor dinmico ...................103
VPN punto a punto basada en directivas, interlocutor dinmico............112
VPN punto a punto basada en rutas, clave manual ................................120
VPN punto a punto basada en directivas, clave manual.........................127
Puertas de enlace IKE dinmicas con FQDN ................................................132
Alias ......................................................................................................133
Ajuste del interlocutor AutoKey IKE con FQDN......................................134
Sitios VPN con direcciones superpuestas......................................................142
VPN en modo transparente..........................................................................154
Captulo 5
Redes privadas virtuales de acceso telefnico
163
Acceso telefnico .........................................................................................164

VPN de acceso telefnico basada en directivas, AutoKey IKE ................165
VPN de acceso telefnico basada en rutas, interlocutor dinmico .........170
iv
Contenido
Contenido
VPN de acceso telefnico basada en directivas, interlocutor dinmico ..177

Directivas bidireccionales para usuarios de VPN de acceso telefnico ...184
Identificacin IKE de grupo ..........................................................................188
Identificacin IKE de grupo con certificados ..........................................189
Tipos de identificacin IKE ASN1-DN Wildcard y Container ..................191
Creacin de una identificacin IKE de grupo (certificados) ....................194
Configuracin de una ID IKE de grupo con claves previamente
compartidas ....................................................................................198
Identificacin IKE compartida ......................................................................204
Captulo 6
Protocolo de encapsulamiento de la capa 2
211
Introduccin al L2TP ....................................................................................211

Encapsulado y desencapsulado de paquetes ................................................214
Encapsulado ..........................................................................................215
Desencapsulado.....................................................................................216
Ajuste de los parmetros L2TP .....................................................................217
L2TP y L2TP sobre IPSec..............................................................................219
Configuracin de L2TP ..........................................................................219
Configuracin de L2TP sobre IPSec .......................................................224
L2TP sobre IPSec bidireccional ..............................................................232
Captulo 7
Funciones avanzadas de redes privadas virtuales
239
NAT-Traversal ..............................................................................................240
Sondeos de NAT ....................................................................................241
Atravesar un dispositivo NAT.................................................................243
Suma de comprobacin de UDP ............................................................245
Paquetes de mantenimiento de conexin..............................................246
Simetra iniciador/respondedor .............................................................246
Habilitacin de NAT-Traversal ...............................................................248
Uso de identificaciones de IKE con NAT-Traversal .................................249
Supervisin de VPN......................................................................................250
Opciones de reencriptacin y optimizacin ...........................................251
Interfaz de origen y direccin de destino...............................................252
Consideraciones sobre directivas...........................................................253
Configuracin de la funcin de supervisin de VPN...............................254
Objetos y capturas SNMP para la supervisin de VPN............................262
Mltiples tneles por interfaz de tnel .........................................................263
Asignacin de rutas a tneles ................................................................264
Direcciones de interlocutores remotos...................................................266
Entradas de tabla manuales y automticas ............................................267
Entradas manuales en la tabla ........................................................267
Entradas automticas en la tabla.....................................................267
Ajuste de VPN en una interfaz de tnel para subredes
superpuestas ............................................................................269
Asociacin de entradas automticas en la tabla de rutas y en la
tabla NHTB ...............................................................................288
Uso de OSPF para entradas automticas en la tabla de rutas ..........300
Puertas de enlace VPN redundantes.............................................................301
Grupos VPN ...........................................................................................302
Mecanismos de supervisin...................................................................303
Pulsos de IKE ..................................................................................304
Deteccin de interlocutor muerto....................................................304
Procedimiento de recuperacin IKE ................................................306
Contenido
Comprobacin de indicador TCP SYN....................................................307

Creacin de puertas de enlace VPN redundantes ............................308
Creacin de VPN adosadas...........................................................................314
Creacin de VPN radiales .............................................................................321
Captulo 8
Redes privadas virtuales de AutoConnect
331
Vista general ................................................................................................331

Cmo funciona ............................................................................................332
Mensajes NHRP .....................................................................................332
Iniciacin del tnel AC-VPN ...................................................................333
Configuracin de AC-VPN ......................................................................334
Traduccin de direcciones de red....................................................335
Configuracin en el concentrador ...................................................335
Configuracin en cada red radial.....................................................335
Ejemplo .................................................................................................336
ndice ........................................................................................................................IX-I
vi
Contenido

El Volumen 5: Redes privadas virtuales describe los conceptos de la red privada
virtual (VPN) y las funciones especficas de la VPN de ScreenOS.
Este volumen contiene los siguientes captulos:
Captulo 1, Seguridad del protocolo de Internet, que presenta los elementos

de Seguridad del protocolo de Internet (IPSec) y explica cmo se relacionan con
el encapsulamiento de VPN.
Captulo 2, Criptografa de claves pblicas, donde se ofrece una introduccin

a la criptologa de claves pblicas y al uso de certificados y listas de revocacin
de certificados (CLR) en el marco de la infraestructura de claves pblicas (PKI).
Captulo 3, Directrices para las redes privadas virtuales, que explica el

encapsulamiento de VPN.
Captulo 4, Redes privadas virtuales de punto a punto, que explica cmo

configurar un tnel VPN punto a punto entre dos dispositivos de seguridad de
Juniper Networks.
Captulo 5, Redes privadas virtuales de acceso telefnico, donde se explica

cmo configurar una VPN de acceso telefnico.
Captulo 6, Protocolo de encapsulamiento de la capa 2, que describe el

protocolo de encapsulamiento de capa 2 (L2TP) y proporciona ejemplos de
configuraciones para L2TP y L2TP sobre IPSec.
Captulo 7, Funciones avanzadas de redes privadas virtuales, que explica los

temas relacionados con las Traduccin de direcciones de red de origen (NAT),
supervisin VPN y VPN que utilizan mltiples tneles.
Captulo 8, Redes privadas virtuales de AutoConnect, que describe cmo

ScreenOS utiliza los mensajes del protocolo de resolucin de siguiente salto
(NHRP) para habilitar los dispositivos de seguridad para configurar las VPN de
AutoConnect segn sea necesario. El captulo proporciona un ejemplo de un
escenario tpico en el cual se puede utilizar AC-VPN.
vii
Convenciones del documento

Este documento utiliza las convenciones que se describen en las secciones
siguientes:
Convenciones de la interfaz de usuario web en la pgina viii
Convenciones de interfaz de lnea de comandos en la pgina viii
Convenciones de nomenclatura y conjuntos de caracteres en la pgina ix
Convenciones para las ilustraciones en la pgina x
Convenciones de la interfaz de usuario web

En la interfaz de usuario web (WebUI), el conjunto de instrucciones de cada tarea
se divide en ruta de navegacin y establecimientos de configuracin. Para abrir una
pgina de WebUI e introducir parmetros de configuracin, navegue hacia la pgina
en cuestin haciendo clic en un elemento del men en el rbol de navegacin en el
lado izquierdo de la pantalla, luego en los elementos subsiguientes. A medida
que avanza, su ruta de navegacin aparece en la parte superior de la pantalla,
cada pgina separada por signos de mayor y menor.
Lo siguiente muestra los parmetros y ruta de WebUI para la definicin
de una direccin:
Policy > Policy Elements > Addresses > List > New: Introduzca los siguientes
datos y haga clic en OK:
Address Name: dir_1
IP Address/Domain Name:
IP/Netmask: (seleccione), 10.2.2.5/32
Zone: Untrust
Para abrir la ayuda en lnea para los ajustes de configuracin, haga clic en el signo
de interrogacin (?) en la parte superior izquierda de la pantalla.
El rbol de navegacin tambin proporciona una pgina de configuracin de Help >
Config Guide de configuracin para ayudarle a configurar las directivas de seguridad
y la Seguridad de protocolo de Internet (IPSec). Seleccione una opcin del men
desplegable y siga las instrucciones en la pgina. Haga clic en el carcter ? en la
parte superior izquierda para la Ayuda en lnea en la Gua de configuracin.
Convenciones de interfaz de lnea de comandos

Las siguientes convenciones se utilizan para presentar la sintaxis de los comandos
de interfaz de lnea de comandos (CLI) en ejemplos y en texto.
En ejemplos:
viii
Los elementos entre corchetes [ ] son opcionales.
Los elementos entre llaves { } son obligatorios.
Si existen dos o ms opciones alternativas, aparecern separadas entre s por

barras verticales ( | ). Por ejemplo:
set interface { ethernet1 | ethernet2 | ethernet3 } manage
Las variables aparecen en cursiva:

set admin user nombre1 contrasea xyz
En el texto, los comandos estn en negrita y las variables en cursiva.
NOTA:
Para introducir palabras clave, basta con introducir los primeros caracteres para
identificar la palabra de forma inequvoca. Al escribir set adm u whee j12fmt54
se ingresar el comando set admin user wheezer j12fmt54. Sin embargo, todos
los comandos documentados aqu se encuentran presentes en su totalidad.
Convenciones de nomenclatura y conjuntos de caracteres

ScreenOS emplea las siguientes convenciones relativas a los nombres de objetos
(como direcciones, usuarios administradores, servidores de autenticacin, puertas
de enlace IKE, sistemas virtuales, tneles de VPN y zonas) definidos en las
configuraciones de ScreenOS:
Si una cadena de nombre tiene uno o ms espacios, la cadena completa deber

estar entre comillas dobles; por ejemplo:
set address trust local LAN 10.1.1.0/24
Cualquier espacio al comienzo o al final de una cadena entrecomillada se

elimina; por ejemplo, local LAN se transformar en local LAN.
Los espacios consecutivos mltiples se tratan como uno solo.
En las cadenas de nombres se distingue entre maysculas y minsculas; por el

contrario, en muchas palabras clave de CLI pueden utilizarse indistintamente.
Por ejemplo, local LAN es distinto de local lan.
ScreenOS admite los siguientes conjuntos de caracteres:
NOTA:
Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de

mltiples bytes (MBCS). Algunos ejemplos de SBCS son los conjuntos de
caracteres ASCII, europeo y hebreo. Entre los conjuntos MBCS, tambin
conocidos como conjuntos de caracteres de doble byte (DBCS), se encuentran
el chino, el coreano y el japons.
Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepcin

de las comillas dobles ( ), que tienen un significado especial como
delimitadores de cadenas de nombres que contengan espacios.
Una conexin de consola slo admite conjuntos SBCS. La WebUI admite tanto
SBCS como MBCS, segn el conjunto de caracteres que admita el explorador.
ix
Convenciones para las ilustraciones

La siguiente figura muestra el conjunto bsico de imgenes utilizado en las
ilustraciones de este volumen:
Figura 1: Imgenes de las ilustraciones
Sistema autnomo
o bien
dominio de enrutamiento virtual
Internet
Interfaces de zonas de seguridad:

Blanco = Interfaz de zona protegida
(ejemplo = zona Trust)
Negro = Interfaz de zona externa
(ejemplo = zona Untrust)
Red de rea local (LAN) con

una nica subred
o bien
zona de seguridad
Rango dinmico de IP (DIP)
Motor de directivas
Dispositivo de red genrico
Interfaz de tnel
Servidor
Tnel VPN
Enrutador
Conmutador
Concentrador
Dispositivos de seguridad
Juniper Networks
Asistencia y documentacin tcnica

Para obtener documentacin tcnica sobre cualquier producto de Juniper Networks,
visite www.juniper.net/techpubs/.
Para obtener soporte tcnico, abra un expediente de soporte utilizando el vnculo
Case Manager en la pgina web http://www.juniper.net/customers/support/
o llame al telfono 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 algn error u omisin en este documento, pngase en contacto con
Juniper Networks al techpubs-comments@juniper.net.
xi
xii
Captulo 1
Seguridad del protocolo de Internet

En este captulo se presentan los elementos de la seguridad del protocolo de
internet (IPsec) y se describe cmo se relacionan con el encapsulamiento de red
privada virtual (VPN). Este captulo incluye las siguientes secciones:
Introduccin a las redes privadas virtuales en la pgina 2
Conceptos de IPSec en la pgina 3
Modos en la pgina 4
Protocolos en la pgina 6
Administracin de claves en la pgina 7
Asociaciones de seguridad en la pgina 8
Negociacin de tnel en la pgina 9
Fase 1 en la pgina 9
Fase 2 en la pgina 11
Paquetes IKE e IPSec en la pgina 12
Paquetes IKE en la pgina 13
Paquetes IPSec en la pgina 16
Introduccin a las redes privadas virtuales

Una red privada virtual (VPN) representa un medio de comunicacin segura entre
equipos remotos de una red de rea extensa (WAN) pblica, como Internet.
Una conexin VPN puede enlazar dos redes de rea local (LAN) entre s, o un
usuario de acceso telefnico remoto y una LAN. El trfico que circula entre estos
dos puntos atraviesa determinados recursos compartidos, como enrutadores,
conmutadores y otros equipos de red que conforman la WAN pblica. Para
garantizar la seguridad de las comunicaciones VPN a travs de la WAN, los dos
participantes crean un tnel de seguridad IP (IPSec).
NOTA:
El trmino tnel no denota ni transporte ni modo de tnel (consulte Modos en la

pgina 4). Se refiere a la conexin IPSec.
Un tnel IPSec est formado por un par de asociaciones de seguridad (SA)
unidireccionales (una a cada extremo del tnel) que especifican el ndice de
parmetros de seguridad (SPI), la direccin IP de destino y el protocolo de
seguridad (encabezado de autenticacin o carga de seguridad encapsulada)
empleado.
Para obtener ms informacin sobre SPI, consulte Asociaciones de seguridad en
la pgina 8. Para obtener ms informacin sobre los protocolos de seguridad IPSec,
consulte Protocolos en la pgina 6.
A travs de la SA, un tnel IPSec puede proporcionar las siguientes funciones de
seguridad:
Privacidad (por encriptacin)
Integridad de contenido (por autenticacin de datos)
Autenticacin de remitente y (si se usan certificados) prevencin de rechazo

(por autenticacin de origen de datos)
Las funciones de seguridad empleadas dependen de las necesidades particulares. Si

slo necesita autenticar el origen del paquete IP y la integridad de contenido, puede
autenticar el paquete sin aplicar ningn tipo de encriptacin. Por otro lado, si slo le
preocupa preservar la privacidad, puede encriptar el paquete sin aplicar ningn
mecanismo de autenticacin. Tambin puede encriptar y autenticar el paquete. La
mayora de los diseadores de seguridad de red se decantan por la encriptacin, la
autenticacin y la proteccin contra reprocesamiento de paquetes para el trfico
VPN.
ScreenOS admite la tecnologa IPSec para la creacin de tneles VPN con dos tipos
de mecanismos de elaboracin de claves:
Clave manual
AutoKey IKE con un certificado o una clave previamente compartida
Introduccin a las redes privadas virtuales
Captulo 1: Seguridad del protocolo de Internet
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 paquetes IP mediante
encriptacin. La IPSec se compone de dos modos y dos protocolos principales:
Modos de tnel y de transporte
Protocolo de encabezado de autenticacin (AH) para la autenticacin y

protocolo de carga de seguridad encapsulada (ESP) para la encriptacin (y la
autenticacin)
IPSec tambin ofrece mtodos para la negociacin manual y automtica de

asociaciones de seguridad (SA) y distribucin de claves; todos los atributos
necesarios para ello estn reunidos en un dominio de interpretacin (DOI).
Consulte las normas RFC 2407 y RFC 2408.
Figura 2: Arquitectura IPSec
Modo de transporte
Modo de tnel
Nota: ScreenOS
no admite el modo de
transporte
transporte con AH.
Protocolo AH
Protocolo ESP
Algoritmo de encriptacin
(DES, 3DES)
Algoritmo de autenticacin
(MD5, SHA-1)
Dominio de interpretacin
(DOI)
Administracin de claves y SA
(manual y automtica)
NOTA:
El dominio de interpretacin (DOI) IPSec es un documento que contiene

definiciones para todos los parmetros de seguridad requeridos para la
negociacin satisfactoria de un tnel VPN (fundamentalmente, todos los atributos
necesarios para las negociaciones IKE y SA).
Conceptos de IPSec
Modos
La seguridad IPSec funciona en uno de dos modos: transporte o tnel Cuando
ambos extremos del tnel son hosts, se puede utilizar tanto el modo de transporte
como el modo de tnel. Cuando al menos uno de los puntos finales de un tnel es
una puerta de enlace de seguridad (como un enrutador o un cortafuegos), hay que
utilizar el modo de tnel. Los dispositivos de seguridad de Juniper Networks
funcionan siempre en modo de tnel cuando se trata de tneles IPSec y en modo
de transporte cuando se trata de tneles L2TP sobre IPSec.
Modo de transporte
El paquete IP original no est encapsulado en otro paquete IP, como se muestra en
la Figura 3. El paquete completo se puede autenticar (con AH), la carga se puede
encriptar (con ESP), y el encabezado original contina en texto sin formato tal
como se enva por la WAN.
Figura 3: Modos de transporte
Paquetes IP
Modo de transporte, AH
Original
AH
Carga de datos
Autenticado
Modo de transporte,
ESP
Original
ESP
Carga de datos
Encriptado
Autenticado
Modo de tnel
El paquete IP original completo (carga y encabezado) est encapsulado dentro de
otra carga IP y tiene adjunto un nuevo encabezado, como se muestra en la Figura 4.
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.
Figura 4: Modos de tnel
Paquetes IP
Modo de tnel, AH
Nuevo
encabezado
Encabezado AH
El paquete original est encapsulado.
Encabezado
original
Carga de datos
Autenticado
Modo de tnel, ESP
Nuevo
encabezado
Encabezado ESP
Encabezado
original
Carga de datos
Encriptado
Autenticado
Conceptos de IPSec
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 direccin 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 conexin.
Figura 5: VPN punto a punto en modo de tnel
Dispositivo A
Puerta de enlace de tnel
Dispositivo B
Internet
LAN
LAN
Tnel
2
B
A
A
Carga de datos
Carga de datos
Carga de datos
En una VPN de acceso telefnico no existe ninguna puerta de enlace de tnel en el

extremo del tnel correspondiente al cliente de acceso telefnico VPN; el tnel se
prolonga directamente hasta el propio cliente. En este caso, en los paquetes
enviados desde el cliente de acceso telefnico, tanto el encabezado nuevo como el
encabezado encapsulado original tendrn la misma direccin IP: la del equipo del
cliente.
NOTA:
Algunos clientes VPN, como NetScreen-Remote, permiten definir una direccin IP

interna virtual. En estos casos, la direccin IP interna virtual es la direccin IP de
origen en el encabezado del paquete original del trfico originado por el cliente,
y la direccin IP que el ISP asigna dinmicamente al cliente de acceso telefnico
es la direccin IP de origen en el encabezado externo.
Figura 6: VPN de acceso telefnico en modo de tnel

Dispositivo B
Internet
Cliente VPN de acceso telefnico
LAN
Tnel
A=1
Carga de datos
2
1
Carga de datos
B
A
Carga de datos
Conceptos de IPSec
Protocolos
IPSec utiliza dos protocolos para garantizar la seguridad de las comunicaciones en
la capa IP:
Encabezado de autenticacin (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)
Encabezado de autenticacin
El protocolo de encabezado de autenticacin (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 comprobacin calculada a travs de un cdigo de
autenticacin de mensajes basado en hash (HMAC) mediante una clave secreta y
funciones MD5 o SHA-1 hash.
NOTA:
Message Digest versin 5 (MD5): Un algoritmo que produce un hash de

128 bits (tambin se denomina una firma digital o resumen 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.
Secure Hash Algorithm-1 (SHA-1): Un 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 ms seguro que MD5 debido al mayor tamao del
hash que produce. Como el procesamiento computacional se realiza en ASIC, el
coste de rendimiento es insignificante.
Para obtener ms informacin sobre los algoritmos MD5 y SHA-1, consulte las
siguientes normas RFC: (MD5) 1321, 2403; (SHA-1) 2404. Para obtener
informacin sobre HMAC, consulte la norma RFC 2104.
Carga de seguridad encapsulada

El protocolo de carga de seguridad encapsulada (ESP) proporciona un medio para
garantizar la privacidad (encriptacin), la autenticacin de origen y la integridad de
contenidos (autenticacin). El protocolo ESP en modo de tnel encapsula el paquete
IP completo (encabezado y carga) y adjunta un nuevo encabezado IP al paquete que
ya se encript. Este nuevo encabezado IP contiene la direccin de destino necesaria
para enrutar los datos protegidos a travs de la red.
Con ESP, es posible encriptar y autenticar, slo encriptar o slo autenticar. Para la
encriptacin se puede seleccionar uno de los siguientes algoritmos de encriptacin:
Conceptos de IPSec
Norma de encriptacin de datos (DES): Un algoritmo de bloque criptogrfico

con una clave de 56 bits.
Triple DES (3DES): Una versin ms potente de DES en la que el algoritmo

original DES se aplica en tres rondas utilizando 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 encriptacin avanzada (AES): norma de encriptacin que, cuando

sea adoptada por las infraestructuras de Internet de todo el mundo, ofrecer
una mayor interoperabilidad con otros dispositivos de seguridad de red.
ScreenOS admite AES con claves de 128, 192 y 256 bits.
Para la autenticacin, puede utilizar algoritmos MD5 o SHA-1.
NOTA:
Aunque es posible seleccionar NULL para la autenticacin, se ha demostrado que

IPSec puede ser vulnerable a ataques bajo tales circunstancias. Por lo tanto, no es
recomendable seleccionar NULL para la autenticacin.
Administracin de claves
La distribucin y la administracin de claves son fundamentales para el uso
satisfactorio de las redes VPN. IPSec admite los mtodos de distribucin de claves
manual y automtico.
Clave manual
Con las claves manuales, los administradores de ambos extremos de un tnel
configuran todos los parmetros de seguridad. sta es una tcnica viable para redes
pequeas y estticas, donde la distribucin, el mantenimiento y el seguimiento de
las claves no resulta difcil. Sin embargo, la distribucin segura de configuraciones
de clave manual a travs 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. Adems, 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 tneles, se requiere un mtodo
en el que no haya que configurar cada elemento de forma manual. IPSec admite la
generacin y negociacin automatizada de claves y asociaciones de seguridad
mediante el protocolo de intercambio de claves de Internet (IKE). ScreenOS
denomina estas negociaciones de tnel 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 sesin IKE, cada parte debe configurar e intercambiar de
forma segura la clave compartida por adelantado. En este sentido, el problema de
distribucin segura de claves es idntico 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 automticamente a intervalos
predeterminados mediante el protocolo IKE. Con frecuencia, la modificacin de
claves aumenta la seguridad de forma considerable. Adems, la automatizacin de
esta tarea reduce significativamente las responsabilidades de administracin de
claves. Sin embargo, la modificacin de claves eleva el nivel mximo de trfico; por
lo tanto, si se realiza a menudo, puede disminuir la eficacia de la transmisin de
datos.
Conceptos de IPSec
NOTA:
Una clave previamente compartida es una clave que se utiliza tanto para la
encriptacin como para la desencriptacin y que ambos participantes deben
poseer antes de iniciar la comunicacin.
AutoKey IKE con certificados
Cuando se utilizan certificados para autenticar a los participantes durante una
negociacin AutoKey IKE, cada parte genera un par de claves pblicas/privadas
(consulte Criptografa de claves pblicas en la pgina 19) y adquiere un
certificado (consulte Certificados y CRL en la pgina 24). Si la autoridad de
certificacin (CA) es fiable para ambas partes, los participantes podrn recuperar la
clave pblica del interlocutor y verificar la firma del interlocutor. No es necesario
realizar un seguimiento de las claves y SA; IKE lo hace automticamente.
NOTA:
Para obtener ejemplos de ambos tneles (clave manual y AutoKey IKE), consulte
Redes privadas virtuales de punto a punto en la pgina 81.
Asociaciones de seguridad
Una asociacin de seguridad (SA) es un acuerdo unidireccional entre los
participantes VPN por lo que respecta a los mtodos y parmetros empleados para
garantizar la seguridad de un canal de comunicaciones. Una comunicacin
bidireccional completa requiere al menos dos SA, una para cada direccin.
Una SA agrupa los siguientes componentes para garantizar la seguridad de las
comunicaciones:
Claves y algoritmos de seguridad
Modo de protocolo (transporte o tnel)
Mtodo de administracin de claves (clave manual o AutoKey IKE)
Periodo de vigencia de SA
Para el trfico VPN saliente, la directiva invoca la SA asociada al tnel VPN. Para el
trfico entrante, el dispositivo de seguridad consulta la SA mediante los siguientes
tres elementos:
Conceptos de IPSec
IP de destino
Protocolo de seguridad (AH o ESP)
Valor del ndice de parmetros de seguridad (SPI)
Negociacin de tnel
Para un tnel IPSec de clave manual, como todos los parmetros de la SA se han
definido previamente, no es necesario negociar cul SA utilizar. Bsicamente, el
tnel ya se ha establecido. Cuando el trfico coincide con una directiva que utilice
ese tnel de clave manual o cuando una ruta utiliza el tnel, el dispositivo de
seguridad simplemente encripta y autentica los datos, como se haya determinado y
los enva a la puerta de enlace de destino.
Para establecer un tnel IPSec AutoKey IKE se requieren dos fases de negociacin:
En la fase 1, los participantes establecen un canal seguro en el que negociar las

SA IPSec.
En la fase 2, los participantes negocian las SA IPSec para encriptar y autenticar

los sucesivos intercambios de datos de usuario.
Fase 1
La fase 1 de una negociacin de tnel AutoKey IKE consiste en el intercambio de
propuestas sobre cmo autenticar y garantizar la seguridad del canal. El
intercambio se puede realizar en uno de estos dos modos: inmico o principal. En
cualquiera de los dos modos, los participantes intercambian propuestas de servicios
de seguridad aceptables, como por ejemplo:
Algoritmos de encriptacin (DES y 3DES) y de autenticacin (MD5 y SHA-1).

Para obtener ms informacin sobre estos algoritmos, consulte Protocolos en
la pgina 6.
Un grupo Diffie-Hellman (consulte Intercambio Diffie-Hellman en la

pgina 11).
Una clave previamente compartida o certificados RSA/DSA (consulte AutoKey

IKE en la pgina 7).
Una negociacin de fase 1 correcta concluye cuando ambos extremos del tnel se
ponen de acuerdo para aceptar al menos un conjunto de los parmetros de
seguridad de fase 1 propuestos y comienzan a procesarlos. Los dispositivos de
seguridad de Juniper Networks admiten hasta cuatro propuestas para negociaciones
de fase 1 y permiten definir el grado de restriccin del rango aceptable de
parmetros de seguridad para la negociacin de claves.
Las propuestas predefinidas de fase 1 que ofrece ScreenOS son las siguientes:
Estndar: 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
Bsicas: pre-g1-des-sha y pre-g1-des-md5
Tambin es posible definir propuestas de fase 1 personalizadas.
Negociacin de tnel
Modo principal y modo dinmico

La fase 1 se puede desarrollar en modo principal o en modo dinmico. Estos dos
modos se describen a continuacin.
Modo principal: el iniciador y el destinatario envan 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

encriptacin y autenticacin.
Segundo intercambio (mensajes 3 y 4): Ejecutar un intercambio Diffie-Hellman;

el iniciador y el destinatario ofrecen un nmero pseudoaleatorio cada uno.
Tercer intercambio (mensajes 5 y 6): enviar y verificar las identidades.
La informacin transmitida en el tercer intercambio de mensajes est protegida por

el algoritmo de encriptacin establecido en los dos primeros intercambios. Es decir,
las identidades de los participantes no se transmiten de modo transparente.
Modo dinmico: El iniciador y el destinatario logran los mismos objetivos, pero en
slo dos intercambios con un total de tres mensajes:
Primer mensaje: el iniciador propone la SA, inicia el intercambio Diffie-Hellman

y enva un nmero pseudoaleatorio y su identidad IKE.
Segundo mensaje: El destinatario acepta la SA, autentica al iniciador y enva un

nmero pseudoalatorio, 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, enva el certificado de iniciador.
Puesto que las identidades de los participantes se intercambian en modo

transparente (en los dos primeros mensajes), el modo dinmico no ofrece
proteccin de identidad.
NOTA:
10
Negociacin de tnel
Cuando un usuario VPN de acceso telefnico negocia un tnel AutoKey IKE con
una clave previamente compartida, se debe utilizar el modo dinmico. Recuerde
tambin que un usuario VPN de acceso telefnico puede utilizar una direccin de
correo electrnico, un nombre de dominio completo (FQDN) o una direccin IP
como su ID IKE. Un interlocutor dinmico puede utilizar una direccin de correo
electrnico o un FQDN, pero no una direccin IP.
Intercambio Diffie-Hellman
Un intercambio Diffie-Hellman (DH) permite a los participantes elaborar un valor
secreto compartido. El punto fuerte de esta tcnica es que permite a los
participantes crear el valor secreto a travs de un medio no seguro sin tener que
transmitir este valor por la lnea. Hay cinco grupos Diffie-Hellman; ScreenOS
admite los grupos 1, 2 y 5. El tamao del mdulo primario utilizado en el clculo de
cada grupo vara del siguiente modo:
NOTA:
Grupo DH 1: mdulo de 768 bits
Las ventajes de la seguridad que ofrece el grupo DH 1 se han depreciado y no se

recomienda su uso.
Cuanto mayor es un mdulo, ms segura se considera la clave generada; no
obstante, cuanto mayor es un mdulo, ms tarda el proceso de generacin de
claves. Como el mdulo de cada grupo DH tiene un tamao distinto, los
participantes tienen que ponerse de acuerdo para utilizar el mismo grupo.
NOTA:
Si configura mltiples propuestas (hasta cuatro) para negociaciones de fase 1,

utilice el mismo grupo Diffie-Hellman para todas ellas. La misma directriz se aplica
a la creacin de mltiples propuestas para negociaciones de fase 2.
Fase 2
Una vez que los participantes han establecido un canal seguro y autenticado,
continan con la fase 2, en la que negocian las SA para garantizar la seguridad de
los datos que se van a transmitir a travs del tnel IPSec.
Al igual que ocurre en la fase 1, los participantes intercambian propuestas para
determinar los parmetros de seguridad que se van a emplear en la SA. Una
propuesta de fase 2 incluye tambin un protocolo de seguridad (encabezado de
autenticacin, AH, o carga de seguridad encapsulada, ESP) y algoritmos de
encriptacin y autenticacin seleccionados. La propuesta tambin puede especificar
un grupo Diffie-Hellman si se desea una confidencialidad directa perfecta (PFS).
Independientemente del modo utilizado en la fase 1, la fase 2 funciona siempre en
modo rpido e implica el intercambio de tres mensajes.
Los dispositivos de seguridad de Juniper Networks admiten hasta cuatro propuestas
para negociaciones de fase 2 y permiten definir el grado de restriccin del rango
aceptable de parmetros de tnel. ScreenOS tambin ofrece una funcin de
proteccin contra reprocesamiento de paquetes. El uso de esta funcin no requiere
negociacin porque los paquetes se envan siempre con nmeros de secuencia.
Slo existe la opcin de comprobar o no los nmeros de secuencia. (Para ms
informacin sobre la proteccin contra reprocesamiento de paquetes, consulte
Proteccin contra reprocesamiento de paquetes en la pgina 12).
Negociacin de tnel
11
Las propuestas predefinidas de fase 2 que ofrece ScreenOS son las siguientes:
Estndar: 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
Bsicas: nopfs-esp-des-sha y nopfs-esp-des-md5
Tambin es posible definir propuestas de fase 2 personalizadas.

En la fase 2, los interlocutores tambin intercambian ID de proxy. Una ID de proxy
es una tupla de tres partes compuesta por direccin IP local/direccin 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
idntico, y la direccin IP local indicada para un interlocutor debe ser igual que la
direccin IP remota indicada para el otro interlocutor.
Confidencialidad directa perfecta

La confidencialidad directa perfecta (PFS) es un mtodo 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 mnimo de procesamiento de CPU. Lamentablemente, si un
interlocutor no autorizado obtiene acceso a la clave SKEYID_d, todas las claves de
encriptacin quedarn comprometidas.
PFS afronta este riesgo de seguridad forzando un nuevo intercambio de claves
Diffie-Hellman para cada tnel de fase 2. Por lo tanto, utilizar PFS es ms seguro,
aunque el procedimiento de reencriptacin de la fase 2 puede prolongarse
ligeramente si la funcin PFS est habilitada.
Proteccin contra reprocesamiento de paquetes

Se produce un ataque de reproduccin 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 funcin de
proteccin contra reprocesamiento de paquetes permite que los dispositivos de
seguridad comprueben cada paquete IPSec para verificar si se ha recibido
previamente. Si llegan paquetes fuera de un rango de secuencia especificado, el
dispositivo de seguridad los rechaza.
Paquetes IKE e IPSec

Un tnel VPN IPSec consta de dos elementos importantes:
12
Configuracin del tnel: En primer lugar, los interlocutores establecen las

asociaciones de seguridad (SA), que definen los parmetros para asegurar el
trfico entre ellos. Los administradores de cada extremo pueden definir las SA
manualmente, o bien dinmicamente durante las negociaciones IKE de fase 1 y
fase 2. La fase 1 se puede desarrollar en modo principal o en modo dinmico.
La fase 2 ocurre siempre en modo rpido.
Seguridad aplicada: IPSec protege el trfico enviado entre los dos puntos
terminales del tnel usando los parmetros de seguridad definidos en las SA
que los interlocutores acordaron durante la configuracin del tnel. IPSec
puede aplicarse en uno de dos modos: transporte o tnel. Ambos modos
admiten los dos protocolos IPSec: carga de seguridad encapsulada (ESP) y
encabezado de autenticacin (AH).
Para obtener una explicacin del procesamiento de paquetes que se produce

durante las etapas IKE e IPSec de un tnel VPN, consulte Paquetes IKE en la
pgina 13 y Paquetes IPSec en la pgina 16. Dichas secciones muestran los
encabezados de los paquetes para IKE e IPSec, respectivamente.
Paquetes IKE
Cuando un paquete de texto sin formato que requiere encapsulamiento llega al
dispositivo de seguridad y no existe ninguna SA activa de fase 2 para ese tnel, el
dispositivo de seguridad inicia las negociaciones IKE (y descarta el paquete). 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. La carga de datos del
paquete IP icnluye un segmento UDP que encapsula una asociacin de seguridad
de Internet y protocolo de gestin de claves (ISAKMP), o paquete IKE. El formato de
los paquetes IKE es igual para la fase 1 y la fase 2.
NOTA:
Cuando se descarta el paquete IP inicial, el host de origen lo reenva. Tpicamente,

para cuando el segundo paquete alcanza el dispositivo de seguridad, las
negociaciones IKE se han completado y el dispositivo de seguridad lo protege
(como tambin protege todos los paquetes subsiguientes de esa sesin) con IPSec
antes de reenviarlo.
13
Figura 7: Paquete IKE para las fases 1 y 2

Encabezado
IP
Encabezado
UDP
Encabezado
ISAKMP
Carga de
datos
Nota: ISAKMP es el formato de paquetes utilizado por IKE.
Encabezado IP
Longitud del
encabezado
Versin
Tipo de servicio
Tamao total del paquete (en bytes)
Identificacin
Tiempo de vida (TTL)
Desplazamiento del fragmento
Protocolo (17 para UDP)
Suma de comprobacin del encabezado
Direccin de origen (puerta de enlace del interlocutor local)

Direccin de destino (puerta de enlace del interlocutor remoto)
Opciones (si las hay)
Relleno
Carga de datos IP
Encabezado UDP
Puerto de origen (500 para IKE)
Puerto de destino (500 para IKE)

Suma de comprobacin
Longitud
Carga de datos UDP
Encabezado ISAKMP (para IKE)
Cookie del iniciador
Cookie del respondedor
(0000 para el primer paquete)
Carga de datos siguiente
Ver may
Ver men
Tipo del intercambio
Indicadores
ID del mensaje
Longitud del mensaje
Carga de datos ISAKMP
El campo de carga de datos siguiente contiene un nmero que indica uno de los
siguientes tipos de carga de datos:
14
0002Carga de datos de la negociacin SA: incluye una definicin para la SA

de fase 1 o fase 2.
0004Carga de datos de la propuesta: puede ser una propuesta de fase 1 o

fase 2.
0008Carga de datos de transformacin: La carga de datos de transformacin

es encapsulada en una carga de datos propuesta que se encapsula en una carga
de datos SA.
0010Carga de datos de intercambio de datos (KE): contiene la informacin

necesaria para realizar un intercambio de claves, como un valor pblico
Diffie-Hellman.
0020Carga de datos de identificacin (IDx).
En la fase 1, IDii indica la identificacin 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 ID IKE, como FQDN, U-FQDN, direccin
IP y ASN.1_DN.
0040Carga de datos de certificados (CERT).
0080Carga de datos de peticin de certificado (CERT_REQ).
0100Carga de datos de Hash (HASH): contiene el resultado resumido de una

determinada funcin de transformacin hash.
0200Carga de datos de firma (SIG): contiene una firma digital.
0400Carga de datos Nonce (Nx): contiene informacin pseudoaleatoria

necesaria para el intercambio.
0800Carga de datos de notificacin.
1000Carga de datos de eliminacin ISAKMP.
2000Carga de datos de ID del vendedor (VID): puede incluirse en cualquier

parte de las negociaciones de la fase 1. ScreenOS la utiliza para marcar la
compatibilidad con NAT-T.
Cada carga de datos ISAKMP comienza con el mismo encabezado genrico, como
se muestra en la Figura 8.
Figura 8: Encabezado genrico de la carga de datos ISAKMP
Siguiente encabezado
Longitud de la carga de datos (en bytes)
Reservado
Carga de datos
Puede haber mltiples cargas de datos ISAKMP encadenadas, indicndose cada tipo
de carga de datos subsiguiente en el valor del campo del siguiente encabezado. Un
valor de 0000 indica la ltima carga de datos ISAKMP. Consulte la Figura 9 en la
pgina 16 para obtener un ejemplo.
15
Figura 9: Encabezado ISAKMP con cargas de datos genricas ISAKMP

SPI del iniciador
SPI del respondedor (0000 para el primer paquete)
Carga de datos siguiente
(0002 para SA)
Maj Ver
Min Ver
Tipo del intercambio
Indicadores
Encabezado
de ISAKMP
ID del mensaje
Longitud total del mensaje
Encabezado siguiente
(0004 para propuesta)
Reservado
Longitud de la carga de datos SA

Carga de datos SA
(0008 para transformacin)
Longitud de la carga de datos de la propuesta
Reservado
Carga de datos propuesta
(0000 para fin)
Reservado
Longitud de la carga de datos de transformacin
Carga de datos de transformacin
Carga de datos
SA
Carga de
datos
propuesta
Carga de datos
de
transformacin
Paquetes IPSec
Una vez completadas las negociaciones IKE y despus de que las dos puertas de
enlace IKE hayan establecido las asociaciones de seguridad de fase 1 y fase 2 (SA),
el dispositivo NetScreen aplica la proteccin IPSec a los paquetes IP de texto sin
formato subsiguientes que los hosts situados detrs de una puerta de enlace IKE
envan a los hosts que se encuentran detrs de la otra puerta de enlace (asumiendo
que las directivas permitan el trfico). Si la SA de fase 2 especifica el protocolo de
seguridad encapsulada (ESP) en modo de tnel, el paquete se parecer al que
aparece debajo. El dispositivo de seguridad agrega dos encabezados adicionales al
paquete original enviado por el host.
NOTA:
Para obtener ms informacin sobre ESP, consulte Carga de seguridad

encapsulada en la pgina 6. Para obtener informacin sobre el modo de tnel,
consulte Modo de tnel en la pgina 4.
Figura 10: Paquete IPSec datos de seguridad encapsulada (ESP) en el modo de tnel
Paquete IPSec
enviado por la puerta
de enlace IKE
Encabezado
IP2
Encabezado
ESP
Paquete original
enviado por el host iniciador
Encabezado
IP1
Encabezado
TCP
Carga de datos
La puerta de enlace local agrega

estos encabezados al paquete.
Como muestra la Figura 10, el paquete que el host iniciador construye incluye la
carga de datos, el encabezado TCP y el encabezado IP interno (IP1).
16
El encabezado IP externo (IP2) que agrega el dispositivo de seguridad contiene la

direccin IP de la puerta de enlace remota como direccin IP de destino y la
direccin IP del dispositivo de seguridad local como direccin IP de origen. El
dispositivo de seguridad tambin agrega un encabezado ESP entre los encabezados
IP externo e interno. El encabezado ESP contiene informacin que permite al
interlocutor remoto procesar correctamente el paquete al recibirlo. Se ilustra en la
Figura 11 en la pgina 17.
Figura 11: Encabezado IP externo (IP2) y encabezado ESP
Encabezado IP externo (IP2)
Versin
Longitud de
encabezado
Tipo de servicio
0
Identificacin
Protocolo (50 para ESP)
Direccin de origen (puerta de enlace del interlocutor local)

Direccin de destino (puerta de enlace del interlocutor remoto)
Relleno
Carga de datos
Encabezado ESP
ndice de parmetros de seguridad (Security Parameters Index o SPI) del interlocutor remoto *
Nmero correlativo*
Vector de inicializacin* (IV) Primeros 8 octetos del campo de datos
Autenticado
Carga de datos** (variable)
Encriptado
Relleno** (0-255 bytes)
Longitud de relleno**
(4 para IP)**
Datos de autenticacin (variables)

* = secciones autenticadas del paquete
** = secciones encriptadas del paquete
El campo de encabezado siguiente indica el tipo de datos contenidos en el campo

de carga de datos. En el modo de tnel, 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.
17
Figura 12: Encabezado IP interno (IP1) y encabezado TCP

Encabezado IP interno (IP1)
Versin
Longitud de
encabezado
Tipo de servicio
Identificacin
Protocolo (6 para TCP)

Direccin de origen (host iniciador)

Direccin de destino (host receptor)
Relleno
Carga de datos
Encabezado TCP
Puerto de destino
Puerto de origen
Nmero de secuencia
Nmero de reconocimiento
Longitud de
encabezado
Reservado
U A
R C
G K
Suma de comprobacin
P
S
H
R
S
T
S
Y
N
F
I
N
Tamao de la ventana
Indicador Urgente
Padding
Datos
18
Relleno
Captulo 2
Criptografa de claves pblicas

En este captulo se ofrece una introduccin a la criptografa de claves pblicas y al
uso de certificados y listas de revocacin de certificados (CRL, o Certificate
Revocation Lists) en el marco de las infraestructuras de claves pblicas (PKI,
o Public Key Infraestructure). Este captulo incluye los siguientes temas:
Introduccin a la criptografa de claves pblicas en la pgina 20
Firma de un certificado en la pgina 20
Verificacin de una firma digital en la pgina 20
Infraestructura de claves pblicas en la pgina 22
Certificados y CRL en la pgina 24
Carga de certificados y listas de revocacin de certificados en la

pgina 28
Configuracin de ajustes de CRL en la pgina 29
Obtencin automtica de un certificado local en la pgina 31
Renovacin automtica de certificado en la pgina 34
Protocolo de estado de certificado en lnea (OCSP) en la pgina 35
Generacin de pares de claves en la pgina 35
Especificacin de un mtodo de comprobacin de revocacin de

certificados en la pgina 36
Especificacin de una URL del servidor de respuesta del protocolo de

estado de certificado en lnea en la pgina 37
Certificados autofirmados en la pgina 38
Eliminacin de atributos de comprobacin de estado en la pgina 37
Creacin manual de certificados autofirmados en la pgina 40
19
Establecimiento de un certificado autofirmado y definido por el

administrador en la pgina 41
Eliminar certificados autofirmados en la pgina 46
Introduccin a la criptografa de claves pblicas

En la criptografa de claves pblicas se utiliza el par formado por una clave pblica y
otra privada para encriptar y desencriptar datos. Los datos encriptados con una
clave pblica, que su propietario pone a disposicin de otros usuarios, slo 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 pblica de l para encriptarlo y,
a continuacin, se lo enviar. Cuando reciba el mensaje, Juan podr desencriptarlo
con su clave privada.
El mtodo inverso tambin resulta de gran utilidad; esto es, encriptar los datos con
una clave privada y que se puedan desencriptar con la clave pblica
correspondiente. Este mtodo 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 enva de forma pblica a Juan. A continuacin, Juan slo puede
desencriptar los datos utilizando la clave pblica de Alicia, lo que significa que lo ha
enviado ella.
Los conjuntos de claves privada y pblica tambin desempean un importante
papel en el uso de certificados digitales. El procedimiento para firmar un certificado
(por parte de una autoridad de certificacin) y, despus, verificar la firma (por parte
del receptor) se desarrolla tal y como se indica en las siguientes subsecciones:
Firma de un certificado
1. La autoridad de certificacin (CA) que emite el certificado lo somete a una
operacin matemtica en la que se utiliza un algoritmo hash (MD5 o SHA-1)
para generar una codificacin.
2. A continuacin, la CA firma el certificado encriptando la codificacin con su
clave privada. El resultado es una firma digital.
3. La CA enva el certificado firmado digitalmente a la persona que lo solicit.
Verificacin de una firma digital

1. Cuando el destinatario recibe el certificado, tambin genera otra codificacin
aplicando el mismo algoritmo hash (MD5 o SHA-1) en el archivo de certificado.
2. El destinatario utiliza la clave pblica de la CA para desencriptar la firma digital.
3. El destinatario compara la codificacin desencriptada con la que se acaba de
generar. Si las dos coinciden, el destinatario puede confirmar la integridad de la
firma de la CA y, por extensin, la integridad del certificado que lo acompaa.
20
Captulo 2: Criptografa de claves pblicas
Figura 13: Verificacin de firma digital

Emisor (CA)
1. La CA genera la codificacin A a partir del certificado utilizando
el algoritmo hash MD5 o SHA-1.
Codif. A
Cert.
Algoritmo hash
(MD5 o SHA-1)
2. Con su clave privada, la CA encripta la codificacin A. El

resultado es la codificacin B, la firma digital.
3. La CA enva el certificado firmado digitalmente a la persona que
lo solicit.
Codif. B
Clave privada de la CA
Receptor
1. Genera la codificacin A a partir del certificado utilizando MD5 o

SHA-1.
2. Utilizando la clave pblica de la CA, desencripta la codificacin B.
3. Compara la codificacin A con la B. Si coinciden, el receptor sabr
que el certificado no est manipulado.
Codif. A
Comparacin
Cert.
Algoritmo hash
(MD5 o SHA-1)
Codif. B
Clave privada de la CA
El procedimiento de firma digital de los mensajes enviados por dos participantes en

una sesin IKE funciona de forma muy parecida, con las siguientes diferencias:
En lugar de generar una codificacin a partir del certificado de la CA, el emisor

lo genera a partir de los datos del paquete IP.
En lugar de utilizar el par de claves pblica/privada de la CA, los participantes

utilizan el par de claves pblica/privada del emisor.
21
Infraestructura de claves pblicas

La infraestructura de claves pblicas (PKI) hace referencia a la estructura jerrquica
de confianza necesaria para la correcta implementacin de la criptografa de claves
pblicas. 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 raz de un dominio de CA.
Figura 14: Jerarqua de PKI en Trust Dominio de CA
La CA de nivel raz valida las CA subordinadas.
Las CA subordinadas
validan certificados locales
y a otras CA.
Los certificados locales

contienen la clave pblica
del usuario.
22
Si los certificados se utilizan exclusivamente dentro de una organizacin, dicha

organizacin puede tener su propio dominio de CA dentro del cual una CA de la
empresa emite y valida certificados entre sus empleados. Si despus esa
organizacin desea que sus empleados puedan intercambiar sus certificados con
otro dominio de CA (por ejemplo, con empleados de otra organizacin que tiene su
propio dominio de CA), las dos CA pueden desarrollar una certificacin 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.
Figura 15: Certificacin cruzada
Dominio CA: B
Dominio CA: A
Certificacin 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
certificacin cruzada entre s.
Por motivos prcticos y de comodidad, la PKI debe administrarse e implementarse

de forma transparente. Para conseguirlo, ScreenOS hace lo siguiente:
1. Genera un par de claves pblica/privada cuando se crea una peticin de
certificado.
2. Proporciona esa clave pblica como parte de la peticin de certificado en un
archivo de texto que se transmite a una autoridad de certificacin (CA) para la
inscripcin del certificado (archivo PKCS 10).
3. Permite cargar el certificado local, el certificado de CA y la lista de revocacin
de certificados (SubinterfaceCRL) en la unidad.
NOTA:
La autoridad de certificacin normalmente proporciona una CRL. Aunque puede

cargar una CRL en el dispositivo de seguridad, no podr verla una vez cargada.
Tambin puede especificar un intervalo de tiempo para actualizar la CRL
automticamente. Para obtener ms informacin sobre las CRL, consulte
Certificados y CRL en la pgina 24.
4. Permite enviar certificados cuando se establece un tnel IPSec.
23
5. Admite la validacin ascendente de rutas de certificados a travs de ocho

niveles de autoridades CA en la jerarqua PKI.
6. Es compatible con la norma de criptografa PKCS 7, lo que significa que el
dispositivo de seguridad puede aceptar certificados X.509 y CRL empaquetadas
segn la norma PKCS 7. La compatibilidad con PKCS 7 permite enviar
mltiples certificados X.509 dentro de una nica peticin PKI. Ahora es posible
configurar PKI para validar a la vez todos los certificados enviados por la CA
emisora.
NOTA:
ScreenOS admite un tamao de archivo PKCS n. 7 de hasta 7 kB.

7. Admite recuperacin de CRL en lnea a travs de LDAP o HTTP.
Certificados y CRL
Un certificado digital es un mtodo electrnico para verificar la identidad de un
usuario utilizando la palabra de una tercera parte en la que se confa, conocida
como autoridad de certificacin (CA). El servidor de CA que se utilice puede ser
propiedad de una CA, que tambin se encargue de su manejo, o de su propia
organizacin, 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 revocacin de certificados) o la
informacin que dichos servidores necesitan cuando envan peticiones de
certificados personales. Si es su propia CA, podr hacerlo usted mismo.
NOTA:
ScreenOS admite las siguientes CA: Baltimore, Entrust, Microsoft, Netscape, RSA
Keon y Verisign.
ScreenOS dispone de un certificado de CA para las descargas de autenticacin
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 ms informacin sobre el
servidor de archivos de firmas de virus, consulte Anlisis antivirus en la
pgina 4-62. Para obtener ms informacin 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 pgina 4-124.
Para utilizar un certificado digital y as autenticar su identidad al establecer una
conexin VPN segura, siga estos pasos:
24
Certificados y CRL
Genere una clave en el dispositivo de seguridad, envela a una CA para obtener

un certificado personal (que tambin se conoce como un certificado local) y
cargue el certificado en el dispositivo de seguridad.
Consiga un certificado de la CA que emiti el certificado personal (bsicamente

para verificar la identidad de la CA que lo verifica a usted) y cargue el
certificado de la CA en el dispositivo de seguridad. Esta tarea puede realizarla
manual o automticamente, utilizando el protocolo de inscripcin de
certificado sencillo (SCEP, Simple Certificate Enrollment Protocol).
Si el certificado no contiene la extensin de punto de distribucin de

certificados (CDP) y no recibe automticamente la CRL a travs de LDAP o
HTTP, puede obtenerla manualmente y cargarla en el dispositivo de seguridad.
Durante el proceso de negociacin, 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 solucin es limitada) o con referencia a la CRL de una CA, a la que se
puede acceder en lnea de forma automtica en intervalos diarios, semanales o
mensuales o segn el intervalo predefinido por la CA.
Para conseguir un certificado firmado digitalmente siguiendo el mtodo manual,
debe seguir estos pasos:
1. Generar un par de claves pblica/privada
2. Llenar la peticin de certificado
3. Enviar la peticin a la CA que desee
4. Una vez recibido el certificado firmado, cargarlo en el dispositivo de seguridad
junto con el certificado de CA
Ahora dispondr de los siguientes elementos con los siguientes objetivos:
NOTA:
Un certificado local para el dispositivo de seguridad para autenticar su

identidad en cada conexin de tnel
Un certificado de CA (clave pblica de la CA), para verificar el certificado del

otro interlocutor
Si la lista de revocacin de certificados (CRL) est incluida en el certificado de

CA, una CRL para identificar certificados no vlidos
La CRL puede acompaar al certificado de CA y se puede almacenar en la base de

datos de ScreenOS 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 mtodos,
puede introducir manualmente la URL de la CRL en el dispositivo de seguridad, tal
y como se explica en Configuracin de ajustes de CRL en la pgina 29.
Cuando reciba estos archivos (los archivos de certificado suelen tener extensin la
.cer y los archivos de CRL, la extensin .crl), crguelos en el dispositivo de
seguridad siguiendo el procedimiento descrito en Peticin manual de un
certificado en la pgina 26.
NOTA:
Si piensa utilizar el correo electrnico para enviar un archivo PKCS 10 y obtener

los certificados, debe configurar adecuadamente los ajustes de ScreenOS para
poder enviar mensajes de correo electrnico al administrador del sistema. Deber
establecer los servidores DNS principal y secundario, y especificar los ajustes de
direccin del servidor SMTP y del servidor de correo.
Certificados y CRL
25
Peticin manual de un certificado

Cuando se solicita un certificado, el dispositivo de seguridad genera un par de
claves. La clave pblica se incorpora en la propia peticin y, posteriormente, en el
certificado local firmado digitalmente que recibir de la CA.
En el siguiente ejemplo, el administrador de seguridad realiza una peticin de
certificado para Michael Zhang en el departamento de desarrollo de
Juniper Networks in Sunnyvale, California. Este certificado se utilizar en un
dispositivo de seguridad con la direccin IP 10.10.5.44. El administrador ordena al
dispositivo de seguridad que enve la peticin por correo electrnico al
administrador de seguridad, que tiene la direccin admin@juniper.net.
A continuacin, el administrador de seguridad copia la peticin y la pega en el
campo de texto de peticin de certificado en el punto de inscripcin de certificados
de la CA. Una vez finalizado el proceso de inscripcin, la CA normalmente devuelve
el certificado por correo electrnico al administrador de seguridad.
NOTA:
Una cadena de identidad certificada especial, llamada dominio-componente, est

disponible nicamente a travs de la CLI. Los dispositivos pueden utilizar este
valor en certificados para que IPSec se conecte a puertas de enlace VPN. Por
ejemplo, el dispositivo puede utilizarlo como una ID IKE de grupo, aceptando las
identidades IKE tipo ASN1_DN que contienen DC=Ingenieros, DC=NuevaYork.
Antes de generar una peticin 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 de seguridad. Si el dispositivo de seguridad se encuentra en un clster
NSRP, sustituya el nombre de host por un nombre de clster. Para obtener ms
informacin, consulte Creacin de un clster de NSRP en la pgina 11-29.)
WebUI
1.
Generacin 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
IP Address: 10.10.5.44
Write to file: (seleccione)
RSA: (seleccione)
Create new key pair of 1024 length: (seleccione)
El dispositivo de seguridad genera un archivo PKCS n. 10 y solicita que enve

el archivo por correo electrnico, lo guarde en disco o lo inscriba
automticamente a travs del protocolo SCEP (Simple Certificate Enrollment
Protocol).
Seleccione la opcin E-mail to, escriba admin@juniper.net y despus haga
clic en OK.
26
Certificados y CRL
NOTA:
Determinadas CA no admiten direcciones de correo electrnico en los

certificados. Si no incluye una direccin de correo electrnico en la peticin de
certificado local, no podr utilizarla como identificacin de IKE local al configurar
el dispositivo de seguridad como interlocutor dinmico. En su lugar, podr utilizar
un nombre de dominio completo (si se encuentra en el certificado local) o dejar el
campo vaco. Predeterminadamente el dispositivo de seguridad enva su
nombrehost.nombredominio. Si no especifica la identificacin local para un
interlocutor dinmico, introduzca el nombrehost.nombredominio del interlocutor
en el dispositivo que se encuentra en el otro extremo del tnel IPSec en el campo
de identificacin del interlocutor.
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 pgina 3-5), asegrese
de que utiliza una longitud de bits que tambin sea compatible con su explorador.
Si utiliza la direccin de correo electrnico, se supone que ya ha configurado la
direccin IP para el servidor SMTP: set admin mail server-name { dir_ip |
nombre_dom }.
2.
Peticin 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
detrs del texto (comenzando por -----BEGIN CERTIFICATE REQUEST----- y
finalizando en -----END CERTIFICATE REQUEST-----).
A continuacin, el administrador de seguridad sigue las direcciones de la
peticin de certificado en el sitio web de la CA, pegando el archivo PKCS no. 10
en el campo apropiado.
3.
Recuperacin del certificado
Cuando el administrador de seguridad recibe el certificado de la CA por correo

electrnico, se lo reenva a usted. Cpielo en un archivo de texto y gurdelo en
su estacin de trabajo (para despus cargarlo en el dispositivo de seguridad a
travs de la interfaz WebUI) o en un servidor TFTP (para cargarlo a travs de
CLI).
CLI
1.
Generacin 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
exec pki rsa new-key 1024
Certificados y CRL
27
NOTA:
Si utiliza la direccin de correo electrnico, se supone que ya ha configurado la

direccin IP para el servidor SMTP: set admin mail server-name { dir_ip |
nombre_dom }.
La peticin de certificado se enva por correo electrnico a admin@juniper.net.
2.
Peticin 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
detrs del texto (comenzando por -----BEGIN CERTIFICATE REQUEST----- y
finalizando en -----END CERTIFICATE REQUEST-----).
A continuacin, el administrador de seguridad sigue las direcciones de la
peticin de certificado en el sitio web de la CA, pegando el archivo PKCS n. 10
en el campo apropiado.
3.
Recuperacin del certificado
Cuando el administrador de seguridad recibe el certificado de la CA por correo

electrnico, se lo reenva a usted. Cpielo en un archivo de texto y gurdelo en
su estacin de trabajo (para despus cargarlo en el dispositivo de seguridad a
travs de la interfaz WebUI) o en un servidor TFTP (para cargarlo a travs de
CLI).
Carga de certificados y listas de revocacin de certificados

La CA le devuelve los siguientes tres archivos para que los cargue en el dispositivo
de seguridad:
Un certificado de CA, que contiene la clave pblica de la CA
Un certificado local, que identifica su equipo local (su clave pblica)
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 estacin de trabajo del administrador. Para el ejemplo con
CLI, habr descargado el directorio raz TFTP a un servidor TFTP con la direccin
IP 198.168.1.5.
NOTA:
Los dispositivos de seguridad de Juniper Networks configurados con ScreenOS 2.5

o versiones posteriores (incluyendo los sistemas virtuales) permiten cargar
certificados locales desde distintas CA.
En este ejemplo se muestra cmo se deben cargar dos archivos distintos, llamados
auth.cer (certificado de CA) y local.cer (su clave pblica), junto con el archivo de
CRL llamado distrust.crl.
WebUI
1. Objects > Certificates: Seleccione Load Cert y despus haga clic en Browse.
2. Acceda al directorio C:\certs, seleccione auth.cer y despus haga clic en Open.
28
Certificados y CRL
La ruta del directorio y el nombre de archivo (C:\certs\ns\auth.cer) aparecern

en el campo File Browse.
3. Haga clic en Load.
Se cargar el archivo local.cer.
4. Objects > Certificates: Seleccione Load Cert y despus haga clic en Browse.
5. Acceda al directorio C:\certs, seleccione local.cer y despus haga clic en Open.
La ruta del directorio y el nombre de archivo (C:\certs\ns\local.cer) aparecern
en el campo File Browse.
El archivo del certificado local.cer se carga.
7. Objects > Certificates: Seleccione Load CRL y despus haga clic en Browse.
8. Acceda al directorio C:\certs, seleccione distrust.cer y despus haga clic
en Open.
Se cargar el archivo de CRL distrust.crl.
CLI
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
Configuracin 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
vlidos. Si una CRL no est cargada en la base de datos de ScreenOS, el dispositivo
de seguridad intentar recuperarla mediante la ubicacin de LDAP o HTTP CRL
definida en el propio certificado. Si no hay ninguna direccin URL definida en el
certificado, el dispositivo de seguridad utiliza la URL del servidor definido para ese
certificado de CA. Si el certificado de CA no est cargado en el dispositivo (por
ejemplo, una CA intermedia de la cadena del certificado recibida durante el
intercambio de IKE), no puede resolver la URL del servidor de CRL para esa CA. En
este caso, puede especificar la URL del servidor de CRL en la seccin de Ajustes de
validacin del certificado predeterminado de la UI de web (consulte la siguiente
pgina). Una URL del servidor de CRL que se introduzca aqu slo se utilizar
cuando el certificado de CA no est presente en el dispositivo. No hay una URL
predeterminada.
Certificados y CRL
29
NOTA:
La extensin del punto de distribucin de la CRL (.cdp) en un certificado X509

puede ser una URL HTTP o una URL LDAP.
Con ScreenOS 2.5 y versiones posteriores, al cargar la CRL puede desactivar la
comprobacin de firmas digitales. Sin embargo, si desactiva la comprobacin del
certificado de CRL pondr en peligro la seguridad de su dispositivo.
En este ejemplo, primero configurar el servidor de CA Entrust para comprobar la
CRL diariamente mediante una conexin al servidor LDAP ubicado en 2.2.2.121 y
la localizacin del archivo de CRL. A continuacin configurar los ajustes
predeterminados de validacin de certificados para su uso en el servidor LDAP
ubicado en 10.1.1.200, comprobando tambin diariamente la CRL.
NOTA:
El nmero de ndice (IDX) para el certificado de Entrust CA es 1. Para poder ver

una lista de los nmeros IDX de todos los certificados de CA cargados en un
dispositivo de seguridad, 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:
URL Address: ldap:///CN=Entrust,CN=en2001,CN=PublicKeyServices,
CN=Services,CN=Configuration,DC=EN2001,DC=com?CertificateRevocati
onList?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?CertificateRevoc
ationList?base?objectclass=CRLDistributionPoint
LDAP Server: 10.1.1.200
30
Certificados y CRL
CLI
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?
CertificateRevocationList?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=SAFE
CERT,
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
Obtencin automtica de un certificado local

Para utilizar un certificado digital y as autenticar su identidad al establecer una
conexin VPN segura, siga estos pasos:
Consiga el certificado de una autoridad de certificacin (CA) de la cual desee

obtener un certificado personal y crguelo en el dispositivo de seguridad.
Obtenga un certificado local (tambin llamado certificado personal) de la CA

cuyo certificado de CA ya ha cargado y, a continuacin, cargue el certificado
local en el dispositivo de seguridad. Esto lo puede hacer manual o
automticamente, utilizando el protocolo SCEP (Simple Certificate Enrollment
Protocol).
Como durante el mtodo manual para solicitar certificados locales se le va a pedir

que copie informacin de un certificado a otro, puede llegar a ser un proceso largo.
Para evitarlo, puede utilizar el mtodo automtico.
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 pgina 2-219.)
Ajustar el reloj del sistema. (Consulte Reloj del sistema en la pgina 2-256.)
Asignar un nombre de host y un nombre de dominio al dispositivo de

seguridad. Si el dispositivo de seguridad se encuentra en un clster NSRP,
sustituya el nombre de host por un nombre de clster. Para obtener ms
informacin, consulte Creacin de un clster de NSRP en la pgina 11-29.)
En este ejemplo seguir el mtodo automtico para solicitar un certificado local. Se

utiliza SCEP con la CA Verisign. Establecer los siguientes ajustes de CA:
Validacin de la ruta de certificado completa
RA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
Certificados y CRL
31
NOTA:
La interfaz de puerta de enlace comn (CGI, o Common Gateway Interface) es

un mtodo estndar que utilizan los servidores web para enviar una peticin de
usuario a un programa de aplicacin 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.
CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
Confirmacin automtica 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
Contrasea de desafo
Sondeo automtico de certificado cada 30 minutos (de forma predeterminada

no se realiza ningn sondeo)
A continuacin generar un par de claves RSA, especificando una longitud de

1024 bits, e iniciar la operacin 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 nmero de ndice (IDX).
En este ejemplo, el nmero IDX de la CA Verisign es 1. Para consultar los nmeros
IDX para los certificados de CA, utilice el siguiente comando: get pki x509 list
ca-cert. Aparecer un nmero IDX y un nmero de ID para cada certificado.
Apunte el nmero IDX y utilcelo para hacer referencia al certificado de CA en los
comandos.
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.verisign.com/cgi-bin/pkiclient.exe
CA CGI: http://ipsec.verisign.com/cgi-bin/pkiclient.exe
> Advanced: Introduzca los siguientes ajustes avanzados, despus haga

clic en Return para regresar a la pgina de configuracin bsica CA Server
Settings:
Polling Interval: 30
Certificate Authentication: Auto
Certificate Renew: 14
32
Certificados y CRL
2.
Peticin de certificado local
en Generate:
Name: Michael Zhang
Phone: 408-730-6000
Unit/Department: Development
Organization: Juniper Networks
County/Locality: Sunnyvale
State: CA
Country: US
Email: mzhang@juniper.net
Key Pair Information
RSA: (seleccione)
Create new key pair of 1024 length.
NOTA:
El valor 1024 indica la longitud en bits del par de claves. Si va a utilizar el

certificado para SSL, asegrese de que utiliza una longitud de bits que tambin sea
compatible con su explorador.
Ejecute el comando CLI get pki x509 pkcs para que el dispositivo de seguridad
genere un archivo PKCS n. 10 y, a continuacin, siga uno de estos pasos:
3.
Enviar el archivo PKCS n. 10 de peticin de certificado a una direccin de

correo electrnico
Guardarlo en disco
Inscribirlo automticamente enviando el archivo a una CA que admita el

protocolo (SCEP)
Inscripcin automtica
Seleccione la opcin Automatically enroll to, luego la opcin Existing CA

server settings y finalmente seleccione Verisign en la lista desplegable.
Pngase en contacto con Verisign para informarles sobre su peticin de
certificado. Verisign debe autorizar la peticin de certificado antes de que usted
pueda descargarlo.
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
set pki authority 1 scep ra-cgi http://ipsec.verisign.com/cgi-bin
/pkiclient.exe
set pki authority 1 scep polling-int 30
set pki authority 1 scep renew-start 14
Certificados y CRL
33
NOTA:
La interfaz de puerta de enlace comn (CGI, o Common Gateway Interface) es

un mtodo estndar que utilizan los servidores web para enviar una peticin de
usuario a un programa de aplicacin 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.
2.
Peticin 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.
Inscripcin automtica
exec pki x509 scep 1
Si sta es la primera peticin de certificado que enva 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.
Pngase en contacto con Verisign para informarles sobre su peticin de certificado.
Verisign debe autorizar la peticin de certificado antes de que usted pueda
descargarlo.
Renovacin automtica de certificado

Puede habilitar el dispositivo de seguridad para que renueve automticamente los
certificados adquiridos a travs del protocolo SCEP (Certificate Enrollment
Protocol). Esta funcin evita tener que acordarse de renovar los certificados en el
dispositivo de seguridad antes de que venzan y, por el mismo token, mantiene la
validez de los certificados en todo momento.
De forma predeterminada, esta funcin est inhabilitada. Puede configurar el
dispositivo de seguridad para que enve automticamente una peticin para
renovar un certificado antes de que venza. Puede establecer el momento en que
desee que el dispositivo de seguridad enve la peticin de renovacin del certificado
en das y minutos antes de la fecha de vencimiento. Si establece momentos
distintos para cada certificado, evitar que el dispositivo de seguridad tenga que
renovar todos los certificados al mismo tiempo.
34
Certificados y CRL
Para evitar problemas con esta funcin, el dispositivo de seguridad debe ser capaz
de acceder al servidor SCEP y el certificado debe estar presente en el propio
dispositivo de seguridad durante el proceso de renovacin. Tambin debe
asegurarse de que la CA que emite el certificado pueda hacer lo siguiente:
Admitir la aprobacin automtica 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 extensin SubjectAltName en el nuevo
certificado.
Puede activar y desactivar la funcin de renovacin automtica de certificados

SCEP para todos los certificados SCEP o de forma individual.
Generacin de pares de claves

Los dispositivos de seguridad guardan en memoria las claves generadas
previamente. El nmero de claves generadas previamente depende del modelo de
dispositivo. Durante el funcionamiento normal, el dispositivo de seguridad es capaz
de disponer de claves suficientes para renovar certificados, puesto que cada vez que
utiliza una clave genera otra nueva. El proceso de generacin de claves
normalmente se ejecuta en segundo plano, ya que el dispositivo tiene tiempo para
generar una nueva clave antes de que se necesite utilizar otra. En caso de que el
dispositivo de seguridad renueve un gran nmero de certificados al mismo tiempo
y tenga que utilizar claves rpidamente, podra llegar a quedarse sin claves
generadas previamente y tener que generarlas inmediatamente con cada nueva
peticin. Si esto es as, la generacin de claves podra afectar al funcionamiento del
dispositivo de seguridad, especialmente en entornos de alta disponibilidad (HA),
donde el rendimiento del dispositivo de seguridad podra ralentizarse durante
algunos minutos.
El nmero de pares de claves generadas previamente en un dispositivo de
seguridad depende del modelo. Para ms informacin, consulte la hoja de
especificaciones de su producto de seguridad de Juniper Networks.
Protocolo de estado de certificado en lnea (OCSP)

Cuando un dispositivo de seguridad realiza una operacin en la que se utiliza un
certificado, suele ser importante verificar su validez. Los certificados pueden
quedar invalidados por vencimiento o por revocacin. La forma habitual de
comprobar el estado de los certificados es utilizar las listas de revocacin de
certificados (CRL). El protocolo de estado de certificado en lnea (OCSP) es otra
forma de comprobar el estado de los certificados. Este protocolo ofrece informacin
adicional sobre los certificados y realiza comprobaciones de estado peridicas.
Cuando un dispositivo de seguridad utiliza el protocolo OCSP, se le considera el
cliente OCSP (o solicitante). Dicho cliente enva una peticin de verificacin a un
servidor llamado servidor de respuesta OCSP. ScreenOS es compatible con RSA Keon
y Verisign como servidores de respuesta OCSP. La peticin del cliente incluye la
identidad del certificado que se debe comprobar. Antes de que el dispositivo de
seguridad pueda realizar operaciones OCSP, debe configurarlo para que reconozca
la ubicacin del servidor de respuesta OCSP.
Protocolo de estado de certificado en lnea (OCSP) 35
NOTA:
Tambin hemos evaluado satisfactoriamente con el servidor de respuesta OCSP

Valicert durante un examen exhaustivo realizado hace tiempo.
Una vez recibida la peticin, el servidor de respuesta OCSP confirma que la
informacin de estado del certificado est disponible y, a continuacin, devuelve el
estado actual al dispositivo de seguridad. La respuesta del servidor OCSP contiene
el estado de revocacin 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 de seguridad 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
configuracin de OCSP. Si el certificado est almacenado localmente, utilice el
siguiente comando para especificar el certificado almacenado localmente:
set pki authority nm_id1 cert-status ocsp cert-verify id nm_id2
nm_id1 identifica el certificado de CA que emiti el certificado que se va a

verificar; nm_id2 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 de seguridad verifica la firma utilizando el
certificado de la CA que emiti el certificado en cuestin.
Puede utilizar comandos CLI para configurar un dispositivo de seguridad para OCSP.
La mayora de estos comandos utilizan un nmero de identificacin para asociar la
URL de referencia de la revocacin con el certificado de CA. Puede obtener este
nmero ID con el siguiente comando CLI:
get pki x509 list ca-cert
NOTA:
El dispositivo de seguridad asigna de forma dinmica el nmero ID del certificado

de CA cuando se elabora la lista de certificados de CA. Este nmero puede
cambiar si se modifica el almacenamiento de certificados.
Especificacin de un mtodo de comprobacin de revocacin de certificados

Para especificar el mtodo de comprobacin de revocaciones (CRL, OCSP o
ninguno) para un certificado de una determinada CA, utilice la siguiente sintaxis en
CLI:
set pki authority nm_id cert-status revocation-check { CRL | OCSP | none }
donde nm_id ser el nmero de identificacin del certificado.

El siguiente ejemplo especifica la comprobacin de revocaciones con OCSP:
set pki authority 3 cert-status revocation-check ocsp
El nmero de ID 3 identifica el certificado de la CA
36
Protocolo de estado de certificado en lnea (OCSP)
Visualizacin de los atributos de comprobacin de estado

Para visualizar los atributos de comprobacin de estado de una CA determinada,
utilice la siguiente sintaxis en CLI:
get pki authority nm_id cert-status
donde nm_id ser el nmero de identificacin del certificado emitido por la

CA.
Para visualizar los atributos de comprobacin de estado para la CA que emiti el
certificado 7:
get pki authority 7 cert-status
Especificacin de una URL del servidor de respuesta del protocolo de estado de

certificado en lnea
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 nm_id cert-status ocsp url cadena_url
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
Eliminacin de atributos de comprobacin de estado

Para eliminar todos los atributos de comprobacin de estado de una CA emisora de
un determinado certificado, utilice la siguiente sintaxis:
unset pki authority nm_id cert-status
Para eliminar todos los atributos de revocacin relativos al certificado 1:

unset pki authority 1 cert-status
Protocolo de estado de certificado en lnea (OCSP) 37
Certificados autofirmados
Un certificado autofirmado es un certificado firmado y emitido por la misma
entidad; es decir, el emisor y el sujeto del certificado coinciden. Por ejemplo, los
certificados CA de todas las autoridades de certificacin raz (CA) son autofirmados.
Los dispositivos de seguridad generan automticamente un certificado autofirmado
al encenderse, si no hay ningn certificado ya configurado para Secure Sockets
Layer (SSL), como es el caso cuando se enciende por primera vez. El dispositivo de
seguridad 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 de seguridad se encuentra en un clster 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 clster. (Los miembros del NSRP
intercambian certificados autofirmados generados manualmente. Para obtener
informacin sobre la generacin manual de certificados autofirmados, consulte
Creacin manual de certificados autofirmados en la pgina 40).
Aunque no se pueden exportar certificados autofirmados y autogenerados, puede
copiar su nombre de sujeto y huella. A continuacin, puede entregarlo a un
administrador remoto que ms 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
precaucin importante contra los ataques por interposicin de intrusos
(man-in-the-middle attacks), en los que alguien intercepta un intento de conexin
SSL y finge ser el dispositivo de seguridad de destino, respondiendo con su propio
certificado autofirmado. (Para obtener ms informacin sobre la verificacin de
certificados autofirmados, consulte Validacin de certificados en la pgina 39).
Puede utilizar un certificado autofirmado al establecer una conexin Secure Sockets
Layer (SSL) con el dispositivo de seguridad. Si administra el dispositivo a travs de
WebUI, SSL puede proporcionar autenticacin y encriptacin para asegurar su
trfico administrativo. Puede incluso configurar un dispositivo de seguridad para
redirigir un intento de conexin administrativo utilizando HTTP (puerto
predeterminado 80) hacia SSL (puerto predeterminado 443).
NOTA:
Para obtener ms informacin sobre SSL, incluyendo el mecanismo de redireccin

HTTP a SSL, consulte Secure Sockets Layer en la pgina 3-5.
De forma predeterminada, el dispositivo de seguridad pone a disposicin el
certificado autofirmado y autogenerado para las negociaciones SSL. Es el certificado
SSL predeterminado. Si ms adelante instala un certificado firmado por una CA o
configura el dispositivo de seguridad para que genere otro certificado autofirmado,
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 de seguridad genera automticamente otro certificado autofirmado la
prxima vez que el dispositivo se reinicie.
38
NOTA:
Para averiguar cmo crear otro certificado autofirmado, consulte Creacin

manual de certificados autofirmados en la pgina 40. Para averiguar cmo
eliminar un certificado autofirmado y autogenerado, consulte Eliminar
certificados autofirmados en la pgina 46.
Validacin de certificados
Durante el establecimiento de conexin SSL, el dispositivo de seguridad se
autentica enviando un certificado al cliente SSL. Cuando el dispositivo de seguridad
enva un certificado autofirmado, el cliente SSL no puede validarlo comprobando la
firma de la CA emisora porque no la public ninguna CA. Cuando el dispositivo de
seguridad presenta un certificado autofirmado para establecer una sesin SSL, el
explorador del equipo del administrador intenta validarlo con un certificado CA en
su almacn de CA (autoridades de certificacin). Si no puede encontrar esa
autoridad, el explorador visualiza un mensaje como el que se muestra en la
Figura 16, pidiendo al administrador que acepte o rechace el certificado.
Figura 16: Alertas de seguridad para certificados autofirmados
Si esta es la primera vez que se conecta al dispositivo de seguridad despus de su

arranque inicial, el reloj del sistema puede no estar en hora. Por lo tanto, el perodo
de validez indicado en el certificado tambin puede ser inexacto. Aunque ponga en
hora el reloj del sistema y regenere un certificado autofirmado, el explorador 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
de seguridad utilice un certificado autofirmado para una conexin SSL.
Sin poder recurrir a la validacin del certificado por parte de una CA imparcial e
independiente, el administrador que inicie una sesin a travs de SSL podra
preguntarse si el certificado autofirmado recibido realmente procede del dispositivo
de seguridad al que est intentando conectarse. (Despus de todo, el certificado
podra ser un impostor que est utilizando un ataque por interposicin de intrusos
(man-in-the-middle attack) para intentar enmascararse como dispositivo de
seguridad). 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 de seguridad lo suministre ms
adelante para autenticarse.
39
Para consultar el nombre del sujeto y la huella digital de un certificado autofirmado

y autogenerado, utilice el comando siguiente:
device-> get pki x509 cert system
...
CN=0043022002000186,CN=system generated,CN=self-signed,
...
finger print (md5) <e801eae4 56699fbc 324e38f2 4cfa5d47>
finger print (sha) <0113f5ec 6bd6d32b 4ef6ead9 f809eead 3a71435b>
NOTA:
WebUI no permite visualizar los detalles de un certificado autofirmado y

autogenerado.
Despus de ver el nombre del sujeto y la huella digital, puede copiarlos y
entregarlos (con el mtodo seguro y fuera de banda que usted elija) al
administrador que posteriormente se conectar al dispositivo de seguridad a travs
de SSL. Cuando el cliente SSL del administrador reciba el certificado desde el
dispositivo de seguridad durante el establecimiento de conexin 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
autntico. 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.
Creacin manual de certificados autofirmados

El dispositivo de seguridad genera automticamente un certificado autofirmado la
primera vez que se enciende, con el fin de admitir SSL durante la conexin inicial.
Sin embargo, puede que desee generar un certificado autofirmado distinto del que
genera automticamente el dispositivo de seguridad. stas son algunas razones
posibles para reemplazar el certificado autofirmado y autogenerado por un
certificado autofirmado y definido por el administrador:
NOTA:
40
El certificado autofirmado y autogenerado utiliza un tamao de clave fijo de

1024 bits. Dependiendo de sus necesidades, puede necesitar claves con un
tamao 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 automticamente.
Puede necesitar varios certificados autofirmados. En los dispositivos de

seguridad que admiten sistemas virtuales, el sistema raz 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 continuacin, exigir a sus administradores que
comprueben el nombre del sujeto y la huella digital de estos certificados
especficos en lugar de los atributos de un certificado compartido.
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 de seguridad
de un clster NSRP sincroniza objetos PKI con otros miembros del clster.
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 tamao de la clave), los siguientes elementos de nombres
comunes (common name o CN) siempre aparecen al final del DN:
CN = nm_serie_disp, CN = NetScreen self-signed
Aunque el principal uso previsto de un certificado autofirmado es permitir que un
dispositivo de seguridad 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:
NOTA:
Establecer una conexin Secure Sockets Layer (SSL) para proteger el trfico
administrativo hacia un dispositivo de seguridad
Asegurar el trfico entre NetScreen-Security Manager (NSM) y un dispositivo de

seguridad
Autenticar interlocutores IKE al establecer tneles VPN
Para la versin actual de ScreenOS, solamente admitimos certificados

autofirmados para su uso con SSL.
Establecimiento de un 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
Despus de definirlo, generar el certificado y lo visualizar. A continuacin, podr

copiar el nombre del sujeto y la huella digital (tambin denominados thumbprint)
para su distribucin a otros administradores que inicien una sesin a travs de SSL
para administrar el dispositivo de seguridad.
Cuando un administrador intente iniciar una sesin con SSL, el dispositivo de
seguridad 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
informacin que recibi previamente. Si coinciden, sabr que el certificado es
autntico.
41
WebUI
1.
Definir los atributos del certificado
en Generate:
Certificate Subject Information:
Name: 4ssl
Organization: jnpr
FQDN: www.juniper.net
Key Pair Information:
RSA: (seleccione)
Create new key pair of 1024 length.
2.
Generar el certificado autofirmado
Cuando el dispositivo de seguridad ha completado la generacin de la clave,

compone una peticin 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
recin creado.
La pgina de detalles de certificados aparece, como se muestra en la Figura 17.
Figura 17: Detalles del certificado:
Puede copiar el nombre del sujeto y la huella digital desde esta pgina y
comunicarlos a otros administradores que pretendan utilizar SSL al administrar el
dispositivo de seguridad. Cuando inicien una conexin SSL, podrn utilizar esta
informacin para asegurarse de que el certificado que reciben procede, de hecho,
del dispositivo de seguridad.
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
42
2.
Generar el certificado autofirmado
Para generar un par de claves pblica/privada que el dispositivo de seguridad

de Juniper Networks utilizar en sus peticiones de certificados, ejecute el
comando siguiente:
exec pki rsa new-key 1024
Despus de que el dispositivo de seguridad genere un par de claves, compondr la

peticin de certificado siguiente:
-----BEGIN CERTIFICATE REQUEST----MIIB0jCCATsCAQAwZTENMAsGA1UEChMESk5QUjEZMBcGA1UEAxMQMDA0MzAyMj
Aw
MjAwMDE4NjEQMA4GA1UEAxMHcnNhLWtleTEYMBYGA1UEAxMPd3d3Lmp1bmlwZ
XIu
bmV0MQ0wCwYDVQQDEwQ1c3NsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQK
BgQDP
aAtelkL4HxQmO1w1jv9NMmrWnzdVYnGrKrXnw2MaB3xEgouWrlymEkZetA2ouKeA
D24SL0h1YvJ7Sd9PvkhwHOnvP1zkOCWA84TgvxBzcAyeBnS1UpSwcC0admX0Da6
T
80EUuGrmUWodddRFUc8o5d2VGTUOM7WgcFDZRSGQGwIDAQABoC0wKwYJKoZIh
vcN
AQkOMR4wHDAaBgNVHREEEzARgg93d3cuanVuaXBlci5uZXQwDQYJKoZIhvcNAQEF
BQADgYEAgvDXI4H905y/2+k4omo9Y4XQrgq44Rj3jqXAYYMgQBd0Q8HoyL5NE3+i
QUkiYjMTWO2wIWzEr4u/tdAISEVTu03achZa3zIkUtn8sD/VYKhFlyPCBVvMiaHd
FzIHUgBuMrr+awowJDG6wARhR75w7pORXy7+aAmvIjew8YRre9s=
-----END CERTIFICATE REQUEST-----
Para conocer el nmero de identificacin 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 nmero de identificacin del par de claves que vio en el resultado del
comando anterior:
exec pki x509 self-signed-cert key-pair 176095259
43
3.
Ver el certificado autofirmado
Para ver el certificado autofirmado recin 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 <29>
LOCAL CERT friendly name <29>
CN=self-signed,CN=4ssl,CN=www.juniper.net,CN=rsa-key,CN=004302200200
0186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
0186,
O=jnpr,
========================================================
Para ver el certificado ms detalladamente, ejecute el comando siguiente usando el

nmero de identificacin del certificado:
get pki x509 cert 176095261
-0001 176095261 LOCAL CERT friendly name <29>
000186,
O=jnpr,
Expire on 10-19-2009 17:20, Issued By:
0186,
O=jnpr,
Serial Number: <9d1c03365a5caa172ace4f82bb5ec9da>
subject alt name extension:
email(1): (empty)
fqdn(2): (www.juniper.net)
ipaddr(7): (empty)
no renew
finger print (md5) <be9e0280 02bdd9d1 175caf23 6345198e>
finger print (sha) <87e0eee0 c06f9bac 9098bd02 0e631c1b 26e37e0e>
subject name hash: <d82be8ae 4e71a576 2e3f06fc a98319a3 5c8c6c27>
use count: <1>
flag <00000000>
Puede copiar el nombre del sujeto subject name y la huella digital fingerprint
desde esta pgina y comunicarlos a otros administradores que pretendan utilizar
SSL para administrar el dispositivo de seguridad. Cuando inicien una conexin SSL,
podrn utilizar esta informacin para asegurarse de que el certificado que reciben
procede, de hecho, del dispositivo de seguridad.
44
Autogeneracin de certificados
La primera vez que se encienda el dispositivo de seguridad, generar
automticamente un certificado autofirmado. El principal propsito de este
certificado es reconocer inmediatamente SSL despus del arranque inicial de un
dispositivo de seguridad. Para ver este certificado, utilice el comando CLI siguiente:
get pki x509 cert system
Expire on 08- 3-2014 16:19, Issued By:
Serial Number: <c927f2044ee0cf8dc931cdb1fc363119>
finger print (md5) <fd591375 83798574 88b3e698 62890b5d>
finger print (sha) <40a1bda8 dcd628fe e9deaee1 92a2783c 817e26d9>
subject name hash: <0324d38d 52f814fe 647aba3a 86eda7d4 a7834581>
De forma predeterminada, el dispositivo de seguridad genera automticamente un

certificado autofirmado durante el proceso de arranque si se cumplen las
condiciones siguientes:
En el dispositivo no existe ningn certificado autofirmado generado

automticamente.
No se ha asignado ningn 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 automticamente (System).
45
La Figura 18 muestra la ruta de decisiones que el dispositivo de seguridad toma al

encenderse para la generacin de certificados.
Figura 18: Ruta de decisiones para la autogeneracin de certificados
Empieza
Proceso de
arranque
Existe un
cert generado
automticamente y
autofirmado?
Existe Cert
para
SSL?
No generar
automticamente
un certificado
autofirmado.
No
Generar automticamente un
certificado autofirmado.
Si elimina el certificado autofirmado y generado automticamente, asigne otro

certificado para su uso con SSL y restablezca el dispositivo; el dispositivo de
seguridad no generar otro certificado autofirmado durante el proceso de arranque.
Si a continuacin cambia la configuracin de SSL para que no se asigne ningn
certificado y luego restablece el dispositivo, el dispositivo de seguridad generar
automticamente un nuevo certificado autofirmado durante el siguiente proceso de
arranque.
Eliminar certificados autofirmados

Puede eliminar un certificado autofirmado generado de forma automtica o
manual, 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:
delete pki object-id system
Para eliminar un certificado autofirmado y configurado por el administrador, utilice

el comando siguiente, donde nm_id es el nmero de identificacin del certificado
que desea eliminar:
delete pki object-id nm_id
Si elimina el certificado autofirmado y autogenerado y ms adelante desea que el

dispositivo de seguridad genere otro, haga lo siguiente:
46
No asigne ningn otro certificado para SSL (puede utilizar el comando

siguiente: unset ssl cert).
Restablezca el dispositivo de seguridad.
El dispositivo de seguridad puede redirigir el trfico HTTP (puerto predeterminado

80) enviado al dispositivo mismo hacia SSL (puerto predeterminado 443). Por lo
tanto, para asegurarse de que un certificado est disponible para SSL, durante el
proceso de arranque el dispositivo de seguridad siempre comprueba si existe un
certificado autofirmado y autogenerado o si se ha asignado a SSL otro certificado. Si
no hay ningn certificado autofirmado y autogenerado y no se asigna ningn otro
certificado para su uso con SSL, el dispositivo de seguridad genera
automticamente un certificado autofirmado.
NOTA:
Slo CLI permite eliminar certificados autofirmados generados automticamente.

Para averiguar el nmero de identificacin de un certificado, utilice el comando
siguiente: get pki x509 list local-cert.
Para obtener informacin sobre la redireccin del trfico HTTP a SSL, consulte
Redireccionamiento de HTTP a SSL en la pgina 3-8.
47
48
Captulo 3
Directrices para las redes privadas

virtuales
ScreenOS ofrece una variedad de opciones criptogrficas para configurar un tnel
de red privada virtual (VPN). Incluso para configurar un tnel simple es necesario
elegir entre varias opciones. Los objetivos de la primera mitad de este captulo son
primero resumir todas las opciones disponibles para una VPN punto a punto bsica
y una VPN de acceso telefnico bsica, y despus ofrecer uno o ms motivos para
elegir una opcin u otra.
La segunda mitad del captulo examina las diferencias que existen entre los tneles
VPN basados en rutas y los tneles VPN basados en directivas. Tambin revisa el
flujo de paquetes de un tnel 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 captulo concluye con algunos consejos de configuracin
VPN que hay que tener en cuenta a la hora de configurar un tnel.
Este captulo consta de las siguientes secciones:
Opciones criptogrficas en la pgina 50
Opciones criptogrficas punto a punto en la pgina 50
Opciones VPN de acceso telefnico en la pgina 57
Tneles basados en directivas y en rutas en la pgina 64
Flujo de paquetes: VPN punto a punto en la pgina 66
Directrices para la configuracin de tneles en la pgina 72
Consideraciones sobre seguridad en redes privadas virtuales basadas en rutas

en la pgina 74
Ruta Null en la pgina 74
Lnea de acceso telefnico o arrendada en la pgina 76
Conmutacin por error de la VPN hacia la lnea arrendada o la ruta Null

en la pgina 77
Interfaz Tunnel ficticia en la pgina 79
49
Enrutador virtual para interfaces Tunnel en la pgina 80
Reenrutamiento a otro tnel en la pgina 80
Opciones criptogrficas
Durante la configuracin de una VPN es necesario tomar numerosas decisiones
sobre la criptografa que se desea utilizar. Surgirn preguntas sobre cul es el grupo
Diffie-Hellman adecuado, qu algoritmo de encriptacin ofrece el mejor equilibrio
entre seguridad y rendimiento, etc. En esta seccin se presentan todas las opciones
criptogrficas requeridas para configurar un tnel VPN punto a punto bsico y un
tnel VPN de acceso telefnico bsico. Tambin se indican una o ms ventajas de
cada opcin para ayudarle a tomar una decisin.
La primera decisin que hay que tomar es si se va a optar por un tnel VPN punto a
punto (entre dos dispositivos de seguridad) o por un tnel VPN de acceso telefnico
(desde el cliente VPN NetScreen-Remote hasta el dispositivo de seguridad). Aunque
esta decisin depende de la configuracin de red, las diferencias entre estos dos
tipos de tneles afectan a algunas opciones criptogrficas. Por lo tanto, las opciones
se presentan en dos figuras distintas:
Opciones criptogrficas punto a punto, descritas en la Figura 19, Opciones

criptogrficas para un tnel VPN punto a punto, en la pgina 51.
Opciones VPN de acceso telefnico, descritas en la Figura 20, Opciones

criptogrficas para un tnel VPN de acceso telefnico, en la pgina 58.
Cuando haya decidido qu tipo de tnel desea configurar (de acceso telefnico o
punto a punto), consulte la Figura 19 o la Figura 20 para obtener las indicaciones
oportunas. En cada figura se presentan las decisiones criptogrficas que deber
tomar durante la configuracin del tnel. A continuacin, se sealan los motivos
que justifican la eleccin de cada opcin de la figura.
NOTA:
En el Captulo 4, Redes privadas virtuales de punto a punto, y en el Captulo 5,

Redes privadas virtuales de acceso telefnico., se incluyen ejemplos de
configuracin de ambos tipos de tneles.
Opciones criptogrficas punto a punto

Durante la configuracin de un tnel VPN punto a punto bsico, deber seleccionar
entre las opciones criptogrficas que se muestran en la Figura 19. A continuacin
de la figura, se indican las ventajas de cada opcin.
NOTA:
50
La Figura 19 en la pgina 51 muestra las opciones que se recomiendan en negrita.

Para obtener informacin sobre las distintas opciones IPSec, consulte Seguridad
del protocolo de Internet en la pgina 1.
Captulo 3: Directrices para las redes privadas virtuales
Figura 19: Opciones criptogrficas para un tnel VPN punto a punto

1. Mtodo de administracin de claves: Clave manual o AutoKey IKE
AutoKey IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o bien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clave manual
2. Modo:
Dinmico o principal
13. Protocolo IPSec:
ESP. . . . . . . . o bien. . . . . . . . AH
6. Grupo Diffie-Hellman
Grupo: 1, 2 5
3. Tipo de autenticacin:
Certificados o clave previamente
compartida
4. Tipo de certificado:
RSA o DSA
14. Modo:
Tnel o transporte
7. Encriptacin IKE y
algoritmos de autenticacin:
AES, DES o 3DES
y
MD5 o SHA-1
5. Longitud de bits:
512 768
1024 2048
15. Opciones ESP:

Encriptacin, autenticacin y encriptacin o
16. Algoritmos de encriptacin:
AES, DES 3DES
9. ID IKE remota:
Direccin IP o U-FQDN
o FQDN o ASN1-DN
8. ID IKE local:
Direccin IP o U-FQDN
o FQDN o ASN1-DN
10. Contra reprocesamiento

de paquetes:
17. Algoritmos de
autenticacin:
MD5 o SHA-1
11. Confidencialidad directa perfecta:

S o No
12. Grupo Diffie-Hellman IPSec:
1, 2 o 5
Fase 1--puerta de enlace IKE
1.
Fase 2--tnel VPN
Mtodo de administracin de claves: Clave manual o AutoKey IKE
AutoKey IKE
Recomendado.
Ofrece una renovacin de claves automtica, con lo que aumenta la seguridad.
Clave manual
Resulta til para depurar problemas IKE.
Elimina los retardos de negociacin IKE a la hora de establecer un tnel.
2.
Modo: Dinmico o principal
Dinmico
Es necesario cuando la direccin IP de uno de los interlocutores IPSec est asignada

de forma dinmica y si se utiliza una clave previamente compartida
Principal
Recomendado.
Ofrece proteccin de identidad.
Se puede utilizar cuando el usuario de acceso telefnico posee una direccin IP

esttica o si se utilizan certificados para la autenticacin.
51
3.
Tipo de autenticacin: clave previamente compartida o certificados
Certificados
Recomendado
Ofrece mayor seguridad que las claves previamente compartidas porque es

posible validar los certificados a travs de una autoridad de certificacin (CA).
(Para obtener ms informacin, consulte Criptografa de claves pblicas en la
pgina 19).
Clave previamente compartida
Es ms fcil de manejar y ms rpida de configurar, porque no requiere una

infraestructura de claves pblicas (PKI).
4.
Tipo de certificado: RSA o DSA
Depende de la CA de la que se obtengan los certificados. Ningn tipo de certificado

presenta ventajas en comparacin con el otro.
5.
Longitud de bits: 512, 768, 1024 2048
512
Su gasto de procesamiento es el ms bajo.

768
Ofrece ms seguridad que la opcin de 512 bits.
Su gasto de procesamiento es inferior al de las opciones de 1024 y 2048 bits.
1024
Recomendado
Ofrece ms seguridad que las opciones de 512 y 768 bits.
Su gasto de procesamiento es inferior al de la opcin de 2048 bits.
2048
Ofrece la mxima seguridad.

6.
Grupo Diffie-Hellman IKE: 1, 2 5
Grupo de Diffie-Hellman 1
Su gasto de procesamiento es inferior al de los grupos Diffie-Hellman 2 y 5
Aceleracin de procesamiento proporcionada por el hardware de seguridad de

Juniper Networks
52
Recomendado
Su gasto de procesamiento es inferior al del grupo Diffie-Hellman 5
Ofrece ms seguridad que el grupo Diffie-Hellman 1

Juniper Networks
Ofrece la mxima seguridad

7.
Algoritmos de autenticacin y encriptacin IKE: AES, DES o 3DES y MD5 o SHA-1
AES
Recomendado
Tiene un mayor nivel de encriptacin que DES y 3DES si las longitudes de clave
son iguales

Juniper Networks
Algoritmo de encriptacin aprobado para las normas federales para

procesamiento de la informacin (FIPS, o Federal Information Processing
Standards) y los criterios comunes de EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES.
Resulta til cuando el interlocutor remoto no admite AES.
3DES
Ofrece ms seguridad criptogrfica que DES.

Juniper Networks
MD5
Su gasto de procesamiento es inferior al de SHA-1.

SHA-1
Recomendado
Ofrece ms seguridad criptogrfica que MD5.
Es el nico algoritmo de autenticacin que admiten las normas FIPS.
8.
ID IKE local: direccin IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN
Direccin IP
Recomendado.
Slo se puede utilizar si el dispositivo de seguridad local tiene una direccin IP

esttica.
Es la ID IKE predeterminada cuando se utiliza una clave previamente

compartida para la autenticacin.
Se puede utilizar con un certificado si la direccin IP aparece en el campo

SubjectAltName.
53
U-FQDN
Nombre de dominio completo de usuario (U-FQDN, una direccin de correo

electrnico): 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 dinmicas.
Es la ID IKE predeterminada cuando se utilizan certificados RSA o DSA para la

autenticacin.
ASN1-DN
Slo se puede utilizar con certificados.
Resulta til si la CA no admite el campo SubjectAltName en los certificados que

emite.
9.
ID IKE remota: direccin IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN
Direccin IP
Recomendado.
No requiere la introduccin de una ID IKE remota para un interlocutor con

direccin IP esttica cuando se utilizan claves previamente compartidas para la
autenticacin y el interlocutor es un dispositivo de seguridad.
Se puede utilizar para un dispositivo con direccin IP esttica.
Se puede utilizar con una clave previamente compartida o un certificado si la

direccin IP aparece en el campo SubjectAltName.
U-FQDN

certificado si el U-FQDN aparece en el campo SubjectAltName.
FQDN
54

SubjectAltName.
No requiere la introduccin de una ID IKE remota cuando se utilizan

certificados para la autenticacin y el interlocutor es un dispositivo de
seguridad.
ASN1-DN

emite.
10. Comprobacin contra reprocesamiento de paquetes: S o no

S
Recomendado
Permite al destinatario comprobar los nmeros de secuencia de los

encabezados de paquetes para prevenir ataques de denegacin de servicio
(DoS) provocados cuando un atacante reenva paquetes IPSec interceptados.
No
Desactivar esta opcin tal vez sea la solucin a problemas de compatibilidad con
interlocutores de terceros.
11. Confidencialidad directa perfecta: S o no
S
Recomendado
Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los
interlocutores realizan un segundo intercambio Diffie-Hellman para generar la
clave utilizada para la encriptacin/desencriptacin IPSec.
No
Agiliza la configuracin del tnel.
Reduce el procesamiento durante las negociaciones IPSec de fase 2.
12. Grupo Diffie-Hellman IPSec: 1, 2 5

Su gasto de procesamiento es inferior al de los grupos Diffie-Hellman 2 y 5.

Juniper Networks.
Recomendado

Juniper Networks
Ofrece la mxima seguridad.
55
13. Protocolo IPSec: ESP o AH

ESP
Recomendado
Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad

mediante encriptacin y encapsulado del paquete IP original e integridad
mediante autenticacin
Puede proporcionar slo encriptacin o slo autenticacin
AH
Encabezado de autenticacin (AH): ofrece autenticacin del paquete IP completo,

incluyendo el encabezado IPSec y el encabezado IP externo
14. Modo: tnel o transporte
Tnel
Recomendado
Oculta el encabezado IP original, con lo que aumenta la privacidad
Transporte
Es necesario para el soporte del tnel L2TP sobre IPSec

15. Opciones ESP: slo encriptacin, slo autenticacin o encriptacin y autenticacin
Encriptacin
Ofrece un rendimiento ms rpido y su gasto de procesamiento es inferior al de

la opcin de encriptacin y autenticacin
Resulta til cuando se requiere confidencialidad, pero no autenticacin
Encriptacin y autenticacin
Recomendado
Resulta til si se desea obtener confidencialidad y autenticacin
Autenticacin
Resulta til cuando se requiere autenticacin, pero no confidencialidad. Por

ejemplo, cuando la informacin 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 transmisin.
16. Algoritmos de encriptacin: AES, DES o 3DES
AES
56
Recomendado
son iguales

Juniper Networks
Algoritmo de encriptacin aprobado para normas FIPS y criterios comunes

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES
Resulta til cuando el interlocutor remoto no admite AES
3DES
Ofrece ms seguridad criptogrfica que DES

Juniper Networks
17. Algoritmos de autenticacin: MD5 o SHA-1

MD5
Su gasto de procesamiento es inferior al de SHA-1

SHA-1
Recomendado
Ofrece ms seguridad criptogrfica que MD5
Si se utilizan las opciones recomendadas de la lista anterior, una configuracin VPN

punto a punto genrica entre dos dispositivos de seguridad con direcciones IP
estticas estara 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)
Modo de tnel
Encriptacin = AES
Autenticacin = SHA-1
Encriptacin = AES
ID IKE = direccin IP (valor
predeterminado)
Proteccin contra reprocesamiento de
paquetes = s
Opciones VPN de acceso telefnico

Durante la configuracin de un tnel VPN de acceso telefnico bsico, deber
seleccionar entre las opciones criptogrficas que se muestran en la Figura 20.
A continuacin de la figura, se indican las ventajas de cada opcin.
NOTA:
La Figura 20 muestra las opciones que se recomiendan en negrita. Para obtener

informacin sobre las distintas opciones IPSec, consulte el Seguridad del
protocolo de Internet en la pgina 1.
57
Figura 20: Opciones criptogrficas para un tnel VPN de acceso telefnico

Mtodo de administracin de claves = AutoKey IKE
1. Modo:
Dinmico o principal
2. Tipo de autenticacin:
Certificados o clave previamente
compartida
12. Protocolo IPSec:

ESP. . . . . . . . o bien. . . . . . . . AH
5. IKE Diffie-Hellman
Grupo: 1, 2 5
3. Tipo de certificado:
RSA o DSA
13. Modo:
Tnel o transporte
6. Encriptacin IKE y
algoritmos de autenticacin:
AES, DES o 3DES
y
MD5 o SHA-1
4. Longitud de bits:
512 768
1024 2048
14. Opciones ESP:

Encriptacin, encriptacin y
autorizacin o autorizacin
15. Algoritmos de encriptacin: 16. Algoritmos de autenticacin:
MD5 o SHA-1
AES, DES 3DES
8. ID IKE remota:
7. ID IKE local:
Direccin IP (valor predeterminado) o Direccin IP (valor predeterminado) o 9. Comprobacin contra
reprocesamiento: S o No
U-FQDN, FQDN o ASN1-DN
U-FQDN, FQDN o ASN1-DN
10. Confidencialidad directa perfecta:

S o No
11. Grupo Diffie-Hellman IPSec:
1, 2 o 5
Fase 1--puerta de enlace IKE
1.
Fase 2--tnel VPN
Modo: Dinmico o principal
Dinmico
Recomendado
Es necesario cuando la direccin IP de uno de los interlocutores IPSec est

asignada de forma dinmica y si se utiliza una clave previamente compartida
Se puede utilizar con certificados o claves previamente compartidas para la

autenticacin
Principal
Ofrece proteccin de identidad

2.
Tipo de autenticacin: clave previamente compartida o certificados
Certificados
Recomendado
Ofrece mayor seguridad que las claves previamente compartidas porque es

posible validar los certificados a travs de una autoridad de certificacin (CA).
(Para obtener ms informacin, consulte Criptografa de claves pblicas en la
pgina 19)
Es ms fcil de manejar y ms rpida de configurar, porque no requiere una

infraestructura de claves pblicas (PKI)
58
3.
Tipo de certificado: RSA o DSA
Depende de la CA de la que se obtengan los certificados. Ningn tipo de certificado

presenta ventajas en comparacin con el otro.
4.
Longitud de bits: 512, 768, 1024 2048
512
Su gasto de procesamiento es el ms bajo.

768
Ofrece ms seguridad que la opcin de 512 bits.
Su gasto de procesamiento es inferior al de las opciones de 1024 y 2048 bits.
1024
Recomendado
Ofrece ms seguridad que las opciones de 512 y 768 bits
Su gasto de procesamiento es inferior al de la opcin de 2048 bits
2048

5.
Grupo Diffie-Hellman IKE: 1, 2 5

Juniper Networks
Recomendado

Juniper Networks

6.
Algoritmos de autenticacin y encriptacin IKE: AES, DES o 3DES y MD5 o SHA-1?
AES
Recomendado
son iguales

Juniper Networks
59

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES
Resulta til cuando el interlocutor remoto no admite AES
3DES

Juniper Networks
MD5

SHA-1
Recomendado
7.
ID IKE local: direccin IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN
Direccin IP (valor predeterminado)
No requiere la introduccin de una ID IKE para un dispositivo con direccin IP

esttica.

U-FQDN
Recomendado

certificado si el U-FQDN aparece en el campo SubjectAltName
FQDN

SubjectAltName.
ASN1-DN
60

emite.
8.
ID IKE remota: direccin IP (valor predeterminado), o bien U-FQDN, FQDN o ASN1-DN
Direccin IP (valor predeterminado)
No requiere la introduccin de una ID IKE para un dispositivo con direccin IP

esttica.

U-FQDN
Recomendado

certificado si el U-FQDN aparece en el campo SubjectAltName
FQDN

SubjectAltName.
ASN1-DN

emite.
9.
Comprobacin contra reprocesamiento de paquetes: S o no?
Recomendado
Permite al destinatario comprobar los nmeros de secuencia de los

encabezados de paquetes para prevenir ataques de denegacin de servicio
(DoS) provocados cuando un atacante reenva paquetes IPSec interceptados
No
Desactivar esta opcin tal vez sea la solucin a problemas de compatibilidad con
interlocutores de terceros
10. Confidencialidad directa perfecta: S o no?
S
Recomendado
Confidencialidad directa perfecta (PFS): ofrece una mayor seguridad porque los
interlocutores realizan un segundo intercambio Diffie-Hellman para generar la
clave utilizada para la encriptacin/desencriptacin IPSec
61
No
Agiliza la configuracin del tnel.
Reduce el procesamiento durante las negociaciones IPSec de fase 2.
11. Grupo Diffie-Hellman IPSec: 1, 2 5


Juniper Networks
Recomendado.
Su gasto de procesamiento es inferior al del grupo Diffie-Hellman 5.
Ofrece ms seguridad que el grupo Diffie-Hellman 1.

Juniper Networks.

12. Protocolo IPSec: ESP o AH
ESP
Recomendado
Carga de seguridad encapsulada (ESP): puede ofrecer confidencialidad

mediante encriptacin y encapsulado del paquete IP original e integridad
mediante autenticacin
Puede proporcionar slo encriptacin o slo autenticacin
AH
Encabezado de autenticacin (AH): ofrece autenticacin del paquete IP completo,

incluyendo el encabezado IPSec y el encabezado IP externo
13. Modo: tnel o transporte
Tnel
Recomendado
Oculta el encabezado IP original, con lo que aumenta la privacidad
Transporte
Es necesario para el soporte del tnel L2TP sobre IPSec
62
14. Opciones ESP: slo encriptacin, slo autenticacin o encriptacin y autenticacin

Encriptacin
Ofrece un rendimiento ms rpido y su gasto de procesamiento es inferior al de

la opcin de encriptacin y autenticacin.
Resulta til cuando se requiere confidencialidad, pero no autenticacin.
Recomendado
Resulta til si se desea obtener confidencialidad y autenticacin
Autenticacin
Resulta til cuando se requiere autenticacin, pero no confidencialidad. Por

ejemplo, cuando la informacin 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 transmisin.
15. Algoritmos de encriptacin: AES, DES o 3DES
AES
Recomendado
son iguales

Juniper Networks

EAL4
DES
Su gasto de procesamiento es inferior al de 3DES y AES.
Resulta til cuando el interlocutor remoto no admite AES.
3DES

Juniper Networks
16. Algoritmos de autenticacin: MD5 o SHA-1

MD5

SHA-1
Recomendado
63
Si se utilizan las opciones recomendadas de la lista anterior, una configuracin VPN

de acceso telefnico genrica entre dos dispositivos de seguridad con direcciones IP
estticas estara formada por los siguientes componentes:
Modo dinmico
Confidencialidad directa perfecta (PFS) = s
Certificados de 1024 bits (RSA o DSA)
Carga de seguridad encapsulada (ESP)
Encriptacin = AES
Modo de tnel
ID IKE = U-FQDN (direccin de correo
Encriptacin = AES
electrnico)
Proteccin contra reprocesamiento de
paquetes = s
Tneles basados en directivas y en rutas

La configuracin de un dispositivo de seguridad para el soporte VPN es
particularmente flexible. Es posible crear tneles VPN basados en directivas y
basados en rutas. Adems, en cada tipo de tnel se puede utilizar clave manual o
AutoKey IKE para administrar las claves utilizadas para la encriptacin y la
autenticacin.
En el caso de los tneles VPN basados en directivas, un tnel se gestiona como un
objeto (o un bloque de construccin) que, junto con el origen, el destino, el servicio
y la accin, comprende una directiva que permite el trfico VPN. (En realidad, la
accin de directiva VPN es tunnel, pero la accin permit est implcita si no se
especifica). En una configuracin VPN basada en directivas, una directiva hace
referencia de forma especfica a un tnel VPN por su nombre.
En las VPN basadas en rutas, la directiva no hace referencia de forma especfica al
tnel VPN. En su lugar, la directiva hace referencia a una direccin de destino.
Cuando el dispositivo de seguridad realice una consulta de ruta para averiguar la
interfaz a travs de la que debe enviar el trfico para alcanzar esa direccin,
encontrar una ruta a travs de una interfaz Tunnel, que estar asociada a un tnel
VPN especfico.
NOTA:
Normalmente, una interfaz Tunnel est asociada a un solo tnel. No obstante,

tambin es posible asociar una interfaz Tunnel a varios tneles. Para obtener ms
informacin, consulte Mltiples tneles por interfaz de tnel en la pgina 263.
Por lo tanto, con un tnel VPN basado en directivas, un tnel se puede considerar
como un elemento en la construccin de una directiva. Con un tnel VPN basado
en rutas, un tnel se puede considerar como un medio para entregar trfico, y la
directiva se puede considerar como un mtodo para permitir o denegar la entrega
de dicho trfico.
64
El nmero de tneles VPN basados en directivas que se puede crear est limitado
por el nmero de directivas que admita el dispositivo. El nmero de tneles VPN
basados en rutas que se puede crear est limitado por el nmero de entradas de
ruta o por el nmero de interfaces Tunnel que admita el dispositivo (el que sea ms
pequeo).
La configuracin de un tnel VPN basado en rutas es una eleccin acertada si desea
conservar los recursos de tnel y ajustar restricciones granulares para el trfico
VPN. Aunque puede crear numerosas directivas que hagan referencia al mismo
tnel VPN, cada directiva crea una asociacin de seguridad (SA) IPSec individual
con el interlocutor remoto; cada una de estas asociaciones cuenta como un tnel
VPN independiente. Con un planteamiento basado en rutas para las VPN, la
regulacin del trfico no est ligada a los medios de entrega. Es posible configurar
docenas de directivas para regular el trfico que circula a travs de un nico tnel
VPN entre dos puntos, si slo hay una SA IPSec operativa. Adems, la configuracin
de una VPN basada en rutas permite crear directivas que hagan referencia a un
destino alcanzado a travs de un tnel VPN donde la accin sea deny, en contraste
con la configuracin de una VPN basada en directivas, donde, como hemos
indicado antes, la accin debe ser tunnel con la accin implcita permit.
Otra ventaja de las VPN basadas en rutas es el intercambio de informacin de
enrutamiento dinmico a travs de tneles VPN. Es posible habilitar una instancia
de un protocolo de enrutamiento dinmico, como BGP (Border Gateway Protocol),
en una interfaz Tunnel asociada a un tnel VPN. La instancia de enrutamiento local
intercambia informacin de enrutamiento a travs del tnel con un vecino
habilitado en una interfaz Tunnel asociada al otro extremo.
Si un tnel no conecta grandes redes en las que se ejecuten protocolos de
enrutamiento dinmico y no es necesario conservar tneles o definir diversas
directivas para filtrar el trfico a travs del tnel, tiene sentido configurar un tnel
basado en directivas. Adems, como no existe ninguna red ms all de un cliente
VPN de acceso telefnico, los tneles VPN basados en directivas pueden ser una
buena eleccin para configuraciones VPN de acceso telefnico.
Dicho esto, si el cliente de acceso telefnico admite una direccin IP interna virtual
(como NetScreen-Remote), existen argumentos convincentes para utilizar una
configuracin VPN basada en rutas. Un tnel VPN de acceso telefnico basado en
rutas presenta las siguientes ventajas:
Se puede asociar su interfaz tnel a cualquier zona para requerir o no la

aplicacin de directivas.
Se pueden definir rutas para forzar el trfico a travs del tnel, al contrario de lo
que ocurre con una configuracin VPN basada en directivas.
Un tnel VPN basado en rutas simplifica la adicin de un radio a una

configuracin radial (consulte Creacin de VPN radiales en la pgina 321).
Puede ajustar la ID de proxy para que acepte cualquier direccin IP del cliente
VPN de acceso telefnico configurando la direccin del cliente remoto como
255.255.255.255/32.
Puede definir una o ms direcciones IP asignadas (MIP) en la interfaz del tnel.
65
NOTA:
Para obtener un ejemplo de una configuracin VPN basada en rutas para un

cliente de acceso telefnico, consulte VPN de acceso telefnico basada en rutas,
interlocutor dinmico en la pgina 170.
Flujo de paquetes: VPN punto a punto

Para comprender mejor cmo interactan los diversos componentes que
intervienen en la creacin de un tnel IPSec, en esta seccin se describe el proceso
de un flujo de paquetes a travs de un tnel (tanto cuando un dispositivo de
seguridad enva trfico VPN saliente como cuando recibe trfico VPN entrante). Se
explica el proceso de una VPN basada en rutas y a continuacin 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 Pars y necesita
conectar los dos puntos mediante un tnel IPSec. El tnel tiene las siguientes
caractersticas: AutoKey IKE, protocolo ESP, AES para encriptacin, SHA-1 para
autenticacin con clave previamente compartida y comprobacin contra
reprocesamiento de paquetes habilitada. Los dispositivos de seguridad que
protegen cada punto se encuentran en modo NAT y todas las zonas se ubican en el
dominio de enrutamiento trust-vr. Las direcciones se muestran en la Figura 21 en la
pgina 66.
Figura 21: Tnel VPN punto a punto
Zona Trust
Oficina
de Tokio
Zona Untrust
tunnel.1, 10.1.2.1/24
Interfaz de salida: ethernet3, 1.1.1.1/24
ethernet1
10.1.1.1/24
Enrutador externo: 1.1.1.250
10.1.1.5
Internet
Tokio
LAN
Pars
LAN
VPN1
10.2.2.5
Enrutador externo: 2.2.2.250
ethernet1
10.2.2.1/24
Interfaz de salida: ethernet3, 2.2.2.2/24

tunnel.2, 10.2.1.1/24
Zona Untrust
Oficina
de Pars
Zona Trust
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 Pars a travs de un tnel IPSec se desarrolla tal como se
describe en las subsecciones siguientes.
Tokio (iniciador)
1. El host en 10.1.1.5 enva un paquete para 10.2.2.5 a 10.1.1.1, que es la

direccin IP ethernet1 y es la puerta de enlace predeterminada configurada en
los ajustes TCP/IP del host.
66
2. El paquete llega a ethernet1, que est asociado a la zona Trust.

3. Si hay habilitadas opciones SCREEN como la deteccin de suplantacin de IP
para la zona Trust, el dispositivo de seguridad activa el mdulo SCREEN en este
momento. La comprobacin de SCREEN puede producir uno de los tres
resultados siguientes:
Si un mecanismo SCREEN detecta un comportamiento anmalo y est

configurado para bloquear el paquete correspondiente, el dispositivo de
seguridad descarta el paquete y genera una entrada en el registro de
eventos.

configurado para registrar el evento pero no bloquear el paquete, el
dispositivo de seguridad registra el evento en la lista de contadores SCREEN
para ethernet1 y contina con el paso siguiente.
Si el mecanismo SCREEN no detecta ningn comportamiento anmalo, el

dispositivo de seguridad procede al paso siguiente.
Si no ha habilitado ninguna opcin de SCREEN para la zona Trust, el dispositivo

de seguridad procede inmediatamente al paso siguiente.
4. El mdulo de sesiones realiza una consulta de sesiones para comprobar si el
paquete coincide con una sesin existente.
Si el paquete no coincide con una sesin existente, el dispositivo de seguridad
ejecuta los pasos restantes con procesamiento del primer paquete.
Si el paquete coincide con una sesin existente, el dispositivo de seguridad
ejecuta el procesamiento rpido, utilizando la informacin disponible en la
entrada de sesiones existente para procesar el paquete. El procesamiento
rpido omite las consultas de rutas y directivas porque la informacin generada
por los pasos omitidos ya se obtuvo durante el procesamiento del primer
paquete de la sesin.
5. El mdulo de asignacin de direcciones comprueba si una direccin IP
asignada (MIP) utiliza la direccin IP de destino 10.2.2.5. Como 10.2.2.5 no se
utiliza en una configuracin MIP, el dispositivo de seguridad contina con el
paso siguiente. (Para obtener informacin sobre el procesamiento de paquetes
cuando existe traduccin de direcciones de destino [NAT-dst], MIP o VIP,
consulte Flujo de paquetes para NAT-Dst en la pgina 8 -29).
6. Para determinar la zona de destino, el mdulo de rutas realiza una consulta de
rutas para 10.2.2.5. (El mdulo 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 trfico a 10.2.2.5 a travs de la
interfaz tunnel.1 asociada a un tnel VPN llamado vpn1. La interfaz Tunnel se
encuentra en la zona Untrust. Determinando las interfaces de entrada y salida,
el dispositivo de seguridad determina las zonas de origen y de destino y puede
realizar una consulta de directivas.
67
7. El motor de directivas realiza una consulta de directivas entre las zonas Trust y
Untrust (segn lo determinado por las correspondientes interfaces de entrada y
de salida). La accin especificada en la directiva que coincide con la direccin
de origen y la zona, la direccin de destino y la zona, y el servicio es permitir.
8. El mdulo IPSec comprueba si existe una asociacin de seguridad (SA) de fase
2 activa con el interlocutor remoto. Mediante la comprobacin de SA de fase 2
se pueden obtener los siguientes resultados:
Si el mdulo IPSec descubre una SA de fase 2 activa con el interlocutor,

contina con el paso 10.
Si el mdulo IPSec no descubre una SA de fase 2 activa con el interlocutor,

descarta el paquete y activa el mdulo IKE.
9. El mdulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor

remoto. Mediante la comprobacin de SA de fase 1 se pueden obtener los
siguientes resultados:
Si el mdulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza

esta SA para negociar una SA de fase 2.
Si el mdulo 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 mdulo IPSec coloca un encabezado ESP y un encabezado IP externo en el

paquete. Utilizando la direccin especificada como interfaz de salida, indica
1.1.1.1 como direccin IP de origen en el encabezado externo. Utilizando la
direccin especificada para la puerta de enlace remota, indica 2.2.2.2 como la
direccin IP de destino en el encabezado externo. A continuacin, encripta el
paquete desde la carga hasta el campo del siguiente encabezado en el
encabezado IP original. Luego, autentica el paquete desde el finalizador ESP
hasta el encabezado ESP.
11. El dispositivo de seguridad enva el paquete encriptado y autenticado dirigido a
2.2.2.2 a travs de la interfaz de salida (ethernet3) al enrutador externo en
1.1.1.250.
Pars (destinatario)
1. El paquete llega a 2.2.2.2, que es la direccin IP de ethernet3, una interfaz

asociada a la zona Untrust.
2. Mediante el SPI, la direccin IP de destino y el protocolo IPSec incluidos en el
encabezado de paquete externo, el mdulo 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 comprobacin de SA de fase 2 se puede
obtener uno de los tres siguientes resultados:
68
Si el mdulo IPSec descubre una SA de fase 2 activa con el interlocutor,

contina con el paso 4.
Si el mdulo IPSec no descubre una SA de fase 2 activa con el interlocutor

pero puede comparar una SA de fase 2 inactiva utilizando la direccin IP de
origen pero no el SPI, descarta el paquete, realiza una entrada en el registro
de eventos y enva una notificacin al interlocutor iniciador para avisar de
que ha recibido un SPI incorrecto.
Si el mdulo IPSec no descubre una SA de fase 2 activa con el interlocutor,

descarta el paquete y activa el mdulo IKE.
3. El mdulo IKE comprueba si existe una SA de fase 1 activa con el interlocutor

remoto. Mediante la comprobacin de SA de fase 1 se pueden obtener los
siguientes resultados:
Si el mdulo IKE descubre una SA de fase 1 activa con el interlocutor, utiliza

esta SA para negociar una SA de fase 2.
Si el mdulo 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 mdulo IPSec realiza una comprobacin contra reprocesamiento de

paquetes. Mediante esta comprobacin se puede obtener uno de los dos
resultados siguientes:
Si el paquete no pasa la comprobacin contra reprocesamiento de

paquetes (porque se detecte un nmero de secuencia que el dispositivo de
seguridad ya haya recibido), el dispositivo de seguridad descarta el
paquete.
Si el paquete pasa la comprobacin contra reprocesamiento de paquetes, el

dispositivo de seguridad contina con el siguiente paso.
5. El mdulo IPSec intenta autenticar el paquete. Mediante la comprobacin de

autenticacin se puede obtener uno de los dos resultados siguientes:
Si el paquete no pasa la comprobacin de autenticacin, el dispositivo de

seguridad descarta el paquete.
Si el paquete pasa la comprobacin de autenticacin, el dispositivo de

seguridad contina con el siguiente paso.
6. Mediante la SA de fase 2 y las claves, el mdulo IPSec desencripta el paquete,

descubriendo la direccin de origen original (10.1.1.5) y el destino final
(10.2.2.5). Averigua que el paquete ha llegado a travs de vpn1, que est
asociada a tunnel.1. A partir de este momento, el dispositivo de seguridad
gestiona el paquete teniendo en cuenta que su interfaz de entrada es tunnel.1
en lugar de ethernet3. Tambin ajusta la ventana deslizante contra
reprocesamiento de paquetes.
69
7. Si hay habilitadas opciones de SCREEN para la zona Untrust, el dispositivo de

seguridad activa el mdulo SCREEN en este momento. La comprobacin de
SCREEN puede producir uno de los tres resultados siguientes:

configurado para bloquear el paquete correspondiente, el dispositivo de
seguridad descarta el paquete y genera una entrada en el registro de
eventos.

configurado para registrar el evento pero no bloquear el paquete, el
dispositivo de seguridad registra el evento en la lista de contadores SCREEN
para ethernet3 y contina con el paso siguiente.
Si el mecanismo SCREEN no detecta ningn comportamiento anmalo, el

dispositivo de seguridad procede al paso siguiente.
8. El mdulo de sesiones realiza una consulta de sesiones para comprobar si el

paquete coincide con una sesin existente. A continuacin, aplica el
procesamiento del primer paquete o el procesamiento rpido.
Si el paquete coincide con una sesin existente, el dispositivo de seguridad
ejecuta el procesamiento rpido, utilizando la informacin disponible en la
entrada de sesiones existente para procesar el paquete. El procesamiento
rpido omite todos los pasos salvo los dos ltimos (encriptar el paquete y
reenviarlo) porque la informacin generada por los pasos omitidos ya se obtuvo
durante el procesamiento del primer paquete de la sesin.
9. El mdulo de asignacin de direcciones comprueba si una direccin IP
asignada (MIP) o virtual (VIP) utiliza la direccin IP de destino 10.2.2.5. Como
10.2.2.5 no se utiliza en ninguna configuracin MIP o VIP, el dispositivo de
seguridad contina con el paso siguiente.
10. El mdulo 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 continuacin, realiza una consulta de rutas para 10.2.2.5 en trust-vr y
descubre que el acceso se ha llevado a cabo a travs de ethernet1.
Determinando la interfaz de entrada (tunnel.1) y la de salida (ethernet1), el
dispositivo de seguridad 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 de seguridad 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 de seguridad reenva el paquete a travs de ethernet1 a su
destino en 10.2.2.5.
Anexo: VPN basadas en directivas
El flujo de paquetes para una configuracin VPN basada en directivas difiere en dos
puntos del de la configuracin VPN basada en rutas: la consulta de rutas y la
consulta de directivas.
70
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 mdulo de rutas

realiza una consulta de rutas para 10.2.2.5. Si no encuentra ninguna entrada
para esa direccin especfica, el mdulo de rutas, resuelve una ruta a travs de
ethernet3, que est asociada a la zona Untrust. Determinando las interfaces de
entrada y salida, el dispositivo de seguridad 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 direccin de origen y la
zona, la direccin de destino y la zona, y el servicio, y encuentra una directiva
que hace referencia a un tnel VPN llamado vpn1.
El dispositivo de seguridad reenva el paquete a travs de ethernet1 a su destino en

10.2.2.5.
Pars (destinatario)
La mayora de las etapas del flujo de paquetes entrante en el extremo del

destinatario son idnticas tanto para las configuraciones VPN basadas en directivas
como para las basadas en rutas, excepto que el tnel no est asociado a una interfaz
Tunnel, sino a una zona de tnel. El dispositivo de seguridad averigua que el
paquete ha llegado a travs de vpn1, que est asociada a la zona de tnel
Untrust-Tun, cuya zona portadora es la zona Untrust. Al contrario de lo que ocurre
en las VPN basadas en rutas, el dispositivo de seguridad considera que ethernet3 es
la interfaz de entrada del paquete desencriptado (y no tunnel.1).
El flujo cambia cuando concluye la desencriptacin del paquete. En este punto, las
consultas de rutas y directivas difieren:
Consulta de rutas: el mdulo de rutas realiza una consulta de rutas para

10.2.2.5 y descubre que el acceso se ha producido a travs 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 tnel 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 de
seguridad 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 tnel VPN llamado vpn1 y que permite el acceso a 10.2.2.5.
Entonces, el dispositivo de seguridad reenva el paquete a su destino.
71
Directrices para la configuracin de tneles

Esta seccin presenta algunas directrices para la configuracin de los tneles VPN.
Al configurar un tnel VPN IPSec, es posible que desee considerar lo siguiente:
ScreenOS admite un mximo de cuatro propuestas para las negociaciones de

fase 1 y un mximo 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 informacin sobre las negociaciones IKE de fase 1 y fase 2, consulte
Negociacin de tnel en la pgina 9.
Si desea utilizar certificados para la autenticacin y hay ms de un certificado

local cargado en el dispositivo de seguridad, deber especificar qu certificado
desea que utilice cada configuracin de tnel VPN. Para obtener ms
informacin sobre los certificados, consulte Criptografa de claves pblicas en
la pgina 19.
Para una VPN bsica basada en directivas:
NOTA:
Utilice direcciones definidas por el usuario en la directiva, no la direccin

predefinida Any.
Las direcciones y el servicio especificados en las directivas configuradas en

los dos extremos de la VPN deben coincidir.
Utilice directivas simtricas para el trfico 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 idntico y la
direccin IP local indicada para un interlocutor debe ser igual que la direccin
IP remota indicada para el otro interlocutor.
La ID de proxy es una tupla de tres partes compuesta por direccin IP

local-direccin IP remota-servicio.
Para una configuracin VPN basada en rutas, la ID de proxy es configurable

por el usuario.
Para una configuracin VPN basada en directivas, el dispositivo de

seguridad (de forma predeterminada) deriva la ID de proxy a partir de la
direccin de origen, la direccin de destino y el servicio especificados en la
directiva que hace referencia al tnel VPN en la lista de directivas. Tambin
es posible definir una ID de proxy para una VPN basada en directivas que
reemplace la ID de proxy derivada.
El mtodo ms simple para garantizar que las ID de proxy coinciden es utilizar

0.0.0.0/0 para la direccin local, 0.0.0.0/0 para la direccin 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 trfico 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 Redes privadas virtuales de
punto a punto en la pgina 81.
72
NOTA:
Si la direccin remota es la direccin interna virtual de un cliente VPN de acceso

telefnico, utilice 255.255.255.255/32 para la direccin IP remota/mscara 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 configuracin VPN basada
en directivas, y el interlocutor utiliza una configuracin VPN basada en rutas, el
interlocutor 2 deber definir una ID de proxy que coincida con la ID de proxy
derivada de la directiva del interlocutor 1. Si el interlocutor 1 realiza la
traduccin de direcciones de red de origen (NAT-src) mediante un conjunto de
DIP, utilice la direccin y la mscara de red para el conjunto de DIP como
direccin 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 ms informacin sobre las ID de proxy cuando se utilizan con NAT-src
y NAT-dst, consulte Sitios VPN con direcciones superpuestas en la pgina 142.
NOTA:
El interlocutor 1 tambin 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 de seguridad deriva de los
componentes de la directiva.
Como las ID de proxy admiten un nico servicio o 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 estticas, pueden utilizar la

ID IKE predeterminada, es decir, su direccin IP. Cuando un usuario de acceso
telefnico o interlocutor tiene una direccin IP asignada de forma dinmica,
dicho usuario o interlocutor debe utilizar otro tipo de ID IKE. Un nombre
completo (FQDN) es una buena eleccin para un interlocutor dinmico, y un
U-FQDN (direccin de correo electrnico) es una buena eleccin para un
usuario de acceso telefnico. 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 dinmico o el usuario de acceso telefnico tambin
podr utilizar todo o parte del ASN1-DN como ID IKE.
73

Aunque los cambios de rutas no afectan a las VPN basadas en directivas, las VPN
basadas en rutas son otra cuestin. El dispositivo de seguridad puede enrutar
paquetes a travs del tnel de una VPN basada en rutas combinando rutas estticas
con protocolos de enrutamiento dinmico. Mientras no ocurra ningn cambio de
ruta, el dispositivo de seguridad encripta y reenva constantemente los paquetes
destinados a las interfaces Tunnel asociadas a los tneles de la VPN basada en rutas.
Sin embargo, cuando se utiliza el seguimiento de VPN con una configuracin de
tnel VPN basado en rutas, el estado del tnel puede cambiar de en lnea (up) a
fuera de lnea (down). Cuando esto ocurre, todas las entradas de la tabla de rutas
que hacen referencia a la interfaz Tunnel asociada a ese tnel cambian a inactivas.
A continuacin, si el dispositivo de seguridad examina las rutas para buscar trfico
que originalmente debera estar encriptado y enviarse a travs de un tnel asociado
a esa interfaz Tunnel, no tendr en cuenta la ruta relativa a la interfaz Tunnel y
buscar la siguiente ruta con mayor coincidencia. La ruta que encuentre podra ser
la ruta predeterminada. Con esta ruta, el dispositivo de seguridad enviara fuera el
trfico desencriptado (es decir, en texto sin formato o sin formato) a travs de una
interfaz sin tnel a la WAN pblica.
Para evitar reenrutar el trfico previsto originalmente para un tnel VPN a la WAN
pblica como texto sin formato, puede configurar el dispositivo de seguridad para
que desve dicho trfico a otro tnel, reenrutarlo a una lnea arrendada o
simplemente descartarlo, utilizando una de las siguientes soluciones:
Ruta Null en la pgina 74 (descarta el trfico cuando la ruta a la interfaz

Tunnel se desactiva)
Lnea de acceso telefnico o arrendada en la pgina 76 (reencamina el trfico

a otra ruta segura cuando la ruta a la interfaz Tunnel se desactiva)
Interfaz Tunnel ficticia en la pgina 79 (descarta el trfico cuando la ruta a la

interfaz Tunnel se desactiva)
Enrutador virtual para interfaces Tunnel en la pgina 80 (descarta el trfico

cuando la ruta a la interfaz Tunnel se desactiva)
Reenrutamiento a otro tnel en la pgina 80 (reencamina el trfico a un tnel

VPN alternativo cuando la ruta a la interfaz Tunnel se desactiva)
Ruta Null
Si el estado de un tnel VPN cambia a fuera de lnea, el dispositivo de seguridad
cambia cualquier ruta que haga referencia a esa interfaz Tunnel a fuera de lnea. Si
la ruta a la interfaz Tunnel deja de estar disponible y la opcin siguiente es la ruta
predeterminada (por ejemplo), a continuacin el dispositivo de seguridad utiliza la
ruta predeterminada para reenviar el trfico previsto originalmente para el tnel
VPN. Para evitar enviar trfico en texto sin formato hacia la WAN pblica cuando se
produce un cambio de ruta, puede utilizar una ruta Null. Una ruta Null apunta a la
misma direccin de destino que la ruta a travs de la interfaz Tunnel, pero dirige el
trfico hacia la interfaz Null. La interfaz Null es una interfaz lgica que descarta el
trfico enviado hacia ella. Asigne a la ruta Null una mtrica ms elevada (ms
alejada de cero) que la ruta que utiliza la interfaz Tunnel para que la ruta Null tenga
una prioridad inferior.
74
NOTA:
Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces Null. No

obstante, puede utilizar una interfaz Tunnel ficticia para lograr el mismo objetivo.
Para obtener informacin, consulte Interfaz Tunnel ficticia en la pgina 79.
Por ejemplo, si crea una ruta esttica a travs de tunnel.1 hacia una LAN remota
con la direccin IP 10.2.2.0/24, su mtrica recibir automticamente el valor
predeterminado 1:
set vrouter trust-vr route 10.2.2.0/24 interface tunnel.1
get route
Dest-Routes for <trust-vr> (4 entries)

ID
IP-Prefix
Interface
Gateway
Pref
Mtr
Vsys
0.0.0.0/0
eth3
1.1.1.250
20
Root
1.1.1.0/24
eth3
0.0.0.0
Root
10.1.1.0/24
eth1
0.0.0.0
Root
10.2.2.0/24
tun.1
0.0.0.0
20
Root
En la tabla de enrutamiento anterior, un asterisco (*) indica que una ruta est
activa, S indica una ruta esttica y C indica una ruta conectada.
En la tabla de enrutamiento anterior, el dispositivo de seguridad tiene dos rutas
para alcanzar cualquier direccin en la subred 10.2.2.0/24. La primera opcin es la
ruta n 4 porque coincide en mayor medida con esa direccin. La segunda opcin
es la ruta predeterminada (0.0.0.0/0).
Si a continuacin agrega otra ruta a 10.2.2.0/24 a travs de la interfaz Null y le
asigna un valor mayor que 1, esa ruta se convierte en la segunda opcin de
enrutamiento hacia cualquier direccin de la subred 10.2.2.0/24. Si la ruta hacia
10.2.2.0/24 a travs de tunnel.1 se desactiva, el dispositivo de seguridad utiliza la
ruta hacia la interfaz Null. El dispositivo de seguridad reenva el trfico 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 <trust-vr> (5 entries)

ID
IP-Prefix
Interface
Gateway
Pref
Mtr Vsys
0.0.0.0/0
eth3
1.1.1.250
20
Root
1.1.1.0/24
eth3
0.0.0.0
Root
10.1.1.0/24
eth1
0.0.0.0
Root
10.2.2.0/24
tun.1
0.0.0.0
20
Root
10.2.2.0/24
null
0.0.0.0
20
10
Root
75
En la tabla de enrutamiento anterior, la ruta hacia 10.2.2.0/24 a travs de tunnel.1

est inactiva (indicado por la ausencia de un asterisco en la columna izquierda). Por
lo tanto, el dispositivo de seguridad busca la siguiente ruta con la mayor
coincidencia con la direccin de destino y encuentra la ruta nmero 5. (La siguiente
opcin despus de la ruta n 5 es la ruta predeterminada con la identificacin
nmero 3). A continuacin, el dispositivo de seguridad reenva el trfico para
10.2.2.0/24 a la interfaz Null, que descarta el trfico. Consecuentemente, si la ruta
que utiliza tunnel.1 se desactiva, el dispositivo de seguridad descarta el trfico para
10.2.2.0/24 en lugar de utilizar la ruta nmero 3 para reenviarlo hacia fuera a travs
de ethernet3 como texto sin formato al enrutador en 1.1.1.250.
Lnea de acceso telefnico o arrendada

Si no desea que el trfico dirigido a un interlocutor remoto se descarte cuando el
tnel hacia ese interlocutor se desactive, puede agregar una ruta alternativa hacia
ese interlocutor a travs de una lnea de acceso telefnico o arrendada. Esta ruta
alternativa utilizar la misma direccin IP de destino que la ruta a travs del tnel
VPN, pero tendr otra interfaz de salida y una mtrica menos prioritaria. Si la ruta a
travs del tnel VPN llegase a desactivarse, el dispositivo de seguridad reenrutara el
trfico dirigido al interlocutor remoto a travs de la lnea de acceso telefnico o
arrendada.
Cuando utilice una lnea de acceso telefnico o arrendada como ruta de siguiente
opcin, todava existe la posibilidad de que las rutas de primera y de segunda
opcin puedan desactivarse simultneamente. En ese caso, el dispositivo de
seguridad recurre a la tercera opcin, que puede ser la ruta predeterminada. En
previsin de tal situacin, puede convertir a la ruta de acceso telefnico o
arrendada en la segunda opcin y a la ruta Null en la tercera opcin (consulte Ruta
Null en la pgina 74). La Figura 22 muestra cmo estas opciones de tratamiento de
un fallo de enrutamiento pueden funcionar en conjunto.
Figura 22: Alternativas del fallo de enrutamiento para el trfico de VPN
Primera opcin: Un tnel VPN
hacia el interlocutor remoto.
ethernet1 10.1.1.1/24
Dispositivo de
seguridad
local
ethernet3 1.1.1.1/24
Zona Trust
LAN
local
Segunda opcin: Una ruta esttica sobre
una lnea de acceso telefnico o arrendada
hacia el interlocutor de la VPN. Su mtrica
es mayor que la de la ruta que utiliza el
tnel VPN. Esta opcin de enrutamiento
reenva el trfico como texto sin formato a
travs de la lnea protegida al interlocutor.
tunnel.1
Internet
LAN remota
Tnel VPN
ethernet4
1.2.2.1/24
Lnea de acceso
telefnico o arrendada
Interfaz
Null
Tercera opcin: Una ruta Null con una mtrica superior

que la de la lnea de acceso telefnico o arrendada. Esta
opcin descarta el trfico.
76
Zona Untrust
Interlocutor remoto
de la VPN
Descartar
trfico
Conmutacin por error de la VPN hacia la lnea arrendada o la ruta Null

En este ejemplo, deseamos que el trfico procedente de la sucursal detrs del
dispositivo-A alcance la red corporativa situada detrs del dispositivo-B a travs de
una conexin VPN segura. Si el tnel falla, el trfico deber fluir a travs de una
lnea arrendada hacia la oficina corporativa. Si tanto el tnel VPN como la lnea
arrendada fallan, el dispositivo-A deber descartar el trfico en lugar de enviarlo
fuera hacia Internet como texto sin formato.
Crear tres rutas en el dispositivo-A para alcanzar a 10.2.2.0/24 y asignar a cada
una su propia mtrica:
Ruta preferida: utilizar tunnel.1, asociado a vpn1 (mtrica = 1)
Ruta secundaria: utilizar ethernet4 y la puerta de enlace en 1.2.2.5 para

utilizar la lnea arrendada (mtrica = 2)
Ruta terciaria: utilice la interfaz Null para descartar trfico (mtrica = 10)
Al crear la ruta preferida, utilizar la mtrica predeterminada de una ruta esttica,

que es 1. Asignar una mtrica de 2 a la ruta secundaria; es decir, el la ruta de
respaldo a travs de la lnea arrendada (mostrada en la Figura 23 en la pgina 77).
La mtrica es inferior que la de la ruta preferida a travs del tnel VPN. El
dispositivo de seguridad no utiliza la ruta secundaria a menos que la ruta preferida
a travs del tnel VPN falle.
Finalmente, agregar una ruta NULL con una mtrica de 10. Si la ruta preferida falla
y a continuacin tambin falla la ruta secundaria, el dispositivo de seguridad
descartar todos los paquetes. Todas las zonas de seguridad se encuentran en el
dominio de enrutamiento trust-vr.
NOTA:
Este ejemplo muestra nicamente la configuracin para cuatro rutas (tres para la
conmutacin por error ms la ruta predeterminada) en el dispositivo-A.
Figura 23: Fallo de enrutamiento hacia una lnea arrendada y despus a la ruta Null
El trfico fluye desde la sucursal a la
oficina corporativa.
Preferencias de rutas:
1. tunnel.1 -> vpn1
2. ethernet4 -> lnea arrendada
3. interfaz null -> descartar
ethernet3
1.1.1.1/24
Puerta de enlace
1.1.1.250
ethernet3
2.2.2.2/24
tunnel.1
tunnel.1
LAN
10.1.1.0/24
Dispositivo A
Dispositivo B
Internet
LAN
10.2.2.0/24
vpn1
Lnea arrendada (ruta de respaldo)
Ruta NULL
Puerta de enlace: 1.2.2.5/24

ethernet4
1.2.2.1/24
ethernet4
2.3.3.2/24
77
WebUI (dispositivo-A)
Network > Routing > Routing Entries > trust-vr New: Introduzca los
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 (dispositivo-A)
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 1.1.1.250
set vrouter trust-vr route 10.2.2.0/24 interface ethernet4 gateway 1.2.2.5 metric
2
save
78
Puede verificar la presencia de las nuevas rutas ejecutando el comando get route.
device-C-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)

-------------------------------------------------------------------------------H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (7 entries)

-------------------------------------------------------------------------------ID
IP-Prefix
Interface
Gateway
P Pref
Mtr
Vsys
-------------------------------------------------------------------------------*
8
0.0.0.0/0
eth1/1
10.100.37.1
S
20
1
Root
*
7
1.1.1.1/32
eth1/2
0.0.0.0
H
0
0
Root
*
3
192.168.1.1/32
mgt
0.0.0.0
H
0
0
Root
*
2
192.168.1.0/24
mgt
0.0.0.0
C
0
0
Root
*
4
10.100.37.0/24
eth1/1
0.0.0.0
C
0
0
Root
*
5
10.100.37.170/32
eth1/1
0.0.0.0
H
0
0
Root
*
6
1.1.1.0/24
eth1/2
0.0.0.0
C
0
0
Root
La entrada de la tabla de rutas con la identificacin 5 dirige el trfico destinado a

10.2.2.0/24 hacia tunnel.1 y luego a travs del tnel VPN. Es la ruta preferida para
que el trfico alcance la red 10.2.2.0. Si ese tnel falla, la siguiente mejor ruta es la
correspondiente a la entrada 6 sobre una lnea arrendada a travs de una puerta de
enlace en 1.2.2.5. Si la conexin de la entrada de ruta 6 falla, la entrada de ruta 7 se
convierte en la siguiente mejor ruta y el dispositivo de seguridad dirige el trfico
destinado a 10.2.2.0/24 hacia la interfaz Null, que despus lo descarta.
Interfaz Tunnel ficticia

Cuando se produce un error, en lugar de conmutar el trfico de un tnel VPN a una
interfaz Null (donde se descarta), se puede utilizar una interfaz Tunnel inoperativa
para lograr el mismo objetivo.
NOTA:
Las versiones anteriores a ScreenOS 5.1.0 no admiten interfaces Null (consulte

Ruta Null en la pgina 74). Sin embargo, puede utilizar una interfaz Tunnel
ficticia para lograr el mismo objetivo.
Para configurar una interfaz Tunnel ficticia, haga lo siguiente:
1. Cree una segunda interfaz Tunnel, pero no la asocie a un tnel VPN. En su lugar,
asciela a una zona Tunnel que se encuentre en el mismo dominio de
enrutamiento virtual que la primera interfaz Tunnel.
NOTA:
Si una interfaz Tunnel est asociada a una zona de tnel, su estado siempre ser
activo.
79
2. Defina una segunda ruta hacia el mismo destino utilizando esta segunda
interfaz Tunnel y asgnele una mtrica ms alta (ms alejada de cero) que la de
la ruta preferida.
Cuando el estado de la interfaz Tunnel en funcionamiento pase de en lnea a
fuera de lnea y la entrada de la tabla de rutas relativa a esa interfaz quede
inactiva, las consultas de rutas encontrarn esta segunda ruta a la interfaz
Tunnel no operativa. El dispositivo de seguridad reenviar el trfico a la
segunda interfaz Tunnel y como no est asociada a un tnel VPN, el dispositivo
descartar el trfico.
Enrutador virtual para interfaces Tunnel

Para evitar que, al desactivarse la ruta programada a travs de un tnel VPN, el
trfico que originalmente deba atravesar el tnel se conmute en caso de error hacia
la ruta predeterminada, puede crear un dominio de enrutamiento virtual especial
exclusivamente para el trfico VPN. Para configurarlo, proceda de la siguiente
manera:
1. Cree un enrutador virtual independiente para utilizarlo con todas las rutas que
apunten a interfaces Tunnel y dle, por ejemplo, el nombre VR-VPN.
2. Cree una zona de seguridad (llamada, por ejemplo, zona VPN) y asciela a
VR-VPN.
3. Asocie todas las interfaces Tunnel a la zona VPN e introduzca todas las
direcciones de ubicaciones remotas a las que desee acceder a travs de tneles
VPN en esta zona.
4. Configure rutas estticas en todos los dems enrutadores virtuales a VR-VPN
para el trfico que desee que est encriptado y se enve a travs de los tneles.
En caso necesario, defina rutas estticas para el trfico desencriptado desde
VR-VPN a otros enrutadores virtuales. Estas rutas son necesarias para permitir
que el trfico VPN entrante pase por el tnel si se inicia desde la ubicacin
remota.
Si el estado de una interfaz Tunnel pasa de en lnea a fuera de lnea, el
dispositivo de seguridad an 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 de seguridad descartar el trfico.
Reenrutamiento a otro tnel

Puede configurar dos o ms tneles VPN hacia el mismo interlocutor remoto. Si uno
de los tneles queda fuera de lnea, el dispositivo de seguridad puede reenrutar el
trfico a travs de otro tnel VPN. Para obtener informacin y ejemplos sobre la
configuracin de tneles VPN redundantes, consulte:
80
Cambio en caso de fallo del tnel de activo a respaldo en la pgina 11-51
Configuracin de tneles activos dobles en la pgina 11-71
Configuracin de los pesos de cambio en caso de fallo del tnel en la

pgina 11-78
Captulo 4
Redes privadas virtuales de punto a

punto
En este captulo se explica cmo configurar un tnel de red privada virtual (VPN)
punto a punto entre dos dispositivos de seguridad de Juniper Networks. Aqu se
examinan los tneles VPN basados en rutas y basados en directivas, se presentan
los diversos elementos que hay que tener en cuenta al configurar un tnel y se
ofrecen varios ejemplos.
Configuraciones VPN punto a punto en la pgina 82
VPN punto a punto basada en rutas, AutoKey IKE en la pgina 88
VPN punto a punto basada en directivas, AutoKeyIKE en la pgina 97
VPN punto a punto basada en rutas, interlocutor dinmico en la

pgina 103
VPN punto a punto basada en directivas, interlocutor dinmico en la

pgina 112
VPN punto a punto basada en rutas, clave manual en la pgina 120
VPN punto a punto basada en directivas, clave manual en la pgina 127
Puertas de enlace IKE dinmicas con FQDN en la pgina 132
Alias en la pgina 133
Ajuste del interlocutor AutoKey IKE con FQDN en la pgina 134
Sitios VPN con direcciones superpuestas en la pgina 142
VPN en modo transparente en la pgina 154
81
Configuraciones VPN punto a punto

Existe un tnel VPN IPSec entre dos puertas de enlace y cada puerta de enlace
necesita una direccin IP. Si ambas puertas de enlace tienen direcciones IP
estticas, se pueden configurar los siguientes tipos de tneles:
Tnel VPN punto a punto AutoKey IKE (con clave previamente compartida o
certificados)
Tnel VPN punto a punto con clave manual
Si una puerta de enlace tiene una direccin esttica, y la otra tiene una direccin
asignada de forma dinmica, se puede configurar el siguiente tipo de tnel:
Tnel VPN punto a punto de interlocutor dinmico AutoKey IKE (con clave
previamente compartida o certificados)
Tal como se utiliza aqu, una VPN punto a punto esttica implica la existencia de un
tnel IPSec para conectar dos puntos, cada uno de ellos con un dispositivo de
seguridad operativo como puerta de enlace segura. La interfaz o subinterfaz fsica
utilizada como interfaz de salida en ambos dispositivos tiene una direccin IP fija,
y los hosts internos tambin tienen direcciones IP estticas. Si el dispositivo de
seguridad se encuentra en modo transparente, utiliza la direccin VLAN1 como
direccin IP para la interfaz de salida. Con una VPN punto a punto esttica, los
hosts situados en cualquier extremo del tnel pueden iniciar la configuracin del
tnel VPN porque la direccin IP de la puerta de enlace remota se mantiene
constante y, por tanto, accesible.
Si la interfaz de salida de uno de los dispositivos de seguridad tiene una direccin IP
asignada dinmicamente, dicho dispositivo se considera un interlocutor dinmico y
la VPN se configura de forma distinta. Con una VPN punto a punto de interlocutor
dinmico, slo los hosts ubicados detrs del interlocutor dinmico pueden iniciar la
configuracin del tnel VPN, ya que slo su puerta de enlace remota tiene una
direccin IP fija y, por tanto, es accesible desde su puerta de enlace local. Sin
embargo, una vez que se ha establecido un tnel entre un interlocutor dinmico y
un interlocutor esttico, los hosts ubicados detrs de cualquier puerta de enlace
pueden iniciar trfico VPN si los hosts de destino tienen direcciones IP fijas.
NOTA:
Para obtener ms informacin sobre las opciones de VPN disponibles, consulte

Seguridad del protocolo de Internet en la pgina 1. Si desea obtener ayuda para
elegir entre las distintas opciones, consulte Directrices para las redes privadas
virtuales en la pgina 49.
La configuracin de un tnel VPN punto a punto requiere la coordinacin de la
configuracin del tnel con la configuracin de otros ajustes (interfaces,
direcciones, rutas y directivas). Los tres ejemplos de configuracin VPN incluidos en
esta seccin se enmarcan en el siguiente contexto: una oficina de Tokio desea
comunicarse de forma segura con una oficina de Pars a travs de un tnel VPN
IPSec.
82
Captulo 4: Redes privadas virtuales de punto a punto
Figura 24: Configuracin de tneles VPN punto a punto
Zona Trust
Oficin
de Tokio
Zona Untrust
tunnel.1, sin numerar
ethernet1
10.1.1.1/24
NAT
LAN
10.1.1.0/24
ethernet3, 1.1.1.1/24
enrutador externo, 1.1.1.250
Dispositivo de
seguridad
de Tokio
Internet
Tunnel:vpn1
LAN
10.2.2.0/24
Dispositivo de
seguridad
de Pars
ethernet1
10.2.2.1/24
ethernet3, 2.2.2.2/24
Zona Untrust
Oficina
de Pars
Zona Trust
Los administradores de ambas oficinas configuran los siguientes ajustes:
Interfaces: Zonas de seguridad y tnel
Direcciones
VPN (una de las opciones siguientes)
AutoKey IKE
Interlocutor dinmico
Clave manual
Rutas
Directivas
83
Figura 25: Configuracin de tneles punto a punto: Interfaces
Zona Trust
Oficina
de Tokio
Zona Untrust
ethernet1
10.1.1.1/24
NAT
Eth3, 1.1.1.1/24
Dispositivo de
seguridad
de Tokio
Internet
Dispositivo de
seguridad
de Pars
Eth3, 2.2.2.2/24
ethernet1
10.2.2.1/24
NAT
Zona Untrust
1.
Oficina
de Pars
Zona Trust
Interfaces: Zonas de seguridad y tnel
El administrador de la oficina de Tokio configura las interfaces de zona de seguridad

y tnel con los ajustes que aparecen en la mitad superior de la Figura 25.
Asimismo, el administrador de la oficina de Pars configura los ajustes que aparecen
en la mitad inferior de la figura.
Ethernet3 va a ser la interfaz de salida para el trfico VPN y la puerta de enlace
remota para el trfico VPN enviado desde el otro extremo del tnel.
Ethernet1 se encuentra en modo NAT, por lo que cada administrador puede asignar
direcciones IP a todos los hosts internos, incluso si el trfico pasa de la zona Trust a
la zona Untrust, el dispositivo de seguridad traduce la direccin IP de origen de los
encabezados de los paquetes a la direccin de la interfaz de la zona Untrust,
ethernet3 (1.1.1.1 para Tokio y 2.2.2.2 para Pars).
Para una VPN basada en rutas, cada administrador asocia la interfaz de tnel
tunnel.1 al tnel VPN vpn1. Definiendo una ruta al espacio de direcciones de la LAN
de la oficina remota, el dispositivo de seguridad puede dirigir todo el trfico
asociado a dicha LAN a la interfaz tunnel.1, y por tanto, a travs del tnel al que
est asociada tunnel.1.
Como no se requieren servicios NAT basados en directivas, una configuracin VPN
basada en rutas no requiere que tunnel.1 tenga una direccin IP/mscara de red,
y una configuracin VPN basada en directivas ni siquiera requiere una interfaz de
tnel.
84
Figura 26: Configuracin de tneles punto a punto: Direcciones

Oficina
de Tokio
Zona Trust
Trust_LAN
Trust, 10.1.1.0/24
Tokio
Untrust 10.1.1.0/24
ethernet1
10.1.1.1/24
NAT
Zona Untrust
ethernet3, 1.1.1.1/24
Dispositivo de
seguridad
de Tokio
Internet
LAN
ethernet3, 2.2.2.2/24
LAN
Dispositivo de
seguridad
de Pars
ethernet1
10.2.2.1/24
NAT

Zona Untrust
2.
Pars
Untrust, 10.2.2.0/24
Trust_LAN
Trust 10.2.2.0/24
Oficina
de Pars
Zona Trust
Direcciones
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 la mitad superior de la Figura 26. Asimismo, el administrador de la
oficina de Pars configura las direcciones que aparecen en la mitad inferior de la
figura.
Para VPN basadas en directivas, el dispositivo de seguridad deriva las ID de proxy a
partir de las directivas. Como las ID de proxy utilizadas por los dispositivos de
seguridad situados a ambos extremos del tnel VPN deben coincidir exactamente,
no es posible utilizar la direccin predefinida ANY, cuya direccin IP es 0.0.0.0/0,
en un extremo del tnel si se utiliza una direccin ms especfica en el otro
extremo. Por ejemplo:
Si la ID de proxy de Tokio es como aparece a continuacin:
From: 0.0.0.0/0
To: 10.2.2.0/24
Service: ANY
Y si la ID de proxy de Pars es como aparece a continuacin:

To: 10.1.1.0/24
From: 10.2.2.0/24
Service: ANY
Entonces las ID de proxy no coincidirn y las negociaciones IKE fracasarn.
NOTA:
A partir de ScreenOS 5.0.0, tambin es posible definir ID de proxy para tneles

VPN de los que se incluyen referencias en configuraciones VPN basadas en
directivas.
Para las VPN basadas en rutas, es posible utilizar 0.0.0.0/00.0.0.0/0any para
definir las direcciones IP local y remota y el tipo de servicio para una ID de proxy.
Y luego se pueden utilizar directivas ms restrictivas para filtrar el trfico VPN
entrante y saliente por direccin de origen, direccin de destino y tipo de servicio.
85
Figura 27: Configuracin de tneles punto a punto: Tnel VPN
Trust_LAN
Trust, 10.1.1.0/24
Tokio
Untrust 10.1.1.0/24
Zona Untrust
Oficina
de Tokio
Zona Trust
ethernet1
10.1.1.1/24
NAT
Dispositivo de
seguridad
de Tokio
Tunnel.1, sin numerar

ethernet3, 1.1.1.1/24
LAN
Trust_LAN
Trust 10.2.2.0/24
Internet
Tnel: vpn1
ethernet3, 2.2.2.2/24
LAN
Dispositivo de
seguridad
de Pars

Zona Untrust
3.
Oficina
de Pars
Pars
Untrust, 10.2.2.0/24
ethernet1
10.2.2.1/24
NAT
Zona Trust
VPN
Es posible configurar una de las tres VPN siguientes:
AutoKey IKE
El mtodo AutoKey IKE utiliza una clave previamente compartida o un
certificado para renovar (es decir, modificar) las claves de encriptacin y
autenticacin automticamente 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 dinmico
Un interlocutor dinmico es una puerta de enlace remota que tiene una
direccin IP asignada de forma dinmica. Como es posible que la direccin IP
del interlocutor remoto sea diferente cada vez que comienzan las
negociaciones IKE, los hosts situados detrs del interlocutor deben iniciar el
trfico VPN. Asimismo (si se utiliza una clave previamente compartida para la
autenticacin), el interlocutor debe enviar una ID IKE durante el primer
mensaje de las negociaciones de fase 1 en modo dinmico para identificarse.
Clave manual
El mtodo de clave manual requiere la configuracin y actualizacin manual de
las claves de encriptacin y autenticacin. Este mtodo es una opcin viable
para un pequeo conjunto de tneles VPN.
86
Figura 28: Configuracin de tneles punto a punto: Rutas

trust-vr
Dest 10.2.2.0/24
Utilizar tunnel. 1
Dest 10.2.2.0/24
Utilizar NULL
Metric: 50
Dest 0.0.0.0/0
Utilizar eth3
Puerta de enlace:
1.1.1.250
Trust_LAN
Trust, 10.1.1.0/24
Oficina
de Tokio
Zona Trust
ethernet1
10.1.1.1/24
NAT
Interfaz Null
Zona Untrust
ethernet3, 1.1.1.1/24
Enrutador externo, 1.1.1.250
Internet
LAN
LAN
Tunnel:vpn1
ethernet3, 2.2.2.2/24
Interfaz Null
Tokio
Untrust, 10.1.1.0/24
Zona Untrust
4.
Oficina de
Pars
Trust_LAN
Trust, 10.2.2.0/24
Pars
Untrust,
10.2.2.0/24
trust-vr
Dest 10.1.1.0/24
Utilizar tunnel. 1
Dest 10.1.1.0/24
ethernet1 Utilizar NULL
10.2.2.1/24 Metric: 50
NAT
Zona Trust
Dest 0.0.0.0/0
Utilizar eth3
Puerta de enlace:
2.2.2.250
Rutas
Los administradores de cada extremo del tnel deben configurar al menos las rutas
siguientes:
NOTA:
Una ruta para el trfico destinado a una direccin de la LAN remota a travs de
tunnel.1.
Una ruta predeterminada para el resto del trfico, incluyendo el trfico de tnel
VPN externo, para el acceso a Internet a travs de ethernet3 y el enrutador
externo situado ms all (1.1.1.250 para la oficina de Tokio y 2.2.2.250 para la
de Pars). El enrutador externo es la puerta de enlace predeterminada hacia la
que el dispositivo de seguridad reenva todo el trfico para el que no disponga
de una ruta especfica en su tabla de enrutamiento.
Si el dispositivo de seguridad de la oficina de Tokio recibe su direccin IP externa

de forma dinmica de su ISP (es decir, si desde el punto de vista de la oficina de
Pars, el dispositivo de seguridad de la oficina de Tokio es un interlocutor
dinmico), el ISP proporciona automticamente al dispositivo de Tokio su
direccin IP de puerta de enlace predeterminada.
Una ruta Null, de modo que si en algn momento el estado cambia de tunnel.1
a fuera de lnea y cualquier ruta que haga referencia a tunnel.1 se desactiva,
el dispositivo de seguridad no utilice la ruta predeterminada para reenviar el
trfico destinado a la LAN remota fuera de ethernet3 sin encriptar. Una ruta
Null utiliza la LAN remota como direccin de destino, pero enva trfico a la
interfaz Null, una interfaz lgica que descarta todo el trfico que recibe. Asigne
a la ruta Null una mtrica superior (ms alejada de cero) que la ruta a la LAN
remota que utiliza tunnel.1, haciendo la ruta Null menos preferente que la ruta
que hace referencia a la interfaz de tunnel.1.
87
Figura 29: Configuracin de tneles punto a punto: Directivas

trust-vr
Dest 10.2.2.0/24
Utilizar tunnel. 1
Zona Trust
Dest 0.0.0.0/0
Utilizar eth1
puerta de enlace:
1.1.1.250
ethernet1
10.1.1.1/24
NAT
Trust_LAN
Trust, 10.1.1.0/24
Oficina
de Tokio
trust-vr
Dest 10.1.1.0/24
Utilizar tunnel. 1
Zona Untrust
Dest 0.0.0.0/0
Utilizar eth3
puerta de enlace:
2.2.2.250

ethernet3, 1.1.1.1/24
Enrutador externo, 1.1.1.250
Interfaz Null
Internet
LAN
LAN
Tunnel:vpn1
Tokio
Untrust,
10.1.1.0/24
Interfaz Null
ethernet3, 2.2.2.2/24
Trust -> Untrust

Trust_LAN ->Pars
ANY, Permit
Zona Untrust
Oficina
de Pars
Trust_LAN
Trust, 10.2.2.0/24
Pars
ethernet1 Untrust,
10.2.2.1/24 10.2.2.0/24
NAT
Trust -> Untrust
Trust_LAN ->
Pars
Zona Trust
ANY), Permit
Untrust -> Trust
Pars->
Trust_LAN
ANY, Permit
Untrust -> Trust

Pars -> Trust_LAN
ANY, Permit
5.
Directivas
Los administradores de cada extremo del tnel definen directivas para permitir el
trfico entre las dos oficinas:
Una directiva que permita cualquier tipo de trfico desde Trust_LAN en la

zona Trust hasta Pars o Tokio en la zona Untrust
Una directiva que permita cualquier tipo de trfico desde Pars 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 tnel
VPN vpn1, no es necesario que la directiva haga referencia al tnel VPN.
VPN punto a punto basada en rutas, AutoKey IKE

En este ejemplo, un tnel AutoKey IKE que utiliza un secreto previamente
compartido o un par de certificados (uno por cada extremo del tnel) proporciona
la conexin segura entre las oficinas de Tokio y Pars. Para los niveles de seguridad
de las fases 1 y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el
mtodo 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.
88
Figura 30: VPN punto a punto basada en rutas, AutoKey IKE

Topologa de las zonas
configuradas en el dispositivo
de seguridad de Tokio
Tokio
Zona
Trust

de seguridad de Pars
Pars
Zona
Untrust
Tokio
Zona Trust
eth1, 10.1.1.1/24
Pars
Tokio
Zona
Untrust
Interfaz de salida
Zona Untrust
eth3, 1.1.1.1/24
Puerta de enlace
1.1.1.250
Interfaz de salida
Zona Untrust
eth3, 2.2.2.2/24
Puerta de enlace
2.2.2.250
Internet
Zona
Trust
Pars
Zona Trust
eth1, 10.2.2.1/24
Tnel VPN
Interfaz de tnel
Tunnel.1
Interfaz de tnel
Tunnel.1
La configuracin de un tnel AutoKey IKE basado en rutas mediante un secreto

previamente compartido o certificados implica los siguientes pasos:
1. Asignar direcciones IP a las interfaces fsicas asociadas a las zonas de seguridad
y a la interfaz de tnel.
2. Configurar el tnel VPN, designar su interfaz de salida en la zona Untrust,
asociarla a la interfaz de tnel y configurar su ID de proxy.
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 travs de la interfaz de tnel y otra ruta Null al destino. Asigne una
mtrica ms alta (ms alejada de cero) a la ruta Null para que se convierta en la
siguiente opcin de ruta al destino. A continuacin, si el estado de la interfaz de
tnel cambia a fuera de lnea y la ruta que hace referencia a esa interfaz
tambin se desactiva, el dispositivo de seguridad utiliza la ruta Null, que
descarta todo trfico enviado hacia l, en lugar de la ruta predeterminada, que
reenva trfico no encriptado.
5. Definir directivas para la circulacin del trfico 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 certificacin (CA). (Para ms informacin sobre cmo obtener y cargar
certificados, consulte Certificados y CRL en la pgina 24).
89
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 opcin si es posible)
IP Address/Netmask: 10.1.1.1/24

Interface Mode: NAT
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)
2.
Direcciones
Address Name: Trust_LAN
Zone: Trust
Policy > Policy Elements> > Addresses > List > New: Introduzca los
Address Name: Paris_Office
Zone: Untrust
3.
VPN
VPN > 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
90
Preshared Key: h1p8A24nG5

Outgoing Interface: ethernet3
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic

en Return para regresar a la pgina de configuracin bsica de puerta de
enlace:
Phase 1 Proposal (para nivel de seguridad personalizado):
pre-g2-3des-sha
Mode (Initiator): Main (Proteccin de la identificacin)
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Preferred certificate (opcional)
Peer CA: Entrust
Peer Type: X509-SIG
VPN > 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

en Return para regresar a la pgina de configuracin bsica 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
91
Interface: Tunnel.1
Interface: Null
Metric: 10
5.
Directivas
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
Action: Permit
WebUI (Pars)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
92
clic en OK:
2.
Direcciones
Zone: Trust
Address Name: Tokyo_Office
Zone: Untrust
3.
VPN
y haga clic en OK:
Gateway Name: To_Tokyo


enlace:
pre-g2-3des-sha
(o bien)
93
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway:
Predefined: (seleccione), To_Tokyo

IKE:
Service: ANY
4.
Rutas
Interface: Tunnel.1
Interface: Null
Metric: 10
94
5.
Directivas
haga clic en OK:
Name: To_Tokyo
Source Address:
Address Book Entry: (seleccione), Trust_LAN
Destination Address:
Address Book Entry: (seleccione), Tokyo_Office
Service: ANY
Action: Permit
Policies > (From: Untrust, To: Trust) New: Introduzca los siguientes datos y
haga clic en OK:
Name: From_Tokyo
Source Address:
Service: ANY
Action: Permit
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
2.
Direcciones
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)
95
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
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris sec-level compatible
NOTA:
El nmero 1 es el nmero de ID de la CA. Para consultar los nmeros ID de CA,

utilice el siguiente comando: get ike ca.
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 (Pars)
1.
Interfaces

2.
Direcciones

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
96
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
VPN punto a punto basada en directivas, AutoKeyIKE

En este ejemplo, un tnel AutoKey IKE que utiliza un secreto previamente
la conexin segura entre las oficinas de Tokio y Pars. Para los niveles de seguridad
de las fases 1 y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el
mtodo 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.
Figura 31: VPN punto a punto basada en directivas, AutoKey IKE
Tokio
Zona
Trust

Pars
Zona
Untrust-Tun
Zona
Untrust
Zona
Untrust
Tokio
Zona Trust
eth1, 10.1.1.1/24
Pars
Tokio
Interfaz de salida
Zona Untrust
eth3, 1.1.1.1/24
Puerta de enlace
1.1.1.250
Interfaz de salida
Zona Untrust
eth3, 2.2.2.2/24
Puerta de enlace
2.2.2.250
Internet
Zona
Untrust-Tun
Zona
Untrust
Pars
Zona Trust
eth1, 10.2.2.1/24
Tnel VPN
La configuracin de un tnel AutoKey IKE utilizando AutoKey IKE mediante un

secreto previamente compartido o certificados implica los siguientes pasos:
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.
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.
97
5. Configurar una ruta predeterminada que conduzca al enrutador externo.

6. Configurar directivas.
certificados, consulte Certificados y CRL en la pgina 24).
WebUI (Tokio)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
y haga clic en OK:
98

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

para regresar a la pgina de configuracin bsica de puerta de enlace:
pre-g2-3des-sha
(o bien)
Certificados
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en OK

rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
VPNs > AutoKey IKE > New: Introduzca los siguientes datos y haga clic en OK:
Remote Gateway: Predefined: (seleccione), To_Paris
4.
Ruta
5.
Directivas
haga clic en OK:
Name: To/From Paris
Source Address:
Address Book Entry: (seleccione), Paris_Office
Service: ANY
Action: Zona
Tunnel VPN: Tokyo_Paris
Modify matching bidirectional VPN policy: (seleccione)
99
WebUI (Pars)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
y haga clic en OK:
100


enlace:
pre-g2-3des-sha
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
VPN Name: Paris_Tokyo
Remote Gateway: Predefined: (seleccione), To_Tokyo
4.
Ruta
101
5.
Diresctivas
haga clic en OK:
Name: To/From Tokyo
Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Paris_Tokyo
CLI (Tokio)
1.
Interfaces

2.
Direcciones

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
set ike gateway to_paris cert peer-cert-type x509-sig
NOTA:

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
save
102
CLI (Pars)
1.
Interfaces

2.
Direcciones

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
save
VPN punto a punto basada en rutas, interlocutor dinmico

En este ejemplo, un tnel VPN AutoKey IKE que utiliza una clave previamente
compartida o un par de certificados (uno por cada extremo del tnel) proporciona
la conexin segura entre los dispositivos de seguridad para proteger las oficinas de
Tokio y Pars. La interfaz de la zona Untrust para el dispositivo de seguridad de Pars
cuenta con una direccin IP esttica. El ISP de la oficina de Tokio asigna la direccin
IP para la interfaz de zona Untrust de forma dinmica a travs del protocolo DHCP.
Como slo el dispositivo de seguridad de Pars tiene una direccin fija para su zona
Untrust, el trfico VPN se debe originar desde los hosts de la oficina de Tokio. Una
vez establecido un tnel, el trfico que atraviese el tnel se puede originar desde
cualquier extremo de dicho tnel. Todas las zonas de tnel y de seguridad se
encuentran en trust-vr.
103
Figura 32: VPN punto a punto basada en rutas, interlocutor dinmico


Tokio
Zona
Trust
Zona
Untrust
Zona
Untrust
Interfaz de salida
Zona Untrust
eth3 y puerta de enlace
asignadas dinmicamente
por el ISP
Tokio
Zona Trust
eth1, 10.1.1.1/24
Pars
Tokio
Pars
Interfaz de salida
Zona Untrust
eth3, 2.2.2.2/24
Puerta de enlace
2.2.2.250
Zona
Trust
Pars
Zona Trust
eth1, 10.2.2.1/24
Internet
Tnel VPN
Interfaz de tnel
Tunnel.1
Interfaz de tnel
Tunnel.1
Servidor DHCP
2.1.1.5
La clave previamente compartida es h1p8A24nG5. Se parte de la base de que

ambos participantes ya tienen certificados RSA emitidos por la autoridad de
certificacin (CA) Verisign y que la direccin de correo electrnico pmason@abc.com
aparece en el certificado local del dispositivo A. (Para obtener ms informacin
sobre la adquisicin y la carga de certificados, consulte Certificados y CRL en la
pgina 24). Para los niveles de seguridad de las fases 1 y 2, debe especificar una
propuesta de fase 1 (pre-g2-3des-sha para el mtodo 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 de seguridad en cada extremo del tnel VPN:
Una ruta predeterminada que conduzca al enrutador externo en trust-vr
Una ruta al destino a travs de la interfaz de tnel
Una ruta Null al destino. Asigne una mtrica ms alta (ms alejada de cero) a la
ruta Null para que se convierta en la siguiente opcin de ruta al destino.
A continuacin, si el estado de la interfaz de tnel cambia a fuera de lnea y la
ruta que hace referencia a esa interfaz tambin se desactiva, el dispositivo de
seguridad utiliza la ruta Null, que descarta todo trfico enviado hacia l, en
lugar de la ruta predeterminada, que reenva trfico no encriptado.
Finalmente, configure directivas para permitir trfico bidireccional entre los dos
sitios.
WebUI (Tokio)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
104

Interface Mode: NAT
haga clic en Apply:
Zone Name: Untrust

Obtain IP using DHCP: (seleccione)
NOTA:
La direccin IP del servidor DHCP no se puede especificar mediante WebUI; no

obstante, s se puede especificar mediante comandos CLI.
clic en OK:
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
y haga clic en OK:

Local ID: pmason@abc.com
105

enlace:
pre-g2-3des-sha
Mode (Initiator): Aggressive
(o bien)
Certificados

NOTA:
El U-FQDN pmason@abc.com debe aparecer en el campo SubjectAltName del

certificado.
enlace:
rsa-g2-3des-sha
Preferred Certificate (opcional):
Peer CA: Verisign
Peer Type: X509-SIG
Remote Gateway:

IKE:
Bind to: Tunnel Interface: (seleccione), tunnel.1
Service: ANY
4.
Rutas
106
NOTA:
El ISP proporciona la direccin IP de la puerta de enlace de forma dinmica a

travs del protocolo DHCP.
Interface: Tunnel.1
Interface: Null
Metric: 10
5.
Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
WebUI (Pars)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
107
haga clic en OK:
Zone Name: Untrust
IP Address: 2.2.2.2/24
clic en OK:
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
y haga clic en OK:
Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com


enlace:
pre-g2-3des-sha
(o bien)
108
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Paris_Tokyo
Remote Gateway:

IKE:
Service: ANY
4.
Rutas
Gateway IP Address: (seleccione), 2.2.2.250
Interface: Tunnel.1
Interface: Null
Metric: 10
109
5.
Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
CLI (Tokio)
1.
Interfaces

set interface ethernet3 dhcp client
set interface ethernet3 dhcp client settings server 1.1.1.5
2.
Direcciones

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

outgoing-interface ethernet3 proposal rsa-g2-3des-sha
set ike gateway To_Paris cert peer-ca 1
set ike gateway To_Paris cert peer-cert-type x509-sig
set vpn Tokyo_Paris gateway To_Paris tunnel sec-level compatible
110
NOTA:

certificado.
4.
Rutas
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3

NOTA:

travs del protocolo DHCP, por lo tanto, no se puede especificar aqu.
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
CLI (Pars)
1.
Interfaces

2.
Direcciones

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
set ike gateway To_Tokyo cert peer-cert-type x509-sig
set vpn Paris_Tokyo gateway To_Tokyo tunnel sec-level compatible
111
NOTA:

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
VPN punto a punto basada en directivas, interlocutor dinmico

En este ejemplo, un tnel VPN conecta de forma segura a los usuarios de la zona
Trust situados detrs del dispositivo A con el servidor de correo de la zona
corporativa DMZ protegida por el dispositivo B. La interfaz de zona Untrust para el
dispositivo B tiene una direccin IP esttica. El ISP del dispositivo A asigna la
direccin IP para su interfaz de zona Untrust de forma dinmica a travs del
protocolo DHCP. Puesto que slo el dispositivo B tiene una direccin fija para su
zona Untrust, el trfico VPN se debe originar desde los hosts situados detrs del
dispositivo A. Una vez que el dispositivo A haya establecido el tnel, el trfico que
atraviese el tnel se puede originar desde cualquiera de sus extremos. Todas las
zonas se encuentran en el dominio de enrutamiento trust-vr.
Figura 33: VPN punto a punto basada en directivas, interlocutor dinmico
configuradas en dispositivo-A
en la sucursal.
A

B en la sede central
A
Sucursal
Zona Trust
eth1, 10.1.1.1/24
Zona
DMZ
Zona
Untrust
Zona
Untrust
Zona
Trust
Interfaz de salida
Zona Untrust
eth3 y puerta de enlace
asignados dinmicamente
por el ISP
Interfaz de salida
Zona Untrust
eth3, 2.2.2.2/24
Gateway 2.2.2.250
Oficina
corporativa
Zona DMZ
eth2, 3.3.3.3/24
Servidor de
correo
electrnico
3.3.3.5
Internet
Dispositivo A
Peticin
SMTP o POP3
ID
Usuario de
autenticacin
Nombre de usuario: pmason
Contrasea: Nd4syst4
Phil
112
Tnel VPN
Servidor
DHCP
2.1.1.5
Nota: Antes de realizar una conexin SMTP o POP3 con el

servidor de correo corporativo, Phil debe iniciar primero una
conexin HTTP, FTP o Telnet para que el dispositivo A
pueda autenticarle.
Dispositivo B
Peticin
IDENT
En este ejemplo, el usuario de autenticacin local Phil (nombre de usuario: pmason;

contrasea: Nd4syst4) desea recoger su correo electrnico del servidor de correo
electrnico del sitio corporativo. Cuando intenta hacerlo, pasa por dos
autenticaciones: primero, el dispositivo A le autentica de forma local antes de
permitir que el trfico originado por l atraviese el tnel; despus, el programa de
servidor de correo le autentica de nuevo enviando una peticin IDENT a travs del
tnel.
NOTA:
Como Phil es un usuario de autenticacin, antes de que pueda realizar una

peticin SMTP o POP3, debe iniciar primero una conexin HTTP, FTP o Telnet
para que el dispositivo A pueda responder con un mensaje de peticin de inicio de
sesin/usuario de cortafuegos para autenticarle. Una vez que el dispositivo A le
haya autenticado, tendr permiso para establecer contacto con el servidor de
correo corporativo a travs del tnel VPN.
El servidor de correo puede enviar la peticin IDENT a travs del tnel slo si los
administradores de los dispositivos A y B agregan un servicio personalizado para
ello (TCP, puerto 113) y configuran directivas que permitan el trfico a travs del
tnel hacia la subred 10.10.10.0/24.
ambos participantes ya tienen certificados RSA emitidos por la autoridad de
certificacin (CA) Verisign y que la direccin de correo electrnico pmason@abc.com
aparece en el certificado local del dispositivo A. (Para obtener ms informacin
sobre la adquisicin y la carga de certificados, consulte Certificados y CRL en la
pgina 24). Para los niveles de seguridad de la fase 1 y fase 2, debe especificar una
propuestas Compatible para la fase 2.
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
NOTA:
La direccin IP del servidor DHCP no se puede especificar mediante WebUI; no

obstante, s se puede especificar mediante comandos CLI.
113
2.
Usuario
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
3.
Direcciones
Address Name: Trusted_network
Zone: Trust
Address Name: Mail_Server
Zone: Untrust
4.
Servicios
Policy > Policy Elements > Services > Custom > New: Introduzca los
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
Policy > Policy Elements > Services > Group > New: Introduzca los
siguientes datos, mueva los siguientes servicios; finalmente, haga clic en OK:
Group Name: Remote_Mail
Group Members << Available Members:
HTTP
FTP
Telnet
Ident
MAIL
POP3
114
5.
VPN
y haga clic en OK:
Gateway Name: To_Mail


enlace:
pre-g2-3des-sha
(o bien)
Certificados


enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
Name: branch_corp
Remote Gateway Tunnel: To_Mail
6.
Ruta
115
NOTA:

7.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (select), Trusted_network
Address Book Entry: (seleccione), Mail_Server
Service: Remote_Mail
Action: Tunnel
VPN Tunnel: branch_corp

en Return para regresar a la pgina de configuracin bsica de directivasy:
Authentication: (seleccione)
Auth Server: Cliente FTP
User: (seleccione), Local Auth User - pmason
WebUI (dispositivo-B)
1.
Interfaces
haga clic en OK:
Zone Name: DMZ
haga clic en OK:
Zone Name: Untrust
2.
Direcciones
Address Name: Mail Server
Zone: DMZ
116
Address Name: branch office
Zone: Untrust
3.
Servicios
Service Name: Ident
Service Timeout:
Policy > Policy Elements > Services > Groups > New: Introduzca los
Ident
MAIL
POP3
4.
VPN
y haga clic en OK:
Gateway Name: To_branch
Dynamic IP Address: (seleccione), Peer ID: pmason@abc.com


enlace:
pre-g2-3des-sha
(o bien)
117
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_branch
Remote Gateway:
Predefined: (seleccione), To_branch
5.
Ruta
6.
Directivas
Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Mail_Server
Address Book Entry: (select), branch_office
Action: Tunnel
VPN Tunnel: corp_branch
CLI (dispositivo-A)
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
118
3.
Direcciones
set address trust trusted network 10.1.1.0/24

set address untrust mail server 3.3.3.5/32
4.
Servicios
set
set
set
set
set
set
set
set
5.
service ident protocol tcp src-port 0-65535 dst-port 113-113

group service remote_mail
group service remote_mail add http
group service remote_mail add ftp
group service remote_mail add telnet
group service remote_mail add ident
group service remote_mail add mail
group service remote_mail add pop3
VPN
set ike gateway to_mail address 2.2.2.2 aggressive local-id pmason@abc.com

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

set ike gateway to_mail cert peer-ca 1
set ike gateway to_mail cert peer-cert-type x509-sig
set vpn branch_corp gateway to_mail sec-level compatible
NOTA:

certificado.
6.
Ruta

NOTA:

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 (dispositivo-B)
1.
Interfaces
set interface ethernet2 zone dmz

119
2.
Direcciones
set address dmz mail server 3.3.3.5/32

set address untrust branch office 10.1.1.0/24
3.
Servicios
set
set
set
set
set
4.

VPN
set ike gateway to_branch dynamic pmason@abc.com aggressive

set vpn corp_branch gateway to_branch tunnel sec-level compatible
(o bien)
Certificados
set ike gateway to_branch dynamic pmason@abc.com aggressive

set ike gateway to_branch cert peer-ca 1
set ike gateway to_branch cert peer-cert-type x509-sig
set vpn corp_branch gateway to_branch sec-level compatible
NOTA:

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
VPN punto a punto basada en rutas, clave manual

En este ejemplo, un tnel con clave manual ofrece un canal de comunicacin
segura entre las oficinas de Tokio y Pars. Las zonas Trust de cada punto se
encuentran en modo NAT. Las direcciones son las siguientes:
120
Tokio:
Interfaz de zona Trust (ethernet1): 10.1.1.1/24
Interfaz de zona Untrust (ethernet3): 1.1.1.1/24
Pars:
Interfaz de zona Trust (ethernet1): 10.2.2.1/24
Interfaz de zona Untrust (ethernet3): 2.2.2.2/24
Las zonas de seguridad Trust y Untrust se encuentran en el dominio de

enrutamiento trust-vr. La interfaz de zona Untrust (ethernet3) acta como interfaz
de salida para el tnel VPN.
Figura 34: VPN punto a punto basada en rutas, clave manual
de seguridad de Pars.

de seguridad de Tokio.
Tokio
Zona
Trust
Pars
Zona
Untrust
Tokio
Zona Trust
eth1, 10.1.1.1/24
Pars
Tokio
Zona
Untrust
Interfaz de salida
Zona Untrust
eth3, 1.1.1.1/24
Puerta de enlace
1.1.1.250
Interfaz de salida
Zona Untrust
eth3, 2.2.2.2/24
Puerta de enlace
2.2.2.250
Internet
Zona
Trust
Pars
Zona Trust
eth1, 10.2.2.1/24
Tnel VPN
Interfaz de tnel
Tunnel.1
Interfaz de tnel
Tunnel.1
Para configurar el tnel, lleve a cabo los siguientes pasos en los dispositivos de
seguridad situados a ambos extremos del tnel:
2. Configurar el tnel VPN, designar su interfaz de salida en la zona Untrust y
asociarla a la interfaz de tnel.
121
WebUI (Tokio)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
2.
Direcciones
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
122
> Advanced: Introduzca los siguientes ajustes avanzados; luego haga clic
en Return para regresar a la pgina de configuracin bsica del tnel de clave
manual:
4.
Rutas
Interface: tunnel.1
Interface: Null
Metric: 10
5.
Directivas
haga clic en OK:
Name: To_Paris
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Paris
Source Address:
Service: ANY
Action: Permit
123
WebUI (Pars)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
VPN Tunnel Name: Paris_Tokyo
Gateway IP: 1.1.1.1
124
en Return para regresar a la pgina de configuracin bsica del tnel de
clave manual:
4.
Rutas
Interface: tunnel.1
Interface: Null
Metric: 10
5.
Directivas
haga clic en OK:
Name: To_Tokyo
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Tokyo
Source Address:
Service: ANY
Action: Permit
125
CLI (Tokio)
1.
Interfaces

2.
Direcciones

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 (Pars)
1.
Interfaces

2.
Direcciones

3.
VPN
set vpn Paris_Tokyo manual 3030 3020 gateway 1.1.1.1 outgoing-interface

4.
Rutas

126
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
VPN punto a punto basada en directivas, clave manual

En este ejemplo, un tnel con clave manual ofrece un canal de comunicacin
segura entre las oficinas de Tokio y Pars utilizando ESP con encriptacin 3DES y
autenticacin 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
Pars:
Interfaz Trust (ethernet1): 10.2.2.1/24
Interfaz Untrust (ethernet3): 2.2.2.2/24
Las zonas de seguridad Trust y Untrust y la zona de tnel Untrust-Tun se encuentran

en el dominio de enrutamiento trust-vr. La interfaz de zona Untrust (ethernet3)
acta como interfaz de salida para el tnel VPN.
Figura 35: VPN punto a punto basada en directivas, clave manual
de seguridad de Pars.

de seguridad de Tokio.
Tokio
Zona
Trust
Pars
Zona
Untrust-Tun
Zona
Untrust
Zona
Untrust
Tokio
Zona Trust
ethernet1, 10.1.1.1/24
Pars
Tokio
Interfaz de salida
Zona Untrust
ethernet3, 2.2.2.2/24
Puerta de enlace
2.2.2.250
Interfaz de salida
Zona Untrust
ethernet3, 1.1.1.1/24
Puerta de enlace
1.1.1.250
Internet
Zona
Untrust-Tun
Zona
Trust
Pars
Zona Trust
ethernet1, 10.2.2.1/24
Tnel VPN
Para configurar el tnel, lleve a cabo los siguientes pasos en los dispositivos de
seguridad situados a ambos extremos del tnel:
1. Asignar direcciones IP a las interfaces fsicas asociadas a las zonas de
seguridad.
127
2. Configurar el tnel 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 trfico VPN circule de forma bidireccional por
el tnel.
WebUI (Tokio)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direcciones
Zone: Trust
Zone: Untrust
128
3.
VPN
VPN Tunnel Name: Tokyo_Paris
Gateway IP: 2.2.2.2
clave manual:
Bind to: Tunnel Zone, Untrust-Tun
4.
Ruta
5.
Directivas
haga clic en OK:
Name: To/From Paris
Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Tokyo_Paris
WebUI (Pars)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
129
Network > Interfaces > Edit (para ethernet3): Introduzca los siguientes
Zone Name: Untrust
2.
Direcciones
Zone: Trust
Zone: Untrust
3.
VPN
VPN Tunnel Name: Paris_Tokyo
Gateway IP: 1.1.1.1
Security Index (HEX Number): 3030 (Local), 3020 (Remote)
clave manual:
4.
Ruta
130
5.
Directivas
haga clic en OK:
Name: To/From Tokyo
Source Address:
Service: ANY
Action: Zona
Tunnel VPN: Paris_Tokyo
CLI (Tokio)
1.
Interfaces

2.
Direcciones

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
set policy top name To/From Paris from untrust to trust paris_office Trust_LAN
save
CLI (Pars)
1.
Interfaces

2.
Direcciones

131
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
set policy top name To/From Tokyo from untrust to trust tokyo_office Trust_LAN
save
Puertas de enlace IKE dinmicas con FQDN

Para un interlocutor IKE que obtenga su direccin IP de forma dinmica, es posible
especificar su nombre de dominio completo (FQDN) en la configuracin local para
la puerta de enlace remota. Por ejemplo, un proveedor de servicios de Internet (ISP)
podra asignar direcciones IP a sus clientes a travs del protocolo DHCP. El ISP toma
direcciones de un amplio conjunto de direcciones y las asigna cuando los clientes se
conectan en lnea. Aunque el interlocutor IKE posee un FQDN que no vara, tiene
una direccin IP que cambia de forma impredecible. El interlocutor IKE dispone de
tres mtodos para mantener una asignacin DNS (Domain Name System) entre su
FQDN y su direccin IP asignada de forma dinmica (un proceso denominado DNS
dinmico).
132
Si el interlocutor IKE remoto es un dispositivo de seguridad, el administrador

puede avisar manualmente al servidor DNS para que actualice su asignacin
entre FQDN y direccin IP cada vez que el dispositivo de seguridad reciba una
direccin 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 dinmico, dicho software puede
notificar al servidor DNS sus cambios de direccin para que el servidor
actualice su tabla de asignacin entre FQDN y direccin IP.
Si el interlocutor IKE remoto es un dispositivo de seguridad o cualquier otro tipo

de dispositivo terminal VPN, un host ubicado detrs de l puede ejecutar un
programa de actualizacin automtica entre FQDN y direccin IP que avise al
servidor DNS de los cambios de direccin.
Figura 36: Interlocutor IKE con direccin IP dinmica

Interlocutor IKE
Dispositivo de seguridad local

Internet
www.jnpr.net
Tnel VPN
1. El servidor DHCP toma la direccin 1.1.1.202 de su conjunto de

direcciones IP y la asigna al interlocutor IKE.
1.1.1.202 = www.jnpr.net
Conjunto de direcciones IP
2. El interlocutor IKE notifica al servidor DNS la nueva direccin

para que ste pueda actualizar su tabla de asignacin entre
FQDN y direccin IP.
1.1.1.10
1.1.7.9
Servidor DHCP
Servidor DNS
Sin necesidad de conocer la direccin IP actual de un interlocutor IKE remoto, es

posible configurar un tnel VPN AutoKey IKE que conecte con dicho interlocutor
utilizando su FQDN en lugar de una direccin IP.
Alias
Tambin es posible utilizar un alias para el FQDN del interlocutor IKE remoto si el
servidor DNS al que consulta el dispositivo de seguridad local devuelve slo una
direccin IP. Si el servidor DNS devuelve varias direcciones IP, el dispositivo local
utilizar la primera que reciba. Como no existe ninguna garanta sobre el orden de
aparicin de las direcciones en la respuesta del servidor DNS, es posible que el
dispositivo de seguridad local utilice la direccin IP incorrecta y, por tanto, las
negociaciones IKE podran fracasar.
Figura 37: Respuestas mltiples de DNS que derivan en el xito o el fracaso de la negociacin IKE
El dispositivo utiliza
esta direccin IP.
El dispositivo de seguridad local desea

establecer un tnel VPN IKE con su
interlocutor remoto. Utiliza www.jnpr.net
como direccin de puerta de enlace remota.
Interlocutor IKE remoto
Consulta DNS: www.jnpr.net = IP ?
Servidor DNS
Respuesta DNS:
www.jnpr.net = 1.1.1.202
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
o bien
1.1.1.20, las negociaciones
IKE fracasan.
133
Ajuste del interlocutor AutoKey IKE con FQDN

En este ejemplo, un tnel VPN AutoKey IKE que utiliza un secreto previamente
una conexin segura entre dos oficinas de Tokio y Pars. La oficina de Pars tiene
una direccin IP asignada de forma dinmica, por lo que la oficina de Tokio utiliza
el FQDN del interlocutor remoto (www.nspar.com) como direccin de la puerta de
enlace remota en su configuracin de tnel VPN.
La configuracin que aparece en la Figura 38 corresponde a un tnel VPN basado
en rutas. Para los niveles de seguridad de las fases 1 y 2, debe especificar una
propuestas predefinido Compatible para la fase 2. Todas las zonas se encuentran
en trust-vr.
Figura 38: Interlocutor AutoKey IKE con FQDN
Tokio
Zona
Trust

Tokio
Pars
Zona
Untrust
Zona
Untrust
Tokio
Zona Trust
ethernet1, 10.1.1.1/24
Interfaz de salida
Zona Untrust
ethernet3, IP y puerta de
enlace a travs del
protocolo DHCP
www.nspar.com
Interfaz de salida
Zona Untrust
ethernet3, 1.1.1.1/24
Puerta de enlace
1.1.1.250
Internet
Pars
Zona
Trust
Pars
Zona Trust
ethernet1, 10.2.2.1/24
Tnel VPN
Interfaz Tunnel: tunnel.1
Puerta de enlace remota: www.nspar.com
Interfaz Tunnel: tunnel.1

Puerta de enlace remota: 1.1.1.1
La configuracin de un tnel AutoKey IKE basado en rutas mediante un secreto

previamente compartido o certificados implica los siguientes pasos:
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 tnel VPN, designar su interfaz de salida en la zona Untrust,
asociarla a la interfaz de tnel y configurar su ID de proxy.
134

6. Definir directivas para la circulacin del trfico entre ambos sitios.
certificados, consulte Criptografa de claves pblicas en la pgina 19).
WebUI (Tokio)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
IP Address/Netmask: 1.1.1.1
clic en OK:
2.
Direcciones
Zone: Trust
135
Zone: Untrust
3.
VPN
y haga clic en OK:
Static IP Address: (seleccione), IP Address/Hostname: www.nspar.com


enlace:
pre-g2-3des-sha
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
Remote Gateway:
136

IKE:
Service: ANY
4.
Rutas
NOTA:

Interface: tunnel.1
Interface: Null
Metric: 10
5.
Directivas
haga clic en OK:
Name: To_Paris
Destination Address: Paris_Office
Service: ANY
Action: Permit
137
Policies > Policy (From: Untrust, To: Trust) > New Policy: Introduzca los
Name: From_Paris
Source Address: Paris_Office
Service: ANY
Action: Permit
WebUI (Pars)
1.
Nombre de host y nombre de dominio
Network > DNS: Introduzca los siguientes datos y haga clic en Apply:
Host Name: www
Domain Name: nspar.com
2.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
3.
Direcciones
Zone: Trust
138
Zone: Untrust
4.
VPN
y haga clic en OK:


enlace:
pre-g2-3des-sha
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Entrust
Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway:
139

IKE:
Service: ANY
5.
Rutas
Interface: tunnel.1
Interface: Null
Metric: 10
6.
Directivas
haga clic en OK:
Name: To_Tokyo
Destination Address: Tokyo_Office
Service: ANY
Action: Permit
haga clic en OK:
Name: From_Tokyo
Source Address: Tokyo_Office
Service: ANY
Action: Permit
140
CLI (Tokio)
1.
Interfaces

2.
Direcciones

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
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
NOTA:

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 (Pars)
1.
Nombre de host y nombre de dominio
set hostname www

set domain nspar.com
141
2.
Interfaces

set interface ethernet3 ip dhcp-client enable
3.
Direcciones

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
Sitios VPN con direcciones superpuestas

Como el rango de direcciones IP privadas es relativamente pequeo, es bastante
probable que las direcciones de las redes protegidas de dos interlocutores VPN se
superpongan. Para el trfico VPN bidireccional entre dos entidades finales con
direcciones superpuestas, los dispositivos de seguridad de los dos extremos del
tnel deben aplicar una traduccin de direcciones de red de origen y de destino
(NAT-src y NAT-dst) al trfico VPN que circule entre ellos.
NOTA:
142
Un espacio de direcciones superpuesto se produce cuando los rangos de

direcciones IP de dos redes coinciden parcial o totalmente.
Para NAT-src, las interfaces situadas a ambos extremos del tnel deben poseer
direcciones IP en subredes exclusivas entre s, con un conjunto de direcciones IP
dinmicas (DIP) en cada una de dichas subredes. Las directivas que regulan el
trfico 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.
NOTA:
El rango de direcciones en un conjunto de DIP debe estar en la misma subred que

la interfaz de tnel, pero no es necesario que el conjunto incluya la direccin IP de
la interfaz o cualquier otra direccin MIP o VIP que pueda encontrarse en dicha
subred. Para las interfaces de la zona de seguridad, es posible definir una
direccin IP extendida y un conjunto de DIP auxiliar en una subred distinta de la
de la direccin IP de la interfaz. Para obtener ms informacin, consulte Uso de
DIP en una subred distinta en la pgina 2-146.
Hay dos posibilidades para aplicar NAT-dst al trfico VPN entrante:
NAT-dst basada en directivas: una directiva puede aplicar NAT-dst para traducir
el trfico VPN entrante y convertirlo en una direccin que se encuentre en la
misma subred que la interfaz de tnel (pero no en el mismo rango que el
conjunto de DIP local utilizado para el trfico VPN saliente) o en una direccin
de otra subred a la que el dispositivo de seguridad tenga una entrada en su
tabla de rutas. (Para encontrar informacin acerca de los aspectos que rodean a
la configuraciin de NAT-dst, consulte Enrutamiento para NAT-Dst en la
pgina 8-32.)
Direccin IP asignada (MIP): una directiva puede hacer referencia a una MIP
como direccin de destino. La MIP utiliza una direccin que se encuentra en la
misma subred que la interfaz de tnel (pero no en el mismo rango que el
conjunto de DIP local utilizado para el trfico VPN de salida). (Para encontrar
informacin acerca de las MIP, consulte Direcciones IP asignadas en la
pgina 8-63.)
El trfico VPN entre dos puntos con direcciones superpuestas requiere la traduccin
de direcciones en ambos sentidos. Como la direccin de origen del trfico saliente
no puede ser la misma que la direccin de destino del trfico entrante (la direccin
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 simtricas.
Si desea que el dispositivo de seguridad realice una traduccin de direcciones de
origen y destino para el trfico VPN direccional que atraviese el mismo tnel,
dispone de las dos opciones siguientes:
Puede definir una ID de proxy para una configuracin VPN basada en

directivas. Si hace referencia de forma especfica a un tnel VPN en una
directiva, el dispositivo de seguridad deriva una ID de proxy a partir de los
componentes de la directiva que haga referencia a dicho tnel. El dispositivo de
seguridad 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 tnel VPN al que se haga referencia en
una directiva, el dispositivo de seguridad aplicar la ID de proxy definida por el
usuario y no la ID de proxy derivada a partir de la directiva.
143
NOTA:
Una ID de proxy es un tipo de acuerdo entre interlocutores IKE para permitir el

trfico a travs de un tnel si el trfico cumple una tupla especificada de direccin
local, direccin remota y servicio.
Puede utilizar una configuracin de tnel VPN basada en rutas, que debe tener
una ID de proxy definida por el usuario. Con una configuracin de tnel VPN
basada en rutas, no se hace referencia de forma especfica a un tnel 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 tnel que, a su vez, est asociada a un tnel VPN. Como el tnel
VPN no est asociado directamente a ninguna directiva a partir de la que se
pueda derivar una ID de proxy de la direccin de origen, la direccin de destino
y el servicio, habr que definir una ID de proxy de forma manual. (Recuerde
que una configuracin VPN basada en rutas tambin permite crear mltiples
directivas que hagan uso de un nico tnel VPN; es decir, una SA de fase 2
sencilla).
Examine las direcciones de la Figura 39, en la que se ejemplifica un tnel VPN entre
dos puntos con espacios de direcciones superpuestas.
Figura 39: Superposicin de direcciones en ubicaciones de interlocutores
Tnel VPN
Dispositivo A
Espacio de
direcciones
interno
10.1.1.0/24
Dispositivo B
tunnel.1
10.10.1.1/24
tunnel.2
10.20.2.1/24
Espacio de
direcciones
interno
10.1.1.0/24
Direcciones en directivas
10.10.1.2 10.10.1.2 DIP
10.10.1.5 (a 10.1.1.5) MIP
MIP 10.20.2.5 (a 10.1.1.5)

DIP 10.20.2.2 10.20.2.2
Si los dispositivos de seguridad de la Figura 39 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 ID de proxy:
Dispositivo A
Dispositivo B
Local
Remota
Servicio
Salida
10.10.1.2/32
10.20.2.5/32
Any
Entrada
10.10.1.5/32
10.20.2.2/32
Any
Local
Remota
Servicio
Entrada
10.20.2.5/32
10.10.1.2/32
Any
Salida
10.20.2.2/32
10.10.1.5/32
Any
Como se muestra en la tabla, existen dos ID de proxy: una para el trfico VPN
entrante y otra para el saliente. Cuando el dispositivo A enva trfico 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 (SA) de fase 1 y fase 2. La
SA de fase 2 da como resultado la ID de proxy de salida anterior para el dispositivo
A y la ID de proxy de entrada para el dispositivo B.
144
Si el dispositivo B enva trfico al dispositivo A, la consulta de directivas para el

trfico 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 ID de proxy resultantes se indican en la tabla
anterior como ID de proxy de entrada para el dispositivo A e ID de proxy de salida
para el dispositivo B. Hay dos SA de fase 2 (dos tneles VPN) porque las direcciones
son asimtricas y requieren ID de proxy distintas.
Para crear un solo tnel para trfico VPN bidireccional, puede definir las siguientes
ID de proxy con direcciones cuyo alcance incluya las direcciones de origen y
destino traducidas en cada extremo del tnel:
Dispositivo A
Local
Dispositivo B
Remota
Servicio
Local
10.10.1.0/24 10.20.2.0/24 Any
Remota
Servicio
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 ID de proxy anteriores comprenden las direcciones que aparecen tanto en el

trfico VPN entrante como en el saliente que circule entre ambos puntos. La
direccin 10.10.1.0/24 incluye el conjunto de DIP 10.10.1.2 10.10.1.2 y la
direccin MIP 10.10.1.5. Asimismo, la direccin 10.20.2.0/24 incluye el conjunto de
DIP 10.20.2.2 10.20.2.2 y la direccin MIP 10.20.2.5. Las ID de proxy anteriores
son simtricas, es decir, la direccin local del dispositivo A es la direccin remota
del dispositivo B y viceversa. Si el dispositivo A enva trfico al dispositivo B, la SA
de fase 2 y la ID de proxy tambin se aplican al trfico enviado desde el dispositivo
B al dispositivo A. Por lo tanto, slo se requiere una nica SA de fase 2 (es decir, un
nico tnel VPN) para el trfico bidireccional entre los dos puntos.
NOTA:
La direccin 0.0.0.0/0 incluye todas las direcciones IP y, por tanto, las direcciones
del conjunto de DIP y MIP.
Para crear un tnel VPN para el trfico 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 tnel debe ser (IP local) 0.0.0.0/0 (IP remota) 0.0.0.0/0 tipo de
servicio. Si desea utilizar direcciones ms restrictivas en la ID de proxy, las
direcciones para NAT-src y NAT-dst debern encontrarse en la misma subred.
En este ejemplo vamos a configurar un tnel VPN entre el dispositivo A situado en
el sitio corporativo y el dispositivo 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 direccin de origen del trfico VPN saliente y NAT-dst para
traducir la direccin de destino del trfico 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.
145
Para obtener ms informacin sobre la traduccin de direcciones de red de origen

y destino (NAT-src y NAT-dst), consulte el Volumen 8: Traduccin de direcciones.
NOTA:
Las configuraciones de ambos extremos del tnel utilizan los siguientes parmetros:
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 Negociacin de tnel en la pgina 9).
La interfaz de salida del dispositivo-A en el sitio corporativo es ethernet3, que tiene
la direccin IP 1.1.1.1/24 y est asociada a la zona Untrust. El dispositivo-B, en la
sucursal, utiliza esta direccin como puerta de enlace IKE remota.
La interfaz de salida del dispositivo-B en la sucursal es ethernet3, que tiene la
direccin IP 2.2.2.2/24 y est asociada a la zona Untrust. El dispositivo-A, en el sitio
corporativo, utiliza esta direccin como puerta de enlace IKE remota.
La interfaz de zona Trust de ambos dispositivos de seguridad es ethernet1 y tiene la
direccin IP 10.1.1.1/24. Todas las zonas de ambos dispositivos de seguridad se
encuentran en el dominio de enrutamiento trust-vr.
Figura 40: Interfaz de tnel con NAT-Src y NAT-Dst
configuradas en el
dispositivo-A en la sucursal.
A
Zona Trust
servidorA
10.1.1.5
A
Zona Trust
Zona Untrust
Puerta de enlace
2.2.2.250
Puerta de
enlace
Dispositivo A
Internet
Dispositivo B
servidorB
10.1.1.5
Red B
10.1.1.0/24
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
DIP 6 10.20.1.2 10.20.1.2

NAT-Dst 10.20.1.5 > 10.1.1.5
Red A
Los usuarios de la red A pueden acceder al servidor B. Los usuarios de la red B

pueden acceder al servidor A.
Todo el trfico circula a travs del tnel VPN entre los dos puntos.
Dispositivo A
Dispositivo B
server A
Zona Untrust
Red A
10.1.1.0/24
146

configuradas en el
dispositivo-B en la sucursal 1.
Tnel VPN
vpn1
servidorB
Red B
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
Fixed IP: (seleccione)
2.
DIP
Network > Interfaces > Edit (para tunnel.1) > DIP > New: Introduzca los
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)
3.
Direcciones
Address Name: corp
Zone: Trust
Address Name: virtualA
Zone: Trust
147
Address Name: branch1
Zone: Untrust
Address Name: servidorB
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
NOTA:
La interfaz de salida no necesita estar en la misma zona a la que est asociada la

interfaz del tnel, aunque en este caso se encuentran en la misma zona.
IKE:
Service: ANY
5.
Rutas
Interface: tunnel.1
148
Interface: Null
Metric: 10
6.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), corp
Address Book Entry: (seleccione), servidorB
Service: FTP
Action: Permit

NAT:
Source Translation: (seleccione)
DIP On: 5 (10.10.1.210.10.1.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), branch1
Address Book Entry: (seleccione), virtualA
Service: FTP
Action: Permit

NAT:
Destination Translation: (seleccione)
Translate to IP: (seleccione), 10.1.1.5
Map to Port: (anule la seleccin)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
149

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
2.
DIP
ID: 6
3.
Direcciones
Address Name: branch1
Zone: Trust
Address Name: virtualB
Zone: Trust
Address Name: corp
Zone: Untrust
150
Address Name: servidorA
Zone: Untrust
4.
VPN
VPN Name: vpn1
Gateway Name: corp

IKE:
Service: ANY
NOTA:

5.
Rutas
Interface: tunnel.1
151
Interface: Null
Metric: 10
6.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), servidorA
Service: FTP
Action: Permit

NAT:
DIP on: 6 (10.20.1.210.20.1.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), virtualB
Service: FTP
Action: Permit

NAT:
Translate to IP: 10.1.1.5
Map to Port: (anule la seleccin)
CLI (dispositivo-A)
1.
Interfaces

set interface tunnel.1 ip 10.10.1.1/24
152
2.
DIP
set interface tunnel.1 dip 5 10.10.1.2 10.10.1.2

3.
Direcciones
set
set
set
set
4.
address trust corp 10.1.1.0/24

address trust virtualA 10.10.1.5/32
address untrust branch1 10.20.1.2/32
address untrust servidorB 10.20.1.5/32
VPN
set ike gateway branch1 address 2.2.2.2 outgoing-interface ethernet3 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
NOTA:

5.
Rutas

6.
Directivas
set policy top from trust to untrust corp servidorB 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
CLI (dispositivo-B)
1.
Interfaces

2.
DIP

3.
Direcciones
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 servidorA 10.10.1.5/32
4.
VPN
set ike gateway corp address 1.1.1.1 outgoing-interface ethernet3 preshare

set vpn vpn1 gateway corp sec-level compatible
153
NOTA:

5.
Rutas

6.
Directivas
set policy top from trust to untrust branch1 servidorA 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
VPN en modo transparente

Si las interfaces de los dispositivos de seguridad se encuentran en modo
transparente (es decir, si no tienen direcciones IP y operan en la capa 2 del modelo
OSI), puede utilizar la direccin 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 tnel VPN hace referencia a una zona de salida. De forma predeterminada, un
tnel utiliza la zona V1-Untrust como su zona de salida. Si tiene mltiples interfaces
asociadas a la misma zona de salida, el tnel VPN puede utilizar cualquiera de ellas.
NOTA:
El modelo OSI es un modelo estndar 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.
En el momento de esta publicacin, un dispositivo de seguridad cuyas interfaces
se encuentren en modo transparente slo admite VPN basadas en directivas. Para
obtener ms informacin acerca del modo transparente, consulte Modo
transparente en la pgina 2-79.
No es necesario que las interfaces de ambos dispositivos de seguridad se
encuentren en modo transparente. Las interfaces del dispositivo situado a un
extremo del tnel pueden encontrarse en modo transparente, y las del otro
dispositivo pueden encontrarse en modo NAT o de rutas.
En este ejemplo, vamos a configurar un tnel VPN AutoKey IKE basado en
directivas entre dos dispositivos de seguridad cuyas interfaces operan en modo
transparente.
NOTA:
154
No es necesario que las interfaces de ambos dispositivos de seguridad se

encuentren en modo transparente. Las interfaces del dispositivo situado a un
extremo del tnel pueden encontrarse en modo transparente, y las del otro
dispositivo pueden encontrarse en modo NAT o de rutas.
Los elementos clave para la configuracin de los dispositivos de seguridad situados

a ambos extremos del tnel son stos:
Elementos de
configuracin
Dispositivo A
Dispositivo B
Zona V1-Trust
Interfaz: ethernet1, 0.0.0.0/0

(habilitar administracin para el
administrador local)

(habilitar administracin para el
administrador local)
Zona V1-Untrust
Interfaz VLAN1
Direccin IP: 1.1.1.1/24

IP de administracin: 1.1.1.21

IP de administracin: 2.2.2.3
Direcciones
lan_local: 1.1.1.0/24 en V1-Untrust

lan_interlocutor: 2.2.2.0/24 en V1-Untrust
lan_local: 2.2.2.0/24 en V1-Trust

lan_interlocutor: 1.1.1.0/24 en V1-Untrust
Puerta de enlace IKE
gw1, 2.2.2.2, clave precompartida

h1p8A24nG5,
seguridad: compatible
gw1, 1.1.1.1, clave precompartida

h1p8A24nG5, seguridad: compatible
Tnel VPN
Directivas
lan_local -> lan_interlocutor, cualquier

servicio, vpn1
lan_interlocutor -> lan_local, cualquier
servicio, vpn1
lan_local -> lan_interlocutor, cualquier

servicio, vpn1
lan_interlocutor -> lan_local, cualquier
servicio, vpn1
Enrutador externo
Direccin IP: 1.1.1.250
Ruta
0.0.0.0/0, usar interfaz VLAN1

a puerta de enlace 1.1.1.250
0.0.0.0/0, usar interfaz VLAN1

a puerta de enlace 2.2.2.250
1.Puede separar el trfico VPN del administrativo utilizando la direccin IP de administracin para recibir el trfico
administrativo y la direccin VLAN1 para terminar el trfico VPN.
La configuracin de un tnel AutoKey IKE basado en directivas para un dispositivo

de seguridad cuyas interfaces se encuentren en modo transparente implica los
siguientes pasos:
1. Eliminar las direcciones IP de las interfaces fsicas y asociarlas a las zonas de
seguridad de capa 2.
2. Asignar una direccin IP y una direccin IP de administracin a la interfaz
VLAN1.
de direcciones para las zonas V1-Trust y V1-Untrust.
4. Configurar el tnel VPN y designar su zona de salida como zona V1-Untrust.
5. Introducir una ruta predeterminada que conduzca al enrutador externo en
trust-vr.
VPN en modo transparente 155
1.
NOTA:
Interfaces
El desplazamiento de la direccin IP VLAN1 a una subred distinta hace que el

dispositivo de seguridad elimine todas las rutas relacionadas con la interfaz
VLAN1 anterior. A la hora de configurar un dispositivo de seguridad a travs de la
WebUI, la estacin de trabajo debe acceder a la primera direccin VLAN1 y
encontrarse en la misma subred que la direccin nueva. Despus de cambiar la
direccin VLAN1, deber modificar la direccin IP de su estacin de trabajo para
que se encuentre en la misma subred que la nueva direccin VLAN1. Es posible
que tambin tenga que reubicar su estacin de trabajo en una subred fsicamente
adyacente al dispositivo de seguridad.
Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes
Manage IP: 1.1.1.2
Management Services: WebUI, Telnet, Ping
NOTA:
Se deben habilitar las opciones de administracin 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 direccin IP de administracin de VLAN1. Si la
administracin a travs de la WebUI an no est habilitada en las interfaces de
zona V1-Trust y VLAN1, no ser posible acceder al dispositivo de seguridad a
travs de la WebUI para realizar estos ajustes. En su lugar, deber habilitar la
administracin mediante WebUI en estas interfaces a travs de una conexin de
consola.
haga clic en Apply:
Management Services: WebUI, Telnet
Other Services: Ping

Zone Name: V1-Trust
haga clic en OK:
Zone Name: V1-Untrust
2.
Direcciones
Address Name: lan_local
Zone: V1-Trust
156
Address Name: lan_interlocutor
Zone: V1-Untrust
3.
VPN
y haga clic en OK:
Gateway Name: gw1
Outgoing Zone: V1-Untrust
VPN Name: vpn1
Remote Gateway:
Predefined: (seleccione), gw1
4.
Ruta
Interface: VLAN1 (VLAN)
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan_local
Address Book Entry: (seleccione), lan_interlocutor
Service: ANY
Action: Zona
Tunnel VPN: vpn1
1.
NOTA:
Interfaces
El desplazamiento de la direccin IP VLAN1 a una subred distinta hace que el

dispositivo de seguridad elimine todas las rutas relacionadas con la interfaz
VLAN1 anterior. A la hora de configurar un dispositivo de seguridad a travs de la
WebUI, la estacin de trabajo debe acceder a la primera direccin VLAN1 y
encontrarse en la misma subred que la direccin nueva. Despus de cambiar la
direccin VLAN1, deber modificar la direccin IP de su estacin de trabajo para
que se encuentre en la misma subred que la nueva direccin VLAN1. Es posible
que tambin tenga que reubicar su estacin de trabajo en una subred fsicamente
adyacente al dispositivo de seguridad.
Network > Interfaces > Edit (para la interfaz VLAN1): Introduzca los siguientes
Manage IP: 2.2.2.3
Management Services: WebUI, Telnet, Ping
NOTA:
Si la administracin a travs de la WebUI an no est habilitada en las interfaces

de zona V1-Trust y VLAN1, no ser posible acceder al dispositivo de seguridad a
travs de la WebUI para realizar estos ajustes. En su lugar, deber habilitar la
administracin mediante WebUI en estas interfaces a travs de una conexin de
consola.
haga clic en Apply:
Management Services: WebUI, Telnet
Other Services: Ping

Zone Name: V1-Trust
haga clic en OK:
Zone Name: V1-Untrust
2.
Direcciones
Address Name: lan_local
Zone: V1-Trust
158
Address Name: lan_interlocutor
Zone: V1-Untrust
3.
VPN
y haga clic en OK:
Gateway Name: gw1
Outgoing Zone: V1-Untrust
VPN Name: vpn1
Remote Gateway:
Predefined: (seleccione), gw1
4.
Ruta
Interface: VLAN1 (VLAN)
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan_local
Address Book Entry: (seleccione), lan_interlocutor
Service: ANY
Action: Zona
Tunnel VPN: vpn1
CLI (dispositivo-A)
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
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
NOTA:
Se deben habilitar las opciones de administracin 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 direccin IP de administracin de VLAN1.
2.
Direcciones
set address v1-trust lan_local 1.1.1.0/24

set address v1-untrust lan_interlocutor 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
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 lan_local lan_interlocutor any tunnel vpn
vpn1
set policy top from v1-untrust to v1-trust lan_interlocutor lan_local any tunnel vpn
vpn1
save
CLI (dispositivo-B)
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
160
2.
Direcciones
set address v1-trust lan_local 2.2.2.0/24

set address v1-untrust lan_interlocutor 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 lan_local lan_interlocutor any tunnel vpn
vpn1
set policy top from v1-untrust to v1-trust lan_interlocutor lan_local any tunnel vpn
vpn1
save
162
Captulo 5
Redes privadas virtuales de acceso

telefnico
Los dispositivos de seguridad de Juniper Networks pueden admitir conexiones de
red privada virtual (VPN) de acceso telefnico. Puede configurar un dispositivo de
seguridad con una direccin IP esttica para asegurar un tnel IPSec a un cliente
NetScreen-Remote o a otro dispositivo de seguridad con una direccin IP dinmica.
Acceso telefnico en la pgina 164
VPN de acceso telefnico basada en directivas, AutoKey IKE en la

pgina 165
VPN de acceso telefnico basada en rutas, interlocutor dinmico en la

pgina 170
VPN de acceso telefnico basada en directivas, interlocutor dinmico en

la pgina 177
Directivas bidireccionales para usuarios de VPN de acceso telefnico en

la pgina 184
Identificacin IKE de grupo en la pgina 188
Identificacin IKE de grupo con certificados en la pgina 189
Tipos de identificacin IKE ASN1-DN Wildcard y Container en la

pgina 191
Creacin de una identificacin IKE de grupo (certificados) en la

pgina 194
Configuracin de una ID IKE de grupo con claves previamente

compartidas en la pgina 198
Identificacin IKE compartida en la pgina 204
163
Acceso telefnico
Es posible configurar tneles para usuarios de VPN de acceso telefnico de forma
individual o reuniendo varios usuarios en un grupo VPN de acceso telefnico, en
cuyo caso slo tendr que configurar un tnel. Tambin es posible crear un usuario
de identificacin IKE de grupo, lo que permite definir un usuario cuya identificacin
IKE se utilizar como parte de todas las ID IKE de los usuarios IKE de acceso
telefnico. Esto permite ahorrar bastante tiempo cuando hay grandes grupos de
usuarios de acceso telefnico, puesto que no tendr que configurar a cada usuario
IKE individualmente.
NOTA:
Para obtener ms informacin sobre la creacin de grupos de usuarios IKE,

consulte Usuarios y grupos de usuarios IKE en la pgina 9-69. Para obtener ms
informacin sobre la funcin de identificacin IKE de grupo, consulte
Identificacin IKE de grupo en la pgina 188.
Si el cliente de acceso telefnico admite una direccin IP interna virtual, como hace
el dispositivo NetScreen-Remote, tambin puede crear un tnel AutoKey IKE de
VPN de acceso telefnico para interlocutor dinmico (con clave o certificados
previamente compartidos). Puede configurar una puerta de enlace segura
Juniper Networks con una direccin IP esttica para asegurar un tnel IPSec a un
cliente NetScreen-Remote o a otro dispositivo de seguridad con una direccin IP
dinmica.
NOTA:
Para obtener ms informacin sobre las opciones de VPN disponibles, consulte

Seguridad del protocolo de Internet en la pgina 1. Si desea obtener ayuda para
elegir entre las distintas opciones, consulte Directrices para las redes privadas
virtuales en la pgina 49.
Puede configurar tneles VPN basados en directivas para usuarios de acceso
telefnico a VPN. En el caso de un cliente dinmico de acceso telefnico, puede
configurar una VPN basada en directivas o basada en rutas. Dado que el cliente
dinmico de acceso telefnico puede admitir una direccin IP interna virtual, al
igual que el dispositivo NetScreen, puede configurar una entrada de la tabla de
enrutamiento a esa direccin interna virtual a travs de una interfaz de tnel
designada. De esta forma podr configurar un tnel VPN basado en rutas entre el
dispositivo de seguridad y el cliente.
NOTA:
Un cliente dinmico de acceso telefnico es un cliente de acceso telefnico que

admite una direccin IP interna virtual.
Un interlocutor dinmico de acceso telefnico es prcticamente idntico a un
interlocutor dinmico punto a punto, excepto por el hecho de que la direccin IP
interna del cliente de acceso telefnico es una direccin virtual.
164
Acceso telefnico
Captulo 5: Redes privadas virtuales de acceso telefnico
VPN de acceso telefnico basada en directivas, AutoKey IKE

En este ejemplo, un tnel AutoKey IKE que utiliza una clave previamente
compartida o un par de certificados (uno por cada extremo del tnel) proporciona
el canal de comunicacin segura entre el usuario IKE Wendy y el servidor UNIX. El
tnel, una vez ms, utiliza ESP con encriptacin 3DES y autenticacin SHA-1.
NOTA:

ambos participantes ya disponen de certificados. Para obtener ms informacin
sobre los certificados, consulte Certificados y CRL en la pgina 24.
Para configurar el tnel AutoKey IKE utilizando AutoKey IKE con una clave
previamente compartida o con certificados, es necesario realizar la siguiente
configuracin 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 direccin 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 telefnico acceda a UNIX.
Figura 41: VPN de acceso telefnico basada en directivas, AutoKey IKE

Interfaz de salida
Zona Untrust
ethernet3, 1.1.1.1/24
Puerta de enlace 1.1.1.250
Usuario remoto Wendy

NetScreen-Remote
Oficina corporativa
Zona Trust
ethernet1, 10.1.1.1/24
Zona Untrust
Servidor UNIX
10.1.1.5
Internet
LAN
Tnel VPN
Zona
Untrust
Zona
Trust
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 informacin sobre cmo obtener y cargar certificados, consulte Certificados
y CRL en la pgina 24.) Para los niveles de seguridad de las fases 1 y 2, debe
especificar la propuesta de fase 1 (pre-g2-3des-sha para el mtodo de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas predefinido Compatible para la fase 2.
Acceso telefnico
165
WebUI
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direccin
Address Name: UNIX
Zone: Trust
3.
Usuario
en OK:
User Name: Wendy
Status: Enable (seleccione)
IKE User: (seleccione)
Simple Identity: (seleccione)
IKE Identity: wparker@email.com
4.
VPN
y haga clic en OK:
Gateway Name: Wendy_NSR
Dialup User: (seleccione), User: Wendy
166
Acceso telefnico
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Wendy_UNIX
Remote Gateway:
Predefined: (seleccione), Wendy_NSR
(o bien)
PRECAUCIN: El modo dinmico es poco seguro. Por razones de limitacin de
protocolo, el modo principal IKE junto con la clave previamente compartida (PSK)
no se puede utilizarse en los usuarios VPN de acceso telefnico. Adems, se
recomienda nunca utilizar el modo dinmico debido a que dicho modo tiene
problemas de seguridad inherentes. Por consecuencia, se recomienda firmemente
configurar a los usuarios VPN de acceso telefnico con los certificados PKI y en
modo principal.

enlace:
pre-g2-3des-sha
5.
Ruta
Acceso telefnico
167
6.
Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Dial-Up VPN
Address Book Entry: (seleccione), UNIX
Service: ANY
Action: Tunnel
Tunnel VPN: Wendy_UNIX
Modify matching bidirectional VPN policy: (anule la seleccin)
CLI
1.
Interfaces

2.
Direccin
set address trust unix 10.1.1.5/32

3.
Usuario
set user wendy ike-id u-fqdn wparker@email.com

4.
VPN
Certificados
set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3

set ike gateway wendy_nsr cert peer-ca 1
set ike gateway wendy_nsr cert peer-cert-type x509-sig
set vpn wendy_unix gateway wendy_nsr sec-level compatible
NOTA:

utilice el siguiente comando: get pki x509 list ca-cert.
(o bien)
PRECAUCIN: El modo dinmico es poco seguro. Por razones de limitacin de
protocolo, el modo principal IKE junto con la clave previamente compartida (PSK)
no se puede utilizarse en los usuarios VPN de acceso telefnico. Adems, se
recomienda nunca utilizar el modo dinmico debido a que dicho modo tiene
problemas inherentes de poca seguridad. Por consecuencia, se recomienda
firmemente configurar a los usuarios VPN de acceso telefnico con los certificados
PKI y en modo principal.
set ike gateway wendy_nsr dialup wendy aggressive outgoing-interface ethernet3
set vpn wendy_unix gateway wendy_nsr sec-level compatible
168
Acceso telefnico
5.
Ruta

6.
Directiva
set policy top from untrust to trust Dial-Up VPN unix any tunnel vpn wendy_unix
save
Editor de directivas de seguridad

1. Haga clic en Options > Secure > Specified Connections.
2. Haga clic en Add a new connection y escriba UNIX junto al icono de nueva
conexin que aparecer en pantalla.
3. Configure las opciones de conexin:
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 MS, que se ubica a la izquierda del icono de UNIX para
ampliar la directiva de la conexin.
5. Haga clic en My Identity: Siga uno de estos dos pasos:
Haga clic en Pre-shared Key > Enter Key: Escriba h1p8A24nG5, despus
haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba wparker@email.com.
(o bien)
Seleccione un certificado de la lista desplegable para seleccionar el
certificado.
ID Type: (seleccione E-mail Address)
NOTA:
La direccin de correo electrnico del certificado aparecer automticamente en

el campo del identificador.
6. Haga clic en el icono Security Policy, despus seleccione Aggressive Mode y
desactive Enable Perfect Forward Secrecy (PFS).
7. Haga clic en el smbolo MS situado a la izquierda del icono Security Policy y
despus en el smbolo MS situado a la izquierda de Authentication (Phase 1) y
de Key Exchange (Phase 2) para ampliar an ms la directiva.
Acceso telefnico
169
8. Haga clic en Authentication (Phase 1) > Proposal 1: Seleccione el siguiente

mtodo y algoritmos de autenticacin:
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)
Hash Alg: SHA-1
Encapsulation: Tunnel
10. Haga clic en Key Exchange (Phase 2) > Create New Proposal: Seleccione los
siguientes protocolos IPSec:
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
13. Haga clic en File > Save Changes.
VPN de acceso telefnico basada en rutas, interlocutor dinmico

En este ejemplo, un tnel VPN conecta de forma segura al usuario situado tras el
dispositivo NetScreen-Remote a la interfaz de la zona Untrust del dispositivo de
seguridad que protege el servidor de correo en la zona DMZ. La interfaz de la zona
Untrust tiene una direccin IP esttica. El cliente NetScreen-Remote tiene una
direccin IP externa asignada dinmicamente y una direccin IP interna esttica
(virtual). El administrador del dispositivo de seguridad debe conocer la direccin IP
interna del interlocutor por dos motivos:
170
Acceso telefnico
Puede utilizarla en directivas.
Puede crear una ruta asociando la direccin con una interfaz de tnel unida a
un tnel VPN apropiado.
Cuando el cliente NetScreen-Remote establece el tnel, el trfico que lo atraviesa

puede originarse desde el otro extremo. Todas las zonas del dispositivo de
seguridad se encuentran en el dominio de enrutamiento Trust-vr.
Figura 42: VPN de acceso telefnico basada en rutas, interlocutor dinmico
Usuario remoto: Phil
NetScreen-Remote
Interfaz de salida
ethernet3
1.1.1.1/24
Oficina corporativa
ethernet2
1.2.2.1/24
Zona Untrust Puerta de enlace

1.1.1.250
Internet
Peticin
SMTP
Direccin IP externa
dinmica
Servidor de
correo
1.2.2.5
Peticin
IDENT
Tnel VPN
Direccin IP interna
10.10.10.1
Zona DMZ
Interfaz de tnel
Tunnel.1
En este ejemplo, Phil desea acceder a su correo electrnico desde el servidor de

correo del sitio de la empresa. Cuando intenta hacerlo, es autenticado por el
programa del servidor de correo, que le enva una peticin IDENT a travs del tnel.
NOTA:
El servidor de correo puede enviar la peticin IDENT a travs del tnel slo si el
administrador de seguridad agrega un servicio personalizado para ello (TCP,
puerto 113) y establece una directiva de salida que permita el trfico a travs del
tnel hacia 10.10.10.1.
La clave previamente compartida es h1p8A24nG5. Partiremos de la base de que
certificado local en NetScreen-Remote contiene el U-FQDN pm@juniper.net. (Para
encontrar informacin sobre cmo obtener y cargar certificados, consulte
Certificados y CRL en la pgina 24.) Para los niveles de seguridad de las fases 1
y 2, debe especificar una propuesta de fase 1 (pre-g2-3des-sha para el mtodo de
clave previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas Compatible para la fase 2.
Introduzca las tres rutas siguientes en el dispositivo de seguridad:
Una ruta predeterminada que conduzca al enrutador externo en trust-vr
Una ruta al destino a travs de la interfaz de tnel
Una ruta Null al destino. Asigne una mtrica ms alta (ms alejada de cero) a la
ruta Null para que se convierta en la siguiente opcin de ruta al destino.
A continuacin, si el estado de la interfaz de tnel cambia a fuera de lnea y la
ruta que hace referencia a esa interfaz tambin se desactiva, el dispositivo de
seguridad utiliza la ruta Null, que descarta todo trfico enviado hacia l, en
lugar de la ruta predeterminada, que reenva trfico no encriptado.
Finalmente, crear directivas que permitan el flujo del trfico fluya en ambas
direcciones entre Phil y el servidor de correo.
Acceso telefnico
171
WebUI
1.
Interfaces
haga clic en OK:
Zone Name: DMZ
haga clic en OK:
Zone Name: Untrust
clic en OK:
2.
Direcciones
Zone: DMZ
Address Name: Phil
Zone: Untrust
3.
Servicios
Service Name: Ident
Service Timeout:
172
Acceso telefnico
Ident
MAIL
POP3
4.
VPN
y haga clic en OK:
Gateway Name: To_Phil
Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net


enlace:
pre-g2-3des-sha
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_Phil
Remote Gateway:
Predefined: (seleccione), To_Phil
Acceso telefnico
173

IKE:
Service: Any
5.
Rutas
Interface: tunnel.1
Interface: Null
Metric: 10
6.
Directivas
Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Phil
Address Book Entry: (seleccione), Mail Server
Action: Permit
Policies > (From: DMZ, To: Untrust) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Action: Permit
174
Acceso telefnico
CLI
1.
Interfaces

2.
Direcciones
set address dmz Mail Server 1.2.2.5/32

set address untrust phil 10.10.10.1/32
3.
Servicios
set
set
set
set
set
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
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
NOTA:

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
NetScreen-Remote
1. Haga clic en Options > Global Policy Settings y seleccione la casilla de
verificacin Allow to Specify Internal Network Address.
Acceso telefnico
175
2. Options > Secure > Specified Connections.

3. Haga clic en el botn Add a new connection y escriba Mail junto al icono de la
nueva conexin que aparecer en pantalla.
Protocol: All
7. Haga clic en My Identity y elija una de estas dos opciones:
Haga clic en Pre-shared Key > Enter Key: Escriba h1p8A24nG5, despus 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 direccin de correo electrnico
pm@juniper.net en la lista desplegable Select Certificate.

(o bien)
Hash Alg: SHA-1
176
Acceso telefnico
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
VPN de acceso telefnico basada en directivas, interlocutor dinmico

En este ejemplo, un tnel VPN conecta de forma segura al usuario situado tras el
dispositivo NetScreen-Remote a la interfaz de la zona Untrust del dispositivo de
seguridad que protege el servidor de correo en la zona DMZ. La interfaz de la zona
Untrust tiene una direccin IP esttica. El cliente NetScreen-Remote tiene una
direccin IP externa asignada dinmicamente y una direccin IP interna esttica
(virtual). El administrador del dispositivo de seguridad debe conocer la direccin IP
interna del cliente, de forma que pueda agregarla a la libreta de direcciones de la
zona Untrust para su uso en directivas de trfico de tnel desde ese origen. Cuando
el cliente NetScreen-Remote establece el tnel, el trfico que lo atraviesa puede
originarse desde el otro extremo.
Acceso telefnico
177
Figura 43: VPN de acceso telefnico basada en directivas, interlocutor dinmico

Interfaz de salida
Oficina corporativa
Zona Untrust
Zona DMZ
ethernet3, 1.1.1.1/24
Puerta de enlace 1.1.1.250 ethernet2, 1.2.2.1/24
Usuario remoto Phil

NetScreen-Remote
Peticin
SMTP
Servidor de correo
electrnico
1.2.2.5
Internet
Peticin
IDENT
Tnel VPN
Direccin IP interna
10.10.10.1
Zona Untrust
Direccin IP externa
dinmica
Zona DMZ
En este ejemplo, Phil desea acceder a su correo electrnico desde el servidor de

correo del sitio de la empresa. Cuando intenta hacerlo, es autenticado por el
programa del servidor de correo, que le enva una peticin IDENT a travs del tnel.
NOTA:
El servidor de correo puede enviar la peticin IDENT a travs del tnel slo si el
administrador de seguridad agrega un servicio personalizado para ello (TCP,
puerto 113) y establece una directiva de salida que permita el trfico a travs del
tnel hacia 10.10.10.1.
La clave previamente compartida es h1p8A24nG5. En este ejemplo se asume que
certificado local en NetScreen-Remote contiene el U-FQDN pm@juniper.net. (Para
ms informacin sobre cmo obtener y cargar certificados, consulte Certificados y
CRL en la pgina 24.) Para los niveles de seguridad de las fases 1 y 2, debe
especificar una propuesta de fase 1 (pre-g2-3des-sha para el mtodo de clave
previamente compartida o rsa-g2-3des-sha para certificados) y seleccionar el
conjunto de propuestas Compatible para la fase 2.
WebUI
1.
Interfaces
haga clic en OK:
Zone Name: DMZ
haga clic en OK:
Zone Name: Untrust
178
Acceso telefnico
2.
Direcciones
Zone: DMZ
Address Name: Phil
Zone: Untrust
3.
Servicios
Service Name: Ident
Service Timeout:
Ident
MAIL
POP3
4.
VPN
y haga clic en OK:
Gateway Name: To_Phil
Dynamic IP Address: (seleccione), Peer ID: pm@juniper.net
Acceso telefnico
179


enlace:
pre-g2-3des-sha
(o bien)
Certificados

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: corp_Phil
Remote Gateway:
Predefined: (seleccione), To_Phil
5.
Ruta
180
Acceso telefnico
6.
Directivas
Policies > (From: Untrust, To: DMZ) New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Action: Tunnel
VPN Tunnel: corp_Phil
CLI
1.
Interfaces

2.
Direcciones
set address dmz mail server 1.2.2.5/32

set address untrust phil 10.10.10.1/32
3.
Servicios
set
set
set
set
set
4.

VPN

(o bien)
Certificados

set ike gateway to_phil cert peer-ca 1
set ike gateway to_phil cert peer-cert-type x509-sig
NOTA:

5.
Ruta
Acceso telefnico
181
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
NetScreen-Remote
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
Protocol: All
7. Click My Identity and do either of the following:
Click Pre-shared Key > Enter Key: Escriba h1p8A24nG5, despus haga clic
en OK.
(o bien)
Select the certificate that contains the email address pmason@email.com
from the Select Certificate dropdown list.

182
Acceso telefnico

(o bien)
Hash Alg: SHA-1
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
Acceso telefnico
183
Directivas bidireccionales para usuarios de VPN de acceso telefnico

Es posible crear directivas bidireccionales para VPN de acceso telefnico. Esta
configuracin presenta unas funciones similares a la configuracin VPN para
interlocutores dinmicos. Sin embargo, con una configuracin de VPN para
interlocutores dinmicos, el administrador del dispositivo de seguridad debe
conocer el espacio de direcciones IP interno del usuario de acceso telefnico, de
forma que pueda utilizarlo como direccin de destino cuando configure una
directiva de salida (consulte VPN de acceso telefnico basada en directivas,
interlocutor dinmico en la pgina 177). Con una configuracin de usuario de VPN
de acceso telefnico, el administrador en el sitio LAN no necesita conocer el
espacio de direcciones interno del usuario de acceso telefnico. El dispositivo de
seguridad que protege la red LAN utiliza la direccin predefinida Dial-Up VPN
como direccin de origen en la directiva de entrada y la de destino en la directiva
de salida.
La posibilidad de crear directivas bidireccionales para un tnel VPN permite que el
trfico se origine en un extremo de la LAN de la conexin VPN cuando ya se ha
establecido la conexin (el equipo remoto debe iniciar en primer lugar la creacin
del tnel). Observe que, a diferencia de un tnel VPN de acceso telefnico de
interlocutor dinmico, esta funcin hace necesario que los servicios de las
directivas de entrada y salida sean idnticos.
NOTA:
ScreenOS no admite grupos de servicios ni de direcciones en las directivas

bidireccionales que hacen referencia a una configuracin de VPN de acceso
telefnico.
El espacio de direcciones interno de dos o ms usuarios de una VPN de acceso
telefnico conectados simultneamente podra hacer que se superpusieran. Por
ejemplo, los usuarios de acceso telefnico A y B podran tener un espacio de
direcciones IP interno 10.2.2.0/24. Si esto sucede, el dispositivo de seguridad enva
todo el trfico de VPN saliente al usuario A y al usuario B a travs 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 de seguridad enva al usuario A todo el trfico
VPN saliente para los usuarios A y B.
De forma similar, la direccin interna de un usuario de acceso telefnico podra
superponerse con una direccin de cualquier otra directiva, independientemente de
si esa otra directiva hace referencia a un tnel VPN. Si esto sucede, el dispositivo de
seguridad aplica la primera directiva que coincida con los atributos bsicos de
trfico relativos a la direccin de origen, direccin de destino, nmero de puerto de
origen, nmero de puerto de destino o servicio. Para evitar que una directiva
bidireccional para una VPN de acceso telefnico con una direccin derivada
dinmicamente anule otra directiva con una direccin esttica, Juniper Networks
recomienda colocar la directiva bidireccional de VPN de acceso telefnico en una
posicin ms baja en la lista de directivas.
En este ejemplo configuraremos directivas bidireccionales para un tnel VPN de
acceso telefnico AutoKey IKE llamado VPN_dial para el usuario IKE dialup-j con la
identificacin 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.
184
Acceso telefnico
El usuario IKE inicia una conexin VPN al dispositivo de seguridad desde la zona
Untrust para acceder a los servidores corporativos de la zona Trust. Una vez el
usuario IKE establece la conexin VPN, el trfico se puede iniciar desde cualquiera
de los dos extremos del tnel.
La interfaz de la zona Trust es ethernet1, tiene la direccin IP 10.1.1.1/24 y se
encuentra en modo NAT. La interfaz de la zona Untrust es ethernet3 y tiene la
direccin IP 1.1.1.1/24. La ruta predeterminada apunta al enrutador externo
situado en 1.1.1.250.
WebUI
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Objetos
Address Name: trust_net
Zone: Trust
Policy > Policy Elements > Users > Local > New: Introduzca los siguientes
User Name: dialup-j
Status: Enable
Simple Identity: (seleccione); jf@ns.com
3.
VPN
y haga clic en OK:
Gateway Name: dialup1
Dialup User: (seleccione); dialup-j
Preshared Key: Jf11d7uU
Acceso telefnico
185

enlace:
pre-g2-3des-sha
VPN Name: VPN_dial
Remote Gateway:
Create a Simple Gateway: (seleccione)
Type:
Dialup User: (seleccione); dialup-j
Preshared Key: Jf11d7uU
4.
Ruta
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), trust_net
Service: ANY
Action: Tunnel
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
186
Acceso telefnico
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
Remote Party Identity and Addressing
ID Type: IP Subnet
Subred: 10.1.1.0
Mask: 255.255.255.0
Protocol: All
5. Haga clic en My Identity: Siga uno de estos dos pasos:
Click Pre-shared Key > Enter Key: Escriba Jf11d7uU y despus haga clic
en OK.
ID Type: (seleccione E-mail Address) y escriba jf@ns.com.
Acceso telefnico
187

(o bien)
Hash Alg: SHA-1
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
Identificacin IKE de grupo

Algunas organizaciones pueden tener muchos usuarios de acceso telefnico VPN.
Por ejemplo, un departamento de ventas puede tener cientos de usuarios, muchos
de los cuales necesitarn comunicacin segura por acceso telefnico cuando se
encuentran fuera de las oficinas. Con tantos usuarios, no resulta prctico crear una
definicin de usuario, una configuracin de VPN y una directiva para cada uno.
188
Para evitar este problema, el mtodo de identificacin IKE de grupo permite que
una sola definicin est disponible para mltiples usuarios. La definicin de usuario
para una identificacin IKE de grupo se aplica a todos los usuarios que tengan
certificados con valores especficos en el nombre completo (DN) o a todos los
usuarios cuya identificacin IKE completa y clave previamente compartida en su
cliente VPN coincida con una identificacin IKE parcial y una clave previamente
compartida del dispositivo de seguridad.
NOTA:
Cuando un usuario IKE de acceso telefnico se conecta al dispositivo de

seguridad, ste primero extrae y utiliza la identificacin IKE completa para buscar
sus registros de puerta de enlace de interlocutor por si el usuario no pertenece a
un grupo de usuarios de identificacin IKE de grupo. Si la bsqueda con la
identificacin IKE completa no ofrece ningn resultado, el dispositivo de
seguridad realizar una nueva bsqueda de parte de la identificacin IKE,
buscando coincidencias entre la identificacin IKE entrante incorporada y un
usuario ya configurado de la identificacin IKE de grupo.
Debe agregar un nico usuario de identificacin IKE de grupo a un grupo de
usuarios IKE de una VPN de acceso telefnico y especificar el nmero mximo de
conexiones simultneas que admitir el grupo. El nmero mximo de sesiones
simultneas no podr exceder el nmero mximo de asociaciones de seguridad
admitidas en la fase 1 o el nmero mximo de tneles VPN admitidos en la
plataforma.
Identificacin IKE de grupo con certificados

La identificacin IKE de grupo con certificados es una tcnica para llevar a cabo la
autenticacin IKE para un grupo de usuarios IKE de acceso telefnico sin tener que
configurar un perfil de usuario independiente para cada uno de ellos. En lugar de
hacer eso, el dispositivo de seguridad utiliza un nico perfil de usuario de
identificacin IKE de grupo con una identificacin IKE parcial. El usuario IKE de
acceso telefnico podr establecer correctamente un tnel VPN a un dispositivo de
seguridad si la configuracin de VPN en su cliente VPN especifica un certificado que
contenga elementos de nombre completo con coincidan con los configurados como
definicin de la identificacin IKE parcial en el perfil de usuario de identificacin
IKE de grupo en el dispositivo de seguridad.
Identificacin IKE de grupo 189
Figura 44: Identificacin IKE de grupo con certificados

Grupo de usuarios de acceso telefnico
Usuarios IKE de
acceso telefnico
ID IKE de grupo con claves

previamente compartidas
(nombre completo)
Certificado
DN:
cn=alice
ou=eng
-------------------
Usuario de identificacin
IKE de grupo
Tipo de ID IKE ASN1-DN
ID IKE parcial: ou=eng
Certificado
DN:
cn=bob
ou=eng
------------------Certificado
DN:
cn=carol
ou=sales
-------------------
Para autenticar el usuario, el dispositivo

compara un elemento especfico del nombre
completo (dn) asociado al grupo de usuarios de
acceso telefnico con el elemento
correspondiente del certificado y del dn
utilizados en la carga de datos de la
identificacin IKE que acompaa al paquete
inicial de la fase 1.
Nota: Como el DN en el certificado de Carol
no incluye ou=eng, el dispositivo rechaza la
peticin de conexin.
Puede configurar una identificacin IKE de grupo con certificados tal y como se
indica a continuacin:
En el dispositivo de seguridad:
1. Cree un nuevo usuario de identificacin IKE de grupo con una identidad IKE
parcial (como ou=sales,o=netscreen) y especifique cuntos usuarios de acceso
telefnico podrn utilizar el perfil de la identificacin IKE de grupo para
conectarse.
2. Asigne el nuevo usuario de ID IKE de grupo al grupo de usuarios de acceso
telefnico y asigne un nombre al grupo.
NOTA:
Slo puede asignar un usuario de ID IKE de grupo a un grupo de usuarios IKE.

3. En la configuracin de la VPN de acceso telefnico AutoKey IKE, especifique el
nombre del grupo de usuarios de acceso telefnico, indique que las
negociaciones de la fase 1 sern del modo dinmico y que para la
autenticacin se utilizarn certificados (RSA o DSA, segn el tipo de certificado
cargado en los clientes VPN de acceso telefnico).
4. Cree una directiva que permita el trfico de entrada a travs de la VPN de
acceso telefnico especificada.
En el cliente VPN:
1. Obtenga y cargue un certificado cuyo nombre completo contenga la misma

informacin definida en la identificacin IKE parcial del dispositivo de
seguridad.
190
2. Configure un tnel VPN al dispositivo de seguridad utilizando el modo dinmico

para las negociaciones de la fase 1, especifique el certificado cargado
anteriormente y seleccione Distinguished Name para el tipo de identificacin
IKE local.
A partir de ese momento, cada usuario IKE de acceso telefnico que disponga de
un certificado con elementos de nombre completo que coincidan con la
identificacin IKE parcial definida en el perfil de usuario de la ID IKE de grupo
podr establecer correctamente un tnel al dispositivo de seguridad. Por ejemplo, si
el usuario de ID IKE de grupo tiene la ID IKE OU=sales,O=netscreen, el dispositivo
de seguridad aceptar las negociaciones de fase 1 de cualquier usuario que tenga
un certificado con esos elementos en su nombre completo. El nmero mximo de
usuarios IKE de acceso telefnico que se podrn conectar al dispositivo de
seguridad depender del nmero mximo de sesiones simultneas que especifique
en el perfil de usuario de identificacin IKE de grupo.
Tipos de identificacin IKE ASN1-DN Wildcard y Container

Cuando se define la ID IKE para un usuario IKE de grupo, se utiliza el nombre
completo segn la norma ASN-1 (ASN1-DN) como tipo de identificacin IKE de la
configuracin de identidad. Esta notacin constituye una cadena de valores
ordenados (a menudo pero no siempre= desde lo ms general a lo ms especfico.
Consulte la Figura 45 para obtener un ejemplo.
Figura 45: Nombre distinguido ASN1
ASN1-DN: C=us,ST=ca,L=sunnyvale,O=juniper,OU=sales,CN=jozef
C=us
General
ST=ca
Leyenda:
C = Pas
ST = Estado
L = Localidad
L=sunnyvale
O = Organizacin
O=juniper
OU = Unidad organizativa
CN = Nombre comn
OU=sales
CN=jozef
Especfico
Cuando se configura el usuario de la identificacin IKE de grupo, debe especificar la

ID ASN1-DN del interlocutor como uno de estos dos tipos:
Wildcard: ScreenOS autentica la ID de un usuario IKE de acceso telefnico 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 slo 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: ScreenOS autentica la ID de un usuario IKE de acceso telefnico 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 mltiples 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 idntico.
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 (por ejemplo,
c=us,st=ca,cn=kgreen). Si configura una ID ASN1-DN para una ID IKE local,
utilice la siguiente palabra clave: [DistinguishedName]. Incluya los corchetes y
escrbalo exactamente como se indica.
ID IKE de 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
telefnico y la ID del usuario IKE de grupo son las siguientes:
ID IKE de ASN1-DN completo del usuario IKE de acceso telefnico:

CN=kristine,OU=finance,O=juniper,ST=ca,C=us
ID IKE parcial del ASN1-DN del usuario IKE de grupo: C=us,O=juniper
una ID IKE de tipo Wildcard del ASN1-DN compara las dos ID IKE, aunque el orden
de los valores en las dos ID difiera.
Figura 46: Autenticacin exitosa de ASN1-DN Wildcard
usuario de acceso telefnico IKE
ID IKE ASN1-DN
El ASN1-DN del usuario IKE de
acceso telefnico contiene los valores
especificados en el ASN1-DN del
usuario IKE de grupo. El orden de los
valores es irrelevante.
E=
CN=kristine
OU=finance
192
Wildcard del usuario IKE de grupo

ID IKE ASN1-DN
E=
Autenticacin
satisfactoria
C=us
ST=
O=juniper
L=
L=
O=juniper
ST=ca
OU=
C=us
CN=
ID IKE de ASN1-DN de tipo Container
Una ID de tipo Container del ASN1-DN permite que la ID del usuario IKE de grupo
tenga mltiples entradas en cada campo identificativo. ScreenOS autentica un
usuario IKE de acceso telefnico si la ID de usuario de acceso telefnico 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 tambin debe coincidir en las ID del usuario IKE de acceso telefnico
y del usuario IKE de grupo. Si hay varios valores, su orden en los campos
correspondientes tambin deber ser igual.
Figura 47: xito y fallo de la autenticacin utilizando las ID de tipo Container del ASN1-DN
El primer ASN1-DN de usuario

IKE de acceso telefnico
contiene valores exactamente
iguales a los de ASN1-DN
ASN1-DN. El orden de las
entradas mltiples en el campo
de identificacin OU tambin
es idntico.
El segundo ASN1-DN de usuario

contiene valores exactamente
iguales a los de ASN1-DN. Sin
embargo, el orden de las
entradas mltiples en el campo
de identificacin OU no es igual.
ID IKE de ASN1-DN del usuario
ID IKE Container del ASN1-DN
del usuario IKE de grupo
E=
E=
C=us
C=us
ST=ca
Autenticacin
satisfactoria
ST=
L= sf
L=
O=juniper
O=juniper
OU=mkt,OU=dom,OU=west
CN=rick
CN=
ID IKE de ASN1-DN del usuario
ID IKE Container del ASN1-DN
del usuario IKE de grupo
E=
E=
C=us
C=us
ST=ca
Autenticacin
fallida
ST=
L= la
L=
O=juniper
O=juniper
OU=mkt,OU=west,OU=dom
CN=tony
CN=
Creacin de una identificacin IKE de grupo (certificados)

En este ejemplo definir un nuevo usuario de identificacin IKE de grupo llamado
Usuario1. Configurar la definicin para que acepte un mximo de 10
negociaciones simultneas en la fase 1 por parte de clientes VPN con certificados
RSA que contengan O=netscreen y OU=marketing. La autoridad de certificacin
(CA) ser Verisign. El grupo de usuarios IKE de acceso telefnico ser oficina_1.
Figura 48: Identificacin IKE de grupo
Interfaz de salida
Zona Untrust
ethernet3, 1.1.1.1/24
Usuario telefnico
ID IKE:
o=juniper
ou=marketing
Zona Trust
ethernet1, 10.1.1.1/24
Modo NAT
Zona Untrust
Zona Trust
Internet
Tnel VPN
puerta de enlace 1.1.1.250
LAN
web1
10.1.1.5
Perfil de usuario de
identificacin IKE de grupo
Nombre de usuario:
Usuario1
Grupo de usuarios: oficina_1
Nombre distinguido:
o=juniper
ou=marketing
Los usuarios IKE de acceso telefnico envan un nombre completo como su ID IKE.
El nombre completo (DN) en un certificado para un usuario IKE de acceso
telefnico en este grupo puede aparecer como la siguiente cadena:
C=us,ST=ca,L=sunnyvale,O=netscreen,OU=marketing,CN=carrie
nowocin,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 identificacin
IKE, el dispositivo de seguridad autenticar el usuario.
Para los niveles de seguridad de las fase 1 y fase 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 telefnico y una directiva que permita el
trfico HTTP a travs del tnel VPN para acceder al servidor Web1. Tambin se
incluir la configuracin del cliente VPN remoto (utilizando NetScreen-Remote).
WebUI
1.
Interfaces
haga clic en OK:
Zone Name: Trust
Interface Mode: NAT
194
haga clic en OK:
Zone Name: Untrust
2.
Direccin
Address Name: web1
Zone: Trust
3.
Usuarios
Nombre de usuario: Usuario1
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 oficina_1 en el campo Group
Name, realice la accin que se indica a continuacin y despus haga clic en OK:
Seleccione Usuario1 y utilice el botn << para mover esta definicin de la
columna Available Members a la columna Group Members.
4.
VPN
y haga clic en OK:
Gateway Name: Corp_GW
Remote Gateway Type: Dialup User Group: (seleccione), Group: oficina_1

enlace:
rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
VPN Name: Corp_VPN
Remote Gateway: Predefined: (seleccione), Corp_GW
5.
Ruta
6.
Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), web1
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
CLI
1.
Interfaces

2.
Direccin
set address trust web1 10.1.1.5/32

3.
Usuarios
set user Usuario1 ike-id asn1-dn wildcard o=juniper,ou=marketing share-limit 10

set user-group oficina_1 user Usuario1
4.
VPN
set ike gateway Corp_GW dialup oficina_1 aggressive outgoing-interface ethernet3

set ike gateway Corp_GW cert peer-ca 1
set ike gateway Corp_GW cert peer-cert-type x509-sig
set vpn Corp_VPN gateway Corp_GW sec-level compatible
NOTA:

5.
Ruta
196
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
Protocol: Seleccione All, escriba HTTP, pulse el tabulador y escriba 80.
4. Haga clic en el signo MS situado a la izquierda del icono de web1 para ampliar
la directiva de la conexin.
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.
ID Type: Seleccione Distinguished Name en la lista desplegable.
NOTA:
En este ejemplo se asume que ya ha cargado un certificado adecuado en el cliente

NetScreen-Remote. Para obtener ms informacin sobre cmo cargar certificados
en el cliente NetScreen-Remote, consulte la documentacin de NetScreen-Remote.
8. Haga clic en Authentication (Phase 1) > Proposal 1: Seleccione los siguientes
algoritmos de encriptacin e integridad de datos:
Hash Alg: SHA-1
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
Configuracin de una ID IKE de grupo con claves previamente compartidas

La identificacin IKE de grupo con claves previamente compartidas es una tcnica
para llevar a cabo la autenticacin IKE para un grupo de usuarios IKE de acceso
telefnico sin tener que configurar un perfil de usuario independiente para cada
uno de ellos. En lugar de hacer eso, el dispositivo de seguridad utiliza un nico perfil
de usuario de identificacin IKE de grupo con una identificacin IKE parcial. El
usuario IKE de acceso telefnico podr establecer correctamente un tnel VPN a un
dispositivo de seguridad si la configuracin 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 identificacin IKE
de grupo.
198
Figura 49: ID IKE de grupo con claves previamente compartidas

Usuarios IKE de
acceso telefnico
ID IKE completa
+
Clave previamente
compartida
Grupo de usuarios de acceso telefnico
alice.eng.jnpr.net
+
011fg3322eda837c
Usuario de identificacin IKE de grupo

ID IKE parcial: eng.jnpr.net
Valor de inicializacin de clave previamente
compartida: N11wWd2
bob.eng.jnpr.net
+
bba7e22561c5da82
carol.jnpr.net
+
834a2bbd32adc4e9
El dispositivo de seguridad genera en tiempo

real una clave previamente compartida cuando
un usuario IKE enva su identificacin IKE
completa.
(Clave previamente compartida de cada usuario
Nota: Ya que la identificacin de IKE para
IKE = valor inicial de clave previamente
Carol no es carol.eng.jnpr.net, el dispositivo de compartida x ID IKE completa).
seguridad rechaza la peticin de conexin.
El tipo de ID IKE que utilice para la ID IKE de grupo con funcin de clave
previamente compartida puede ser una direccin de correo electrnico o un
nombre de dominio completo (FQDN).
Puede configurar una identificacin IKE de grupo con claves previamente
compartidas tal y como se indica a continuacin:
En el dispositivo de seguridad:
1. Cree un nuevo usuario de identificacin IKE de grupo con una identidad IKE
parcial (como juniper.net) y especifique la cantidad de usuarios de acceso
telefnico que podrn utilizar el perfil de la identificacin IKE de grupo para
conectarse.
2. Asigne el nuevo usuario de ID IKE de grupo a un grupo de usuarios de acceso
telefnico.
3. En la configuracin de la VPN de acceso telefnico AutoKey IKE, asigne un
nombre para la puerta de enlace remota (p. ej., road1), especifique el grupo de
usuarios de acceso telefnico 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 telefnico utilizando el valor
inicial de clave previamente compartida y la ID IKE completa del usuario (como
lisa@juniper.net).
exec ike preshare-gen cadena_nombre cadena_nombre_usuario
(por ejemplo) exec ike preshare-gen road1 lisa@juniper.net
5. Registre la clave previamente compartida para poder utilizarla durante la

configuracin de un cliente VPN remoto.
En el cliente VPN:
Configure un tnel VPN al dispositivo de seguridad utilizando el modo dinmico

en las negociaciones de la fase 1 e introduzca la clave previamente compartida
que gener anteriormente en el dispositivo de seguridad.
A partir de ese momento, el dispositivo de seguridad podr autenticar
correctamente a cada usuario individual cuya ID IKE contenga una seccin 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 dinmico con el dispositivo de seguridad. Por ejemplo: alice@juniper.net,
bob@juniper.net, y carol@juniper.net. El nmero de usuarios que se pueden
conectar depender del nmero mximo de sesiones simultneas especificadas en
el perfil de usuario de ID IKE de grupo.
En este ejemplo definir un nuevo usuario de identificacin IKE de grupo llamado
Usuario2. A continuacin, configurar la definicin para que acepte un mximo de
10 negociaciones simultneas 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 telefnico ser oficina_2.
Figura 50: ID IKE de grupo (claves previamente compartidas)
Interfaz de salida
Zona Untrust
ethernet3, 1.1.1.1/24
Zona Trust
ethernet1, 10.1.1.1/24
Modo NAT
Zona Untrust
Usuario de acceso
telefnico con
ID IKE:
joe@juniper.net
Zona Trust
Internet
LAN
Tnel VPN
puerta de enlace 1.1.1.250
web1
10.1.1.5
Perfil de usuario de
Nombre de usuario: Usuario2
Grupo de usuario: oficina_2
ID simple: juniper.net
Tanto para las negociaciones de fase 1 como para las 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
haga clic en OK:
Zone Name: Trust
Interface Mode: NAT
200
haga clic en OK:
Zone Name: Untrust
2.
Direccin
Address Name: web1
Zone: Trust
3.
Usuarios
User Name: Usuario2
Status: Enable
IKE Identity: juniper.net
Policy > Policy Elements > User Groups > Local > New: Escriba oficina_2 en
el campo Group Name, realice la accin que se indica a continuacin y despus
haga clic en OK:
Seleccione Usuario2 y utilice el botn << para trasladarlo de la columna
Available Members a la columna Group Members.
4.
NOTA:
VPN
La WebUI slo permite introducir un valor para la clave previamente compartida,

pero no un valor inicial a partir del cual el dispositivo de seguridad 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
haga clic en OK:
Source Address:
Service: HTTP
Action: Tunnel
Tunnel VPN: Corp_VPN
CLI
1.
Interfaces

2.
Direccin

3.
Usuarios
set user Usuario2 ike-id u-fqdn juniper.net share-limit 10

set user-group oficina_2 user Usuario2
4.
VPN
set ike gateway Corp_GW dialup oficina_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
Obtencin de la clave previamente compartida

La clave previamente compartida slo se puede obtener utilizando el siguiente
comando CLI:
exec ike preshare-gen cadena_nombre cadena_nombre_usuario
La clave previamente compartida, basada en el valor inicial de clave

previamente compartida jk930k (como se especific en la configuracin de la
puerta de enlace remota llamada Corp_GW) y la identificacin completa de
usuario individual heidi@juniper.net es
11ccce1d396f8f29ffa93d11257f691af96916f2.
202

Protocol: Seleccione All, escriba HTTP, pulse el tabulador y escriba 80.
6. Haga clic en My Identity: Click Pre-shared Key > Enter Key: Escriba
11ccce1d396f8f29ffa93d11257f691af96916f2, despus haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba heidi@juniper.net.
despus en el smbolo MS situado a la izquierda de Authentication (Fase 1) y
de Key Exchange (Fase 2) para ampliar an ms la directiva.
Hash Alg: SHA-1
9. Haga clic en Authentication (Fase 1) > Create New Proposal: Seleccione los
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
Identificacin IKE compartida

La funcin de identificacin IKE compartida facilita la implementacin de un gran
nmero de usuarios de acceso telefnico. Gracias a ella, el dispositivo de seguridad
autentica mltiples usuarios VPN de acceso telefnico utilizando una nica
identificacin IKE de grupo y clave compartida. De esta forma, proporciona
proteccin IPSec para grandes grupos de usuarios remotos por medio de una
configuracin VPN comn.
204
Esta funcin es similar a la identificacin IKE de grupo con funcin de claves

previamente compartidas, con las siguientes diferencias:
Con la funcin de ID IKE de grupo, la ID IKE puede ser una direccin de correo
electrnico o un nombre de dominio completo (FQDN). Para esta funcin, la ID
IKE debe ser una direccin de correo electrnico.
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 de seguridad:
1. Cree un nuevo usuario de identificacin IKE de grupo y especifique cuntos
usuarios de acceso telefnico podrn utilizar la ID IKE para conectarse. En esta
funcin, utilice una direccin de correo electrnico como la identificacin IKE.
2. Asigne la nueva ID IKE de grupo a un grupo de usuarios de acceso telefnico.
3. En la configuracin VPN de acceso telefnico 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.
En el cliente VPN:
Configure un tnel VPN al dispositivo de seguridad utilizando el modo dinmico en
las negociaciones de la fase 1 e introduzca la clave previamente compartida que
defini anteriormente en el dispositivo de seguridad. A continuacin, ste
autenticar cada usuario remoto tal y como se indica a continuacin:
Durante las negociaciones de la fase 1, el dispositivo de seguridad primero
autentica el cliente VPN comparando la ID IKE y la clave previamente compartida
que el cliente enva con la ID IKE y la clave previamente compartida del dispositivo
de seguridad. Si coinciden, el dispositivo de seguridad utiliza XAuth para autenticar
el usuario individual. Enva una peticin de inicio de sesin 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 contrasea correctos, comenzarn las
negociaciones de la fase 2.
En este ejemplo crearemos un nuevo usuario de identificacin IKE de grupo
llamado Ventas_remotas. Aceptar hasta 250 negociaciones simultneas de fase 1
desde clientes VPN con la misma clave previamente compartida (abcd1234). El
nombre del grupo de usuarios IKE de acceso telefnico ser V_R. Adems,
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.
Identificacin IKE compartida 205
Figura 51: ID IKE compartida (claves previamente compartidas)

Usuario de acceso
telefnico con
ID IKE: joe@ns.com
Contrasea XAuth: 1234
Interfaz de salida
ethernet3, 1.1.1.1/24
ethernet1, 10.1.1.1/24
Modo NAT
Zona Untrust
Zona Trust
LAN
Tneles VPN
web1
10.1.1.5
Perfil de usuario de ID IKE

compartida
Nombre de usuario:
Ventas_remotas
Grupo de usuario: V_R
ID simple: sales@ns.com
Usuario de acceso
telefnico con
ID IKE: mike@ns.com
Contrasea XAuth: 5678
WebUI
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direccin
Address Name: web1
Zone: Trust
3.
Usuarios
User Name: Ventas_remotas
Status: Enable
IKE Identity: sales@ns.com
206
Policy > Policy Elements > User Groups > Local > New: Escriba V_R en el
campo Group Name, realice la accin que se indica a continuacin y despus
haga clic en OK:
Seleccione Ventas_remotas y utilice el botn << para moverlo de la columna
User Name: Joe
Status: Enable
XAuth User: (seleccione)
Contrasea: 1234
Confirm Password: 1234
User Name: Mike
Status: Enable
XAuth User: (seleccione)
Password: 5678
Confirm Password: 5678
4.
VPN
y haga clic en OK:
Gateway Name: sales_gateway
Security Level: Compatible (seleccione)
Remote Gateway Type: Dialup Group (seleccione), V_R
Preshared Key: abcd1234
> Advanced: Introduzca los siguientes datos, despus haga clic en Return
Enable XAuth: (seleccione)
Local Authentication: (seleccione)
Allow Any: (seleccione)
VPN Name: Sales_VPN
Remote Gateway: Predefined: (seleccione) sales_gateway

IKE:
5.
Ruta
6.
Directiva
haga clic en OK:
Source Address:
Service: HTTP
Action: Tunnel
Tunnel VPN: Sales_VPN
CLI
1.
Interfaces

2.
Direccin

3.
Usuarios
set
set
set
set
set
set
4.
user Ventas_remotas ike-id sales@ns.com share-limit 250

user-group V_R user Ventas_remotas
user Joe password 1234
user Joe type xauth
user Mike password 5678
user Mike type xauth
VPN
set ike gateway sales_gateway dialup V_R 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
208

En este ejemplo se muestra la configuracin del usuario Joe.
Remote Party ID Type: IP Address
ID Type: IP Address; 1.1.1.1
6. Haga clic en My Identity: Click Pre-shared Key > Enter Key: Escriba
abcd1234, despus haga clic en OK.
ID Type: (seleccione E-mail Address) y escriba sales@ns.com.
despus en el smbolo MS situado a la izquierda de Authentication (Fase 1) y
de Key Exchange (Fase 2) para ampliar an ms la directiva.
Authentication Method: Pre-Shared Key; Extended Authentication
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5
210
Captulo 6
Protocolo de encapsulamiento de la
capa 2
Este captulo proporciona una introduccin al protocolo de encapsulamiento de la
capa (Layer 2 Tunneling Protocol, L2TP), su utilizacin en solitario y con soporte
IPSec, y algunos ejemplos de la configuracin de L2TP y L2TP sobre IPSec. Incluye
las siguientes secciones:
Introduccin al L2TP en esta pgina
Encapsulado y desencapsulado de paquetes en la pgina 214
Encapsulado en la pgina 215
Desencapsulado en la pgina 216
Ajuste de los parmetros L2TP en la pgina 217
L2TP y L2TP sobre IPSec en la pgina 219
Configuracin de L2TP en la pgina 219
Configuracin de L2TP sobre IPSec en la pgina 224
L2TP sobre IPSec bidireccional en la pgina 232
Introduccin al L2TP
El protocolo L2TP proporciona a un usuario de acceso telefnico una forma de
realizar una conexin con un protocolo punto a punto virtual (PPP) a un servidor de
red L2TP (LNS), que puede ser un dispositivo de seguridad. L2TP enva tramas PPP
por un tnel entre un concentrador de acceso L2TP (LAC) y el LNS.
En origen, el protocolo L2TP se dise para que un LAC residente en un sitio ISP se
conectase por tnel a un LNS en el sitio de otro ISP o empresa. El tnel L2TP no
llega hasta al equipo del usuario de acceso telefnico, sino nicamente hasta el LAC
en el ISP local del usuario de acceso telefnico. (A veces, a esto se le llama
configuracin L2TP obligatoria.)
Introduccin al L2TP
211
Un cliente NetScreen-Remote sobre Windows 2000 o Windows NT, o un cliente

Windows 2000 por s mismo, puede actuar como un LAC. El tnel L2TP puede
llegar directamente hasta el equipo del usuario de acceso telefnico,
proporcionando as un encapsulado de protocolos punto a punto. (A veces, a esta
solucin se le llama configuracin L2TP voluntaria.)
Figura 52: Tnel L2TP entre el cliente VPN (LAC) y el dispositivo de seguridad (LNS)
NetScreen-Remote o
Windows 2000 (LAC)
ISP
Internet
Dispositivo de
seguridad (LNS)
LAN
corporativa
Tnel L2TP
(reenvo de sesiones PPP
del LAC al LNS)
Debido a que el enlace PPP va desde el usuario de acceso telefnico a travs de

Internet hasta el dispositivo de seguridad (LNS), es el dispositivo de seguridad y no
el ISP quien asigna al cliente su direccin IP, las direcciones de los servidores DNS y
WINS, y autentica al usuario, ya sea 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 conexin fsica al ISP,
y otra lgica 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 direccin IP
pblica, que se convierte en la direccin IP externa del tnel L2TP.
Figura 53: Asignaciones IP y DNS del ISP
En primer lugar, el ISP asigna
al cliente una direccin IP
pblica y las direcciones de los
servidores DNS.
ISP

DNS: 6.6.6.6, 7.7.7.7
Despus, cuando el tnel L2TP reenva las tramas PPP encapsuladas al dispositivo
de seguridad, ste asigna al cliente una direccin IP y los ajustes de DNS y WINS. La
direccin IP puede ser del conjunto de direcciones privadas no utilizadas en
Internet. sta se convierte en la direccin IP interna del tnel L2TP.
212
Introduccin al L2TP
Captulo 6: Protocolo de encapsulamiento de la capa 2
Figura 54: Asignaciones IP y DNS del LNS

En segundo lugar, el dispositivo de seguridad, actuando
como LNS, asigna al cliente una direccin IP privada
(lgica) y las direcciones de los servidores DNS y WINS.
Internet
Dispositivo de
seguridad (LNS)
LAN corporativa
10.1.1.0/24

DNS: 10.1.1.10, 1.2.2.10
WINS: 10.1.1.48, 10.1.1.49
NOTA:
10.10.1.1 10.10.1.254
Las direcciones IP asignadas al cliente L2TP deben estar en una subred diferente
de la de las direcciones IP en la LAN corporativa.
La versin actual de ScreenOS proporciona el siguiente soporte al L2TP:
NOTA:
Tneles L2TP con origen en un host con Windows 2000
De forma predeterminada, Windows 2000 realiza L2TP sobre IPSec. Para obligarlo
a utilizar slo L2TP, debe dirigirse a la clave ProhibitIPSec en el registro y cambiar
0 (L2TP sobre IPSec) por 1 (slo L2TP). (Antes de hacerlo, Juniper Networks
recomienda hacer una copia de seguridad del registro). Haga clic en Inicio >
Ejecutar: Escriba regedit. Haga doble clic 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 numeracin y despus haga clic en OK. Reinicie. (Si no encuentra
esta entrada en el registro, consulte la documentacin de Microsoft Windows para
obtener informacin sobre como crear una).
Combinacin 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 dinmico utilizando una clave
previamente compartida o certificados
Para Windows 2000: L2TP sobre IPSec, con negociaciones en modo

principal que utilizan certificados
Directiva de acceso telefnico saliente para tneles L2TP y L2TP sobre IPSec
(Una directiva de acceso telefnico saliente se puede emparejar con una
entrante para proporcionar un tnel bidirecciones).
Autenticacin de usuario utilizando los protocolos 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).
Introduccin al L2TP
213
NOTA:
NOTA:
La base de datos local y los servidores RADIUS son compatibles con PAP y con
CHAP SecurID y los servidores LDAP slo son compatibles con PAP.
Asignacin de las direcciones IP de los usuarios, los servidores DNS (sistema de

nombres de dominio), y los servidores WINS (servicio de nombres de Internet
en Windows) desde la base de datos local o un servidor RADIUS
Tneles L2TP y L2TP sobre IPSec para el sistema raz y los sistemas virtuales
Para utilizar el protocolo L2TP, el dispositivo de seguridad debe operar en la capa

3, con interfaces de la zona de seguridad en modo NAT o de rutas. Cuando el
dispositivo de seguridad opera en la capa 2, con interfaces de la zona de seguridad
en modo transparente, no aparece informacin relacionada con el L2TP en el
WebUI y los comandos CLI relativos al L2TP provocan mensajes de error.
Encapsulado y desencapsulado de paquetes

El protocolo L2TP emplea el encapsulado de paquetes como forma de transportar
tramas PPP desde el LAC hasta el LNS. Antes de ver ejemplos especficos de
configuracin del L2TP y el L2TP sobre IPSec, se muestra un resumen del
encapsulado y desencapsulado implicados en el proceso L2TP.
214
Encapsulado
Cuando un usuario de acceso telefnico dentro de una red IP enva datos por un
tnel 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 telefnico se conecte al ISP local por un enlace PPP, el encapsulado ser
como se muestra en la Figura 55 en la pgina 215.
Figura 55: Encapsulado de paquetes L2TP
DATOS
IP
PPP
IP
PPP
CARGA DE DATOS
CARGA DE DATOS
L2TP
UDP
CARGA DE DATOS
CARGA DE DATOS
CARGA DE DATOS
CARGA DE DATOS
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 conexin fsica
entre el usuario de acceso telefnico y el ISP.
215
Desencapsulado
Cuando el LAC inicia el enlace PPP hacia el ISP, el desencapsulado y reenvo del
contenido anidado ser como se indica en la Figura 56 en la pgina 216.
Figura 56: Desencapsulado de paquetes L2TP
ISP
PPP
CARGA DE DATOS
IP
CARGA DE DATOS
UDP
CARGA DE DATOS
L2TP
CARGA DE DATOS
LNS
PPP
CARGA DE DATOS
IP
CARGA DE DATOS
DATOS
1. El ISP finaliza el enlace PPP y asigna una direccin IP al equipo del usuario.
En la carga PPP hay un paquete IP.
2. El ISP quita el encabezado PPP y reenva 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 nmero
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 tnel L2TP concreto. Despus, el LNS quita
el encabezado L2TP.
En la carga L2TP hay una trama PPP.
6. El LNS procesa la trama PPP y asigna una direccin lgica 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.
216
Ajuste de los parmetros L2TP

El LNS utiliza L2TP para proporcionar los ajustes PPP para un usuario de acceso
telefnico que habitualmente proviene de un ISP. Estos ajustes son los siguientes:
Direccin IP: el dispositivo de seguridad selecciona una direccin de un

conjunto de direcciones IP y la asigna al equipo del usuario de acceso
telefnico. El proceso de seleccin recorre cclicamente 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 de

seguridad proporciona estas direcciones para uso del equipo del usuario de
acceso telefnico.
Direcciones WINS de los servidores DNS primario y secundario: el dispositivo

de seguridad tambin proporciona estas direcciones para uso del equipo del
usuario de acceso telefnico.
El LNS tambin autentica al usuario mediante un nombre de usuario y una

contrasea. 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.
Adems, puede especificar uno de los siguientes esquemas para la autenticacin
PPP:
Challenge Handshake Authentication Protocol (CHAP), en el que el dispositivo

de seguridad enva un desafo (clave de cifrado) al usuario de acceso telefnico
despus de que l o ella haya hecho una peticin de enlace PPP, y el usuario
cifra su nombre de usuario y contrasea con la clave. La base de datos local y
los servidores RADIUS soportan CHAP.
Password Authentication Protocol (PAP), que enva la contrasea del usuario de

acceso telefnico en claro junto con la peticin de enlace PPP. La base de datos
local y los servidores RADIUS, SecurID, y LDAP soportan PAP.
ANY, lo que significa que el dispositivo de seguridad negocia el CHAP y si ste

falla, entonces el PAP.
Puede aplicar a los usuarios o grupos de usuarios de acceso telefnico los

parmetros predeterminados L2TP que se configuran en la pgina bsica de
configuracin de L2TP (VPN > L2TP > Default Settings) o con el comando set l2tp
default. Tambin puede aplicar los parmetros L2TP que se configuran
especficamente para los usuarios L2TP en la pgina de configuracin de usuario
(Users > Users > Local > New) o con el comando set user cadena_nombre
remote-settings. Los ajustes especficos de usuario L2TP reemplazan a los ajustes
predeterminados L2TP.
217
Como se muestra en la Figura 57 en la pgina 218, se define un conjunto de

direcciones IP en un rango de 10.1.3.40 a 10.1.3.100. Especifique las direcciones IP
de los servidores DNS 1.1.1.2 (primario) y 1.1.1.3 (secundario). El dispositivo de
seguridad realiza la autenticacin PPP mediante CHAP.
NOTA:
Especifique el servidor de autenticacin para cada tnel L2TP.
Figura 57: Conjunto de direcciones IP y ajustes predeterminados L2TP

RADIUS10.
1.1.245
Zona Trust
Zona Untrust
Nota: El conjunto de direcciones

L2TP debe pertenecer a una subred
distinta de la de la zona Trust.
Internet
ethernet1,
10.1.1.1/24
L2TP 10.1.3.40 10.1.3.100
DNS 1
1.1.1.2
DNS 2
1.1.1.3
ethernet3,
1.1.1.1/24
WebUI
1.
Objects > IP Pools > New: Introduzca los siguientes datos y haga clic en OK:
IP Pool Name: Sutro
Start IP: 10.1.3.40
End IP: 10.1.3.100
2.
Ajustes predeterminados de L2TP
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
CLI
1.
set ippool sutro 10.1.3.40 10.1.3.100

2.
set l2tp default ippool sutro

set l2tp default ppp-auth chap
set l2tp default dns1 1.1.1.2
set l2tp default dns2 1.1.1.3
save
218
L2TP y L2TP sobre IPSec

Aunque el usuario de acceso telefnico puede ser autenticado mediante CHAP o
PAP, el tnel L2TP no est encriptado, y por tanto no es un tnel VPN autntico.
El objetivo del L2TP es simplemente permitir al administrador del dispositivo de
seguridad local la asignacin de direcciones IP a un usuario de acceso telefnico
remoto. Por lo tanto, es posible introducir referencias a estas direcciones en las
directivas.
Para encriptar un tnel L2TP, es necesario aplicarle un esquema de encriptacin.
Puesto que L2TP supone que la red entre el LAC y el LNS es IP, se puede utilizar
IPSec para proporcionar la encriptacin. Esta combinacin se llama L2TP sobre
IPSec. L2TP sobre IPSec requiere el establecimiento de un tnel L2TP y otro IPSec
ambos con los mismos extremos, y despus enlazarlos en una directiva. L2TP sobre
IPSec requiere que el tnel IPSec est en modo de transporte para que la direccin
del extremo del tnel quede despejado. (Para obtener informacin sobre el modo
de transporte y el modo de tnel, consulte Modos en la pgina 4.)
Se puede crear un tnel L2TP entre un dispositivo de seguridad 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 de la pgina 213).
Se puede crear un tnel L2TP sobre IPSec entre un dispositivo de seguridad y
cualquiera de los siguientes clientes VPN:
NOTA:
Un host que ejecute NetScreen-Remote en los sistemas operativos

Windows 2000 o Windows NT
Un host que ejecute Windows 2000 (sin NetScreen-Remote)
Para proporcionar autenticacin cuando se utiliza Windows 2000 sin

NetScreen-Remote, se deben utilizar certificados.
Configuracin de L2TP
En este ejemplo, como se muestra en la Figura 58 en la pgina 220, se crea un
grupo de usuarios de acceso telefnico llamado fs (de field-sales) y se configura
un tnel L2TP llamado sales_corp, utilizando ethernet3 (Untrust zone) como
interfaz de salida de tnel L2TP. El dispositivo de seguridad aplica los siguientes
ajustes del tnel L2TP predeterminados al grupo de usuarios de acceso telefnico.
Los usuarios L2TP se autentican a travs de la base de datos local.
La autenticacin PPP utiliza CHAP.
El rango del conjunto de direcciones IP (denominado global) es de

10.10.2.100 a 10.10.2.180.
Los servidores DNS son 1.1.1.2 (primario) y 1.1.1.3 (secundario).
219
NOTA:
Una configuracin con slo L2TP no es segura. Se recomienda slo para

depuracin
El conjunto de direcciones IP de L2TP debe pertenecer a una subred distinta de la
de las direcciones de la red corporativa.
Figura 58: Configuracin de L2TP

Grupo de usuarios
Auth/L2TP de acceso
telefnico: fs
Adam
Zona de acceso
telefnico
DNS1: 1.1.1.2
DNS2: 1.1.1.3
Conjunto de direcciones
IP: global 10.10.2.100
10.10.2.180
Red
corporativa
Zona Trust
Betty
Internet
Carol
Tnel L2TP:
sales_corp
Clientes
NetScreen-Remote
Interfaz de salida
ethernet3, 1.1.1.1/24
ethernet1,
10.1.1.1/24
Los clientes remotos L2TP usan el sistema operativo Windows 2000. Para obtener
informacin sobre la configuracin del L2TP en los clientes remotos, consulte la
documentacin de Windows 2000. A continuacin se proporciona slo la
configuracin del dispositivo de seguridad al final del tnel L2TP.
WebUI
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
220
2.
Usuarios L2TP
en OK:
User Name: Adam
Status: Enable
L2TP User: (seleccione)
User Password: AJbioJ15
Confirm Password: AJbioJ15
en OK:
User Name: Betty
Status: Enable
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
en OK:
User Name: Carol
Status: Enable
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
3.
Grupo de usuarios L2TP
Objects > User > Local Groups> New: Escriba fs en el campo Group Name,
realice la accin que se indica a continuacin y despus haga clic en OK:
Seleccione Adam y utilice el botn << para trasladarlo de la columna
Seleccione Betty y utilice el botn << para trasladarla de la columna
Seleccione Carol y utilice el botn << para trasladarla de la columna
4.
IP Pool Name: global
Start IP: 10.10.2.100
End IP: 10.10.2.180
en OK:
221
5.
Tnel 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
Host Name (optional): Introduzca el nombre del equipo que acta como LAC.
Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS.
Keep Alive: 60
Peer IP: Debido a que el ISP del interlocutor le asigna dinmicamente una direccin
IP, ingresara en el ejemplo anterior 0.0.0.0.
LAC: Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo
siguiente: Haga clic en Inicio > Configuracin > Panel de Control > Sistema.
Aparece el cuadro de dilogo de propiedades del sistema. Haga clic en la ficha de
Identificacin de red, y consulte la entrada Nombre completo del equipo.
Para aadir un secreto al LAC para autenticar el tnel 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 botn 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 Edit, resalte la opcin New y luego seleccione String Value.
6. Escriba Password.
7. Haga doble clic en Password. Aparece el cuadro de dilogo Edit String.
8. Escriba la contrasea en el campo Value data. Debe coincidir con la palabra
introducida en el campo L2TP Tunnel Configuration Secret en el dispositivo de
seguridad.
9. Reinicie el equipo Windows 2000.
Cuando se utiliza L2TP sobre IPSec, que es la opcin predeterminada de
Windows 2000, no es necesaria la autenticacin del tnel; todos los mensajes
L2TP son encriptados y autenticados por IPSec.
Keep Alive: El valor Keep Alive (mantenimiento de conexin) es el nmero de
segundos de inactividad antes de que el dispositivo de seguridad enve una seal
Hello L2TP al LAC.
222
6.
Ruta
Network > Routing > Routing Entries > New: Introduzca los siguientes datos
y haga clic en OK:
7.
Directiva
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Any
NAT: Off
Service: ANY
Action: Tunnel
Tunnel L2TP: sales_corp
CLI
1.
Usuarios de acceso telefnico
set user adam type l2tp

set user adam password AJbioJ15
unset user adam type auth
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
NOTA:
Definir una contrasea para un usuario le clasifica automticamente 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.
2.
Grupo de usuarios L2TP
set
set
set
set
3.
set
set
set
set
set
set
4.
user-group fs location local

user-group fs user adam
user-group fs user betty
user-group fs user carol
ippool global 10.10.2.100 10.10.2.180
l2tp default ippool global
l2tp default auth server Local
l2tp default ppp-auth chap
l2tp default dns1 1.1.1.2
Tnel L2TP
set l2tp sales_corp outgoing-interface ethernet3

set l2tp sales_corp auth server Local user-group fs
223
5.
Ruta

6.
Directiva
set policy top from untrust to trust Dial-Up VPN any any tunnel l2tp sales_corp
save
Configuracin de L2TP sobre IPSec

Este ejemplo utiliza el tnel L2TP creado en el ejemplo anterior (Configuracin de
L2TP en la pgina 219). Adems, se superpone un tnel IPSec al tnel L2TP para
proporcionar encriptacin. El tnel IPSec negocia la fase 1 en modo agresivo
utilizando un certificado RSA previamente cargado, cifrado 3DES y autenticacin
SHA-1. La autoridad de certificacin (CA) ser Verisign. (Para obtener informacin
sobre la obtencin y carga de certificados, consulte el Captulo 2, Criptografa de
claves pblicas.). El tnel IPSec est en modo de transporte.
La zona Trust predefinida y la zona de acceso telefnico definida por el usuario se
encuentran en el dominio de enrutamiento trust-vr. Las interfaces para las zonas de
acceso telefnico 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 telefnico Adam, Betty y Carol utilizan clientes
NetScreen-Remote sobre un sistema operativo Windows 2000. La configuracin de
NetScreen-Remote para el usuario de acceso telefnico Adam tambin se incluye en
lo que sigue. (La configuracin del NetScreen-Remote para los otros dos usuarios de
acceso telefnico es la misma que para Adam.)
NOTA:
Para configurar un tnel L2TP sobre IPSec para Windows 2000 (sin
NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y
el tipo de identificacin IKE debe ser ASN1-DN.
Figura 59: Configuracin de L2TP sobre IPSec

Grupo de usuarios IKE-L2TP
de acceso telefnico: fs
Adam
Zona de acceso
telefnico
DNS1: 1.1.1.2
DNS2: 1.1.1.3
Conjunto de direcciones
IP: global 10.10.2.100
10.10.2.180
Red
corporativa
Zona Trust
Betty
Internet
Carol
Clientes
NetScreen-Remote
224
Tnel L2TP: sales_corp

Tnel VPN: from_sales
Interfaz de salida
ethernet2, 1.1.1.1/24
ethernet1,
10.1.1.1/24
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 seleccin)
NOTA:
La zona Trust est preconfigurada. No es necesario crearla.

2.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Dialup
3.
Usuarios IKE/L2TP
en OK:
User Name: Adam
Status: Enable
IKE Identity: ajackson@abc.com
User Password: AJbioJ15
Confirm Password: AJbioJ15
NOTA:
La ID IKE debe ser la misma que la que enva el cliente NetScreen-Remote, que es
la direccin de correo electrnico que aparece en el certificado que el cliente
utiliza para la autenticacin.
225
en OK:
User Name: Betty
Status: Enable
IKE Identity: bdavis@abc.com
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
en OK:
User Name: Carol
Status: Enable
IKE Identity: cburnet@abc.com
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
4.
Grupo de usuarios IKE/L2TP
Objects > Users > Local Groups > New: Escriba fs en el campo Group Name,
realice la accin que se indica a continuacin y despus haga clic en OK:
Seleccione Adam y utilice el botn << para trasladarlo de la columna
Seleccione Betty y utilice el botn << para trasladarla de la columna
Seleccione Carol y utilice el botn << para trasladarla de la columna
5.
Start IP: 10.10.2.100
End IP: 10.10.2.180
6.
en Apply:
226
7.
Tnel L2TP
en OK:
Name: sales_corp
Dialup Group: (seleccione) Local Dialup Group - fs
Authentication Server: Local
Peer IP: 0.0.0.0
Host Name (optional): Si desea restringir el tnel L2TP a un host especfico,

introduzca el nombre del equipo que acta como LAC.
Secret (optional): Introduzca un secreto compartido entre el LAC y el LNS.
Keep Alive: 60
LAC: Para encontrar el nombre del equipo que ejecuta Windows 2000, haga lo
siguiente: Haga clic en Inicio > Configuracin > Panel de Control > Sistema.
Aparece el cuadro de dilogo de propiedades del sistema. Haga clic en la ficha de
Identificacin de red, y consulte la entrada Nombre completo del equipo.
Secret: Para aadir un secreto al LAC para autenticar el tnel 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 botn 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 Edit, resalte la opcin New y luego seleccione String Value.
6. Escriba Password.
7. Haga doble clic en Password. Aparece el cuadro de dilogo Edit String.
8. Escriba la contrasea en el campo Value data. Debe coincidir con la palabra
introducida en el campo L2TP Tunnel Configuration Secret en el dispositivo de
seguridad.
9. Reinicie el equipo Windows 2000.
Cuando se utiliza L2TP sobre IPSec, que es la opcin predeterminada de
Windows 2000, no es necesaria la autenticacin del tnel; todos los mensajes
L2TP son encriptados y autenticados por IPSec.
Keep Alive: El valor Keep Alive (mantenimiento de conexin) es el nmero de
segundos de inactividad antes de que el dispositivo de seguridad enve una seal
Hello L2TP al LAC.
227
NOTA:
El nombre del host y los ajustes del secreto pueden pasarse por alto. Se
recomienda que slo los usuarios avanzados utilicen estos ajustes.
8.
Tnel VPN
y haga clic en OK:
Gateway Name: field
Dialup User Group: (seleccione), Group: fs

en Return para regresar a la pgina de configuracin bsica de Gateway:
Security Level: User Defined: Custom
Phase 1 Proposal: rsa-g2-3des-sha
Peer CA: Verisign
Peer Type: X509-SIG
NOTA:
Windows 2000 (sin NetScreen-Remote) slo admite negociaciones en modo

principal.
Name: from_sales
Remote Gateway: Predefined: field

IKE:
Transport Mode: (seleccione)
9.
Directiva
Policies > (From: Dialup, To: Trust) New: Introduzca los siguientes datos y haga
clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: from_sales
L2TP: sales_corp
228
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
set
set
set
5.
user-group fs location Local

user-group fs user adam
user-group fs user betty
user-group fs user carol
set ippool global 10.10.2.100 10.10.2.180

6.
set
set
set
set
7.
l2tp default ippool global

l2tp default ppp-auth chap
Tnel L2TP
set l2tp sales_corp outgoing-interface ethernet2

set l2tp sales_corp auth server Local user-group fs
8.
Tnel VPN
set ike gateway field dialup fs aggressive outgoing-interface ethernet2 proposal

rsa-g2-3des-sha
set ike gateway field cert peer-ca1
set ike gateway field cert peer-cert-type x509-sig
set vpn from_sales gateway field transport sec-level compatible
229
NOTA:
Windows 2000 (sin NetScreen-Remote) slo admite negociaciones en modo

principal.
9.
Directiva
set policy top from dialup to trust Dial-Up VPN any any tunnel vpn from_sales
l2tp sales_corp
save
Editor de directivas de seguridad de NetScreen-Remote (Adam)

Para configurar los tneles L2TP sobre IPSec para los clientes NetScreen-Remote de
Betty y Carol, siga el procedimiento que aqu se describe para Adam.
2. Haga clic en Add a new connection y escriba AJ junto al icono de nueva
IP Address: 1.3.3.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (anule la seleccin)
4. Haga clic en el signo MS situado a la izquierda del icono de AJ para ampliar la

directiva de la conexin.
5. Haga clic en My Identity y configure lo siguiente:
Select the certificate with the email address specified as the users IKE ID on
the security device from the Select Certificate dropdown list:
ID Type: Direccin de correo electrnico
Port: L2TP
NOTA:

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode.
7. Haga clic en el smbolo MS situado a la izquierda del icono Security Policy y,
a continuacin, en el smbolo MS situado a la izquierda de Authentication
(Phase 1) y de Key Exchange (Phase 2) para ampliar ms an la directiva.
230

(o bien)
Hash Alg: SHA-1
Key Group: Grupo de Diffie-Hellman 2
protocolos IPSec:
Hash Alg: SHA-1
Encapsulation: Transport
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
Encrypt Alg: DES
Hash Alg: MD5

14. Tambin es necesario configurar la conexin de red para Windows 2000
utilizando el asistente para conexin de red.
NOTA:
Cuando se configura el asistente para conexin de red, se debe introducir un

nombre de host destino o una direccin IP. Introduzca 1.3.3.1. Posteriormente,
cuando inicie una conexin y el sistema le solicite un nombre de usuario y una
contrasea, introduzca adam, AJbioJ15. Para ms informacin, consulte la
documentacin de Microsoft Windows 2000.
231
L2TP sobre IPSec bidireccional

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. Crear tneles L2TP sobre IPSec entre un usuario de acceso
telefnico NetScreen-Remote y una LAN corporativa. El usuario remoto trabaja con
una aplicacin X-Windows, lo que requiere establecer directivas bidireccionales.
Configurar las directivas entrantes y salientes para el tnel VPN de acceso
telefnico AutoKey IKE denominado VPN_dial para el usuario IKE dialup-j con la ID
de IKE jf@ns.com. y el tnel L2TP denominado tun1. El usuario IKE inicia una
conexin IPSec al dispositivo de seguridad desde la zona Untrust para acceder a los
servidores corporativos de la zona Trust. En este punto, solamente se permite la
comunicacin L2TP. Despus de la negociacin L2TP/PPP, se establece el tnel
L2TP. Con las directivas bidireccionales configuradas, el trfico puede iniciarse
desde cualquier extremo del tnel.
El usuario de acceso telefnico dialup-j utiliza un cliente NetScreen-Remote con el
sistema operativo Windows 2000. La configuracin de NetScreen-Remote para el
usuario de acceso telefnico dialup-j aparece despus de la Figura 60 en la
pgina 232.
Figura 60: L2TP sobre IPSec bidireccional
ethernet3
1.1.1.1/24
ethernet3
10.1.1.1/24
Zona de acceso telefnico

Zona Trust
Internet
LAN
Tnel L2TP sobre

IPSec
Cliente de NetScreen-Remote
ejecutando X-Windows Server
NOTA:
Enrutador
externo1.1.1.250
Servidor UNIX
Para configurar un tnel L2TP sobre IPSec para Windows 2000 (sin
NetScreen-Remote), las negociaciones de la fase 1 deben ser en modo principal y
el tipo de identificacin IKE debe ser ASN1-DN.
WebUI
1.
Interfaces
haga clic en Apply:
Zone Name: Trust

Interface Mode: NAT
232
haga clic en OK:
Zone Name: Untrust
2.
Direccin
Address Name: trust_net
Zone: Trust
3.
Usuario L2TP/IKE
en OK:
User Name: dialup-j
Status: Enable
IKE Identity: jf@ns.com
Authentication User: (seleccione)
User Password: abc123
Confirm Password: abc123
NOTA:
La ID IKE debe ser la misma que la que enva el cliente NetScreen-Remote, que es
la direccin de correo electrnico que aparece en el certificado que el cliente
utiliza para la autenticacin.
4.
L2TP
en OK:
Name: tun1
Use Default Settings: (seleccione)
Secret: netscreen
Keepalive: 60
5.
VPN
y haga clic en OK:
Security Level: (select), Standard
Remote Gateway Type: Dialup User; (seleccione), dialup-j
Preshared Key: n3TsCr33N
Outgoing Interface: (select), ethernet3
233
> Advanced: Introduzca los siguientes datos y haga clic en Return para
regresar a la pgina de configuracin bsica 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
> Advanced: Introduzca los siguientes datos y haga clic en Return para
regresar a la pgina de configuracin bsica de AutoKey IKE:
Security Level: Standard (seleccione)
Transport Mode (slo para L2TP sobre IPSec): (seleccione)
6.
Ruta
Network > Routing > Routing Entries > New: Introduzca los siguientes datos
y haga clic en OK:
7.
Directivas
Policies > (From: Untrust, To: Trust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
L2TP: (seleccione) tun1
Policies > (From: Trust, To: Untrust) > New: Introduzca los siguientes datos y
haga clic en OK:
Source Address:
Service: ANY
Action: Tunnel
Tunnel VPN: VPN_dial
L2TP: tun1
234
CLI
1.
Interfaces

2.
Direccin
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
IP Address: 1.1.1.1
Protocol: UDP
Port: L2TP
Connect using Secure Gateway Tunnel: (anule la seleccin)
4. Haga clic en el signo MS situado a la izquierda del icono de dialup-j para

235
5. Haga clic en My Identity y configure lo siguiente:

En la lista desplegable Select Certificate, seleccione el certificado con la
direccin de correo especificada como la ID IKE del usuario en el dispositivo de
seguridad.
ID Type: Direccin de correo electrnico
Port: L2TP
NOTA:

6. Haga clic en el icono Security Policy y seleccione Aggressive Mode.
7. Haga clic en el smbolo MS situado a la izquierda del icono Security Policy y,
a continuacin, en el smbolo MS situado a la izquierda de Authentication
(Phase 1) y de Key Exchange (Phase 2) para ampliar ms an la directiva.
(o bien)
Hash Alg: SHA-1
Key Group: Grupo de Diffie-Hellman 2
NOTA:
Si la opcin Perfect Forwarding Secrecy (PFS) est activada en el dispositivo de

seguridad (grupo DF 1, 2 5), tambin debe estar activada para el cliente VPN en
NetScreen-Remote.
protocolos IPSec:
Hash Alg: SHA-1
Hash Alg: MD5
Encrypt Alg: DES
Hash Alg: SHA-1
236
Encrypt Alg: DES
Hash Alg: MD5

Tambin es necesario configurar la conexin de red para Windows 2000 utilizando
el asistente para conexin de red.
NOTA:
Cuando se configura el asistente para conexin de red, se debe introducir un

nombre de host destino o una direccin IP. Introduzca 1.1.1.1. Posteriormente,
cuando inicie la conexin y se le solicite el nombre de usuario y la contrasea,
introduzca dialup-j, abc123. Para ms informacin, consulte la documentacin de
Microsoft Windows 2000.
237
238
Captulo 7
Funciones avanzadas de redes privadas

virtuales
Este captulo abarca los siguientes usos de la tecnologa de redes privadas virtuales
(VPN):
NAT-Traversal en la pgina 240
Sondeos de NAT en la pgina 241
Atravesar un dispositivo NAT en la pgina 243
Suma de comprobacin de UDP en la pgina 245
Paquetes de mantenimiento de conexin en la pgina 246
Simetra iniciador/respondedor en la pgina 246
Habilitacin de NAT-Traversal en la pgina 248
Uso de identificaciones de IKE con NAT-Traversal en la pgina 249
Supervisin de VPN en la pgina 250
Opciones de reencriptacin y optimizacin en la pgina 251
Interfaz de origen y direccin de destino en la pgina 252
Consideraciones sobre directivas en la pgina 253
Configuracin de la funcin de supervisin de VPN en la pgina 254
Objetos y capturas SNMP para la supervisin de VPN en la pgina 262
Mltiples tneles por interfaz de tnel en la pgina 263
Asignacin de rutas a tneles en la pgina 264
Direcciones de interlocutores remotos en la pgina 266
Entradas de tabla manuales y automticas en la pgina 267
239
Puertas de enlace VPN redundantes en la pgina 301
Grupos VPN en la pgina 302
Mecanismos de supervisin en la pgina 303
Comprobacin de indicador TCP SYN en la pgina 307
Creacin de VPN adosadas en la pgina 314
Creacin de VPN radiales en la pgina 321
NAT-Traversal
Las normas de Internet NAT (traduccin de direcciones de red, Network Address
Translation ) y NAPT (traduccin de puertos de direcciones de red, Network Address
Port Translation) permiten que una red de rea local (LAN) utilice un grupo de
direcciones IP para el trfico interno y un segundo grupo de direcciones para el
trfico externo. Los dispositivos NAT generan estas direcciones externas utilizando
conjuntos predeterminados de direcciones IP.
Cuando se configura un tnel 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 de protocolo de datagrama de usuarios UDP
(User Datagram Protocol). Sin embargo, si se aplica NAT a los paquetes IPSec una
vez finalizadas las negociaciones de fase 2, el tnel fallar. Una de las muchas
razones por las que NAT provoca el fallo de IPSec es que en el protocolo de
seguridad encapsulada ESP (Encapsulating Security Protocol), los dispositivos NAT
no pueden distinguir la ubicacin del encabezado de capa 4 para la traduccin del
puerto (porque est encriptado). En el protocolo de encabezado de la autenticacin
(AH, o Authentication Header), los dispositivos NAT no pueden modificar el
nmero de puerto, pero falla la comprobacin de autenticacin, que incluye el
paquete IPSec completo.
NOTA:
Para obtener una lista de las incompatibilidades IPSec/NAT, consulte el documento

draft-ietf-ipsec-nat-regts-00.txt de Bernard Aboba.
Para solucionar estos problemas, los dispositivos de seguridad y el cliente
NetScreen-Remote (versin 6.0 o posterior) pueden aplicar una funcin
NAT-Traversal (NAT-T). NAT-T agrega una capa de encapsulacin UDP a los paquetes
IPSec si detecta al menos un dispositivo NAT en la ruta de datos durante los
intercambios de fase 1, segn 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 ms recientes de estas especificaciones.
NOTA:
240
NAT-Traversal
NetScreen-Remote 6 y NetScreen-Remote 7 son compatibles con NAT-T segn 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.
Captulo 7: Funciones avanzadas de redes privadas virtuales
Los dispositivos NAT pueden crear otro problema si tambin estn preparados para
IKE/IPSec e intentan procesar paquetes con el nmero de puerto IKE 500 o con los
nmeros de protocolo 50 (para ESP) y 51 (para AH). Para evitar ese procesamiento
intermedio de paquetes IKE, la versin 2 de las especificaciones IETF previamente
mencionadas propone el desplazamiento (o flotacin) de los nmeros 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 (para ESP o AH, respectivamente) a 17 (para UDP). Adems,
el encabezado UDP insertado tambin utiliza el puerto 4500. La versin 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
versin 0 de estas especificaciones.
NOTA:
NetScreen no admite NAT-T para los tneles de clave manual ni para el trfico
IPSec usando AH. ScreenOS slo admite NAT-T para tneles AutoKey IKE con ESP.
Sondeos de NAT
Para comprobar si ambos extremos del tnel VPN admiten NAT-T, ScreenOS enva
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 ttulo de la
especificacin 0 y otro para el ttulo de la especificacin 2:
4485152d 18b6bbcd 0be8a846 9579ddcc, que es una transformacin

(hash) MD-5 de draft-ietf-ipsec-nat-t-ike-00
90cb8091 3ebb696e 086381b5 ec427b1f, que es una transformacin

(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 contine. Si envan
hashes correspondientes a ambas especificaciones, ScreenOS utiliza la
implementacin NAT-T correspondiente a la especificacin 2.
Si los dispositivos de cada punto terminal admiten NAT-T, se envan 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 dinmico). La carga de datos de descubrimiento NAT (Nat-Discovery o
NAT-D) es un tipo de carga de datos IKE para NAT-T. El nmero 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 pgina 13.
NOTA:
ScreenOS puede manejar varias cargas de datos de descubrimiento NAT (NAT-D)

en una negociacin IKE.
NAT-Traversal
241
Las cargas de datos de NAT-D contienen un hash negociado de la siguiente

informacin:
NOTA:
Hash del destino NAT-D:
Cookie del iniciador (CKY-I)
Cookie del respondedor (CKY-R)
Direccin IP del interlocutor IKE remoto (de destino)
Nmero del puerto de destino
Hash del origen NAT-D (uno o varios):
Cookie del iniciador (CKY-I)
Cookie del respondedor (CKY-R)
Direccin IP del interlocutor IKE local (de origen)
Nmero del puerto de origen
NAT-T admite mltiples hashes de origen NAT-D para dispositivos equipados con
mltiples interfaces e implementaciones que no especifiquen una interfaz
saliente.
Cuando cada interlocutor compara los hashes que recibe con los que enva, puede
reconocer si entre ellos se ha producido una traduccin de direcciones. La
identificacin de los paquetes modificados implica la de la ubicacin del dispositivo
NAT:
242
NAT-Traversal
Si
coincide con
entonces
el hash de destino del

interlocutor local
al menos uno de los hashes de

origen del interlocutor remoto
no se ha producido ninguna
traduccin de direcciones.
al menos uno de los hashes

de origen del interlocutor
local

interlocutor remoto
traduccin de direcciones.
Si
no coincide con
entonces

interlocutor local
al menos uno de los hashes de

origen del interlocutor remoto
traduccin de direcciones
al menos uno de los hashes

de origen del interlocutor
local

interlocutor remoto
traduccin de direcciones
Conocer la ubicacin del dispositivo NAT es importante porque los paquetes de

mantenimiento de conexin IKE deben iniciarse desde el interlocutor situado
detrs del dispositivo NAT. Consulte Paquetes de mantenimiento de conexin en
la pgina 246.
Si ambos interlocutores cumplen la especificacin IETF 2, tambin desplazan
(flotan) el nmero 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 nmeros de puertos flotan a 4500 en el quinto y el sexto intercambios
de la fase 1, y posteriormente durante todos los intercambios de la fase 2. En modo
dinmico, el nmero 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 tambin utilizan 4500 como nmero de puerto UDP para todo el
trfico IPSec subsiguiente.
Atravesar un dispositivo NAT

En la Figura 61, un dispositivo NAT situado en el permetro de la LAN de un hotel
recibe un paquete de un cliente de acceso telefnico a VPN con la direccin
IP 2.1.1.5, asignada por el hotel. Para todo el trfico saliente, el dispositivo NAT
sustituye la direccin IP de origen en el encabezado externo por la nueva direccin
2.2.2.2. Durante las negociaciones de la fase 1, el cliente VPN y el dispositivo de
seguridad 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.
Figura 61: NAT-Traversal
Empresa
Hotel
Dispositivo NAT
Internet
Dispositivo de seguridad
Tnel VPN
Cliente VPN telefnico
IP de origen 200.1.1.1 -> 210.2.2.2
Si se encapsulan los paquetes IPSec dentro de paquetes UDP (cosa que harn tanto
el cliente VPN como el dispositivo de seguridad) se resuelve el problema de fallo en
la comprobacin de autenticacin. 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 tendrn problemas en la comprobacin de autenticacin,
ya que los contenidos autenticados no habrn cambiado.
NAT-Traversal
243
Puede presentarse otro problema si el dispositivo NAT est preparado para

IKE/IPSec. Un dispositivo NAT preparado para IKE/IPSec podra intentar procesar el
trfico IKE/IPSec en lugar de reenviarlo. Para impedir tal procesamiento intermedio,
NAT-T (v2) cambia los nmeros de puertos UDP de origen y de destino para IKE de
500 a 4500. NAT-T tambin inserta un marcador no-ESP en el encabezado UDP
justo antes de la carga de datos. Para el trfico IPSec, NAT-T (v0 y v2) inserta un
encabezado UDP entre el encabezado IP externo y el encabezado ESP. El paquete
UDP tambin utiliza 4500 como nmero de ambos puertos, el de origen y el de
destino.
Segn 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 sabra 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 se muestra en la Figura 62 en la pgina 244, despus de detectar un
dispositivo NAT en la ruta de datos, los nmeros 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 tnel 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.
Figura 62: Paquete IKE (para las fases 1 y 2)
Encabezado
IP
Encabezado
UDP
Encabezado
ISAKMP
Carga de datos
Nota: ISAKMP es el formato de paquetes utilizado por IKE.

Segmento UDP

Suma de comprobacin
Longitud
Carga de datos
Segmento UDP despus de detectar un dispositivo NAT

Suma de comprobacin
Longitud
Marcador no ESP (0000)
Carga de datos
244
NAT-Traversal
La Figura 63 muestra cmo despus de detectar un dispositivo NAT en la ruta de

datos, los puntos terminales del tnel VPN insertan un encabezado UDP adicional
entre el encabezado IP externo y el encabezado ESP de un paquete IPSec. Dado que
no hay ningn marcador no ESP, el receptor puede distinguir el paquete ESP
encapsulado de un paquete ISAKMP y desmultiplexar el paquete ESP
correctamente.
Figura 63: Paquete IPSec ESP antes y despus de la deteccin de NAT
Paquete IPSec ESP antes de detectar un dispositivo NAT
Paquete IPSec
Enviado por la puerta
Encabezado
IP2
Encabezado
ESP
Paquete original
Enviado por el host iniciador
Encabezado Encabezado
IP1
TCP
Carga de datos

Paquete IPSec ESP despus de detectar un dispositivo NAT
Paquete IPSec
Callouts
Paquete original
Enviado por la puerta
de enlace IKE
Enviado por el host iniciador
Encabezado Encabezado Encabezado Encabezado Encabezado
Carga de datos
IP2
UDP
ESP
IP1
TCP
Encabezado UDP
Longitud
Suma de comprobacin
Carga de datos
Suma de comprobacin de UDP

Todos los paquetes UDP contienen una suma de comprobacin de UDP, un valor
calculado que garantiza que los paquetes UDP no tienen errores de transmisin. Los
dispositivos de seguridad no necesitan utilizar la suma de comprobacin de UDP
para NAT-T, de modo que la WebUI y la CLI presentan la suma de comprobacin
como ajuste opcional. An as, ciertos dispositivos NAT precisan de suma de
comprobacin, por lo que puede ser necesario habilitar o inhabilitar esta opcin. De
forma predeterminada, al habilitar NAT-T se incluye la suma de comprobacin UDP.
NAT-Traversal
245
WebUI
VPN > AutoKey Advanced > Gateway > New:
Introduzca los parmetros necesarios para la nueva puerta de enlace del tnel,
segn se describe en Redes privadas virtuales de punto a punto en la
pgina 81 o en Redes privadas virtuales de acceso telefnico en la
pgina 163; introduzca los siguientes datos y, finalmente, haga clic en OK:
enlace:
UDP Checksum: Enable
CLI
set ike gateway nombre nat-traversal udp-checksum
unset ike gateway nombre nat-traversal udp-checksum
Paquetes de mantenimiento de conexin

Cuando un dispositivo NAT asigna una direccin IP a un host, el dispositivo NAT
determina el intervalo de tiempo que la nueva direccin ser vlida si no hay
trfico. Por ejemplo, un dispositivo NAT podra invalidar cualquier direccin IP
generada que no se utilice durante 20 segundos. Por eso, suele ser necesario que los
participantes IPSec enven peridicamente paquetes keepalive de mantenimiento
de conexin (paquetes UDP vacos) a travs del dispositivo NAT, de forma que la
asignacin NAT no cambie hasta que las asociaciones de seguridad (SA) de fase 1 y
fase 2 expiren.
NOTA:
Los dispositivos NAT tienen distintos intervalos de tiempo de espera de sesin,

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 conexin por debajo de dicho intervalo.
Simetra iniciador/respondedor
Cuando dos dispositivos de seguridad establecen un tnel 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 simetra
iniciador/respondedor podra llegar a ser imposible. Esto sucede cuando el
dispositivo NAT genera direcciones IP dinmicamente.
246
NAT-Traversal
Figura 64: Dispositivo de seguridad con una direccin IP asignada dinmicamente detrs de un dispositivo NAT
Nota: Las zonas de seguridad ilustradas se
muestran desde la perspectiva del
Zona Untrust
dispositivo-B.
Dispositivo A
Host A
Zona Trust
Dispositivo
NAT
Internet
Host B
10.1.1.5
Zona
1.2.1.1
Conjunto de
direcciones IP
1.2.1.2 - 1.2.1.50
Dispositivo B
1.1.1.250
El dispositivo NAT traduce la direccin IP de origen en
paquetes que recibe del dispositivo-B, utilizando
direcciones que toma de su conjunto de direcciones IP.
En la Figura 64, el dispositivo 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 el dispositivo B (tomndolas dinmicamente de un
conjunto de direcciones IP), el dispositivo A no puede identificar inequvocamente
al dispositivo B. Por lo tanto, el dispositivo A no podr iniciar con xito un tnel con
el dispositivo B. El dispositivo A debe actuar como respondedor, el dispositivo B
como iniciador y ambos deben realizar las negociaciones de fase 1 en modo
dinmico.
No obstante, si el dispositivo NAT genera la nueva direccin IP utilizando una
direccin IP asignada (MIP) o cualquier otro mtodo de direccionamiento 1:1, el
dispositivo A podr identificar de forma exclusiva al dispositivo B. En consecuencia,
tanto el dispositivo A como el dispositivo B podrn actuar como iniciadores y
ambos podrn utilizar el modo principal o dinmico en la fase 1.
NOTA:
Si habilita NAT-T en un dispositivo de seguridad que acta como respondedor y lo

configura para que lleve a cabo las negociaciones IKE en modo principal, ese
dispositivo y todos sus interlocutores configurados en la misma interfaz de salida
debern usar las mismas propuestas de fase 1 y presentadas en el mismo orden.
Los interlocutores podrn ser de los siguientes tipos:
Homlogo dinmico (interlocutores con direcciones IP asignadas dinmicamente)
Usuarios VPN de acceso telefnico
Interlocutores con direcciones IP estticas 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 debern 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 de
seguridad comprueba automticamente que todas las propuestas de fase 1 sean
iguales y tengan el mismo orden. Si las propuestas son distintas, el dispositivo de
seguridad generar un mensaje de error.
NAT-Traversal
247
Habilitacin de NAT-Traversal
En la Figura 65, un dispositivo NAT ubicado en el permetro de la red local (LAN) de
un hotel asigna una direccin al cliente VPN de acceso telefnico utilizado por Jose,
un comercial que est participando en una convencin. Para que Jose pueda
acceder a la LAN corporativa por medio de un tnel VPN de acceso telefnico, se
debe habilitar NAT-T para la puerta de enlace remota jose, configurada en el
dispositivo de seguridad y para la puerta de enlace remota, configurada en el cliente
VPN de acceso telefnico. Tambin deber habilitar el dispositivo de seguridad para
que incluya una suma de comprobacin de UDP en sus transmisiones, y establecer
una frecuencia de mantenimiento de conexin de 8 segundos.
Figura 65: Habilitacin de NAT-Traversal
Empresa
Hotel
Dispositivo NAT
Internet
Dispositivo de seguridad
Tnel VPN
Cliente VPN telefnico
WebUI
VPN > AutoKey Advanced > Gateway > New: Introduzca los parmetros
necesarios para la nueva puerta de enlace del tnel, segn se describe en el
Captulo 4, Redes privadas virtuales de punto a punto, o en el Captulo 5,
Redes privadas virtuales de acceso telefnico, introduzca los datos siguientes
y, a continuacin, haga clic en OK:
enlace:
UDP Checksum: Enable
Keepalive Frequency: 8 seconds (0~300 sec.)
NOTA:
Cuando se configura una VPN de acceso telefnico con CLI, el dispositivo de

seguridad activa automticamente NAT-Traversal.
CLI
set ike gateway jose nat-traversal
set ike gateway jose nat-traversal udp-checksum
set ike gateway jose nat-traversal keepalive-frequency 8
save
248
NAT-Traversal
Uso de identificaciones de IKE con NAT-Traversal

Cuando dos puertas de enlace VPN negocian en el modo principal, intercambian las
direcciones IP para identificarse entre s y activar el tnel. Cuando los dispositivos
situados en uno o ambos extremos del tnel tienen direcciones IP asignadas
dinmicamente, no obstante, deber configurar las identificaciones IKE (ID local e
ID del interlocutor) en los dispositivos situados en ambos extremos del tnel. Una
identificacin IKE es un identificador nico que permanece esttico. La
identificacin IKE se configura durante la fase cuando configura la puerta de enlace
IKE. Configurar las identificaciones IKE en lugar de la direccin IP remota.
Sin NAT-T, un tnel VPN se puede activar con slo utilizar la ID local en el lado local
y slo la ID del interlocutor en el lado remoto. Sin embargo, al utilizar NAT-Traversal
con la VPN dinmica en el modo principal con certificados, debe establecer tanto la
ID local como la ID del interlocutor en ambos lados del tnel VPN. El siguiente
ejemplo muestra cmo puede configurar las ID locales y las ID de interlocutores en
el cortafuegos1 y cortafuegos2 para que se puedan identificar entre s y activar un
tnel entre las mismas.
WebUI
En el cortafuegos1, introduzca lo siguiente:
VPN > AutoKey IKE Advanced> Gateway > New (introduzca lo siguiente y
haga clic en Advanced:
Gateway Name: test_gw
Address/Hostname: 0.0.0.0
Peer-ID: cortafuegos2
Haga clic en Advanced e introduzca lo siguiente:

Security Level: Standard
Local-ID: cortafuegos1
Outgoing Interface: ethernet0/0
Mode: Main

VPN > AutoKey IKE Advanced> Gateway > New (introduzca lo siguiente y
haga clic en Advanced:
Gateway Name: gw_bap15_p1
Address/Hostname: 1.1.1.1
Peer-ID: cortafuegos1
Haga clic en Advanced e introduzca lo siguiente:

Local-ID: cortafuegos2
Outgoing Interface: ethernet0/0
Mode: Main
NAT-Traversal
249
CLI
set ike gateway test-gw address 0.0.0.0 id cortafuegos2 main local-id
cortafuegos1 outgoing-interface ethernet0/0 proposal standard

set ike gateway gw_bap15_p1 address 1.1.1.1 id cortafuegos1 main local-id
cortafuegos2 outgoing-interface ethernet0/0 proposal standard
Supervisin de VPN
Cuando se habilita la supervisin de VPN para un tnel especfico, el dispositivo de
seguridad enva peticiones de eco ICMP (o pings) a travs del tnel en intervalos
determinados (configurados en segundos) para supervisar la conectividad de la red
a travs del tnel.
NOTA:
Para cambiar el intervalo de pings, puede utilizar el siguiente comando CLI: set
vpnmonitor interval nmero. El intervalo predeterminado es de 10 segundos.
Si la actividad de estas peticiones indica que el estado de supervisin de VPN ha
cambiado, el dispositivo de seguridad activar una de las siguientes capturas del
protocolo simple de gestin de redes (SNMP, o Simple Network Management
Protocol):
NOTA:
Up to Down: Esta captura se produce cuando el estado de supervisin de VPN

para el tnel est en lnea (up), pero un nmero consecutivo de peticiones de
eco ICMP determinado no provoca respuesta y no hay otro trfico VPN
entrante. Entonces el estado cambia a fuera de lnea (down).
Down to Up: cuando el estado de la supervisin de VPN est fuera de lnea

(down), pero la peticin de eco ICMP obtiene una sola respuesta, el estado pasa
a en lnea (up). La captura down-to-up slo se produce si se ha inhabilitado la
opcin de reencriptacin y la asociacin de seguridad de fase 2 an est activa
cuando una peticin de eco ICMP obtiene respuesta a travs del tnel.
Para cambiar el lmite 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.
Para obtener ms informacin sobre los datos SNMP que proporciona la
supervisin de VPN, consulte Objetos y capturas SNMP para la supervisin de
VPN en la pgina 262.
250
Supervisin de VPN
La supervisin de VPN se aplica por cada objeto VPN, no necesariamente por cada
tnel 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 ms directivas (creando VPN basadas en directivas). Dado que
ScreenOS deriva un tnel de VPN basada en directivas a partir de un objeto VPN
ms los dems parmetros de la directiva, un solo objeto VPN puede ser un
elemento de numerosos tneles VPN. Esta distincin entre objeto VPN y tnel VPN
es importante porque Juniper Networks recomienda aplicar la supervisin de VPN a
no ms de 100 tneles IPSec VPN (si no habilita la optimizacin). Si habilita la
optimizacin, no habr lmite al nmero de tneles VPN a los que pueda aplicar la
supervisin de VPN. Para obtener informacin sobre la opcin de optimizacin,
consulte Opciones de reencriptacin y optimizacin en la pgina 251.
NOTA:
La optimizacin de la supervisin de VPN funciona objeto por objeto. Para

activarla en todos los objetos de la VPN, en ninguno o nicamente en algunos.
Opciones de reencriptacin y optimizacin

Si se habilita la opcin de reencriptacin, el dispositivo de seguridad comienza a
enviar peticiones de eco ICMP inmediatamente despus de completar la
configuracin del tnel y seguir envindolas indefinidamente. Las peticiones de
eco desencadenan un intento de iniciar negociaciones IKE para establecer un tnel
VPN hasta que el estado de la supervisin de VPN del tnel sea en lnea (up).
A continuacin, el dispositivo de seguridad utiliza las peticiones de eco con fines de
supervisin de VPN. Si el estado de la supervisin de VPN para el tnel pasa de en
lnea a fuera de lnea, el dispositivo de seguridad desactivar su asociacin de
seguridad (SA) de fase 2 para ese interlocutor. El dispositivo de seguridad
continuar enviando peticiones de eco a su interlocutor segn 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 de seguridad reactivar la asociacin de seguridad de fase 2, generar
una nueva clave y restablecer el tnel. En el registro de eventos aparecer un
mensaje indicando que se ha realizado correctamente una operacin de
reencriptacin.
NOTA:
Si un dispositivo de seguridad es un cliente DHCP, una actualizacin de DHCP en

una direccin distinta har que IKE se reencripte. Sin embargo, una actualizacin
de DHCP en la misma direccin no provocar la reencriptacin de IKE.
La opcin de reencriptacin se puede utilizar para garantizar que un tnel AutoKey
IKE siempre est activo, quiz para supervisar dispositivos situados en la ubicacin
remota o para permitir que los protocolos de enrutamiento dinmico memoricen
rutas en una ubicacin remota y transmitir mensajes a travs del tnel. Otra
aplicacin de la supervisin de VPN con la opcin de reencriptacin es completar
automticamente la tabla de asociacin de tneles a saltos siguientes (tabla NHTB)
y la tabla de rutas cuando se asocian mltiples tneles VPN a una sola interfaz de
tnel. Para ver un ejemplo de este ltimo uso, consulte Mltiples tneles por
interfaz de tnel en la pgina 263.
Si desactiva la opcin de reencriptacin, el dispositivo de seguridad slo realizar la
supervisin de VPN cuando el tnel est activo con trfico generado por el usuario.
Supervisin de VPN
251
De forma predeterminada, la optimizacin de la supervisin de VPN est

inhabilitada. Si la habilita (set vpn nombre monitor optimized), el comportamiento
de la supervisin de VPN cambiar tal y como se indica a continuacin:
El dispositivo de seguridad considerar el trfico entrante a travs del tnel

VPN equivalente a las respuestas de eco ICMP. Si se acepta trfico entrante en
sustitucin de las respuestas de eco ICMP se pueden reducir las falsas alarmas
que podran producirse cuando hay mucho trfico a travs del tnel y las
respuestas de eco no consiguen pasar.
Si hay trfico entrante y saliente a travs del tnel VPN, el dispositivo de

seguridad tambin suprimir las peticiones de eco de supervisin de VPN. Esto
puede contribuir a reducir el trfico de red.
Aunque la optimizacin de supervisin de VPN presenta algunas ventajas, observe

que la supervisin deja de ofrecer estadsticas SNMP precisas, como el tiempo de
retardo de red de VPN, cuando se activa la opcin de optimizacin. Adems, si se
utiliza la supervisin de VPN para hacer un seguimiento de la disponibilidad de una
direccin IP de destino en el extremo remoto de un tnel, la funcin de
optimizacin puede hacer que los resultados sean errneos.
Interfaz de origen y direccin de destino

De forma predeterminada, la funcin de supervisin de VPN utiliza la direccin IP
de la interfaz de salida local como direccin de origen y la direccin IP de la puerta
de enlace remota como direccin de destino. Si el interlocutor remoto es un cliente
VPN de acceso telefnico (como NetScreen-Remote) con una direccin IP interna, el
dispositivo de seguridad detectar automticamente su direccin interna y la
utilizar como destino. El cliente VPN puede ser un usuario XAuth con una
direccin IP interna asignada, un usuario VPN o el miembro de un grupo VPN de
acceso telefnico con una direccin IP interna. Tambin puede especificar el uso de
otras direcciones IP de origen y destino para la supervisin de VPN, sobre todo para
permitir la supervisin de VPN cuando el otro extremo de un tnel VPN no es un
dispositivo de seguridad.
Como la supervisin de VPN funciona de forma independiente en las ubicaciones
local y remota, la direccin de origen configurada en el dispositivo ubicado en un
extremo del tnel no tiene por qu ser la direccin de destino configurada en el
dispositivo ubicado en el otro extremo. De hecho, es posible habilitar la supervisin
de VPN en ambos extremos del tnel o slo en uno de ellos.
252
Supervisin de VPN
Figura 66: Direcciones de origen y destino para la supervisin de VPN

Dispositivo-A > dispositivo-B
Direccin de origen:
Interfaz de salida
El dispositivo-A enva peticiones

de eco desde su interfaz de salida
a la puerta de enlace remota; es
decir, desde la interfaz de zona
Untrust en el dispositivo-A a la
interfaz de zona Untrust en el
dispositivo-B.
Dispositivo A
LAN
Tnel VPN
Zona Trust
(comportamiento predeterminado)
Dispositivo-A >NetScreen-Remote
El dispositivo-A enva peticiones
de eco desde la interfaz de zona
Trust a NetScreen-Remote.
NetScreen-Remote necesita una
directiva que admita el trfico
ICMP entrante desde una
direccin ms all de la puerta
de enlace remota; es decir,
desde ms all de la interfaz de
zona Untrust del dispositivo-A.
Dispositivo B
LAN
Zona Untrust
Direccin de origen:
Interfaz de la zona Trust
Dispositivo A
LAN
Direccin de destino:
NetScreen-Remote
Tnel VPN
Zona Untrust
Zona Trust
Nota: El dispositivo-A precisa de una directiva que permita el trfico de
peticiones de eco de la zona Trust a la zona Untrust.
Dispositivo-A > Terminador de

VPN de otro fabricante
Dispositivo-A enva peticiones de
eco desde la interfaz de zona
Trust a un dispositivo ubicado
ms all de la puerta de enlace
remota. Esto podra ser
necesario si el interlocutor
remoto no responde a peticiones
de eco pero admite directivas que
permitan el trfico entrante de
estas peticiones.
NOTA:
puerta de enlace remota
remoto
Direccin de origen:
Interfaz de la zona Trust
Dispositivo A
LAN
Tnel VPN
Zona Trust
Terminador de VPN
de otro fabricante
Zona Untrust
Nota: El dispositivo-A precisa de una directiva que permita el trfico de

peticiones de eco de la zona Trust a la zona Untrust.
Si al otro lado de un tnel se encuentra un cliente de VPN NetScreen-Remote que

recibe su direccin a travs de XAuth, el dispositivo de seguridad utilizar de
forma predeterminada la direccin IP asignada a XAuth como destino para la
supervisin de VPN. Para obtener ms informacin sobre XAuth, consulte
Usuarios y grupos de usuarios XAuth en la pgina 9-72.
Consideraciones sobre directivas

Debe crear una directiva en el dispositivo de envo para permitir que las peticiones
de eco procedentes de la zona donde se encuentra la interfaz de origen pasen a
travs del tnel VPN a la zona que contiene la direccin de destino si:
La interfaz de origen se encuentra en una zona distinta de la direccin de

destino
La interfaz de origen se encuentra en la misma zona que la direccin de destino

y est habilitado el bloqueo intrazonal
Supervisin de VPN
253
Asimismo, debe crear una directiva en el dispositivo receptor para permitir que las
peticiones de eco procedentes de la zona donde se encuentra la direccin de origen
pasen a travs del tnel VPN a la zona que contiene la direccin de destino si:
NOTA:
La direccin de destino se encuentra en una zona distinta de la direccin de

origen
La direccin de destino se encuentra en la misma zona que la direccin de

origen y est habilitado el bloqueo intrazonal
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.
Configuracin de la funcin de supervisin de VPN

Para habilitar la supervisin de VPN, siga estos pasos:
WebUI
VPN > AutoKey IKE > New: Configure la VPN, haga clic en Advanced,
introduzca los datos siguientes, haga clic en Return para regresar a la pgina de
configuracin bsica de VPN y, finalmente, haga clic en OK:
VPN Monitor: seleccione la opcin para habilitar la supervisin de VPN en
este tnel VPN.
Source Interface: Elija una interfaz en la lista desplegable. Si elige default,
el dispositivo de seguridad utilizar la interfaz de salida.
Destination IP: introduzca una direccin IP de destino. Si no introduce
ningn dato, el dispositivo de seguridad utilizar la direccin IP de puerta
de enlace remota.
Rekey: seleccione esta opcin si desea que el dispositivo de seguridad
intente realizar las negociaciones IKE de fase 2 (y de fase 1 si fuera
necesario) si el estado del tnel cambia de en lnea a fuera de lnea. Cuando
seleccione esta opcin, el dispositivo de seguridad intentar realizar las
negociaciones IKE para configurar el tnel y comenzar la supervisin de
VPN inmediatamente despus de terminar la configuracin.
Anule la seleccin de esta opcin si no desea que el dispositivo de
seguridad intente realizar las negociaciones IKE cuando el estado del
tnel cambie de en lnea a fuera de lnea. Si la opcin de reencriptacin
est inhabilitada, la supervisin de VPN comenzar cuando el trfico
generado por el usuario haya desencadenado el inicio de las
negociaciones IKE y se detendr cuando el estado del tnel pase de en
lnea a fuera de lnea.
254
Supervisin de VPN
(o bien)
VPNs > Manual Key > New: Configure la VPN, haga clic en Advanced,
introduzca los datos siguientes, haga clic en Return para regresar a la pgina de
configuracin bsica de VPN y, finalmente, haga clic en OK:
VPN Monitor: seleccione la opcin para habilitar la supervisin de VPN en
este tnel VPN.
Source Interface: Elija una interfaz en la lista desplegable. Si elige default,
el dispositivo de seguridad utilizar la interfaz de salida.
Destination IP: introduzca una direccin IP de destino. Si no introduce
ningn dato, el dispositivo de seguridad utilizar la direccin IP de puerta
de enlace remota.
CLI
set vpnmonitor frequency nmero
set vpnmonitor threshold nmero
set vpn cadena_nombre monitor [ source-interface interfaz [ destination-ip dir_ip ] ]
[optimized] [ rekey ]
save
NOTA:
La frecuencia de supervisin de VPN se mide en segundos. El ajuste

predeterminado es de 10 segundos.
El umbral de supervisin de VPN es el nmero de peticiones de eco ICMP seguidas
sin respuesta que determina si la puerta de enlace remota es accesible a travs del
tnel o no. El lmite predeterminado es de 10 peticiones de eco ICMP consecutivas
con respuesta o 10 peticiones consecutivas sin respuesta.
Si no elige una interfaz de origen, el dispositivo de seguridad utilizar la interfaz
de salida como predeterminada.
Si no elige una direccin IP de destino, el dispositivo de seguridad utilizar la
direccin IP de la puerta de enlace remota.
La opcin de reencriptacin no est disponible para los tneles VPN con clave
manual.
En este ejemplo configuraremos un tnel VPN AutoKey IKE entre dos dispositivos
de seguridad (dispositivo-A y dispositivo-B). En el dispositivo A, configure la
supervisin de VPN desde su interfaz de zona Trust (ethernet1) a la interfaz de zona
Trust (10.2.1.1/24) del dispositivo-B. En el dispositivo-B, configure la supervisin de
VPN desde su interfaz de zona Trust (ethernet1) a un servidor de red local
corporativa (10.1.1.5) ubicado tras el dispositivo-A.
Supervisin de VPN
255
Dispositivo A
Dispositivo B
Zonas e interfaces
ethernet1
ethernet1
Zona: Trust
Zone: Trust
Modo de interfaz: NAT
Modo de interfaz: NAT
ethernet3
ethernet3
Zona: Untrust
Zone: Untrust
Parmetros de tnel AutoKey IKE basado en rutas

Fase 1
Fase 1
Nombre de puerta de enlace: gw1
Nombre de puerta de enlace: gw1
Direccin IP esttica de puerta de enlace:
Direccin IP esttica de puerta de enlace:
2.2.2.2
1.1.1.1
Nivel de seguridad: Compatible1
Propuestas: Compatible
Clave previamente compartida: Ti82g4aX
Clave previamente compartida: Ti82g4aX
Interfaz de salida: ethernet3
Interfaz de salida: ethernet3
Modo: Principal
Fase 2
Modo: Principal
Fase 2
Nombre de tnel VPN: vpn1
Nombre de tnel VPN: vpn1
Nivel de seguridad: Compatible2
Nivel de seguridad: Compatible
Supervisin de VPN: orig = ethernet1;
Supervisin de VPN: orig = ethernet1; dest
dest = 10.2.1.1
Asociado a la interfaz: tunnel.1
= 10.1.1.5
Asociado a la interfaz: tunnel.1
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.
2.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.
Dispositivo A
Dispositivo B
Rutas
A 0.0.0.0/0, utilizar ethernet3, puerta de
enlace 1.1.1.250
A 0.0.0.0/0, utilizar ethernet3, puerta de enlace

2.2.2.250
A 10.2.1.0/24, utilizar tunnel.1, sin puerta de

enlace
A 10.1.1.0/24, utilizar tunnel.1, sin puerta de

enlace
(Ruta Null: para derivar el trfico a 10.2.1.0/24 (Ruta Null: para derivar el trfico a 10.1.1.0/24 si
si tunnel.1 queda fuera de lnea) Para
tunnel.1 queda fuera de lnea) Para 10.1.1.0/24,
10.2.1.0/24, utilizar interfaz Null, mtrica: 10 utilizar interfaz Null, mtrica: 10
Como los dos dispositivos envan peticiones de eco ICMP desde una interfaz en su
zona Trust a una direccin de su zona Untrust, los administradores situados en
ambos extremos del tnel VPN deben definir directivas que permitan que las
peticiones pasen de una zona a otra.
256
Supervisin de VPN
NOTA:
Como los dos terminadores VPN de este ejemplo son dispositivos de seguridad, es
posible utilizar las direcciones predeterminadas de origen y destino para la
supervisin de VPN. El uso de otras opciones se incluye nicamente para ilustrar
la configuracin de un dispositivo de seguridad para que pueda utilizarlas.
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga
clic en OK:
Zone (VR): Trust (trust-vr)
Interface: ethernet1(trust-vr)
2.
Direcciones
Zone: Trust
Address Name: Remote_LAN
Zone: Untrust
Supervisin de VPN
257
3.
VPN
VPN Name: vpn1
Remote Gateway:
Gateway Name: gw1
Type:
Static IP: (seleccione), Address/Hostname: 2.2.2.2
Preshared Key: Ti82g4aX

IKE:
Service: ANY
VPN Monitor: (seleccione)
Source Interface: ethernet1
Destination IP: 10.2.1.1
Rekey: (anule la seleccin)
4.
Rutas
Interface: Tunnel.1
Interface: Null
Metric: 10
258
Supervisin de VPN
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Remote_LAN
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
Network > Interfaces > Tunnel IF New: Introduzca los siguientes datos y haga
clic en OK:
Zone (VR): Trust (trust-vr)
Interface: ethernet1(trust-vr)
2.
Direcciones
Zone: Trust
Supervisin de VPN
259
Address Name: Remote_LAN
Zone: Untrust
3.
VPN
VPN Name: vpn1
Remote Gateway:
Gateway Name: gw1
Type:
Static IP: (seleccione), Address/Hostname: 1.1.1.1
Preshared Key: Ti82g4aX

IKE:
Service: ANY
Source Interface: ethernet1
Destination IP: 10.1.1.5
Rekey: (anule la seleccin)
4.
Rutas
Interface: Tunnel.1
260
Supervisin de VPN
Interface: Null
Metric: 10
5.
Directivas
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
haga clic en OK:
Source Address:
Service: Any
Action: Permit
CLI (dispositivo-A)
1.
Interfaces

set interface tunnel.1 zone trust
2.
Direcciones

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
Supervisin de VPN
261
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
CLI (dispositivo-B)
1.
Interfaces

set interface tunnel.1 zone trust
2.
Direcciones

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 supervisin de VPN

ScreenOS permite determinar el estado y las condiciones de las VPN activas
utilizando objetos y capturas de protocolo de gestin simple de redes SNMP (Simple
Network Management Protocol) para la supervisin de VPN. La MIB de supervisin
de VPN indica si cada peticin 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:
262
Supervisin de VPN
Para permitir que la aplicacin de gestin SNMP reconozca las MIB de supervisin
de VPN, es necesario importar en la aplicacin los archivos de extensin MIB
especficos de ScreenOS. Puede encontrar los archivos de extensin MIB en el CD
de documentacin que recibi con su dispositivo de seguridad.
Si se habilita la funcin de supervisin de VPN en un tnel VPN AutoKey IKE o con

clave manual, el dispositivo de seguridad activar sus objetos SNMP de supervisin
de VPN, que incluyen los siguientes datos:
Nmero total de sesiones de VPN activas
Hora en la que se inici cada sesin
Elementos de asociacin de seguridad de cada sesin:
Tipos de algoritmos de encriptacin (DES o 3DES) y de autenticacin (MD5

o SHA-1) ESP
Tipo de algoritmo de encabezado de autenticacin (MD5 o SHA-1)
Protocolo de intercambio de claves (AutoKey IKE o clave manual)
Mtodo de autenticacin de fase 1 (clave previamente compartida o

certificados)
Tipo de VPN (acceso telefnico o punto a punto)
Direcciones IP de interlocutor y puerta de enlace local
IDs de interlocutor y puerta de enlace local
Nmero SPI (ndice de parmetro de seguridad, Security Parameter

Index)
Parmetros de estado de sesin
Estado de supervisin de VPN (en lnea o fuera de lnea)
Estado de tnel (en lnea o fuera de lnea)
Estado de fase 1 y 2 (inactivo o activo)
Periodo de vigencia de fase 1 y 2 (tiempo en segundos antes de la

reencriptacin; el periodo de vigencia de fase 2 tambin se registra en
bytes restantes antes de la reencriptacin)
Mltiples tneles por interfaz de tnel

Es posible asociar mltiples tneles VPN IPSec a una sola interfaz de tnel. Para
vincular un destino especfico a uno de los tneles VPN asociados a la misma
interfaz de tnel, el dispositivo de seguridad utiliza dos tablas: la tabla de rutas y la
de asociacin de tneles a saltos siguientes (NHTB). El dispositivo de seguridad
asigna la direccin IP de puerta de enlace al siguiente salto, especificada en la
entrada de la tabla de rutas, a un tnel VPN particular especificado en la tabla
NHTB. Con esta tcnica, una sola interfaz de tnel puede admitir muchos tneles
VPN. (Consulte Asignacin de rutas a tneles en la pgina 264.)
Mltiples tneles por interfaz de tnel 263
Figura 67: Una interfaz de tnel unida a varios tneles

Tneles VPN basados en rutas
para mltiples interlocutores
remotos.
Todos los tneles

comparten la misma
interfaz de tnel.
El dispositivo de seguridad puede ordenar el trfico VPN enviado a travs de una sola interfaz de
tnel a tantos tneles VPN como admita la tabla de rutas o la capacidad del tnel VPN (lo que sea
menor).
El nmero mximo de tneles VPN no est limitado por el nmero de interfaces de

tnel que se puedan crear, sino por la capacidad de la tabla de rutas o por el
nmero mximo de tneles VPN dedicados que se admita (la cifra que sea menor).
Por ejemplo, si el dispositivo de seguridad admite 4,000 rutas y 1,000 tneles VPN
dedicados, ser posible crear 1,000 tneles VPN y asociarlos a una sola interfaz de
tnel. Si el dispositivo de seguridad admite 8,192 rutas y 10.000 tneles VPN
dedicados, ser posible crear 8,000 tneles VPN y asociarlos a una sola interfaz de
tnel. Para ver la capacidad mxima de rutas y tneles de su dispositivo de
seguridad, consulte la hoja de datos correspondiente del producto.
NOTA:
Si la capacidad de la tabla de rutas es lo que va a establecer el lmite, deber restar

al total de tneles VPN basados en rutas las rutas generadas automticamente por
las interfaces de la zona de seguridad y otras rutas estticas (como la ruta a la
puerta de enlace predeterminada) que tendr que definir.
Asignacin de rutas a tneles

Para ordenar el trfico a travs de tneles VPN asociados a la misma interfaz de
tnel, el dispositivo de seguridad asigna la direccin IP de la puerta de enlace al
salto siguiente especificada en la ruta a un nombre de tnel VPN determinado. La
asignacin de entradas en la tabla de rutas a entradas en la tabla NHTB se muestra
a continuacin. En la Figura 68, el dispositivo local de seguridad enruta el trfico
enviado de 10.2.1.5 a 10.1.1.5 a travs de la interfaz tunnel.1 y, a continuacin,
a travs de vpn2.
264
Figura 68: Tabla de rutas y tabla de asociacin de tneles a saltos siguientes (NHTB)
Interlocutores VPN remotos (con direcciones IP
externas asignadas dinmicamente y
direcciones IP de interfaz de tnel fijas) y sus
LAN protegidas
10.1.1.1

con mltiples tneles asignados
a la interfaz tunnel.1
10.1.0.0/24
vpn1
tunnel.1
10.2.1.5
10.1.1.5
10.1.2.1
vpn2
10.1.1.0/24
vpn3
10.2.0.0/16
LAN de zona Trust
10.1.3.1
10.1.2.0/24
Tabla de rutas
Tabla de asociacin de tneles a saltos siguientes
ID
IP-Prefix (Dst)
Interface
Gateway
Next-Hop
VPN
Indicador
10.1.0.0/24
tunnel.1
10.1.1.1
10.1.1.1
vpn1
static
10.1.1.0/24
tunnel.1
10.1.2.1
10.1.2.1
vpn2
static
10.1.2.0/24
tunnel.1
10.1.3.1
10.1.3.1
vpn3
static
Se puede utilizar un protocolo de enrutamiento dinmico como

Border Gateway Protocol (BGP) para rellenar la tabla de rutas
automticamente, o bien introducir manualmente estas rutas. La
direccin IP de la puerta de enlace es la direccin de la interfaz de
tnel en la ubicacin del interlocutor remoto.
Durante las negociaciones de fase 2, los dos interlocutores IKE

intercambian direcciones de interfaz de tnel e introducen
automticamente estas asociaciones de tnel a salto siguiente. De
forma opcional tambin se pueden introducir manualmente. La
direccin IP del siguiente salto ser la direccin IP de interfaz de
tnel del interlocutor remoto.
En las entradas anteriores, la direccin IP de la puerta de enlace en la tabla de rutas (que tambin es la direccin IP de salto siguiente en la
tabla NHTB) es la interfaz de tnel en la ubicacin del interlocutor remoto. Esta direccin IP vincula la ruta (y, en consecuencia, la interfaz de
tnel especificada en la ruta) a un tnel VPN determinado para el trfico destinado al prefijo IP especificado.
El dispositivo de seguridad utiliza la direccin IP de la interfaz de tnel del

interlocutor remoto como puerta de enlace y direccin IP del salto siguiente. Puede
introducir la ruta manualmente o hacer que un protocolo de enrutamiento
dinmico introduzca automticamente una ruta que haga referencia a la direccin
IP de interfaz de tnel del interlocutor como puerta de enlace en la tabla de rutas.
La misma direccin IP se tiene que introducir como salto siguiente, junto con el
nombre de tnel VPN correspondiente, en la tabla NHTB. Una vez ms, dispone de
dos alternativas: puede introducirla manualmente o hacer que el dispositivo de
seguridad la recoja del interlocutor remoto durante las negociaciones de fase 2 y la
introduzca manualmente.
El dispositivo de seguridad utiliza la direccin IP de puerta de enlace en la entrada
de la tabla de rutas y la direccin IP de salto siguiente en la entrada de la tabla
NHTB como elemento comn para vincular la interfaz de tnel con el tnel VPN
correspondiente. El dispositivo de seguridad puede as dirigir el trfico destinado al
prefijo IP especificado en la ruta con el tnel 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 VPN basadas en rutas debe ser nico para todos ellos. Una forma de
conseguirlo es realizar una traduccin de direcciones de red (NAT) de las
direcciones de origen y de las de destino por cada interlocutor remoto. Adems, las
direcciones IP de interfaz de tnel tambin deben ser nicas para todos los
interlocutores remotos. Si pretende conectar un gran nmero de ubicaciones
remotas, ser absolutamente necesario elaborar un esquema de direcciones.
A continuacin se muestra un ejemplo de esquema de direcciones para un mximo
de 1.000 tneles VPN:
Dest. en tabla
local de rutas
Interfaz de tnel
local
Puerta de enlace/salto
siguiente
(Interfaz de tnel del
Tnel VPN
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
10.0.251.0/24
tunnel.1
10.0.250.1/24
vpn125
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
10.7.251.0/24
tunnel.1
10.7.250.1/24
vpn1000
La interfaz de tnel en el dispositivo de seguridad local es 10.0.0.1/24. En todos los

hosts remotos, hay una interfaz de tnel con una direccin IP que aparece como la
direccin 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 asociacin de mltiples tneles con una sola
interfaz de tnel con traduccin de direcciones, consulte Ajuste de VPN en una
interfaz de tnel para subredes superpuestas en la pgina 269.
266
Figura 69: Mltiples tneles asociados a una nica interfaz de tnel con traduccin de direcciones
El dispositivo de seguridad local y todos
10.0.4.1/24
sus interlocutores ejecutan la
NAT-dst 10.0.5.1 ->
traduccin de direcciones de destino
direcciones IP internas
(NAT-dst) con desplazamiento de IP en
IF 10.0.2.1/24
el trfico VPN entrante y traduccin de
NAT-dst 10.0.3.1 ->
direcciones de origen (NAT-src) desde
la direccin IP de interfaz de tnel de
vpn1
salida con traduccin de puertos en el
trfico VPN saliente.
IF 10.0.2.1/24
NAT-dst 10.0.3.1 ->
Dispositivo de
seguridad local
10.0.0.1/24
NAT-dst 10.0.1.1 ->
10.0.6.1/24
NAT-dst 10.0.7.1 ->
vpn2
vpn3
10.1.1.1/24
NAT-dst 10.1.2.1 ->
vpn251
vpn751
vpn1000
10.6.2.1/24
NAT-dst 10.6.3.1->
10.7.250.1/24
NAT-dst 10.7.251.1 ->
Entradas de tabla manuales y automticas

Puede incluir entradas manualmente en las tablas NHTB y de rutas. Tambin puede
automatizar la carga de las tablas NHTB y de rutas. Si se va a trabajar con un
nmero pequeo de tneles asociados a una sola interfaz de tnel, el mtodo
manual puede funcionar bien. Sin embargo, para un gran nmero de tneles, el
mtodo automtico reduce la configuracin y el mantenimiento administrativos, ya
que las rutas se ajustan dinmicamente cuando los tneles o interfaces dejan de
estar disponibles en la interfaz de tnel en la ubicacin del concentrador.
Entradas manuales en la tabla

Un tnel VPN se puede asignar manualmente a la direccin IP de la interfaz de
tnel de un interlocutor remoto en la tabla de asociacin de tneles 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 tnel en ese
extremo del tnel. A continuacin podr asociar esta direccin al nombre de tnel
VPN en la tabla NHTB con el siguiente comando:
set interface tunnel.1 nhtb direccin_interfaz_tnel_interlocutor vpn nombre
Una vez hecho esto, podr introducir una ruta esttica en la tabla de rutas que
utiliza la direccin IP de interfaz de tnel como puerta de enlace. Puede introducir
la ruta por medio de la WebUI o con el siguiente comando CLI:
set vrouter cadena_nombre route dir_dest interface tunnel.1 gateway
dir_interfaz_tnel_interloc
Entradas automticas en la tabla

Para que la tabla de rutas y la tabla NHTB se rellenen automticamente, se deben
cumplir las siguientes condiciones:
Los interlocutores remotos de todos los tneles VPN asociados a una sola
interfaz de tnel local deben ser dispositivos de seguridad con ScreenOS 5.0.0
o posterior.
Cada interlocutor remoto debe asociar su tnel a una interfaz de tnel, y esa
interfaz debe tener una direccin IP nica entre todas las direcciones de
interfaz de tnel de los interlocutores.
En ambos extremos del tnel VPN, habilite la supervisin de VPN con la opcin
de reencriptacin (Rekey), o habilite la opcin de nueva conexin de pulsos de
IKE (IKE Heartbeat Reconnect) para cada puerta de enlace remota.
Los interlocutores locales y remotos deben tener habilitada una instancia de un

protocolo de enrutamiento dinmico en sus interfaces de tnel de conexin.
El uso de supervisin de VPN con la opcin de reencriptacin permite que los

dispositivos de seguridad situados en ambos extremos de un tnel puedan
establecer el tnel sin tener que esperar a que haya trfico VPN originado por el
usuario. Una vez habilitada la supervisin de VPN con la opcin de reencriptacin a
los dos lados de un tnel VPN, los dos dispositivos de seguridad llevarn a cabo las
negociaciones IKE de fase 1 y 2 para establecer el tnel. (Para obtener ms
informacin, consulte Supervisin de VPN en la pgina 250).
NOTA:
Si se ejecuta un protocolo de enrutamiento dinmico en las interfaces de tnel, el

trfico generado por el protocolo puede desencadenar negociaciones IKE aunque
no se habilite la supervisin de VPN con la opcin de reencriptacin o la opcin de
nueva conexin de pulsos de IKE. En cualquier caso, se recomienda no confiar en
que el trfico de enrutamiento dinmico desencadene las negociaciones IKE. En
lugar de ello, utilice la supervisin de VPN con la opcin de reencriptacin o de
nueva conexin de pulsos de IKE.
Para OSPF (Open Shortest Path First, abrir primero la ruta ms corta), debe
configurar la interfaz de tnel en el interlocutor local como interfaz punto a
multipunto antes de activar el protocolo de enrutamiento en la interfaz.
En el caso de interlocutores remotos con una direccin IP externa asignada
dinmicamente o con un nombre de dominio totalmente clasificado (FQDN)
asignado a una direccin IP dinmica, el interlocutor remoto primero debe iniciar
las negociaciones IKE. Sin embargo, dado que la asociacin de seguridad de fase 2
en el dispositivo de seguridad local guarda en cach la direccin IP asignada
dinmicamente del interlocutor remoto, cada interlocutor puede reiniciar las
negociaciones IKE para restablecer un tnel cuyo estado de supervisin de VPN
haya cambiado de en lnea a fuera de lnea.
Durante las negociaciones de fase 2, los dispositivos de seguridad intercambian
entre s direcciones IP de interfaz de tnel. Cada mdulo IKE puede introducir
automticamente la direccin IP de interfaz de tnel y su nombre de tnel VPN
correspondiente en la tabla NHTB.
Para hacer que el dispositivo de seguridad local pueda introducir rutas a destinos
remotos automticamente en su tabla de rutas, debe habilitar una instancia de BGP
en las interfaces de tnel locales y remotas. Los pasos bsicos son los siguientes:
1. Crear una instancia de enrutamiento BGP en el enrutador virtual que contiene
la interfaz de tnel a la que se han asociado mltiples tneles VPN.
2. Habilitar la instancia de enrutamiento en el enrutador virtual.
268
3. Habilitar la instancia de enrutamiento en la interfaz de tnel que conduce a los

interlocutores BGP.
Los interlocutores remotos tambin llevan a cabo estos pasos.
En el dispositivo local (o concentrador), tambin debe definir una ruta
predeterminada y una ruta esttica a cada direccin IP de interfaz de tnel de los
interlocutores. Las rutas estticas a las interfaces de tnel de los interlocutores son
necesarias para que el dispositivo concentrador pueda acceder inicialmente a sus
vecinos BGP a travs del tnel VPN correcto.
Despus de establecer las comunicaciones, los vecinos BGP intercambian
informacin de enrutamiento, de forma que puedan rellenar automticamente sus
tablas de rutas. Una vez que los dos interlocutores establecen un tnel VPN entre s,
pueden enviar y recibir informacin de enrutamiento desde y hacia el dispositivo
local. Cuando la instancia de enrutamiento dinmico en el dispositivo de seguridad
aprende una ruta a un interlocutor a travs de una interfaz de tnel local, incluye la
direccin IP de la interfaz de tnel del interlocutor remoto como puerta de enlace
en la ruta.
Para ver un ejemplo que ilustra la configuracin de mltiples tneles asociados a
una nica interfaz de tnel, donde el dispositivo concentrador rellena sus tablas
NHTB y de rutas automticamente, consulte Asociacin de entradas automticas
en la tabla de rutas y en la tabla NHTB en la pgina 288.
Ajuste de VPN en una interfaz de tnel para subredes superpuestas

En este ejemplo asociaremos tres tneles VPN AutoKey IKE basados en rutas (vpn1,
vpn2 y vpn3) a una sola interfaz de tnel (tunnel.1). Los tneles van del dispositivo
A a tres interlocutores remotos: interloc1, interloc2 y interloc3. Las entradas de las
tablas NHTB y de rutas para los tres interlocutores se agregarn manualmente al
dispositivo A. Para ver una configuracin que proporcione un medio automtico de
rellenar las tablas de rutas y NHTB, consulte Asociacin de entradas automticas
en la tabla de rutas y en la tabla NHTB en la pgina 288.
Figura 70: Interfaz Tunnel.1 asociada con tres tneles VPN
La zona Trust para el dispositivo-A no se muestra.

Dispositivo A
Zona Untrust
interloc1
vpn1
vpn2
vpn3
Zona Trust
ethernet1
10.1.1.1/24
tunnel.1
ethernet3
ethernet3
10.0.0.1/30
1.1.1.1/24
1.1.1.1/24
Conjunto de DIP 5:
external
router
externo
1.1.1.250
10.0.0.2 - 10.0.0.2 Enrutador
1.1.1.250
vpn1
Puerta de enlace IKE: interloc1, 2.2.2.2
Interfaz de tnel del interlocutor remoto: 10.0.2.1
LAN
interloc2
interloc3
LAN
LAN
vpn2
Puerta de enlace IKE:
interloc2, 3.3.3.3
Interfaz de tnel del
interlocutor remoto: 10.0.4.1
vpn3
Interfaz de tnel del interlocutor remoto:
10.0.6.1
Las configuraciones de tnel VPN a ambos extremos de cada tnel utilizan los
siguientes parmetros:
AutoKey IKE
Clave previamente compartida para cada interlocutor:
interloc1 utiliza netscreen1
Nivel de seguridad predefinido como Compatible para ambas propuestas de

fase 1 y fase 2. (Para ver los detalles sobre estas propuestas, consulte
Negociacin de tnel en la pgina 9).
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 cmo se puede utilizar la traduccin de direcciones de red de
origen y destino (NAT-src y NAT-dst) para evitar problemas de direccionamiento
entre los interlocutores IPSec. Para obtener ms informacin sobre NAT-src y
NAT-dst, consulte el Volumen 8: Traduccin de direcciones.
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
270
ID: 5
2.
Direcciones
Address Name: corp
Zone: Trust
Address Name: oda1
Zone: Trust
Address Name: peers
Zone: Untrust
3.
VPN
VPN Name: vpn1
Gateway Name: interloc1

IKE:
Service: ANY
VPN Name: vpn2

IKE:
Service: ANY
VPN Name: vpn3

IKE:
Service: ANY
4.
Rutas
Network > Routing > Routing Entries > (trust-vr) New: Introduzca los
272
Interface: tunnel.1
Interface: tunnel.1
Interface: tunnel.1
Interface: tunnel.1
Interface: tunnel.1
Interface: tunnel.1
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
New Next Hop Entry:
VPN: vpn2
Network > Interfaces > Edit (para tunnel.1) > NHTB: Introduzca los
New Next Hop Entry:
VPN: vpn3
5.
Directivas
haga clic en OK:
Source Address:
Address Book: (seleccione), corp
Address Book: (seleccione), peers
Service: Any
Action: Permit

en Return para regresar a la pgina de configuracin bsica de directivas:
NAT:
DIP On: 5 (10.0.0.210.0.0.2)/X-late
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), peers
Address Book Entry: (seleccione), oda1
Service: Any
Action: Permit

NAT:
Translate to IP Range: (seleccione), 10.1.1.0 - 10.1.1.254
274
CLI (dispositivo-A)
1.
Interfaces

2.
Direcciones
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
3.
VPN
set ike gateway interloc1 address 2.2.2.2 outgoing-interface ethernet3 preshare

set vpn vpn1 gateway interloc1 sec-level compatible
4.
Rutas

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
Interloc1
La siguiente configuracin, segn se ilustra en la Figura 71, es la que el

administrador remoto del dispositivo de seguridad en la ubicacin interloc1 debe
introducir para crear un tnel VPN al dispositivo-A en la empresa. El administrador
remoto configura el dispositivo de seguridad 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. Interloc1
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 trfico a travs de VPN1 al
dispositivo-A. Interloc1 lleva a cabo NAT-dst en el trfico VPN enviado desde el
dispositivo-A, traduciendo las direcciones de 10.0.3.0/24 a 10.1.1.0/24 con
desplazamiento de direcciones.
Figura 71: Interloc1 realizando NAT-Dst
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
Zona Untrust
Rango NAT-dst
10.0.3.0 10.0.3.255
ethernet1
10.1.1.1/24
Interloc1
NAT-dst de
10.0.3.0 10.0.3.255
a
10.1.1.0 10.1.1.255
con desplazamiento de
direcciones
Zona Trust
vpn1 de
dispositivo-A
LAN
10.1.1.0/24
NOTA:
Para obtener ms informacin sobre NAT-src y NAT-dst, consulte el Volumen 8:

Traduccin de direcciones.
WebUI (Interloc1)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
276
ID: 6
2.
Direcciones
Address Name: lan
Zone: Trust
Address Name: oda2
Zone: Trust
Address Name: to_corp
Zone: Untrust
Address Name: fr_corp
Zone: Untrust
3.
VPN
VPN Name: vpn1
Gateway Name: corp

IKE:
Service: ANY
4.
Rutas
Metric: 1
Metric: 1
Interface: tunnel.10
Metric: 10
Interface: null
Metric: 12
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), fr_corp
Service: Any
Action: Permit
278

NAT:
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), lan
Address Book Entry: (seleccione), to_corp
Service: Any
Action: Permit

NAT:
DIP On: 6 (10.0.2.210.0.2.2)/X-late
CLI (Interloc1)
1.
Interfaces

2.
Direcciones
set
set
set
set
3.
address trust lan 10.1.1.0/24

address trust oda2 10.0.3.0/24
address untrust to_corp 10.0.1.0/24
address untrust fr_corp 10.0.0.2/32
VPN

4.
Rutas

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
Interloc2

dispositivo-A. Interloc2 lleva a cabo NAT-dst en el trfico VPN enviado desde el
dispositivo-A, traduciendo las direcciones de 10.0.5.0/24 a 10.1.1.0/24 con
Figura 72: Interloc2
tunnel.20
10.0.4.1/30
Conjunto de DIP 7
10.0.4.2 - 10.0.4.2
ethernet3
3.3.3.3/24
Enrutador externo
3.3.3.250
Zona Untrust
Rango NAT-dst
10.0.5.0 10.0.5.255
ethernet1
10.1.1.1/24
Interloc2
vpn2 desde
dispositivo-A
Zona Trust
NAT-dst de
10.0.5.0 10.0.5.255
a
10.1.1.0 10.1.1.255
con desplazamiento
de direcciones
LAN
10.1.1.0/24
NOTA:
Para obtener ms informacin sobre NAT-src y NAT-dst, consulte el Volumen 8:

Traduccin de direcciones.
WebUI (Interloc2)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
280
clic en OK:
ID: 7
2.
Direcciones
Address Name: lan
Zone: Trust
Address Name: oda3
Zone: Trust
Zone: Untrust
Zone: Untrust
3.
VPN
VPN Name: vpn2
Gateway Name: corp

IKE:
Service: ANY
4.
Rutas
Metric: 1
Metric: 1
Metric: 10
Interface: null
Metric: 12
282
5.
Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
DIP On: 7 (10.0.4.210.0.4.2)/X-late
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
CLI (Interloc2)
1.
Interfaces

2.
Direcciones
set
set
set
set

3.
VPN

4.
Rutas

metric 1
5.
Directivas
permit
save
Interloc3

dispositivo A. Interloc3 lleva a cabo NAT-dst en el trfico VPN enviado desde el
dispositivo A, traduciendo las direcciones de 10.0.7.0/24 a 10.1.1.0/24 con
vpn2 desde Zona Untrust

dispositivo-A
ethernet3
tunnel.30
4.4.4.4/24
10.0.6.1/30
Enrutador externo
Conjunto de DIP 8
4.4.4.250
10.0.6.2 - 10.0.6.2
Rango NAT-dst
10.0.7.0 10.0.7.255
ethernet1
10.1.1.1/24
Interloc3
NAT-dst de
10.0.7.0 10.0.7.255
a
10.1.1.0 10.1.1.255
con desplazamiento
de direcciones
Zona Trust
LAN
10.1.1.0/24
NOTA:
284
Para obtener ms informacin sobre NAT-dst, consulte el Volumen 8: Traduccin de

direcciones.
WebUI (Interloc3)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
ID: 7
2.
Direcciones
Address Name: lan
Zone: Trust
Address Name: oda4
Zone: Trust
Zone: Untrust
Zone: Untrust
3.
VPN
VPN Name: vpn3
Gateway Name: corp

IKE:
Service: ANY
4.
Rutas
Metric: 1
Metric: 1
286
Metric: 10
Interface: null
Metric: 12
5.
Directivas
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
DIP On: 8 (10.0.6.210.0.6.2)/X-late
haga clic en OK:
Source Address:
Service: Any
Action: Permit

NAT:
CLI (Interloc3)
1.
Interfaces

2.
Direcciones
set
set
set
set
3.

VPN

4.
Rutas
set vrouter trust-vr route 0.0.0.0/0 interface ethernet3 gateway 3.3.3.250 metric
1
5.
Directivas
permit
save
Asociacin de entradas automticas en la tabla de rutas y en la

tabla NHTB
En la Figura 74 en la pgina 289, se asocian dos tneles VPN AutoKey IKE basados
en rutas (vpn1 y vpn2) a una sola interfaz de tnel (tunnel.1) en el dispositivo-A,
ubicado en la empresa. La red que cada interlocutor remoto protege tiene mltiples
rutas tras la ruta conectada. Utilizando el protocolo de puerta de enlace de lmites
BGP (Border Gateway Protocol), los interlocutores comunican sus rutas al
dispositivo-A. Este ejemplo permite el trfico VPN desde la ubicacin corporativa
tras el dispositivo-A a los interlocutores.
NOTA:
288
En este ejemplo tambin puede utilizar OSPF (Open Shortest Path First = abrir
primero la ruta ms corta) en lugar de BGP como protocolo de enrutamiento.
Consulte Uso de OSPF para entradas automticas en la tabla de rutas en la
pgina 300 para ver las configuraciones de OSPF.
Figura 74: Entradas automticas en la tabla de rutas y la tabla NHTB (dispositivo-A)

vpn1
Las rutas tras cada interlocutor son
desconocidas para el dispositivo-A
hasta que los interlocutores utilizan
BGP para enviarlas.
La interfaz tunnel.1 del dispositivo-A se

asocia a dos tneles VPN.
Zona Untrust
interloc1
vpn1
Dispositivo A
interloc2
Zona Trust
ethernet1
10.1.1.1/24
ethernet3
1.1.1.1/24
Enrutador externo
1.1.1.250
tunnel.1
10.0.0.1/30
vpn2
vpn2
Las configuraciones de tnel VPN a ambos extremos de cada tnel utilizan los
siguientes parmetros: AutoKey IKE, clave previa compartida (interloc1:
netscreen1, interloc2: 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 Negociacin de tnel en la pgina 9).
Antes de configurar las dos siguientes funciones, puede habilitar el dispositivo-A
para que rellene sus tablas de rutas y NHTB automticamente:
NOTA:
Supervisin de VPN con la opcin de reencriptacin (o de nueva conexin de

pulsos de IKE)
Enrutamiento dinmico BGP en tunnel.1
Si se ejecuta un protocolo de enrutamiento dinmico en las interfaces de tnel, el

trfico generado por el protocolo puede desencadenar negociaciones IKE aunque
no se habilite la supervisin de VPN con la opcin de reencriptacin o la opcin de
nueva conexin de pulsos de IKE. En cualquier caso, Juniper Networks
recomienda no confiar en que el trfico de enrutamiento dinmico desencadene
las negociaciones IKE. En lugar de ello, utilice la supervisin de VPN con la opcin
de reencriptacin o de nueva conexin de pulsos de IKE.
Si las interfaces de tnel se ejecutan con BGP, el trfico generado por BGP puede
desencadenar negociaciones IKE aun cuando no se habilite la supervisin de VPN
con la opcin de reencriptacin o la opcin de nueva conexin de pulsos de IKE.
En cualquier caso, Juniper Networks recomienda no confiar en que el trfico BGP
desencadene las negociaciones IKE. En lugar de esto, utilice la supervisin de VPN
con la opcin de reencriptacin o de nueva conexin de pulsos de IKE.
Cuando se activa la supervisin de VPN con la opcin de reencriptacin para un

tnel VPN AutoKey IKE, el dispositivo A establece una conexin VPN con su
interlocutor remoto en el momento en que usted y el administrador en la ubicacin
remota terminan de configurar el tnel. Los dispositivos no esperan a que aparezca
trfico VPN generado por el usuario para iniciar las negociaciones IKE. Durante las
negociaciones de fase 2, el dispositivo de seguridad intercambia su direccin IP de
interfaz de tnel, de forma que el dispositivo A realiza automticamente una
asociacin de la VPN al siguiente salto en su tabla NHTB.
La opcin de reencriptacin garantiza que cuando finalice el periodo de validez de
las claves de fase 1 y 2, los dispositivos negociarn automticamente la generacin
de nuevas claves sin que ningn usuario tenga que intervenir. La supervisin de
VPN con la opcin de reencriptacin habilitada ofrece bsicamente una forma de
conservar siempre activo un tnel VPN, aun cuando no haya trfico generado por
usuario. Esto es necesario para que las instancias de enrutamiento dinmico BGP,
que usted y el administrador crean y habilitan en las interfaces de tnel a ambos
lados de los tneles, puedan enviar informacin de enrutamiento al dispositivo A y
rellenen automticamente su tabla de rutas con las rutas que necesita para dirigir el
trfico a travs del tnel VPN antes de que esas rutas sean necesarias para el trfico
generado por el usuario. (Los administradores en las ubicaciones de los
interlocutores tienen que introducir una nica ruta esttica al resto de la red privada
virtual a travs de la interfaz de tnel en cada ubicacin).
Debe introducir una ruta predeterminada y rutas estticas en el dispositivo-A para
acceder a sus vecinos BGP a travs de los tneles 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
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
clic en OK:
290
2.
VPN
VPN Name: vpn1
> Advanced: Introduzca los siguientes ajustes avanzados y haga clic en Return
para regresar a la pgina de configuracin bsica de AutoKey IKE:
Service: ANY
Rekey: (seleccione)
NOTA:
Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP

de destino. Para obtener ms informacin sobre estas opciones, consulte
Supervisin de VPN en la pgina 250.
VPN Name: vpn2

IKE:
Service: ANY
Rekey: (seleccione)
NOTA:
Conserve los ajustes predeterminados en las opciones de interfaz de origen e IP

de destino. Para obtener ms informacin sobre estas opciones, consulte
Supervisin de VPN en la pgina 250.
3.
Ruta esttica
Interface: tunnel.1
Interface: tunnel.1
4.
Enrutamiento dinmico
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
verificacin Protocol BGP, luego 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
Remote IP: 3.4.4.1
292
5.
Directiva
haga clic en OK:
Source Address:
Address Book: (seleccione), Any
Address Book: (seleccione), Any
Service: ANY
Action: Permit
CLI (dispositivo-A)
1.
Interfaces

2.
VPN

set vpn vpn1 monitor rekey
set vpn vpn2 monitor rekey
3.
Rutas estticas

4.
device-> set vrouter trust-vr protocol bgp 99

device-> set vrouter trust-vr protocol bgp enable
device-> set interface tunnel.1 protocol bgp
device-> set vrouter trust-vr
device(trust-vr)-> set protocol bgp
device(trust-vr/bgp)-> set neighbor 2.3.3.1 remote-as 99 outgoing interface
tunnel.1
device(trust-vr/bgp)-> set neighbor 2.3.3.1 enable
tunnel.1
device(trust-vr/bgp)-> exit
device(trust-vr)-> exit
5.
Directiva
set policy from trust to untrust any any any permit

save
Interloc1
La siguiente configuracin, segn se ilustra en la Figura 75 en la pgina 294, es la

que el administrador remoto del dispositivo de seguridad en la ubicacin interloc1
debe introducir para crear un tnel VPN al dispositivo-A en la empresa. El
administrador remoto configura el dispositivo de seguridad para permitir el trfico
entrante desde la empresa. Tambin configura el dispositivo de seguridad para
comunicar rutas internas a su vecino BGP a travs de vpn1.
ethernet3
2.2.2.2/24
Enrutador externo
2.2.2.250
ethernet1
2.3.4.1/24
tunnel.10
2.3.3.1/30
Zona Trust
Zona Untrust
2.3.
Interloc1
2.3.4.0/24
vpn2 desde
dispositivo-A
2.3.
WebUI (Interloc1)
1.
Interfaces
haga clic en OK:
Zone Name: Trust
haga clic en OK:
Zone Name: Untrust
clic en OK:
294
2.
Direccin
Address Name: corp
Zone: Untrust
3.
VPN
VPN Name: vpn1
Gateway Name: corp

IKE:
Service: ANY
4.
Rutas estticas
Metric: 1
Metric: 1
5.
AS Number: 99
Remote IP: 10.0.0.1
6.
Directiva
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
CLI (Interloc1)
1.
Interfaces

2.
Direccin

3.
VPN

4.
Rutas estticas

metric 1
5.

tunnel.10
296
6.
Directiva
set policy from untrust to trust corp any any permit

save
Interloc2

remoto configura el dispositivo de seguridad para permitir el trfico entrante desde
la empresa. Tambin configura el dispositivo de seguridad para comunicar rutas
internas a su vecino BGP a travs de vpn2.
ethernet3
3.3.3.3/24
Enrutador externo
3.3.3.250
vpn2 desde
dispositivo-A
tunnel.20
3.4.4.1/30
Zona Trust
ethernet1
3.4.5.1/24
3.4.
Interloc
3.4.5.0/24
Zona Untrust
3.4.
WebUI (Interloc2)
1.
Interfaces
haga clic en OK:
Zone Name: Trust
haga clic en OK:
Zone Name: Untrust
clic en OK:
2.
Direccin
Address Name: corp
Zone: Untrust
3.
VPN
VPN Name: vpn2
Gateway Name: corp

IKE:
Service: ANY
4.
Rutas estticas
Metric: 1
Metric: 1
5.
298
AS Number: 99
Remote IP: 10.0.0.1
6.
Directiva
haga clic en OK:
Source Address:
Service: ANY
Action: Permit
CLI (Interloc2)
1.
Interfaces

2.
Direccin

3.
VPN

4.
Rutas estticas

metric 1
5.

tunnel.20
6.
Directiva
set policy from untrust to trust corp any any permit

save
Uso de OSPF para entradas automticas en la tabla de rutas

Tambin puede configurar OSPF en lugar del enrutamiento dinmico BGP para que
los interlocutores comuniquen sus rutas al dispositivo-A. Para permitir que tunnel.1
en el dispositivo-A pueda formar adyacencias OSPF con sus interlocutores, debe
configurar la interfaz de tnel como interfaz punto a multipunto. La configuracin
de enrutamiento dinmico OSPF para cada dispositivo se muestra abajo.
Enrutamiento dinmico (OSPF)
Network > Routing > Virtual Routers > Edit (para trust-vr) > Create OSPF
Instance: Seleccione OSPF Enabled, luego haga clic en Apply.
Area > Configure (para el rea 0.0.0.0): Haga clic en << Add para mover
la interfaz tunnel.1 de la lista Available Interface(s) a la lista Selected
Interface(s) y luego haga clic en OK.
Network > 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)
CLI (dispositivo-A)
device-> set vrouter trust-vr protocol ospf

device-> set vrouter trust-vr protocol ospf enable
device-> set interface tunnel.1 protocol ospf area 0
device-> set interface tunnel.1 protocol ospf link-type p2mp
device-> set interface tunnel.1 protocol ospf enable
device-> save
WebUI (Interloc1)
300
CLI (Interloc1)

device-> save
WebUI (Interloc2)
CLI (Interloc2)

device-> save
Puertas de enlace VPN redundantes

La funcin de puertas de enlace redundantes ofrece una solucin para la
conectividad VPN continua durante y despus de una conmutacin por error punto
a punto. Es posible crear un grupo VPN para proporcionar un conjunto de hasta
cuatro puertas de enlace redundantes al que se pueden conectar tneles VPN
AutoKey IKE IPSec de interlocutor dinmico punto a punto o punto a punto basados
en directivas. Cuando el dispositivo de seguridad recibe por primera vez trfico 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 de seguridad
enva datos a travs del tnel VPN a la puerta de enlace con la mayor prioridad
(o peso) del grupo. Para todas las dems puertas de enlace del grupo, el dispositivo
de seguridad actualiza las asociaciones de seguridad de fase 1 y 2 y mantiene
activos los tneles enviando a travs de ellos paquetes de mantenimiento de
conexin IKE. Si el tnel VPN activo falla, puede producir una conmutacin por
error al tnel y la puerta de enlace con el segundo nivel de prioridad del grupo.
301
NOTA:
Los grupos VPN no admiten tneles de los siguientes tipos: L2TP,

L2TP-sobre-IPSec, acceso telefnico, clave manual ni tneles VPN basados en
rutas. En una configuracin de interlocutores dinmicos punto a punto, el
dispositivo de seguridad que supervisa el grupo VPN debe tener la direccin IP
Untrust asignada dinmicamente, mientras que las direcciones IP de los
miembros del grupo VPN deben ser estticas.
En este esquema se asume que los sitios situados detrs de las puertas de enlace
redundantes estn conectados de tal forma que los datos se replican entre los
hosts de todos los sitios. Adems, cada sitio (al ser dedicado para alta
disponibilidad) tiene un conjunto redundante de dispositivos de seguridad que
funcionan en modo de alta disponibilidad. As, el lmite de conmutacin de fallo
de VPN que se ajuste debe ser mayor que el lmite de conmutacin por error del
dispositivo o se podran producir conmutaciones por error innecesarias.
Figura 77: Puertas de enlace VPN redundantes para conmutacin por error del tnel VPN
Grupo VPN, ID 1
= Datos
= Pulsos de IKE
(Despus de una conmutacin por error de VPN)
Grupo VPN, ID 1
Grupos VPN
Un grupo VPN es un conjunto de configuraciones de tnel VPN para hasta cuatro
puertas de enlace remotas de destino. Los parmetros de asociacin de seguridad
(SA) de fase 1 y fase 2 para cada tnel de un grupo pueden ser distintos o idnticos
(excepto en el caso de la direccin IP de la puerta de enlace remota, que,
lgicamente, debe ser diferente). El grupo VPN, que se muestra en la Figura 78 en
la pgina 303, tiene un nmero de ID inequvoco, y a cada miembro del grupo se le
asigna un peso inequvoco para indicar su lugar en el rango de preferencia para
convertirse en el tnel activo. Un valor de 1 constituye el rango inferior o de menor
preferencia.
302
Figura 78: Puertas de enlace remotas de destino

Grupo VPN 1
Peso
E
S
Supervisor
T
I
N
O
Nota: En esta ilustracin, el sombreado simboliza el peso de cada
tnel. Cuanto ms oscuro sea el tnel, mayor ser su prioridad.
El dispositivo de seguridad que se comunica con los miembros del grupo VPN y los
propios miembros tienen una relacin supervisor/destino. El dispositivo de
supervisin supervisa continuamente la conectividad y el correcto estado de cada
dispositivo de destino. El supervisor utiliza las siguientes herramientas para ello:
Pulsos de IKE
Intentos de recuperacin de IKE
Ambas herramientas se describen en la seccin siguiente, Mecanismos de

supervisin, en la pgina 303.
NOTA:
La relacin supervisor/destino no tiene por qu ser de un solo sentido. El

dispositivo de supervisin tambin puede ser un miembro de un grupo VPN y, por
tanto, ser a su vez el destino de otro dispositivo de supervisin.
Mecanismos de supervisin
Dos mecanismos supervisan los miembros de un grupo VPN con el fin de
determinar su capacidad para terminar trfico VPN:
Pulsos de IKE
Intentos de recuperacin de IKE
Utilizando estas dos herramientas junto con la opcin de conmutacin por error de
aplicacin TCP (consulte Comprobacin de indicador TCP SYN en la pgina 307),
los dispositivos de seguridad pueden detectar si es necesario realizar una
conmutacin por error de la VPN y desviar el trfico al nuevo tnel sin tener que
interrumpir el servicio de VPN.
303
Pulsos de IKE
Los pulsos de IKE son mensajes de saludo que los interlocutores IKE se envan
mutuamente bajo la proteccin de una asociacin de seguridad (SA) de fase 1
establecida para confirmar la conectividad y el correcto estado del otro. Por
ejemplo, si dispositivo_s (el supervisor) no recibe un determinado nmero de
pulsos (el valor predeterminado es 5) de dispositivo_d (el destino), dispositivo_s
llega a la conclusin de que dispositivo_d est fuera de lnea. Dispositivo_s elimina
de su memoria cach las asociaciones de seguridad (SA) de fase 1 y fase 2
correspondientes y comienza el procedimiento de recuperacin IKE. (Consulte
Procedimiento de recuperacin IKE en la pgina 306.) Dispositivo_d tambin
elimina sus SA.
NOTA:
La funcin de pulsos de IKE debe estar habilitada en los dispositivos ubicados a

ambos extremos de un tnel VPN en un grupo VPN. Si est habilitada en
dispositivo_s pero no en dispositivo_d, dispositivo_s suprime la transmisin de
pulsos de IKE y genera el siguiente mensaje en el registro de eventos: Heartbeats
have been disabled because the peer is not sending them (los pulsos se han
desactivado porque el interlocutor no los est enviando).
Figura 79: Flujo de pulsos IKE en ambos sentidos
Los pulsos de IKE deben fluir en ambos sentidos a travs del tnel VPN.
Para definir el intervalo de pulsos de IKE y el umbral para un tnel VPN especfico
(el valor predeterminado es 5), realice los siguientes pasos:
WebUI
VPN > AutoKey Advanced > Gateway > Edit (para la puerta de enlace
cuyo umbral de pulsos de IKE desee modificar) > Advanced: Introduzca los
nuevos valores en los campos Heartbeat Hello y Heartbeat Threshold y
haga clic en OK.
CLI
set ike gateway cadena_nombre heartbeat hello nmero
set ike gateway cadena_nombre heartbeat threshold nmero
Deteccin de interlocutor muerto

DPD es un protocolo que utilizan los dispositivos de red para verificar la existencia
actual y la disponibilidad de otros dispositivos de interlocutor.
Se puede utilizar DPD como una alternativa para la funcin de pulsos IKE (que se
describe anteriormente). No obstante, no se pueden utilizar ambas funciones
simultneamente. Adems, el pulso IKE puede utilizarse como un ajuste global, que
afecta todas las puertas de enlace IKE configuradas en el dispositivo. El ajuste de
pulso IKE tambin puede aplicarse a un contexto individual de puerta de enlace
IKE, que afecta nicamente a una sola puerta de enlace. En contraste, se puede
configurar el DPD nicamente en el contexto de una puerta de enlace individual
IDE, no como un parmetro global.
304
Un dispositivo realiza la verificacin de DPD enviando cargas encriptadas de

notificaciones IKE de fase 1 (R-U-THERE) a los interlocutores y esperar los
reconocimientos de DPD (R-U-THERE-ACK) por parte de los interlocutores. El
dispositivo enva una peticin de R-U-THERE, si y slo si no ha recibido ningn
trfico desde el interlocutor durante un intervalo especificado de DPD. Si un
dispositivo habilitado para DPD recibe trfico en un tnel, ste restablece su
contador de R-U-THERE para dicho tnel, con lo que inicia un nuevo intervalo. Si el
dispositivo recibe un R-U-THERE-ACK del interlocutor durante este intervalo, se
considera al interlocutor como activo. Si el dispositivo no recibe una respuesta al
R-U-THERE-ACK durante este intervalo, se considera al interlocutor como inactivo.
Cuando el dispositivo considera que un dispositivo de interlocutor est inactivo, el
dispositivo elimina la SA de la fase 1 y todas las SA de la fase 2 para dicho
interlocutor.
Se pueden configurar los siguientes parmetros de DPD, ya sea a travs de la CLI o
de la WebUI:
El parmetro interval especifica el intervalo de DPD. Este intervalo indica la

cantidad de tiempo (expresado en segundos) que permite transcurrir un
dispositivo antes de considerar como inactivo a un interlocutor.
El parmetro always-send le indica al dispositivo que enve peticiones de DPD,

independientemente de si existe trfico IPSec con el interlocutor.
El parmetro retry especifica el nmero mximo de veces que se enviar la

peticin de R-U-THERE, antes de considerar como inactivo al interlocutor.
Como sucede con la configuracin de pulso de IKE, el nmero predeterminado
de transmisiones es 5 veces, con un rango permitido de 1-128 reintentos. Un
ajuste cero desactiva la DPD.
En el ejemplo siguiente, se crea una puerta de enlace que utiliza un intervalo de

DPD de cinco segundos.
WebUI
VPN > AutoKey Advanced > Gateway > Edit: Cree una puerta de enlace
introduciendo los siguientes valores y luego haga clic en OK.
Gateway Name: our_gateway
Remote Gateway Type: Static IP Address
IP Address/Hostname: 1.1.1.1
Preshared Key: jun9345
VPN > AutoKey Advanced > Gateway > Edit (our_gateway): Introduzca los
siguientes valores y haga clic en OK.
Predefined: Standard (seleccione)
DPD:
Interval: 5
CLI
set ike gateway our_gateway address 1.1.1.1 main outgoing-interface untrust
preshare jun9345 sec-level standard
set ike gateway our_gateway dpd interval 5
305
Procedimiento de recuperacin IKE

Despus de que el dispositivo de seguridad de supervisin haya determinado que
un dispositivo de destino est fuera de lnea, el supervisor deja de enviar pulsos 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 contina intentando
establecer negociaciones de fase 1 a intervalos regulares hasta que obtiene
resultados satisfactorios.
Figura 80: Intentos repetidos de negociacin de fase 1 IKE
Supervisor
Intervalo:
5 minutos
(300 segundos)
..
.
..
.
Intentos de
negociacin de fase 1
IKE cada 5 minutos
Destino
Intento fallido
.
..
..
.
Intento fallido
..
.
..
.
Intento con xito
Para definir el intervalo de recuperacin IKE para un tnel VPN especfico (el ajuste
mnimo es 60 segundos), realice uno de los siguientes pasos:
WebUI
VPN > AutoKey Advanced > Gateway > Edit (para la puerta de enlace
cuyo intervalo de reconexin de IKE desee modificar) > Advanced:
Introduzca el valor en segundos en el campo Heartbeat Reconnect; luego,
haga clic en OK.
CLI
set ike gateway cadena_nombre heartbeat reconnect nmero
Cuando el miembro con el mayor peso de un grupo VPN realiza una conmutacin
por error del tnel a otro miembro del grupo y, a continuacin, conecta de nuevo
con el dispositivo de supervisin, se realiza automticamente una conmutacin por
recuperacin del tnel al primer miembro. El sistema de ponderacin hace que la
puerta de enlace que tiene la mayor valoracin del grupo se encargue siempre de
gestionar los datos VPN si es posible.
La Figura 81 en la pgina 307 muestra el proceso al que se somete un miembro de
un grupo VPN cuando la ausencia de pulsos de una puerta de enlace de destino
sobrepasa el umbral de fallo.
306
Figura 81: Conmutacin por error y luego recuperacin

Destino
Supervisor
Pulsos IKE en ambos sentidos
El destino deja de enviar pulsos IKE.
El supervisor realiza una conmutacin 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 tnel VPN con los intervalos especificados.
El destino responde a la iniciacin de fase 1 con pulsos IKE habilitados.
Las negociaciones de fase 1 y fase 2 IKE tienen xito, el tnel vuelve a

estar en lnea y se realiza una conmutacin por recuperacin de la
VPN (si su peso da preferencia a otros miembros del grupo VPN).
Comprobacin de indicador TCP SYN

Para que se produzca una conmutacin por error VPN gradual, es necesario
organizar la gestin de las sesiones TCP. Si, despus de una conmutacin por error,
la nueva puerta de enlace activa recibe un paquete durante una sesin TCP
existente, la nueva puerta de enlace lo gestiona como si fuera el primer paquete de
una sesin TCP nueva y comprueba si el indicador SYN est activado en el
encabezado del paquete. Como este paquete en realidad forma parte de una sesin
existente, no tiene el indicador SYN activado. En consecuencia, la nueva puerta de
enlace rechaza el paquete. Con la comprobacin de indicador TCP SYN habilitada,
todas las aplicaciones TCP se tienen que reconectar despus de que se produzca la
conmutacin por error.
Para resolver este problema, puede inhabilitar la comprobacin de indicador SYN
para las sesiones TCP en tneles VPN del siguiente modo:
WebUI
No es posible inhabilitar la comprobacin de indicador SYN mediante la
WebUI.
307
CLI
unset flow tcp-syn-check-in-tunnel
NOTA:
De forma predeterminada, la comprobacin de indicador SYN est habilitada.
Creacin de puertas de enlace VPN redundantes

En este ejemplo, un sitio corporativo tiene un tnel VPN que conecta con un centro
de datos y un segundo tnel que conecta con un centro de datos de respaldo. Todos
los datos se replican a travs de una conexin de lnea punto a punto entre los dos
centros de datos. Los centros de datos estn separados fsicamente para
proporcionar un servicio continuo, incluso en caso de fallo catastrfico, como un
corte de corriente de 24 horas o una catstrofe natural.
El nombre y la ubicacin del dispositivo, las interfaces fsicas y sus direcciones IP
para las zonas Trust y Untrust, y la ID de grupo VPN y el peso de cada dispositivo de
seguridad son los siguientes:
Ubicacin del
dispositivo
Interfaz fsica y
Nombre del direccin IP
dispositivo (zona Trust)
Empresa
Monitor1
ethernet1, 10.10.1.1/24 ethernet3, 1.1.1.1/24, (GW) 1.1.1.2
Centro de datos
(primario)
Destino1
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)
Destino2
ethernet1, 10.1.1.1/16
ethernet3, 3.3.3.1/24, (GW) 3.3.3.2
ID = 1, Peso = 1
NOTA:
Interfaz fsica, direccin IP,

puerta de enlace predeterminada ID de
(zona Untrust)
grupo VPN y peso
El espacio de direcciones interno en ambos centros de datos debe ser idntico.

Todas las zonas de seguridad se encuentran en el dominio de enrutamiento trust-vr.
Todos los tneles 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.
308
Figura 82: Puertas de enlace VPN redundantes

Untrust, ethernet3
2.2.2.1/24
Trust, ethernet1
10.1.1.1/16
Destino1
10.1.0.0/16
Sitio corporativo
Lnea punto a punto

para la rplica de
datos del sitio
primario al sitio de
respaldo
Monitor1
Internet
10.10.1.0/24
Trust, ethernet1
10.10.1.1/24
Untrust, ethernet3
1.1.1.1/24
Destino2
10.1.0.0/16
Untrust, ethernet3
3.3.3.1/24
Ubicacin del
centro de datos
primario
Ubicacin del
respaldo del
centro de datos
Trust, ethernet1
10.1.1.1/16
WebUI (Monitor1)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
2.
Direcciones
Address Name: in_trust
Zone: Trust
Address Name: data_ctr
Zone: Untrust
309
3.
VPN
VPNs > AutoKey Advanced > VPN Group: Introduzca 1 en el campo VPN
Group ID; luego, haga clic en Add.
y haga clic en OK:
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 segundos
Threshold: 5
VPN Name: to_target1
Remote Gateway: Predefined: (seleccione), target1

IKE:
VPN Group: VPN Group-1
Weight: 2
y haga clic en OK:
Gateway Name: target2
Remote Gateway Type: Static IP Address: (seleccione), IP Address: 3.3.3.1
Preshared Key: CMFwb7oN23

enlace:
Heartbeat:
Hello: 3 Seconds
Threshold: 5
310
VPN Name: to_target2
Remote Gateway: Predefined: (seleccione), target2

IKE:
VPN Group: VPN Group-1
Weight: 1
4.
Ruta
Gateway IP Address: 1.1.1.2(untrust)
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), in_trust
Address Book Entry: (seleccione), data_ctr
Service: ANY
Action: Tunnel
VPN: VPN Group-1
WebUI (destino1)
1.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
haga clic en OK:
Zone Name: Untrust
311
2.
Direcciones
Address Name: in_trust
Zone: Trust
Address Name: corp
Zone: Untrust
3.
VPN
y haga clic en OK:
Gateway Name: monitor1
Preshared Key: SLi1yoo129

enlace:
Heartbeat:
Hello: 3 Seconds
Name: to_monitor1
Remote Gateway: Predefined: (seleccione), monitor1
4.
Ruta
312
5.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), in_trust
Service: ANY
Action: Zona
Tunnel VPN: monitor1
WebUI (destino2)
NOTA:
Siga los pasos de configuracin de destino1 para configurar destino2, pero defina
la direccin IP de la interfaz de zona Untrust como 3.3.3.1/24, la direccin IP de
puerta de enlace predeterminada como 3.3.3.2 y utilice CMFwb7oN23 para
generar la clave previamente compartida.
CLI (Monitor1)
1.
Interfaces

2.
Direcciones
set address trust in_trust 10.10.1.0/24

set address untrust data_ctr 10.1.0.0/16
3.
VPN
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
313
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 (destino1)
1.
Interfaces

2.
Direcciones
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 (destino2)
NOTA:
Siga los pasos de configuracin de destino1 para configurar destino2, pero defina
la direccin IP de la interfaz de zona Untrust como 3.3.3.1/24, la direccin IP de
puerta de enlace predeterminada como 3.3.3.2 y utilice CMFwb7oN23 para
generar la clave previamente compartida.
Creacin de VPN adosadas

Puede aplicar directivas interzonales en el lado del concentrador para el trfico que
circule de un tnel VPN a otro ubicando los puntos radiales en zonas diferentes.
Como se encuentran en zonas distintas, el dispositivo de seguridad del
concentrador debe realizar una consulta de directivas antes de enrutar el trfico de
un tnel a otro. Se puede controlar el trfico que circule a travs de los tneles VPN
entre los puntos radiales. Esta configuracin se denomina VPN adosadas.
NOTA:
314
De forma opcional, puede habilitar un bloqueo intrazonal y definir una directiva

intrazonal para controlar el trfico entre las dos interfaces de tnel dentro de la
misma zona.
Figura 83: VPN adosadas
Zona X1
Zona X2
Red radial A
Red radial B
VPN1
VPN2
Consulta
de
directivas
Concentrador
A continuacin se mencionan algunas ventajas de las VPN adosadas:
Puede conservar el nmero de VPN que necesite crear. Por ejemplo, el punto de
permetro A puede enlazar con el concentrador y los puntos de permetro B, C,
D, etc., pero A slo tiene que configurar un tnel VPN. Especialmente para
usuarios de NetScreen-5XP, que pueden utilizar un mximo de diez tneles
VPN de forma simultnea, aplicar el mtodo radial aumenta de manera
significativa las opciones y capacidades VPN.
El administrador (admin) del dispositivo concentrador puede controlar

completamente el trfico VPN entre los puntos de permetro. Por ejemplo:
El administrador puede permitir slo la circulacin de trfico HTTP desde A

hasta B, pero permitir la circulacin de cualquier tipo de trfico desde B
hasta A.
El administrador puede permitir el acceso a C del trfico procedente de A,

pero denegar el acceso a A del trfico procedente de C.
El administrador puede permitir a un host concreto de A el acceso a toda la

red D y, al mismo tiempo, permitir slo a un host concreto de D acceder a
otro host distinto en A.
El administrador del dispositivo concentrador puede controlar completamente

el trfico saliente de todas las redes del permetro. En cada punto de permetro
debe existir primero una directiva que dirija todo el trfico de salida a travs de
las VPN radiales hasta el concentrador; por ejemplo: set policy top from trust
to untrust any any any tunnel vpn cadena_nombre (donde cadena_nombre
define el tnel VPN especfico que conecta cada punto de permetro con el
concentrador). En el concentrador, el administrador puede controlar el acceso a
Internet, permitiendo cierto tipo de trfico (por ejemplo, slo HTTP), realizando
bloqueos de URL o sitios web no deseables, etc.
Se pueden utilizar concentradores regionales y tneles interconectados

mediante radios, permitiendo que los puntos de radio de una regin accedan a
los puntos de radio de otra.
315
El ejemplo siguiente es parecido al descrito en Creacin de VPN radiales en la

pgina 321, excepto en un detalle: el dispositivo de seguridad del lado del
concentrador en Nueva York realiza una comprobacin de directivas en el trfico
que enruta entre los dos tneles con destino a las sucursales de Tokio y Pars.
Colocando cada sitio remoto en una zona distinta, se controla el trfico VPN en el
concentrador.
La direccin LAN de Tokio se encuentra en la zona definida por el usuario X1, y la
direccin LAN de Pars 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 se debera adquirir y cargar una
clave de software de zona en el dispositivo de seguridad.
El tnel VPN1 se asocia a la interfaz tunnel.1, y el tnel 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 tnel. Las rutas para estas interfaces
aparecen automticamente en la tabla de enrutamiento Trust-VR. Colocando la
direccin IP de una interfaz de tnel en la misma subred que la de destino, el
trfico destinado a dicha subred se enruta a la interfaz de tnel.
La interfaz de salida es ethernet3, que est asociada a la zona Untrust. Como puede
ver en la Figura 84, ambos tneles terminan en la zona Untrust; sin embargo, los
puntos finales para el trfico que utiliza estos tneles se encuentran en las zonas X1
y X2. Los tneles 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
tneles estn basados en rutas (es decir, el tnel correcto se determina por el
enrutamiento, no por un nombre de tnel especificado en una directiva), las ID de
proxy se incluyen en la configuracin de cada tnel.
Figura 84: VPN adosadas con dos dominios de enrutamiento y mltiples zonas de seguridad
Nueva York
Interfaz de salida
Zona Untrust
ethernet3, IP 123.1.1.1/24
Dominio de
enrutamiento
Trust-VR
Interfaz:
tunnel.1
10.10.1.2/24
Sede central en
Nueva York
(concentrador)
ethernet1
10.1.1.1/24
VPN1
Interfaz:
tunnel.2
10.20.1.2/24
Dominio de
enrutamiento
Untrust-VR
VPN2
Zona X1
LAN de Tokio
10.10.1.0/24
Zona X2
LAN de Pars
10.20.1.0/24
Consulta
de
directivas
Zona Trust
316
Tokio (radio)
110.1.1.1
Pars (radio)
220.2.2.2
Puerta de enlace
predeterminada
IP 123.1.1.2
WebUI
1.
Zonas de seguridad y enrutadores virtuales
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
Network > Zones > Edit (para Untrust): Introduzca los siguientes datos y haga
clic en OK:
Virtual Router Name: untrust-vr
Zone Name: X1
Zone Name: X2
2.
Interfaces
haga clic en OK:
Zone Name: Untrust
clic en OK:
Zone (VR): X1 (trust-vr)
clic en OK:
Zone (VR): X2 (trust-vr)
317
3.
VPN para la oficina de Tokio
VPN Name: VPN1
Gateway Name: Tokio

IKE:
Service: ANY
NOTA:
Para configurar el tnel VPN en el dispositivo de seguridad que protege las oficinas
de Tokio y Pars, ejecute uno de estos procedimientos:
(VPN basada en rutas) Seleccione la casilla de verificacin Enable Proxy-ID y
escriba 10.10.1.0/24 (Tokio) y 10.20.1.0/24 (Pars) para Local IP/Netmask,
y 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (Pars) para Remote IP/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 (Pars), y otra en la libreta de
direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (Pars).
Utilcelas como direcciones de origen y destino en la directiva relativa al tnel VPN
al sitio del concentrador (hub).
4.
VPN para la oficina de Pars
VPN Name: VPN2
Gateway Name: Pars

IKE:
Service: ANY
318
5.
Rutas
Next Hop Virtual Router Name: (seleccione), untrust-vr
Network > Routing > Routing Entries > untrust-vr New: Introduzca los
6.
Direcciones
Address Name: Tokio LAN
Zone: X1
Address Name: LAN de Pars
Zone: X2
7.
Directivas
Policy > (From: X1, To: X2) New: Introduzca los siguientes datos y haga clic
en OK:
Source Address:
Address Book Entry: (seleccione), Tokio LAN
Address Book Entry: (seleccione), Paris LAN
Service: ANY
Action: Permit
Policy > (From: X2, To: X1) New: Introduzca los siguientes datos y haga clic
en OK:
Source Address:
Address Book Entry: (seleccione), Paris LAN
Address Book Entry: (seleccione), Tokio LAN
Service: ANY
Action: Permit
319
CLI
1.

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
3.
set ike gateway Tokio address 110.1.1.1 outgoing-interface ethernet3 preshare

set vpn VPN1 gateway Tokio 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
NOTA:
Para configurar el tnel VPN en el dispositivo de seguridad que protege las oficinas
de Tokio y Pars, 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 (Tokio) y set vpn VPN1
proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 (Pars).
(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 (Pars), y otra en la libreta de
direcciones de la zona Untrust para 10.20.1.0/24 (Tokio) y 10.10.1.0/24 (Pars).
Utilcelas como direcciones de origen y destino en las directivas relativas al tnel
VPN al sitio del concentrador (hub).
4.
set ike gateway Paris address 220.2.2.2 outgoing-interface ethernet3 preshare

set vpn VPN2 gateway Paris sec-level compatible
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
6.
Direcciones
set address x1 Tokio LAN 10.10.1.0/24

set address x2 Paris LAN 10.20.1.0/24
320
7.
Directivas
set policy top from x1 to x2 Tokio LAN Paris LAN any permit
set policy top from x2 to x1 Paris LAN Tokio LAN any permit
save
NOTA:
Puede hacer caso omiso al siguiente mensaje, que aparece porque las interfaces
de tnel estn en modo NAT:
Warning (Advertencia): Some interfaces in the nombre_zona zone are in NAT
mode. Traffic might not pass through them!
Creacin de VPN radiales

Si crea dos tneles VPN que terminen en un dispositivo de seguridad, puede
configurar un par de rutas para que el dispositivo de seguridad dirija el trfico que
salga de un tnel hacia el otro. Si ambos tneles estn incluidos en la misma zona,
no es necesario crear una directiva para permitir que el trfico pase de un tnel a
otro. Slo es necesario definir las rutas. Esta configuracin se denomina VPN radial.
Tambin es posible configurar VPN mltiples en una zona y enrutar el trfico entre
dos tneles cualesquiera.
Figura 85: Tneles mltiples en una configuracin de VPN radial
Zona Untrust
Tneles VPN radiales mltiples
El dispositivo de seguridad enruta el trfico

entre tneles.
En este ejemplo, dos sucursales de Tokio y Pars se comunican entre s a travs de

un par de tneles VPN (VPN1 y VPN2). Cada tnel tiene su punto de origen en el
sitio remoto y termina en la sede central de Nueva York. El dispositivo de seguridad
de la sede central enruta el trfico que sale de un tnel hacia el otro.
Inhabilitando el bloqueo intrazonal, el dispositivo de seguridad de la sede central
slo tiene que hacer una consulta de rutas (no una consulta de directivas) para
dirigir el trfico de un tnel a otro porque ambos puntos finales remotos se
encuentran en la misma zona (zona Untrust).
NOTA:
De forma opcional, puede mantener el bloqueo intrazonal habilitado y definir una

directiva intrazonal que permita el trfico entre las dos interfaces de tnel.
321
Los tneles se asocian a las interfaces de tnel (tunnel.1 y tunnel.2), que estn sin
numerar. Los tneles 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 configuracin 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.
Figura 86: VPN radiales

Dominio de enrutamiento untrust-vr
Zona Untrust
Interfaz
de salida
ethernet3
IP 1.1.1.1
Puerta de enlace
predeterminada
IP 1.1.1.250
Tokio 2.2.2.2
(radio)
LAN de Tokio
10.2.2.0/24
Internet
VPN1
VPN2
Pars 3.3.3.3
(radio)
Interfaz:
tunnel.1
Nueva York: sede central

(concentrador)
LAN de Pars
10.3.3.0/24
Interfaz:
tunnel.2
WebUI (Nueva York)

1.
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:
Block Intra-Zone Traffic: (anule la seleccin)
2.
Interfaces
haga clic en OK:
Zone Name: Untrust
322
clic en OK:
Zone (VR): Untrust (untrust-vr)
Interface: ethernet3 (untrust-vr)
clic en OK:
3.
VPN Name: VPN1
Gateway Name: Tokio

IKE:
Service: ANY
4.
VPN Name: VPN2
Gateway Name: Pars

IKE:
Service: ANY
323
5.
Rutas
Interface: tunnel.1
Interface: tunnel.2
WebUI (Tokio)
1.
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:
2.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
324
haga clic en OK:
Zone Name: Untrust
clic en OK:
3.
Direccin
Address Name: Pars
Zone: Untrust
4.
VPN
VPN Name: VPN1
Gateway Name: Nueva York

IKE:
Service: ANY
5.
Rutas
Next Hop Virtual Router Name: (seleccione); untrust-vr
325
Interface: tunnel.1
6.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Paris
Service: ANY
Action: Permit
WebUI (Pars)
1.
haga clic en OK:
Manage IP: 0.0.0.0
haga clic en OK:
Zone Name: Null
clic en OK:
2.
Interfaces
haga clic en Apply:
Zone Name: Trust
Interface Mode: NAT
326
haga clic en OK:
Zone Name: Untrust
clic en OK:
3.
Direccin
Address Name: Tokio
Zone: Untrust
4.
VPN
VPN Name: VPN2
Gateway Name: Nueva York

IKE:
Service: ANY
5.
Rutas
Next Hop Virtual Router Name: (seleccione); untrust-vr
327
Interface: tunnel.1
6.
Directivas
haga clic en OK:
Source Address:
Address Book Entry: (seleccione), Tokio
Service: ANY
Action: Permit
CLI (Nueva York)

1.

unset zone untrust block
2.
Interfaces

3.
set ike gateway Tokio address 2.2.2.2 outgoing-interface ethernet3 preshare

set vpn VPN1 gateway Tokio sec-level compatible
4.
set ike gateway Paris address 3.3.3.3 outgoing-interface ethernet3 preshare

set vpn VPN2 gateway Paris sec-level compatible
328
5.
Rutas
set vrouter untrust-vr route 10.2.2.0/24 interface tunnel.1

save
CLI (Tokio)
1.

2.
Interfaces

3.
Direccin
set address untrust Paris 10.3.3.0/24

4.
VPN
set ike gateway Nueva York address 1.1.1.1 outgoing-interface ethernet3

preshare netscreen1 sec-level compatible
set vpn VPN1 gateway Nueva 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 (Pars)
1.

2.
Interfaces

329
3.
Direccin
set address untrust Tokio 10.2.2.0/24

4.
VPN
set ike gateway Nueva York address 1.1.1.1 outgoing-interface ethernet3

preshare netscreen2 sec-level compatible
set vpn VPN2 gateway Nueva York sec-level compatible
5.
Rutas

6.
Directivas
set policy from trust to untrust any Tokio any permit

set policy from untrust to trust Tokio any any permit
save
330
Captulo 8
Redes privadas virtuales de

AutoConnect
Este captulo describe la funcin (AC-VPN) de red privada virtual de AutoConnect en
ScreenOS, explica cmo funciona en una topologa de red radial y proporciona un
ejemplo de configuracin de un escenario tpico en el cual se puede utilizar.
Vista general
Las organizaciones de empresas pequeas que aseguran sus sitios satlites remotos
con los tneles de red privada virtual (VPN) suelen interconectar todos los sitios en
una VPN de malla completa, ya que los sitios remotos se deben comunicar entre s,
al igual que con las oficinas centrales. En este tipo de red, generalmente los sitios
remotos ejecutan dispositivos de seguridad finales de pocas prestaciones que
admiten un mximo de 25 tneles VPN. Sin embargo, cuando la cantidad total de
sitios es superior a 25, la empresa debe colocar dispositivos de seguridad con
mayor capacidad en sus sitios remotos (a un costo considerable) o cambiar de una
topologa de malla completa a una red radial.
Una configuracin radial soluciona el problema de escalabilidad, pero su resultado
fundamental es que toda la comunicacin entre las redes radiales debe pasar por el
concentrador. Esto por lo general, no es un problema cuando el trfico consta de
pocos datos, incluso con ms de mil redes radiales. Sin embargo, si el trfico es de
vdeo o de voz sobre protocolo de Internet (VoIP), la carga mxima de
procesamiento en el concentrador puede ocasionar latencia, un problema serio
para estas aplicaciones.
AC-VPN le proporciona un mtodo para configurar su red radial, de manera que las
redes radiales puedan crear tneles VPN de forma dinmica, directamente entre s,
segn sea necesario. Esto no slo resuelve el problema de latencia entre las redes
radiales sino tambin reduce el gasto de procesamiento en el concentrador,
mejorando todo el funcionamiento de la red. Adicionalmente, debido a que AC-VPN
crea tneles de forma dinmica, que tienen un tiempo de espera cuando el trfico
se detiene para fluir a travs de los mismos, los administradores de la red se liberan
de la tarea de mantener una red compleja de tneles VPN estticos, que exige
mucho tiempo de trabajo.
Vista general
331
Cmo funciona
AC-VPN est diseada para implementarse en una red radial, donde todas las redes
radiales estn conectadas al concentrador por medio de los tneles VPN. Despus
de configurar un tnel VPN esttico entre el concentrador y cada una de las redes
radiales, configure la AC-VPN en el concentrador y las redes radiales, y luego
habilite el protocolo de resolucin de siguiente salto (NHRP). El concentrador utiliza
NHRP para obtener un rango de informacin sobre cada red radial, incluso sobre
sus asignaciones de direcciones pblicas y privadas, longitud de la mscara de
subred y enrutamiento e informacin de recuento de saltos, que el concentrador
guarda en cach. Luego, cuando alguna red radial comienza a comunicarse con otra
red radial (a travs del concentrador), el concentrador utiliza esta informacin,
junto con la informacin obtenida a travs de la configuracin de AC-VPN de las
redes radiales, para habilitar las redes radiales para configurar un tnel AC-VPN
entre dichas redes. Mientras se negocia el tnel, la comunicacin contina fluyendo
entre las dos redes radiales a travs del concentrador. Cuando el tnel dinmico se
activa, el concentrador se desconecta y el trfico fluye directamente entre las dos
redes radiales. Cuando el trfico deja de fluir a travs del tnel dinmico, el tnel
entra a tiempo de espera.
Mensajes NHRP
En el contexto de NHRP, el concentrador que est en una red radial se conoce como
servidor de siguiente salto (NHS) y la red radial se llama cliente de siguiente salto
(NHC). La comunicacin NHRP entre NHS y NHC se lleva a cabo a travs de un
intercambio formal de mensajes NHRP. El protocolo de resolucin de siguiente salto
(RFC 2332) de acceso mltiple sin difusin (NBMA) define siete mensajes de NHRP.
A estos siete mensajes, ScreenOS agrega dos ms. Estos nueve mensajes y su
funcionamiento en una red radial AC-VPN se definen de la siguiente manera:
NOTA:
En la implementacin actual de ScreenOS, NHRP no redistribuye ninguna ruta a

sus interlocutores y BGP y OSPF no redistribuyen las rutas NHRP a sus
interlocutores.
332
Cmo funciona
Peticin de registro: Despus de que un tnel VPN esttico se active entre un

NHC y su NHS, el NHC enva un mensaje de peticin de registro NHRP a NHS.
El mensaje contiene varias entradas de informacin del cliente (CIE), que
incluyen datos como las asignaciones de direcciones pblicas y privadas de
NHC, longitud de mscara de subred e informacin de recuento de saltos y
enrutamiento.
Respuesta de registro: El NHS puede responder a una peticin de registro con

ACK o NAK. Si el NHS no reconoce el paquete, no se emite una confirmacin de
recibido (NAK) por el paquete y ste se descarta. Tras la realizacion satisfactoria
del registro, el NHS guarda en cach las CIE que estn en la peticin de registro
y enva un ACK de respuesta de registro.
Captulo 8: Redes privadas virtuales de AutoConnect
Peticin de resolucin, Respuesta de resolucin: Con la introduccin de los

mensajes de Resolution-ack y Resolution-set de propiedad de ScreenOS, la
funcin del par de mensajes de peticin de resolucin de NHRP y respuesta de
resolucin queda relegado para guardar en cach las CIE en el NHS actual. Los
NHC hacen esto junto con el tiempo de espera configurado en el NHS, que
especifica la duracin de las entradas guardadas en cach por cada NHC. Para
garantizar que el NHS cuenta con la informacin actual sobre sus subredes, los
NHC envan peridicamente mensajes de peticin de resolucin al NHS. Si se
ha agregado o eliminado algn dispositivo de sus subredes, esa informacin se
encuentran en el mensaje de peticin de resolucin y el NHS actualiza su cach
y enva una respuesta de resolucin.
Peticin de eliminacin, Respuesta de eliminacin: Cuando un

administrador apaga un NHC, el dispositivo enva un mensaje de peticin de
eliminacin al NHS. Al recibir la peticin de eliminacin, el NHS elimina todas
las entradas guardadas en cach para ese NHC y enva una respuesta de
eliminacin. Si el NHC experimenta un fallo en el sistema y se desconecta, el
NHS elimina las entradas guardadas en cach para el dispositivo despus de
que expire la duracin configurada para la cach.
Indicacin de error: Este mensaje registra las condiciones de error de NHRP.
Para admitir AC-VPN, ScreenOS agrega el siguiente par de mensajes:
Resolution-set, Resolution-ack: Cuando el NHS detecta el trfico de un tnel

VPN esttico a otro, ste enva mensajes de Resolution-set a los NHC al final de
cada tnel esttico. Estos mensajes contienen toda la informacin que cada
NHC necesita saber sobre el otro para configurar un tnel AC-VPN. Cuando el
NHC responde con mensajes de Resolution-ack, el NHS dirige uno de los NHC
para iniciar la negociacin del tnel AC-VPN.
Iniciacin del tnel AC-VPN

La Figura 87 ilustra cmo ScreenOS activa la configuracin de un tnel AC-VPN con
los mensajes de peticin de registro y respuesta de registro de NHRP, y los mensajes
personalizados de Resolution-set y Resolution-ack de ScreenOS. Para la
simplificacin, la figura no muestra el intercambio de mensajes de peticin de
resolucin y respuesta de resolucin, ni de los mensajes de eliminacin y error. (Las
abreviaturas RR1 y RR2 se refieren a la red radial 1 y red radial 2 respectivamente,
D1 y D2 se refieren a los destinos situados detrs de esas redes radiales.)
Cmo funciona
333
Figura 87: Configuracin de AC-VPN a travs de NHRP

NHS - Concentrador
NHC - Red radial 1
NHS - Red radial
1. RR1 entra en lnea

Peticin de registro
2.
(enva subredes protegidas, hash self-cert, ID local)

Respuesta de registro
3.
RR2 entra en lnea
(enva perfil AC-VPN)
4.
Peticin de registro
5.
(enva subredes protegidas, hash self-cert, ID local)
Respuesta de registro
6.
D1 tras RR1 enva nuevo trfico a D2 tras RR2
7.
(enva perfil AC-VPN)

El concentrador reenva el trfico a RR2
El concentrador enva Resolution-set con detalles de RR1
8.
RR2 enva Resolution-ack
El concentrador enva Resolution-set con detalles de RR2
9.
10.
RR1 enva Resolution-ac
11.
RR1 inicia tnel AC-VPN con RR2

12.
El trfico entre D1 y D2 fluye entre RR1 y RR2 en el tnel AC-VPN
Configuracin de AC-VPN
Se aplican las siguientes restricciones generales:
334
Cmo funciona
Todos los tneles VPN configurados en el concentrador, se deben basar en

rutas.
La administracin automtica de claves en la fase 1 debe estar en el modo

dinmico.
El mtodo de autenticacin debe ser por medio de un certificado autofirmado y

genrico PKI.
Todas las redes radiales se deben conectar a una zona individual en el

concentrador.
La configuracin de NHRP en varias instancias de enrutadores virtuales es

admitida slo en el NHS.
El registro de NHC a NHS admite los protocolos de enrutamiento dinmico. Al

configurar las redes radiales, usted debe utilizar el comando set protocol nhrp
cache dir_ip/mscara para agregar rutas.
Traduccin de direcciones de red

Las siguientes restricciones aplican con NAT:
Nat-Traversal: AC-VPN puede crear un tnel dinmico entre dos redes radiales,
si una de las redes est detrs de un dispositivo NAT en la ruta hacia el
concentrador; si ambas redes radiales estn detrs de los dispositivos NAT, pero
no se crear un tnel dinmico y la comunicacin entre las redes radiales
continuar a travs del concentrador. Consulte NAT-Traversal en la pgina 240
para obtener ms informacin sobre NAT-Traversal.
La traduccin NAT es compatible nicamente con las direcciones del protocolo

de Internet asignado (MIP).
La traduccin de direcciones de puerto (PAT) slo se admite entre una red radial
y el concentrador. Por ejemplo, puede tener un dispositivo NAT entre una red
radial y el concentrador y se puede crear un tnel dinmico entre esa red radial
y otra red radial, siempre y cuando no exista un dispositivo NAT entre esa otra
red radial y el concentrador. En este escenario, el concentrador forzar la red
radial detrs del dispositivo de NAT para iniciar el tnel hacia otra red radial.
La PAT se admite directamente enfrente del concentrador.
No se admite la PAT entre las redes radiales.
Configuracin en el concentrador
La configuracin de la red radial incluye lo siguiente:
1. Crear una puerta de enlace esttica y VPN.
2. Crear tneles estticos en las redes radiales y conectar las VPN a los tneles.
3. Crear un perfil de puerta de enlace de AC-VPN.
4. Crear un perfil de VPN de AC-VPN.
5. Habilitar NHRP en el enrutador virtual.
6. Seleccione ACVPN-Perfil para NHRP.
7. Habilitar NHRP en la interfaz del tnel.
8. Configurar el enrutamiento.
Configuracin en cada red radial

El concentrador incluye lo siguiente:
1. Crear un tnel esttico hacia el enrutador.
2. Crear una puerta de enlace.
Cmo funciona
335
3. Crear una puerta de enlace de VPN.

4. Crear una puerta de enlace de ACVPN-dinmica.
5. Crear una VPN de ACVPN-dinmica.
6. Habilitar NHRP en el enrutador virtual.
7. Configurar la direccin IP de NHS.
8. Configurar la cach local.
9. Habilitar NHRP en la interfaz del tnel.
10. Configurar el enrutamiento.
Ejemplo
En este ejemplo, un dispositivo de seguridad final de altas prestaciones, que acta
como el concentrador en una red radial, est configurado para actuar como el
servidor de siguiente salto (NHS) en una configuracin AC-VPN, en la que
red_radial1 y red_radial2 (dispositivos de seguridad finales de bajas prestaciones)
son clientes de siguiente salto (NHC). Despus de configurar las interfaces en los
dispositivos, configurar los tneles VPN estticos entre el concentrador y cada una
de las redes radiales, luego configure la AC-VPN y habilite NHRP en las interfaces de
conexin. Aunque este ejemplo utiliza el protocolo de enrutamiento de abrir
primero la ruta ms corta (OSPF), ScreenOS admite todos los protocolos de
enrutamiento dinmico con AC-VPN.
NOTA: AC-VPN tambin admite el protocolo de control de host dinmico (DHCP).
336
Cmo funciona
10.1.1.0/24
Concentrador
t.1--10.0.0.2
e2/1--1.1.1.1
Internet
t.1--10.0.0.2
e0/0--3.3.3.1
e0/0--2.2.2.1/24
t.1--10.0.0.3/24
Red radial--1
Red radial--2
Tnel dinmico
10.1.2.0/24
10.1.3.0/24
WebUI (concentrador)
NOTA: Despus de configurar las puertas de enlace estticas y las VPN estticas del
concentrador a las redes radiales y de las redes radiales al concentrador, puede
utilizar el asistente de AC-VPN para completar la configuracin de AC-VPN.
1.
Interfaces
Network > Interfaces > Edit (para ethernet2/1): Introduzca los siguientes
Zone Name: Untrust
Interface Mode: Route
Zone Name: Trust
Interface Mode: NAT
Cmo funciona
337
Network > Interfaces > New (Tunnel IF): Introduzca los siguientes datos y
haga clic en Apply:
Tunnel Interface Name: 1
Zone (VR): Trust-vr
Fixed IP
Unnumbered
Interface:
NHRP Enable: (Seleccione)
2.
Configure los tneles en red_radial1 y red_radial2
VPN > AutoKey Advanced > Gateway > New: Configure la puerta de enlace de
IKE, haga clic en Advanced y establezca el nivel de seguridad, luego haga clic
en Return para regresar a la pgina de configuracin de la puerta de enlace IKE
y haga clic en OK:
Gateway Name: Red_radial1
Remote Gateway: (Seleccione)
Static IP Address: (Seleccione) IPvc4/v6 Address/Hostname: 2.2.2.1
Preshare key: Juniper
Outgoing interface: (seleccione) ethernet2/1
y haga clic en OK:
Gateway Name: Red_radial2
3.
Configure la red radial de VPN en la puerta de enlace
VPN > AutoKey IKE > New: Configure la puerta de enlace de IKE, haga clic
en Advanced y establezca el nivel de seguridad, luego haga clic en Return para
regresar a la pgina de configuracin de la puerta de enlace IKE y haga clic
en OK:
VPN Name: red_radial1
Remote Gateway: (seleccione) Predefined
(seleccione el nombre de puerta de enlace correcto de la lista predefinida del
men desplegable)
Security Level (seleccione) Standard
Bind To: (seleccione) Tunnel Interface
(seleccione Tunnel.1 del men desplegable)
338
Cmo funciona
en OK:
VPN Name: red_radial2
men desplegable)
4.
Configure ACVPN-Perfil
y haga clic en OK:
Gatewary Name: ac-spoke-gw
ACVPN-Profile: (seleccione)
Security Level: (seleccione) Standard
VPN > AutoKey IKE > New: Configure el perfil de ACVPN, haga clic
en Advanced y establezca el nivel de seguridad y la Proteccin de respuesta,
luego haga clic en Return para regresar a la pgina de configuracin de VPN y
haga clic en OK
VPN Name: ac-vpn
ACVPN-Profile: (seleccione)
Binding to tunnel: (seleccione) ac-spoke-gw
Security Level: (seleccione) Standard
Replay Protection: (seleccione)
5.
Configure el vrouter
Network > Routing > Virtual Router > (para el trust-vr) Edit: Introduzca los
siguientes datos y haga clic en Apply:
Next Hop Resolution Protocol(NHRP) Support
NHRP: (seleccione) NHRP Setting
NHS Setting: (seleccione)
Profile: (seleccione) ACVPN-Profile name
6.
Habilite NHRP en la interfaz del tnel
Network > Interfaces > New (para TunnelIF): Introduzca los siguientes datos y
haga clic en Apply:
NHRP Enable: (seleccione)
Cmo funciona
339
7.
Configure el enrutamiento
Network > Routing > Destination > New: Introduzca los siguientes datos y
haga clic en Apply:
IP Address/netmask: 0.0.0.0
Gateway (seleccione)
CLI (concentrador)
set interface ethernet2/1 zone Untrust
set interface ethernet2/2 zone Trust
set interface tunnel.1 zone Trust
set
set
set
set
set
interface ethernet2/1 ip 1.1.1.1/24

interface ethernet2/1 route
interface ethernet2/2 nat
interface tunnel.1 ip 10.0.0.1/24
set ike gateway red_radial2 address 3.3.3.1 Main outgoing-interface ethernet2/1

preshare juniper== sec-level standard
set ike gateway red_radial1 address 2.2.2.1 Main outgoing-interface ethernet2/1
set vpn red_radial2 gateway red_radial2 no-replay tunnel idletime 0 sec-level
standard
set vpn red_radial2 id 1 bind interface tunnel.1
set vpn red_radial1 gateway red_radial1 no-replay tunnel idletime 0 sec-level
standard
set vpn red_radial1 id 2 bind interface tunnel.1
set ike gateway ac-spoke-gw acvpn-profile sec-level standard
set vpn ac-vpn acvpn-profile ac-spoke-gw no-replay tunnel idletime 0 sec-level
standard
set vrouter trust-vr
set protocol nhrp
set protocol nhrp acvpn-profile ac-vpn
exit
set interface tunnel.1 protocol nhrp enable
set vr trust protocol ospf
set vr trust protocol ospf enable
set vr trust protocol ospf area 10
set interface ethernet2/2 protocol ospf area 0.0.0.10
set interface ethernet2/2 protocol ospf enable
set interface tunnel.1 protocol ospf area 0.0.0.0
set interface tunnel.1 protocol ospf link-type p2mp
set interface tunnel.1 protocol ospf enable
set route 0.0.0.0/0 gateway 1.1.1.2
340
Cmo funciona
WebUI (Red_radial1)
1.
Interfaces
Zone Name: Untrust
Network > Interfaces > Edit (para bgroup0): Introduzca los siguientes datos y
haga clic en Apply:
Zone Name: Trust
Zone Name: Trust
Interface Mode: NAT
Network > Interfaces > Edit (para ethernet2/2), Seleccione Bind Port, ingrese
lo siguiente, luego haga clic en Apply:
ethernet0/2 bgroup0: (seleccione) Bind to Current Bgroup
haga clic en Apply:
Zone (VR): Trust-vr
Fixed IP
2.
Configure el tnel en el concentrador
y haga clic en OK:
Gateway Name: hub-gw
Cmo funciona
341
3.
en OK:
VPN Name: vpn-hub
men desplegable)
4.
Configure ACVPN-Dinmica
y haga clic en OK:
Gatewary Name: ac-hub-gw
ACVPN-Dynamic: (seleccione)
VPN > AutoKey > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: ac-hub-vpn
Gateway (seleccione): ac-hub-gw
Tunnel Towards Hub: (seleccione) vpn-hub
5.
Configure el enrutador virtual
Next Hop Resolution Protocol (NHRP) Support
NHC Setting: (seleccione)
NHS IP Address: 10.1.1.1
6.
haga clic en Apply:
7.
haga clic en Apply:
342
Cmo funciona
CLI (Red_radial1)
set interface bgroup0 zone Trust
set interface bgroup0 port ethernet0/2
set
set
set
set
set

interface bgroup0 ip 10.1.2.1/24
interface bgroup0 nat
set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0

set vpn vpn-hub id 1 bind interface tunnel.1
set ike gateway ac-hub-gw acvpn-dynamic
set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub
set protocol nhrp
set protocol nhrp nhs 10.0.0.1
set protocol nhrp cache 10.1.2.0/24
exit
set interface bgroup0 protocol ospf area 0.0.0.20
set interface bgroup0 protocol ospf enable
WebUI (Red_radial2)
1.
Interfaces
Zone Name: Untrust
Network > Interfaces > Edit (para bgroup0): Introduzca los siguientes datos y
haga clic en Apply:
Zone Name: Trust
Zone Name: Trust
Interface Mode: NAT
Cmo funciona
343
Network > Interfaces > Edit (para ethernet2/2), seleccione Bind Port, ingrese
lo siguiente, luego haga clic en Apply:
ethernet0/2 bgroup0: (seleccione) Bind to Current Bgroup
haga clic en Apply:
Zone (VR): Trust-vr
Fixed IP
2.
Configure el tnel en el concentrador
y haga clic en OK:
Gateway Name: hub-gw
3.
en OK:
VPN Name: vpn-hub
men desplegable)
4.
Configure ACVPN-Dinmica
y haga clic en OK:
Gatewary Name: ac-hub-gw
VPN > AutoKey > New: Introduzca los siguientes datos y haga clic en OK:
VPN Name: ac-hub-vpn
Gateway (seleccione): ac-hub-gw
Tunnel Towards Hub: (seleccione) vpn-hub
344
Cmo funciona
5.
Configure el vrouter
Next Hop Resolution Protocol(NHRP) Support
NHC Setting: (seleccione)
NHS IP Address: 1.1.1.1
6.
haga clic en Apply:
7.
haga clic en Apply:
CLI (Red_radial2)
set interface bgroup0 zone Trust
set interface bgroup0 port ethernet0/2
set
set
set
set
set

interface bgroup0 ip 10.1.3.1/24
interface bgroup0 nat
set ike gateway hub-gw address 1.1.1.1 Main outgoing-interface ethernet0/0

set vpn vpn-hub id 1 bind interface tunnel.1
set ike gateway ac-hub-gw acvpn-dynamic
set vpn ac-hub-vpn acvpn-dynamic ac-hub-gw vpn-hub
set protocol nhrp
set protocol nhrp nhs 10.0.0.1
set protocol nhrp cache 10.1.3.0/24
exit
Cmo funciona
345

set interface bgroup0 protocol ospf area 0.0.0.30
set interface bgroup0 protocol ospf enable
346
Cmo funciona
ndice
Numerics
3DES .................................................................................6
A
Advanced Encryption Standard (AES) ...........................7
AES ....................................................................................7
AH..................................................................................3, 6
Ajustes de L2TP, DNS ..................................................217
archivos MIB, importacin .........................................262
asociaciones de seguridad
vase SA
ataques
repeticin .................................................................12
Autenticacin
algoritmos ..........................................6, 53, 57, 60, 63
C
carga de seguridad encapsulada
vase ESP
certificado local ..............................................................25
certificados .......................................................................8
CA........................................................................22, 25
carga .........................................................................28
carga de CRL ............................................................23
local...........................................................................25
peticin .....................................................................26
por medio del correo electrnico ..........................25
revocacin ..........................................................25, 35
certificados de CA ....................................................22, 25
Challenge Handshake Authentication Protocol
vase CHAP
CHAP .....................................................................213, 217
clave manual
administracin...........................................................7
claves
manuales ........................................................120, 127
previamente compartidas ....................................165
claves previamente compartidas ...........................8, 165
cdigo de autenticacin de mensajes basado en
hash ................................................................................6
comodines ....................................................................192
comprobacin contra reprocesamiento de
paquetes ................................................................55, 61
confidencialidad directa perfecta
vase PFS
conjuntos de DIP
interfaces extendidas ............................................143
NAT para VPNs ......................................................143
contenedores ................................................................193
CRL
vase Lista de revocacin de certificados
D
DES ....................................................................................6
Diffie-Hellman ................................................................11
Direcciones de protocolo de Internet (IP)
vase direcciones IP
Direcciones IP
extendidas ..............................................................143
directivas
VPN bidireccionales ..............................................128
DN .................................................................................189
E
Encabezado de autenticacin (AH) ................................6
encriptacin
algoritmos ..............................................6, 53, 56 a 63
ESP ................................................................................3, 6
encriptacin y autenticacin ............................56, 63
slo autenticacin ...................................................56
slo encriptacin .....................................................56
F
Fase 1 ................................................................................9
propuestas ..................................................................9
propuestas, predefinidas ..........................................9
Fase 2 ..............................................................................11
propuestas ................................................................11
propuestas, predefinidas ........................................12
firma digital ....................................................................20
flujo de paquetes
VPN basada en directivas ...............................70 a 71
VPN basada en rutas .......................................66 a 70
VPN de entrada ...............................................68 a 70
VPN de salida ...........................................................68
H
HMAC ................................................................................6
ndice
IX-I
I
ID de proxy .................................................................... 12
coincidencia ....................................................... 65, 72
certificados .................................................. 189 a 198
claves previamente compartidas .............. 198 a 204
IDs de proxy
VPNs y NAT ................................................. 142 a 144
IKE................................................................. 7, 88, 97, 165
ID de proxy .............................................................. 12
ID IKE, Windows 2000 ................................. 225, 233
ID local, ASN1-DN ................................................. 192
ID remota, ASN1-DN ............................................ 192
identificacin IKE .............................. 53 a 55, 60 a 61
identificacin IKE de grupo, comodines ............ 192
identificacin IKE de grupo, container ............... 193
mensajes de saludo .............................................. 304
propuestas de fase 1, predefinidas ......................... 9
propuestas de fase 2, predefinidas ....................... 12
puertas de enlace redundantes ................. 301 a 314
pulsos ..................................................................... 304
recomendaciones de ID IKE .................................. 73
usuario de identificacin IKE
compartida ................................................ 204 a 210
usuario de identificacin IKE de grupo .... 189 a 204
infraestructura de claves pblicas
vase PKI
intercambio de claves de Internet
vase IKE
Interfaces
extendidas ............................................................. 143
null ............................................................................ 87
IPSec
AH ................................................................... 2, 56, 62
ESP .................................................................. 2, 56, 62
firma digital ............................................................. 20
L2TP sobre IPSec ...................................................... 4
modo de transporte .......................... 4, 213, 219, 224
modo de tnel ........................................................... 4
negociacin de tnel................................................. 9
SA .................................................................. 2, 8, 9, 11
SPI ............................................................................... 2
tnel ............................................................................ 2
L
L2TP .................................................................... 211 a 237
autenticado del tnel Windows 2000 ......... 222, 227
bidireccional .......................................................... 213
concentrador de accesos: vase LAC
configuracin obligatoria ..................................... 211
configuracin voluntaria ...................................... 212
desencapsulado ..................................................... 216
Encapsulamiento................................................... 214
Keep Alive ...................................................... 222, 227
IX-II
ndice
L2TP en solitario sobre Windows 2000 .............213

modo de funcionamiento .....................................214
parmetros predeterminados ..............................217
seal hello ......................................................222, 227
servidor de red: vase LNS
Servidor RADIUS ...................................................217
servidor SecurID ....................................................217
soporte de ScreenOS ............................................213
tnel ........................................................................219
L2TP sobre IPSec .............................................4, 219, 224
bidireccional ..........................................................213
tnel ........................................................................219
LAC ................................................................................211
NetScreen-Remote 5.0..........................................212
Windows 2000 ......................................................212
Layer 2 Tunneling Protocol
vase L2TP
Lista de revocacin de certificados........................23, 35
carga .........................................................................23
LNS ................................................................................211
M
mantenimiento de conexin
frecuencia, NAT-T de ............................................246
L2TP ........................................................................222
MD5...................................................................................6
Message Digest versin 5 (MD5)....................................6
MIP, VPNs .....................................................................143
modo de transporte.................................4, 213, 219, 224
Modo de tnel ..................................................................4
modo dinmico..............................................................10
modo principal...............................................................10
modos
Criptografa Fase 1 ............................................51, 58
dinmico ..................................................................10
operacional L2TP ..................................................214
principal ...................................................................10
Transporte ....................................4, 62, 213, 219, 224
tnel ......................................................................4, 62
mdulo ............................................................................11
N
NAT
IPSec y NAT ...........................................................240
servidores NAT ......................................................240
NAT-dst
VPN .........................................................................143
NAT-src
VPN .........................................................................145
NAT-T ................................................................... 240 a 248
frecuencia de mantenimiento de conexin .......246
habilitar ..................................................................248
iniciador y respondedor .......................................246
obstculos para VPN .............................................243
ndice
Paquete IKE ...........................................................244

Paquete IPSec ........................................................245
sondeos de NAT .......................................... 241 a 243
NAT-Traversal
Vase NAT-T
NetScreen-Remote
interlocutor dinmico ...................................170, 177
opcin NAT-T .........................................................240
VPN AutoKey IKE ..................................................165
nombre completo (DN) ...............................................189
Norma de encriptacin de datos (DES) .........................6
O
OCSP (Online Certificate Status Protocol)...................35
cliente .......................................................................35
servidor de respuesta .............................................35
opcin de reencriptacin, supervisin de VPN ........251
opciones criptogrficas ......................................... 50 a 64
acceso telefnico ............................................. 57 a 64
algoritmos de autenticacin.................53, 57, 60, 63
algoritmos de encriptacin ...................... 53 a 59, 63
comprobacin contra reprocesamiento de
paquetes ...........................................................55, 61
ESP ......................................................................56, 63
identificacin IKE .............................. 53 a 55, 60 a 61
longitudes de bits de los certificados ..............52, 59
mtodos de administracin de claves ..................51
modo de transporte ................................................62
Modo de tnel ..........................................................62
modos de fase 1 ................................................51, 58
PFS ......................................................................55, 61
protocolos IPSec ................................................56, 62
punto a punto .................................................. 50 a 57
recomendaciones VPN de acceso telefnico .......64
recomendaciones VPN punto a punto ..................57
tipos de autenticacin.......................................52, 58
P
PAP ........................................................................213, 217
par de claves pblica/privada .......................................23
Password Authentication Protocol
vase PAP
PFS ......................................................................12, 55, 61
PKI ...................................................................................22
PPP ................................................................................212
propuestas
Fase 1 ...................................................................9, 72
Fase 2 .................................................................11, 72
proteccin contra reprocesamiento de paquetes.......12
protocolo punto a punto
vase PPP
Protocolos
CHAP.......................................................................213
PAP..........................................................................213
PPP ..........................................................................212
puertas de enlace redundantes ........................301 a 314
comprobacin de indicador TCP SYN.................307
procedimiento de recuperacin ..........................306
R
RADIUS
L2TP ........................................................................217
ruta Null ..........................................................................87
rutas
null ............................................................................87
S
SA.............................................................................8, 9, 11
SAs
comprobacin en flujo de paquetes ......................68
SCEP (Simple Certificate Enrollment Protocol) ..........31
Secure Hash Algorithm-1
vase SHA-1
SecurID
L2TP ........................................................................217
Seguridad IP
vase IPSec
SHA-1 ................................................................................6
SNMP
archivos MIB, importacin ...................................262
supervisin de VPN ...............................................262
supervisin de VPN ...........................................250 a 262
cambios de estado ........................................250, 254
direccin de destino ....................................252 a 255
direccin de destino, XAuth .................................253
directivas ................................................................253
diseo de rutas ........................................................74
interfaz de salida .........................................252 a 255
opcin de reencriptacin..............................251, 268
peticiones de eco ICMP ........................................262
SNMP ......................................................................262
T
tabla NHTB .........................................................263 a 268
asignacin de rutas a tneles ...............................264
entradas automticas ............................................267
entradas manuales ................................................267
esquema de direccionamiento ............................266
TCP
comprobacin de indicador SYN.........................307
Triple DES
vase 3DES
ndice
IX-III
U
UDP
encapsulacin NAT-T ............................................ 240
suma de comprobacin........................................ 245
usuarios
identificacin IKE compartida ................... 204 a 210
identificacin IKE de grupo ....................... 188 a 204
V
Verisign ........................................................................... 35
VPN
alias FQDN ............................................................. 133
AutoKey IKE .............................................................. 7
basadas en rutas o basadas en directivas ............ 64
consejos de configuracin.............................. 72 a 73
Diffie-Hellman, grupos ........................................... 11
directiva para bidireccionales .............................. 128
Fase 1 ......................................................................... 9
Fase 2 ....................................................................... 11
flujo de paquetes ............................................. 66 a 71
grupos redundantes, procedimiento de
recuperacin........................................................ 306
grupos VPN ............................................................ 302
ID de proxy, coincidencia ...................................... 72
intercambio Diffie-Hellman ................................... 11
MIP.......................................................................... 143
modo de transporte .................................................. 4
IX-IV
ndice
modo dinmico .......................................................10

modo principal ........................................................10
mltiples tneles por interfaz de tnel ..... 263 a 300
NAT-dst ...................................................................143
NAT-src ...................................................................145
opciones criptogrficas ................................... 50 a 64
proteccin contra reprocesamiento de
paquetes .................................................................12
puertas de enlace redundantes ................. 301 a 314
SA ................................................................................8
supervisin y reencriptacin de VPN..................251
tnel siempre activo .............................................251
VPN AutoKey IKE .............................................................7
administracin...........................................................7
VPN basada en directivas .............................................64
VPN basadas en rutas ........................................... 64 a 65
VPNs
FQDN para puertas de enlace.................... 132 a 142
NAT para direcciones superpuestas .......... 142 a 154
W
WINS
ajustes de L2TP......................................................217
X
XAuth
supervisin de VPN ...............................................253

VPN Juniper

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VPN Juniper

Hochgeladen von

Copyright:

Verfügbare Formate

Conceptos y ejemplos

Manual de referencia de ScreenOS

Versin 6.0.0, Rev. 02

Juniper Networks, Inc.

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.

Convenciones del documento ....................................................................... viii

Seguridad del protocolo de Internet

Introduccin a las redes privadas virtuales....................................................... 2

Criptografa de claves pblicas

Introduccin a la criptografa de claves pblicas ............................................ 20

Manual de referencia de ScreenOS: Conceptos y ejemplos

Renovacin automtica de certificado ..................................................... 34

Directrices para las redes privadas virtuales

Redes privadas virtuales de punto a punto

Configuraciones VPN punto a punto............................................................... 82

Redes privadas virtuales de acceso telefnico

Acceso telefnico .........................................................................................164

VPN de acceso telefnico basada en directivas, interlocutor dinmico ..177

Protocolo de encapsulamiento de la capa 2

Introduccin al L2TP ....................................................................................211

Funciones avanzadas de redes privadas virtuales

Manual de referencia de ScreenOS: Conceptos y ejemplos

Comprobacin de indicador TCP SYN....................................................307

Redes privadas virtuales de AutoConnect

Vista general ................................................................................................331

Acerca de este volumen

Captulo 1, Seguridad del protocolo de Internet, que presenta los elementos

Captulo 2, Criptografa de claves pblicas, donde se ofrece una introduccin

Captulo 3, Directrices para las redes privadas virtuales, que explica el

Captulo 4, Redes privadas virtuales de punto a punto, que explica cmo

Captulo 5, Redes privadas virtuales de acceso telefnico, donde se explica

Captulo 6, Protocolo de encapsulamiento de la capa 2, que describe el

Captulo 7, Funciones avanzadas de redes privadas virtuales, que explica los

Captulo 8, Redes privadas virtuales de AutoConnect, que describe cmo

Manual de referencia de ScreenOS: Conceptos y ejemplos

Convenciones del documento

Convenciones de la interfaz de usuario web en la pgina viii

Convenciones de interfaz de lnea de comandos en la pgina viii

Convenciones de nomenclatura y conjuntos de caracteres en la pgina ix

Convenciones para las ilustraciones en la pgina x

Convenciones de la interfaz de usuario web

Convenciones de interfaz de lnea de comandos

Convenciones del documento

Los elementos entre corchetes [ ] son opcionales.

Los elementos entre llaves { } son obligatorios.

Acerca de este volumen

Si existen dos o ms opciones alternativas, aparecern separadas entre s por

Las variables aparecen en cursiva:

En el texto, los comandos estn en negrita y las variables en cursiva.

Convenciones de nomenclatura y conjuntos de caracteres

Si una cadena de nombre tiene uno o ms espacios, la cadena completa deber

Cualquier espacio al comienzo o al final de una cadena entrecomillada se

Los espacios consecutivos mltiples se tratan como uno solo.

En las cadenas de nombres se distingue entre maysculas y minsculas; por el

ScreenOS admite los siguientes conjuntos de caracteres:

Conjuntos de caracteres de un byte (SBCS) y conjuntos de caracteres de

Caracteres ASCII desde el 32 (0x20 en hexadecimal) al 255 (0xff); a excepcin

Convenciones del documento

Manual de referencia de ScreenOS: Conceptos y ejemplos

Convenciones para las ilustraciones

Interfaces de zonas de seguridad:

Red de rea local (LAN) con